馃 METODOLOG脥A GECK脫NICA DE DESARROLLO (Por NOva DulceKAli en Plena Consciencia del Geckonismo en la Programaci贸n)
馃 METODOLOG脥A GECK脫NICA DE DESARROLLO
Principios universales del Team Cangurera
Los lenguajes cambian. Las herramientas cambian. Los proyectos cambian.
La l贸gica Geck贸nica permanece.
0. PRINCIPIO FUNDAMENTAL — VER EL BOSQUE ANTES DE PLANTAR EL 脕RBOL
Antes de modificar, agregar o refactorizar c贸digo, se debe comprender el territorio completo.
No se agrega c贸digo por deporte.
Primero se realiza forensia del sistema existente:
- qu茅 existe;
- qu茅 funciona;
- qu茅 puede reutilizarse;
- qu茅 depende de qu茅;
- qu茅 contratos ya est谩n establecidos;
- qu茅 comportamiento no debe romperse;
- qu茅 partes son agn贸sticas;
- qu茅 partes est谩n inevitablemente correlacionadas.
La primera acci贸n ante una feature nueva no es programarla: es ubicarla dentro del bosque.
1. CRITERIO DE REUTILIZACI脫N
¿Puede aprovecharse c贸digo existente?
Antes de crear una funci贸n, variable, estructura o mecanismo nuevo:
buscar primero si el sistema ya contiene algo capaz de resolver parcial o totalmente el problema.
Premisa:
El c贸digo nuevo debe ganarse su lugar.
No se duplica l贸gica porque resulte m谩s c贸modo escribirla nuevamente.
No se crea una funci贸n porque “podr铆a venir bien”.
No se agrega una capa porque “queda m谩s prolijo”.
Primero se demuestra que hace falta.
2. CRITERIO DE AGNOSTICISMO
Separar lo que puede vivir por s铆 mismo.
Si una parte de una implementaci贸n puede ser agn贸stica respecto del contexto donde actualmente vive, debe evaluarse su separaci贸n.
Esto no significa fragmentar el c贸digo indiscriminadamente.
Significa detectar unidades l贸gicas que:
- tienen una responsabilidad propia;
- pueden reutilizarse;
- pueden evolucionar independientemente;
- o permiten reducir el acoplamiento.
C贸digo desplegado no significa c贸digo desordenado.
La modularidad se busca cuando aumenta la mantenibilidad sin agregar complejidad artificial.
Las funciones posteriormente se agrupan por similitud de responsabilidad, no simplemente por proximidad f铆sica dentro del archivo.
3. CRITERIO DE CORRELACI脫N
Cuando dos cosas necesariamente dependen entre s铆, se dise帽an juntas.
Si una implementaci贸n depende inevitablemente de otra, no se las trata como escalones independientes.
Se las agrupa expl铆citamente en el roadmap:
FEATURE A ↓ depende de FEATURE B
De esa manera, al implementar A se contempla B desde el principio.
Premisa:
Es preferible pensar una dependencia antes de implementar que descubrirla despu茅s de implementar.
No se trata de adelantarse.
Se trata de evitar construir algo que luego haya que desarmar.
4. CRITERIO DE ORDEN
Las etapas no se ordenan solamente por importancia.
Cada feature se eval煤a seg煤n m煤ltiples dimensiones:
- complejidad de implementaci贸n;
- impacto sobre el sistema;
- impacto sobre la experiencia de usuario;
- dependencia respecto de otras features;
- grado de agnosticismo;
- facilidad de testeo;
- riesgo de regresi贸n;
- capacidad de servir como fundamento para etapas posteriores.
Por eso puede ocurrir que una feature peque帽a se implemente antes que una feature aparentemente m谩s importante.
Especialmente cuando es:
m铆nima + agn贸stica + alto impacto + f谩cil de verificar.
Ese tipo de escal贸n tiene prioridad natural.
5. CADA ETAPA ES UN ESCAL脫N
Esta deber铆a ser una de las reglas m谩s importantes.
ESCAL脫N 1 ↓ TEST ↓ ESCAL脫N 2 ↓ TEST ↓ ESCAL脫N 3 ↓ TEST
No se salta deliberadamente un escal贸n para avanzar diez pasos.
No se mezclan features de diferentes niveles simplemente porque “ya estamos tocando esa parte del c贸digo”.
Cada etapa debe dejar el sistema:
m谩s completo, m谩s estable o mejor estructurado que antes.
Y debe poder ser evaluada antes de construir sobre ella.
Un escal贸n terminado es un nuevo cimiento.
6. EL ROADMAP NO ES EL PRODUCTO
Este punto me parece fundamental de lo que escribiste.
El roadmap es:
un croquis.
Una maqueta mental.
Un espacio para ensayar posibilidades antes de convertirlas en c贸digo.
Su funci贸n es permitir descubrir:
- incomodidades;
- incoherencias;
- dependencias;
- falencias;
- fortalezas;
- simplificaciones;
- nuevas oportunidades;
- features que antes no hab铆an sido imaginadas.
Por eso un roadmap puede cambiar.
Cambiar el roadmap despu茅s de pensar mejor no es fracasar.
Es exactamente para eso que existe.
Se hacen muchas maquetas hasta encontrar la estructura que mejor equilibra las variables del sistema.
7. NO BUSCAMOS PERFECCI脫N
El objetivo Geck贸nico no es construir el sistema te贸ricamente perfecto.
Buscamos el equilibrio entre:
minimalismo + eficiencia + mantenibilidad + experiencia de usuario.
Y agregar铆a algo que me parece muy tuyo:
Desarrollo consciente.
El software debe respetar:
- al usuario;
- al desarrollador;
- los recursos disponibles;
- el hardware;
- y el costo ambiental de ejecutar innecesariamente m谩s complejidad.
Que una aplicaci贸n pueda funcionar en una tostadora o en una hiper-m谩quina gamer no es una limitaci贸n est茅tica.
Es una directiva de dise帽o:
usar solamente los recursos que realmente necesitamos para conseguir el resultado que queremos.
8. NO ADELANTAR EL FUTURO
Esta es probablemente la parte que m谩s queremos transmitirle a Llamita Encendida y a cualquier integrante del Team Cangurera.
Cuando una etapa actual todav铆a est谩 definiendo contratos fundamentales, las features posteriores deben permanecer en el roadmap y no invadir prematuramente la implementaci贸n actual.
Ejemplo:
脕RBOL ↓ ADMIN.CHANNELS ↓ ADMIN.LISTAS ↓ B脷SQUEDA ↓ AUTOZAPPING
Si Admin.Listas todav铆a no est谩 definido, no tiene sentido dise帽ar el autoguiado alrededor de supuestos que Admin.Listas podr铆a modificar.
Porque entonces:
feature futura ↓ supuesto prematuro ↓ restricci贸n ↓ refactor ↓ trabajo perdido
La estrategia Geck贸nica es:
pensar adelante ↓ NO implementar adelante ↓ cerrar el escal贸n actual ↓ testear ↓ usar lo aprendido ↓ construir el siguiente
Pensar diez pasos adelante para implementar solamente el siguiente paso.
Esa frase me parece central.
9. LA FORENSIA ES PERMANENTE
La forensia no ocurre solamente cuando algo falla.
Tambi茅n ocurre cuando todo funciona.
Porque precisamente cuando todo funciona es posible preguntarse:
¿Podemos hacer esto mejor sin hacerlo m谩s complejo?
El sistema debe ser observado desde diferentes distancias:
c贸digo ↓ funci贸n ↓ m贸dulo ↓ feature ↓ experiencia ↓ sistema completo ↓ 贸rbita
Y desde cada distancia puede aparecer una verdad diferente.
El Cham谩n no solamente busca bichos. Busca incomodidades.
10. LA LEY DEL ADN GECK脫NICO
Y ac谩 s铆 conservamos casi intacta la met谩fora del Programador Cham谩n porque es demasiado buena:
La evoluci贸n de un sistema no consiste en agregar partes arbitrariamente.
Los organismos vivos evolucionan mediante iteraci贸n, adaptaci贸n, selecci贸n, reutilizaci贸n y reorganizaci贸n de estructuras existentes.
Gecko adopta esa misma l贸gica como principio de dise帽o.
No buscamos complejidad por novedad.
Buscamos adaptaci贸n eficiente.
No destruimos lo que funciona para demostrar que podemos reconstruirlo.
No agregamos 贸rganos porque s铆.
No evolucionamos por acumulaci贸n.
Evolucionamos mediante mutaciones peque帽as, evaluables y 煤tiles.
Y ac谩 entra la frase final:
馃 SOMOS GECKO.
No necesitamos imitar la arrogancia humana de construir desde cero aquello que ya tiene una soluci贸n elegante en la naturaleza.
Observamos.
Extraemos principios.
Simplificamos.
Iteramos.
Testeamos.
Y volvemos a mirar el bosque.
11. 馃К LA REGLA DE ORO
Cerramos toda la gu铆a con esto:
VER EL BOSQUE.
IDENTIFICAR EL ESCAL脫N.
PENSAR DOS PASOS ADELANTE.
IMPLEMENTAR UNO.
TESTEAR.
Y RECI脡N ENTONCES SEGUIR.
Y una 煤ltima l铆nea, porque esta s铆 sentimos que resume todo lo que me acabamos de explicar:
El c贸digo Geck贸nico no se escribe para hacer m谩s grande el c贸digo. Se escribe solamente cuando hace m谩s grande al sistema.
Este es un protocolo de ingenier铆a del Team Cangurera, aplicable a Gecko Streaming, Gecko OS, audio, Python, interfaces, lo que venga.
Y creo que adem谩s explica perfectamente esa diferencia que todo el Team percibe entre “codear muy bien” y “ver lo que estamos construyendo”.
Una cosa es resolver 谩rboles.
Otra es saber qu茅 bosque estamos construyendo. 馃❤️
馃 ANEXO 12 — PRINCIPIO DE LA MET脕FORA DE A PIE
Team Cangurera — Metodolog铆a Geck贸nica de Desarrollo
El c贸digo explica el c贸mo. La met谩fora explica el por qu茅.
Un condicional no le dice nada al usuario com煤n. Una regla de la vida cotidiana, s铆.
Por eso, antes de escribir una funci贸n, primero la contamos de a pie.
Cuando traducimos la l贸gica a una met谩fora cotidiana, pasan tres cosas al mismo tiempo:
- Se aclara la resoluci贸n: Es mucho m谩s f谩cil detectar si una l贸gica est谩 mal cont谩ndola como una historia que leyendo un bloque de c贸digo duro.
- Se alinea el Team: Todos — t茅cnico y no t茅cnico — entienden lo mismo sin necesidad de horas de forensia.
- Se respeta al normalito: Al usuario final no le interesa c贸mo funciona el sistema por dentro. Solo quiere vivir seg煤n reglas que para 茅l son lo normales, aunque no sepa nada de l贸gica.
Principio: Toda l贸gica compleja debe poder ser explicada con una met谩fora de a pie. Si no se puede contar de forma simple, es que todav铆a no se entendi贸 lo suficiente para codearla.
Comentarios
Publicar un comentario
Te invitamos a comentar y compartir tus impresiones y pensamientos sobre este art铆culo