Desde principios de 2018, ocupo o posto de xefe/xefe/desenvolvedor principal do equipo; chámalle como queiras, pero a cuestión é que son totalmente responsable dun dos módulos e de todos os desenvolvedores que traballan. sobre el. Esta posición dáme unha nova perspectiva sobre o proceso de desenvolvemento, xa que estou implicado en máis proxectos e máis activamente na toma de decisións. Recentemente, grazas a estas dúas cousas, decateime de súpeto de canto afecta a medida de comprensión ao código e á aplicación.
O punto que quero subliñar é que a calidade do código (e do produto final) está intimamente relacionada coa conciencia do que están a facer as persoas que están a deseñar e escribir o código.
Podes estar pensando agora mesmo: "Grazas, Cap. Por suposto, estaría ben comprender o que estás escribindo en xeral. Se non, tamén podes contratar un grupo de monos para premer teclas arbitrarias e deixalo así". E tes toda a razón. En consecuencia, dou por feito que te das conta de que é necesario ter unha idea xeral do que estás facendo. Isto pódese chamar o nivel cero de comprensión, e non o analizaremos en detalle. Analizaremos en detalle o que precisa entender exactamente e como afecta ás decisións que toma todos os días. Se soubese estas cousas de antemán, aforraríame moito tempo perdido e código cuestionable.
Aínda que non verá unha soa liña de código a continuación, sigo crendo que todo o que se di aquí é de gran importancia para escribir código expresivo de alta calidade.
Primeiro nivel de comprensión: Por que non funciona?
Os desenvolvedores adoitan alcanzar este nivel moi cedo na súa carreira, ás veces mesmo sen axuda doutros, polo menos na miña experiencia. Imaxina que recibiches un informe de erro: algunha función da aplicación non funciona, hai que corrixila. Como vai proceder?
O esquema estándar ten o seguinte aspecto:
- Atopar o fragmento de código que está causando o problema (como facelo é un tema separado, o cubro no meu libro sobre o código heredado)
- Fai cambios neste fragmento
- Asegúrate de que o erro está solucionado e que non se produciron erros de regresión
Agora centrámonos no segundo punto: facer cambios no código. Hai dous enfoques para este proceso. O primeiro é afondar no que está a suceder exactamente no código actual, identificar o erro e solucionalo. Segundo: móvese por sensación - engade, digamos, +1 a unha instrución condicional ou un bucle, mira se a función funciona no escenario desexado, despois proba outra cousa, e así sucesivamente ata o infinito.
O primeiro enfoque é correcto. Como explica Steve McConnell no seu libro Code Complete (que recomendo encarecidamente, por certo), cada vez que cambiamos algo no código, deberíamos ser capaces de prever con confianza como afectará á aplicación. Cito de memoria, pero se unha corrección de erros non funciona como esperabas, deberías estar moi alarmado e deberías cuestionar todo o teu plan de acción.
Para resumir o que se dixo, para realizar unha boa corrección de erros que non degrade a calidade do código, cómpre comprender tanto a estrutura completa do código como a orixe do problema específico.
Segundo nivel de comprensión: por que funciona?
Este nivel enténdese de forma moito menos intuitiva que o anterior. Eu, aínda que era un programador novato, aprendín grazas ao meu xefe e, posteriormente, expliquei repetidamente a esencia do asunto aos recén chegados.
Esta vez, imaxinemos que recibiu dous informes de erros á vez: o primeiro é sobre o escenario A, o segundo é sobre o escenario B. En ambos os dous escenarios, ocorre algo mal. En consecuencia, primeiro abordas o primeiro erro. Usando os principios que desenvolvemos para a comprensión do nivel 1, profundizas no código relevante para o problema, descubres por que fai que a aplicación se comporte como o fai no escenario A e fai axustes razoables que produzan o resultado esperado. . Todo vai xenial.
Despois pasas ao escenario B. Repites o escenario nun intento de provocar un erro, pero... ¡sorpresa! - Agora todo funciona como debería. Para confirmar a túa suposición, desfaces os cambios que fixeches mentres traballabas no erro A e volve o erro B. A túa corrección de erros resolveu os dous problemas. Sorte!
Non contaches con isto en absoluto. Deches unha forma de corrixir o erro no escenario A e non tes idea de por que funcionou para o escenario B. Neste momento, é moi tentador pensar que ambas tarefas se completaron con éxito. Isto é bastante lóxico: a cuestión era eliminar erros, non si? Pero o traballo aínda non está rematado: aínda tes que descubrir por que as túas accións corrixiron o erro no escenario B. Por que? Porque pode estar traballando en principios incorrectos, e entón terás que buscar outra saída. Aquí tes un par de exemplos deste tipo:
- Dado que a solución non se axustou ao erro B, tendo en conta todos os factores, é posible que sen sabelo rompera a función C.
- É posible que tamén haxa un terceiro erro á espreita nalgún lugar, relacionado coa mesma función, e a súa corrección de erros depende del para o correcto funcionamento do sistema no escenario B. Agora todo parece ben, pero algún día este terceiro erro notarase e solucionarase. Entón, no escenario B, o erro ocorrerá de novo, e é bo aínda que só exista.
Todo isto engade caos ao código e algún día caerá na túa cabeza, probablemente no momento máis inoportuno. Terás que reunir a túa forza de vontade para forzarte a pasar o tempo entendendo por que todo parece funcionar, pero paga a pena.
Terceiro nivel de comprensión: por que funciona?
A miña visión recente refírese precisamente a este nivel, e probablemente sexa o que me tería proporcionado máis beneficios se tivese esta idea antes.
Para que quede máis claro, vexamos un exemplo: o teu módulo debe ser compatible coa función X. Non estás especialmente familiarizado coa función X, pero dixéronche que para ser compatible con ela cómpre utilizar o marco F. Outros módulos que se integran con X funcionan exactamente con el.
O teu código non estivo en contacto co framework F desde o primeiro día da súa vida, polo que implementalo non será tan sinxelo. Isto terá graves consecuencias para algunhas partes do módulo. Non obstante, lánzase ao desenvolvemento: pasa semanas escribindo código, probando, lanzando versións piloto, recibindo comentarios, corrixindo erros de regresión, descubrindo complicacións imprevistas, non cumprindo os prazos acordados orixinalmente, escribindo máis código, probando, recibindo comunicación de comentarios, corrixindo erros de regresión, todo isto para implementar o marco F.
E nalgún momento dáche conta de súpeto -ou quizais escoitas de alguén- que quizais o marco F non che ofreza compatibilidade coa función X. Quizais todo o tempo e o esforzo dedicouse completamente a iso.
Algo semellante ocorreu unha vez mentres traballaba nun proxecto do que eu era responsable. Por que pasou isto? Porque entendía pouco o que era a función X e como se relacionaba co cadro F. Que debería ter feito? Pídalle á persoa que asignou a tarefa de desenvolvemento que explique claramente como o curso de acción previsto conduce ao resultado desexado, en lugar de simplemente repetir o que se fixo para outros módulos ou dar a súa palabra de que iso é o que debe facer a función X.
A experiencia deste proxecto ensinoume a negarme a comezar o proceso de desenvolvemento ata que teñamos unha clara comprensión de por que se nos pide que fagamos certas cousas. Rexeitarse rotundamente. Cando recibes unha tarefa, o primeiro impulso é asumila inmediatamente para non perder o tempo. Pero a política de "conxelar o proxecto ata entrar en todos os detalles" pode reducir o tempo perdido en ordes de magnitude.
Aínda que traten de presionarche, de obrigarte a comezar a traballar, aínda que non entendas a razón para iso, resiste. En primeiro lugar, descubra por que se lle encarga unha tarefa e decide se este é o camiño correcto para acadar o obxectivo. Tiven que aprender todo isto pola dura maneira; espero que o meu exemplo facilite a vida aos que len isto.
Cuarto nivel de comprensión: ???
Sempre hai máis que aprender na programación, e creo que só raiñei a superficie do tema da comprensión. Que outros niveis de comprensión descubriches ao longo dos anos de traballo co código? Que decisións tomaches que tiveron un impacto positivo na calidade do código e da aplicación? Que decisións resultaron incorrectas e deronche unha lección valiosa? Comparte a túa experiencia nos comentarios.
Fonte: www.habr.com