Actúa con prudencia

Actúa con prudencia
Autor: Seb Rose

“En todo lo que emprendas, actúa con prudencia y considera las consecuencias”Anónimo

No importa qué tan cómoda se vea una agenda de trabajo al comienzo de una iteración, no podrás evitar sentirte bajo presión en algún momento. Si te encuentras en una situación en la que tienes que elegir entre “hacerlo bien” o “hacerlo rápido”, suele ser tentador “hacerlo rápido” y pensar que regresarás a corregirlo más adelante. Cuando te haces esta promesa a ti mismo, a tu equipo, al cliente, lo haces en serio. Pero a menudo la siguiente iteración trae nuevos problemas y te debes enfocar en ellos. Este tipo de trabajo aplazado se conoce como deuda técnica y no es un buen amigo. Martin Fowler, en su taxonomía de la deuda técnica, la llama específicamente deuda técnica deliberada, la cual no debería confundirse con la deuda técnica inadvertida.

La deuda técnica es como un préstamo: te trae beneficios en el corto plazo, pero deberás pagar intereses hasta terminar de saldarla. Tomar atajos a la hora de programar hace que sea más difícil agregar funcionalidad o refactorizar tu código; las soluciones rápidas son un caldo de cultivo para defectos y casos de prueba muy frágiles. Mientras más tiempo las abandones, peor se ponen. Para cuando te decidas a corregir el problema puede que haya toda una pila de malas decisiones de diseño acumulada encima del problema original, haciendo que el código sea mucho más difícil de refactorizar y corregir. De hecho, es sólo cuando las cosas están tan mal como para tener que arreglarlas, que realmente vuelves y corriges el problema. Pero para entonces suele ser tan difícil corregirlo que no te puedes permitir el tiempo ni correr el riesgo.

Hay ocasiones en las que debes incurrir en la deuda técnica para cumplir con una fecha límite o para implementar una pequeña parte de una función. Intenta esquivar esos casos; sólo hazlo si la situación lo exige. Pero (y éste es un gran pero) debes mantener un ojo sobre la deuda técnica y pagarla tan pronto como puedas o las cosas se irán rápidamente cuesta abajo. Apenas te hayas endeudado, escribe una tarjeta o registra el problema en tu sistema de seguimiento para asegurarte de no olvidarlo.

Si planeas pagar la deuda en la próxima iteración, el costo será mínimo. Pero si la abandonas, se incrementarán los intereses y esto también deberá registrarse para que el costo permanezca a la vista. Hacer esto resaltará el impacto que tiene la deuda técnica del proyecto sobre el valor de la empresa y permitirá una priorización de pago. Cómo calcular y realizar el seguimiento de los intereses dependerá de cada proyecto, pero deberás hacerlo.

Paga la deuda técnica tan pronto como puedas; sería imprudente no hacerlo.

Leer contribución original

Adueñate (y Refactoriza) la compilación

Adueñate (y Refactoriza) la compilación
Autor: Steve Berczuk

No es poco común para los equipos que, aunque son altamente disciplinados sobre las prácticas de codificación, descuiden los scripts de compilación, quizás por la creencia de que son meramente un detalle de poca importancia o por el miedo de que son complejos y necesitan ser atendidos por el culto de la ingeniería de la liberación. Los scripts que no son posibles de mantener, con duplicaciones y errores, causan problemas de la misma magnitud que aquellos con código pobremente factorizado.

Una de las razones por las que los desarrolladores hábiles y disciplinados tratan la compilación como algo secundario es que los scripts de compilación son frecuentemente escritos en un lenguaje diferente al código fuente. Otra es que la compilación no es realmente “código”. Estas justificaciones van en contra de la realidad de que la mayoría de los desarrolladores de software disfrutan aprendiendo nuevos lenguajes y que la compilación es lo que crea artefactos ejecutables para desarrolladores y usuarios finales para probar y ejecutar. El código es inútil si no ha sido compilado, y la compilación es lo que define el componente de arquitectura de la aplicación. La compilación es una parte esencial del desarrollo, y las decisiones sobre el proceso compilado pueden hacer más simples tanto el código como la codificación.

Los scripts para la compilación que son escritos usando modismos erróneos son difíciles de mantener y, más importante, de mejorar. Vale la pena tomarse tiempo para entender la forma correcta de realizar un cambio. Los errores pueden aparecen cuando una aplicación se compila con la versión incorrecta de una dependencia o cuando la configuración del tiempo de compilador está mal.

Tradicionalmente las pruebas han sido algo que siempre fue dejado al equipo de “Quality Assurance”. Ahora nos damos cuenta de que hacer pruebas mientras codificamos es necesario para permitirnos liberar el valor predeciblemente. Del mismo modo, el proceso de compilación tiene que ser propiedad del equipo de desarrollo.

Entender la compilación puede simplificar el ciclo de vida completo y reducir costos. Una compilación simple de ejecutar permite al nuevo desarrollador empezar rápida y fácilmente. La automatización de la configuración de compilación puede permitirte obtener resultados consistentes cuando muchas personas están trabajando en un proyecto, evitando el “a mí me funciona”. Muchas herramientas para compilación te permiten ejecutar reportes de calidad de código, lo que hace posible detectar problemas potenciales tempranamente. Al entender cómo hacer tuya la compilación, puedes ayudarte a ti mismo y a los integrantes de tu equipo. Enfócate en codificar características, en beneficio de las partes interesadas y para hacer tu trabajo más agradable.

Aprende lo suficiente de tu proceso de compilación para saber cuándo y cómo realizar los cambios. Los scripts de compilación son código. También son muy importantes para dejárselos a alguien más, la aplicación no está completa hasta que se compila. El trabajo de programación no está completo hasta que hayamos liberado software funcionando.

Leer contribución original

Antes de Refactorizar

Antes de Refactorizar
Autor: Rajith Attapattu

En algún punto todo programador necesitará refactorizar código existente. Pero antes de hacerlo por favor piensa en lo siguiente, ya que tú y otras personas podrían ahorrar una gran cantidad de tiempo (y dolor):

  • El mejor enfoque para la reestructuración comienza por hacer un balance del código base existente y las pruebas escritas contra ese código. Esto ayudará a entender las fortalezas y debilidades del código en su estado actual, por lo que puedes asegurar que retienes los puntos fuertes, mientras evitas los errores. Todos pensamos que podemos hacerlo mejor que el sistema actual… hasta que terminamos con algo que no es mejor –o incluso peor– que la anterior encarnación, debido a que fallamos en aprender de los errores existentes en el sistema.
  • Evita la tentación de volver a escribir todo. Es mejor reusar tanto código como sea posible. No importa que tan feo sea el código, ya ha sido probado, revisado, etcétera. Desechar el código viejo –especialmente si está en producción– significa que estás desechando meses (o años) de pruebas sobre el aguerrido código que podría haber tenido ciertos atajos y correcciones críticas de errores de los cuales no estás enterado. Si no tomas esto en cuenta, el nuevo código que se escriba podría terminar mostrando el mismo error misterioso que fue reparado en el código antiguo. Esto desperdiciará un montón de tiempo, esfuerzo y conocimiento adquiridos a través de los años.
  • Muchos cambios incrementales son mejores que un cambio masivo. Los cambios incrementales permiten medir el impacto en el sistema más fácilmente a través de la retroalimentación, como las pruebas. No es divertido ver cientos de pruebas fallidas después de realizar un cambio. Esto puede conducir a la frustración y presión que puede, a su vez, dar lugar a malas decisiones. Un par de pruebas fallidas es fácil de manejar y provee un enfoque más manejable.
  • Después de cada iteración es importante asegurar que las pruebas existentes pasan. Agrega nuevas pruebas si las pruebas existentes no son suficientes para cubrir los cambios realizados. No deseches las pruebas del código antiguo sin la debida consideración. En la superficie algunas de estas pruebas podrían no parecer aplicables a tu nuevo diseño, pero será de utilidad el esfuerzo de investigación a fondo de las razones por las cuales estas pruebas en particular fueron añadidas.
  • Las preferencias personales y el ego no deben ponerse en el camino. Si algo no está roto, ¿para qué arreglarlo? Que el estilo o la estructura del código no se ajuste a tus preferencias personales no es una razón válida para reestructurarlo. Pesar que podrías hacer un mejor trabajo que el programador previo no es una razón válida tampoco.
  • La nueva tecnología es razón insuficiente para refactorizar. Una de las peores razones para refactorizar se debe a que el código actual está muy por detrás de las buenas tecnologías que tenemos hoy en día, y creemos que un nuevo lenguaje o framework puede hacer las cosas mucho más elegantemente. A menos que un análisis de costo-beneficio muestre que el nuevo lenguaje o framework beneficiará la funcionalidad, mantenimiento o productividad, es mejor dejar las cosas como están.
  • Recuerda que los humanos cometen errores. Reestructurar no siempre garantiza que el nuevo código será mejor o tan bueno como el intento anterior. He visto y sido parte de muchos intentos de reestructuración fallidos. No fue bonito, pero fue humano.

Leer contribución original

Aplica los principios de la programación funcional

Aplica los principios de la programación funcional
Autor: Edward Garson

Recientemente, la comunidad programadora ha demostrado un renovado interés por la programación funcional. Parte del motivo es que las propiedades emergentes de este paradigma las hacen una buena opción para abordar la transición de la industria hacia el desarrollo sobre arquitecturas multi-core. Sin embargo, aunque es, sin duda, una aplicación importante, no es la razón por la que este texto te exhorta a que aprendas sobre programación funcional.

Dominar el paradigma funcional puede mejorar enormemente la calidad del código que escribes en otros contextos. Si lo comprendes y lo aplicas a tus diseños, lograrás un nivel mucho más alto de transparencia referencial.

La transparencia referencial es una cualidad deseable: implica que las funciones devuelvan siempre los mismos resultados cuando se les pase el mismo valor, independientemente de dónde y cuándo se las invoque. Es decir, la evaluación de una función no depende tanto de los efectos colaterales del estado mutable –idealmente, no depende en absoluto–.

Una de las principales causas de defectos cuando se programa en lenguajes imperativos no es otra que las variables mutables. Cualquier persona que se encuentre leyendo esto habrá tenido que investigar alguna vez por qué un valor no es el esperado en una situación particular. La semántica de visibilidad puede ayudar a mitigar estos errores insidiosos o, al menos, reducir drásticamente su ubicación; pero es probable que el verdadero culpable de su existencia sea un desarrollo que hace uso de mutabilidad excesiva.

Y la industria no nos ayuda mucho con este problema. La mayoría de la documentación introductoria sobre orientación a objetos tácitamente promueve este tipo de prácticas, porque a menudo utilizan como ejemplo una serie de objetos con un tiempo de vida relativamente largo, invocando métodos mutadores unos sobre otros, lo cual puede ser peligroso. Sin embargo, con un buen desarrollo guiado por pruebas, particularmente asegurándose de “simular roles, no objetos“, se puede evitar la mutabilidad excesiva.

El resultado neto será un diseño que generalmente posee una mejor distribución de responsabilidades con una mayor cantidad de funciones –más pequeñas– que trabajan sobre los argumentos que se les pasa, en lugar de hacer referencia a miembros mutables. Habrá menos defectos y también será menos complejo detectarlos, porque es más fácil localizar dónde se introdujo un valor no deseado que deducir el contexto específico que resulta en una asignación errónea. Un diseño de este tipo establecerá un nivel mucho más alto de transparencia referencial; y, de seguro, nada fijará mejor estas ideas en tu cabeza que estudiar un lenguaje de programación funcional, en el cual este modelo de computación es la norma.

Por supuesto, este enfoque no es la mejor opción para todas las situaciones. Por ejemplo, en sistemas orientados a objetos de este estilo suele lograr mejores resultados con el desarrollo del modelo de dominio (es decir, en el cual la interacción de las funciones sirve para descomponer la complejidad de las reglas de negocio) y no tanto con el desarrollo de la interfaz de usuario.

Domina el paradigma de la programación funcional y podrás –con criterio– aplicar en otros contextos las lecciones que aprendas. Tus sistemas orientados a objetos (para empezar) se llevarán mejor con las bondades de la transparencia referencial y, contrario a lo que muchos te dirán, estarán más cerca de su contraparte funcional. De hecho, algunos incluso afirman que, en el fondo, los paradigmas de programación funcional y orientada a objetos no son más que un mero reflejo el uno del otro, una especie de yin y yang computacional.

Leer contribución original

Aprende a decir “Hola, Mundo”

Aprende a decir “Hola, Mundo”
Autor: Thomas Guest

Paul Lee, nombre de usuario “leep”, comúnmente conocido como Hoppy, tenía la reputación de experto local en temas de programación. Necesitaba ayuda. Caminé hacia el escritorio de Hoppy y le pregunté:

— ¿Podrías echar un vistazo al código por mí?

— Seguro —dijo Hoppy—, toma una silla.

Tuve el cuidado de no derribar las latas vacías de soda apiladas en una pirámide detrás de él.

—¿Qué código?

—En una función en un archivo —le dije.

—Echemos un vistazo a esta función.

Hoppy alejó una copia de K&R y deslizó su teclado frente a mí. ¿Dónde está el IDE? Aparentemente Hoppy no tenía un IDE ejecutándose, sólo algún editor que yo no podía operar. Tomó de nuevo el teclado. Unos cuantos teclazos después y teníamos el archivo abierto –era un archivo algo grande– y estamos observando la función –era una función algo grande–. Él avanzó unas páginas hacia el bloque condicional que quería cuestionarle.

— ¿Qué haría realmente esta cláusula si x es negativo? —le pregunté—. ¿Sin duda, es un error.

Había estado probando toda la mañana tratando de encontrar una manera de forzar que x fuera negativo, pero la gran función en un gran archivo era parte de un gran proyecto, y el ciclo de recompilar y volver a ejecutar mis experimentos me estaba venciendo. ¿No podría un experto como Hoppy simplemente decirme la respuesta?

Hoppy admitió que estaba seguro. Para mi sorpresa, no buscó en K&R. En vez de ello, copió el bloque de código en un nuevo buffer del editor, lo reindentó y lo envolvió en una función. Un poco más tarde codificó una función main y lo cicló, pidiendo al usuario valores de entrada, pasándolos a la función e imprimiendo el resultado. Guardó el buffer como un nuevo archivo, tryit.c. Todo esto lo podría haber hecho yo mismo, creo que quizá no tan rápido. Sin embargo, su siguiente paso fue maravillosamente simple y, para ese tiempo, un poco extraño para mi manera de trabajar

$ cc tryit.c && ./a.out

¡Mira! Su programa, concebido unos pocos minutos antes, ahora estaba en marcha y funcionando. Probamos unos cuantos valores y confirmó mis sospechas (¡había tenido razón sobre algo!) y entonces cotejó la sección correspondiente de K&R. Le agradecí a Hoppy y me fui, una vez más, teniendo cuidado de no molestar su pirámide de latas de soda.

De regreso a mi escritorio, cerré mi IDE. Me había hecho tan familiar al trabajo con un gran proyecto con un gran producto que había empezado a pensar qué debía hacer. Una computadora de propósito general puede realizar pequeñas tareas también. Abrí un editor de texto y empecé a escribir.

#include <stdio.h>

int main() {
    printf("Hello, World\n");
    return 0;
}

Leer contribución original

Aprende a hacer estimaciones

Aprende a hacer estimaciones
Autor: Giovanni Asproni

Como programador debes ser capaz de proporcionar estimaciones a tus directivos, colegas y usuarios de las tareas que necesitas realizar, así ellos tendrán una idea razonablemente precisa del tiempo, costo, tecnología y otros recursos necesarios para lograr sus objetivos.

Para poder estimar bien es obvia la importancia aprender algunas técnicas de estimación. En primer lugar, sin embargo, es fundamental aprender qué son las estimaciones y para qué deberían ser usadas –por extraño que parezca, muchos desarrolladores y administradores no conocen esto–.

El siguiente diálogo entre un administrador de proyectos y un programador es nada atípico:

  • Administrador de Proyecto: ¿Puedes darme un estimado del tiempo necesario para desarrollar la característica xyz?
  • Programador: Un mes.
  • Administrador de Proyecto: ¡Eso es mucho tiempo! Sólo tenemos una semana.
  • Programador: Necesito al menos tres.
  • Administrador de Proyecto: Puedo darte dos cuando mucho.
  • Programador: ¡Es un trato!

Al programador, al final, se le ocurre un “estimado” que concuerda con lo que es aceptable para el administrador. Pero, ya que es una estimación del programador, el gerente lo hará responsable de ello. Para entender qué está mal en esta conversación necesitamos tres definiciones: estimado, fin y compromiso.

  • Un estimado es un cálculo aproximado o un juicio de valor, número, cantidad o extensión de algo. Esta definición implica que un estimado es una medición factual basada en datos concretos y experiencia previa; la esperanza y los deseos deben ser ignorados cuando se calcula. La definición también implica que, al ser aproximada, una estimación no pueden ser precisa, por ejemplo: una tarea de desarrollo no puede ser estimada para durar 234.14 días.
  • Un fin es una declaración de un objetivo deseable del negocio, por ejemplo, “el sistema debe soportar al menos 400 usuarios concurrentes”.
  • Un compromiso es una promesa de ofrecer una funcionalidad especificada a una determinado nivel de calidad en una cierta fecha o evento. Un ejemplo podría ser: “la funcionalidad de búsqueda estará disponible en la próxima versión del producto”.

Los estimados, fines y compromisos son independientes uno del otro, pero los blancos y cometidos deberían estar basados en estimados. Como Steve McConnell señala: “El propósito principal de la estimación de software no es predecir el futuro del proyecto, sino determinar si los fines son lo suficientemente realistas para que pueda ser controlado hasta lograrlo”. Por lo tanto, el propósito de una estimación es hacer una administración de proyecto adecuada y una planificación posible, permitiendo que los interesados hagan compromisos basados en fines realistas.

Lo que estaba pidiendo el administrador en la conversación anterior al programador era hacer un compromiso basado en un fin no declarado que el administrador tenía en mente, no dar un estimado. La próxima vez que te pidan proporcionar un estimado asegúrate que todos los involucrados sepan de lo que están hablando, y tus proyectos tendrán una mejor oportunidad de éxito. Ahora es el momento de aprender algunas técnicas…

Leer contribución original

Aprende un lenguaje extranjero

Aprende un lenguaje extranjero
Autor: Klaus Marquardt

Los programadores necesitamos comunicarnos. Mucho.

Hay periodos en la vida de un programador cuando mucha de su comunicación parece ser con la computadora. Más precisamente, con los programas ejecutándose en esa computadora. Esta comunicación es con respecto a expresar ideas en una forma leíble por la máquina. Sigue siendo un prospecto emocionante: los programas son ideas convertidas en realidad, con virtualmente ninguna sustancia física involucrada.

Los programadores deben tener fluidez en el lenguaje de la máquina, ya sea real o virtual, y en las abstracciones que pueden estar relacionadas con el lenguaje vía herramientas de desarrollo. Es importante aprender muchas abstracciones diferentes, de otro modo algunas ideas se vuelven increíblemente difíciles de expresar. Los buenos programadores necesitan ser capaces de pararse fuera de su rutina diaria, de estar al tanto de otros lenguajes que son expresivos para otros propósitos. La hora siempre llega cuando éste vale la pena.

Más allá de la comunicación con las máquinas, los programadores necesitan comunicarse con sus pares. Los grandes proyectos de hoy en día son más emprendimientos sociales que simplemente una aplicación en el arte de la programación. Es importante entender y expresar más de lo que pueden las abstracciones de máquina. La mayoría de los mejores programadores que conozco es muy fluida en su lengua madre y, por lo general, en otros idiomas también. Esto no es sólo sobre la comunicación con otros: hablar bien un lenguaje nos lleva a una claridad de pensamiento que es indispensable cuando se abstrae un problema. Y también de eso se trata la programación.

Más allá de la comunicación con las máquinas, con uno mismo y con los compañeros, un proyecto tiene muchos stakeholders, la mayoría con una formación diferente o no técnica. Ellos viven en las áreas de pruebas, calidad y despliegue, en mercadeo y ventas, son usuarios finales en alguna oficina (o tienda o casa). Necesitas entenderlos y a sus preocupaciones. Esto es casi imposible si no puedes hablar su lenguaje en su mundo, su dominio. Mientras puedes pensar que una conversación con ellos salió bien, ellos probablemente no.

Si puedes hablar con contadores, necesitas un conocimiento básico de contabilidad, de centros, de costos o capital invertido, capital empleado, et al. Si vas a hablar con mercadólogos o abogados, algo de su jerga y lenguaje (y, por lo tanto, su mente) debería serte familiar. Todos estos lenguajes específicos del dominio necesitan ser dominados por alguien en el proyecto; de preferencia los programadores, ya que son los responsables de llevar las ideas a la vida a través de una computadora.

Y, por supuesto, la vida es más que proyectos de software. Como lo nota Charlemagne, el conocer otro lenguaje es tener otra alma. Para tus contactos más allá de la industria del software serás más apreciado al conocer lenguajes extranjeros. Para saber cuándo escucharlos en vez de hablar. Para saber que la mayor parte del lenguaje es sin palabras.

“De lo que no se puede hablar, hay que callar”. Ludwig Wittgenstein.

Leer contribución original

Aprende a usar las herramientas de línea de comandos

Aprende a usar las herramientas de línea de comandos
Autor: Carroll Robinson

Hoy en día, muchas herramientas de desarrollo de software se empaquetan como Entornos Integrados de Desarrollo (IDE, Integrated Development Environments). Microsoft Visual Studio y el proyecto de software libre Eclipse son dos ejemplos populares, aunque hay muchos otros. Hay muchas razones por las cuales nos gustan los IDE. No sólo porque son fáciles de usar, sino que también alivian al programador de pensar en un montón de pequeños detalles que involucran el proceso de construcción.

La facilidad de uso, sin embargo, tiene su lado negativo. Por lo general, cuando una herramienta es fácil de usar, es debido a que está tomando decisiones por ti y haciendo un montón de cosas automáticamente detrás de la escena. Por lo tanto, si un IDE es el único entorno de programación que siempre has usado, quizás nunca entiendas completamente lo que tus herramientas están haciendo. Haces clic en un botón, algo de magia ocurre, y un archivo ejecutable aparece en la carpeta del proyecto.

Al trabajar con las herramientas de línea de comandos vas a aprender mucho más sobre lo que están haciendo cuando se está construyendo el proyecto. Escribir tus propios archivos make te ayudará al entendimiento de todos los pasos (compilar, ensamblar, enlazar, etcétera) que están en la construcción de un archivo ejecutable. Experimentar con las muchas opciones de la línea de comandos de esas herramientas también es una experiencia educacional valiosa. Para empezar con el uso de las herramientas de construcción en línea de comandos, puedes usar las de software libre, como GCC, o las proporcionadas por tu IDE propietario. Después de todo, un IDE bien diseñado es sólo una interface gráfica para un conjunto de herramientas de línea de comandos.

Además de mejorar tu entendimiento del proceso de construcción, hay algunas tareas que pueden ser realizadas de forma más fácil o eficiente con las herramientas de línea de comandos que con un IDE. Por ejemplo, las capacidades de buscar y reemplazar provistas por las utilerías grep y sed son más poderosas que aquellas que encuentras en IDEs. Las herramientas de línea de comandos inherentemente soportan secuencias de comandos (scripting), lo cuál permite la automatización de tareas, como calendarizarbuilds diarios, crear múltiples versiones de un proyecto y la ejecución de conjuntos de pruebas. En un IDE este tipo de automatización puede ser más difícil (si no imposible) de realizar debido a que las opciones de construcción son usualmente especificadas usando cajas de diálogo del GUI (Interface Gráfica de Usuario) y el proceso de construcción es invocado con el clic del ratón. Si nunca has dado un paso fuera de un IDE, quizá nunca te diste cuenta de que estos tipos de tareas automatizadas son posibles.

Pero, espera. ¿Acaso el IDE no existe para hacer el desarrollo más fácil y para mejorar la productividad del programador? Bueno, sí. La propuesta presentada aquí no es que debes dejar de usar un IDE. La propuesta es que deberías “mirar debajo de la cortina” y entender lo que el IDE está haciendo por ti. La mejor manera de hacerlo es aprender a usar las herramienta de línea de comandos. Luego, cuando vuelvas a usar tu IDE, tendrás un mucho mejor entendimiento de qué es lo que está haciendo por ti y cómo puedes controlar el proceso de construcción. Por otra parte, una vez que domines el uso de las herramientas de línea de comandos y experimentes el poder y flexibilidad que ofrecen, quizás podrías encontrar que prefieres la línea de comando sobre el IDE.

Leer contribución original

Aprendiendo continuamente

Aprendiendo continuamente
Autor: Clint Shank

Vivimos en tiempos interesantes. Conforme el desarrollo se distribuye en todo el mundo, se aprende que hay muchas personas capaces de hacer tu trabajo. Necesitas seguir aprendiendo para seguir siendo comercializable. De lo contrario, te convertirás en dinosaurio, atrapado en el mismo trabajo hasta que, un día, no serás necesario o tu trabajo será subcontratado con algún recurso más barato

Entonces, ¿qué hacer al respecto? Algunos empleadores son lo suficientemente generosos para proveer formación para ampliar tus habilidades. Otros pueden no ser capaces de ahorrar el tiempo o el dinero para entrenarte. Para jugar a la segura, necesitas tomar responsabilidad de tu propia educación.

Aquí hay una lista de las ideas para mantenerte en aprendizaje. Muchas de se pueden encontrar en Internet de forma gratuita:

  • Lee libros, revistas, blogs, feeds de twitter y sitios web. Si quieres profundizar en un tema, considera unirte a una lista de correo o grupos de noticias
  • Si realmente quieres estar inmerso en una tecnología, pon las manos en ello y escribe algún código.
  • Trata siempre de trabajar con un mentor, sentirse el mejor puede dificultar tu educación. Aunque puedes aprender algo de cualquiera, puedes aprender mucho más de alguien más inteligente o más experimentado que tú. Si no puedes encontrar un mentor, considera seguir adelante.
  • Utiliza mentores virtuales. Encuentra autores y desarrolladores en la web que realmente te gusten y lee todo lo que han escrito. Inscríbete en sus blogs.
  • Conoce sobre los frameworks y bibliotecas que usan. Saber cómo funciona algo te hace saber cómo usarlo mejor. Si son de software libre, estás de suerte. Usa el depurador para ir paso a paso por el código para ver qué hay tras el telón. Podrás ver el código escrito y revisado por personas realmente inteligentes.
  • Cada vez que cometas un error, arregles un error o estés en un problema trata de entender qué pasó. Es probable que alguien más haya tenido el mismo problema y haya escrito sobre él en algún lugar de la web. Google es útil en este caso.
  • Una buena manera de aprender algo es enseñando o hablando sobre eso. Como la gente está para escucharte y te hará preguntas, estarás motivado a aprender. Intenta un “almuerza y aprende” en el trabajo, un grupo de usuarios o con conferencias locales.
  • Inicia o únete a un grupo de estudio (a la comunidad de patrones) o a un grupo local de usuarios del lenguaje, tecnología o disciplina en la que estés interesado.
  • Asiste a conferencias. Y si no puedes ir, muchas conferencias ponen sus charlas en línea gratuitamente.
  • ¿Tienes un largo trayecto de la casa al trabajo? Escucha podcasts.
  • ¿Alguna vez has ejecutado las herramientas de análisis estático sobre tu código base o has mirado en las advertencias de tu IDE? Comprende qué están reportando y por qué.
  • Sigue la recomendación de The Pragmatic Programmer y aprende un nuevo lenguaje cada año. Al menos aprenderás una nueva tecnología o herramienta. El diversificar te dará ideas que puedes usar en tu pila tecnológica actual.
  • No todo lo que aprendas tiene que ser sobre tecnología. Aprende el dominio de lo que estás trabajando, así puedes comprender mejor los requerimientos y ayudar a resolver el problema del negocio. Aprender a ser más productivo – cómo trabajar mejor – es otra buena opción.
  • Vuelve a la escuela.

Sería bueno tener la capacidad que Neo tenía en The Matrix y simplemente descargar en tu cerebro la información que necesitas. Pero no podemos, por lo que requerirá un compromiso de tiempo. No tienes que gastar cada hora de vigilia aprendiendo. Un poco de tiempo, por ejemplo semanalmente, es mejor que nada. Existe (o debería haber) una vida fuera del trabajo.

La tecnología cambia rápidamente. No te quedes atrás.

Leer contribución original

Automatiza el estándar de codificación

Automatiza el estándar de codificación
Autor: Filip van Laenen

Probablemente a ti también te sucedió. Al comenzar un proyecto todo el mundo tiene buenas intenciones; las llamaremos “resoluciones de proyecto nuevo”. A menudo, muchas de estas resoluciones se documentan, y las que tienen que ver con el código terminan en el estándar de codificación del proyecto. Durante la primera reunión, el jefe de desarrollo revisa la documentación y, en el mejor de los casos, todos aceptan que intentarán respetarla. Sin embargo, una vez que el proyecto se pone en marcha, las buenas intenciones se van dejando de lado, una a una. Para cuando se entrega el proyecto, el código es un desastre y nadie parece saber por qué.

¿En qué momento salieron mal las cosas? Probablemente desde la reunión inicial. Algunos miembros no estaban prestando atención; otros no lo consideraron importante. Para peor, algunos no estuvieron de acuerdo y ya estaban planeando rebelarse en contra del estándar. Por último, algunos sí lo comprendieron y estuvieron de acuerdo pero, cuando la presión del proyecto fue demasiada, tuvieron que dejar de lado algunas convenciones. Aplicar un buen formato al código no te hará ganar puntos con un cliente que desea más funcionalidad. De hecho, respetar un estándar de codificación puede ser bastante aburrido si la función no está automatizada: intenta indentar una clase a mano para comprobarlo por tu cuenta.

Pero si es tan problemático, ¿para qué queremos un estándar de codificación? Una de las razones para darle un formato uniforme al código es que, de este modo, nadie se “adueñará” del código que escriba utilizando un formato propio. Probablemente queremos evitar que los programadores utilicen ciertos antipatrones, para así ahorrarnos algunos errores comunes. En general, un estándar de codificación debería hacer más fácil el trabajo grupal de un proyecto y mantener la velocidad de desarrollo desde el principio hasta el final. Se deduce entonces que todos deberían estar de acuerdo con el estándar; no ayuda que un programador utilice tres espacios para indentar y otro utilice cuatro.

Hay una gran cantidad de herramientas que se pueden usar para producir reportes de calidad de código, y para documentar y mantener el estándar de codificación, pero ésa no es la solución completa. El estándar debería automatizarse e imponerse siempre que sea posible. Por ejemplo, de las siguientes maneras:

  • Asegúrate de que parte del proceso de compilación sea darle formato al código, de modo que todo el mundo lo realice cada vez que se compile la aplicación.
  • Utiliza herramientas de análisis de código estático para encontrar antipatrones. Si se encuentra alguno, detén la compilación.
  • Aprende a configurar estas herramientas para que detecten antipatrones definidos por ti mismo y para tus proyectos específicos.
  • Mide la cobertura del código, pero también evalúa automáticamente los resultados. Nuevamente, detén la compilación si los resultados son muy bajos.

Intenta aplicar esto en todo lo que consideres de importancia, aunque no te será posible automatizarlo todo. Las cosas que no puedas marcar o corregir automáticamente podrían agruparse en un conjunto de directrices suplementarias al estándar automatizado, pero ten en cuenta que probablemente tú y tus colegas no lo respeten con la misma diligencia.

Por último, el estándar de codificación debería ser dinámico y no estático. A medida que el proyecto evolucione, sus necesidades también irán cambiando, y lo que quizás pareció inteligente en un principio, no será necesariamente inteligente algunos meses después.

Leer contribución original