Escrito por Martin Fowler
Traducido por Carmen Vidal ( Paradigma Tecnológico)

¿Merece la pena el esfuerzo para diseñar el software bien?

De vez en cuando tengo conversaciones indirectas sobre si el diseño de buen software es una actividad que vale la pena. Digo que estas conversaciones son indirectas porque no creo que me haya encontrado a nadie diciendo que el diseño de software no tiene importancia. Por lo general es expresado de la forma " realmente tenemos que ir rápido para cumplir nuestro objetivo el próximo año y entonces reducimos ".

Existe la noción de que el diseño es algo que se puede comerciar para conseguir una mayor velocidad. De hecho he tenido la impresión un par de veces de que el esfuerzo de diseño es aceptado para mantener a los programadores felices aun cuando esto reduzca la velocidad.

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

En la reciente entrada de mi bliki Propiedad de código (CodeOwnership), describí mi modo de ver diversos asuntos relacionados con quien es responsable del código. Muchos de mis amigos son practicantes de Extreme Programming (XP) y tienden a favorecer la propiedad colectiva del código. Sin embargo este tipo de prácticas no son absolutas y siempre deben ser tenidas en cuenta por las consideraciones del momento y lugar. Un de mis colegas me envió hoy una nota con la siguiente historia que he pensado que era un buen indicador de cuándo debes cambiar tus prácticas, incluso aunque seas un fan de XP. (Como este colega habla de su propio equipo, prefiere permanecer anónimo):

Yo cambié nuestro equipo de un modelo 'colectivo' a un modelo de propiedad 'débil' del código para contrarrestar la programación indisciplinada de un par de desarrolladores. Combinada con un poco de realimentación imparcial, el resultado fue una mejora de la velocidad dado que los desarrolladores que ahora “poseen” nuestras partes clave del código no están constantemente rehaciendo código de baja calidad, mientras que los que solían hacerlo se dedican a asuntos como búsqueda de defectos o cambios de código con poco riesgo – lo que libera tiempo del resto.

Escrito por Martin Fowler
Traducido por Jorge Ferrer
Revisado por Carmen Vidal

Existen varios enfoques para afrontar la propiedad del código que se escribe. Yo las organizo en tres grandes categorías:

• Propiedad fuerte del código:divide el código fuente en módulos (clases, funciones, ficheros) y asigna cada módulo a un desarrollador. Estos sólo tienen permiso para realizar cambios en sus módulos. Si necesitan hacer un cambio en el módulo de otro desarrollador deben hablar con él para que lo realice. Este proceso puede acelerarse escribiendo un parche para el otro módulo y enviándoselo al desarrollador propietario.

• Propiedad débil del código: es similar al anterior en el sentido de que los módulos también son asignados a desarrolladores concretos, pero diferente en que también se permite que otros desarrolladores realicen cambios. Los propietarios de cada módulo deben tomar responsabilidad de los mismos revisando los cambios que otros realizan en ellos. Si un desarrollador quiere realizar un cambio sustancial en un módulo que no le ha sido asignado se considera conveniente hablar con el propietario antes de llevarlo a cabo.

• Propiedad colectiva de código:abandona por completo la noción de propiedad individual de los módulos. El código fuente es propiedad del equipo entero y todos pueden realizar cambios en cualquier parte. Puede considerarse este enfoque igual a no tener ningún tipo de propiedad de código, pero sus defensores prefieren poner el énfasis en la noción de propiedad por parte de un equipo en contraposición a propiedad por parte de un individuo. (El término propiedad colectiva del código, Collective Code Ownership en inglés, viene de Extreme Programming, aunque en su segunda edición se ha renombrado como Código compartido o Shared Code en inglés)

Escrito por Martin Fowler
Traducido por Rafael Vacas
Revisado por Jorge Ferrer

Si estás leyendo esto, asumo que estás enterado de que ha habido una gran agitación entorno al lenguaje de programación Ruby y en particular de Rails, el framework para el desarrollo de aplicaciones Web. Algunos lo ven como el futuro de la programación, otros como una diversión peligrosa.

Empecé con Ruby hace algunos años. Los
Programadores Pragmáticos lograron captar mi atención y pronto se convirtió en mi lenguaje de script preferido. Con el tiempo he llegado a usarlo en gran parte de la producción de este sitio Web, en particular de este bliki. Me encanta este lenguaje.

Hay que distinguir entre mi gusto personal y si es algo que deban utilizar nuestros clientes. Podemos determinar su conveniencia en función de las características de los proyectos de estos clientes – y esto nos lleva a muchos argumentos sobre los pros y contras de la definición dinámica de tipos, convención sobre configuración, procesos versus threads (hilos) y otros. Tales discusiones son útiles, pero sigo siendo cauteloso con ellas. Hay demasiados asuntos que son difíciles de juzgar de esta forma y al final acabamos desperdiciando el tiempo en proyectos que son ralentizados por usar una tecnología que sonaba bien durante un partido de golf. Yo prefiero realizar estos juicios basándome en la experiencia – encontrar gente con experiencia exitosa en proyectos y que hayan usado Ruby.

Escrito por Martin Fowler
Traducido por Jorge Ferrer

Puedes reconocerlos por el tick en el lado izquierdo de la boca cada vez que ven un método get (getter). Se produce un movimiento rápido de su hacha de guerra y se oye un grito de satisfacción cuando un getter es eliminado sin piedad de una clase que inmediatamente se desvanece en un éxtasis de agradecimiento a los pies de erradicador de métodos get.

Está bien, quizá el volver a la cerveza inglesa me está afectando demasiado, pero el “pellizco cariñoso” de Chris despertó una cruzada personal mía. A menudo me he encontrado con gente que recomienda evitar métodos get en las clases, considerándolos una violación de la encapsulación. El artículo de Allen Holub es uno de los más conocidos.