Consejos pragmáticos para programadores

pragprog-com.translate.goog/tips

Comprar →

Durante veinte años, las lecciones de The Pragmatic

Programmer han ayudado a una generación de programadores
a examinar la esencia misma del desarrollo de software,
independientemente de cualquier lenguaje, marco o
metodología en particular. Este título clásico aparece con
regularidad en las listas de "Diez mejores", y muchas
corporaciones lo emiten a sus nuevos empleados.

Andy y Dave escribieron este libro clásico e influyente para

ayudar a sus clientes a crear un mejor software y redescubrir el placer de la codificación.
Casi veinte años después, su consejo sigue siendo acertado, y la filosofía pragmática ha
generado cientos de libros, screencasts y audiolibros, así como miles de carreras e
historias de éxito.

Hemos publicado los 100 consejos del libro aquí para su referencia y disfrute. ¡Twittea y
comparte tus favoritos!

¡Feliz programación!

Consejos extraídos de The Pragmatic Programmer, 20th Anniversary Edition.

Reproducido con permiso del editor.

Consejo n. ° 1, pág. xxi:

Cuida tu artesanía

¿Por qué pasar la vida desarrollando software a menos que le importe hacerlo bien?

tuitea esto

Consejo n. ° 2, pág. xxi:

¡Pensar! Acerca de su trabajo

Apaga el piloto automático y toma el control. Constantemente critica y valora tu trabajo.

tuitea esto

Consejo n. ° 3, pág. 2:

Tienes agencia

1/18
Es tu vida. Agárralo y hazlo como quieras.

tuitea esto

Consejo n. ° 4, pág. 4:

Ofrezca opciones, no dé excusas poco convincentes

En lugar de excusas, brinde opciones. No digas que no se puede hacer; Explique lo que se
puede hacer.

tuitea esto

Consejo n. ° 5, pág. 7:

No vivas con ventanas rotas

Corrija los diseños incorrectos, las decisiones incorrectas y el código deficiente cuando los
vea.

tuitea esto

Consejo n. ° 6, pág. 9:

Sea un catalizador del cambio

No puedes forzar el cambio a la gente. En cambio, enséñeles cómo podría ser el futuro y
ayúdelos a participar en su creación.

tuitea esto

Consejo n. ° 7, pág. 10:

Recuerda el panorama general

No se concentre tanto en los detalles que se olvide de comprobar lo que sucede a su

alrededor.

tuitea esto

Consejo n. ° 8, pág. 12:

Haga de la calidad un problema de requisitos

Involucre a sus usuarios en la determinación de los requisitos reales de calidad del

proyecto.

tuitea esto

Consejo n. ° 9, pág. 15:

Invierta regularmente en su cartera de conocimientos

2/18
Haga del aprendizaje un hábito.

tuitea esto

Consejo n. ° 10, pág. 17:

Analice críticamente lo que lee y escucha

No se deje llevar por los vendedores, la publicidad mediática o el dogma. Analice la

información en términos de usted y su proyecto.

tuitea esto

Consejo n. ° 11, pág. 20:

El inglés es solo otro lenguaje de programación

Trate el inglés como un lenguaje más de programación. Escriba documentos como

escribiría código: respete el principio DRY, ETC, automatización, etc.

tuitea esto

Consejo n. ° 12, pág. 22:

Es tanto lo que dices como la forma en que lo dices

No tiene sentido tener grandes ideas si no las comunica de manera eficaz.

tuitea esto

Consejo n. ° 13, pág. 23:

Cree documentación, no la atornille

Es menos probable que la documentación creada por separado del código sea correcta y
esté actualizada.

tuitea esto

Consejo # 14, pág. 28:

Un buen diseño es más fácil de cambiar que un mal diseño

Una cosa está bien diseñada si se adapta a las personas que la utilizan. Para el código, eso
significa que debe adaptarse cambiando.

tuitea esto

Consejo n. ° 15, pág. 31:

SECO: no se repita

3/18
Cada pieza de conocimiento debe tener una representación única, inequívoca y autorizada
dentro de un sistema.

tuitea esto

Consejo n. ° 16, pág. 38:

Facilite su reutilización

Si es fácil de reutilizar, la gente lo hará. Cree un entorno que admita la reutilización.

tuitea esto

Consejo n. ° 17, pág. 40:

Eliminar efectos entre cosas no relacionadas

Diseñe componentes que sean autónomos, independientes y que tengan un propósito

único y bien definido.

tuitea esto

Consejo n. ° 18, pág. 48:

No hay decisiones finales

Ninguna decisión está grabada en piedra. En su lugar, considere que cada uno está escrito
en la arena de la playa y planifique el cambio.

tuitea esto

Consejo n. ° 19, pág. 49:

Renunciar a las modas pasajeras

Neal Ford dice: "La mejor práctica de ayer se convierte en el antipatrón del mañana". Elija
arquitecturas basadas en los fundamentos, no en la moda.

tuitea esto

Consejo n. ° 20, pág. 51:

Utilice balas trazadoras para encontrar el objetivo

Las balas trazadoras te permiten enfocarte en tu objetivo probando cosas y viendo qué tan
cerca aterrizan.

tuitea esto

Consejo n. ° 21, pág. 57:

Prototipo para aprender

4/18
La creación de prototipos es una experiencia de aprendizaje. Su valor no radica en el
código que produce, sino en las lecciones que aprende.

tuitea esto

Consejo n. ° 22, pág. 60:

Programa cercano al dominio del problema

Diseño y codificación en el lenguaje del dominio del problema.

tuitea esto

Consejo n. ° 23, pág. 66:

Estimación para evitar sorpresas

Estima antes de empezar. Detectará problemas potenciales desde el principio.

tuitea esto

Consejo n. ° 24, pág. 70:

Iterar el horario con el código

Use la experiencia que gane a medida que implementa para refinar las escalas de tiempo
del proyecto.

tuitea esto

Consejo n. ° 25, pág. 75:

Mantenga el conocimiento en texto sin formato

El texto sin formato no quedará obsoleto. Ayuda a aprovechar su trabajo y simplifica la

depuración y las pruebas.

tuitea esto

Consejo n. ° 26, pág. 79:

Usa los proyectiles de poder de mando

Utilice el shell cuando las interfaces gráficas de usuario no lo corten.

tuitea esto

Consejo n. ° 27, pág. 81:

Logre la fluidez del editor

5/18
Un editor es tu herramienta más importante. Sepa cómo hacer que haga lo que necesita,
de forma rápida y precisa.

tuitea esto

Consejo # 28, pág. 85:

Utilice siempre el control de versiones

El control de versiones es una máquina del tiempo para su trabajo; puedes volver.

tuitea esto

Consejo # 29, pág. 89:

Solucione el problema, no la culpa

En realidad, no importa si el error es culpa suya o de otra persona; sigue siendo su

problema y aún debe solucionarse.

tuitea esto

Consejo # 30, pág. 89:

Que no cunda el pánico

Esto es cierto para los autostopistas galácticos y para los desarrolladores.

tuitea esto

Consejo # 31, pág. 91:

Prueba fallida antes de corregir el código

Cree una prueba enfocada que revele el error antes de intentar solucionarlo.

tuitea esto

Consejo # 32, pág. 92:

Leer el maldito mensaje de error

La mayoría de las excepciones indican tanto qué falló como dónde falló. Si tiene suerte,
incluso puede obtener valores de parámetros.

tuitea esto

Consejo n. ° 33, pág. 95:

"Seleccionar" no está roto

6/18
Es raro encontrar un error en el sistema operativo o el compilador, o incluso en un
producto o biblioteca de terceros. Lo más probable es que el error esté en la aplicación.

tuitea esto

Consejo # 34, pág. 96:

No lo asuma, demuéstrelo

Demuestre sus suposiciones en el entorno real, con datos reales y condiciones de

contorno.

tuitea esto

Consejo n. ° 35, pág. 98:

Aprenda un lenguaje de manipulación de texto

Pasas gran parte del día trabajando con texto. ¿Por qué no hacer que la computadora lo
haga por usted?

tuitea esto

Consejo n. ° 36, pág. 102:

No se puede escribir un software perfecto

El software no puede ser perfecto. Proteja su código y a los usuarios de los inevitables
errores.

tuitea esto

Consejo n. ° 37, pág. 107:

Diseño con contratos

Utilice contratos para documentar y verificar que el código haga ni más ni menos de lo
que dice hacer.

tuitea esto

Consejo # 38, pág. 113:

Choque temprano

Un programa inactivo normalmente hace mucho menos daño que uno paralizado.

tuitea esto

Consejo # 39, pág. 115:

Utilice afirmaciones para prevenir lo imposible

7/18
Si no puede suceder, utilice afirmaciones para asegurarse de que no suceda. Las
afirmaciones validan sus suposiciones. Úselos para proteger su código de un mundo
incierto.

tuitea esto

Consejo # 40, pág. 118:

Termina lo que empiezas

Cuando sea posible, la función u objeto que asigna un recurso debe ser responsable de
desasignarlo.

tuitea esto

Consejo n. ° 41, pág. 121:

Actuar localmente

Mantenga el alcance de las variables mutables y los recursos abiertos breves y fácilmente
visibles.

tuitea esto

Consejo # 42, pág. 126:

Tome pequeños pasos, siempre

Pequeños pasos siempre; verifique la retroalimentación; y ajuste antes de continuar.

tuitea esto

Consejo n. ° 43, pág. 127:

Evite la adivinación

Solo mire hacia adelante hasta donde pueda ver.

tuitea esto

Consejo n. ° 44, pág. 131:

El código desacoplado es más fácil de cambiar

El acoplamiento une las cosas, por lo que es más difícil cambiar solo una cosa.

tuitea esto

Consejo n. ° 45, pág. 132:

Dile, no preguntes

8/18
No obtengas valores de un objeto, transfórmalos y luego pégalos. Haz que el objeto haga
el trabajo.

tuitea esto

Consejo n. ° 46, pág. 134:

No encadenar llamadas de método

Trate de no tener más de un punto cuando acceda a algo.

tuitea esto

Consejo # 47, pág. 136:

Evite los datos globales

Es como agregar un parámetro adicional a cada método.

tuitea esto

Consejo # 48, pág. 136:

Si es lo suficientemente importante para ser global, envuélvalo en una API

… Pero solo si realmente quieres que sea global.

tuitea esto

Consejo n. ° 49, pág. 149:

La programación se trata de código, pero los programas se tratan de datos

Todos los programas transforman datos, convirtiendo una entrada en una salida. Empiece
a diseñar utilizando transformaciones.

tuitea esto

Consejo n. ° 50, pág. 153:

No atesore el estado; Pásalo

No se quede con los datos dentro de una función o módulo. Tome uno y páselo.

tuitea esto

Consejo n. ° 51, pág. 161:

No pague el impuesto a la herencia

Considere alternativas que se adapten mejor a sus necesidades, como interfaces,

delegación o mixins

9/18
 tuitea esto

Consejo n. ° 52, pág. 162:

Prefiere interfaces para expresar polimorfismo

Las interfaces hacen explícito el polimorfismo sin el acoplamiento introducido por

herencia.

tuitea esto

Consejo # 53, pág. 163:

Delegado de servicios: Has-A Trumps Is-A

No herede de los servicios: conténgalos.

tuitea esto

Consejo n. ° 54, pág. 165:

Utilice Mixins para compartir la funcionalidad

Los mixins agregan funcionalidad a las clases sin el impuesto a la herencia. Combine con
interfaces para un polimorfismo indoloro.

tuitea esto

Consejo n. ° 55, pág. 166:

Parametrice su aplicación usando una configuración externa

Cuando el código se basa en valores que pueden cambiar después de que la aplicación se
activa, mantenga esos valores externos a la aplicación. Cuando su aplicación se ejecute en
diferentes entornos, y potencialmente para diferentes clientes, mantenga el entorno y los
valores específicos del cliente fuera de la aplicación.

tuitea esto

Consejo # 56, pág. 171:

Analice el flujo de trabajo para mejorar la simultaneidad

Aproveche la simultaneidad en el flujo de trabajo de su usuario.

tuitea esto

Consejo # 57, pág. 174:

El estado compartido es un estado incorrecto

10/18
El estado compartido abre una gran cantidad de gusanos que a menudo solo se pueden
solucionar reiniciando.

tuitea esto

Consejo # 58, pág. 180:

Los fallos aleatorios suelen ser problemas de simultaneidad

Las variaciones en el tiempo y el contexto pueden exponer errores de concurrencia, pero

de manera inconsistente e irreproducible.

tuitea esto

Consejo # 59, pág. 182:

Usar actores para simultaneidad sin estado compartido

Utilice Actors para administrar el estado concurrente sin sincronización explícita.

tuitea esto

Consejo # 60, pág. 189:

Use Blackboards para coordinar el flujo de trabajo

Utilice pizarrones para coordinar hechos y agentes dispares, mientras mantiene la

independencia y el aislamiento entre los participantes.

tuitea esto

Consejo # 61, pág. 194:

Escuche a su lagarto interior

Cuando siente que su código está retrocediendo, es realmente su subconsciente tratando

de decirle que algo anda mal.

tuitea esto

Consejo # 62, pág. 200:

No programe por coincidencia

Confíe solo en cosas confiables. Tenga cuidado con la complejidad accidental y no

confunda una feliz coincidencia con un plan intencionado.

tuitea esto

Consejo # 63, pág. 207:

Estime el orden de sus algoritmos

11/18
Tenga una idea del tiempo que pueden tardar las cosas antes de escribir el código.

tuitea esto

Consejo # 64, pág. 208:

Pruebe sus estimaciones

El análisis matemático de algoritmos no te lo dice todo. Intente cronometrar su código en

su entorno de destino.

tuitea esto

Consejo # 65, pág. 212:

Refactorizar temprano, refactorizar a menudo

Del mismo modo que podría desyerbar y reorganizar un jardín, reescriba, reelabore y
rediseñe el código cuando lo necesite. Arregle la raíz del problema.

tuitea esto

Consejo # 66, pág. 214:

Las pruebas no se tratan de encontrar errores

Una prueba es una perspectiva de su código y le brinda comentarios sobre su diseño, api y
acoplamiento.

tuitea esto

Consejo # 67, pág. 216:

Una prueba es el primer usuario de su código

Utilice sus comentarios para guiar lo que hace.

tuitea esto

Consejo n. ° 68, pág. 218:

Construya de punta a punta, no de arriba hacia abajo ni de abajo hacia arriba

Construya pequeñas piezas de funcionalidad de extremo a extremo, aprendiendo sobre el

problema a medida que avanza.

tuitea esto

Consejo # 69, pág. 221:

Diseño para probar

12/18
Empiece a pensar en probar antes de escribir una línea de código.

tuitea esto

Consejo n. ° 70, pág. 223:

Pruebe su software, o sus usuarios lo harán

Prueba sin piedad. No hagas que tus usuarios encuentren errores por ti.

tuitea esto

Consejo # 71, pág. 224:

Utilice pruebas basadas en propiedades para validar sus suposiciones

Las pruebas basadas en propiedades probarán cosas que nunca pensó probar, y ejercitar
su código de una manera que no está destinada a ser utilizada.

tuitea esto

Consejo # 72, pág. 234:

Mantenlo simple y minimiza las superficies de ataque

El código complejo crea un caldo de cultivo para errores y oportunidades para que los
atacantes exploten.

tuitea esto

Consejo # 73, pág. 235:

Aplicar parches de seguridad rápidamente

Los atacantes implementan exploits tan rápido como pueden, tienes que ser más rápido.

tuitea esto

Consejo # 74, pág. 242:

Nombre bien; Cambiar nombre cuando sea necesario

Nombre para expresar su intención a los lectores y cámbiele el nombre tan pronto como
cambie esa intención.

tuitea esto

Consejo n. ° 75, pág. 244:

Nadie sabe exactamente lo que quiere

Puede que conozcan una dirección general, pero no conocerán los giros y vueltas.

13/18
 tuitea esto

Consejo # 76, pág. 245:

Los programadores ayudan a las personas a comprender lo que quieren

El desarrollo de software es un acto de creación conjunta entre usuarios y programadores.

tuitea esto

Consejo # 77, pág. 246:

Los requisitos se aprenden en un circuito de retroalimentación

Comprender los requisitos requiere exploración y retroalimentación, por lo que las

consecuencias de las decisiones se pueden usar para refinar las ideas iniciales.

tuitea esto

Consejo # 78, pág. 247:

Trabajar con un usuario para pensar como un usuario

Es la mejor manera de conocer cómo se utilizará realmente el sistema.

tuitea esto

Consejo n. ° 79, pág. 248:

La política son metadatos

No codifique la política en un sistema; en su lugar, expresarlo como metadatos utilizados

por el sistema.

tuitea esto

Consejo # 80, pág. 251:

Utilice un glosario de proyectos

Cree y mantenga una fuente única de todos los términos y vocabulario específicos para un
proyecto.

tuitea esto

Consejo # 81, pág. 254:

No piense fuera de la caja: encuentre la caja

Cuando se enfrente a un problema imposible, identifique las limitaciones reales.

Pregúntese: “¿Tiene que hacerse de esta manera? ¿Tiene que hacerse en absoluto? "

14/18
 tuitea esto

Consejo n. ° 82, pág. 259:

No entre en el código solo

La programación puede ser difícil y exigente. Lleva a un amigo contigo.

tuitea esto

Consejo n. ° 83, pág. 259:

Agile no es un sustantivo; Ágil es la forma de hacer las cosas

Agile es un adjetivo: es cómo haces algo.

tuitea esto

Consejo n. ° 84, pág. 264:

Mantener equipos pequeños y estables

Los equipos deben ser pequeños y estables, donde todos confíen y dependan unos de
otros.

tuitea esto

Consejo n. ° 85, pág. 266:

Prográmelo para que suceda

Si no lo programa, no sucederá. Programar reflexión, experimentación, aprendizaje y

mejora de habilidades.

tuitea esto

Consejo n. ° 86, pág. 268:

Organice equipos completamente funcionales

Organícese en torno a la funcionalidad, no a las funciones laborales. No separe a los

diseñadores de UI / UX de los codificadores, frontend del backend, probadores de los
modeladores de datos, diseño de implementación. Cree equipos para que pueda crear
código de un extremo a otro, de forma incremental e iterativa.

tuitea esto

Consejo n. ° 87, pág. 271:

Haz lo que funciona, no lo que está de moda

15/18
No adopte un método o técnica de desarrollo solo porque otras empresas lo estén
haciendo. Adopte lo que funcione para su equipo, en su contexto.

tuitea esto

Consejo # 88, pág. 273:

Entregue cuando los usuarios lo necesiten

No espere semanas o meses para entregar solo porque su proceso lo requiera.

tuitea esto

Consejo n. ° 89, pág. 274:

Utilice el control de versiones para impulsar compilaciones, pruebas y lanzamientos

Utilice confirmaciones o empujes para activar compilaciones, pruebas y lanzamientos.

Utilice una etiqueta de control de versiones para implementar en producción.

tuitea esto

Consejo n. ° 90, pág. 275:

Probar temprano, probar a menudo, probar automáticamente

Las pruebas que se ejecutan con cada compilación son mucho más efectivas que los planes
de prueba que se encuentran en un estante.

tuitea esto

Consejo n. ° 91, pág. 275:

La codificación no se ha terminado hasta que se ejecuten todas las pruebas

'Nuff dijo.

tuitea esto

Consejo n. ° 92, pág. 277:

Utilice saboteadores para probar sus pruebas

Introduzca los errores a propósito en una copia separada de la fuente para verificar que
las pruebas los detecten.

tuitea esto

Consejo n. ° 93, pág. 278:

Cobertura estatal de prueba, no cobertura de código

16/18
Identificar y probar estados importantes del programa. Probar solo líneas de código no es
suficiente.

tuitea esto

Consejo n. ° 94, pág. 278:

Encuentra errores una vez

Una vez que un evaluador humano encuentra un error, debería ser la última vez que un
evaluador humano encuentra ese error. Las pruebas automáticas deberían comprobarlo a
partir de ese momento.

tuitea esto

Consejo n. ° 95, pág. 279:

No utilice procedimientos manuales

Una computadora ejecutará las mismas instrucciones, en el mismo orden, una y otra vez.

tuitea esto

Consejo # 96, pág. 281:

Deleite a los usuarios, no se limite a entregar código

Desarrolle soluciones que generen valor comercial para sus usuarios y deleítelos todos los
días.

tuitea esto

Consejo # 97, pág. 282:

Firma tu trabajo

Los artesanos de una época anterior estaban orgullosos de firmar su trabajo. Tú también
deberías estarlo.

tuitea esto

Consejo # 98, pág. 286:

Primero, no hagas daño

El fracaso es inevitable. Asegúrate de que nadie sufra por eso.

tuitea esto

Consejo n. ° 99, pág. 287:

No habilites escoria

17/18
Porque también corres el riesgo de convertirte en uno.

tuitea esto

Consejo n. ° 100, pág. 287:

Es tu vida. Compártelo. Celebrarlo. Constrúyelo. ¡Y DIVERTIRSE!

Disfruta de esta increíble vida que tenemos y haz grandes cosas.

tuitea esto

18/18