La habilidad principal del desarrollador que mejorará su código



Prefacio del traductor: después de leer este artículo, puede sorprenderse o incluso enojarse. Sí, también nos sorprendió: el autor supuestamente nunca escuchó sobre la jerarquía en el equipo, sobre el establecimiento de tareas con el estado "hacerlo rápidamente y sin razonamiento". Sí, eso es, es un texto un poco extraño. De hecho, el autor le ofrece al programador el rol de arquitecto de sistemas. ¿Por qué necesita un arquitecto? Pero todas estas objeciones no deberían ocultarle lo principal: por qué, sin embargo, tomamos y traducimos este texto. No se trata de roles. Este texto trata sobre el enfoque profesional y la conciencia. La verdad es que si bien "haces lo que dicen" sin pensar en el significado de tus acciones, nunca te convertirás en un gran programador.

Di no al código extra. Todo lo que tienes que hacer es juntar las tres letras y decir la palabra. Intentemos hacerlo juntos: "¡Nooo!"

Pero oye. ¿Por qué estamos haciendo esto? Después de todo, la tarea principal de un programador es escribir código. ¿Pero es necesario escribir el código que se requiere de usted? No! "Comprender cuándo no debes escribir código es probablemente la habilidad más importante para un programador". El arte del código legible .

Le recordamos: para todos los lectores de "Habr": un descuento de 10.000 rublos al registrarse en cualquier curso de Skillbox con el código de promoción "Habr".

Skillbox recomienda: Curso práctico "Mobile Developer PRO" .

La programación es el arte de resolver problemas. Y ustedes son los maestros de este arte.
A veces, tratando de comenzar lo antes posible, no pensamos en otra cosa que completar la tarea. Y esto puede causar problemas aún más graves.

¿A qué hacen la vista gorda los programadores?

Todo el código que escriba debe ser entendido por otros desarrolladores, así como probado y depurado.

Pero hay un problema: cualquier cosa que escriba, complicará su software y probablemente agregará errores en el futuro.

Según Rich Skrent, el código es nuestro enemigo . Aquí está lo que escribe:
“El código es malo porque comienza a pudrirse y requiere un mantenimiento constante. Agregar nuevas funciones a menudo requiere la modificación del código anterior. Cuanto más grande es, mayor es la probabilidad de que ocurra un error y más tiempo toma compilar. Otro desarrollador necesita más tiempo para resolverlo. Y si necesita refactorizar, entonces ciertamente hay fragmentos que vale la pena cambiar. El código masivo a menudo significa reducir la flexibilidad y la funcionalidad de un proyecto. Una solución simple y elegante es más rápida que el código complejo ".

¿Cómo saber cuándo no debes escribir código?


El problema es que los programadores a menudo exageran la cantidad de funciones que necesita su aplicación. Como resultado, muchas secciones del código permanecen incompletas o nadie las usa, pero complican la aplicación.

Debe tener claro lo que su proyecto necesita y lo que no.

Un ejemplo es una aplicación que resuelve solo una tarea: administra el correo electrónico. Se han introducido dos funciones para esto: enviar y recibir cartas. No debe esperar que el administrador de correo se convierta simultáneamente en un administrador de tareas.

Debe decir firmemente no a las sugerencias para agregar funciones que no están relacionadas con la tarea principal de la aplicación. Este es exactamente el momento en que queda claro que no se necesita código adicional.

Nunca desenfoque su aplicación.

Siempre pregúntate a ti mismo:

- ¿Qué función se debe implementar ahora?
- ¿Qué código vale la pena escribir?

Cuestione las ideas que se le ocurran y evalúe las sugerencias del exterior. De lo contrario, el código adicional puede matar el proyecto.

Saber cuándo no debe agregar demasiado mantendrá la base del código bajo estricto control.



Al comienzo de la ruta, el programador tiene solo dos o tres archivos de origen. Todo es simple Compilar y ejecutar la aplicación requiere un tiempo mínimo; siempre está claro dónde y qué buscar.

A medida que la aplicación se expande, aparecen más y más archivos de código. Llenan el directorio, cada uno con cientos de líneas. Para organizar todo esto correctamente, deberá crear directorios adicionales. Al mismo tiempo, se hace cada vez más difícil recordar qué funciones son responsables de qué y qué acciones causan; atrapar insectos también lleva más tiempo. La gestión de proyectos se está volviendo más complicada, no solo una, sino que se requieren varios desarrolladores para realizar un seguimiento de todo. En consecuencia, los costos, tanto monetarios como temporales, están creciendo y el proceso de desarrollo está inhibido.

El proyecto eventualmente se vuelve enorme, agregando que cada nueva función se da con gran y gran dificultad. Incluso para algo muy insignificante tienes que pasar varias horas. La corrección de los errores existentes conduce a la aparición de otros nuevos, las fechas de lanzamiento de la aplicación se ven interrumpidas.

Ahora tenemos que luchar por la vida del proyecto. Por qué

El hecho es que simplemente no entendía cuándo no necesitaba agregar código adicional, y respondieron "sí" a cada oración e idea. Eras ciego, el deseo de crear algo nuevo te hizo ignorar hechos importantes.

Suena como un guión de película de terror, ¿verdad?

Esto es exactamente lo que sucederá si continúa diciendo que sí. Intenta comprender cuándo no vale la pena agregar el código. Eliminar innecesarios del proyecto: esto facilitará enormemente su vida y extenderá la existencia de la aplicación.

"Uno de mis días más productivos fue cuando eliminé 1000 líneas de código".
- Ken Thompson.

Aprender a entender cuando no necesita escribir código es difícil. Pero es necesario.

Sí, sé que acaba de embarcarse en el camino de un desarrollador y desea escribir código. Esto es bueno, no pierda esta primera impresión, pero no pierda de vista factores importantes debido al entusiasmo. Nos dimos cuenta de todo a través de prueba y error. También cometerás errores y aprenderás de ellos. Pero si puede aprender una lección de lo anterior, su trabajo se volverá más consciente.

Sigue creando, pero sabe cuándo decir que no.

Skillbox recomienda:

Source: https://habr.com/ru/post/453178/


All Articles