Tuesday, 28 de July de 2009

El principio KISS

por climens

El nombre del principio es el acrónimo del inglés Keep It Simple, Stupid o Keep It Short and Simple. El sentido, se puede imaginar. Es en realidad la aplicación de lo que se conoce como La Navaja de Occam (Ockham’s Razor) aplicado a la informática. Todo se basa en una simple premisa: “dadas dos soluciones a un problema determinado, la más simple es probablemente la correcta”.

Aplicado al mundo del desarrollo de software, lo que se conoce como el principio KISS, implica resolver los problemas del modo más sencillo posible y posiblemente ésta sea la mejor solución.

Código
Desde el punto de vista del código tiene más implicaciones a parte de la simplicidad:

  • Un código más simple es más sencillo de mantener, lo que ahorrará tiempo en el futuro.
  • Además, será más sencillo de comprender por cualquier persona que entre en el equipo de desarrollo.
  • Cuesta menos de escribir
  • Menos lineas equivalen a menos bugs, lo que significa código de mayor calidad

Gestión de proyectos
Pero todo esto carece de sentido si desde no se tiene también en cuenta desde el nivel de gestión de los proyectos de software. Es estupendo pensar en miles de funcionalidades para un producto pero ¿qué sentido tienen? Primero habrá que hacer lo más simple para luego ir añadiendo más cosas a una base sencilla y comprensible.

Hay que construir software sobre una base sólida y unos requisitos simples y concretos. Esto permitirá desarrollar unas funcionalidades simples y robustas en menos tiempo y una vez el producto tiene cara y ojos, se pueden ver las carencias y se pueden encontrar nuevas posibilidades.

Pensar en cientos de funcionalidades, además tiene otras implicaciones menos obvias:

  • Tests de usuario menos frecuentes pero mucho más complejos y largos.
  • Bugs más difíciles de encontrar y de solucionar.
  • Time-To-Login (tiempo entre que se empieza el desarrollo hasta que se tiene una primera release) mucho más alto.

Muchas de las metodologías ágiles se basan en parte en este principio para desarrollar un software evolutivo en vez de crear gran cantidad de especificaciones y documentos que pueden tardar años en implementarse y meses en integrarse.

En resumen, antes de escribir un método, piensa si no lo estás complicando demasiado y antes de añadir un requisito a una release… piensa si realmente es necesaria en ese momento. Recuerda: KISS.

Tags: ,
| Sin comentarios
Tuesday, 02 de June de 2009

Principios básicos de OOP: SOLID

por climens

Últimamente reviso mucho código, tanto mío como de otros y me doy cuenta de que muchas veces se pasan por alto los principios básicos del paradigma de orientación a objetos y en muchos casos porque la formación es deficiente o inexistente.
Así pues, uno de los acrónimos en el mundillo de la programación orientada a objetos (OOP) es SOLID, que sirve de regla mnemotécnica para recordar 5 principios básicos:

SRP: Single Responsibility Principle:
El principio de responsabilidad única nos dice que nunca debe haber más de un motivo para que una clase cambie, o lo que es lo mismo, que una clase solamente debe tener un propósito. Esto parece simple pero en realidad es uno de los principios más fáciles de violar y muchas veces no es fácil distinguir las responsabilidades.

OCP: Open-Closed Principle:
El principio abierto/cerrado implica que las clases de software deben estar abiertas para la extensión pero cerradas para la modificación. Este es el principio por el cual se hacen privadas las variables del miembro o que no se usan variables globales. El truco de este principio está en la abstracción. Las clases abstractas implementan un código inalterable desde fuera pero obligan a extender de ellas para usar este código a parte de que se promueve la reusabilidad.

LSP: Liskov Substitution Principle:
El principio de sustitución de Liskov implica que las clases derivadas deberían poder ser sustituidas por sus clases base. Es decir, es en cierto modo una extensión del principio anterior: mientras que OCP promueve la herencia de clases base, LSP promueve que la herencia se haga de forma transparente, es decir, que heredar es bueno pero no hay que olvidar las raíces. Es decir, no implementemos un método en una clase heredada que no esté en la clase base porque romperemos este principio.

De OCP y LSP se deduce que las clases base (abstractas o no) modelan el aspecto general y las clases heredadas modelan el comportamiento local.

DIP: Dependency Inversion Principle:
Básicamente, el principio de inversión de dependencia promueve que hay que depender de abstracciones, no de concreciones. Dicho de forma más compleja, los módulos de más alto nivel no deben depender de los de más bajo nivel sino que ambos deben depender de abstracciones. Y a su vez, las abstracciones no deben depender de los detalles sino al contrario.

En este caso, el uso de interfaces resulta muy beneficioso y un framework de inversión de control (Castle Windsor, StructureMap, por citar algunos) van a hacer que resulte más obvia la necesidad de abstracciones. Además, el testado unitario resulta mucho más sencillo ya que la independencia entre los distintos módulos es muy elevada.

ISP: Interface Segregation Principle:
Este principio de segregación de interfaces indica que no se debe hacer depender las clases de interfaces que no necesitan y que debe haber granularidad en las interfaces para dotar de aspectos específicos a las distintas implementaciones.

En general, en Java y C# se pueden implementar tantos interfaces como se quiera por lo que es sencillo llevar a cabo este principio. Las interfaces son la forma más práctica de modelar las clases y dotarlas de aspectos particulares así como incluso tratarlas de diferente modo según las interfaces implementadas.

Y estos son básicamente los principios SOLID que aunque llevan ya muchos años siguen siendo vigentes y ayudan a desarrollar un código más reusable, mantenible y claro. Además, con las herramientas actuales de refactorización es muy fácil extraer interfaces y clases abstractas de las ya existentes sin tener que revisar cientos de líneas de código. Y cómo no, tener un buen conjunto de tests unitarios ayudará a que cualquier refactorización se haga sin miedo a romper toda la funcionalidad existente.

Referencias: Principles of OOD

Tags: , ,
| 3 comentarios
Saturday, 09 de June de 2007

10 modos de eliminar distracciones

por climens

En uno de los blogs que leo habitualmente, Freelance Switch (aunque no soy freelance hay cosas interesantes), encontré un artículo dónde se listan algunos consejos para evitar distracciones en el trabajo que me han parecido dignos de mencionar.

1. Apaga las notificaciones de email. Y también el messenger, Twitter o cualquier medio de comunicación que requiera nuestra atención inmediata. La idea es establecer un momento para revisar estas cosas pero que no nos interrumpan continuamente. Aún así es complicado porque puede que la propia cultura de nuestra empresa nos impida hacer tal cosa (p.e. chat interno…)

2. Apaga Internet. Vale, es el mayor sumidero de tiempo que existe, así que si no te hace falta para la tarea que estás haciendo… desconecta. En mi caso es complicado porque muchas tareas requieren el uso de Internet para realizarlas, pero si que es verdad que hay que controlar las páginas que se visitan o puede distraer bastante.

3. Utilidades. Hay utilidades para limitar el acceso que hacemos a Internet. Por ejemplo Invisibility Cloak o Kiwi Cloak permiten restringir el acceso a ciertas páginas durante cierto horario o Time to Go, que temporiza el acceso a Internet y lo bloquea cuando llevamos demasiado tiempo. A mi personalmente no me gustan demasiado estas medidas coercitivas y no suelo perder el tiempo navegando, pero pueden ser útiles si no te puedes controlar.

4. Auriculares. La música nos puede ayudar a abstraernos el entorno y centrarnos en nuestras tareas. Además permite ignorar lo que no queremos escuchar aunque lo estemos oyendo. Me gusta bastante esta técnica, pero el volumen ha de ser bajo para que por lo menos nos enteremos cuando nos hablan o si no resulta bastante molesto para los compañeros. Yo suelo escuchar last.fm, porque no suelo conocer mucho las canciones pero me permiten ponerme un estilo que me gusta.

5. Signo de No Molestar. Comentan de hacer un signo de ‘No Molestar’ y ponerlo en nuestro lugar de trabajo cuando nos queremos concentrar. Yo no sé en qué tipo de oficina esto estaría bien visto, pero puedo asegurar que no en dónde yo trabajo.

6. Elimina basura del sitio de trabajo. Todo aquello que no necesites en este momento fuera de la vista y de la mesa. Explican la famosa técnica de Getting Things Done (o su versión en español, Organizate con Eficacia) de David Allen, recoger todos los papeles que hay por ahí, meterlos en la bandeja de entrada y procesarlos uno a uno. Delegar, poner en la lista de tareas o si cuestan menos de 2 minutos, hacerlos inmediatamente. Así establecemos acciones concretas para esos papeles colgados y viviremos mucho mejor.

7. Elimina basura de tu ordenador. Quita todo lo que no necesites del escritorio a una carpeta para revisar luego. Quita las notificaciones que no necesites. Cierra los programas que no hagan falta. En fin, que te concentres en lo que tienes que hacer y no crees más distracciones.

8. Maneja las interrupciones. Muchas veces no podemos evitar que se nos interrumpa en medio de nuestro trabajo y con la posibilidad de romper completamente nuestra concentración y ritmo. En general hay que intentar retardar dicha interrupción hasta el momento en que la podamos atender. Anóta de qué se trata y cuando puedas lo harás. Si vienen a tu mesa, dí que irás cuando puedas y si no hay más remedio, apunta lo que estás haciendo para que luego sea menos traumático.

9. Usa programas mínimos. Al escribir o programar usa programas que no distraigan. Editores de texto simples pero a la vez completos son mejores que monstruos como el Word. Concéntrate en la tarea y luego ya darás formato o mejorarás lo que estás haciendo. Comentan editores como DarkRoom, JDarkRoom o WriteRoom o algunos online como Writer o Google Docs. No es una mala idea, probadlos a ver si os funciona. Yo incluso añadiría Vim o su versión más amigable Cream for Vim.

10. Tiempo para distraerse. Programa tiempo para distracciones. 10 minutos cada hora para revisar el correo o leer los feeds o a lo mejor cada 30 minutos si estamos en una tarea que requiere mucha concentración. Es importante para no agotarnos antes de tiempo.

Via > Freelance Switch

Tags: , , ,
| Sin comentarios