Prefacio do tradutor: Despois de ler este artigo, podes estar sorprendido ou mesmo enfadado. Si, tamén nos sorprendeu: o autor parecía nunca ter oído falar da xerarquía no equipo, de establecer tarefas co estado "faino rapidamente e sen razoar". Si, é certo, é un texto un pouco estraño. De feito, o autor ofrécelle ao programador que asuma o papel de arquitecto de sistemas: entón por que precisa un arquitecto? Pero todas estas obxeccións non deberían ocultarche o principal: por que aínda levamos e traducimos este texto. Non se trata de papeis. Este texto trata dun enfoque e concienciación profesional. A verdade é que mentres simplemente "fagas o que din" sen pensar no significado das túas accións, nunca chegarás a ser un gran programador.
Di "non" ao código adicional. Todo o que tes que facer é xuntar tres letras e dicir a palabra. Intentemos facelo xuntos: "Noooo!"
Pero agarda. Por que facemos isto? Despois de todo, a principal tarefa dun programador é escribir código. Pero necesitas escribir algún código que che se requira? Non! "Saber cando non escribir código é probablemente a habilidade máis importante para un programador". .
Recordámolo: para todos os lectores de "Habr" - un desconto de 10 rublos ao inscribirse en calquera curso de Skillbox usando o código promocional "Habr".
Skillbox recomenda: Curso práctico .
A programación é a arte de resolver problemas. E vós sodes os mestres desta arte.
Ás veces, nun esforzo por comezar canto antes, non pensamos en outra cousa que en completar a tarefa. E isto pode causar problemas aínda máis graves.
Para que fan a vista gorda os programadores?
Todo o código que escribas debe ser comprensible para outros desenvolvedores, así como probado e depurado.
Pero hai un problema: o que escribas complicará o teu software e probablemente engadirá erros no futuro.
Segundo Rich Skrent, . Velaquí o que escribe:
“O código é malo porque comeza a podrecer e require un mantemento constante. Engadir novas funcións moitas veces require modificar o código antigo. Canto maior sexa, maior será a probabilidade de erro e máis tempo levará a compilación. Leva máis tempo para que outro desenvolvedor descubrilo. E se é necesaria a refactorización, definitivamente haberá fragmentos que paga a pena cambiar. O código grande a miúdo significa unha flexibilidade e funcionalidade reducidas do proxecto. Unha solución sinxela e elegante é máis rápida que un código complexo".
Como sabes cando non escribir código?
O problema é que os programadores adoitan esaxerar o número de funcións que necesita a súa aplicación. Como resultado, moitas seccións de código seguen incompletas ou ninguén as usa, pero complican a aplicación.
Debes ter claro o que necesita o teu proxecto e o que non.
Un exemplo é unha aplicación que resolve só unha tarefa: xestiona o correo electrónico. Para iso, introducíronse dúas funcións: enviar e recibir cartas. Non esperes que un xestor de correo se converta nun xestor de tarefas ao mesmo tempo.
Debe dicir "non" firmemente ás propostas para engadir funcións que non estean relacionadas coa tarefa principal da aplicación. Este é exactamente o momento no que queda claro que non é necesario un código adicional.
Nunca perdas o foco da túa aplicación.
Pregúntase sempre:
Que función debería implementarse agora?
Que código debe escribirse?
Desafiar as ideas que se ocorran e valorar as suxestións do exterior. En caso contrario, o código adicional só pode matar o proxecto.
Saber cando non engadir demasiado permitirache manter o teu código base baixo control firme.
Ao principio do camiño, o programador só ten dous ou tres ficheiros fonte. Todo é sinxelo. Compilar e executar a aplicación require un tempo mínimo; sempre está claro onde e que buscar.
A medida que a aplicación se expande, aparecen máis e máis ficheiros de código. Enchen o catálogo, cada un con centos de liñas. Para organizar todo isto correctamente, terás que crear directorios adicionais. Ao mesmo tempo, faise cada vez máis difícil lembrar que funcións son responsables de que e que accións provocan; atrapar erros tamén leva máis tempo. A xestión de proxectos tamén é cada vez máis complexa, non fai falta un, senón varios desenvolvedores para facer un seguimento de todo. En consecuencia, os custos, tanto monetarios como de tempo, están crecendo, e o proceso de desenvolvemento estase a ralentizar.
O proxecto finalmente faise enorme, engadindo cada nova función dáse con máis e máis dificultade. Incluso para algo moi pequeno, tes que pasar varias horas. A corrección dos erros existentes leva á aparición de novos, os prazos para o lanzamento da aplicación vense interrompidos.
Agora temos que loitar pola vida do proxecto. Por que?
O feito é que simplemente non entendeu cando non era necesario engadir código adicional e respondeu "si" a cada suxestión e idea. Eras cego, o desexo de crear algo novo fixo que ignoraras feitos importantes.
Parece un guión de película de terror, non?
Isto é exactamente o que ocorrerá se segues dicindo que si. Tenta entender cando o código non paga a pena engadir. Elimina as cousas innecesarias do proxecto: isto facilitará moito a túa vida e prolongará a vida útil da aplicación.
"Un dos meus días máis produtivos é aquel no que eliminei 1000 liñas de código".
- Ken Thompson.
Aprender a saber cando non hai que escribir código é difícil. Pero é necesario.
Si, sei que acabas de entrar no camiño dun programador e queres escribir código. É bo, non perdas esa primeira impresión, pero tampouco perdas de vista factores importantes por entusiasmo. Descubrimos-o por proba e erro. Ti tamén cometerás erros e aprenderás deles. Pero se podes aprender do anterior, o teu traballo farase máis consciente.
Sigue creando, pero sabe cando dicir que non.
Skillbox recomenda:
- Curso online aplicado .
- Curso en liña .
- Curso práctico anual .
Fonte: www.habr.com