Ir al contenido principal

La ley del boyscout

Hoy leí un texto que compartió Diego Ocampo que me pareció excelente y lo comparto acá:

"A menos que seamos extremadamente cuidadosos la entropía siempre hará que la calidad del software se degrade con el tiempo. Quizás pensemos que tenemos cosas más importantes que hacer que modificar esta clase o esta función y salgamos del paso con un pequeño hack. Es posible que no recordemos muy bien cómo funcionaba el sistema, y que añadamos complejidad innecesaria con nuestros cambios. O que el código nos cause tal sentimiento de repulsión, que no nos importe ejercer un cierto vandalismo casi deliberado contra él.



Sea cual sea la razón, la principal receta contra la entropía es la que siguen los boy scout a la hora de acampar.

Deja siempre el campamento más limpio de como lo encontraste

No se trata de que refactorices toda la aplicación hasta que se ajuste totalmente a tu ideal de perfección. Basta con que intentes dejar cada archivo que abras mejor de como lo encontraste. Formatea el código, añade un comentario, extrae una función o renombra una variable. Todo pequeño gesto contribuye a que el software que mantenemos no se degrade, y que, incluso, mejore con el tiempo." Fuente (al menos donde yo encontré el original).

Aplicado al software, la tecnología/herramientas (GeneXus, KBDoctor, etc) ayudan, pero al final del día creo que se trata de la "actitud". Sin la actitud correcta no hay herramienta, tecnología ni nada que valga.

A su vez, con la actitud correcta aplica en todos los contextos que puedan imaginar, hayan o no herramientas que ayuden a ello: el jardin, la casa, la familia, los amigos, en fin...se podría escribir mucho de ello.

En cualquier caso a mi me hizo acordar a una frase que suelo usar: "¡Sonría! aunque no lo estén filmando".

 

 

 

Comentarios

Publicar un comentario

Entradas más populares de este blog

Abrir links con aplicaciones nativas y no el browser (deeplinking)

El problema que tengo con algunas aplicaciones Android/iOS es que cuando recibo un link por algún medio (mail, tweet, etc) al abrirlo me lo abre con el browser, en lugar de abrirlo con una aplicación nativa asociada a ese “contenido”. Por ejemplo, si recibo un link a un tweet espero que lo abra con alguna aplicación de twitter que tenga instalada y no con el browser. De modo análogo si recibo un mail con una nota de prensa de un medio X y tengo la aplicación de ese medio X instalada, espero que el link lo abra con la aplicación nativa y no con el browser. Lo mismo quisiera con mi aplicación de "banking" o cualquiera que tenga instalada y sepa manejar ese "contenido" (link). Los motivos son bastante obvios pero los resumo en: la experiencia de usuario es mucho mejor en la aplicación nativa que en el navegador. Parte importante del tema es que el mismo link sea válido tanto para ver el contenido en el browser como para verlo en la aplicación, porque como prove

¡A la salud de mi KB!

Es bueno, especialmente en "bases de conocimiento" (KB) que han pasado por varias versiones de Genexus, chequear su "estado de salud". En este sentido KBDoctor  es una herramienta que ayuda mucho, principalmente desde el punto de vista del "modelo" Genexus (atributos, calls, definiciones de variables, etc) representado en una KB. También es útil revisar la salud de los archivos que lo soportan. Hasta la 9.0 eran archivos C-tree (los famosos .DAT) que tenían indices (los famosos .IDX) y teníamos en "rebuild -y" que mejoraba esos archivos y sobre todo reconstruía los indices. A partir de la X las KBs se almacenan en MS SQL Server por lo cual la administración de la misma pasó de ser un "file server" a un "database server". En este sentido algo que me ha dado muy buenos resultados es el "CheckKnowledgeBase".

Rocha:Constantes tipo fecha

En la Rocha se soportan constantes del tipo fecha o fecha-hora con formato ANSI/ISO (AAAA-MM-DD HH:MM:SS).  Tecnicamente (Sintáxis): <date>::=    [0-9]{1,4}"/"[0-9]{1,2}"/"[0-9]{1,2} | [0-9]{1,4}"."[0-9]{1,2}"."[0-9]{1,2} | [0-9]{1,4}"-"[0-9]{1,2}"-"[0-9]{1,2} <hms>::=    [0-9]{1,2}[ap] | [0-9]{1,2}":"[0-9]{1,2}[ap]? | [0-9]{1,2}":"[0-9]{1,2}":"[0-9]{1,2}[ap]? <constant> ::=   "#"<date>"#" | "#"<date> <hms>"#" | "#"<hms>"#" Funcionalmente Se pueden utilizar esas constantes en las reglas, eventos, propiedades, etc (todo lugar donde se utilice el parser): Algunos ejemplos básicos: &FechaInicial=#2007-01-01# &FechaHoraInicial=#07-1-1 11:15a# &HoraInicial=#11a# Me parece bueno no tener que escribir funciones (CTOD, TTOC) sobre constantes tipo char para lograr una fecha y mucho mejor aun en