Acta con prudencia

Autor: Seb Rose

En todo lo que emprendas, acta con prudencia y considera las consecuencias Annimo
No importa qu tan cmoda se vea una agenda de trabajo al comienzo de una iteracin, no podrs evitar sentirte bajo
presin en algn momento. Si te encuentras en una situacin en la que tienes que elegir entre hacerlo bien o
hacerlo rpido, suele ser tentador hacerlo rpido y pensar que regresars a corregirlo ms adelante. Cuando te
haces esta promesa a ti mismo, a tu equipo, al cliente, lo haces en serio. Pero a menudo la siguiente iteracin trae
nuevos problemas y te debes enfocar en ellos. Este tipo de trabajo aplazado se conoce como deuda tcnica y no es
un buen amigo. Martin Fowler, en su taxonoma de la deuda tcnica, la llama especficamente deuda tcnica
deliberada, la cual no debera confundirse con la deuda tcnica inadvertida.
La deuda tcnica es como un prstamo: te trae beneficios en el corto plazo, pero debers pagar intereses hasta
terminar de saldarla. Tomar atajos a la hora de programar hace que sea ms difcil agregar funcionalidad o
refactorizar tu cdigo; las soluciones rpidas son un caldo de cultivo para defectos y casos de prueba muy frgiles.
Mientras ms tiempo las abandones, peor se ponen. Para cuando te decidas a corregir el problema puede que haya
toda una pila de malas decisiones de diseo acumulada encima del problema original, haciendo que el cdigo sea
mucho ms difcil de refactorizar y corregir. De hecho, es slo cuando las cosas estn tan mal como para tener que
arreglarlas, que realmente vuelves y corriges el problema. Pero para entonces suele ser tan difcil corregirlo que no te
puedes permitir el tiempo ni correr el riesgo.
Hay ocasiones en las que debes incurrir en la deuda tcnica para cumplir con una fecha lmite o para implementar
una pequea parte de una funcin. Intenta esquivar esos casos; slo hazlo si la situacin lo exige. Pero (y ste es un
gran pero) debes mantener un ojo sobre la deuda tcnica y pagarla tan pronto como puedas o las cosas se irn
rpidamente 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 prxima iteracin, el costo ser mnimo. Pero si la abandonas, se incrementarn los
intereses y esto tambin deber registrarse para que el costo permanezca a la vista. Hacer esto resaltar el impacto
que tiene la deuda tcnica del proyecto sobre el valor de la empresa y permitir una priorizacin de pago. Cmo
calcular y realizar el seguimiento de los intereses depender de cada proyecto, pero debers hacerlo.
Paga la deuda tcnica tan pronto como puedas; sera imprudente no hacerlo.

Adueate (y Refactoriza) la compilacin

Autor: Steve Berczuk

No es poco comn para los equipos que, aunque son altamente disciplinados sobre las prcticas de codificacin,
descuiden los scripts de compilacin, quizs 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 ingeniera de la liberacin. Los scripts
que no son posibles de mantener, con duplicaciones y errores, causan problemas de la misma magnitud que aquellos
con cdigo pobremente factorizado.
Una de las razones por las que los desarrolladores hbiles y disciplinados tratan la compilacin como algo secundario
es que los scripts de compilacin son frecuentemente escritos en un lenguaje diferente al cdigo fuente. Otra es que
la compilacin no es realmente cdigo. Estas justificaciones van en contra de la realidad de que la mayora de los
desarrolladores de software disfrutan aprendiendo nuevos lenguajes y que la compilacin es lo que crea artefactos
ejecutables para desarrolladores y usuarios finales para probar y ejecutar. El cdigo es intil si no ha sido compilado,
y la compilacin es lo que define el componente de arquitectura de la aplicacin. La compilacin es una parte
esencial del desarrollo, y las decisiones sobre el proceso compilado pueden hacer ms simples tanto el cdigo como
la codificacin.
Los scripts para la compilacin que son escritos usando modismos errneos son difciles de mantener y, ms
importante, de mejorar. Vale la pena tomarse tiempo para entender la forma correcta de realizar un cambio. Los
errores pueden aparecen cuando una aplicacin se compila con la versin incorrecta de una dependencia o cuando
la configuracin 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 compilacin tiene que ser propiedad del equipo de desarrollo.
Entender la compilacin puede simplificar el ciclo de vida completo y reducir costos. Una compilacin simple de
ejecutar permite al nuevo desarrollador empezar rpida y fcilmente. La automatizacin de la configuracin de
compilacin puede permitirte obtener resultados consistentes cuando muchas personas estn trabajando en un
proyecto, evitando el a m me funciona. Muchas herramientas para compilacin te permiten ejecutar reportes de
calidad de cdigo, lo que hace posible detectar problemas potenciales tempranamente. Al entender cmo hacer tuya
la compilacin, puedes ayudarte a ti mismo y a los integrantes de tu equipo. Enfcate en codificar caractersticas, en
beneficio de las partes interesadas y para hacer tu trabajo ms agradable.
Aprende lo suficiente de tu proceso de compilacin para saber cundo y cmo realizar los cambios. Los scripts de
compilacin son cdigo. Tambin son muy importantes para dejrselos a alguien ms, la aplicacin no est completa
hasta que se compila. El trabajo de programacin no est completo hasta que hayamos liberado software
funcionando.

Antes de Refactorizar

Autor: Rajith Attapattu

En algn punto todo programador necesitar refactorizar cdigo existente. Pero antes de hacerlo por favor piensa en
lo siguiente, ya que t y otras personas podran ahorrar una gran cantidad de tiempo (y dolor):

El mejor enfoque para la reestructuracin comienza por hacer un balance del cdigo base existente y las
pruebas escritas contra ese cdigo. Esto ayudar a entender las fortalezas y debilidades del cdigo 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 encarnacin, debido a que fallamos en aprender de los errores existentes en el
sistema.

Evita la tentacin de volver a escribir todo. Es mejor reusar tanto cdigo como sea posible. No importa que
tan feo sea el cdigo, ya ha sido probado, revisado, etctera. Desechar el cdigo viejo especialmente si est
en produccin significa que ests desechando meses (o aos) de pruebas sobre el aguerrido cdigo que
podra haber tenido ciertos atajos y correcciones crticas de errores de los cuales no ests enterado. Si no
tomas esto en cuenta, el nuevo cdigo que se escriba podra terminar mostrando el mismo error misterioso que
fue reparado en el cdigo antiguo. Esto desperdiciar un montn de tiempo, esfuerzo y conocimiento adquiridos
a travs de los aos.

Muchos cambios incrementales son mejores que un cambio masivo. Los cambios incrementales permiten
medir el impacto en el sistema ms fcilmente a travs de la retroalimentacin, como las pruebas. No es
divertido ver cientos de pruebas fallidas despus de realizar un cambio. Esto puede conducir a la frustracin y
presin que puede, a su vez, dar lugar a malas decisiones. Un par de pruebas fallidas es fcil de manejar y
provee un enfoque ms manejable.

Despus de cada iteracin 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
cdigo antiguo sin la debida consideracin. En la superficie algunas de estas pruebas podran no parecer
aplicables a tu nuevo diseo, pero ser de utilidad el esfuerzo de investigacin a fondo de las razones por las
cuales estas pruebas en particular fueron aadidas.

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 cdigo no se ajuste a tus preferencias personales no es una razn
vlida para reestructurarlo. Pesar que podras hacer un mejor trabajo que el programador previo no es una
razn vlida tampoco.

La nueva tecnologa es razn insuficiente para refactorizar. Una de las peores razones para refactorizar se
debe a que el cdigo actual est muy por detrs de las buenas tecnologas que tenemos hoy en da, y creemos
que un nuevo lenguaje o framework puede hacer las cosas mucho ms elegantemente. A menos que un anlisis
de costo-beneficio muestre que el nuevo lenguaje o framework beneficiar la funcionalidad, mantenimiento o
productividad, es mejor dejar las cosas como estn.

Recuerda que los humanos cometen errores. Reestructurar no siempre garantiza que el nuevo cdigo ser
mejor o tan bueno como el intento anterior. He visto y sido parte de muchos intentos de reestructuracin fallidos.
No fue bonito, pero fue humano.

Aplica los principios de la programacin funcional

Autor: Edward Garson

Recientemente, la comunidad programadora ha demostrado un renovado inters por la programacin funcional. Parte
del motivo es que las propiedades emergentes de este paradigma las hacen una buena opcin para abordar la
transicin de la industria hacia el desarrollo sobre arquitecturas multi-core. Sin embargo, aunque es, sin duda, una
aplicacin importante, no es la razn por la que este texto te exhorta a que aprendas sobre programacin funcional.
Dominar el paradigma funcional puede mejorar enormemente la calidad del cdigo que escribes en otros contextos.
Si lo comprendes y lo aplicas a tus diseos, logrars un nivel mucho ms 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 dnde y cundo se las invoque. Es decir, la
evaluacin de una funcin 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 situacin particular. La semntica de visibilidad puede ayudar a mitigar estos errores
insidiosos o, al menos, reducir drsticamente su ubicacin; 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 mayora de la documentacin introductoria sobre
orientacin a objetos tcitamente promueve este tipo de prcticas, porque a menudo utilizan como ejemplo una serie
de objetos con un tiempo de vida relativamente largo, invocando mtodos mutadores unos sobre otros, lo cual puede
ser peligroso. Sin embargo, con un buen desarrollo guiado por pruebas, particularmente asegurndose de simular
roles, no objetos, se puede evitar la mutabilidad excesiva.
El resultado neto ser un diseo que generalmente posee una mejor distribucin de responsabilidades con una
mayor cantidad de funciones ms pequeas que trabajan sobre los argumentos que se les pasa, en lugar de hacer
referencia a miembros mutables. Habr menos defectos y tambin ser menos complejo detectarlos, porque es ms
fcil localizar dnde se introdujo un valor no deseado que deducir el contexto especfico que resulta en una
asignacin errnea. Un diseo de este tipo establecer un nivel mucho ms alto de transparencia referencial; y, de
seguro, nada fijar mejor estas ideas en tu cabeza que estudiar un lenguaje de programacin funcional, en el cual
este modelo de computacin es la norma.

Por supuesto, este enfoque no es la mejor opcin 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
interaccin 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 programacin funcional y podrs con criterio aplicar en otros contextos las lecciones
que aprendas. Tus sistemas orientados a objetos (para empezar) se llevarn mejor con las bondades de la
transparencia referencial y, contrario a lo que muchos te dirn, estarn ms cerca de su contraparte funcional. De
hecho, algunos incluso afirman que, en el fondo, los paradigmas de programacin funcional y orientada a objetos no
son ms que un mero reflejo el uno del otro, una especie de yin y yang computacional.

Aprende a decir "Hola, Mundo"

Autor: Thomas Guest

Paul Lee, nombre de usuario leep, comnmente conocido como Hoppy, tena la reputacin de experto local en
temas de programacin. Necesitaba ayuda. Camin hacia el escritorio de Hoppy y le pregunt:
Podras echar un vistazo al cdigo por m?
Seguro dijo Hoppy, toma una silla.
Tuve el cuidado de no derribar las latas vacas de soda apiladas en una pirmide detrs de l.
Qu cdigo?
En una funcin en un archivo le dije.
Echemos un vistazo a esta funcin.
Hoppy alej una copia de K&R y desliz su teclado frente a m. Dnde est el IDE? Aparentemente Hoppy no tena
un IDE ejecutndose, slo algn editor que yo no poda operar. Tom de nuevo el teclado. Unos cuantos teclazos
despus y tenamos el archivo abierto era un archivo algo grande y estamos observando la funcin era una
funcin algo grande. l avanz unas pginas hacia el bloque condicional que quera cuestionarle.
Qu hara realmente esta clusula si x es negativo? le pregunt. Sin duda, es un error.
Haba estado probando toda la maana tratando de encontrar una manera de forzar que x fuera negativo, pero la
gran funcin 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 podra 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 cdigo en
un nuevo buffer del editor, lo reindent y lo envolvi en una funcin. Un poco ms tarde codific una funcin main y lo
cicl, pidiendo al usuario valores de entrada, pasndolos a la funcin e imprimiendo el resultado. Guard el buffer
como un nuevo archivo, tryit.c. Todo esto lo podra haber hecho yo mismo, creo que quiz no tan rpido. Sin

embargo, su siguiente paso fue maravillosamente simple y, para ese tiempo, un poco extrao 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 (haba tenido razn sobre algo!) y entonces cotej la seccin
correspondiente de K&R. Le agradec a Hoppy y me fui, una vez ms, teniendo cuidado de no molestar su pirmide
de latas de soda.
De regreso a mi escritorio, cerr mi IDE. Me haba hecho tan familiar al trabajo con un gran proyecto con un gran
producto que haba empezado a pensar qu deba hacer. Una computadora de propsito general puede realizar
pequeas tareas tambin. Abr un editor de texto y empec a escribir.
#include <stdio.h>

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

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 tendrn una idea razonablemente precisa del tiempo, costo, tecnologa y otros
recursos necesarios para lograr sus objetivos.
Para poder estimar bien es obvia la importancia aprender algunas tcnicas de estimacin. En primer lugar, sin
embargo, es fundamental aprender qu son las estimaciones y para qu deberan ser usadas por extrao que
parezca, muchos desarrolladores y administradores no conocen esto.
El siguiente dilogo entre un administrador de proyectos y un programador es nada atpico:

Administrador de Proyecto: Puedes darme un estimado del tiempo necesario para desarrollar la
caracterstica xyz?

Programador: Un mes.

Administrador de Proyecto: Eso es mucho tiempo! Slo 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 estimacin del programador, el gerente lo har responsable de ello. Para entender qu est mal
en esta conversacin necesitamos tres definiciones: estimado, fin y compromiso.

Un estimado es un clculo aproximado o un juicio de valor, nmero, cantidad o extensin de algo. Esta
definicin implica que un estimado es una medicin factual basada en datos concretos y experiencia previa; la
esperanza y los deseos deben ser ignorados cuando se calcula. La definicin tambin implica que, al ser
aproximada, una estimacin no pueden ser precisa, por ejemplo: una tarea de desarrollo no puede ser estimada
para durar 234.14 das.

Un fin es una declaracin 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 podra ser: la funcionalidad de bsqueda estar disponible en
la prxima versin del producto.

Los estimados, fines y compromisos son independientes uno del otro, pero los blancos y cometidos deberan estar
basados en estimados. Como Steve McConnell seala: El propsito principal de la estimacin 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 propsito de una estimacin es hacer una administracin de proyecto
adecuada y una planificacin posible, permitiendo que los interesados hagan compromisos basados en fines
realistas.
Lo que estaba pidiendo el administrador en la conversacin anterior al programador era hacer un compromiso basado
en un fin no declarado que el administrador tena en mente, no dar un estimado. La prxima vez que te pidan
proporcionar un estimado asegrate que todos los involucrados sepan de lo que estn hablando, y tus proyectos
tendrn una mejor oportunidad de xito. Ahora es el momento de aprender algunas tcnicas

Aprende un lenguaje extranjero

Autor: Klaus Marquardt

Los programadores necesitamos comunicarnos. Mucho.

Hay periodos en la vida de un programador cuando mucha de su comunicacin parece ser con la computadora. Ms
precisamente, con los programas ejecutndose en esa computadora. Esta comunicacin es con respecto a expresar
ideas en una forma leble por la mquina. Sigue siendo un prospecto emocionante: los programas son ideas
convertidas en realidad, con virtualmente ninguna sustancia fsica involucrada.
Los programadores deben tener fluidez en el lenguaje de la mquina, ya sea real o virtual, y en las abstracciones que
pueden estar relacionadas con el lenguaje va herramientas de desarrollo. Es importante aprender muchas
abstracciones diferentes, de otro modo algunas ideas se vuelven increblemente difciles 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 propsitos. La hora siempre llega cuando ste vale la pena.
Ms all de la comunicacin con las mquinas, los programadores necesitan comunicarse con sus pares. Los
grandes proyectos de hoy en da son ms emprendimientos sociales que simplemente una aplicacin en el arte de la
programacin. Es importante entender y expresar ms de lo que pueden las abstracciones de mquina. La mayora
de los mejores programadores que conozco es muy fluida en su lengua madre y, por lo general, en otros idiomas
tambin. Esto no es slo sobre la comunicacin con otros: hablar bien un lenguaje nos lleva a una claridad de
pensamiento que es indispensable cuando se abstrae un problema. Y tambin de eso se trata la programacin.
Ms all de la comunicacin con las mquinas, con uno mismo y con los compaeros, un proyecto tiene muchos
stakeholders, la mayora con una formacin diferente o no tcnica. 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 conversacin con ellos sali bien, ellos probablemente no.
Si puedes hablar con contadores, necesitas un conocimiento bsico de contabilidad, de centros, de costos o capital
invertido, capital empleado, et al. Si vas a hablar con mercadlogos o abogados, algo de su jerga y lenguaje (y, por lo
tanto, su mente) debera serte familiar. Todos estos lenguajes especficos 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
travs de una computadora.
Y, por supuesto, la vida es ms que proyectos de software. Como lo nota Charlemagne, el conocer otro lenguaje es
tener otra alma. Para tus contactos ms all de la industria del software sers ms apreciado al conocer lenguajes
extranjeros. Para saber cundo 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.

Aprende a usar las herramientas de lnea de comandos

Autor: Carroll Robinson

Hoy en da, 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 slo
porque son fciles de usar, sino que tambin alivian al programador de pensar en un montn de pequeos detalles
que involucran el proceso de construccin.
La facilidad de uso, sin embargo, tiene su lado negativo. Por lo general, cuando una herramienta es fcil de usar, es
debido a que est tomando decisiones por ti y haciendo un montn de cosas automticamente detrs de la escena.
Por lo tanto, si un IDE es el nico entorno de programacin que siempre has usado, quizs nunca entiendas
completamente lo que tus herramientas estn haciendo. Haces clic en un botn, algo de magia ocurre, y un archivo
ejecutable aparece en la carpeta del proyecto.
Al trabajar con las herramientas de lnea de comandos vas a aprender mucho ms sobre lo que estn haciendo
cuando se est construyendo el proyecto. Escribir tus propios archivos make te ayudar al entendimiento de todos
los pasos (compilar, ensamblar, enlazar, etctera) que estn en la construccin de un archivo ejecutable.
Experimentar con las muchas opciones de la lnea de comandos de esas herramientas tambin es una experiencia
educacional valiosa. Para empezar con el uso de las herramientas de construccin en lnea de comandos, puedes
usar las de software libre, como GCC, o las proporcionadas por tu IDE propietario. Despus de todo, un IDE bien
diseado es slo una interface grfica para un conjunto de herramientas de lnea de comandos.
Adems de mejorar tu entendimiento del proceso de construccin, hay algunas tareas que pueden ser realizadas de
forma ms fcil o eficiente con las herramientas de lnea de comandos que con un IDE. Por ejemplo, las capacidades
de buscar y reemplazar provistas por las utileras grep y sed son ms poderosas que aquellas que encuentras en
IDEs. Las herramientas de lnea de comandos inherentemente soportan secuencias de comandos (scripting), lo cul
permite la automatizacin de tareas, como calendarizar buildsdiarios, crear mltiples versiones de un proyecto y la
ejecucin de conjuntos de pruebas. En un IDE este tipo de automatizacin puede ser ms difcil (si no imposible) de
realizar debido a que las opciones de construccin son usualmente especificadas usando cajas de dilogo del GUI
(Interface Grfica de Usuario) y el proceso de construccin es invocado con el clic del ratn. 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 ms fcil 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
deberas 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 lnea de comandos. Luego, cuando vuelvas a usar tu IDE, tendrs un mucho
mejor entendimiento de qu es lo que est haciendo por ti y cmo puedes controlar el proceso de construccin. Por
otra parte, una vez que domines el uso de las herramientas de lnea de comandos y experimentes el poder y
flexibilidad que ofrecen, quizs podras encontrar que prefieres la lnea de comando sobre el IDE.

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 convertirs en dinosaurio, atrapado en el mismo trabajo hasta que, un da, no sers necesario o tu
trabajo ser subcontratado con algn recurso ms barato
Entonces, qu hacer al respecto? Algunos empleadores son lo suficientemente generosos para proveer formacin
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 educacin.
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 tecnologa, pon las manos en ello y escribe algn cdigo.

Trata siempre de trabajar con un mentor, sentirse el mejor puede dificultar tu educacin. Aunque puedes
aprender algo de cualquiera, puedes aprender mucho ms de alguien ms inteligente o ms 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. Inscrbete en sus blogs.

Conoce sobre los frameworks y bibliotecas que usan. Saber cmo funciona algo te hace saber cmo usarlo
mejor. Si son de software libre, ests de suerte. Usa el depurador para ir paso a paso por el cdigo para ver qu
hay tras el teln. Podrs ver el cdigo escrito y revisado por personas realmente inteligentes.

Cada vez que cometas un error, arregles un error o ests en un problema trata de entender qu pas. Es
probable que alguien ms haya tenido el mismo problema y haya escrito sobre l en algn lugar de la web.
Google es til en este caso.

Una buena manera de aprender algo es enseando o hablando sobre eso. Como la gente est para
escucharte y te har preguntas, estars 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, tecnologa o disciplina en la que ests interesado.

Asiste a conferencias. Y si no puedes ir, muchas conferencias ponen sus charlas en lnea gratuitamente.

Tienes un largo trayecto de la casa al trabajo? Escucha podcasts.

Alguna vez has ejecutado las herramientas de anlisis esttico sobre tu cdigo base o has mirado en las
advertencias de tu IDE? Comprende qu estn reportando y por qu.

Sigue la recomendacin de The Pragmatic Programmer y aprende un nuevo lenguaje cada ao. Al menos
aprenders una nueva tecnologa o herramienta. El diversificar te dar ideas que puedes usar en tu pila
tecnolgica actual.

No todo lo que aprendas tiene que ser sobre tecnologa. Aprende el dominio de lo que ests trabajando, as
puedes comprender mejor los requerimientos y ayudar a resolver el problema del negocio. Aprender a ser ms
productivo cmo trabajar mejor es otra buena opcin.

Vuelve a la escuela.

Sera bueno tener la capacidad que Neo tena en The Matrix y simplemente descargar en tu cerebro la informacin
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 debera haber) una
vida fuera del trabajo.
La tecnologa cambia rpidamente. No te quedes atrs.

Automatiza el estndar de codificacin

Autor: Filip van Laenen

Probablemente a ti tambin 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 cdigo terminan en el estndar de codificacin del proyecto. Durante la primera reunin, el jefe
de desarrollo revisa la documentacin y, en el mejor de los casos, todos aceptan que intentarn 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 cdigo es un desastre y nadie parece saber por qu.
En qu momento salieron mal las cosas? Probablemente desde la reunin inicial. Algunos miembros no estaban
prestando atencin; otros no lo consideraron importante. Para peor, algunos no estuvieron de acuerdo y ya estaban
planeando rebelarse en contra del estndar. Por ltimo, algunos s lo comprendieron y estuvieron de acuerdo pero,
cuando la presin del proyecto fue demasiada, tuvieron que dejar de lado algunas convenciones. Aplicar un buen
formato al cdigo no te har ganar puntos con un cliente que desea ms funcionalidad. De hecho, respetar un
estndar de codificacin puede ser bastante aburrido si la funcin no est automatizada: intenta indentar una clase a
mano para comprobarlo por tu cuenta.
Pero si es tan problemtico, para qu queremos un estndar de codificacin? Una de las razones para darle un
formato uniforme al cdigo es que, de este modo, nadie se aduear del cdigo que escriba utilizando un formato
propio. Probablemente queremos evitar que los programadores utilicen ciertos antipatrones, para as ahorrarnos
algunos errores comunes. En general, un estndar de codificacin debera hacer ms fcil el trabajo grupal de un

proyecto y mantener la velocidad de desarrollo desde el principio hasta el final. Se deduce entonces que todos
deberan estar de acuerdo con el estndar; 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 cdigo, y para
documentar y mantener el estndar de codificacin, pero sa no es la solucin completa. El estndar debera
automatizarse e imponerse siempre que sea posible. Por ejemplo, de las siguientes maneras:

Asegrate de que parte del proceso de compilacin sea darle formato al cdigo, de modo que todo el mundo
lo realice cada vez que se compile la aplicacin.

Utiliza herramientas de anlisis de cdigo esttico para encontrar antipatrones. Si se encuentra alguno, detn
la compilacin.

Aprende a configurar estas herramientas para que detecten antipatrones definidos por ti mismo y para tus
proyectos especficos.

Mide la cobertura del cdigo, pero tambin evala automticamente los resultados. Nuevamente, detn la
compilacin 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 automticamente podran agruparse en un conjunto de directrices
suplementarias al estndar automatizado, pero ten en cuenta que probablemente t y tus colegas no lo respeten con
la misma diligencia.
Por ltimo, el estndar de codificacin debera ser dinmico y no esttico. A medida que el proyecto evolucione, sus
necesidades tambin irn cambiando, y lo que quizs pareci inteligente en un principio, no ser necesariamente
inteligente algunos meses despus.

Averigua qu hara el usuario (t no eres el usuario)

Autor: Giles Colborne

Todos tendemos a asumir que los dems piensan como nosotros, pero no es as. Los psiclogos lo llaman efecto del
falso consenso. Cuando la gente piensa o acta de un modo diferente a nosotros es muy probable que
(subconscientemente) los consideremos defectuosos en cierto modo.
Este prejuicio explica por qu a los programadores les cuesta tanto ponerse en el lugar de los usuarios. Los usuarios
no piensan como programadores. Para empezar, pasan mucho menos tiempo usando computadoras y no saben, ni
les interesa, cmo funcionan. Esto significa que no pueden recurrir a ninguna de las pilas de tcnicas para resolver
problemas que son tan comunes entre programadores. Los usuarios no saben reconocer los patrones ni indicaciones
que los programadores manejan para trabajar y lidiar con las interfaces.

La mejor manera de entender cmo piensan los usuarios es observndolos. Pdele a un usuario que realice una tarea
utilizando una aplicacin similar a la que ests desarrollando. Asegrate de que sea una tarea en serio: agrega una
columna de nmeros est bien; calcula tus gastos del mes pasado es mejor. Evita tareas muy especficas, como
puedes seleccionar estas celdas y agregar una frmula SUMA debajo?; es una pregunta algo obvia. Haz que el
usuario te explique en detalle el proceso que realiza. No lo interrumpas. No intentes ayudarlo. Pregntate todo el
tiempo por qu est haciendo eso.
Lo primero que notars es que los usuarios realizan una serie de cosas de manera similar. Intentan completar las
tareas en el mismo orden y cometen los mismos errores en los mismos lugares. Deberas disear tu aplicacin en
torno a esta conducta base. Esto es algo que difiere de las reuniones de diseo, en las cuales se suelen hacer
preguntas como: y si el usuario quisiera?. Estos planteamientos conducen al desarrollo de funciones demasiado
complejas y generan confusin sobre lo que los usuarios realmente desean. Observarlos eliminar esta confusin.
Vers que los usuarios suelen atascarse. Cuando t te atascas, buscas una solucin. Cuando los usuarios se
atascan, reducen su foco de atencin; se les vuelve ms complicado ver una solucin al problema en otro lugar de la
pantalla. sta es una de las razones por las que los textos de ayuda son una mala solucin al mal diseo de
interfaces de usuario. Si debes agregar instrucciones o textos de ayuda, asegrate de hacerlo justo al lado de las
reas problemticas. Esta limitacin de los usuarios es el motivo por el que los tooltips son ms tiles que los mens
de ayuda.
Los usuarios tienden a salir del paso de alguna manera. Encontrarn algo que funcione y se aferrarn a ello sin
importar lo complejo que sea, pero es mejor proveer un modo obvio de hacer las cosas que dos o tres atajos.
Tambin te encontrars con que hay una marcada diferencia entre lo que los usuarios dicen que quieren y lo que
realmente quieren. Lo cual es preocupante, ya que para averiguar los requerimientos lo normal es preguntarles. Es
por esto que el mejor modo de relevar los requerimientos es observando a los usuarios. Pasar una hora con ellos es
mucho ms informativo que pasar un da suponiendo qu quieren.

La belleza est en la simplicidad

Autor: Jrn lmheim

Hay una gran cita de Platn que es particularmente importante que los programadores sepamos y recordemos
siempre: La belleza en el estilo, la armona, la gracia y el buen ritmo dependen de la simplicidad. Creo que esta cita
resume en una sola oracin todos los valores a los que deberamos aspirar los desarrolladores de software.
En nuestro cdigo, nos esforzamos por lograr una serie de cosas:

Legibilidad

Mantenibilidad

Velocidad de desarrollo

La esquiva cualidad de la belleza

Platn nos est diciendo que el factor que nos permitir alcanzar todas estas cualidades es la simplicidad.
Pero qu hace bello al cdigo? sta puede ser una pregunta muy subjetiva. La percepcin de la belleza depende
mucho de nuestro trasfondo individual, tal como sucede con cualquier otra cosa. La gente formada en las artes tiene
una percepcin (o enfoque) sobre la belleza que es distinta a la de la gente formada en las ciencias. En el mbito del
arte se tiende a analizar la belleza del software comparndola con obras de arte, mientras que en el de las ciencias
se habla de la simetra y la proporcin urea; se intenta reducir las cosas a frmulas. En mi experiencia, la
simplicidad es la base de los argumentos en ambos lados de la moneda.
Piensa en el cdigo que has estudiado. Si no has pasado un buen tiempo leyendo el cdigo de alguien ms, deja de
leer esto ahora mismo y ve a buscar algo de software libre para estudiar. En serio, no es broma! Busca en Internet
algo de cdigo en tu lenguaje preferido, escrito por algn experto reconocido.
Ya has regresado? Bien. Dnde estbamos? Ah, s Me he encontrado con que el cdigo que me llama la
atencin y que considero hermoso siempre posee una misma serie de caractersticas. La ms importante es la
simplicidad. Me encuentro con que, sin importar qu tan complicada sea la aplicacin o sistema en su totalidad, las
partes individuales deben mantenerse simples: los objetos deben ser sencillos, poseer una nica responsabilidad y
contener mtodos similarmente simples, con una tarea bien definida y nombres descriptivos. Algunos piensan que la
idea de escribir mtodos breves, de entre cinco y diez lneas de cdigo cada uno, es bastante extrema, y algunos
lenguajes hacen que sea muy difcil lograr esto, pero yo creo que esta brevedad es un objetivo deseable.
En resumen, para que el cdigo sea bello debe ser simple. Cada pieza individual debe ser sencilla, y poseer
responsabilidades y relaciones simples con otras partes del sistema. De este modo se logra que nuestros proyectos
puedan mantenerse en el tiempo, con cdigo limpio, sencillo y verificable, lo cual permite mantener una alta velocidad
de desarrollo durante el tiempo de vida del proyecto.
La belleza nace y se encuentra en la simplicidad.

El camino al mejor rendimiento est lleno de sucias bombas de cdigo

Autor: Kirk Pepperdine

Ms frecuentemente que nunca, la optimizacin de rendimiento en un sistema requiere que alteres cdigo. Cuando
tenemos que alterar cdigo, cada porcin intrincadamente compleja o altamente acoplada es una sucia bomba de
cdigo, en espera de descarrilar el esfuerzo. La primera vctima de cdigo sucio ser tu agenda. Si el camino a seguir
es suave, ser fcil predecir cuando acabar. Los encuentros inesperados con el cdigo sucio harn que sea muy
difcil hacer una prediccin cuerda.

Considera la situacin en la que encuentras un punto de ejecucin complicado. El curso normal de accin es reducir
la fortaleza del algoritmo en cuestin. Digamos que respondes con 3-4 horas a un estimado que te pide el gerente.
Si aplicas el fix te dars cuenta rpidamente que has descompuesto una parte dependiente. Debido a que las cosas
estn relacionadas, a menudo estn necesariamente acopladas, estas descomposturas son esperadas y se cuenta
con ellas. Pero, qu pasa si un arreglo en esa dependencia termina rompindose en otra parte dependiente? Por
otro lado, entre ms lejos est la dependencia de su origen, menos probable es reconocerla como tal y tomarla en
cuenta en tu estimado. De repente tu estimado de 3-4 horas pueden elevarse fcilmente a 3-4 semanas. Con
frecuencia esta inflacin inesperada en la agenda sucede 1 o 2 das, todas al mismo tiempo. No es raro el ver
refactorizaciones rpidas que eventualmente toman varios meses en ser completadas. En esos casos, el dao en la
credibilidad y capital poltico del equipo responsable variar de severo a terminal. Si tan slo tuviramos una
herramienta para ayudarnos a identificar y medir estos riesgos.
De hecho, tenemos varias maneras de medir y controlar el grado y profundidad de acoplamiento y complejidad de
nuestro cdigo. Las mtricas de software puede ser usadas para contar las apariciones de caracterstica especficas
en nuestro cdigo. Los valores de estos conteos se correlacionan con la calidad del cdigo. Dos de estas mtricas
que miden el acoplamiento son las llamadas fan-in y fan- out. El fan-out est definido como el nmero de clases
referenciadas, ya sea directa o indirectamente, para una clase en particular. Puedes pensar en esto como un
recuento de todas las clases que deben ser compiladas antes de que tu clase pueda ser compilada. El fan-in un
conteo de todas las clases que depende de una clase en especfico. Conociendo el fan-out y fan-in podemos calcular
un factor de inestabilidad usando I = fo / (fi + fo). Conforme se aproxima a 0, el paquete se vuelve ms estable. En
cuanto se aproxime a 1, el paquete se convierte en inestable. Los paquetes que son estables son objetivos de bajo
riesgo, mientras que los paquetes inestables son ms propensos a estar llenos de sucias bombas de cdigos. La
meta de la refactorizacin es mover I lo ms cercano a 0.
Cuando usamos mtricas debemos recordar que slo son reglas empricas. Basndose puramente en las
matemticas puedes ver que el incremento de fi sin cambiar fo mover Imas cerca a 0. Sin embargo hay una
desventaja en tener el valor fan-in alto, pues estas clases sern ms difciles de modificar sin romper dependencias.
Al no tener en cuenta elfan-out no ests reduciendo realmente el riesgo, por lo que debe aplicarse algn balance.
Una desventaja de las mtricas de software es que la gran cantidad que nmeros que producen las herramientas
pueden ser intimidantes para los no iniciados. Dicho esto, las mtricas de software pueden ser una poderosa
herramienta en nuestra lucha por un cdigo limpio. Pueden ayudar a identificar y eliminar las sucias bombas de
cdigo antes de que sean un serio riesgo al ejercicio de optimizacin del rendimiento.

Codificando con la razn

Autor: Yechiel Kimchi

Trata de averiguar manualmente la correctitud de software resulta en una prueba formal ms larga y propensa a
errores que el cdigo mismo. Las herramientas automatizadas son preferibles, pero no siempre posibles. Lo siguiente
describe una ruta intermedia: razonamiento semi-formal sobre la dicha correctitud.

El planteamiento de fondo es dividir todo el cdigo en cuestin de secciones cortas desde una sola lnea, como
invocar a una funcin, hasta bloques de menos de 10 lneas y discutir acerca de su exactitud. Los argumentos slo
necesitan ser suficientemente fuertes para convencer al compaero del diablo como tu pareja de programacin.
Una seccin debera ser elegida de modo que en cada terminal el estado del programa (lase: el conteo del
programa y los valores de todos los objetos vivos) satisface una propiedad fcilmente descrita y que la funcionalidad
de esa seccin (transformacin de estado) sea fcil de describir como una sola tarea estos harn el razonamiento
ms sencillo. Tales propiedades terminales generalizan conceptos como precondincin y poscondicin de funciones,
e invariantes para ciclos y clases (con respecto a sus instancias). La lucha para que las secciones sean
independientes de las otras tanto como sea posible simplifica el razonamiento y es indispensable cuando estas
secciones son modificadas.
Muchas de las prcticas de codificacin que son bien conocidas (aunque quizs menos seguidas) y consideradas
buenas hacen el razonamiento ms fcil. Por lo tanto, slo con la intencin de razonar sobre tu cdigo ya ests
comenzando a pensar acerca de un mejor estilo y estructura. Como era de esperarse, la mayora de estas prcticas
pueden ser revisadas por analizadores de cdigo esttico:
1.

Evita usar sentencias goto, ya que hacen las secciones remotas altamente interdependientes

2.

Evita usar variables globales modificables, debido a que hacen dependientes a todas las secciones que las
usan.

3.

Cada variable debera tener el mnimo alcance posible. Por ejemplo, un objeto local puede ser declarado
justo antes de su primer uso.

4.

Haz los objetos inmutables cuando sea relevante.

5.

Haz al cdigo leble usando espacios, tanto horizontales como verticales. Por ejemplo, alineando estructuras
relacionadas y usando una lnea vaca para separar dos secciones.

6.

Haz al cdigo semi-documentable escogiendo nombres descriptivos (pero relativamente cortos) para los
objetos, tipos, funciones, etc.

7.

Si necesitas una seccin anidada, crea una funcin.

8.

Crea tus funciones cortas y enfocadas en una sola tarea. El viejo lmite de 24 lneas an aplica. A pesar que
los tamaos de las pantallas han cambiado, nada ha cambiado en la cognicin humana desde la dcada de los
sesenta.

9.

Las funciones deben tener pocos parmetros (cuatro es buen lmite superior). Esto no restringe los datos
comunicados a las funciones: agrupando parmetros relacionados en un objeto beneficia desde sus invariantes
y ahorra razonamiento, tales como su coherencia y consistencia.

10.

En general, cada unidad de cdigo, desde un bloque hasta una biblioteca, debera tener una interface rala.
Menos comunicacin reduce el razonamiento requerido. Esto significa que los getters que regresan estados
internos son una liabilidad no pidas a un objeto la informacin que ya tiene. En otras palabras, la
encapsulacin es todo sobre interfaces limitadas.

11.

Para poder preservar las clases invariantes, el uso de setters no debera ser recomendada, debido a que los
setters tienden a permitir invariantes que gobiernan el estado de un objeto hacia su ruptura.

Conforme se razone sobre la correctitud, argumentar sobre tu cdigo te ofrece entendimiento sobre l. Comunica sus
descubrimientos para el beneficio de todos.

Codifica en el lenguaje del dominio

Autor: Dan North

Imagnate dos cdigos bases. En uno te encuentras esto:
if (portfolioIdsByTraderId.get(trader.getId())
.containsKey(portfolio.getId())) {...}
Te rascas la cabeza imaginndote para que podra servir este cdigo. Parece que est obteniendo un ID desde un
objeto comerciante (trader), usndolo para obtener aparentemente un mapa de mapas y, entonces, est viendo si
otro ID desde un objeto portafolio (portfolio) existe en el mapa interior. Te rascas la cabeza un poco ms. Ves la
declaracin del mtodo portfolioIdsByTraderId y descubres esto:
Map<int, Map<int, int>> portfolioIdsByTraderId;
Poco a poco te das cuenta que podra tener algo que ver con que un comerciante tenga acceso a un portafolio en
particular. Y, por supuesto, encontrars el mismo fragmento de bsqueda o un similar-pero- ligeramente-diferente
fragmento de cdigo en el momento en que a alguien le importa si un comerciante tiene acceso a un portafolio en
particular.
En el otro cdigo base te encuentras con esto:
if (trader.canView(portfolio)) {...}
No hay rascado de cabeza. No necesitas saber cmo lo sabe un comerciante. Quizs es uno de esos mapas de
mapas escondidos dentro. Pero es un asunto del comerciante, no tuyo.
Ahora, en cul de estos cdigos te gustara estar trabajando?

Hubo un tiempo en que slo tenamos unas muy bsicas estructuras de datos: bit, bytes y caracteres (realmente slo
bytes que pretendamos que fueran letras y puntuaciones). Tener decimales eran un poco truculento porque nuestros
nmeros de base 10 no trabajan muy bien en binario, as que tenamos varios tamaos de tipos de punto flotante.
Entonces vinieron las matrices y las cadenas (realmente slo matrices distintas). Tenamos pilas, colas, hashes, listas
ligadas y listas salteadas y muchas otras excitantes estructuras de datos que no existan en el mundo real. La
Ciencia Computacional se trataba de gastar mucho esfuerzo mapeando el mundo real en nuestras estructuras de
datos restrictivas. Los verdaderos gurs podran incluso recordar cmo lo haban logrado.
Entonces tuvimos los tipos definidos por el usuario! Est bien, esto no es noticia, pero fue un cambio en el juego, de
alguna manera. Si tu dominio contiene conceptos como negociantes y portafolios, podas modelarlos con tipos
llamados, digamos, Comerciantes y Portafolio. Pero, ms importante que esto, tambin puedes modelar relaciones
entre ellos usando trminos de dominio.
Si no codificas usando trminos del dominio ests creando un entendimiento tcito (lase: secreto) de que este valor
de tipo entero que est por ah significa la manera de identificar a un comerciante, donde ese valor de tipo entero por
all es la manera de identificar un portafolio. (Mejor no confundirlos!) Y si representas un concepto de negocio (a
algunos comerciantes no les est permitido ver algunos portafolios es ilegal) con un algoritmo, digamos la
existencia de relaciones en un mapa de claves, no le ests haciendo ningn favor a los chicos de auditora y quejas.
El programador de junto quizs no sepa el secreto, as que porqu no hacerlo explcito? Usar una llave como el
trmino de bsqueda de otra llave que realiza la revisin de una llave existente no es terriblemente obvio. Cmo se
supone que alguien intuya que ah estn implementadas las reglas de negocio que previenen conflictos de inters?
Realizar conceptos explcitos del dominio en tu cdigo significa que otros programadores pueden adquirir la intencin
del cdigo mucho ms fcilmente que intentar meter un algoritmo en lo que entienden sobre el dominio. Esto tambin
significa que cuando el modelo del dominio evoluciona es decir, que tu entendimiento se incrementa ests en una
buena posicin para evolucionar el cdigo. En conjunto con una buena encapsulacin, aumenta la oportunidad de
que la regla exista slo en un lugar y que puedes cambiarla sin que el cdigo dependiente se d cuenta.
El programador que venga unos cuantos meses despus a trabajar con el cdigo te lo agradecer y quizs ese
programador seas t.

Codificacin Ubuntu para tus amigos

Autor: Aslam Khan

A menudo escribimos cdigo en el aislamiento y refleja nuestra interpretacin personal de un problema, as como una
solucin personalizada. Podemos ser parte de un equipo y aun as estar aislados. Olvidamos todo tan fcilmente que
este cdigo creado en el aislamiento ser ejecutado, usado, extendido y ha confiado a otros. Es fcil pasar por alto el
aspecto social de la creacin de software. Crear software es un ejercicio tcnico mezclado con un ejercicio social.
Slo necesitamos levantar nuestra cabeza para darnos cuenta de que no estamos trabajado aisladamente y tenemos

responsabilidades compartidas con respecto a incrementar la probabilidad de xito de todos, no slo del equipo de
desarrollo.
Podemos escribir cdigo de buena calidad en el aislamiento, mientras nos perdemos en nosotros mismos. Desde
alguna perspectiva, eso es un enfoque egocntrico (no ego como en arrogante, sino ego como en lo personal).
Tambin es una visin Zen y es sobre ti, en ese momento de la creacin de cdigo. Siempre intento vivir en el
momento porque ayuda a estar ms cerca de la calidad, pero entonces vivo en mi momento. Qu pasa con el
momento de mi equipo? Es mi momento el mismo que el del equipo?
En Zulu, la filosofa de Ubuntu se resume en Umuntu ngumuntu ngabantu, que se podra traducir como una
persona es una persona a travs de (otras) personas. Me siento mejor porque t me haces mejor a travs de tus
buenas acciones. La otra cara es que eres peor en lo que haces cuando soy malo en lo que hago. Entre
desarrolladores, podemos reducirlo a un desarrollador es un desarrollador a travs de (otros) desarrolladores. Si lo
llevamos hasta el metal, entonces el cdigo es cdigo a travs de cdigo (de los otros).
La calidad del cdigo que escribo afecta la calidad del cdigo que tu escribes. Qu pasa si mi cdigo es de baja
calidad? Incluso si escribes un cdigo muy limpio, los puntos donde usas mi cdigo es donde la calidad de tu cdigo
se degrada. Puedes aplicar muchos patrones y tcnicas para limitar el dao, pero el dao ya est hecho. He causado
que t hagas ms de lo que necesitas hacer simplemente porque no pens en ti cuando estaba viviendo mi
momento.
Puede que considere mi cdigo como limpio, pero puedo an hacerlo mejor slo codificando Ubuntu. A que se
parece el cdigo Ubuntu? Se ve como un buen cdigo limpio. No se trata del cdigo, el artefacto. Se trata del acto de
crear ese artefacto. Codificar para tus amigos con Ubuntu ayudar a que tu equipo viva tus valores y refuerce sus
principios. La siguiente persona que toque tu cdigo, en cualquier forma, ser una mejor persona y un mejor
desarrollador.
El Zen se trata de lo individual. Ubuntu es acerca del Zen para un grupo de personas. Muy, muy raramente creamos
cdigo para nosotros mismos.

El cdigo es diseo

Autor: Ryan Brush

Imagnate despertar maana y saber que la industria de la construccin ha hecho el avance del siglo. Millones de
robots baratos e increblemente rpidos pueden fabricar materiales de la nada, tener gasto energtico cercano a cero
y se pueden reparar a s mismos. Y se pone mejor: al darle un no-ambiguo plano para un proyecto de construccin, el
robot puede construirlo sin la intervencin humana, todo ello a un costo insignificante.
Uno puede imaginar el impacto en la industria de la construccin, pero qu pasara ms adelante? Cmo
cambiara el comportamiento de los arquitectos y diseadores si los costos de construccin fueran insignificantes?

Hoy en da modelos fsicos y computacionales son creados y rigorosamente probados antes de invertir en la
construccin. Nos preocuparamos si la construccin fuera esencialmente gratis? Si un diseo se colapsa, no hay
problema, slo encuentra qu estuvo mal y pon a nuestros robots mgicos a construir otro. Hay otras implicaciones.
Con modelos obsoletos, los diseos sin terminar evolucionan mediante la construccin y mejoran en repetidas
ocasiones hacia una aproximacin de la meta final. Un observador casual podra tener problemas distinguiendo un
diseo inacabado y un producto terminado.
Nuestra capacidad para predecir lneas de tiempo se esfumara. Los costos de construccin son calculados ms
fcilmente que los costos de diseo sabemos el costo aproximado de instalar una viga y cuntas vigas
necesitamos. Como las tareas predecibles se reducen a cero, la poca del diseo menos predecible empieza a
dominar. Los resultados se producen con mayor rapidez, pero los plazos fiables escapan.
Por supuesto, se sigue aplicando la presin de una economa competitiva. Con los costos de construccin
eliminados, una empresa puede completar rpidamente un diseo ganando una esquina en el mercado. El tener
pronto los diseos terminados se convierte en el empuje central de las firmas de ingeniera. Inevitablemente, alguien
no familiarizado con el diseo ver una versin invalidada, ve una ventaja del mercado al liberar temprano y dice
esto parece lo suficientemente bien.
Algunos proyectos de vida o muerte sern ms diligentes, pero en muchos casos los consumidores aprende a sufrir
el diseo incompleto. Las empresas siempre puede mandar robots mgicos a parchar los edificios y vehculos rotos
que venden. Todo esto apunta a una conclusin intuitiva: nuestra nica premisa era una dramtica reduccin en los
costos de construccin, con el resultado de que la calidad ha empeorado.
No debera sorprendernos que la historia de arriba fuera ejecutada por el software. Si aceptamos que el cdigo es
diseo un proceso creativo en vez de uno mecnico la crisis del software se explica. Ahora tenemos una crisis de
diseo: la demanda de diseos validados y de calidad excede nuestra capacidad de crearlos. La presin por usar
diseos incompletos es fuerte.
Afortunadamente, este modelo tambin ofrece pistas de cmo mejorar. Las simulaciones fsicas equivalen a pruebas
automatizadas; el diseo de software no est completo hasta que es validado con una batera de pruebas brutal.
Para hacer tales pruebas ms efectivas estamos encontrando maneras de frenar en el gran espacio de estados de
los grandes sistemas. Los lenguajes mejorados y las prcticas de diseo nos dan esperanza. Finalmente, hay un
hecho ineludible: los grandes diseos son producidos por grandes diseadores dedicados a la maestra de su oficio.
El cdigo no es diferente.

Comenta slo lo que el cdigo no dice

Autor: Kevlin Henney

La diferencia entre teora y prctica es ms grande en la prctica que en la teora una observacin que aplica a los
comentarios. En teora, la idea general de comentar cdigo suena como algo til: ofrece al lector detalles, una

explicacin de lo que est pasando. Qu podra ser ms til que ser til? En la prctica, sin embargo, los
comentarios frecuentemente se convierten en una plaga. As como otras formas de escritura, existen habilidades para
escribir buenos comentarios. Mucho de esa habilidad es saber cundo no escribirlos.
Cuando el cdigo est mal formado, los compiladores, intrpretes y otras herramientas se aseguran de objetar. Si el
cdigo es, de algn modo, funcionalmente incorrecto, las revisiones, los anlisis estticos, las pruebas y el uso diario
en un ambiente de produccin eliminar muchos de los errores. Qu me dices de los comentarios? En The
Elements of Programming Style, Kernighan y Plauger notaron que un comentario tiene valor de cero (o negativo) si
es errneo. Y, sin embargo, tales comentarios ofrecen poco y sobreviven en un cdigo base de una manera que los
errores de codificacin nunca pueden. Proporcionan una fuente constante de distraccin y desinformacin, un lastre
sutil pero constante en el pensamiento de un programador.
Qu hay con los comentarios que no estn tcnicamente mal, pero no agregan valor al cdigo? Son ruido. Los
comentarios que parlotean el cdigo no ofrecen algo extra al lector decir algo una vez en cdigo y otra vez en
lenguaje natural no lo hace ms verdadero o ms real. El cdigo comentado no es cdigo ejecutable, por lo que no
tiene un efecto til para el lector, ni en tiempo de ejecucin. Tambin se vuelve rancio fcilmente. Los comentarios
relacionados a la versin y el cdigo comentado tratan de abordar preguntas sobre las versiones y la historia. Estas
preguntan ya han sido respondidas, de forma ms eficiente, por las herramientas de control de versiones.
Una prevalencia de comentarios ruidosos e inconsistentes en el cdigo base anima a los programadores a ignorar
todos los comentarios, ya sea saltndolos o tomando medidas activas para ocultarlos. Los programadores tienen
muchos recursos y le darn vuelta a cualquier cosa que se perciba como daino: plegando los comentarios;
cambiando el esquema de color, as los comentarios y el color de fondo se igualan; creando scripts para filtrar
comentarios. Para salvar el cdigo base de las malas aplicaciones de la ingenuidad del programador, y reducir el
riesgo de pasar por alto cualquier comentario de valor genuino, los comentarios deberan ser tratados como si fueran
cdigo. Cada comentario debera agregar algo de valor al lector, de otro modo es un desperdicio que debera ser
removido o reescrito.
Qu lo califica como valioso? Los comentarios deberan decir algo que el cdigo no hace y no puede decir. Un
comentario que explica lo que una pieza de cdigo ya debera decir es una invitacin para cambiar la estructura
del cdigo o las convenciones de codificacin para que hable por s mismo. En vez de compensar la pobreza en el
nombre de los mtodos o de las clases, renmbralos. En vez de comentar secciones en funciones largas, extrae
las funciones pequeas cuyos nombres capturen las intenciones de las anteriores partes. Intenta expresar tanto
como sea posible a travs del cdigo. Cualquier dficit entre lo que puedes expresar en cdigo y lo que deseas
expresar en su totalidad se convierte en un candidato plausible para un comentario til. Comenta lo que el cdigo
no puede decir, no lo que el cdigo no dice.

Un comentario acerca de los comentarios

Autor: Cal Evans

En mi primera clase de programacin en la universidad, el profesor nos entreg dos hojas de codificacin BASIC. En
el pizarrn, se lea la asignatura: Escribir un programa para ingresar y promediar 10 puntuaciones de bolos. A
continuacin, el profesor sali de la habitacin. Qu tan difcil puede ser? No recuerdo mi solucin final, pero estoy
seguro que tena un bucle FOR/NEXT en l y no poda haber sido de ms de 15 lneas de longitud en total. Las hojas
de codificacin para los nios que leen esto, s, solamos escribir el cdigo a mano antes de ingresarlo a la
computadora permitan alrededor de 70 lneas de cdigo cada una. Estaba confundido sobre por qu el maestro nos
haba dado dos hojas. Debido a que mi manuscrito haba sido atroz, us la segunda en transcribir mi cdigo muy
cuidadosamente, esperando obtener un par de puntos extras por el estilo.
Para mi sorpresa, cuando me regresaron la asignatura, al inicio de la siguiente clase, obtuve una calificacin apenas
aprobatoria. (Sera un presagio para m el resto del tiempo en la universidad). Garabateado en la parte superior de mi
cuidadosamente copiado cdigo: Sin comentarios?.
No era suficiente que el profesor y yo supiramos lo que se supona hara el programa. Parte de los puntos de la
asignatura era ensearme que mi cdigo deba explicarse por s mismo al programador despus de m. Es una
leccin que no he olvidado.
Los comentarios no son malignos. Son necesarios en la programacin tanto como los constructos ms bsicos de
ramificaciones o ciclos. Los lenguajes ms modernos tienen una herramienta similar a javadocs que analiza
comentarios con el formato adecuado para construir automticamente la documentacin del API. Esto es un buen
comienzo, pero no es suficiente. Dentro de tu cdigo debera haber explicaciones acerca de lo que se supone que
est haciendo. Codificar con el viejo adagio: Si fue difcil de escribir, debe ser difcil de leer, hace un pobre favor a tu
cliente, tu empleador, tus colegas o tu propio futuro.
Por otro lado, puedes irte demasiado lejos con tus comentarios. Asegrate de que clarifican el cdigo, pero no lo
obscurecen. Espolvorea tu cdigo con comentarios relevantes explicando qu debe realizar. El comentario principal
debera darle a cualquier programador suficiente informacin para usarlo sin tener que leerlo, mientras que los
comentarios en lnea deberan asistir al siguiente desarrollador que lo arregle o lo extienda.
En un trabajo estuve en desacuerdo con una decisin de diseo hecha por mis superiores. Por intentar ser
sarcstico, como suelen ser los programadores jvenes, copi el texto del correo en el cual se me instrua a usar su
diseo en el bloque del comentario principal del archivo. Sucedi que los administradores de esta tienda en particular
revisaron el cdigo cuando lo envi. Fue mi primera introduccin al trmino despido por lmite de profesin.

Cmo usar un Gestor de Errores?

Autor: Matt Doar

Como sea que lo llames: bug, defecto o incluso efecto del lado de diseo, no hay manera de alejarse de ellos.
Saber enviar un buen reporte de error y lo que se debe buscar son habilidades para mantener un proyecto que se
lleve bien.

Un buen reporte de error necesita tres cosas:

Cmo reproducir el error, lo ms preciso posible, y la frecuencia con que esto har que aparezca el error.

Qu debera haber ocurrido? Al menos en tu opinin.

Qu ocurri realmente? Toda la informacin que has registrado.

La cantidad y calidad de la informacin reportada dice mucho acerca de quin reporta y del error mismo. Los errores
con enojo o tensin (esta funcin apesta!) nos dice que los desarrolladores estaban teniendo un mal momento,
pero no ms. Un error con gran cantidad de contexto para que sea ms fcil reproducirlo gana el respeto de todo el
mundo, incluso si detiene una liberacin.
Los errores son como un conversacin, con toda la historia ah en frente de todos. No culpes a otros o niegues la
existencia del error. En vez de eso pide ms informacin o considera qu pudiste haber olvidado.
Cambiar el estatus de un error, por ejemplo, de Abierto a Cerrado, es una declaracin pblica de lo que se piensa del
error. Tomarse el tiempo de explicar por qu crees que el error debera estar cerrado ahorrar horas de tedio en
justificarlo a directores y clientes frustrados. Cambiar la prioridad de un error es similar a las declaraciones pblicas, y
slo porque es trivial no significa que alguien est dejando de usar el producto.
No sobrecargues los campos del error para tu propio propsito. Agregar VITAL: al campo de ttulo de error puede
hacer que sea fcil ordenar los resultados en algn informe, pero har que eventualmente sea copiado por otros e
inevitablemente ser mal escrito o necesitar ser removido para su uso en algn otro informe. En vez de eso usa un
nuevo valor o un nuevo campo, y documenta cmo el campo se supone debe ser usado, as otras personas no tienen
que repetirlo.
Asegrate que todos sepan cmo encontrar el error en el que se supone est trabajando el equipo. Esto se puede
hacer mediante una consulta pblica con un nombre obvio. Asegrate que todos estn usando la misma consulta, y
no la actualices sin primero informar al equipo que ests cambiando algo en lo que todos estn trabajando.
Recuerda, un error no es una unidad estndar de trabajo, como tampoco una lnea de cdigo es una unidad precisa
de esfuerzo.

Conoce bien ms de dos lenguajes de programacin

Autor: Russel Winder

La psicologa de la gente programadora ha sabido, desde hace mucho tiempo, que la experiencia de programacin
est relacionada directamente con el nmero de diferentes paradigmas de programacin con que el programador se
sienta cmodo. No se refiere slo saber o saber un poco, sino a poder programar genuinamente con ellos.

Cada programador inicia con un lenguaje de programacin. Este lenguaje tiene un efecto dominante en la forma en
que el programador piensa acerca del software. No importa cuntos aos de experiencia tenga el programador
usndolo, si se queda con l slo sabr ese lenguaje. Un programador de un solo lenguaje est limitado en su
pensamiento por ese lenguaje.
Un programador que aprende un segundo lenguaje ser desafiante, especialmente si tiene un modelo computacional
diferente que el primero. C, Pascal, Fortran, todos tiene fundamentalmente el mismo modelo computacional. Cambiar
de Fortran a C introduce unos pocos, pero no muchos retos. Moverse de C o Fortran a C++ o Ada introduce retos
fundamentales en la forma en que los programas se comportan. Pasarse de C++ a Haskell es un cambio significativo
y, por lo tanto, un desafo importante. Moverse de C a Prolog es un desafo muy concreto.
Podemos enumerar varios paradigmas de computacin: procedimental, orientado a objetos, funcional, lgico, de flujo
de datos (dataflow), etc. Moverse entre estos paradigmas crea los mayores desafos.
Por qu son buenos estos desafos? Tiene que ver con la forma en que pensamos en la implementacin de
algoritmos, los modismos y patrones de implementacin que aplican. En especfico, la fertilizacin cruzada es la base
de la experiencia. Los modismos para la solucin de problemas que aplican en un lenguaje podran no ser posibles
en otro. Tratar de portar el modismo de un lenguaje a otro nos ensea sobre ambos lenguajes y sobre el problema a
ser resuelto.
La fertilizacin cruzada en el uso de lenguajes de programacin tiene enormes efectos. Quizs el ms obvio es el uso
creciente de modos de expresin declarativos en los sistemas implementados en lenguajes imperativos. Cualquier
persona versada en programacin funcional puede aplicar fcilmente un enfoque declarativo cuando est usando un
lenguaje como lo es C. El uso de enfoques declarativos generalmente conduce a programas ms cortos y ms
comprensibles. C++, por ejemplo, sin duda, toma esto en cuenta con su apoyo incondicional de la programacin
genrica, que casi necesita un modo de expresin declarativo.
La consecuencia de todo esto es que le incumbe a cada programador ser diestro en la programacin en, al menos,
dos diferentes paradigmas, e idealmente en los cinco arriba mencionados. Los programadores deben estar siempre
interesados en aprender nuevos lenguajes, preferiblemente de un paradigma en el que no estn familiarizados.
Incluso si en el trabajo diario siempre usa el mismo lenguaje de programacin, la mayor sofisticacin en el uso de ese
lenguaje cuando una persona puede hacer fertilizacin cruzada desde otro paradigma no debe ser subestimada. Los
empleadores deberan tomar esto en cuenta y permitir en su presupuesto de capacitacin aprender lenguajes que
actualmente no estn siendo usados, como un modo de incrementar la sofisticacin de los lenguajes que se utilizan.
A pesar de que es un inicio, un curso de capacitacin de una semana no es suficiente para aprender un nuevo
lenguaje, generalmente toma unos cuantos meses de uso, aunque a tiempo parcial, para ganar un conocimiento
adecuando de un lenguaje. Son sus modismos de uso, no slo la sintaxis y el modelo computacional, los factores
importantes.

Conoce tu IDE

Autor: Heinz Kabutz

En la dcada de los ochenta nuestros entornos de programacin eran, por lo general, nada mejor que editores de
texto glorificados si tenamos suerte. El resaltado de sintaxis, que damos por sentado hoy en da, era un lujo que
ciertamente no estaba disponible para todos. Los Pretty Printers para formatear bien nuestro cdigo eran usualmente
herramientas externas que tenan que ser ejecutadas para corregir nuestro espaciamiento. Los depuradores eran
tambin programas separados ejecutndose paso a paso a travs de nuestro cdigo, pero con un montn de
teclazos crpticos.
Durante la dcada de los noventa las compaas comenzaron a reconocer el potencial de ingresos que pudieran
derivarse de equipar a los programadores con mejores y ms tiles herramientas. El Entorno Integrado de Desarrollo
(IDE, por sus siglas en ingls) combinaba las caractersticas de edicin previas con un compilador, un depurador,
Pretty Printer y otras herramientas. Durante ese tiempo, los mens y el ratn tambin se volvieron populares, lo cul
significaba que los desarrolladores ya no necesitaban aprender combinaciones de teclas crpticos para usar sus
editores. Podan simplemente seleccionar su comando en el men.
En el siglo XXI los IDE se convirtieron en un lugar tan comn que eran regalados por las compaas que deseaban
ganar un segmento del mercado en otras reas. El IDE moderno est equipado con una increble variedad de
caractersticas. Mi favorita es la refactorizacin automatizada, particularmente la Extraccin de Mtodo, en el cual
puedo seleccionar y convertir un fragmento de cdigo en un mtodo. La herramienta de refactorizacin recoger
todos los parmetros que deben ser transferidos al mtodo, lo cul hace extremadamente fcil modificar cdigo. Mi
IDE detectar incluso otro fragmento de cdigo que podra tambin ser reemplazado por este mtodo y preguntarme
si deseo reemplazarlo tambin.
Otra caracterstica sorprendente en los IDE modernos es la capacidad de hacer cumplir las reglas de estilo dentro de
una empresa. Por ejemplo, en Java, algunos programadores han empezado a hacer todos los parmetros
como final (lo cual, en mi opinin, es una prdida de tiempo). Sin embargo, como ellos lo tienen como una regla de
estilo, todo lo que necesitara hacer a continuacin es configurarlo en mi IDE: obtendra algunas advertencias por
cada parmetro que no fuese final . Las reglas de estilo tambin pueden ser utilizadas para encontrar errores
probables, tales como comparar objetos autoboxed para la igualdad de referencia, por ejemplo, usando == en los
valores primitivos que estn autoboxed en referencias a objetos.
Desafortunadamente, los IDE modernos no requieren de invertir esfuerzo para aprender a usarlos. Cuando program
por primera vez en C bajo Unix tuve que pasar un poco de tiempo aprendiendo cmo trabajaba el editor vi, debido a
su curva de aprendizaje. Este tiempo gastado pag por adelantando bellamente al paso de los aos. Incluso he
escrito el borrador de este artculo con vi. Los IDE modernos tienen una curva de aprendizaje muy gradual, la cual
puede tener como consecuencia que nunca progresamos ms all del uso bsico de la herramienta.
Mis primeros pasos al aprender un IDE es memorizar los atajos de teclado. Ya a que mis dedos estn en el teclado
cuando estoy escribiendo mi cdigo, presionar Ctrl+Shift+I para alinear una variable me ahorra tener que romper mi
flujo, navegar por el men con el ratn interrumpe este flujo. Estas interrupciones lleva a cambios de contexto

innecesarios, hacindome mucho menos productivo si trato de hacer todo por el camino perezoso. La misma regla
tambin aplica a las habilidades del teclado: aprende a teclear, no te arrepentirs del tiempo invertido por adelantado.
Por ltimo, como programadores tenemos herramientas de flujo Unix que pueden ayudarnos a manipular el cdigo.
Como si durante una revisin de cdigo me doy cuenta de que los programadores han nombrado muchas de sus
clases de la misma forma, puedo encontrarlas fcilmente usando las herramientas find, sed, sort, uniq y grep, por
ejemplo:
find . -name "*.java" | sed 's/.*\///' | sort | uniq -c | grep -v "^ *1 " | sort -r
Esperamos que un plomero que llega a nuestra casa sea capaz de usar su soplete. Pasemos un poco de tiempo
estudiando cmo ser ms efectivos con nuestro IDE.

Conoce tus lmites

Autor: Greg Colvin

Mans got to know his limitations. Dirty Harry
Tus recursos son limitados. Slo tienes cierto tiempo y dinero para hacer tu trabajo, incluyendo el tiempo y dinero
necesario para mantener al da tus conocimiento, habilidades y herramientas. Slo se puede trabajar duro, rpido e
inteligentemente por cierto tiempo. Tus herramientas son poderosas. Tus mquinas destino son poderosas. Tienes
que respetar los lmites de tus recursos.
Cmo respetar estos lmites? Concete a ti mismo, conoce a tu gente, tu presupuesto y tus cosas. Especialmente,
como ingeniero de software, conoce el espacio y tiempo de la complejidad de tus estructuras de datos y algoritmos,
as como las caractersticas y rendimiento de tus sistemas. Tu trabajo es crear el enlace ptimo de software y
sistemas.
La complejidad del espacio y tiempo estn dadas como la funcin O(f(n)) donde n es igual al tamao de las entradas
en el espacio asinttico o el tiempo requerido conforme nincrementa hacia infinito. Las clases de complejidad
importantes para f(n) incluyen ln(n), n, n ln(n), ne y en. Al graficar estas funciones se muestra claramente cmo
conforme n se incrementa, O(ln(n)) es siempre mucho ms pequea que O(n) y O(n ln(n)), las cuales son cada vez
ms pequeas que O(ne) y O(en). Como deca Sean Parent, para lograr ntodas las clases de complejidad se
acumulan casi constamente, casi lineal o casi al infinito.

El anlisis de complejidad est en trminos de una mquina abstracta, pero el software se ejecuta en mquinas
reales. Las sistemas modernos de computadoras estn organizados como jerarquas de mquinas fsicas y virtuales,
incluyendo lenguajes en tiempo de ejecucin, sistemas operativos, CPU, memoria cach, memoria de acceso
aleatorio, manejadores de disco y redes. La primera tabla muestra los lmites en el tiempo de acceso aleatorio y la
capacidad de almacenamiento para un servidor en red tpico.

register

Tiempo de Acceso

Capacidad

< 1 ms

64b

cache line

64B

L1 cache

1 ms

64 KB

L2 cache

4 ns

8 MB

RAM

20 ns

32 GB

disk

10 ms

10 TB

LAN

20 ms

> 1 PB

internet

100 ms

> 1 ZB

Toma en cuenta que la capacidad y velocidad difiere en varios rdenes de magnitud. El almacenamiento en cach y
el lookahead son usados ampliamente en cada nivel de nuestro sistema para ocultar esta variacin, pero slo
funcionan cuando el acceso es predecible. Cuando el cach falla es frecuente que el sistema est arrastrndose. Por
ejemplo, inspeccionar aleatoriamente cada byte en un disco duro podra tomar hasta 32 aos. Incluso inspeccionar
aleatoriamente cada byte en la RAM podra tomar 11 minutos. El acceso aleatorio no es predecible. Qu lo es? Eso

depende del sistema, pero volver a acceder a elementos recientemente usados y acceder a elementos
secuencialmente suele ser una victoria.
Los algoritmos y las estructuras de datos varan en qu tan efectivamente usan el cach. Por ejemplo:

La bsqueda lineal hace buen uso del lookahead, pero requiere O(n) comparaciones.

La bsqueda binaria de una matriz ordenada requiere slo O(log(n)) comparaciones.

La bsqueda en un rbol van Emde Boas es O(log(n)) y es ajeno al cach.

Cul elegir? Como en el pasado anlisis, midindolo. La segunda tabla muestra el tiempo requerido para buscar en
matrices de enteros de 64 bits va estos tres mtodos. En mi computadora:

La bsqueda lineal es competitiva para matrices pequeas, pero pierde exponencialmente para matrices
grandes

van Emde Boas gana sin usar las manos, gracias a su patrones de acceso predecible.

Elementos

lineal

binario

vEB

50

90

40

64

180

150

70

512

1200

230

100

4096

17000

320

160

Pagas tu dinero y te llevas tu eleccin. Punch

La conveniencia no es una -bilidad

Autor: Gregor Hohpe

Mucho se ha dicho acerca de la importancia y desafos al disear una buena API. Es difcil hacerlo bien la primera
vez y es incluso ms difcil cambiarlo despus. Algo as como la crianza de nios. La mayora de los programadores
experimentados han aprendido que una buena API sigue un nivel consistente de abstraccin, exhibe consistencia y
simetra, y forma el vocabulario para un lenguaje expresivo. Por lo tanto, estar consciente de los principios gua no se
traduce automticamente en un comportamiento adecuado. Comer dulces es malo para ti.
En vez de predicar desde las alturas, quiero tomar una estrategia especfica de diseo de API, una que me
encuentro una y otra vez: el argumento de conveniencia. Comienza tpicamente con los siguientes puntos de vista:

No quiero que otras clases tengan que hacer dos llamadas separadas para hacer una cosa.

Por qu debera hacer otro mtodo si es casi igual que ste? Slo agregar un switch sencillo.

Mira, es muy fcil: si el segundo parmetro de cadena termina con .txt, el mtodo automticamente asume
que el primer parmetro es el nombre de archivo, por lo que no necesito realmente dos mtodos.

Aunque sea bien intencionado, tales argumentos son propensos a disminuir la legibilidad del cdigo al usar el API.
Una invocacin de mtodo como esta:
parser.processNodes(text, false);
no tiene virtualmente algn significado si no sabemos la implementacin, o al menos consultar la documentacin.
Este mtodo fue probablemente diseado para la comodidad del implementador como un opuesto de la conveniencia
de quien llama. No quiero que quien hace la llamada tenga que hacer dos llamadas separadas se traduce en: no
quera codificar dos mtodos separados. No hay nada fundamentalmente malo con la conveniencia si tiene intencin
de ser el antdoto del tedio, falta de idea o incomodidad. Sin embargo, si pensamos ms cuidadosamente en ello, el
antdoto para esos sntomas es la eficiencia, consistencia y elegancia, no necesariamente la conveniencia. Se
supone que el API oculta la complejidad subyacente, podemos esperar de manera realista que un buen diseo de API
requiere algo de esfuerzo. Un solo mtodo largo podra ser ciertamente ms conveniente de escribir que un bien
pensado conjunto de operaciones, pero sera fcil de usar?
La metfora del API como un lenguaje puede guiarnos hacia mejores decisiones de diseo en estas situaciones. Un
API debe proporcionar un lenguaje expresivo, lo cual nos da en el siguiente nivel suficiente de vocabulario para
preguntar y responder preguntas tiles. Esto no implica que debera proveer exactamente un mtodo o verbo por
cada pregunta que valga la pena. Un vocabulario diverso nos permite expresar matices de significado. Por ejemplo,
preferimos decir correr en vez de caminar(true), a pesar de que podra ser visto como esencialmente la misma
operacin, slo ejecutada en una velocidad distinta. Un vocabulario API consistente y bien pensado hace expresivo y
fcil de entender el cdigo del siguiente nivel. Ms importante an, un vocabulario que pueda ser mejorado permite a
otros programadores usar el API de formas que quizs no habas anticipado de hecho, una gran conveniencia para
los usuarios del API!. La prxima vez que ests tentado a agrupar unas cuantas cosas en un mtodo API, recuerda
que

el

idioma

ingls

no

tiene

una

palabra

para

MakeUpYourRoomBeQuietAndDoYourHomeWork

(LimpiaTuCuartoSeCalladoyHazTuTarea), a pesar de que parece muy conveniente para una operacin tan
frecuentemente solicitada.

Cuando Programadores y Testers colaboran

Autor: Janet Gregory

Algo mgico sucede cuando los testers y programadores empiezan a colaborar. Hay menos tiempo perdido
mandando bugs de ida y de regreso a travs del sistema de rastreo de defectos. Menos tiempo se desperdicia
intentando imaginar si algo es realmente un error o una nueva caracterstica, y ms tiempo es usado desarrollando
buen software para satisfacer las expectativas de los clientes. Hay muchas oportunidades para comenzar a colaborar,
incluso antes de que la codificacin inicie.

Los testers pueden ayudar a los clientes a escribir y automatizar las pruebas de aceptacin usando el lenguaje de su
dominio con herramientas tales como Fit (Framework for Integrated Test). Cuando estas prueban son entregadas a
los programadores antes de que la codificacin inicie, el equipo est practicando el Desarrollo Conducido por
Pruebas de Aceptacin (Acceptance Test Driven Development, ATDD). Los programadores escriben sus arreglos
para ejecutar las pruebas, y entonces codifican para hacer que las pruebas pasen. Estas pruebas se convierten en
parte de la suite de regresin. Cuando esta colaboracin ocurre, las pruebas funcionales se completan de manera
temprana, lo que da tiempo para las pruebas exploratorias en condiciones extremas o a travs de flujos de trabajo
con un rango ms amplio.
odemos dar un paso ms adelante. Como tester puedo suministrar la mayora de mis ideas de prueba antes de que
los programadores codifiquen una nueva caracterstica. Cuando le pregunto a los programadores si tienen alguna
sugerencia, ellos casi siempre me proveen la informacin que me ayuda con una mejor cobertura de pruebas, o me
ayuda a evitar gastar mucho tiempo en pruebas innecesarias. Frecuentemente hemos prevenido defectos porque las
pruebas clarifican muchas de las ideas iniciales. Por ejemplo, en un proyecto en el que estaba, la prueba Fit que le di
al programado mostraba los resultados esperados de una consulta que responda a una bsqueda con comodines. El
programador pretenda codificar slo bsquedas de palabras completas. Pudimos hablar con el cliente y determinar
la interpretacin correcta antes de que la codificacin iniciara. Al colaborar prevenimos el defecto, lo cual nos ahorr a
ambos un montn de tiempo.
Los programadores pueden colaborar con los testers para crear tambin una automatizacin exitosa. Ellos entienden
las buenas prcticas de codificacin y pueden ayudar a los testers a configurar una robusta suite de automatizacin
de pruebas que funcione para todo el equipo. Muchas veces he visto proyectos de automatizacin que fallan porque
las pruebas estn mal diseadas. Las pruebas intentan probar mucho o los testers no han entendido lo suficiente
acerca de la tecnologa para ser capaces de mantener las pruebas independientes. Los testers son frecuentemente el
cuello de botella, as que tiene sentido para los programadores el trabajar con ellos en las tareas como la
automatizacin. Al trabajar con los testers para entender qu puede ser probado tempranamente, quizs al
proporcionar una herramienta sencilla, dar a los programadores otro ciclo de retroalimentacin que les ayudar, a
largo plazo, a entregar mejor cdigo.
Cuando los testers dejan de pensar que su nico trabajo es romper el software y buscar errores en el cdigo de los
programadores, los programadores dejan de pensar que los testers van por ellos y estn ms abiertos a la
colaboracin. Cuando los programadores empiezan a darse cuenta de que son responsables de construir calidad
dentro de su cdigo, el realizar pruebas es algo natural para el producto y el equipo puede automatizar ms pruebas
de regresin juntos. La magia del trabajo en equipo comienza.

Ten cuidado al compartir

Autor: Udi Dahan

Era mi primer proyecto en la compaa. Haba terminado mi carrera y estaba ansioso por probarme a m mismo, me
quedaba tarde cada da a revisar el cdigo existente. Conforme trabajaba en mi primera caracterstica tomaba
cuidados adicionales para poner en marcha cada cosa que haba aprendido: comentarios, bitcoras, sacando cdigo

compartido a bibliotecas de ser posible, el trabajo. La revisin de cdigo de la que haba sentido tan listo vino como
una sorpresa desagradable: el reso estaba mal visto! Cmo poda ser eso posible? En toda la universidad el reso
era tomado como el eptome de la ingeniera de calidad de software. Todos los artculos que haba ledo, los libros de
textos, lo que me haban enseado los profesionales de software con experiencia. Estaba todo mal?
Resulta que haba olvidado algo crtico.
Contexto.
El hecho de que dos partes muy diferentes del sistema realizaran la misma lgica de la misma manera significaba
menos de lo que pensaba. Hasta que saqu esas bibliotecas de cdigo compartido, esas partes no eran
dependientes una de otra. Cada una podan evolucionar independientemente. Cada una poda cambiar su lgica para
satisfacer las necesidades de los cambios en el entorno empresarial del sistema. Esas cuatro lneas de cdigo similar
fueron accidentales, una anomala temporal, una coincidencia. Es decir, hasta que llegu.
Las bibliotecas de cdigo compartido que haba creado ataban los cordones de cada zapato de cada pie entre ellos.
Los pasos por un dominio de negocio no podran ser hechos sin primero sincronizarlos. Los costos de mantenimiento
en estas funciones independientes solan ser insignificantes, pero la biblioteca comn requera un orden de magnitud
de ms pruebas.
A pesar de que haba disminuido el nmero absoluto de lneas de cdigo en el sistema, haba incrementado el
nmero de dependencias. El contexto de esas dependencias es crtico, si hubieran sido localizadas, podan haber
sido justificadas y tendran algn valor positivo. Cuando estas dependencias no se mantienen bajo control, sus
tentculos se enredan en las ms grandes preocupaciones del sistema, a pesar de que el cdigo en s se ve muy
bien.
Estos errores son insidiosos por eso, en esencia, suenan como una buena idea. Cuando se aplican en el contexto
adecuado, estas tcnicas son valiosas. En el contexto equivocado, incrementan el costo en vez del valor. Hoy en da
soy mucho ms cuidadoso en los temas de compartir cuando entro en un cdigo base existente sin el conocimiento
del contexto en el que se utilizan las distintas partes.
Cuidado al compartir. Revisa tu contexto. Slo entonces, procede.

Cumple tus ambiciones con Software Libre

Autor: Richard Monson-Haefel

Hay una alta probabilidad de que no ests desarrollando software en tu trabajo para cumplir tus ms ambiciosos
sueos. Quizs ests desarrollando software para una gran compaa de seguros cuando te gustara estar
trabajando en Google, Apple, Microsoft o tu propia start-up, desarrollando la prxima gran cosa. Nunca vas a llegar
a donde quieres desarrollando software para sistemas que no te importan.
Afortunadamente, hay una respuesta a tus problemas: software libre. Hay miles de proyectos de software libre por
ah, muchos de ellos muy activos, los cuales ofrecen cualquier tipo de experiencia de desarrollo de software que

puedas desear. Si amas la idea de desarrollar un sistema operativo, ve y ayuda con alguno. Si deseas trabajar con
software de msica, animacin, criptografa, robtica, juegos de PC, juegos masivos en lnea, telfonos mviles o lo
que sea, puedes estar casi seguro de que encontrars, al menos, un proyecto de software libre dedicado a ese
inters.
Por supuesto que no hay almuerzos gratis. Tienes que estar dispuesto a dar tu tiempo libre porque probablemente no
puedas trabajar en el un videojuego de software libre en tu trabajo, an tienes responsabilidad con tu empleador.
Adicionalmente, muy pocas personas hacen dinero contribuyendo con proyectos de software libre. Debes estar
dispuesto a renunciar a una parte de tu tiempo libre (menos tiempo jugando videojuegos y mirando TV no te matar).
Cuanto ms trabajes en un proyecto de software libre, ms rpido te dars cuenta de tus verdaderas ambiciones
como programador. Tambin es importante considerar tu contrato de empleado, algunos empleadores pueden
restringir contribuciones, incluso en tu propio tiempo. Adems, es necesario tener cuidado con las violaciones de las
leyes de propiedad intelectual que tienen que ver con derechos de autor, patentes, marcas registradas y secretos
comerciales.
El software libre provee enormes oportunidades para el programador motivado. En primer lugar, se llega a ver cmo
alguien ms implementa una solucin que te interesa puedes aprender mucho leyendo el cdigo de otras
personas. En segundo lugar, se llega a contribuir con tu propio cdigo e ideas al proyecto no todas las ideas
brillantes que tengas sern aceptadas, pero algunas podran serlo, y aprenders algo nuevo con slo trabajar en
soluciones y contribuir con el cdigo. En tercer lugar, conocers a personas grandiosas con la misma pasin que t
por el mismo tipo de software estas amistades pueden duran toda la vida. En cuarto lugar, asumiendo que eres un
contribuidor competente, estars en disposicin de agregar la experiencia del mundo real en la tecnologa que
actualmente te interesa.
Iniciar con el software libre es bastante fcil. Hay plena documentacin en las herramientas que necesitas (por
ejemplo, administracin de cdigo fuente, editores, lenguajes de programacin, sistemas de construccin, etctera).
Primero, encuentra el proyecto en el que deseas trabajar y aprende acerca de las herramientas que utiliza. La
documentacin en proyectos por s misma ser una luz en muchos casos, pero esto quizs importe menos debido a
que la mejor manera de aprender es investigar el cdigo por ti mismo. Si deseas estar involucrado, puedes ofrecer tu
ayuda con la documentacin. O puedes comenzar como voluntario para escribir las pruebas de cdigo. A pesar de
que esto podra no sonar excitante, la verdad es que aprendes mucho ms rpido escribiendo pruebas de cdigo
para el software de otra persona como casi cualquier otra actividad en software. Escribe pruebas de cdigo,
realmente buenas pruebas de cdigo; encuentra errores; sugiere correcciones; haz amigos; trabaja en el software
que te gusta y cumple tus ambiciones.

Los grandes datos interconectados pertenecen a una base de datos

Autor: Diomidis Spinellis

Si tu aplicacin est manejando un conjunto de elementos de datos grandes, persistentes e interconectados, no
dudes en almacenarlos en una base de datos relacional. En el pasado los Sistemas de Administracin de Bases de
Datos Relacionales (RDBMS, por sus siglas en ingls) solan ser caros, escasos, complejos y unas bestias

indomables. Ya no es el caso. Hoy en da los RDBMS son fciles de encontrar, lo ms probable es que el sistema que
ests usando ya tenga uno o dos instalados. Algunos RDBMS muy capaces, como MySQL y PostgreSQL, estn
disponibles como software libre, por lo que el costo de compra ya no es un tema. An mejor, los llamados sistemas
de bases de datos embebidos se pueden vincular como bibliotecas directamente en tu aplicacin, requiriendo casi
ninguna configuracin o administracin; dos notables proyectos de software libre son SQLite y HSQLDB. Estos
sistemas son extremadamente eficientes.
Si los datos de tu aplicacin son ms grandes que la RAM del sistema, una tabla indexada del RBDMS tendr un
rendimiento de rdenes de magnitud ms rpida que la coleccin de mapas de tu biblioteca, que gastar pginas de
memoria virtual. Los productos de bases de datos modernos pueden crecer fcilmente con tus necesidades. Con el
cuidado adecuado, puedes ampliar una base de datos embebida a un sistema ms grande cuando sea requerido.
Despus, puedes cambiar de un producto de software libre a uno mejor soportado o un sistema propietario ms
poderoso.
Una vez que sepas los trucos de SQL, la creacin de aplicaciones centradas en bases de datos es una alegra.
Despus de que hayas almacenado tus datos correctamente normalizados en la base de datos es fcil extraer
eficientemente los hechos con una consulta SQL legible; no hay necesidad de escribir ningn cdigo complejo. Un
solo comando SQL puede realizar cambios de datos complejos. Para modificaciones nicas, digamos, un cambio en
la forma en que organizas los datos, ni siquiera necesitas escribir cdigo: slo lanza la interface directa de SQL. Esta
misma interface tambin te permite experimentar con consultas, dejando a un lado el ciclo de compilacin-edicin de
un lenguaje de programacin regular.
Otra de las ventajas de basar tu cdigo en un RDBMS implica manejar las relaciones entre los elementos de tus
datos. Puedes describir las limitaciones de consistencia en los datos en una manera declarativa, evitando el riesgo de
que los apuntadores se cuelguen si olvidas actualizar los datos en un caso extremo. Por ejemplo, puedes especificar
que en caso de que un usuario sea eliminado, entonces los mensajes enviados por ese usuario deberan ser
eliminados tambin.
Tambin puedes crear enlaces eficientes entre tus entidades almacenadas en la base de datos en el momento que lo
desees, simplemente creando un ndice. No hay necesidad de realizar caras y extensas refactorizaciones de campos
de clases. Adems, codificar en torno a una base de datos permite que varias aplicaciones accedan a tus datos en
manera segura. Esto hace fcil actualizar tu aplicacin para el uso concurrente y tambin permite codificar cada parte
de tu aplicacin usando el lenguaje y plataforma ms adecuada. Por ejemplo, puedes escribir el back-end XML de
una aplicacin web en Java, algunos scripts de autora en Ruby y una interfaz de visualizacin en Processing.
Finalmente, recuerda que el RDBMS sudar duro para optimizar los comandos SQL, lo que te permitir concentrarte
en la funcionalidad de tu aplicacin en vez de la refinacin de algoritmos. Los sistemas avanzados de bases de datos
incluso tomarn ventaja de los procesadores multi-core a tus espaldas. Y, conforme la tecnologa mejora, tambin el
rendimiento de tu aplicacin

Deja que tu proyecto hable por s mismo

Autor: Daniel Lindner

Tu proyecto probablemente tenga un sistema de control de versiones . Quizs est conectado a un servidor de
Integracin Continua que verifica la correctitud por medio de pruebas automatizadas. Eso es genial.
Puedes incluir herramientas para el anlisis esttico de cdigo en tu servidor de Integracin Continua y as recopilar
mtricas de cdigo. Estas mtricas proveen retroalimentacin sobre aspectos especficos, as como la evolucin en el
tiempo. Al instalar mtricas de cdigo, siempre habr una lnea roja que no querrs cruzar. Supongamos que inicias
con un 20% de cobertura de pruebas y nunca caes por debajo del 15%. La Integracin Continua ayuda a mantener
un registro de todos estos nmeros, pero todava tienes que revisarlos regularmente. Imagina que puedes delegar
estas tareas al proyecto mismo y confiarle el reportar cuando las cosas se ponen peor.
Necesitas darle a tu proyecto una voz. Esto puede ser realizado por email o mensajera instantnea, informando a los
desarrolladores sobre la ltima cada o mejora en los nmeros. Pero esto es incluso ms efectivo de llevar usando un
Dispositivo de Retroalimentacin Extrema (XFD, por sus siglas en ingls, Extreme Feedback Device).
La idea del XFD es manejar un dispositivo fsico como una lmpara, una fuente porttil, un robot de juguete o incluso
un lanza cohetes USB, basado en el resultado del anlisis automtico. Cada vez que tus lmites se rompan, el
instrumento altera su estado. En el caso de la lmpara, sta se enciende, brillante y clara. No puedes olvidar el
mensaje, incluso si ests cruzando la puerta para irte a casa.
Dependiendo del tipo de dispositivo de retroalimentacin extrema, puedes or la ruptura del compilado, ver las
seales rojas de advertencia en tu cdigo, incluso oler tu cdigo. Los instrumentos pueden ser replicados en distintos
lugares si trabajas en un equipo distribuido. Puedes colocar un semforo en la oficina de tu director de proyecto,
indicando el estado general de salud. El director del proyecto te lo agradecer.
Deja que tu creatividad te gue al escoger el dispositivo apropiado. Si tu cultura es bastante geek, podras buscar la
manera de equipar a la mascota de tu equipo con juguetes de radio control. Si deseas una apariencia ms
profesional, invierte en lmparas ms estilizadas. Busca ms inspiracin en Internet. Cualquier cosa con un enchufe
de alimentacin o un control remoto tiene el potencial de ser usado como un dispositivo de retroalimentacin extrema.
El dispositivo de retroalimentacin extrema acta como la caja de voz de tu proyecto. El proyecto ahora se encuentra
fsicamente con los desarrolladores, quejndose o alabando, de acuerdo a las reglas que el equipo haya escogido.
Puedes llevar esta personificacin ms all aplicando software de sntesis de voz y un par de altavoces. Ahora tu
proyecto realmente habla por s mismo.

El diseo del cdigo s importa

Autor: Steve Freeman

Hace muchos aos trabajaba en un sistema en Cobol, en el cual no se le permita al personal cambiar la sangra a
menos que tuvieran una razn para cambiar el cdigo, debido a que alguien, alguna vez, descompuso algo al dejar
un trozo de lnea en una de las columnas especiales al inicio de una lnea. Esto aplicaba incluso si el diseo estaba

equivocado, lo cual suceda algunas veces, as que tenamos que leer el cdigo muy cuidadosamente porque no
podamos confiar en l. La poltica debi costar una fortuna en friccin de programador.
Hay una investigacin que muestra que todos pasamos ms de nuestro tiempo de programacin navegando y
leyendo cdigo encontrando dnde hacer el cambio que escribiendo, as que esto es lo que queremos optimizar.

Fcil de escanear. La gente es buena en la comparacin de patrones visuales (una reminiscencia de la poca
en la que tenamos que observar leones en la sabana), as que puedo ayudarme al hacer todo lo que no es
directamente relevante al dominio, toda la complejidad accidental que viene con muchos lenguajes
comerciales, ocultarlo en el fondo de pantalla para estandarizarlo. Si el cdigo que se comporta igual luce igual,
entonces mi sistema perceptual me ayudar a escoger las diferencias. Es por eso que tambin observo las
convenciones sobre cmo disear las partes de una clase dentro de una unidad de compilacin: constantes,
campos, mtodos pblicos, mtodos privados.

Diseo expresivo. Todos hemos aprendido que toma su tiempo encontrar los nombres adecuados para que
nuestro cdigo exprese, tan claramente como es posible, lo que hace; en lugar de slo listar los pasos, est
bien? El diseo de cdigo tambin es parte de esta expresividad. Un primer corte es tener el acuerdo del equipo
en un formateo automtico para lo bsico, entonces podemos hacer ajustes manuales mientras estamos
codificando. A menos que haya un disensin activa, el equipo converger rpidamente en un estilo de acabado
manual comn. Un formateador no puede entender mis intenciones (debera saberlo, una vez codifiqu uno), y
es ms importante para m que los saltos de lnea y los agrupadores reflejen la intencin de mi cdigo, no slo
la sintaxis del lenguaje (Ken McGuire me liber de mi esclavitud a los formateadores automticos de cdigo).

Formato compacto. Mientras ms puedo conseguir en una pantalla, ms puedo ver si se rompe el contexto al
desplazarme o al cambiar de archivo, lo que significa que puedo dejar menos estados en mi cabeza. Los
comentarios del procedimiento largos y los espacios en blanco tienen sentido para nombres de 8 caracteres e
impresoras, pero ahora vivo en un IDE que hace el coloreo de sintaxis y el enlace cruzado. Los pixeles son mi
factor limitante, as que quiero que cada uno contribuya hacia mi entendimiento del cdigo. Quiero que el diseo
me ayude a entender el cdigo, pero no ms que eso.

Un amigo no programador coment alguna vez que el cdigo se parece a la poesa. Tengo esa sensacin en el
cdigo bueno, que todo en el texto tiene un propsito y est ah para ayudarme a entender la idea.
Desafortunadamente, escribir cdigo no tiene la misma imagen romntica que escribir poesa.

Distingue excepciones de Negocio de las excepciones Tcnicas

Autor: Dan Bergh Johnsson

Hay bsicamente dos razones por las que las cosas van mal en tiempo de ejecucin: problemas tcnicos que
impiden el uso de la aplicacin y la lgica del negocio que evita hacer mal uso de la aplicacin. La mayora de los
lenguajes modernos, como LISP, Java, Smalltalk y C#, usan excepciones para sealar ambas situaciones. Sin
embargo, las dos situaciones son tan diferentes que deberan ser tomadas por separado. Es una fuente potencial de

confusin representar ambas usando la misma jerarqua de excepciones, sin mencionar la misma clase de
excepciones.
Un problema tcnico irresoluble puede ocurrir cuando hay un error de programacin. Por ejemplo, si tratas de
acceder al elemento 83 de una matriz de tamao 17, entonces el programa est claramente fuera de control, y
debera resultar en alguna excepcin. La versin ms sutil es llamar a alguna biblioteca de cdigo con argumentos
inapropiados, causando la misma situacin dentro de la biblioteca.
Sera un error intentar resolver t mismo estas situaciones que causaste. En vez de dejar que la excepcin se eleve
al nivel arquitectnico ms alto y dejar que algn mecanismo general de manejo de excepciones haga lo que pueda
para asegurar que el sistema est en un estado seguro, tales como deshacer una transaccin, registrar en la bitcora
y alertar a la gerencia, e informar (educadamente) al usuario.
Una variante de esta situacin es cuando te encuentras en la situacin de biblioteca y quien hace el llamado rompi
el contrato de tu mtodo, por ejemplo, pasando un argumento extrao o sin tener un objeto dependiente configurado
correctamente. Esto va a la par con el acceso al 83vo elemento de 17: quien hace la llamada debera haber
comprobado; no hacerlo es un error del programador en el lado del cliente. La respuesta correcta es lanzar una
excepcin tcnica.
Una diferente, pero an situacin tcnica, es cuando el programa no puede continuar debido a un problema en el
ambiente de produccin, como una base de datos que no responde. En esta situacin debes asumir que la
infraestructura hizo lo que pudo para resolver la situacin reparar conexiones, reintentar un nmero razonable de
veces y fall. Incluso si la causa es diferente, la situacin para el cdigo es similar: hay poco que puedas al
respecto. As que sealamos la situacin a travs de una excepcin que subiremos hacia un mecanismo general de
manejo de excepciones.
En contraste a esas situaciones, tenemos la situacin en la cual no puedes completar la llamada por una razn de
dominio lgico. En este caso nos hemos encontrado una situacin que es una excepcin, es decir, una inusual e
indeseable, pero no un error extrao o programtico. Por ejemplo, tratar de retirar dinero de una cuenta con fondos
insuficientes. En otras palabras, este tipo de situaciones es una parte del contrato, y lanzar una excepcin es slo
una va de retorno alternativa que es parte del modelo y que el cliente debera tener en cuenta y estar preparado para
manejarlo. Para estas situaciones es apropiado crear una excepcin especfica o una jerarqua de excepcin por
separado, as el cliente puede manejar la situacin en sus propios trminos.
Mezclar excepciones tcnicas y excepciones de negocios en la misma jerarqua desdibuja la distincin y confunde a
quien hace la llamada sobre qu mtodo del contrato es, qu condiciones se requiere asegurar antes de ejecutarlas y
qu situaciones se supone debe manejar. Separar los casos ofrece claridad e incrementa la oportunidad de que las
excepciones tcnicas sean manejadas por algn framework de aplicaciones, mientras que las excepciones de
dominio del negocio son consideradas y manejadas por el cdigo del cliente.

Dos cabezas son a menudo mejores que una

Autor: Adrian Wible

La programacin requiere pensamiento profundo, y los pensamientos profundos requieren soledad. As va el

estereotipo del programador.
Este enfoque de lobo solitario de la programacin est dando paso a un enfoque colaborativo, el cul, puedo decir,
mejora la calidad, productividad y satisfaccin laboral de los programadores. Este enfoque tiene a los desarrolladores
trabajando ms cerca entre s y tambin con los no desarrolladores analistas de negocio y sistemas, profesionales
de control de calidad y usuarios.
Qu significa esto para los desarrolladores? Ser el experto tcnico ya no es suficiente. Debes ser ms efectivo
trabajando con otros.
La colaboracin no se trata de preguntar y responder, o sentarse en reuniones. Se trata de arremangarse con alguien
ms para atacar conjuntamente el trabajo.
Soy un gran admirador de la programacin en pareja. Puedes llamar a esto colaboracin extrema. Como
desarrollador, mis habilidades crecen cuando hago pareja. Si soy ms dbil que mi compaero en el dominio o
tecnologa, claramente aprendo de su experiencia. Cuando soy ms fuerte en algn aspecto, aprendo ms sobre lo
que conozco y no conozco al tener que explicarme. Invariablemente, ambos traemos algo a la mesa y aprendemos
mutuamente.
En pareja, cada uno de nosotros llevamos nuestras experiencias de programacin colectiva tanto de dominio como
tcnica al problema en cuestin y podemos aportar agudeza y experiencias nicas al escribir software efectiva y
eficientemente. Incluso en caso de desequilibrio extremo en el dominio o conocimiento tcnico, el participante ms
experimentado invariablemente aprende algo del otro quizs un nuevo atajo del teclado o exposicin a una nueva
herramienta o biblioteca. Para los miembros menos experimentados del par, es una gran manera de ponerse al da.
La programacin en pareja es popular con, pero no exclusivamente a, promotores del desarrollo gil del software.
Alguien que se opone a la pareja sugiere: porqu debera pagar a dos programadores para hacer el trabajo de
uno?. Mi respuesta es que, en efecto, no debera. Argumento que el emparejamiento incrementa la calidad, el
entendimiento del dominio y tecnologa, tcnicas (como los trucos del IDE) y mitiga el impacto del riesgo de lotera
(uno de tus desarrolladores expertos se gana la lotera y renuncia al siguiente da).
Cul es el valor a largo plazo de aprender un nuevo atajo del teclado? Cmo medimos la mejora global de la
calidad del producto resultante del emparejamiento? Cmo medimos el impacto de que tu compaero no te permita
adoptar un enfoque sin salida en la solucin de un problema difcil? Un estudio cita un incremento del 40% en eficacia
y velocidad (J T Nosek, The Case for Collaborative Programming, Communications of the ACM, Marzo de 1998).
Cul es el valor de mitigar tu lotera de riesgo? Muchas de estas ganancias son difciles de medir.
Quin debera hacer pareja con quin? Si eres nuevo, es importante encontrar un miembro del equipo que tenga
conocimientos. Tan importante como encontrar quien tenga buenas habilidades interpersonales y de entrenador. Si no
tienes mucha experiencia del dominio, emparjate con un experto.
Si no ests convencido, experimenta: colabora con tus colegas. Haz pareja en un problema retorcido e interesante.
Ve cmo se siente. Intntalo unas cuantas veces.

Dos fallos pueden hacer un acierto (y es difcil de arreglar)

Autor: Allan Kelly

El cdigo nunca miente, pero puede contradecirse. Algunas contradicciones llevan a esos momentos de: cmo es
posible que esto funcione?.
En una entrevista, el diseador principal del software del mdulo lunar Apolo 11, Allan Klumpp, revel que el software
que controlaba los motores tena un error que haca el mdulo de aterrizaje inestable. Sin embargo, otro error fue
compensado por el primero y el software fue usado por los aterrizajes lunares del Apolo 11 y 12 antes de que el error
fuera encontrado y arreglado.
Considera una funcin que retorna un estatus de finalizacin. Imagina que retorna false cuando debera regresar
un true . Ahora imagina que la llamada de funcin olvida comprobar el valor de retorno. Todo funciona bien hasta que
un da alguien nota la falta de verificacin y la inserta.
O considera una aplicacin que almacena su estado en un documento XML. Imagina que uno de los nodos est
escrito incorrectamente como TimeToLive en vez de TimeToDie, como la documentacin dice que debera. Todo
parece estar bien mientras el cdigo de escritura y el cdigo de lectura contienen ambos el mismo error. Pero arregla
uno, o agrega una nueva aplicacin de lectura del mismo documento, y la simetra se rompe, al igual que el cdigo.
Cuando dos defectos en el cdigo crean un defecto visible, el enfoque metodolgico para arreglar la falla puede, por
s mismo, romperlo. El desarrollador recibe un reporte de error, encuentra el defecto, lo arregla y lo vuelve a probar.
Sin embargo, el fallo reportado an ocurre, debido a que un segundo defecto est en funcionamiento. As que el
primer arreglo se quita, el cdigo es inspeccionado hasta que el segundo defecto es encontrado, y un arreglo se
aplica. Pero el primer defecto ha regresado, el fallo reportado an se ve, as que se deshace el segundo arreglo. El
proceso se repite, pero ahora el desarrollador ha desestimado dos posibles soluciones y est buscando una tercera,
que nunca va a funcionar.
La interaccin entre dos defectos de cdigo que aparecen como un defecto visible no slo hace difcil arreglar el
problema, adems, lleva a los desarrolladores a callejones sin salida, slo para descubrir que intentaron la respuesta
correcta desde el inicio.
Esto no pasa slo en el cdigo: el problema tambin existe en los documentos de requerimientos escritos. Y puede
extenderse, viralmente, de un lugar a otro. Un error en el cdigo compensa un error en la descripcin escrita.
Puede extenderse a la gente tambin: los usuarios aprenden que cuando la aplicacin dice Izquierda se refiere a la
Derecha, as que ajustan su comportamiento, incluso lo pasan al nuevo usuario: recuerda que la aplicacin dice
que hagas clic al botn izquierdo cuando realmente se refiere al botn derecho. Arregla ese error y, de repente, los
usuarios necesitan reentrenamiento.

Fallos sencillos pueden ser fciles de ver y de arreglar. Son los problemas con mltiples causas, que necesitan
mltiples cambios, los que son difciles de resolver. En parte es porque los problemas fciles tienden a ser arreglarlos
con relativa rapidez y se quedan los ms difciles para una fecha posterior.
No hay un consejo simple que se pueda dar en cmo localizar fallos surgidos de defectos simpatticos. Es necesario
darse cuenta de la posibilidad, una cabeza clara y voluntad de considerar todas las posibilidades.

Lenguajes Especficos del Dominio (DSL)

Autor: Michael Hunger

Cada vez que escuches una discusin de expertos de cualquier dominio, ya sean jugadores de ajedrez, maestros de
jardn de nios o agentes de seguros, notars que su vocabulario es un poco diferente del lenguaje diario. Es parte
de los Lenguajes Especficos del Dominio (DSL). Un dominio especfico tiene un vocabulario especializado para
describir cosas que son particulares de ese dominio.
En el mundo del software, los DSL tratan sobre expresiones ejecutables en un lenguaje especfico de un dominio con
un limitado vocabulario y gramtica que es legible, entendible y afortunadamente escribible por expertos del
dominio. Los DSL dirigidos a desarrolladores de software o cientficos han estado por aqu desde hace un largo
tiempo. Por ejemplo, el pequeo lenguaje de Unix encontrado en archivos de configuracin y los lenguajes creados
con el poder de macros de LISP son de los ms viejos ejemplos.
Los DSL son comnmente clasificados como internos o externos:

Los DSL internos son escritos en un lenguaje de programacin de propsito general, cuya sintaxis se ha
inclinado a parecerse ms al lenguaje natural. Es ms fcil para los lenguajes que ofrecen azcar sintctica y
posibilidades de formato (ej. Ruby y Scala) que para otros que no lo hacen (ej. Java). Muchos DSL internos
envuelven API existentes, bibliotecas o cdigo de negocio para proveer un contenedor con un acceso ms
alucinante a sus funcionalidades. Son ejecutados con slo correrlos. Dependiendo en la implementacin y el
dominio, son usados para construir estructuras de datos, definir dependencias, ejecutar procesos o tareas,
comunicarse con otros sistemas o validar entradas de usuario. La sintaxis de un DSL interno estn contenidas
en el lenguaje anfitrin. Hay muchos patrones por ejemplo, constructores de expresiones, encadenadores de
mtodos y anotaciones que pueden ayudarte a doblar el lenguaje anfitrin de tu DSL. Si el lenguaje anfitrin no
requiere recompilacin, entonces un DSL interno puede ser desarrollado rpidamente trabajando lado a lado
con los expertos del dominio.

Los DSL externos son expresiones grficas o textuales de un lenguaje, aunque los DSL textuales tienden a
ser ms comunes que los grficos. Las expresiones textuales pueden ser procesadas por una cadena de
herramientas que incluyen lxico, un analizador, un transformador de modelo, generadores, y cualquier otro tipo
de posprocesamiento. Los DSL externos son frecuentemente ledos en modelos internos, los cuales forman los
fundamentos para su posterior procesamiento. Es til definir una gramtica (por ejemplo, en EBNF). Una
gramtica provee un punto de partida para la generacin de partes de la cadena de herramientas (por ejemplo,

editor, visualizador, generador de analizadores). Para los DSL sencillos, un analizador hecho a mano podra ser
suficiente; usando, por ejemplo, expresiones regulares. Los analizadores personalizados pueden llegar a ser
difciles de manejar si se espera mucho de ellos, as que tiene sentido mirar las herramientas diseadas
especficamente para trabajar con gramticas del lenguaje; por ejemplo, openArchitectureWare, ANTlr, SableCC
y AndroMDA. Es tambin comn el definir DSL externos como los dialectos XML, aunque la legibilidad es
frecuentemente un problema; sobre todo para los lectores no tcnicos.
Siempre debes tomar en cuenta la audiencia objetivo de tu DSL. Son desarrolladores, administradores, clientes de
negocio o usuarios finales? Tienes que adaptar el nivel tcnico del lenguaje, las herramientas disponibles, ayuda de
sintaxis (por ejemplo, intellisense), validacin temprana, visualizacin y representacin a tu audiencia prevista. Al
ocultar detalles tcnicos, los DSL pueden empoderar a los usuarios, dndoles la habilidad para adaptar los sistemas
a sus necesidades sin requerir la ayuda de los desarrolladores. Tambin puede acelerar el desarrollo debido al
potencial de distribucin de trabajo despus de que el framework inicial est en su sitio. El lenguaje puede
evolucionar gradualmente. Hay tambin disponibles diferentes rutas de migracin para expresiones existentes y
gramtica.

El mito del Gur

Autor: Ryan Brush

Cualquiera que haya trabajado en el software el tiempo suficiente ha escuchado preguntas como stas: estoy
obteniendo una excepcin XYZ. Sabes cul es el problema?.
Aquellos que hacen la pregunta rara vez se molestan en incluir la pila de rastreo, registros de error o algn contexto
que nos conduzca al problema. Al parecer creen que operas en un plano distinto, que las soluciones se te aparecen
sin ningn anlisis basado en evidencia. Piensan que eres un gur.
Esperamos dichas preguntas de quienes no tienen familiaridad con el software: para ellos los sistemas pueden verse
como algo mgico. Lo que me preocupa es estar viendo esto en la comunidad del software. Preguntas similares
surgen en el diseo de programas, tales como: estoy construyendo un gestor de inventarios. Debo utilizar el
bloqueo optimista?. Irnicamente, la gente que hace la pregunta est mejor calificada para resolverla que el
destinatario. Los interrogadores presumiblemente conocen el contexto, los requisitos y pueden leer acerca de las
ventajas y desventajas de las diferentes estrategias. Sin embargo, esperan que les des una respuesta inteligente sin
un contexto. Esperan magia.
Es tiempo de que la industria del software disipe este mito del gur. Los gurs son humanos. Ellos aplican la lgica
y el anlisis sistemtico de los problemas, como el resto de nosotros. Aprovechan los atajos mentales y la intuicin.
Considera al mejor programador que hayas conocido: en algn momento esa persona saba menos acerca del
software de lo que t ahora mismo. Si alguien parece ser un gur, es debido a sus aos dedicados al aprendizaje y al
perfeccionamiento de los procesos de pensamiento. Un gur es simplemente una persona inteligente con curiosidad
incesante.

Por supuesto, sigue habiendo una gran variabilidad en la aptitud natural. Muchos hackers son ms inteligentes,
informados y productivos de lo que alguna da puedo llegar a ser. Aun as, el desmitificar el mito del gur tiene un
impacto positivo. Por ejemplo, si trabajo con una persona ms inteligente que yo, me aseguro de hacer el trabajo de
campo, proveer el suficiente contexto para que esa persona pueda aplicar eficazmente sus habilidades. Quitar el mito
del gur tambin significa eliminar una barrera en la percepcin de mejora. En vez de una barrera mgica, veo
continuidad y puedo avanzar.
Por ltimo, uno de los mayores obstculos en el software es la gente inteligente que propaga el mito del gur a
propsito. Esto podra hacerse por ego, o como una estrategia para incrementar el valor percibido por un cliente o por
su empleador. Irnicamente, esta actitud puede hacer que las personas inteligentes sean menos valiosas debido a
que no contribuyen al crecimiento de sus compaeros. No necesitamos gurs. Necesitamos expertos que estn
dispuestos a desarrollar a otros expertos en su campo. Hay espacio para todos nosotros.
El Programador Profesional
Autor: Uncle Bob
Qu es un programador profesional?
El rasgo ms importante de un programador profesional es la responsabilidad personal. Los programadores
profesionales se responsabilizan por su carrera, sus estimaciones, el compromiso con su agenda, sus errores y su
mano de obra. Un programador profesional no le pasa la responsabilidad a los dems.

Si eres profesional, entonces eres responsable de tu propia carrera. Eres responsable de leer y aprender. Eres
responsable de mantenerte actualizado con la industria y la tecnologa. Muchos programadores piensan que es
trabajo de sus patrones entrenarlos. Lo siento, estn tremendamente equivocados. Crees que los mdicos se
comportan de esa manera? Crees que los abogados se comportan de esa manera? No, ellos se entrenan en su
propio horario, y con su propio dinero. Ellos gastan muchas de sus horas libres leyendo revistas y tomando
decisiones. Se mantienen al da. Y as debemos hacerlo nosotros. La relacin entre t y tu empleador est escrita
claramente en tu contrato. En breve: prometen pagarte y t prometes hacer un buen trabajo.
Los profesionales asumen la responsabilidad del cdigo que escriben. No liberan cdigo a menos que sepan que
funciona. Piensa en esto por un minuto. Cmo puedes considerar llamarte profesional, si ests esperando liberar
cdigo del cul no ests seguro? Los programadores profesionales esperan que QA no encuentre algo porque no
liberan su cdigo hasta que se ha probado completamente. Por supuesto, QA encontrar algunos problemas, debido
a que nadie es perfecto. Pero, como profesionales, nuestra actitud debe ser: dejar nada para QA.
Los profesionales son jugadores de equipo. Asumen responsabilidad de la salida de todo el equipo, no slo de su
propio trabajo. Se ayudan unos a otros, ensean a los dems, aprenden unos de otros e, incluso, cubren a los
dems, si es necesario. Cuando un compaero cae, los dems intervienen, sabiendo que algn da ellos van a ser
los que necesiten cobertura.
Los profesionales no toleran grandes listas de errores. Tener una lista as es ser descuidado. Los sistemas con
cientos de issues en la base de datos de seguimiento de problemas son tragedias por la falta de cuidado. De hecho,

en muchos proyectos, la propia necesidad de un sistema de seguimiento de problemas es un sntoma de descuido.

Slo los sistemas muy grandes deberan tener una lista de errores tan larga que sea necesario la automatizacin
para manejarla.
Los profesionales no hacen un desastre. Se enorgullecen de su mano de obra. Mantienen el cdigo limpio, bien
estructurado y fcil de leer. Siguen estndares acordados y las mejores prcticas. Ellos nunca, jams se apresuran.
Imagina que ests teniendo una experiencia fuera de tu cuerpo y miras a un cirujano realizar una ciruga a corazn
abierto en ti. Este mdico tiene un hora lmite (en sentido literal). Debe terminar antes de que la mquina de
derivacin corazn-pulmn dae muchas de las clulas sanguneas. Cmo quieres que se comporte? Quieres que
se comporte como el tpico desarrollador de software, apresurado y haciendo un lo? Quieres que diga: regreso y lo
arreglo luego? O quieres que se aferre cuidadosamente a sus disciplinas, tomndose su tiempo, seguro de que su
enfoque es el mejor? Quieres un desastre o profesionalidad?
Los profesionales son responsables. Asumen la responsabilidad por sus propias carreras. Asumen la responsabilidad
de asegurarse de que su cdigo funciona correctamente. Asumen la responsabilidad de la calidad de su mano de
obra. No abandonan sus principios cuando los plazos se ciernen. De hecho, cuando la presin aumenta, los
profesionales se aferran a las disciplinas que saben que son correctas.
El trabajo duro no paga
Autor: Olve Maudal
Como programador, trabajar duro muchas veces no da frutos. Puedes engaarte a ti mismo y a unos pocos colegas
al creer que ests contribuyendo mucho al proyecto al pasar largas horas en la oficina. Pero, la verdad, es que
trabajando menos puedes lograr ms, a veces mucho ms. Si tratas de estar centrado y ser productivo por ms de
treinta horas a la semana, entonces probablemente ests trabajando demasiado duro. Debes considerar reducir la
carga de trabajo para ser ms eficaz y hacer ms cosas.

Esta frase puede parecer contraria a la intuicin e incluso controversial, pero es una consecuencia directa del hecho
de que la programacin y el desarrollo de software, en conjunto, implican un proceso de aprendizaje continuo. A
medida en que trabajas en un proyecto entenders ms sobre el dominio del problema y, con suerte, encontrars la
manera ms eficaz de alcanzar tu meta. Para evitar el desperdicio de trabajo, debes permitirte tiempo para observar
los efectos de lo que ests haciendo, reflexionar sobre las cosas que se ven y cambiar el comportamiento en
consecuencia.

La programacin profesional no suele ser como correr duro durante unos cuantos kilmetros, donde la meta puede
ser vista al final de un camino pavimentado. Muchos proyectos de software son ms como un largo maratn
orientado; en la oscuridad, con slo un mapa esquemtico como gua. Si acabas de salir hacia una direccin,
corriendo tan rpido como puedas, podras impresionar a algunos, pero no es probable que tengas xito. Necesitas
mantener un ritmo sostenido y ajustar el curso cuando se aprende ms sobre dnde te encuentras y hacia dnde te
diriges.

Adicionalmente, siempre necesitars aprender ms sobre el desarrollo de software, en general, y tcnicas de

programacin, en lo particular. Probablemente tengas que leer libros, ir a conferencias, comunicarte con otros
profesionales, experimentar con nuevas tcnicas de implementacin y aprender acerca de potentes herramientas que
simplificarn el trabajo. Como un programador profesional debes mantenerte actualizado en tu campo de
especializacin; al igual que se espera que los neurocirujanos y los pilotos se mantengan actualizados en sus propios
campos de experiencia. Necesitas pasar tardes, fines de semana y das festivos educndote, por lo tanto, no puedes
pasar tus tardes, fines de semana y das festivos trabajando tiempo extra en tu proyecto actual. Realmente esperas
que los neurocirujanos realicen cirugas 60 horas a la semana o que los pilotos vuelen 60 horas semanalmente? Por
supuesto que no, la preparacin y educacin son parte esencial de su profesin.

Enfcate en el proyecto, contribuye tanto como puedas encontrando soluciones inteligentes, mejora tus habilidades,
reflexiona sobre lo que ests haciendo y adapta tu comportamiento. Evitar avergonzarte, y a nuestra profesin, al
comportarte como un hmster en una jaula corriendo en la rueda. Como programador profesional debes saber que
tratar de estar concentrado y ser productivo 60 horas a la semana no es lo ms sensato. Acta como un profesional:
preprate, s eficaz, observa, reflexiona y cambia.
Encapsula Comportamiento, no slo Estado
Autor: Einar Landre
En la teora de sistemas, el contenimiento es uno de los ms tiles constructos cuando se est tratando con sistemas
de estructuras muy grandes y complejas. En la industria de software el valor del contenimiento o encapsulacin es
bien entendido.

Los mdulos y paquetes resuelven las necesidades a gran escala de la encapsulacin, mientras que las clases,
subrutinas y funciones resuelven los aspectos ms granulares en la materia. A travs de los aos he descubierto que
las clases parecen ser uno de los constructos de encapsulacin ms difciles que los desarrolladores entiendan. Es
comn encontrar una clase con slo un mtodo principal con 3 mil lneas de cdigo, o una clase con slo mtodo set
y get para sus atributos primitivos. Estos ejemplos demuestran que el desarrollador involucrado no ha entendido por
completo el pensamiento orientado a objetos, fallando en tomar ventaja del poder de los objetos como constructos de
modelaje. Para los desarrolladores familiarizados con los trminos POJO (Plain Old Java Object) y POCO (Plain Old
C# Object o Plain Old CLR Object), ste fue el intento para regresar a lo ms bsico de OO como el paradigma
modelo, los objetos son planos y sencillos, pero no tontos.

Un objeto encapsula ambos; estado y comportamiento, donde el comportamiento es definido por el estado actual.
Considera un objeto puerta. ste tiene 4 estados: cerrado, abierto, cerrando, abriendo. Ofrece dos operaciones: abrir
y cerrar. Dependiendo del estado, las operaciones de abrir y cerrar se comportarn de forma diferente. Esta
propiedad inherente de un objeto hace que el proceso de diseo conceptualmente simple. Esto se resume en dos

tareas sencillas: localizacin y delegacin de responsabilidad a los diferentes objetos, incluyendo los protocolos de la
interaccin entre objetos.

Cmo funciona en la prctica se ilustra mejor con un ejemplo. Digamos que tienes tres clases: Customer (Cliente),
Order (Orden) e Item. El objeto Customer es marcador de posicin natural para el lmite de crdito y las reglas de
validacin. Un objeto Order sabe sobre su Customer asociado, y su operacin addItem delega la validacin del
crdito actual llamando al mtodo Customer.validaCredito(item.precio()). Si la poscondicin del mtodo falla, una
excepcin puede ser enviada y la compra cancelada.

Los desarrolladores menos experimentados en orientacin a objetos podran decidirse a envolver todas las reglas de
negocio en un objeto frecuentemente referido como orderManager u OrderService. En este diseo, Order, Customer
e Item son tratados como algo ms que tipos de registros. Toda la lgica es factorizada desde las clases y unidas en
un mtodo largo y procedural con un montn de constructos internos if-the-else. Estos mtodos se rompen con
facilidad y son casi imposibles de mantener. La razn? La encapsulacin est rota.
As que, al final, no rompas la encapsulacin y usa el poder de tu lenguaje de programacin para mantenerla.

Escoge tus herramientas con cuidado

Autor: Giovanni Asproni
Las aplicaciones modernas rara vez son construidas desde cero. Se ensamblan usando herramientas existentes
componentes, bibliotecas y frameworks por una serie de buenas razones:

Las aplicaciones crecen en tamao, complejidad y sofisticacin, mientras el tiempo para desarrollarlas
decrece. Se hace un mejor uso del tiempo e inteligencia del desarrollador, si pueden concentrarse en escribir
ms cdigo del dominio del negocio y menos cdigo de infraestructura

Los componentes y frameworks ampliamente utilizados con frecuencia tienen menos errores que aquellos
desarrollados en casa.

Hay un montn de software de alta calidad disponible en la red de forma gratuita, lo cual significa menores
costos de desarrollo y mayor probabilidad de encontrar desarrolladores con el inters y experiencia necesaria.

La produccin y mantenimiento de software es un trabajo humanamente intensivo, por lo que comprarlo

podra ser ms barato que construirlo.

Sin embargo, escoger la mezcla completa de herramientas para tu aplicacin puede ser un negocio riesgoso que
requiere pensarlo un poco. De hecho, hay unas cuantas cosas que deberas tener en mente mientras ests haciendo
la eleccin:

Las diferentes herramientas pueden estar basadas en distintos supuestos sobre su contexto por ejemplo, la
infraestructura circundante, modelo de control, modelo de datos, protocolos de comunicacin, etctera lo cual
puede llevar a un diferencial de arquitectura entre la aplicacin y las herramientas. Dichas diferencias conducen
a hacks yworkarounds que harn el cdigo ms complejo de lo necesario.

Las diferentes herramientas tienen diferentes ciclos de vida, y actualizar una de ellas podra convertirse en
algo extremadamente difcil y una tarea que consume tiempo en cada nueva funcionalidad, cambios de diseo o
incluso correcciones de errores que podran causar incompatibilidades con las otras herramientas. Entre ms
grande sea el nmero de herramientas, peor es el problema en el que puede convertirse.

Algunas herramientas requieren configuraciones, lo que frecuentemente significa uno o ms archivos XML, lo
cual se sale de control muy rpido. La aplicacin puede terminar como si fuese escrita toda en XML ms unas
cuntas lneas de cdigo en algn lenguaje de programacin. La complejidad en la configuracin har la
aplicacin difcil de mantener y de extender.

Ocurre un vendor-lock cuando el cdigo que depende en gran medida en un proveedor especfico termina
siendo arriesgado por l en varias formas: mantenimiento, rendimiento, habilidad para evolucionar, precio, etc.

Si planeas usar software libre, puedes descubrir que no es tan libre despus de todo. Quizs necesites
comprar soporte comercial, lo cual no necesariamente va a ser barato.

Los trminos de licenciamiento importan, incluso para el software libre. Por ejemplo, en algunas compaas
no es aceptable usar software licenciado bajo los trminos de la licencia GNU, debido a su naturaleza viral, es
decir, el software desarrollado con l debe ser distribuido junto con su cdigo fuente.

Mi estrategia personal para mitigar estos problemas es comenzar poco a poco, usando slo las herramientas que son
absolutamente necesarias. Usualmente el enfoque inicial est en quitar la necesidad de participar en la programacin
(y los problemas) de infraestructura de bajo nivel, por ejemplo, usando algn middleware en vez de usar sockets para
aplicaciones distribuidas. Y entonces agregar ms si es necesario. Tambin tiendo a aislar las herramientas externas
de mis objetos de dominio del negocio con respecto a interfaces y capas de presentacin, as puedo cambiar la
herramienta, si lo tengo que hacer, con slo una pequea dosis de dolor. Un lado positivo de este enfoque es que
generalmente termino con una aplicacin ms pequea que usa menos herramientas externas de lo que
originalmente se pronostic.

Escribe cdigo como si tuvieras que mantenerlo por el resto de tu vida

Autor: Yuriy Zubarev
Puedes preguntarle a 97 personas lo que todo programador debera saber y hacer, y podrs escuchar 97 respuestas
distintas. Esto podra ser abrumador e intimidante al mismo tiempo. Todo consejo es bueno, todos los principios son
slidos y todas las historias son convincentes, pero por dnde empezar? Ms importante an, una vez que has

comenzado, cmo te mantienes al da con todas las mejores prcticas que has aprendido para hacer de ellas una
parte integral de tus prcticas de programacin?
Creo que la respuesta reside en tu estado de nimo o, ms claramente, en tu actitud. Si no te preocupas por tus
compaeros desarrolladores, testers, administradores, personal de venta y mercadotecnia, as como los usuarios
finales, entonces no estars dispuesto a emplear el Desarrollo basado en Pruebas (Test-Driven Development) o
escribir comentarios claros en tu cdigo, por ejemplo. Hay una manera sencilla de ajustar tu actitud y siempre estar
dispuesto a entregar productos de la mejor calidad::
Escribe cdigo como si tuvieras que mantenerlo por el resto de tu vida.
Eso es todo. Si aceptas esta idea, sucedern muchas cosas maravillosas. Si vas aceptar que ninguno de tus
empleadores previos o actuales tiene derecho a llamarte a la mitad de la noche pidindote que expliques las
decisiones que tomaste mientras escribas el mtodo fooBar, entonces deberas mejorar gradualmente para
convertirte en un programador experto. Naturalmente querras llegar a mejores nombres de variables y mtodos. Te
alejaras de bloques de cdigo que contienen cientos de lneas. Buscaras, aprenderas y usaras patrones de diseo.
Escribiras comentarios, probaras tu cdigo y refactoraras continuamente. Mantener todo el cdigo que has escrito
por el resto de tu vida ser tambin un esfuerzo escalable. Por lo tanto, no tendras ms opcin que convertirte en
alguien mejor, ms listo y ms eficiente.
Si lo reflexionas, el cdigo que escribiste hace muchos aos todava influye en tu carrera, te guste o no. Dejas un
rastro de tu conocimiento, actitud, tenacidad, profesionalismo, nivel de compromiso y grado de disfrute con cada
mtodo, clase y mdulo que diseas y escribes. La gente se formar opiniones de ti con base en el cdigo que ven.
Si esas opiniones son constantemente negativas, entonces obtendrs menos de tu carrera de lo que esperabas.
Preocpate por tu carrera, tus clientes y todos los usuarios con cada lnea de cdigo; escribe cdigo como si tuvieras
que mantenerlo por el resto de tu vida.

Escribe pequeas funciones usando ejemplos

Autor: Keith Braithwaite

Nos gustara escribir cdigo que fuese correcto y tener evidencia en mano de que es correcto. Puede ayudar con
ambos temas pensar en el tamao de una funcin. No en el sentido de la cantidad de cdigo que implementa una
funcin, a pesar de que es interesante; sino, ms bien, del tamao como una funcin matemtica que nuestro cdigo
manifiesta.
Por ejemplo, en el juego de Go hay una condicin llamada atari, en la cual la piedra del jugador puede ser capturada
por su oponente: una piedra con dos o ms espacios libres adyacentes a l (llamados liberties) no est en atari.
Puede ser difcil de contar cuntas liberties tiene una piedra, pero determinar el atari es fcil si se sabe. Podras
empezar escribiendo una funcin como esta:
boolean atari(int libertyCount) libertyCount < 2

Esto es ms grande de lo que parece. Una funcin matemtica puede ser entendida como un conjunto, algn
subconjunto del producto Cartesiano del conjunto que son su dominio (en este caso, un entero) y rango (en este
caso, un booleano). Si esos conjuntos de valores fueran del mismo tamao, como en Java, entonces
sera2L*(Integer.MAX_VALUE+(-1L*Integer.MIN_VALUE)+1L) o 8,589,934,592 miembros en el conjunto int
boolean. La mitad son miembros de un conjunto que es nuestra funcin, as que para proveer una evidencia completa
de que nuestra funcin es correcta necesitaramos revisar al rededor de 4.3 10 9 ejemplos.
sta es la esencia de la afirmacin de que las pruebas no pueden probar la ausencia de errores. Sin embargo, las
pruebas pueden demostrar la presencia de caractersticas. Pero an tenemos este tema del tamao.
El dominio del problema nos ayuda. La naturaleza de Go significa que el nmero de liberties de una piedra no es
cualquier entero, pero exactamente uno de {1,2,3,4}. As pues, podramos escribir alternativamente:
LibertyCount = {1,2,3,4} boolean atari(LibertyCount libertyCount)
libertyCount == 1
Esto es mucho ms manejable: la funcin calculada es ahora un conjunto con, cuando mucho, ocho miembros. De
hecho, cuatro ejemplos seleccionados constituiran la evidencia de la certeza completa de que la funcin es correcta.
sta es la razn por la cual es una buena idea usar tipos estrechamente relacionados al dominio del problema para
escribir programas, en vez de tipos nativos. Usar tipos inspirados en dominios a menudo puede hacer que nuestras
funciones sean mucho ms pequeas. Una forma de encontrar qu tipo sera es encontrar los ejemplos para
comprobar en trminos del dominio del problema, antes de escribir la funcin.

Escribe las pruebas para las personas

Autor: Gerard Meszaros
Ests escribiendo pruebas automatizadas para una parte o todo tu cdigo de produccin. Felicidades! Ests
escribiendo tus pruebas antes de que escribas el cdigo? Mucho mejor!! El slo hacerlo te convierte en uno de los
primeros adoptantes de las ms avanzadas prcticas de la ingeniera de software. Pero, ests escribiendo buenas
pruebas? Cmo saberlo? Una manera es preguntar: para quin estoy escribiendo estas pruebas?. Si la respuesta
es para m, para ahorrarme el esfuerzo de corregir errores o para el compilador, con eso puede ser ejecutado,
entonces las apuestas estn en que no ests escribiendo las mejores pruebas posibles. As que, para quin
deberas estar escribiendo las pruebas? Para las personas que tratan de entender tu cdigo.
Las buenas pruebas actan como documentacin para el cdigo que ests probando. Describen cmo funciona el
cdigo. Por cada escenario de uso la(s) prueba(s): Describe el contexto, un punto inicial o precondiciones que deben
ser satisfechas; ilustra cmo el software es invocado; describe los resultados esperados o poscondiciones a ser
verificadas.
Los diferentes escenarios de uso tendrn una versin distinta de cada una de ellas. Las personas que tratan de
entender tu cdigo deberan poder mirar unas cuantas pruebas y, al comparar estas tres partes de las pruebas en
cuestin, ver qu causa que el cdigo se comporte diferente. Cada prueba debera ilustrar claramente la relacin de

causa y efecto entre estas tres partes. Esto implica que lo que no es visible en las pruebas es tan importante como lo
que es visible. Mucho cdigo en las pruebas distrae al lector con trivialidades sin importancia. Cuando sea posible
oculta dichas trivialidades detrs de llamados a mtodos con significado; la refactorizacin Extraer Mtodo es tu
mejor amigo. Y asegrate de darle a cada prueba un nombre con significado que describa el escenario de uso
particular, con esto el lector de la prueba no tiene que hacer ingeniera inversa de cada prueba para entender de qu
se tratan los distintos escenarios. Entre ellos, el nombre de las clases de prueba y los mtodos de clases deben
incluir, al menos, el punto inicial y cmo el software est siendo invocado. Esto permite que la cobertura de prueba
sea verificada va un rpido escaneo de los nombres de los mtodos. Tambin puede ser til incluir los resultados
esperados en el nombre del mtodo de prueba, mientras esto no cause que el nombre sea demasiado largo para ver
o leer.
Tambin es buena idea poner a prueba tus pruebas. Puedes verificar que detectan el error al incluir dicho error en el
cdigo de produccin (por supuesto, en una copia privada que desechars). Asegrate que reporte los errores de
manera significativa. Tambin debes verificar que tus pruebas hablan claramente a una persona que trata de
entender tu cdigo. La nica manera de hacerlo es tener a alguien que no est familiarizado con tu cdigo para que
lea tus pruebas y te diga qu ha aprendido. Escucha cuidadosamente lo que te diga. Si no entendi algo no es
porque no sea muy brillante. Es ms probable que t no fueras muy claro. (Contina e invierte los roles, lee sus
pruebas!).

Evita errores
Autor: Giles Colborne
Los mensajes de error son la interaccin ms crtica entre el usuario y el resto del sistema. Suceden cuando la
comunicacin, entre el usuario y el sistema, est cerca del punto de quiebre.
Es fcil pensar que un error est siendo causado por una mala entrada de datos del usuario. Pero la gente comete
errores de forma predecible y sistemtica. As que es posible depurar la comunicacin entre el usuario y el resto del
sistema as como lo haras con otros componentes del sistema.
Por ejemplo, digamos que quieres que el usuario introduzca una fecha en un rango permitido. En vez de dejar que el
usuario introduzca cualquier fecha es mejor ofrecer un dispositivo, como una lista o calendario, mostrando slo las
fechas permitidas. Esto elimina cualquier oportunidad de que el usuario introduzca una fecha fuera del rango.
El formato del error es otro problema comn. Por ejemplo, si a un usuario se le presenta un campo de texto como
fecha e introduce una fecha ambigua como Julio 29, 2012 es razonable el rechazarlo simplemente porque no es uno
de los formatos preferidos (como DD/MM/AAAA). Es peor an rechazar 29 / 07 / 2012 slo porque contiene
espacios extra; este tipo de problema es particularmente difcil de entender para usuarios porque la fecha parece
estar en el formato deseado.
Este error ocurre porque es ms fcil rechazar una fecha que analizar los tres o cuatro formatos de fecha ms
comunes. Este tipo de errores insignificantes llevan al usuarios a la frustracin, que a su vez conduce a errores

adicionales conforme el usuario pierde su concentracin. En cambio, respeta las preferencias del usuario al entrar
informacin, no los datos.
Otra forma de evitar errores de formato es ofrecer seales, por ejemplo, con una etiqueta dentro del campo mostrar el
formato deseado (DD/MM/AAAA). Otra pista podra ser dividir el campo en tres cajas de texto de dos, dos y cuatro
caracteres.
Las seales son diferentes de las instrucciones: las seales tienden a ser indicios; las instrucciones son detalladas;
las seales ocurren en el punto de interaccin; las instrucciones aparecen antes del punto de interaccin. Las seales
proveen contexto; las instrucciones dictan el uso.
En general, las instrucciones son ineficientes para prevenir errores. Los usuarios tienden a asumir que las interfaces
trabajarn en la lnea con su pasada experiencia (seguramente todos saben el significado de Julio 29, 2012?). As
que las instruccin no son ledas. Las seales dan un suave codazo alejando a los usuarios del error.
Otra forma de evitar errores es ofrecer valores predeterminados. Por ejemplo, los usuarios tpicamente introducen
valores que corresponden al hoy, maana, mi cumpleaos, mi fecha lmite o la fecha que introduje la ltima vez que
us este formulario. Dependiendo del contexto, es probable que uno de ellos sea una buena opcin de un valor
predeterminado inteligente.
Sin importar la causa, los sistemas deberan ser tolerantes a errores. Puedes hacer esto proveyendo niveles mltiples
de deshacer para todas las acciones y en especial las acciones que tenga el potencial de destruir o enmendar los
datos del usuario.
El registro y anlisis de las acciones de deshacer puede tambin ser un punto a destacar, en el cual la interfaz est
atrayendo a los usuarios a errores inconscientes, tales como hacer clic persistentemente en un botn equivocado.
Estos errores son, a menudo, causados por seales engaosas o secuencias de interaccin que puedes redisear
para prevenir ms errores.
Cualquiera que sea el enfoque que tomes, la mayora de los errores son sistemticos, el resultado de malentendidos
entre el usuario y el software. Entender cmo los usuarios piensan, interpretan informacin, toman decisiones e
introducen datos, de entrada, te ayudar a depurar las interacciones entre el software y tus usuarios.

Haz lo invisible ms visible

Autor: Jon Jagger
Muchos aspectos de la invisibilidad son correctamente dichos como principios a usar. Nuestra terminologa es rica en
metforas de invisibilidad, mecanismos de transparencia y ocultamiento de informacin, para mencionar slo dos. El
software y el proceso de desarrollo pueden ser, para parafrasear a Douglas Adams, casi invisibles:

El cdigo fuente no tiene una innata presencia o comportamiento, y no obedece las leyes de la fsica. Es
visible cuando lo cargas en un editor, pero cierra el editor y se ha ido. Piensa sobre eso un rato y, como el rbol
cayendo cuando nadie lo escucha, empieza a preguntarte si en realidad existe.

Una aplicacin en ejecucin tiene presencia y comportamiento, pero no revela nada del cdigo fuente con el
que fue construido. La pgina principal de Google es placenteramente minimalista; lo que pasa detrs es lo
realmente sustancial.

Si has terminado el 90% y ests eternamente atorado tratando de debugear el ltimo 10% entonces no has
acabado el 90%, o s? Corregir errores no es progresar. No te pagan por debugear. El debugging es un
derroche. Es bueno hacer una prdida ms visible as puedes ver qu es y empezar a pensar en no crearla, en
primer lugar.

Si tu proyecto est aparentemente en camino y una semana despus est seis meses atrasado, tienes
problemas, el ms grande de ellos probablemente no sea que ests seis meses tarde, sino que el campo de
invisibilidad es lo suficientemente poderoso como para ocultar seis meses de retraso! La falta de progreso visible
es sinnimo de la falta de progreso.

La invisibilidad puede ser peligrosa. Piensas ms claramente cuando tienes algo concreto a qu amarrar tu
pensamiento. Administras mejor las cosas cuando puedes verlas y verlas cambiar constantemente:

Escribir pruebas unitarias provee evidencia sobre qu tan fcil es el cdigo unitario con respecto a la prueba
unitaria. Ayuda a revelar la presencia (o ausencia) de cualidades de desarrollo que te gustara que el cdigo
exhiba; cualidades como bajo acoplamiento y alta cohesin.

Ejecutar pruebas unitarias provee evidencia sobre el comportamiento del cdigo. Ayuda a revelar la presencia
(o ausencia) de cualidades en tiempo de ejecucin que te gustara que la aplicacin exhiba; cualidades como la
fortaleza y la correctitud.

El usar tableros de boletines y tarjetas hace el progreso ms visible y concreto. Las tareas pueden ser vistas
como No iniciadas, En progreso o Terminadas sin la referencia a una herramienta de administracin de
proyectos y sin tener que perseguir a los programadores para que entreguen reportes de estatus ficticios.

Realizar desarrollo incremental aumenta la visibilidad del progreso del desarrollo (o la falta de l) al
incrementar la frecuencia de la evidencia del desarrollo. El completar la liberacin del software revela realidad;
los estimados no.

Es mejor desarrollar software con una gran cantidad de evidencia visible habitual. La visibilidad otorga confianza de
que el progreso es genuino y no una ilusin, deliberado y no involuntario, repetible y no accidental.

Haz mucha prctica deliberada

Autor: Jon Jagger
La prctica deliberada no es simplemente realizar una tarea. Si te preguntas porqu estoy realizando esta tarea? y
tu respuesta es para completar la tarea, entonces no ests haciendo prctica deliberada.

Haces prctica deliberada para mejorar tu habilidad de realizar una tarea. Se trata de habilidad y tcnica. La prctica
deliberada significa repeticin. Significa realizar la tarea con el nimo de incrementar tu dominio de uno o ms
aspectos de la tarea. Significa repetir la repeticin. Lentamente, una y otra vez. Hasta lograr el nivel deseado de
dominio. Haces prctica deliberada para dominar la tarea, no para terminar la tarea.
El propsito principal de pagar a los desarrolladores es terminar un producto, mientras que el propsito de la prctica
deliberada es mejorar tu rendimiento. No es lo mismo. Pregntate: cunto tiempo inviertes desarrollando el producto
de alguien ms? Cunto desarrollndote?
Cunta prctica deliberada toma el adquirir experiencia?

Peter Norving escribe Puede que sean 10,000 horas [] es el nmero mgico.

En Leading Lean Software Development, Mary Poppendieck seala que: A los practicantes de elite les
toma un mnimo de 10 mil horas de prctica enfocada para convertirse en expertos.

La experiencia llega gradualmente con el tiempo, no toda en la hora 10 mil! Sin embargo, 10 mil horas es mucho:
cerca de 20 horas a la semana durante 10 aos. Dado este nivel de compromiso podras estar preocupado de no ser
material experto. Lo eres. La grandeza es, en gran medida, una cuestin de eleccin consciente. Tu eleccin. Las
investigaciones realizadas durante las dos ltimas dcadas han demostrado que el factor principal de adquisicin de
experiencia es el tiempo dedicado a realizar prctica deliberada. La habilidad innata no es el factor principal.

Mary: Hay un consenso general entre investigadores de rendimiento experto de que el talento natural no
cuenta ms que el esfuerzo; puedes tener una mnima cantidad de habilidad natural para iniciar en un deporte o
profesin. Despus de eso, la gente que es excelente es la que trabaja ms duro.

No tiene mucho sentido la prctica deliberada en algo ya eres un experto. La prctica deliberada significa practicar
algo en lo que no eres bueno.

Peter: La clave [para desarrollar experiencia] es la prctica deliberada: no slo hacindolo una y otra vez,
pero s retndote a ti mismo con una tarea que est ms all de tu capacidad actual, intentndolo, analizando tu
rendimiento mientras y despus de hacerlo, y corrigiendo cualquier error.

Mary: La prctica deliberada no significa hacer algo en lo que ya eres bueno; significa retarte a ti mismo,
haciendo algo en lo que no eres bueno. Esto no es necesariamente divertido.

La prctica deliberada es acerca del aprendizaje. Acerca del aprendizaje que te cambia; del aprendizaje que cambia
tu comportamiento. Buena suerte.

Las herramientas Unix son tus amigas

Autor: Diomidis Spinellis

Si en mi camino al exilio en una isla desierta tuviera que escoger entre un IDE y un conjunto de herramientas Unix, yo
escogera las herramientas Unix sin pensarlo dos veces. Aqu estn las razones por las cules deberas dominar las
herramientas Unix.
Primero, los IDE se enfocan en lenguajes especficos, mientras las herramientas Unix pueden trabajar con cualquier
cosa que aparezca en modo textual. En los ambientes de desarrollo de hoy en da, donde los nuevos lenguajes y
notaciones florecen cada ao, aprender a trabajar de la forma Unix es una inversin que se pagar con el tiempo una
y otra vez.
Adems, mientras los IDE ofrecen slo los comandos que sus desarrolladores concibieron, con las herramientas Unix
puedes realizar cualquier tarea imaginable. Piensa en ello como (los clsico pre- Binico) bloques Lego: creas tus
propios comandos combinando las pequeas pero verstiles herramientas Unix. Por ejemplo, la siguiente secuencia
es una implementacin basada en texto del anlisis de firmas de Cunningam; una secuencia de cada punto y coma,
llaves y comillas que puede revelar mucho sobre el contenido del archivo:
for i in *.java; do echo -n "$i: " sed 's/[^"{};]//g' $i | tr -d
'\n' echo done
En suma, cada operacin del IDE que aprendes es especfica a esa tarea; por ejemplo, agregar un nuevo paso de
depuracin en la configuracin de construccin del proyecto. En contraste, afilar tus habilidades con las herramientas
Unix te hace ms efectivo en cualquier tarea. Como un ejemplo, he empleado la herramienta sed en la secuencia de
comandos precedentes para modificar la construccin de un proyecto para la compilacin cruzada en mltiples
arquitecturas de procesador.
Las herramientas Unix fueron desarrolladas en una poca en la que una computadora multiusuario tena 128kB de
RAM. El ingenio que tuvo su diseo significa que en estos das pueden manejar enormes conjuntos de datos con
extremada eficiencia. La mayora de las herramientas trabajan como filtros, procesando slo una lnea a la vez,
significando que no hay lmite superior en la cantidad de datos que pueden manejar. Quieres buscar un nmero de
ediciones almacenadas en medio terabyte del respaldo de la Wikipedia en ingls? La simple invocacin de
grep '<revision>' | wc l
te dar la respuesta sin siquiera sudar. Si encuentras una secuencia de comandos til, puedes empacarla fcilmente
en un script de shell, usando algunos poderosos constructos de programacin, tales como hacer piping de datos en
ciclos y condicionales. Ms impresionante an, los comandos Unix ejecutados como pipelines, como el arriba
descrito, distribuir su carga con naturalidad a travs de las muchas unidades de procesamiento de los CPU multicore modernos.
Su gnesis en pequeo es bello y las implementaciones de software libre de las herramientas Unix las hacen
disponibles ubicuamente, incluso en plataformas de recursos restringidos, como mi reproductor multimedia de la sala
o el router DSL. Es poco probable que tales dispositivos ofrezcan una poderosa interface grfica, pero
frecuentemente incluyen la aplicacin BusyBox, la cual provee la mayora de las herramientas comnmente usadas. Y
si ests desarrollando en Windows, el ambiente cygwin te ofrece todas las herramientas Unix imaginables, en forma
de ejecutable y cdigo fuente.

Por ltimo, si ninguna de las herramientas disponibles se adecua a tus necesidades, es muy fcil extender el mundo
de las herramientas Unix. Slo escribe un programa (en cualquier lenguaje que elijas) que juegue con unas pocas y
sencillas reglas: tu programa debe realizar slo una tarea sencilla; debe leer datos como lneas de texto de su entrada
estndar y debe mostrar los resultados sin adornos, encabezados ni otros ruidos en su salida estndar. Los
parmetros que afectan la operacin de la herramienta se dan en la lnea de comandos. Sigue estas reglas y tuya
ser la Tierra y todo lo que hay en ella.

Implementa

rpido

con

frecuencia

Autor: Steve Berczuk

Depurar el proceso de implementacin e instalacin suele posponerse hasta que se
acerca el final del proyecto. En algunos proyectos, la escritura de herramientas de
instalacin es delegada a un ingeniero de entrega, quien asume la tarea como un mal
necesario. Las revisiones y demostraciones son realizadas a partir de un ambiente hecho
a mano para asegurarse de que todo funciona. El resultado es que el equipo no obtiene la
experiencia en el proceso de implementacin o sobre el ambiente de implementacin
hasta que quizs es demasiado tarde para hacer los cambios.
El proceso de instalacin/implementacin es lo primero que ve el cliente, y un proceso
simple de instalacin/implementacin es el primer paso para tener un ambiente de
produccin fiable (o, al menos, fcil de depurar). El software implementado es lo que el
cliente usar. El no garantizar que la implementacin configura la aplicacin
correctamente har que el cliente tenga preguntas antes de que use tu software
exhaustivamente.
Iniciar tu proyecto con un proceso de instalacin te dar tiempo para evolucionar el
proceso conforme se vaya moviendo en el ciclo de desarrollo del producto y la posibilidad
para realizar cambios al cdigo de la aplicacin para que la instalacin sea ms fcil.
Ejecutar y probar el proceso de instalacin en un ambiente limpio peridicamente tambin
provee un chequeo en el que no tendrs suposiciones en el cdigo que se base en los
ambientes de desarrollo o de prueba.
Poner la implementacin al ltimo significa que el proceso de implementacin puede
necesitar ser ms complicado para evitar las suposiciones en el cdigo. Lo que parece
una buena idea en un IDE, en el cual tienes el control total de un entorno, puede hacer
que un proceso de implementacin sea mucho ms complicado. Es mejor saber todas las
ventajas y desventajas ms temprano que tarde.
A pesar de que ser capaz de implementar desde el principio, no parece tener mucho
ms valor de negocio comparado con ver una aplicacin ejecutndose en la computadora
porttil del desarrollador, la verdad es que mientras no puedas demostrar tu aplicacin en

entorno final habr un montn de trabajo que hacer antes de que puedas ofrecer un valor
empresarial. Si el fundamento de poner en marcha el proceso de implementacin es que
es algo trivial, entonces hazlo de todos modos, ya que es a bajo costo. Si es demasiado
complicado, o si hay demasiadas incertidumbres, haz lo que haras con el cdigo de una
aplicacin: experimenta, evala y refactoriza el proceso de implementacin conforme
avances.
El proceso de instalacin/implementacin es esencial para la productividad de los clientes
o de su equipo de servicio profesionales, por lo que deberas hacer pruebas y refactorizar
este proceso sobre la marcha. Probamos y refactorizamos el cdigo fuente de todo el
proyecto. La implementacin no se merece menos.
Inicia con un S

Autor: Alex Miller

Recientemente fui a la tienda buscando arriba y abajo edaname (el cul slo saba vagamente que era algn tipo de
vegetal). No estaba seguro si era algo que podra encontrar en la seccin de vegetales, la seccin de congelados o
en enlatados. Me rend y busqu a una empleada para que me ayudara. Ella tampoco saba!
La empleada pudo haber respondido de muchas maneras distintas. Pudo haberme hecho sentir ignorante por no
saber dnde buscar, darme vagas posibilidades o simplemente decirme que no lo tenan. Pero en vez de ello, us el
pedido como una oportunidad de encontrar una solucin y ayudar al cliente. Llam a otro empleado y en minutos me
haban guiado al artculo deseado, ubicado en la seccin de congelados.
La empleada en este caso mir en un pedido e inici con la premisa de que debera resolver el problema y satisfacer
la peticin. Inici con un s, en vez de empezar con un no.
La primera vez que fui colocado en un rol de lder tcnico, sent que mi trabajo era proteger mi precioso software del
ridculo flujo de demandas de los gestores de producto y analistas de negocio. Iniciaba muchas conversaciones
viendo un pedido como algo que tena que vencer, no algo que deba conceder.
En cierto punto, tuve una epifana: quizs haba una manera distinta de trabajar al cambiar mi perspectiva de iniciar
con un no, iniciando con un s. De hecho, he empezado a creer que iniciar con un s es parte esencial de ser un lder
tecnolgico.
Este simple cambio radical alter el cmo abord mi trabajo. Como resultado, hay un montn de maneras de decir s.
Cuando alguien te dice: Hey, esta aplicacin sera mejor si hacemos todas las ventanas redondeadas y traslcidas,
puedes rechazarlo por ridculo. Pero frecuentemente es mejor iniciar con un por qu?. En primer lugar, usualmente
existe una actual e irresistible razn de por qu esa persona est pidiendo ventanas redondeadas y traslcidas. Por
ejemplo, quizs ustedes estn a punto de firmar con un nuevo cliente muy grande con un comit de estndares que
obliga a tener ventanas redondeadas y traslcidas.

Constantemente encontrars que cuando sabes el contexto de la peticin, se abren nuevas posibilidades. Es comn
para la peticin estar cumpliendo con el producto existente en alguna otra forma que permita decir s sin trabajar: De
hecho, en las preferencias de usuario puedes descargar las cubiertas con ventanas traslcidas y activarlas.
Algunas veces la otra persona simplemente no tendr idea que lo encuentras incompatible con tu visin del producto.
Me parece que es generalmente til revertir ese por qu? hacia ti. Algunas veces el acto de expresar la razn har
ms claro que tu primera reaccin no tiene sentido. De lo contrario, quiz necesites elevarlo a un nivel superior de
tomadores de decisiones. Recuerda, la meta de todo esto es decir s a la otra persona e intentar hacerlo funcionar, no
slo por l, sino tambin por ti y tu equipo.
Si puedes expresar una irresistible explicacin de por qu esa caracterstica es incompatible con el producto
existente, entonces es probable tener una conversacin productiva sobre si estn construyendo el producto correcto.
Sin importar cmo concluya esa conversacin, todos se enfocarn ms en qu es el producto y qu no lo es.
Iniciar con un s significa trabajar con tus colegas, no contra ellos.

Instalame
Autor: Marcus Baker
No tengo el menor inters en tu programa.
Estoy rodeado de problemas y tengo una lista de cosas por hacer tan larga como mi brazo. La nica razn por la que
estoy en tu sitio web ahora mismo es porque he odo un poco probable rumor de que cada uno de mis problemas
ser eliminado por tu software. Perdname si soy escptico.
Si los estudios de seguimiento del globo ocular son correctos, ya he ledo el ttulo y estoy buscando un texto
subrayado con color azul marcado como descargar ahora. Como anotacin al margen, si llegu a esta pgina con
un navegador de Linux con una IP del Reino Unido, es probable que me gustara una versin Linux desde un espejo
en Europa, as que por favor no preguntes. Asumiendo que el dilogo de archivo se abre directamente, llevo la cosa a
mi carpeta de descargas y sigo leyendo.
Todos nosotros realizamos constantemente anlisis de costo-beneficio de lo que hacemos. Si tu proyecto cae debajo
de mi umbral por un segundo, me deshar de l e ir a otra cosa. La gratificacin instantnea es mejor.
El primer obstculo es instalar. No crees que sea mucho problema? Ahora ve a tu carpeta de descargas y mira
alrededor. Lleno de archivos .tar y .zip, verdad? Qu porcentaje de esos han sido desempacados? Cuntos has
instalado? Si eres como yo, slo un tercio est haciendo algo ms que actuar como relleno en el disco duro.
Podra querer conveniencia a la puerta, pero no quiero que entres a mi casa sin invitacin. Antes de escribir install
querra saber exactamente dnde ests poniendo cosas. Es mi computadora y quiero mantenerla ordenada cuando
pueda. Tambin quiero ser capaz de eliminar tu programa al instante en el que me desencante de l. Si sospecho
que eso es imposible no lo instalar en primer lugar. Mi mquina es estable ahora y quiero que siga as.

Si tu programa se basa en GUI entonces quiero hacer algo simple y ver un resultado. Los Asistentes no ayudan,
porque ellos hacen cosas que no entiendo. Hay probabilidad de que quiera leer o escribir un archivo. No quiero crear
proyectos, importar directorios o decirte mi correo electrnico. Si todo est funcionando, ir al tutorial
Si tu software es una biblioteca, entonces seguir leyendo tu pgina web buscando una gua rpida de inicio. Quiero
el equivalente de un hola, mundo en cinco lneas sin mucho pensar con la salida descrita por tu sitio web. No quiero
llenar un gran archivo XML o plantillas, slo un script. Recuerda, tambin he descargado tu framework rival. Ya sabes,
el que siempre clama ser mucho mejor que el tuyo en los foros? Si todo est trabajando, al tutorial.
Hay un tutorial, no? Uno que me habla en un lenguaje que pueda entender?
Y si el tutorial menciona mi problema, me animar. Ahora estoy leyendo sobre las cosas que puede hacer para que
comience a ponerse interesante, incluso divertido. Me reclinar y tomar mi t mencion que soy del Reino
Unido? y jugar con tus ejemplos y aprender a usar tu creacin. Si resuelve mi problema, te enviar un correo de
agradecimiento. Enviar reportes de error cuando colapse y sugerencias de caractersticas tambin. Incluso le dir a
todos mis amigos que es mejor tu software, aunque nunca prob el de tu rival. Y todo porque cuidaste mis primeros
pasos tentativos.
Cmo pude haber dudado de ti?

CAPITULO 51
http://97cosas.com/programador/