The Pragmatic Programmer

From ChuWiki
Revision as of 16:17, 27 February 2009 by Chudiang (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Un resumen de las ideas principales del libro "The Pragamtic Programmer".

El gato se comió mi código

Debes hacerte responsable de las cosas. No pongas excusas, busca siempre soluciones. Si hay riesgo de que se fastidie el disco duro, no lo pongas como excusa, simplemente hazte responsable y haz copias de seguridad. Si algún problema te impide trabajar, busca una solución, no vale sólo con quejarse. Si pierdes tu código, decirle a tu jefe "el gato se comió mi código" no te servirá de excusa. Cuando haya problemas, no te quejes, propón soluciones.

No dejes ventanas abiertas

Si dejas tu casa abandonada con las ventanas cerradas, posiblemente la encuentres igual que la dejaste a la vuelta. Si dejas una ventana abierta, posiblemente entren los ladrones y la destrocen. De la misma forma, si tu código está bien hecho y es elegante, los otros programadores serán más reacios a meter "ñapas". Si tu código es un desastre lleno de parches, los demás programadores no tendrán ningún reparo en seguir añadiendo "ñapas". Cuando veas algún trozo de código que no esté bien hecho o no de impresión de ser elegante, arréglalo inmediatamente, no lo dejes. Si lo dejas, el código se irá deteriorando según vaya la gente trabajando en él y las "ñapas" se irán añadiendo una encima de otra.

En el caso contrario, el ejemplo de los bomberos que no rompieron la puerta de una casa para apagar un fuego porque la casa y la puerta estaba impecable. De la misma forma, si un código está muy claramente codificado, muy bien diseñado y es muy elegante, la gente será reacia a estropearlo incluso en caso de apuro y de prisas.

Sopa de piedras y ranas hervidas

Tres soldados hambrientos entran en una aldea y nadie quiere darles de comer. Ellos meten unas piedras en una olla con agua y la ponen a hervir. Los aldeanos se acercan con curiosidad y preguntan qué están haciendo. Ellos contestan que la típica sopa de piedras de su país y que está buenísima, pero que estaría mejor con unas patatas. Los aldenanos traen las patatas. La historia sigue con varios ingredientes hasta que se sacan las piedras y la sopa, con todos sus ingredientes está hecha.

De la misma forma, si tienes claro lo que hay que hacer, pero no puedes hacerlo solo, empieza a hacerlo y enséñaselo a la gente. Luego diles que estaría mejor si alguien ayudara haciendo un pequeño trozo de código. Si no empiezas a hacerlo y directamente pides a los demás que lo hagan como tu quieres, posiblemente no te hagan el mismo caso.

No pierdas de vista al usuario

No haces tu programa, lo haces para los usuarios que te lo compran. No pierdas de vista qué es lo que ellos quieren y necesitan. No sirve de nada hacer mucho código con una funcionalidad que luego nadie quiere usar y no darles la funcionalidad que realmente quieren.

Aprende a parar

Un programa nunca es perfecto. Trata de sacar versiones que funcionen bien, aunque no tengan toda la funcionalidad ni todos los detalles que quisieras que tuvieran. De nada sirve un programa perfecto que nunca se entrega porque nunca está listo.

Investiga constantemente

Cuantas más cosas sepas, mejor. No aprendas sólo el lenguaje de programación que tienes que usar. Hazte un plan de aprendizaje. Todos los años un lenguaje nuevo, todos los años leer dos libros, etc. Cuanto más alejados del estilo de programación que conoces, mejor. Si haces aplicaciones web, estudia sobre aplicaciones de escritorio. Si sabes un lenguaje orientado a objetos, estudia uno de script. Viendo cómo se resuelven las cosas en otras áreas de conocimiento, puedes adquierir buenas ideas para la tuya. Conociendo otras herramientas nuevas, quizás les encuentres una utilidad que no se te habría ocurrido de no haberlas estudiado.

Piensa críticamente

Mientras estés trabajando o codificando, no pongas el piloto automático. Piensa constantemente en lo que estás haciendo y piensa constantemente en si podrías hacerlo mejor, más rápido, de forma más eficiente. Incluso aunque estés aplicando buenos consejos de programación de los gurús, piensa en ellos, si realmente te están siendo útiles o te están molestando más que ayudando, piensa si puedes aplicarlos mejor, si puedes mejorarlos.

Comunícate

La torre de Babel se fué al traste no por falta de conocimientos técnicos, sino por falta de comunicación. Es muy importante comunicarse y es muy importante saber comunicarse. Piensa en lo que quieres decir, piensa cómo vas a decirlo, espera el momento adecuado y dilo. Es la forma adecuada de que los demás te escuchen y se enteren de lo que les estás diciendo. Si no dices claramente lo que quieres decir o lo dices cuando la otra persona está preocupada porque le duele una muela, posiblemente te estén oyendo, pero no escuchando.

No te repitas

Una de las cosas más importantes en la programación es no repetir conocimiento en dos o más sitios distintos. El ejemplo más claro y conocido es duplicar el mismo código en dos sitios. Si hay que corregir un error, hay que corregirlo en dos sitios distintos. Sin embargo, debe llevarse este principio hasta los extremos. No tiene sentido tener en un documento de Word los campos de la base de datos, en la base de datos los mismos campos, en el script que crea las tablas de base de datos los mismos campos y en el código del programa los mismos campos. Hay que buscar scripts que de alguna forma, a partir de una de esas fuentes, sean capaces de generar automáticamente los otros. De esta forma si, por ejemplo, añadimos un campo en una tabla de base de datos, sólo tendremos que ejecutar los scripts para que se genere automáticamente la parte del documento de word, los scripts sql que generar las tablas y el trozo de código de nuestro programa. Aunque parezca complejo, si vamos a realizar la operación varias veces, ganaremos tiempo y seguridad perdiendo el tiempo en hacer los scripts.

Reversibilidad

Cuando hagas el código con una idea en la cabeza, no lo hagas de forma que luego no puedas cambiar de idea. Hazlo siempre de forma que si cambias luego de idea, el cambio sea fácil de realizar también en el código.

Si decides usar una arquitectura cliente/servidor, no hagas el código de forma que si luego decides usar un único ejecutable no puedas hacerlo. Diseña y realiza el código de forma que puedas con poco esfuerzo cambiar de un tipo de arquitectura a otra.

Si decides usar una base de datos de marca A, haz el código de forma que luego puedas cambiarte fácilmente a una base de datos de marca B, y que luego puedas cambiarte fácilmente a usar ficheros normales en vez de una base de datos.

Balas trazadoras

Si no estás muy seguro de qué algoritmo elegir, de cómo hacer un módulo o de qué camino seguir en tu programa, tira balas trazadoras. Simplemente implementa alguna de las opciones, de forma que funcione lo suficiente como para probarla, pero sin todos los detalles que te llevarían mucho tiempo. Comprueba cómo se comporta y decide si merece la pena terminarla por completo o probar otra opción.

Prototipos

Los prototipos son distintos de las balas trazadoras. Un prototipo es un código que se hace para probar algo en concreto y luego tirarlo. Puede incluso implementarse en un lenguaje distinto del final, simplemente porque con ese lenguaje se codifica más rápido o es más adecuado para la prueba que queremos hacer. Podemos ver si un algoritmo matemático funciona bien con matlab. Cuando veamos que funciona, lo implementamos en java. Podemos hacer un prototipo de la interface de usuario, para mostrarla a nuestros clientes y ver si satisface sus necesidades. Para ello podemos hacerla en un lenguaje que nos facilite el dibujo de ventanas.

Usa lenguajes del dominio

Es muy útil inventarse pequeños lenguajes propios para el problema que estamos usando. Son lenguajes en los que escribimos las reglas de nuestro negocio, nuestros datos o lo que sea. El código simplemente leerá los ficheros de ese lenguaje y hará lo que tenga que hacer. Si alguna regla cambia, simplemente tocamos el fichero de ese lenguaje inventado y el código debería ser capaz de interpretarla correctamente.

Por ejemplo, si tenemos una lista de elementos de distintos tipos de forma que si tenemos elementos del tipo A seleccionados podemos borrarlos y copiarlos. Si tenemos del tipo B no podemos hacer nada con ellos y si seleccionamos del tipo C podemos sólo borrarlos, en vez de implementar estas reglas directamente en el código, podemos hacer un fichero asi

TIPO A PUEDE BORRAR,COPIAR
TIPO B PUEDE NULL
TIPO C PUEDE BORRAR

y nuestro código leerá este fichero cuando se seleccione un item de la lista para mostrar las opciones posibles. Si las opciones cambian, bastará con tocar este fichero y no el código.

CONTINUARÁ...