Cómo escribir menos código [cerrado]

Una cualidad que me gustaría desarrollar es escribir un código más conciso. Con una escritura más concisa, al menos en mi opinión, la oportunidad de agregar errores al código es menor. Es más fácil leer el código para otro.

Mi pregunta es si es algo que solo viene con experiencia o es algo que puedes hacer explícitamente para desarrollar esa calidad.

Diría que, en general, es algo que viene con el tiempo y la experiencia, pero es posible que si trabajas con idiomas más concisos, devuelves esa calidad a tus idiomas de trabajo habituales.

Ciertamente, después de un año o dos trabajando con Ruby, encontré que mi C # se volvió mucho más tenso. Creo que si entendiera mejor la programación funcional (una ambición continua) probablemente tomaría más de eso.

También hay algunas pautas que pueden ayudar, por ejemplo, si escribe las mismas dos líneas más de una vez, divídalas en su propio método. Esa es una pauta simple pero reduce rápidamente las líneas de código y la programación de cortar y pegar, de la cual la mayoría de nosotros somos culpables de vez en cuando.

Si comprende la herencia, a menudo puede ahorrar repitiendo el mismo código en diferentes lugares al proporcionar una funcionalidad común a las clases primarias. Esto es obvio en principio, pero algo que la gente suele pasar por alto en la práctica.

Puede haber una diferencia entre escribir menos código y tener menos código en su aplicación; a veces puede usar la generación de código para evitar tener que repetirlo, por lo que solo escribe unas pocas líneas de código, pero luego generan una gran cantidad de otro código para usted - Eso puede darle mucha influencia. Mire lo que hace una herramienta como Rails o Entity Framework a este respecto para comprender cuán útil puede ser. Sin embargo, sea claro acerca de la necesidad y piense dos veces, tres veces y luego cuatro veces sobre la creación de su propio código, eso puede llevarlo al infierno de YAGNI.

Comprenda su idioma, su API y sus herramientas. Una vez más, esto parece obvio, pero a lo largo de los años he escrito tanto código que más tarde me di cuenta de que estaba reproduciendo una funcionalidad que podría haber heredado de la API o haber utilizado una función de lenguaje para simplificar que me di cuenta de que algunas horas de lectura sobre la documentación para la API con la que estoy trabajando me ahorrará muchas horas de codificación o depuración más adelante. Del mismo modo, la mayoría de las plataformas con las que trabaja tienen un gran potencial: aprenda a trabajar de la manera que esperan y su vida será mucho más fácil. Dedique algo de tiempo a encontrar la dirección de menor resistencia para la plataforma con la que está trabajando y hará que las cosas se hagan mucho mejor.

Si se pregunta si hay una mejor manera de hacer algo, probablemente la haya y siempre vale la pena descubrir cómo hacer las cosas mejor.

Una excelente manera de escribir menos código es tratar de evitar reinventar la rueda y usar los componentes de software existentes cuando estén disponibles.

Una respuesta común que obtengo cuando pregunto por qué las personas hicieron su propio ORM, o su propio motor de registro, o sus propios componentes de la interfaz de usuario, o su propio todo:

Pero nuestro es mejor

Creo que esta afirmación es correcta en la mayoría de los casos, pero el impacto negativo en el ROI es muy alto en la mayoría de los casos. Tu mamá hace los mejores platos ¿verdad? Pero no puedes pedirle a tu madre que venga a casa y los prepare todos los días.

Es por eso que creo que los desarrolladores deberían interesarse en el impacto financiero de sus elecciones. Algunos de ellos son:

• Se requiere trabajo adicional para construir el componente
• Trabajo extra para principiantes para aprenderlo
• Enorme trabajo extra para mantenerlo

Me gusta pensar que esos proveedores de componentes son su equipo extenso que trabaja para usted por una pequeña fracción de lo que habría pagado para construirlo, mantenerlo y mejorarlo usted mismo.

Es mejor que toda la empresa obtenga el ROI máximo en lugar de trabajar para maximizar la satisfacción de nuestro ego;) Cuanto más dinero obtenga su empresa, más probabilidades habrá de que aumenten sus condiciones de trabajo y su salario.

En mi opinión, escribir menos código se puede hacer de varias maneras:

• No lo vas a necesitar . No codifiques algo que aún no necesitas. Codifique solo los requisitos. De esta manera, reduciremos el código necesario para escribir.

• No te repitas . Creo que usar CMS, framework o la biblioteca de terceros es una forma de aplicar el principio DRY.

• Abstracción . Y por último, pero no menos importante, la programación de abstracción también puede reducir el código mucho. Al abstraer el código, la posibilidad de reutilizar el código aumentará porque reduce la duplicación.

Más allá de la comprensión de un lenguaje de programación, creo que la propia comprensión de un problema y encontrar una buena solución tiene mucho que ver con eso. Hay muchas soluciones para la mayoría de los problemas, no todos son óptimos. Puede conducir de la ciudad A a la ciudad B a través de diferentes caminos: uno podría tomar dos horas, el otro podría tomar el doble. Es la misma idea en programación. Es posible que conozca muy bien un idioma, pero puede encontrar una solución que tome, por ejemplo, dos páginas de código, mientras que otra persona encontrará una solución que se pueda implementar en un cuarto de la mitad del tamaño del código. Lo he visto mucho a lo largo de los años.

Asegúrese de comprender bien el problema. Analícelo, proponga soluciones, evalúe los pros y los contras (por supuesto, "las soluciones con una 's' 'variarán mucho de un problema a otro, solo hablando aquí en general). Luego está la implementación de la solución elegida, que es donde entrará en juego su comprensión del lenguaje (y el marco, si corresponde).

Se puede decir que todo el arte de la programación se reduce a esto.

Puede estudiar idiomas que tienen un énfasis tradicional en la claridad y concisión (por ejemplo, Haskell, Scheme, Python), o incluso paradigmas terser como Factor y otros lenguajes concatenativos, pero en última instancia, todo lo que podría elegir estudiar debería contribuir a ayudarlo a escribir más brevemente , código menos redundante.

Como todas las otras aflicciones, si no admite tener un problema, no va a buscar una solución. La experiencia comienza a ser un factor cuando aprende cómo se ve menos código. Cuando vuelve a visitar su código, es un buen momento para determinar si puede reutilizar el código o refactorizarlo con menos código. Microsoft pudo mejorar la velocidad de impresión con Windows 2000 al NO ponerla en cola dos veces (cita del empleado de Microsoft en una de sus demostraciones gratuitas).

1. Regrese a su antiguo código de largo aliento,
2. ponlo bajo control de versiones,
3. escriba algunas pruebas para que tenga una esperanza razonable de no introducir nuevos errores,
4. volver a escribir.

Repita ad libitum. Y bienvenido al infierno.

El desarrollo impulsado por pruebas podría ayudar. Con esto, solo escribe el código mínimo requerido para pasar esa prueba.