Hacer que su código sea limpio y hermoso es una excelente manera de cumplir con los plazos. Robert Martin dio en el clavo con una de sus concisas declaraciones: "La única medida verdadera de la calidad del código es la unidad What-The-F**ks/Minute". .” " en el original). Déjame explicarte lo que esto significa. Cada vez que reviso el código, mi cerebro pasa por una de tres emociones:
“¡¿Qué carajo?! ¡¿Que demonios?!" (con disgusto) - Esto no es todo... todo está muy mal....
“¡¿Qué carajo?! ¡¿Que demonios?!" (con admiración) - mmm, ¡lo hizo un tipo inteligente!
“¡¿Qué carajo?! ¡¿Que demonios?!" (con irritación) - algún tipo de confusión, ¡¿de qué estamos hablando?!
Entonces, ¿qué es primordial y qué evaluamos exactamente cuando vemos algún código? Eso es todo: su pureza y belleza. La capacidad de escribir código limpio y hermoso es un indicador de un desarrollador altamente profesional. La formación en esta habilidad se basa en dos componentes: conocimiento y trabajo. El conocimiento te enseña patrones, principios, prácticas, heurísticas. Los necesitas para crecer profesionalmente. Sólo debes absorber este conocimiento como una esponja a través de la práctica constante y el trabajo duro. En resumen, escribir código limpio no es fácil. Este es un trabajo duro y minucioso y tendrás que esforzarte mucho en ello. A través de prueba y error mejorarás repitiendo los mismos pasos una y otra vez hasta encontrar la solución que deseas. Simplemente no existe una manera más sencilla. A continuación se ofrecen algunos consejos que le ayudarán a aprender a escribir código limpio.
Lo que hay en un nombre
Kendrick Lamar (artista estadounidense de hip-hop - nota del editor) señaló una vez con precisión: "Si voy a contar la historia real, tengo que empezar con mi nombre". Los nombres en el desarrollo de software están en todas partes. Nombramos funciones, clases, argumentos, paquetes, programas, todo. Nombramos archivos fuente y libros de referencia y todo lo relacionado con ellos. Nombramos cosas sin cesar y esto se convierte en una parte fundamental del trabajo para crear un código limpio. El nombre que le des a algo debe reflejar la intención. Encontrar un buen nombre no es fácil, lleva tiempo, pero también ahorra mucho tiempo cuando tienes que lidiar con el código y la situación se complica. Así que tenga cuidado con este proceso y no tema cambiar de nombre más adelante si encuentra algo más adecuado. Todos los que se ocupen de su código le estarán muy agradecidos.
Recuerde que el nombre de cualquier variable, clase, función debe responder a tres preguntas principales: por qué existe (variable, función, etc.), para qué sirve y para qué se utiliza.
Esto requiere no sólo buenas habilidades descriptivas, sino también erudición general y una perspectiva amplia. Y nadie puede enseñarte esto mejor que tú mismo.
"Una función" - una cosa
Louis Henry Sullivan (arquitecto racionalista y modernista estadounidense) dijo una vez: "la función determina la forma " . Dijo esto sobre la arquitectura de las casas, pero esto no cambia la esencia. Cada sistema se basa en algún lenguaje de dominio específico que los programadores crean para describirlo con precisión. Las funciones actúan como verbos del idioma y las clases son sustantivos. Muy a menudo, las funciones son primordiales en la organización de un lenguaje de programación y escribirlas correctamente es la esencia de crear un buen código. Sólo existen dos reglas de oro para escribir funciones de calidad:
Deberían ser pequeños
Deben hacer una cosa, una tarea, y hacerlo bien.
Es decir, su función debe ser pequeña y no debe contener estructuras anidadas. Por lo tanto, los niveles de sangría de la función no deben ser más de uno o dos. Este enfoque hace que el código sea mucho más fácil de leer, comprender y comprender. Además, debemos asegurarnos de que las expresiones dentro de la función estén en el mismo nivel de abstracción. Mezclar niveles de abstracción dentro de una función siempre crea mucha confusión y eventualmente conduce a un código inmanejable. Los mejores programadores tratan las funciones como historias que contar, en lugar de simplemente escribir código. Utilizan las herramientas del lenguaje de programación elegido para crear un bloque de código rico, expresivo y limpio que esencialmente puede actuar como un gran narrador.
"Los comentarios no compensan el código incorrecto"
Venus Williams, tenista estadounidense y cinco veces campeona de Wimbledon, dio en el clavo cuando dijo: “Cada uno deja sus comentarios. Así aparecen los rumores " . Los comentarios son como un arma de doble filo, un comentario bien colocado es algo muy útil. Por otro lado, nada abarrota más el espacio que los comentarios frívolos e inútiles. Pero los comentarios más dañinos son aquellos que difunden información errónea y mentiras. En definitiva, los comentarios son una especie de mal necesario. No siempre, pero sí en la mayor parte. ¿Por qué? Es simple, cuanto más antiguo es el comentario, más difícil es mantenerlo y la mayoría de los programadores, como usted sabe, no siempre cambian los comentarios junto con los cambios en el código. El código se mueve y evoluciona. Partes del código se mueven hacia adelante y hacia atrás, pero no hay comentarios. ¡Y esto se convierte en un problema!
Recuerde: un código limpio y claro con pocos comentarios es mucho mejor que un código complejo y desordenado. No desperdicies tu energía explicando el caos que creaste en los comentarios. Será mejor que dediques ese tiempo a limpiar ese desastre.
"El formato del código es siempre una prioridad"
Esto lo dijo nada menos que Robert C. Martin (Robert Cecil Martin), también conocido como el tío Bob, desarrollador, autor de muchos libros sobre desarrollo de software, consultor, coautor del manifiesto Agile, etc. Y agregó: “Formatear código es una forma de comunicación. Y la comunicación es una prioridad absoluta para cualquier desarrollador profesional”. La afirmación anterior no debe subestimarse, porque habla de una de las características más importantes de un excelente desarrollador. El código formateado le permite mirar profundamente en su mente. Queremos impresionar a la gente con nuestra pulcritud, atención al detalle, capacidad para organizar y expresar nuestros pensamientos con claridad. Pero si, cuando la gente mira el código, ve algún tipo de confusión, que recuerda a una vinagreta, sin principio ni fin, esto anula sus esfuerzos y reduce la reputación del desarrollador. ¡Ni lo dudes! Estás muy lejos de la verdad si crees que lo principal en este negocio es que "el código simplemente funciona". Lo más probable es que la funcionalidad que cree hoy cambie en la próxima versión, pero la legibilidad del código no cambiará. El estilo del código y su buena legibilidad hacen que sea más fácil mantenerlo durante mucho tiempo, incluso después de que el código original haya sido modificado hasta quedar irreconocible.
Nunca olvides que en el futuro lo más probable es que lo que se recuerde no sea tu código en sí, sino tu estilo y coherencia. Por lo tanto, asegúrese de que el código esté bien formateado y siga reglas simples que sean comprensibles para todos los miembros del equipo.
Primero crea un bloque "try-catch-finally"
Georges Canguilhem (historiador de la ciencia, filósofo) señaló con razón: "Cometer errores es natural para una persona, pero insistir en los errores es del diablo " . La resolución de problemas es algo que hacen todos los programadores. Es posible que entren datos no válidos en la entrada y que los dispositivos fallen. Y como desarrolladores, debemos asegurarnos de que el código haga lo que se supone que debe hacer. El problema no es sólo el manejo de errores, sino un manejo de errores “limpio y fácil de leer”. Muchos programas se adaptan al manejo de errores. Si haces esto, todo se hundirá en tal caos que el propósito y la lógica del código principal se destruirán. Esto está mal, no debería ser así. El código debe ser limpio y confiable, y el manejo de errores debe integrarse de manera transparente y natural en el código. Este es un indicador de un programador de clase alta. Y una de las formas de lograrlo es mediante el anidamiento y la cobertura adecuados de todos los errores en los bloques try-catch. Estos bloques definen el alcance de su código. Cuando ejecuta código en la parte de prueba de un bloque try-catch-finally, está indicando que la ejecución puede cancelarse en cualquier momento y luego reanudarse en una captura. Por lo tanto, recomendamos comenzar con try-catch-finally cuando escriba código. Esto ayudará a determinar qué puede esperar el usuario del código, independientemente de lo que salga mal durante el intento.
Recuerde siempre que cada excepción que lance debe contener suficiente contexto para determinar la ubicación y el origen del error. Los mensajes de error creativos e informativos se recuerdan mucho después de que se haya escrito el código, incluso cuando el programador ya está ocupado con tareas completamente diferentes.
resumámoslo
Una frase inusual nos ayudará a resumir todo lo anterior. Esto es sentido del código o "un sentido del código común", una especie de equivalente del sentido común para los programadores. En palabras de Robert Martin: “Escribir código limpio requiere el uso sistemático de muchas técnicas pequeñas, aplicadas como resultado de una meticulosa y algo dolorosa sensación de “limpieza”. Estas pequeñas técnicas se denominan colectivamente sentido del código " . Algunos de nosotros tenemos este “sentido del código sólido” desde el principio, mientras que otros tienen que desarrollarlo mediante la práctica persistente. Este instinto ayuda no sólo a reconocer la diferencia entre código bueno y malo, sino que también ayuda en la formación de estrategias destinadas a transformar el código malo en bueno. Un código incorrecto lo arruina todo. Hablando en sentido figurado, si cubres el pastel más delicioso con mierda de perro, entonces... eh... a casi nadie le gustará. Code sense ayuda al programador a utilizar las herramientas adecuadas para lograr su objetivo de crear código limpio. Un programador que entiende qué es el sentido del código es un artista que puede crear una obra de arte en una pantalla en blanco que será recordada durante muchos años. Como lo resumió Harold “Hal” Abelson, profesor de informática en el Mit y director fundador de Creative Commons y la Free Software Foundation: “Los programas deben escribirse primero para que la gente pueda leerlos y luego para que puedan ser leídos”. ejecutado.” coche” . Lo que puede leer sobre el tema: "Un manual de artesanía en software ágil" - Robert Martin. “Un manual de estimación ágil” - Mike Cohn Sobre el autor: Ravi Shankar Rajan es director global de programas de TI de Mumbai (India). Famoso blogger, poeta de haiku, ávido aficionado a la arqueología y la historia. Puedes conectarte con él en Twitter , Medium , LinkedIn
GO TO FULL VERSION