Acta con prudenciaAutor: Seb RoseEn todo lo que emprendas, acta
con prudencia y considera las consecuenciasAnnimoNo 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 sutaxonoma 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 compilacinAutor: Steve BerczukNo
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
RefactorizarAutor: Rajith AttapattuEn 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 funcionalAutor: Edward
GarsonRecientemente, 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 desimular 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 GuestPaul
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 funcinmainy 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.outMira! 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
int main() { printf("Hello, World\n"); return 0;}Aprende a hacer
estimacionesAutor: Giovanni AsproniComo 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
tcnicasAprende un lenguaje extranjeroAutor: Klaus MarquardtLos
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 comandosAutor: Carroll RobinsonHoy 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 archivosmakete 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 utilerasgrepysedson 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 calendarizarbuildsdiarios,
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
continuamenteAutor: Clint ShankVivimos 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 baratoEntonces, 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 deThe Pragmatic Programmery 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 codificacinAutor: Filip van LaenenProbablemente 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 ColborneTodos 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
simplicidadAutor: Jrn lmheimHay 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 bellezaPlatn 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 cdigoAutor: Kirk PepperdineMs 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 elfixte 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
llamadasfan-inyfan- out. Elfan-outest 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. Elfan-inun conteo de todas las clases que
depende de una clase en especfico. Conociendo
elfan-outyfan-inpodemos 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 moverIlo ms cercano a 0.Cuando usamos mtricas
debemos recordar que slo son reglas empricas. Basndose puramente en
las matemticas puedes ver que el incremento defisin
cambiarfomoverImas cerca a 0. Sin embargo hay una desventaja en
tener el valorfan-inalto, pues estas clases sern ms difciles de
modificar sin romper dependencias. Al no tener en cuenta
elfan-outno 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
raznAutor: Yechiel KimchiTrata 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 sentenciasgoto, ya
que hacen las secciones remotas altamente interdependientes2. 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 dominioAutor: Dan NorthImagnate 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
mtodoportfolioIdsByTraderIdy descubres esto:Map
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 amigosAutor: Aslam
KhanA 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 diseoAutor: Ryan
BrushImagnate 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
diceAutor: Kevlin HenneyLa 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 comentariosAutor: Cal
EvansEn 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 DoarComo 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 programacinAutor:
Russel WinderLa 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 IDEAutor: Heinz
KabutzEn 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. LosPretty Printerspara 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 laExtraccin 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
comofinal(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 fuesefinal. 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,
presionarCtrl+Shift+Ipara 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 -rEsperamos
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 lmitesAutor: Greg ColvinMans got to know
his limitations. Dirty HarryTus 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 funcinO(f(n))dondenes igual al tamao de
las entradas en el espacio asinttico o el tiempo requerido
conformenincrementa hacia infinito. Las clases de complejidad
importantes paraf(n)incluyenln(n),n,n ln(n), ney en. Al graficar
estas funciones se muestra claramente cmo conformense
incrementa,O(ln(n))es siempre mucho ms pequea queO(n)yO(n ln(n)),
las cuales son cada vez ms pequeas queO(ne)y O(en). Como deca Sean
Parent, para lograrntodas 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.Tiempo de
AccesoCapacidad
register< 1 ms64b
cache line64B
L1 cache1 ms64 KB
L2 cache4 ns8 MB
RAM20 ns32 GB
disk10 ms10 TB
LAN20 ms> 1 PB
internet100 ms> 1 ZB
Toma en cuenta que la capacidad y velocidad difiere en varios
rdenes de magnitud. El almacenamiento en cach y ellookaheadson
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 cadabyteen 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 dellookahead, pero
requiereO(n)comparaciones. La bsqueda binaria de una matriz
ordenada requiere sloO(log(n))comparaciones. La bsqueda en un
rbolvan Emde BoasesO(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 Boasgana sin usar las manos, gracias a su patrones
de acceso predecible.ElementoslinealbinariovEB
8509040
6418015070
5121200230100
409617000320160
Pagas tu dinero y te llevas tu eleccin. PunchLa conveniencia no
es una -bilidadAutor: Gregor HohpeMucho 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 decircorreren vez decaminar(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 colaboranAutor: Janet GregoryAlgo 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 comoFit(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 pruebaFitque 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 robustasuitede
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 compartirAutor: Udi DahanEra 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
LibreAutor: Richard Monson-HaefelHay 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 propiastart-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 datosAutor: Diomidis
SpinellisSi 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 RDB