Guía PragmaticProgrammer en castellano: c astellano: Cuida tu obra de arte. ¿Por qué desperdiciar tu vida desarrollando software sino 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 ven tanas 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. Hacer de la calidad un u n requisito imprescindible. Involucra a los usuarios para determinar
las necesidades de calidad reales del proyecto. Invertir 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,
dogma 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
sino las transmitimos con eficacia. e ficacia. 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 la
arena 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, sino 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 del
error. El error no es de la ³select´. 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 pe rfecto. El software no puede ser perfecto. Protege el
có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. Arregla la 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 reunasrequisistos, 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 de
conocer 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 prueba
los 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, DontRepeatYourself), 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.
Five books every Java developer must own Update: Welcome,
Javalobby readers! You might be interested in the followup to this post. Thanksforthegreatfeedback and suggestions. y
y
Pragmatic Programmer by Andrew Hunt and David Thomas This is absolutely required reading for any software developer, regardless of language. If you are lost when people are talking about "keeping it DRY" or the danger of broken windows, you need this book. Effective Java by Joshua Bloch Effective Java is absolutely crucial if you create any APIs, and if you ever see public class... you are writing APIs, whether its for a team of one
or one thousand. Bloch covers issues like immutability, properly implementing equals and hashCode, the benefits of composition over inheritance, and the value of static factory methods. He talks about all sort of common beg inner mistakes such as using interfaces for constants, using float or double when you nee d absolute precision, overuse of Strings, and crappy singleton implementations. After you've read this, listen to the JavaPosse interview with Bloch to hear how about a possible second edition and take a look at Java Puzzlers for fun gotchas found in Java.
y
Design Patterns by the GoF Design Patterns is by the Gang of Four (GOF) is often lauded as a classic read for anyone doing OO development, whether the language be Smalltalk, C++, or Java. If you aren't familiar with Design Patterns but have been doing OO for awhile, you have already been using some of the patterns without knowing it. Having a common vocabularily to share with others is very powerful, so know the 26 classic patterns is important for any Java dev eloper today.
y
Extreme
ProgrammingExplained: Embrace Change
by Kent Beck and Cynthia Andres When I first read XP:
Explained,
so many of the concepts
made me nod my head in agreement and wonder how typical software development goes against so many of its principles. XP and agile isn't rocket science or a silver bullet, its just good common sense. "Take small steps, one at a time. Communication is vital. Feedback is important. Change is constant, so work with it instead of fig hting it." It sounds like advice your mom or grandpa gave you when you were eight years old, so why does it take a "revolution" or a "movement" to put these things into practice for softwar e development? That might be a topic for another essay, so for now just get this book. Its essential for understanding the ideas behind XP and agility. Note that the second edition is quite different from the first - it has a broader, less technical apporach. They are both worth reading, the first moreso for programmers and the second for customers and managers.
y
Programming Ruby by Dave Thomas et al, or Practical Common Lisp, or Learning Python or... The fifth book in this list really isn't a specific book at all, but a more general recommendation to get a book about a language very different from the Java/C# family. Learn one of the hot dynamically typed languages all the kdis love these days, like Ruby or Python. If those are old hat, pick up the The Haskell School of Expression if the online tutorial seems interesting. Or maybe Graham's On Lisp, which recently put online for free. Just learn a language that forces you think in a different way from Java. Even if your day job continues to be Java, knowing how you would solve a problem in Ruby or Lisp will only make you a better programmer.
Note what isn't on the list: any of the Java 5 reference books or any of the tens (hundreds?) of J2EE books. Its important to keep up with the language and the platform, but I think thats better done through programming with the JDK and examples as reference. The reference books can be helpful for getting up to speed for day to day work, but I don't think they are essential for furthering your knowledge or your craft. Long after your J2EE
1.4.x.niner
book is collecting dust on the shelf, Effective Java will still be a reference you consult regularly.
