En esta ocasión en SOFTWERO te traemos un artículo dividido en dos partes y escrito por Joel Spolsky, uno de los fundadores de Stack Overflow, que tiene todo un sistema para evaluar el código que hacemos y el proceso de desarollarlo, y que de cumplirse, nos ahorrara mucho tiempo y dolores de cabeza.
La prueba de Joel es fácil y podrás conseguir un rápido sí o no a cada pregunta. No es necesario calcular line-of-code-per-day o average-bugs-per-inflection-point. Suma a tu equipo 1 punto por cada respuesta "sí". Lo malo es que realmente no debe usarse para asegurar que su software de planta de energía nuclear es seguro.
Una puntuación de 12 es perfecta, 11 es tolerable, pero 10 o menor es un "tienes problemas serios". La verdad es que la mayoría de las organizaciones de software se ejecutan con una puntuación de 2 o 3, y necesitan ayuda seria, porque las empresas como Microsoft funcionan a los 12 a tiempo completo.
Por supuesto, estos no son los únicos factores que determinan el éxito o el fracaso: en particular, si tienes un gran equipo de software trabajando en un producto que nadie quiere, bueno, la gente no lo va a querer. Y es posible imaginar un equipo de "pistoleros" que no logran producir software increíble que cambia el mundo. Pero, todo lo demás se mantiene igual, si consigues acertar en estas 12 cosas, tendrás un equipo disciplinado que puede realizar entregas constantemente.
1. ¿Utilizas el control de código fuente?
He utilizado paquetes de control de código comercial, y he utilizado CVS, que es gratis, y déjame decirte, los CVS están bien. Pero si no tienes el control de la fuente, vas a tener que insistir para conseguir que los programadores trabajen juntos. Los programadores no tienen manera de saber lo que otras personas hicieron. Los errores no se pueden revertir fácilmente. La otra cosa genial acerca de los sistemas de control de código fuente es que el código fuente en sí es revisado en el disco duro de cada programador - nunca he oído hablar de un proyecto que utiliza el control de código fuente y que haya perdido mucho código.
2. ¿Puedes hacer una construcción en un solo paso?
Con esto quiero decir: ¿cuántos pasos se necesitan para realizar una compilación desde la última instantánea? En equipos buenos, hay un solo script que se puede ejecutar que realiza una comprobación completa desde cero, reconstruye cada línea de código, hace los EXEs, en todas sus versiones, idiomas y combinaciones #ifdef, crea el paquete de instalación y crea los medios finales - disposición del CDROM, transferencia directa al sitio web, cualquier cosa.
Si el proceso toma más de un paso, es propenso a errores. Y cuando te acerques más al envío, quieres tener un ciclo muy rápido para arreglar el "último" error, hacer los EXE finales, etc. Si se necesitan 20 pasos para compilar el código, ejecuta el constructor de instalación, etc., van a volverse locos y van a cometer errores tontos.
Por esta misma razón, la última empresa en la que trabajé cambió de WISE a InstallShield: requeríamos que el proceso de instalación pudiera ejecutarse desde un script de forma automática, de la noche a la mañana utilizando el planificador de NT, WISE no podía ejecutarse desde el planificador durante la noche, así que lo echamos. (Los amables de WISE aseguran que su última versión es compatible con las compilaciones nocturnas.)
3. ¿Usted hace construcciones diarias?
Cuando se utiliza el control de código fuente, a veces un programador accidentalmente comprueba algo que rompe la compilación. Por ejemplo, han agregado un nuevo archivo de origen y todo se compila bien en su máquina, pero se olvidaron de agregar el archivo de origen al repositorio de código. Así que ellos bloquean su máquina y se van a casa, ajenos y felices. Pero nadie más puede trabajar, así que se tienen que ir a casa también, infelices.
Romper la construcción es tan malo (y tan común) que ayuda a hacer las construcciones diarias, para asegurarse de que no hay rotura que pase desapercibida. En equipos grandes, una buena manera de asegurar que las roturas se arreglan de inmediato es hacer la construcción diaria cada tarde en, por ejemplo, la hora del almuerzo. Todo el mundo hace tantas checkins como sea posible antes del almuerzo. Cuando vuelven, la construcción se hace. Si funcionaba, ¡genial! Todo el mundo echa un vistazo a la última versión de la fuente y sigue trabajando. Si la compilación falló, lo arreglará, pero todo el mundo puede seguir trabajando con la versión previa de la versión ininterrumpida de la fuente.
En el equipo de Excel teníamos una regla de que quien rompiera la construcción, como su "castigo", era responsable de cuidar a los niños hasta que alguien más lo rompiera. Este fue un buen incentivo para no romper la construcción, y una buena manera de rotar a todos a través del proceso de construcción para que todos aprendieran cómo funcionaba.
( Puedes leer: Los lenguajes más Amados, Temidos y Deseados del 2017 )
4. ¿Tiene una base de datos de errores?
No me importa lo que digas. Si estás desarrollando código, incluso en un equipo de uno, sin una base de datos organizada que lista todos los errores conocidos en el código, enviaras código de baja calidad. Muchos programadores piensan que pueden mantener la lista de errores en sus cabezas. Disparates. No puedo recordar más de dos o tres bugs a la vez, y la mañana siguiente, o en la fiebre del envío, se olvidan. Usted absolutamente tiene que hacer un seguimiento de los errores formalmente.
Las bases de datos de errores pueden ser complicadas o simples. Una base de datos de errores mínima útil debe incluir los siguientes datos para cada error:
- Completar los pasos para reproducir el error
- Comportamiento esperado
- Comportamiento observado (buggy)
- A quien está asignado
- Si ha sido arreglado o no
Si la complejidad del software de seguimiento de errores es la única cosa que le impide el seguimiento de sus errores, sólo tiene que hacer una tabla de 5 columnas simple con estos campos cruciales y empezar a usarlo.
5. ¿Se arreglan los errores antes de escribir un nuevo código?
La primera versión de Microsoft Word para Windows fue considerada un proyecto de "marcha de la muerte". Se tardó una eternidad. Siguió resbalando. Todo el equipo estaba trabajando horas ridículas, el proyecto se retrasó de nuevo, y de nuevo, y de nuevo, y el estrés fue increíble. Cuando la cosa finalmente se envió, con años de retraso, Microsoft envió a todo el equipo a Cancún para unas vacaciones, luego se sentó para una búsqueda seria.
Lo que se dieron cuenta fue que los jefes de proyecto habían insistido tanto en mantener el "calendario" que los programadores simplemente se apresuraron en el proceso de codificación, escribiendo código extremadamente malo, porque la fase de arreglo de errores no formaba parte del programa formal. No hubo ningún intento de mantener la cuenta de errores. Todo lo contrario. La historia cuenta que un programador, que tuvo que escribir el código para calcular la altura de una línea de texto, simplemente escribió "return 12" y esperó a que el informe de error informara acerca de cómo su función no siempre es correcta. El programa era simplemente una lista de comprobación de las características que aguardaban para convertirse en errores. En la post mortem, esto se conoce como "metodología de defectos infinitos".
Para corregir el problema, Microsoft universalmente adoptó algo llamado una "metodología de defectos cero". Muchos de los programadores de la compañía rieron, ya que sonaba como la gerencia pensó que podría reducir el conteo de bugs con presupuesto ejecutivo. En realidad, "cero defectos" significa que en cualquier momento dado, la mayor prioridad es eliminar los errores antes de escribir cualquier código nuevo. Este es el por qué.
En general, cuanto más tiempo espera antes de arreglar un error, más costoso (en tiempo y dinero) es de reparar.
Por ejemplo, cuando se comete un error tipográfico o de sintaxis que el compilador captura, el arreglo es básicamente trivial.
Cuando tienes un error en tu código que ves la primera vez que intentas ejecutarlo, podrás arreglarlo en poco tiempo, porque todo el código está todavía fresco en tu mente.
Si encuentras un error en algún código que escribiste hace unos días, te tomará un tiempo cazarlo, pero cuando vuelvas a leer el código que escribiste, lo recordarás todo y podrás arreglar el código. Error en una cantidad razonable de tiempo.
Pero si encuentras un error en el código que escribiste hace unos meses, probablemente habrás olvidado un montón de cosas sobre ese código, y es mucho más difícil de arreglar. En ese momento puede estar arreglando el código de otra persona, y pueden estar en Aruba de vacaciones, en cuyo caso, arreglar el error es como la ciencia: usted tiene que ser lento, metódico y meticuloso, y no puede estar seguro de cuanto tiempo tomará descubrir la cura.
Y si encuentras un error en el código que ya ha sido enviado, vas a incurrir en un gasto increíble para conseguirlo.
Esa es una razón para arreglar los errores de inmediato: porque toma menos tiempo. Hay otra razón, que se relaciona con el hecho de que es más fácil predecir cuánto tiempo tomará escribir código nuevo que arreglar un error existente. Por ejemplo, si le pregunto para predecir cuánto tiempo tomaría escribir el código para ordenar una lista, podría darme una estimación bastante buena. Pero si le pregunté cómo predecir cuánto tiempo se necesitaría para arreglar ese error en el que su código no funciona si Internet Explorer 5.5 está instalado, ni siquiera puede adivinar, porque no sabe (por definición) qué está causando el bicho. Podría tomar 3 días para rastrearlo, o podría tomar 2 minutos.
Lo que esto significa es que si usted tiene un horario con una gran cantidad de errores que quedan por resolver, el horario no es fiable. Pero si has arreglado todos los errores conocidos, y todo lo que queda es código nuevo, entonces tu programa será increíblemente más preciso.
Otra gran cosa acerca de mantener el conteo de errores en cero es que usted puede responder mucho más rápido a la competencia. Algunos programadores piensan en esto como mantener el producto listo para enviar en todo momento. Entonces, si su competidor introduce una nueva característica espectacular que está robando a sus clientes, puede implementar esa característica y enviarla in situ, sin tener que arreglar un gran número de errores acumulados.
6. ¿Tiene un programa de trabajo actualizado?
Lo que nos lleva a los programas de trabajo. Si su código es importante para el negocio, hay muchas razones por las que es importante para el negocio saber cuándo se va a hacer el código. Los programadores son notoriamente malhumorados para hacer programas de trabajo. "Tomará el tiempo que deba tomar!" Gritan a la gente de negocios.
Desafortunadamente, eso no lo corta. Hay demasiadas decisiones de planificación que el negocio necesita para triunfa antes de enviar el código: demos, ferias comerciales, publicidad, etc y la única manera de hacerlo es tener un calendario, y mantenerlo actualizado.
La otra cosa crucial sobre tener un horario es que te obliga a decidir qué características vas a hacer, y luego te obliga a recoger las características menos importantes y cortarlos en lugar de deslizarse en featuritis (a.k.a. Alcance fluido).
( Te puede interesar: Cómo Contratar a un Programador para Llevar a Cabo tus Ideas (8 Pasos) )
¿Que piensas de los primeros 6 puntos hasta el momento? ¿Sería algo que aplicarías para ti o tu equipo de trabajo? ¿Listo para la segunda parte? Háznoslo saber en los comentarios!
Fuente | Joel On Software
No hay comentarios:
Publicar un comentario