Cómo escribir código eficiente a pesar de los plazos de entrega pesados

Estoy trabajando en un entorno en el que tenemos muchos proyectos con plazos estrictos de entregables. Incluso hablamos directamente con los clientes, por lo que es imprescindible hacer el trabajo rápidamente.

Mi problema es que siempre escribiría código para la primera solución que se me ocurra, que por supuesto pensé que era la mejor en ese momento. Sin embargo, siempre termina siendo feo y luego me di cuenta de que hay mejores maneras de hacerlo, pero no puedo permitirme cambiar debido a restricciones de tiempo.

¿Hay algún consejo para que mi código sea eficiente y se entregue a tiempo?

Si necesita mantener el código, explique que se necesita tiempo adicional para que el código sea más fácil de mantener, lo que les ahorrará dinero en el backend. En otras palabras, haga que el código mantenible sea un requisito.

Si no les importa eso, no creo que deba hacer nada diferente, aparte de mejorar todo el tiempo y hacer lo mejor que pueda para incorporar las mejores prácticas siempre que sea posible.

De acuerdo, esto puede sonar un poco loco, pero juro que funciona. No es solo para programar, es una receta para una mayor creatividad, concentración y memoria:

• Comer bien
• Meditar
• Duerma lo suficiente (7-9 horas dependiendo de la persona)
• Siesta siempre que tu cerebro esté borroso
• Ve a dormir con un problema sin resolver. No termines tu día con todo completo. Deje pendiente una tarea difícil: su subconsciente es notablemente efectivo.
• Usa ropa cómoda
• Ejercicio
• Tómese el tiempo para hacer ejercicios mentales de memoria: sudoku (no programado), crucigramas, ejercicios de matemáticas, rompecabezas espaciales, etc.
• Realice experimentos objetivos sobre usted mismo para ver cuál de sus comportamientos impacta el desempeño (necesitará una forma confiable de evaluar el desempeño para que esto funcione).
• Atiende tu salud espiritual
• Calzoncillos de algodón
• Atiende tu salud sexual
• Haga tiempo para su familia y amigos.
• Conviértete en experto en algo fuera de tu profesión (música, cocina, deportes, etc.) y socializa con otras personas que hacen lo mismo
• Para algunas personas, una mascota es imprescindible

Antes de que se dé cuenta, verá una notable mejora en la productividad de su programación y la calidad de las soluciones (sin mencionar las mejoras en otras áreas).

Fuentes:

1. Su cerebro milagroso: maximice su capacidad intelectual, aumente su memoria, eleve su estado de ánimo, mejore su coeficiente intelectual y creatividad, prevenga y revierta el envejecimiento mental
2. El yo cuantificado
3. Seth Roberts - en Scientific American

Es contrario a la intuición, pero probablemente deba reducir la velocidad. Cuando implementa la primera solución que le viene a la mente, crea mucho trabajo adicional para usted en el futuro. Por "en el camino", me refiero tan temprano como esa tarde. Los problemas que crea para usted no tardan meses en desarrollarse. Considera tus opciones. Escribe menos y reflexiona más. Incluso en un proyecto corto, encontrará que menos codificación puede acelerarlo.

Si sus clientes se agrupan en industrias específicas, intente construir proyectos que tengan componentes reutilizables. No escribir código es más rápido que escribirlo.

Desde la perspectiva de su cliente, esto huele un poco a " Rápido, bueno y barato, elija dos ". Claro, todos queremos lo que deseamos de inmediato, pero sus clientes deben considerar si esto es lo mejor a largo plazo. Trate de articular las compensaciones y ayúdelos a tomar buenas decisiones.

Busca otro trabajo.

Encontrará que después de unos 6 meses. a un año en el que no te sentirás orgulloso del trabajo que has realizado. Además, no habrá dedicado tiempo a aprender sobre nuevas técnicas, tecnologías o marcos, por lo que después de un año, no podrá mantenerse al día con las nuevas tecnologías. Serás un peor programador en relación con el mercado después de un año que al principio.

Si pasa demasiado tiempo (digamos un par de años o más), tendrá dificultades para ser contratado en cualquier lugar, excepto para este tipo de trabajos rápidos en los que no se aprecia el código de calidad, solo la velocidad.

Dicho esto, como una experiencia de aprendizaje del "mundo real", hay algo que decir sobre el entorno de ritmo rápido, pero diría que alrededor de 6 meses. es suficiente. Más allá de eso, debe buscar conectarse con un par de reclutadores y buscar un lugar mejor. Serás mucho más feliz, honesto.

Desde el punto de vista de sus clientes, la eficiencia del código puede no ser tan crítica y puede ser bastante costosa. En estos días, el tiempo dedicado a la creación de código debe ahorrar horas de tiempo de CPU para justificar una hora de su tiempo. Para la mayoría de los programas, la eficiencia no es tan crítica. Incluso para aquellos donde está, la mayor parte del código no necesita ser tan eficiente. Dada la opción, mi preferencia sería una solución fácil de mantener en lugar de un código más eficiente y más difícil de mantener.

Tomar tiempo para planificar su codificación antes de comenzar puede darle tiempo para evaluar soluciones y considerar enfoques alternativos. Esto debería ahorrarle tiempo en la codificación y las pruebas. He descubierto que a menudo el código más simple es más eficiente.

Diseñe el código limpiamente usando tantas líneas como sea necesario. El código complejo puede confundir al optimizador y puede resultar en un código más lento. Los compiladores modernos son muy buenos para optimizar el código, confía en él para hacer su trabajo.

Acepta que lo suficientemente bueno es lo suficientemente bueno. Cuando encuentre enfoques más eficientes, anótese. Si tiene tiempo, compare algunos de sus diseños más eficientes con los que implementó. Pruébelos en el pequeño (solo el código efectuado) así como en el grande (el programa que los usa). Esto le dará una idea de cuándo es apropiado un enfoque más eficiente.

Muchas personas consideran que la optimización prematura es un mal enfoque. Puede ser costoso implementarlo. Desafortunadamente, muchas optimizaciones prematuras en realidad no son eficientes como el código que optimizaron. Para optimizar el código correctamente, debe instrumentar el código antes y después del cambio para ver si realmente ha mejorado la eficiencia.

Estudie técnicas que lo ayuden a escribir código más limpio con bajo acoplamiento y alta cohesión. En muchos casos, reducir la complejidad aumenta la eficiencia. Las técnicas que lo ayudan a minimizar los errores que debe corregir durante el desarrollo lo ayudarán a entregar más rápido. Esto puede liberarle tiempo para probar enfoques alternativos.

Robert cubrió los aspectos más importantes.

He trabajado en tales entornos, donde el código no (no puede) vivir por más de seis meses. Hay algunas reglas básicas que se me ocurren:

1. Utilice bibliotecas de código abierto, soluciones de terceros, etc. El aprendizaje involucrado se amortiza con menos mantenimiento y depuración. Sin embargo, si está atrapado con una biblioteca con errores, está condenado.
2. Asegúrese estrictamente de que su diseño sea extensible. Un requisito obligatorio: la mayor parte del trabajo viene como mejoras, no como la creación de nuevas características.
3. Construye planes de prueba rigurosos. Obtenga un control de calidad o automatice las pruebas para garantizar las pruebas de regresión.
4. Utilice herramientas inteligentes: IDE, utilidades de generación de código, etc.
5. Mantenga las cosas lo más configurables posible. (La otra cara es un mayor esfuerzo de prueba)
6. Mejora tu velocidad de escritura :-)

En la fase de diseño, hable con sus colegas .

Discuta su diseño y cómo quiere hacerlo, y pídales que analicen sus decisiones. Si todos están de acuerdo en lo que es inteligente, tienen un diseño mucho más sólido.

Práctica. Practique escribiendo buen código hasta que se convierta en una segunda naturaleza. Luego practique la codificación más rápido. Luego practica mejor la codificación. Y cuando termines ... practica un poco más.

Mi problema es que siempre escribiría código para la primera solución que se me ocurra, que por supuesto pensé que era la mejor en ese momento.

No, ese no es tu problema. Eso es una virtud. Está haciendo lo más simple que podría funcionar. Pero solo funciona cuando se combina con la refactorización. Es un proceso continuo: hacer la siguiente cosa más simple que podría funcionar, una y otra vez, para que su sistema sea siempre una expresión de su comprensión actual del espacio de la solución.

Su problema es que tiene una administración que no comprende el verdadero costo del ciclo de vida de los sistemas de software. El 90% de ese costo es mantenimiento, no implementación inicial. Las pruebas y la refactorización son nuestras mejores herramientas para reducir costo total del ciclo de vida de un sistema de software. Si sus gerentes no le permiten hacer estas cosas, son irresponsables y deben ser reentrenados. O necesita encontrar un nuevo trabajo.

Finalmente: como dije antes *, necesitas aprender a decir que no .

* ¿Cómo codificar en un horario muy apretado?

Si fijaron el alcance y el tiempo, todo lo que puede hacer para cumplir el plazo es reducir la calidad.

Si es posible, elimine la calidad externa, visible para las partes interesadas, no comprometa la calidad interna, lo que perjudica su habitabilidad en la base de código.

Realmente no creo que la superación personal te vaya a ayudar en esta situación. En todo caso, lamento decirlo, generalmente es asertividad.

Trate de poner un pie en la puerta cuando se estima el trabajo. ¿Cómo puede su jefe estimar cuánto tiempo le toma hacer algo?

Traiga opciones a su jefe y / o cliente. Con demasiada frecuencia, son los propios desarrolladores los que eligen perder calidad sin comunicar nada. Los proyectos / trabajos tardíos son muy comunes y típicamente 'gestionados'. Actúe a tiempo, advierta a las personas si ve que se acerca un plazo vencido.

No pueden reducir el alcance o mover la fecha límite si no les dices nada.

Si va a comprometer la calidad de cualquier forma, intente que sea su decisión. Dales cosas para que se pesen unos contra otros.

Algunas cosas que solo USTED puede decidir. Si lo tienes a punto de funcionar. Pero es muy imposible de mantener. Quizás no esté seguro si funciona en todos los casos. No le digas a nadie que has terminado. Vuelvelo a hacer. Muy a menudo es una decisión que solo tú puedes tomar. Ya sea porque el problema lleva mucho tiempo articularse o porque tiene un gerente no técnico.

A veces es parte de su ética de trabajo, ¿podría coser a un paciente sin lavarse las manos porque "no hay tiempo"?

Sobre todo, recuerde: no hay más tarde.

Soy un desarrollador .Net que trabaja en aplicaciones web.

Lo que he comenzado a hacer es ...

Si es un código C #, primero trato de escribir ese código en LinqPad (si es posible).

Si es un código Javascript, primero escribo ese código y lo pruebo en jsfiddle / jsbin (si es posible).

Descubrí que esto ayuda con la calidad del código pero no me ralentiza (y en varios casos, me pareció más rápido).