¿Cómo hace la transición de un programa de en desarrollo a una versión?

  

Así que no pierdo mucho tiempo escribiendo código súper limpio en ese momento porque nunca sé cuánto dura algo.

No saber cuánto dura algo nunca debería ser una excusa para el descuido, todo lo contrario. El código más limpio es, en mi opinión, el que no aparece en tu camino cuando tienes que cambiar algo. Así que mi recomendación es: siempre intente escribir el código más limpio que pueda, especialmente al codificar un prototipo. Porque será mucho más fácil adaptarlo cuando haya que cambiar algo (lo que seguramente sucederá).

No me malinterpretes: mi comprensión del "código más limpio" no tiene nada que ver con hacer que el código sea hermoso por el bien de la belleza. Eso es de hecho algo que puede frenarte. Desde mi punto de vista, el código limpio es un código que en su mayoría es autoexplicativo (no hay necesidad de escribir tantos documentos, causa aceleración), fácil de entender (menos errores, menos depuración necesaria), menos tiempo necesario para encontrar la correcta lugar para alterar - aceleración), resuelve el problema dado con la menor cantidad de código necesario (menos código para depurar - aceleración obvia), es SECO (solo un lugar para cambiar cuando hay que cambiar algo - aceleración - y menos riesgo de introducción errores nuevos al olvidar cambiar un segundo lugar), sigue los estándares de codificación (cosas menos complicadas en las que pensar: aceleración), utiliza bloques de construcción pequeños y reutilizables (que pueden reutilizarse para muchas características o incluso prototipos, aceleración), etc.

  

Se espera que comience la prueba / depuración final, pero mi instinto dice que ahora debería limpiar o reescribir cosas para darle la arquitectura adecuada que facilita el mantenimiento, etc.

Hacer "limpieza" después nunca funciona. Considere la posibilidad de limpiar antes si implementa una nueva función, o cuando comience a implementarla, pero no después. Por ejemplo, cada vez que empiezas a tocar un método para una función y observas que tiene más de 10 líneas, considera refactorizarlo en métodos más pequeños, inmediatamente , antes de completar la función. Siempre que detecte una variable o nombre de función existente, no sepa exactamente qué significa, averigüe para qué sirve y cambie el nombre a la cosa anterior haciendo cualquier otra cosa. Si lo hace con regularidad, mantendrá su código al menos en un estado "suficientemente limpio". Y comienza a ahorrar tiempo , porque necesita mucho menos tiempo para la depuración.

  

Estoy en medio de las pruebas y la corrección de errores sería una reescritura

... que es la prueba real de lo que escribí anteriormente: ser "sucio" te persigue inmediatamente cuando comienzas a depurar tu código y te hará más lento.

Puedes evitar esto casi por completo si haces la limpieza inmediatamente. Luego, las correcciones de errores significarán principalmente pequeños cambios en el código, pero nunca un cambio arquitectónico importante. Si realmente detecta evidencia de una mejora en la arquitectura durante la prueba, la demora, póngala en su sistema de seguimiento de problemas y la implementa la próxima vez que tenga que implementar una función que se beneficie de ese cambio ( antes usted comienza con esa característica).

Esto requiere algo de disciplina, y algo de experiencia en codificación, por supuesto. Es una idea similar a la idea detrás del "desarrollo guiado por pruebas", hacer estas cosas de antemano en lugar de hacerlo después (TDD también puede ayudar, pero lo que escribí funciona incluso cuando no se usa TDD). Cuando haga esto en consecuencia, no necesitará ninguna "fase de limpieza" especial antes de liberar.

Tiene dos problemas separados, ambos con el mismo síntoma (código descuidado):

Problema nº 1: control de requisitos insuficientes No quiero decir que sus partes interesadas cambien sus requisitos con demasiada frecuencia, quiero decir que está permitiendo cambios en los requisitos durante un ciclo de prueba / corrección de errores. Incluso las metodologías ágiles no soportan eso; usted construye, prueba, entrega, inyecta nuevos requisitos.

Problema nº 2: crees que lo que estás escribiendo es "solo por ahora" En el desarrollo de software, el código "solo por ahora" es realmente extremadamente raro. Se ha dado cuenta de que, una vez que haya cumplido con los requisitos de un usuario, los rigores de la oferta y la demanda hacen que sea muy difícil justificar el regreso y la reimplementación de una función "hecho". Entonces, ¿qué hacer al respecto? Siempre escriba el código de producción. Funcionalmente para usted, eso significa que sus estimaciones para sus partes interesadas deben ser sustancialmente más grandes para que tenga tiempo para hacerlo correctamente.

Además, comprenda que está trabajando en la posición más difícil como desarrollador: Lea el artículo de Joel Spolsky asumir la vida de un desarrollador interno . Por lo tanto, debe ser muy vigilante si quiere salir con la cordura intacta.

Es un problema común, especialmente cuando se crea lo que es esencialmente un software globo de prueba , por así decirlo.

Hay una serie de enfoques que pueden ayudar. En primer lugar, el enfoque TDD puede ayudar a reducir la base del código a lo estrictamente necesario. Si sus pruebas van de la mano con su código, al menos puede tener cierta confianza de que su código se comporta como debería.

Tómate tiempo para refactorizar a medida que avanzas. Una vez que tiene un prototipo y el cliente está súper ansioso por tenerlo en sus manos, es difícil decir que necesita tiempo para pulir lo que (para ellos) está completo. Me gusta registrarme a diario y luego hacer un chequeo de refactor, pero YMMV.

Los desarrolladores que escriben código rápidamente son a menudo una gran demanda. Tuvimos un desarrollador en mi último departamento. Todos los equipos lo querían porque trabajaba súper rápido. Sin embargo, una vez que llegó el momento de probar y liberar su código, las ruedas se soltaron rápidamente. Cosas codificadas, hacks y atajos por todas partes. Sus acciones pronto cayeron - masivamente.

Cortar el código de producción desde el principio puede parecer un lastre, pero dependiendo de su entorno, hay muchas herramientas que pueden eliminar el desarrollo como Ghostdoc y Stylecop .

Vale la pena tener la mentalidad de desarrollo correcta desde el principio. Usted se sorprendería de la cantidad de sistemas de back-of-a-a-a-fag-packet que se suponía que eran solo soluciones de "stop-gap" para convertirse en aplicaciones de piedra angular.

Continuamente

La velocidad de desarrollo es la razón principal para escribir código limpio, legible y comprobable; No se hace por la belleza, ni otros valores abstractos. ¿Por qué me lo negaría y solo lo haría después para algún programador futuro?

Claro que puede haber cambios que sean en su mayoría cosméticos y, por lo tanto, no esenciales; Yo diría que es mucho más útil tener un código moderadamente agradable en este momento, durante el desarrollo, que tener un desastre en este momento y con la esperanza de hacerlo perfecto más tarde (lo cual, seamos sinceros, nunca va a suceder, incluso si tuvieras el tiempo).

Usted hace esto al diferenciar entre el código "Sólo estoy intentando esto para ver cómo funciona" y el código "esto va dirigido al producto". Hay varias maneras de hacerlo.

Uno está bifurcando o cualquiera que sea la palabra en su sistema de control de fuente. Usted crea una rama para el nuevo informe o el nuevo diseño de importación o lo que sea. Si a la gente le gusta, el trabajo de devolverlo a la sucursal principal es un trabajo separado y rastreable. Puede asignársele a alguien e informarlo, y no se espera que suceda mágicamente el día en que la administración (o las ventas) acepte que la característica pertenece al producto.

Otro es picos. Usted no hace ese cambio en el producto. Entra en una aplicación separada, super simple, que existe solo para que tenga un lugar para poner código. Puedes estar tan desordenado como quieras porque solo estás explorando la nueva API o lo que sea. Y nuevamente, si regresa e informa "sí, podemos hacerlo, he descubierto cómo" hay una tarea asignable, reportable y rastreable de escribir código listo para el producto en el producto para hacer lo que quiera.

En ambos casos, listo para el producto significa legible, ordenado, siguiendo los estándares de nomenclatura, con pruebas y cumpliendo con el estilo de su código y los objetivos de rendimiento. En ambos casos, haces visible ese trabajo. Estoy de acuerdo en que no desea hacer todo ese trabajo cada vez que alguien es muy probable que saque la característica del producto. Pero tampoco quieres que el trabajo se vuelva invisible. Trabajar en copias separadas del producto o en un producto no relacionado que es apenas algo más que un arnés de prueba le permite resaltar el trabajo para hacer un código listo para el producto una vez que alguien decida que quiere algo.

La desventaja es que no pueden decidir que quieren algo y lo envían (es decir, la mitad de versión, desordenada, no probada, indocumentada, posiblemente media versión lenta que haya implementado como prueba de concepto) mañana. La primera vez que obtiene un rechazo en ese frente, simplemente pregunte si debería hacerlo de la manera más larga (más costosa) cada vez, por el contrario, reduciendo la velocidad de las funciones rechazadas. Si lo pides correctamente, obtendrás un "no".

Realmente creo que ya entiendes el problema. El problema es que su estilo de codificación requiere que haga demasiados trabajos. La razón por la que se necesita demasiada revisión es porque (a) se combina con una previsión y planificación insuficientes y (b) los parches incrementales a corto plazo que se colocan regularmente durante el desarrollo aumentan la complejidad de cualquier revisión necesaria.

La respuesta por lo tanto, es

(a) cambia tu estilo de desarrollo un poco más hacia la cascada y un poco menos ágil. Sin embargo, no hagas todo el camino, porque la cascada clásica tiene sus propios escollos. Hay un equilibrio saludable para tener. Sé que puede ser preocupante solo pensar en cosas por unos días a veces, como si no se realizara ningún desarrollo, pero hay que confiar en el proceso. En ingeniería, no se puede simplemente juntar cosas y luego clavar cosas en la parte superior y esperar salir con una solución elegante. Si no hay nadie haciendo arquitectura y un diseño técnico de nivel superior, eso significa que es su trabajo. Has estado pagando el precio de descuidar ese trabajo.

(b) intenta evitar parchear las cosas. No piense a largo plazo solo cuando llegue el momento de hacer control de calidad. Realmente debería probar cada pequeña pieza que construya, todo el tiempo, y cubrir todos los casos de entrada, aquellos que no están en el camino feliz también. Un parche / hackeo es casi por definición una solución a corto plazo, que bien puede tener un costo a largo plazo, afecta al costo total de propiedad de los clientes en el sistema. Nuevamente, hay presión para que salga el código, así que tiene que haber equilibrio. Pero trate de no poner soluciones a corto plazo en su lugar, esp. aquellos que juntan los componentes que realmente deberían estar ligeramente acoplados. Se volverá a trabajar, así que hazlo TEMPRANO para que sea mucho más fácil, para evitar los trucos y parches que se acumularán con el tiempo y se volverán inmanejables.

Usted escribe:

  

Cada versión no es más que un prototipo. Así que no pierdo mucho tiempo.   en escribir código super limpio en ese punto porque nunca sé cómo   largo algo dura   ...

     

Luego viene el punto donde el programa está terminado y la decisión   fabricante (s) dice "eso es todo". Tengo un prototipo funcional en este punto,   pero el código interior es un poco desordenado por todas partes durante y   La fase de desarrollo.

Una versión registrada puede ser un "prototipo" en el sentido de que pierde características o algunas características no están completas, pero todo el código registrado debe ser un código de calidad de producción que no necesariamente se debe limpiar.

Creo que estás posponiendo tu "limpieza" a mucho.

Mi regla de oro es:

• Comience con la (sub) característica
• siéntase libre de escribir cosas incompletas e incompletas, tal vez algunos c & p para tener una idea de lo que estoy implementando o si tengo que rascar la última hora de codificación (tenga en cuenta que este puede van de la mano con TDD / tests, es solo que todo está atenuado un poco para obtener una respuesta rápida del espacio de implementación que estoy explorando)
• La subcaracterística "funciona" lo suficientemente bien por ahora
• Ahora haga la limpieza: antes de realizar un SCC .
  • Revise el código para ver lo que es obvio
  • Haga un compromiso de diferencia frente a último para revisar los cambios y tal vez detectar algunos problemas
  • Solucionar cosas que anoté en mi bloc de notas
• Ahora hago el compromiso: esta calidad de código está lista para ser enviada

En este punto, el código comprometido aún puede contener algunas soluciones provisionales o "deuda técnica" que sería bueno limpiar, y tal vez lo limpiaré cuando sea algo natural para una subcaracterística siguiente , pero estará bien si ese código se publica tal como está.