Prefacio del traductor: Después de leer este artículo, es posible que se sorprenda o incluso se enoje. Sí, también nos sorprendió: el autor supuestamente nunca había oído hablar de la jerarquía en el equipo, de establecer tareas con el estado "hazlo rápido y sin razonamientos". Sí, es cierto, este es un texto un poco extraño. De hecho, el autor sugiere que el programador asuma el papel de arquitecto de sistemas. ¿Por qué entonces se necesita un arquitecto? Pero todas estas objeciones no deberían cegarle ante lo principal: por qué, no obstante, tomamos y traducimos este texto. No está hablando de roles. Este texto trata sobre el enfoque profesional y la sensibilización. La verdad es que mientras simplemente "hagas lo que te dicen" sin pensar en el significado de tus acciones, nunca te convertirás en un gran programador.
Di no al código innecesario. Todo lo que tienes que hacer es juntar tres letras y decir la palabra. Intentemos hacer esto juntos: "¡Nooooo!"
Pero espera. ¿Por qué estamos haciendo esto? Después de todo, la tarea principal de un programador es escribir código. ¿Pero necesitas escribir algún código que te pidan? ¡No! "Comprender cuándo no escribir código es probablemente la habilidad más importante para un programador". .
Recordamos: para todos los lectores de "Habr": un descuento de 10 rublos al inscribirse en cualquier curso de Skillbox utilizando el código promocional "Habr".
Skillbox recomienda: Curso práctico .
La programación es el arte de resolver problemas. Y ustedes son maestros en este arte.
A veces, en un esfuerzo por empezar a trabajar lo más rápido posible, no pensamos en otra cosa que en completar la tarea que tenemos entre manos. 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 comprensible para otros desarrolladores y debe probarse y depurarse.
Pero hay un problema: cualquier cosa que escribas complicará tu software y probablemente introducirá errores en el futuro.
Según Rich Skrent, . Aquí está lo que escribe:
“El código es malo porque empieza a pudrirse y requiere un mantenimiento constante. Agregar nuevas funciones a menudo requiere modificar el código antiguo. Cuanto más grande sea, mayor será la probabilidad de que se produzca un error y más tiempo llevará compilar. A otro desarrollador le toma más tiempo resolverlo. Y si es necesario refactorizar, definitivamente habrá fragmentos que valga la pena cambiar. Un código grande a menudo significa una flexibilidad y funcionalidad reducidas del proyecto. Una solución simple y elegante es más rápida que un código complejo”.
¿Cómo sabes cuándo no escribir código?
El problema es que los programadores suelen exagerar la cantidad de funciones que necesita su aplicación. Como resultado, muchas secciones de código quedan sin terminar o nadie las usa, pero complican la aplicación.
Debes entender claramente qué necesita tu proyecto y qué no.
Un ejemplo es una aplicación que resuelve una sola tarea: gestionar el correo electrónico. Para ello, se han introducido dos funciones: enviar y recibir cartas. No debes esperar que el administrador de correo se convierta al mismo tiempo en administrador de tareas.
Debe decir firmemente "no" a las propuestas para agregar funciones que no están relacionadas con la tarea principal de la aplicación. Este es exactamente el momento en el que queda claro que no se necesita código adicional.
Nunca pierda el foco de su aplicación.
Pregúntate siempre:
— ¿Qué función debería implementarse ahora?
— ¿Qué código debo escribir?
Cuestiona las ideas que te vienen a la mente y evalúa las sugerencias que vienen del exterior. De lo contrario, el código adicional puede simplemente acabar con el proyecto.
Saber cuándo no agregar cosas innecesarias le ayudará a mantener su base de código bajo firme control.
Al principio de la ruta, el programador tiene sólo dos o tres archivos fuente. Es sencillo. La compilación y ejecución de la aplicación requiere un mínimo de tiempo; 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 catálogo, cada uno con cientos de líneas. Para poder organizar todo esto correctamente, tendrás que crear directorios adicionales. Al mismo tiempo, cada vez es más difícil recordar qué funciones son responsables de qué y qué acciones las causan; atrapar insectos también lleva más tiempo. La gestión de proyectos también es cada vez más compleja: no es necesario uno, sino varios desarrolladores para realizar un seguimiento de todo. En consecuencia, los costos, tanto monetarios como de tiempo, aumentan y el proceso de desarrollo se ralentiza.
El proyecto eventualmente se vuelve enorme y agregar cada nueva característica requiere cada vez más esfuerzo. Incluso para algo muy insignificante hay que dedicarle varias horas. La corrección de errores existentes provoca la aparición de otros nuevos y el incumplimiento de los plazos de publicación de las solicitudes.
Ahora tenemos que luchar por la vida del proyecto. ¿Por qué?
El hecho es que simplemente no entendiste cuándo no deberías agregar código adicional y respondiste "sí" a cada sugerencia e idea. Estabas ciego, el deseo de crear cosas nuevas te hacía ignorar hechos importantes.
Suena a guión de película de terror, ¿verdad?
Esto es exactamente lo que sucederá si sigues diciendo que sí. Intente comprender cuándo no se debe agregar código. Elimine las cosas innecesarias del proyecto; esto le hará la vida mucho más fácil y prolongará la vida útil de la aplicación.
"Uno de mis días más productivos fue cuando eliminé 1000 líneas de código".
—Ken Thompson.
Aprender cuándo no escribir código es difícil. Pero es necesario.
Sí, sé que acabas de emprender el camino de un desarrollador y quieres escribir código. Está bien, no pierdas esa primera impresión, pero no pierdas de vista factores importantes por culpa del entusiasmo. Nos dimos cuenta de todo mediante prueba y error. También cometerás errores y aprenderás de ellos. Pero si puedes aprender de lo anterior, tu trabajo se volverá más consciente.
Sigue creando, pero sabe cuándo decir que no.
Skillbox recomienda:
- Curso en línea aplicado .
- Curso por Internet .
- curso práctico anual .
Fuente: habr.com