Aquí he utilizadoInteligente，PerezosoyProgramadorEstas palabras. Lo que quiero decir con estas palabras es:
- Programador: alguien con energía positiva, enfocado en usar código para resolver problemas del mundo real, no se refiere a los soñadores, aquellos que solo piensan y nunca actúan.
- Inteligente: capaz de pensar los problemas de manera integral (no aquellos que usan pequeñas artimañas).
- Perezoso: es como el lazy-loading en programación, se refiere a retrasar el momento de escribir código (no a quienes no hacen nada).
El desarrollo de software correcto debería ser desarrollo perezoso, también llamado desarrollo paciente; esta forma de desarrollo se manifiesta en que, antes de escribir código realmente, el programador debe dedicar mucho tiempo a considerar todas las soluciones y enfoques posibles. Esto puede verse comoretrasarla escritura de código. Nunca escribas código antes de comprender completamente el problema. Primero entiende bien el problema, asegúrate de que el código que se va a escribir realmente resuelva el problema; esto evitará que luego escribas una gran cantidad de código inútil.
Lo que aquí se diceprimero aclarar el problema, se manifiesta en:
- Entender realmente los requisitos, hacer que el departamento de producto (departamento de análisis de negocio) aclare cuáles son sus verdaderas necesidades.
- Estos departamentos normalmente no dan suficiente tiempo para organizar los requisitos.
- A menudo no consultan a expertos en el dominio del problema, sino que siguen las opiniones de los líderes.
- Por lo general no pueden proporcionar opiniones de requisitos coherentes o completas.
- Tener claro qué interacciones se necesitan con otros programadores del equipo o de otros equipos, y cómo interactuar; esto incluye:
- Comunicarse usando una pizarra
- Dibujar diagramas de flujo (UML o Visio)
Necesitas dedicar mucho tiempo a investigar para asegurarte de que los requisitos se ajusten a la realidad, y para hacer un trabajo que dé a ti y a tus colegas un lenguaje y una semántica comunes en la comunicación. Sin embargo, a los programadores les gusta lanzarse de inmediato a programar y teclear código sin parar frente a la computadora.
En el desarrollo de software real, solo el 5% del tiempo de desarrollo es eficiente (puedes consultar «La paradoja de la eficiencia del programador»). Si encuentras a un programador que pasa el 100% del tiempo mirando la pantalla, entonces ese programador que ves es el peor programador.
Si un programador siempre está codificando frente a la computadora, es sin duda una mala señal.
Los programadores eficientes siempre verifican constantemente su comprensión de los requisitos, asegurándose de que su código y los requisitos esténsincronizados. Los programadores eficientes se comunican con frecuencia con los gerentes de producto / personal de negocios; a menudo puedes verlos usando pizarras para discutir con colegas y arquitectos. La experiencia y el recorrido del programador se utilizan para mejorar la eficiencia del desarrollo; los mejores programadores:
- Pasan más tiempo pensando en el código y menos tiempo escribiéndolo.
- La comprensión profunda del problema hace que la depuración del código sea más rápida.
- El código bien pensado es más rápido.
- El código es más corto.
Psicológicamente, a los programadores les encanta su propio código.
A los malos programadores no les gusta modificar el código malo ya escrito. En lugar de optimizar su propio código, prefieren simplementeagregarmás código para compensar los defectos anteriores. Peor aún, les gusta culpar a los demás. Al final, sobre un montón de código que no funciona bien se apila otro montón, y todo el sistema se llena de bugs y es extremadamente inestable.
Los buenos programadores también suelen escribir código malo, pero pueden ver qué código necesita optimización y cuál necesita reescritura. La diferencia entre un buen programador y uno que no lo es radica en la actitud hacia el código problemático. Lo que hacen los buenos programadores es:
- Si el código es bueno en general, refactorízalo.
- Si el código tiene problemas en general, reescríbelo.
Cuando hay partes del código que necesitan optimización o reescritura, cuanto más tiempo pase, más difícil será volver a resolver estos problemas. Porque habrá cada vez más programas que dependan de este código, cada vez de manera más profunda; cuando optimices este código, las dependencias relacionadas también necesitarán modificaciones correspondientes. Cuando los problemas acumulados sean cada vez más, optimizar/reescribir fácilmente este código se habrá vuelto imposible. Y usar la manera de seguir añadiendo código para compensar los problemas anteriores hará que el sistema sea cada vez más inestable.
Si no lo tienes claro en tu mente, sé un poco perezoso y retrasa el momento de escribir código.