Guía Del Programador Pragmático
Cuida tu obra de arte
¿Por qué desperdiciar tu vida desarrollando software si no te preocupas en hacerlo bien?
¡Piensa!, sobre tu trabajo
Desconecta el piloto automático y toma el control. Critica y evalúa constantemente tu trabajo.
Proporciona opciones, no excusas
En vez de excusas, propón opciones. No digas que no se puede hacer algo, explica mejor lo que sí puedes hacer.
No vivas con ventanas rotas
Corrige malos diseños, decisiones equivocadas y el código mal escrito cuando lo veas.
Sé un catalizador para cambios
No puedes forzar que la gente cambie. En vez de eso,muestra cómo podría ser el futuro y ayúdalos a participar en tu creación.
Recuerda el "Gran Cuadro"
No te obsesiones con los detalles porque hacen olvidarte de lo que ocurre alrededor.
Haz de la calidad un requisito imprescindible
Involucra a los usuarios para determinar las necesidades de calidad reales del proyecto.
Invierte regularmente en conocimiento
Haz de aprender un hábito
Analiza de forma crítica lo que lees y escuchas
No te dejes convencer por vendedores, dogmas o medios. Analiza la información en tus términos y en basada en tu proyecto.
Importa tanto lo que dices como la forma de decirlo
No tiene sentido tener buenas ideas si no las transmitimos con eficacia.
No te repitas
Cada pieza de conocimiento debe de tener una única e inequívoca representación dentro de un sistema.
Hazlo fácil de reutilizar
Si es fácil de reutilizar, la gente lo hará reutilizable. Crea un entorno que apoye la reutilización.
Elimina los efectos entre cosas no relacionadas
Los componentes de un diseño son autónomos, independientes y tienen un único propósito bien definido.
No hay decisiones finales
Las decisiones no se deben grabar en una piedra, sino en laarena de la playa. Cualquier decisión debe ser susceptible a cambio.
Tracea para llegar a to objetivo
Haz distintas pruebas y tracea los resultados para ver cómo se van compenetrando para llegar a nuestro objetivo.
Usa prototipos para aprender
Crear prototipos es un experiencia para el aprendizaje. Su valor no reside en el código generado, si no en las lecciones que aprendes al crearlo.
Programa cerca del dominio
Diseña y programa usando el mismo lenguaje usado por el usuario.
Haz estimaciones para evitar sorpresas
Haz una estimación antes de empezar. Podrás adelantarte a los posibles problemas futuros.
Sincroniza tu agenda con el código
Usa la experiencia que vayas ganando para refinar las escalas temporales de entrega del proyecto.
Guarda tu conocimiento en texto plano
El texto plano nunca será obsoleto. Ayuda a aprovechar tu trabajo y simplifica la depuración así como las pruebas.
Usa el poder de la línea (Shell) de comandos
Usa la línea de comandos (Shell) para resultados seguros que no sean interferidos por las interfaces gráficas.
Utiliza un único buen editor
El editor debe de ser una extensión de tu mano. Asegúrate que es configurable, ampliable (plugins) y programable.
Siempre controla el código fuente
El control del código fuente es una máquina del tiempo, siempre puedes volver atrás.
Arregla el problema, no la culpa
No importa de quién o de qué es la culpa, sigue siendo un problema de todas formas y todavía necesita ser reparado.
No te asustes de depurar (debugging)
Respira profundamente y PIENSA en la causa delerror.
El error no es de la "x"
Es raro encontrar un error en el Sistema Operativo o en el compilador, o incluso en librerías de terceros. El error (bug) siempre es más probable que esté en la aplicación.
No asumes nada, pruébalo
Prueba tu hipótesis en el entorno actual que tengas, con datos reales y condiciones límites.
Aprende un lenguaje para manipular texto
Gastas una gran parte del día peleando con texto. ¿Por qué no hacer que el ordenador haga el trabajo por ti?
Escribe código que escriba código
Los generadores de código aumentan la productividad y evitan la duplicación.
No se puede escribir el software perfecto
El software no puede ser perfecto. Protege elcódigo y a los usuarios de errores inevitables.
Diseña con contratos
Recurre a los contratos para documentar y comprobar que el código hace realmente lo que tiene que hacer.
Error tempranero
Un error cuanto antes sea detectado mejor, hará menos daño que aquel que se detecte tarde, hará que creemos que la aplicación funciona.
Usa afirmaciones para prevenir lo imposible
Las afirmaciones validan tu hipótesis. Úsalas para proteger el código de un mundo desconocido.
Usa excepciones para los problemas excepcionales
El abuso del uso de excepciones pueden convertir tu aplicación en poco legible y sotenible. Usa las excepciones para casos excepcionales.
Acaba lo que empiezas
Siempre que sea posible, la rutina o el objeto asignado a un recurso debe de ser borrado cuando ya no sea necesario.
Minimiza el acoplamiento entre módulos
Evita el acoplamiento debido al código "tímido" y aplica la Ley de Demeter .
Configura, no integres
Implementa las opciones para una tecnología usando opciones de configuración, no a través de integración ó ingeniería.
Coloca abstracciones en código, detalles en metadatos
Programa para el caso general, y coloca las especificaciones fuera del código base compilado.
Analiza el flujo de trabajo para mejorar la concurrencia
Aprovecha la concurrencia en el flujo de trabajo del usuario.
Diseña servicios de uso
Diseña en términos de servicios independientes, detrás de objetos concurrentes bien definidos, interfaces consitentes.
Siempre diseña para la concurrencia
Permite la concurrencia, y diseñarás interfaces más limpias.
Separa las vistas desde los modelos
Gana flexibilidad a bajo coste diseñando tu aplicación en términos de modelos y vistas.
Usa pizarras para coordinar el flujo de trabajo
Usa las pizarras para coordinar agentes y hechos dispares, manteniendo la independencia y el aislamiento entre los participantes.
No programes por coincidencia
Confíe sólo en las cosas confiables. Ten cuidado con la complejidad accidental, y no confundas una feliz coincidencia con un plan organizado.
Haz una estimación del orden de tus algoritmos
Ten una idea de la longitud de las cosas antes de empezar a escribir código.
Prueba tus estimaciones
El análisis matemático no te lo dice todo. Prueba el tiempo consumido por tu código en su entorno final.
Refactoriza pronto, refactoriza a menudo
Así como quitas las malas hierbas de un jardín y lo reorganizas, reescribe, haz de nuevo y rediseña el código cuando sea necesario. Arreglala raíz del problema.
Diseño a prueba
Empieza a pensar en las pruebas antes de escribir una línea de código.
Prueba tu software, o lo harán tus usuarios
Prueba sin piedad. No hagas que los usuarios encuentren los errores por ti.
No uses asistentes de código que no comprendas
Los asistentes pueden generar montones de código. Asegúrate de entender todo antes de incorporarlo a tu proyecto.
No reúnas requisistos, búscalos
Los requisitos rara vez están en la superficie. Están enterrados bajo capas de supuestos, conceptos erróneos y política.
Trabaja como un usuario para pensar como un usuario
Esta es la mejor forma deconocer cómo funciona el sistema que utilizarán realmente.
Las abstracciones viven más que los detalles
Invertir en abstracción, no en la implementación. Las abstracciones pueden sobrevivir.
Usa un glosario del proyecto
Crea y mantén una única fuente de todos los términos y vocabulario específico de un proyecto.
No pienses fuera de la caja, encuentra la caja
Cuando nos enfrentamos a un problema imposible, identifica las limitaciones reales. Tienes que preguntarte ¿Se tiene que hacer de esta manera? ¿Hay que hacerlo en todos?
Empieza cuando estés listo
Has ido adquiriendo experiencia toda tu vida. No ignores las dudas que te puedan surgir.
Algunas cosas son mejores cuando las acabas que cuando se describen
No caigas en la espiral de las especificaciones, en algún momento tenemos que empezar a programar.
No seas un esclavo de los métodos formales
No adoptes ciegamente cualquier técnica sin suponerla en el contexto de tus prácticas de desarrollo y capacidades.
Las herramientas costosas no producen mejores diseños
Ten cuidado con las exageraciones de los proveedores, el dogma de la industria, y el precio. Juzga las herramientas en función a sus méritos.
Organiza los equipos alrededor de la funcionalidad
No separes diseñadores de programadores ni los probadores (testers) de los modeladores de datos.
Construye equipos en función de tu manera de construir código.
No uses el procedimientos de manual
Un Shell script o fichero por lotes se ejecutará las mismas instrucciones, en el mismo orden, una y otra vez.
Prueba pronto, prueba a menudo, prueba de forma automática
Las pruebas que se ejecutan cada vez que compilas son más efectivas que los planes de pruebas teóricos.
La programación no está terminada hasta que todos los tests hayan pasado
Queda todo dicho.
Usa saboteadores para probar tu prueba
Introducir "bugs" a propósito en una copia separada de la fuente para verificar que las pruebas detectan dicho error.
Prueba la cobertura de un estado, no la cobertura del código
Identifica y pon a pruebalos estados de los programas. Probar sólo líneas de código no es suficiente.
Encuentra errores una sola vez
Una vez que los probadores (humanos) encuentran un error, esta debe de ser la última vez que se encuentra. A partir de ahora tienen que ser las pruebas automáticas las que comprueben los errores.
El inglés es un lenguaje de programación
escribir documentos igual que escribes código:respeta el principio DRY(No Te Repitas, Don't Repeat Yourself), usa metadatos, MVC, generación automática, así sucesivamente.
Crea la documentación con el código, no la metas con calzador
La documentación creada separadamente del código acaba siendo poco precisa y actualizada.
De forma gradual, aumenta las expectativas de los usuarios
Cuando comprendas las expectativas de los usuarios, entonces es el momento de ofrecer un poco más.
Firma tu trabajo
Los artesanos de la Edad Media se sentían orgullosos de firmar su trabajo. Tu también deberías.
Traducción libre de:
"The Pragmatic Programmer" by Andrew Hunt and David Thomas
Published by Addison-Wesley, Oct 1999
ISBN: 020161622X
¿Por qué desperdiciar tu vida desarrollando software si no te preocupas en hacerlo bien?
¡Piensa!, sobre tu trabajo
Desconecta el piloto automático y toma el control. Critica y evalúa constantemente tu trabajo.
Proporciona opciones, no excusas
En vez de excusas, propón opciones. No digas que no se puede hacer algo, explica mejor lo que sí puedes hacer.
No vivas con ventanas rotas
Corrige malos diseños, decisiones equivocadas y el código mal escrito cuando lo veas.
Sé un catalizador para cambios
No puedes forzar que la gente cambie. En vez de eso,muestra cómo podría ser el futuro y ayúdalos a participar en tu creación.
Recuerda el "Gran Cuadro"
No te obsesiones con los detalles porque hacen olvidarte de lo que ocurre alrededor.
Haz de la calidad un requisito imprescindible
Involucra a los usuarios para determinar las necesidades de calidad reales del proyecto.
Invierte regularmente en conocimiento
Haz de aprender un hábito
Analiza de forma crítica lo que lees y escuchas
No te dejes convencer por vendedores, dogmas o medios. Analiza la información en tus términos y en basada en tu proyecto.
Importa tanto lo que dices como la forma de decirlo
No tiene sentido tener buenas ideas si no las transmitimos con eficacia.
No te repitas
Cada pieza de conocimiento debe de tener una única e inequívoca representación dentro de un sistema.
Hazlo fácil de reutilizar
Si es fácil de reutilizar, la gente lo hará reutilizable. Crea un entorno que apoye la reutilización.
Elimina los efectos entre cosas no relacionadas
Los componentes de un diseño son autónomos, independientes y tienen un único propósito bien definido.
No hay decisiones finales
Las decisiones no se deben grabar en una piedra, sino en laarena de la playa. Cualquier decisión debe ser susceptible a cambio.
Tracea para llegar a to objetivo
Haz distintas pruebas y tracea los resultados para ver cómo se van compenetrando para llegar a nuestro objetivo.
Usa prototipos para aprender
Crear prototipos es un experiencia para el aprendizaje. Su valor no reside en el código generado, si no en las lecciones que aprendes al crearlo.
Programa cerca del dominio
Diseña y programa usando el mismo lenguaje usado por el usuario.
Haz estimaciones para evitar sorpresas
Haz una estimación antes de empezar. Podrás adelantarte a los posibles problemas futuros.
Sincroniza tu agenda con el código
Usa la experiencia que vayas ganando para refinar las escalas temporales de entrega del proyecto.
Guarda tu conocimiento en texto plano
El texto plano nunca será obsoleto. Ayuda a aprovechar tu trabajo y simplifica la depuración así como las pruebas.
Usa el poder de la línea (Shell) de comandos
Usa la línea de comandos (Shell) para resultados seguros que no sean interferidos por las interfaces gráficas.
Utiliza un único buen editor
El editor debe de ser una extensión de tu mano. Asegúrate que es configurable, ampliable (plugins) y programable.
Siempre controla el código fuente
El control del código fuente es una máquina del tiempo, siempre puedes volver atrás.
Arregla el problema, no la culpa
No importa de quién o de qué es la culpa, sigue siendo un problema de todas formas y todavía necesita ser reparado.
No te asustes de depurar (debugging)
Respira profundamente y PIENSA en la causa delerror.
El error no es de la "x"
Es raro encontrar un error en el Sistema Operativo o en el compilador, o incluso en librerías de terceros. El error (bug) siempre es más probable que esté en la aplicación.
No asumes nada, pruébalo
Prueba tu hipótesis en el entorno actual que tengas, con datos reales y condiciones límites.
Aprende un lenguaje para manipular texto
Gastas una gran parte del día peleando con texto. ¿Por qué no hacer que el ordenador haga el trabajo por ti?
Escribe código que escriba código
Los generadores de código aumentan la productividad y evitan la duplicación.
No se puede escribir el software perfecto
El software no puede ser perfecto. Protege elcódigo y a los usuarios de errores inevitables.
Diseña con contratos
Recurre a los contratos para documentar y comprobar que el código hace realmente lo que tiene que hacer.
Error tempranero
Un error cuanto antes sea detectado mejor, hará menos daño que aquel que se detecte tarde, hará que creemos que la aplicación funciona.
Usa afirmaciones para prevenir lo imposible
Las afirmaciones validan tu hipótesis. Úsalas para proteger el código de un mundo desconocido.
Usa excepciones para los problemas excepcionales
El abuso del uso de excepciones pueden convertir tu aplicación en poco legible y sotenible. Usa las excepciones para casos excepcionales.
Acaba lo que empiezas
Siempre que sea posible, la rutina o el objeto asignado a un recurso debe de ser borrado cuando ya no sea necesario.
Minimiza el acoplamiento entre módulos
Evita el acoplamiento debido al código "tímido" y aplica la Ley de Demeter .
Configura, no integres
Implementa las opciones para una tecnología usando opciones de configuración, no a través de integración ó ingeniería.
Coloca abstracciones en código, detalles en metadatos
Programa para el caso general, y coloca las especificaciones fuera del código base compilado.
Analiza el flujo de trabajo para mejorar la concurrencia
Aprovecha la concurrencia en el flujo de trabajo del usuario.
Diseña servicios de uso
Diseña en términos de servicios independientes, detrás de objetos concurrentes bien definidos, interfaces consitentes.
Siempre diseña para la concurrencia
Permite la concurrencia, y diseñarás interfaces más limpias.
Separa las vistas desde los modelos
Gana flexibilidad a bajo coste diseñando tu aplicación en términos de modelos y vistas.
Usa pizarras para coordinar el flujo de trabajo
Usa las pizarras para coordinar agentes y hechos dispares, manteniendo la independencia y el aislamiento entre los participantes.
No programes por coincidencia
Confíe sólo en las cosas confiables. Ten cuidado con la complejidad accidental, y no confundas una feliz coincidencia con un plan organizado.
Haz una estimación del orden de tus algoritmos
Ten una idea de la longitud de las cosas antes de empezar a escribir código.
Prueba tus estimaciones
El análisis matemático no te lo dice todo. Prueba el tiempo consumido por tu código en su entorno final.
Refactoriza pronto, refactoriza a menudo
Así como quitas las malas hierbas de un jardín y lo reorganizas, reescribe, haz de nuevo y rediseña el código cuando sea necesario. Arreglala raíz del problema.
Diseño a prueba
Empieza a pensar en las pruebas antes de escribir una línea de código.
Prueba tu software, o lo harán tus usuarios
Prueba sin piedad. No hagas que los usuarios encuentren los errores por ti.
No uses asistentes de código que no comprendas
Los asistentes pueden generar montones de código. Asegúrate de entender todo antes de incorporarlo a tu proyecto.
No reúnas requisistos, búscalos
Los requisitos rara vez están en la superficie. Están enterrados bajo capas de supuestos, conceptos erróneos y política.
Trabaja como un usuario para pensar como un usuario
Esta es la mejor forma deconocer cómo funciona el sistema que utilizarán realmente.
Las abstracciones viven más que los detalles
Invertir en abstracción, no en la implementación. Las abstracciones pueden sobrevivir.
Usa un glosario del proyecto
Crea y mantén una única fuente de todos los términos y vocabulario específico de un proyecto.
No pienses fuera de la caja, encuentra la caja
Cuando nos enfrentamos a un problema imposible, identifica las limitaciones reales. Tienes que preguntarte ¿Se tiene que hacer de esta manera? ¿Hay que hacerlo en todos?
Empieza cuando estés listo
Has ido adquiriendo experiencia toda tu vida. No ignores las dudas que te puedan surgir.
Algunas cosas son mejores cuando las acabas que cuando se describen
No caigas en la espiral de las especificaciones, en algún momento tenemos que empezar a programar.
No seas un esclavo de los métodos formales
No adoptes ciegamente cualquier técnica sin suponerla en el contexto de tus prácticas de desarrollo y capacidades.
Las herramientas costosas no producen mejores diseños
Ten cuidado con las exageraciones de los proveedores, el dogma de la industria, y el precio. Juzga las herramientas en función a sus méritos.
Organiza los equipos alrededor de la funcionalidad
No separes diseñadores de programadores ni los probadores (testers) de los modeladores de datos.
Construye equipos en función de tu manera de construir código.
No uses el procedimientos de manual
Un Shell script o fichero por lotes se ejecutará las mismas instrucciones, en el mismo orden, una y otra vez.
Prueba pronto, prueba a menudo, prueba de forma automática
Las pruebas que se ejecutan cada vez que compilas son más efectivas que los planes de pruebas teóricos.
La programación no está terminada hasta que todos los tests hayan pasado
Queda todo dicho.
Usa saboteadores para probar tu prueba
Introducir "bugs" a propósito en una copia separada de la fuente para verificar que las pruebas detectan dicho error.
Prueba la cobertura de un estado, no la cobertura del código
Identifica y pon a pruebalos estados de los programas. Probar sólo líneas de código no es suficiente.
Encuentra errores una sola vez
Una vez que los probadores (humanos) encuentran un error, esta debe de ser la última vez que se encuentra. A partir de ahora tienen que ser las pruebas automáticas las que comprueben los errores.
El inglés es un lenguaje de programación
escribir documentos igual que escribes código:respeta el principio DRY(No Te Repitas, Don't Repeat Yourself), usa metadatos, MVC, generación automática, así sucesivamente.
Crea la documentación con el código, no la metas con calzador
La documentación creada separadamente del código acaba siendo poco precisa y actualizada.
De forma gradual, aumenta las expectativas de los usuarios
Cuando comprendas las expectativas de los usuarios, entonces es el momento de ofrecer un poco más.
Firma tu trabajo
Los artesanos de la Edad Media se sentían orgullosos de firmar su trabajo. Tu también deberías.
Traducción libre de:
"The Pragmatic Programmer" by Andrew Hunt and David Thomas
Published by Addison-Wesley, Oct 1999
ISBN: 020161622X
Comentarios