Algunos podrían argumentar que cuantas menos líneas de código haya en una aplicación, más fácil será leerla. Esta declaración es solo parcialmente cierta, creo que las métricas para la legibilidad del código incluyen:
El código debe ser consistente
El código debe ser autodescriptivo
El código debe tener buena documentación.
El código debe usar características modernas estables
El código no debe ser demasiado complejo.
El rendimiento del código no debe ser un problema (no escriba código que sea intencionalmente lento)
Si la reducción de líneas de código afecta alguno de los anteriores, entonces algo anda mal. De hecho, básicamente reducir la cantidad de líneas de código afectará el estándar anterior, por lo que siempre habrá problemas. Sin embargo, si puede lograr cumplir con las condiciones anteriores, entonces la cantidad de líneas de código es perfecta y no hay necesidad de contar números en absoluto.
1 No hay lenguaje bueno o malo
Alguien siempre dice:
"C es mejor que X porque C tiene un mejor rendimiento".
"Python es mejor que X porque Python es más conciso".
"Haskell es mejor que X porque Haskell es un lenguaje extraño".
En pocas palabras, comparar lenguajes de programación es una tontería en sí mismo. Son idiomas, no Pokémon.
No me malinterpreten, hay diferencias entre idiomas, es solo que los idiomas "buenos para nada" son una minoría después de todo (aunque hay muchos idiomas obsoletos). Cada idioma tiene sus ventajas únicas y, en este sentido, los idiomas son como herramientas en una caja de herramientas. Un destornillador puede hacer cosas que un martillo no puede, pero ¿diría que un destornillador es mejor que un martillo? (Obviamente un martillo es mejor).
Antes de hablar sobre cómo evaluar idiomas, quiero hacer un punto. Hay algunos casos en los que la elección del idioma sí importa, y algunos idiomas obviamente no pueden manejar ciertas situaciones. Si escribe código front-end, ni siquiera tiene derecho a elegir un idioma. Hay determinadas situaciones en las que el rendimiento es importante y el lenguaje X no es una opción, pero son poco frecuentes. A menudo, la elección del idioma es una de las cuestiones menos importantes en un proyecto.
Estos son los factores principales que creo que debe tener en cuenta al elegir un idioma (de mayor a menor prioridad):
Número de recursos en línea (como el número de preguntas en StackOverflow)
velocidad de desarrollo
probabilidad de error
La calidad y amplitud del ecosistema de paquetes de software
características de presentación
Dificultad para reclutar talento (lo siento, COBOL)
También hay lazos estrechos que no se pueden controlar. Si trabaja en ciencia de datos, necesita usar Python, R o Scala (y tal vez Java). Si se trata de un proyecto paralelo, siéntete libre de elegir lo que te gusta. Solo hay una regla que siento que no es negociable: si la mayoría de los problemas que encuentro no se pueden resolver directamente a través de StackOverflow, me negaré a usar este lenguaje. No es que sea incapaz de resolver problemas, pero no creo que valga la pena el tiempo.
2 Es difícil leer el código de otras personas
Leer el código de otras personas es difícil. Robert C. Martin habla de esto en "Clean Code":
"De hecho, la proporción de tiempo dedicado a leer código y escribir código es mucho mayor que 10:1. Constantemente leemos código antiguo a medida que escribimos código nuevo. ... [Por lo tanto,] nuestro código debe ser fácil de leer y escribir. .”
Durante mucho tiempo, pensé que era malo para leer el código de otras personas. Con el tiempo, me di cuenta de que casi todos los programadores tienen dificultades para leer el código de otras personas a diario.
Leer el código de otras personas es como aprender un idioma extranjero. Incluso si está muy familiarizado con un idioma determinado, aún necesita usar los diferentes estilos y arquitecturas de otras personas. Y generalmente asumimos que las personas que escriben el código implementan consistencia y confiabilidad, pero a veces no es así, lo cual es realmente un problema difícil de superar. Pero he encontrado muchos consejos útiles.
Leer el código de otras personas puede mejorar en gran medida su capacidad para leer código. En los últimos dos años, he visto muchas relaciones públicas en Github. Cada vez que leo un PR, siento que mi habilidad para leer el código de otras personas ha mejorado un poco. Los PR en Github son especialmente útiles por las siguientes razones:
Puedes practicar en cualquier momento, solo encuentra un proyecto de código abierto en el que quieras contribuir.
Practique leyendo el código de otras personas dentro de un cierto rango (PR funcional o PR de corrección de errores).
Preste atención a los detalles requeridos e intente leer cada línea.
Existe otra técnica útil para leer el código de otras personas, que es más exclusiva. Este truco me viene a la mente para reducir drásticamente el tiempo que lleva leer un código base desconocido. Después de ver el código en el estilo que quiero leer, primero abro vi y empiezo a escribir código en el estilo usado en el proyecto. Esto reducirá la extrañeza del código.
3 Nunca puedes escribir un código "perfecto"
Antes de unirme al equipo, fui desarrollador "lobo solitario" durante 4 años. La mayoría de las veces, asumo que cada programador escribe un código perfecto. Pensé que con un poco de esfuerzo y tiempo, también escribiría un código "perfecto". "Manual de desarrollo de Java (Edición Songshan)" Le sugiero que lo lea.
En el pasado, solía preocuparme mucho por esto. Después de unirme al equipo, descubrí rápidamente que nadie puede escribir código "perfecto". Sin embargo, el código que ingresa al sistema es casi siempre "perfecto", ¿por qué? La respuesta está en las revisiones de código.
Tenemos muy buenos ingenieros en nuestro equipo. Son los programadores más capaces y confiados. Si alguien sugiriera cometer código sin revisar, todos en nuestro equipo (incluyéndome a mí) lo aceptarían. Incluso si crees que eres el próximo Bill Gates, cometerás errores. Ni siquiera es necesario que se produzcan errores lógicos, e incluso los errores tipográficos y las palabras que faltan son inevitables. Estos son problemas que su cerebro no tiene tiempo para solucionar, por lo que necesita que alguien más lo revise por usted.
Esfuércese por trabajar con personas que presten atención a los detalles y estén felices de criticar su código. Si bien puede ser difícil escuchar críticas al principio, es la única manera de seguir mejorando. Haga todo lo posible para evitar la resistencia durante el proceso de revisión del código y absténgase de hacer comentarios personales. Intenta tener razón sobre las cosas y no sobre las personas.
Al revisar el código, si el autor del código tomó una decisión con la que no estoy familiarizado, buscaré inmediatamente en Google para ver si su elección no coincide con la opinión popular. No digo que la opinión popular siempre tenga la razón, solo que la opinión popular es la opción predeterminada. Si alguien decide no seguir la opinión predominante, también está bien, solo necesito saber si tiene sentido. Al revisar el código, es crucial que comprenda la lógica detrás de las decisiones. Además, mirar el mismo problema con la "mente de un principiante" a menudo puede revelar cosas que la persona ha dejado atrás.
4 El trabajo de programador no significa que tengas que ceñirte a 8 horas de programación todos los días
¿Cuántas horas al día programa el desarrollador promedio o "excelente"? Esta es una pregunta muy común, pero nadie ha dado una respuesta definitiva.
Muy pocas personas escriben código durante más de 4 horas al día.
Las personas que no están de acuerdo con esto son una excepción o la empresa debería apreciarlas. La programación es un trabajo agotador que requiere mucha concentración. Pedir a los programadores que escriban de 5 a 8 horas de código todos los días no es humano. En raras ocasiones, alguien trabajará horas extra para cumplir con los plazos o para el pago de horas extra, pero esto es raro. De hecho, lo que quiero decir con "muy pocos casos" aquí es casi ninguno. Si está trabajando horas extra debido a problemas de planificación o falta de contratación, no lo tolere.
Francamente, escribir 8 horas de código al día no le hace ningún bien ni a usted ni a la empresa. Si tu jefe hace tal pedido, solo se puede decir que es miope, porque a la larga, este tipo de trabajo de alta intensidad tiene un impacto negativo en la productividad y la salud mental.
Tenga en cuenta que no estoy sugiriendo que solo trabaje 4 horas al día. Por lo general, debemos dedicar las 4 horas restantes a las siguientes tareas:
Investigación y desarrollo sobre temas laborales y no laborales
Discutir el trabajo con los colegas
Ayuda a otros compañeros trabajadores
plan de trabajo futuro
revisión de código
la reunión
Más allá de eso, recomiendo tomar descansos regulares y hacer ejercicio (incluso si es solo un entrenamiento corto) durante su día de trabajo. Resulta que el ejercicio puede ser de gran ayuda para aliviar la fatiga mental. Descubrí que hacer ejercicio es especialmente útil cuando tengo problemas para concentrarme.