Uma das profissões mais sobrecarregadas por idiotas é a de gerentes que gerenciam programadores. Não todos, apenas aqueles que nunca foram programadores. Aqueles que pensam que podem "aumentar" a eficiência (ou aumentar a "efetividade"?) com métodos de livros. Nem se dando ao trabalho de ler esses mesmos livros — afinal, tem um vídeo disponível.
Aqueles que nunca escreveram código. Aqueles para quem fazem filmes de Hollywood sobre programadores — bem, aqueles onde checam o e-mail pela linha de comando. Aqueles a quem nada interessa além de indicadores, prazos e seu próprio salário.
Aqueles que representam a maioria.
Mas eles são idiotas por outra razão. Eles querem eficácia, ou pelo menos efetividade (vai lá, gerente, pesquise qual é a diferença), sem entender nada sobre isso. Sem compreender a essência, o processo de obtenção de resultados, as perdas que ocorrem nesse processo, os custos de desenvolvimento. Resumindo, trabalham com programadores como se fossem uma caixa-preta.
Chegaram ao gerenciamento de programadores por uma única razão: aqui tem hype, dinheiro, mercado e um monte de idiotas como eles. Há onde se esconder.
Se houvesse hype na fabricação mecânica, correriam para lá. Universais, mas ruins. Não me surpreenderia que o cara que vende árvores de Natal em nosso quarteirão em dezembro fosse um gerente de TI de férias.
Resumindo, se tiver oportunidade, bote esses caras para correr. Não se preocupe, eles encontrarão trabalho. Nenhum deles, jamais, fará algo digno até que se torne programador. Porque não entende a essência, o mecanismo, a lógica do processo que estão gerenciando.
Bom, chega de falar sobre gerentes. Agora, vamos ao que interessa para os programadores. Como aumentar a eficácia do desenvolvimento, aprendendo a escrever código de qualidade.
Para aumentar a eficácia, é necessário resolver os problemas mais rapidamente, sem perder qualidade. Para resolver os problemas mais rapidamente, é preciso saber escrever código de qualidade desde o início. E 'qualidade', 'escrever' e 'desde o início'. Vou explicar com uma metáfora.
Escrever código de qualidade é como falar corretamente em um idioma estrangeiro. Quando você não conhece a língua, gasta muito tempo tentando formular seus pensamentos nela.
Se precisar falar rapidamente, você acaba usando algumas palavras, muitas vezes as erradas, esquecendo dos artigos, da ordem correta das palavras, sem mencionar os tempos verbais e a pronúncia precária.
Se houver tempo para formular uma resposta, será necessário abrir um dicionário ou um tradutor online, desperdiçando muito tempo para organizar seus pensamentos. A sensação, no entanto, ainda será desconfortável: você responde e não sabe se está certo ou não. O mesmo acontece com o código – parece que você escreveu, parece que funciona, mas se é de qualidade ou não, quem sabe.
Assim, resulta em uma perda dupla de tempo. Leva tempo para pensar na resposta e leva tempo também para formulá-la – e não é pouco.
Se você tem a habilidade de escrever código de qualidade, pode formular a resposta imediatamente, assim que ela surgir em sua mente, sem perder tempo adicional com a tradução.
A habilidade de escrever código de qualidade ajuda na arquitetura do projeto. Você simplesmente não considerará as opções inadequadas, irrealizáveis ou mal feitas.
Resumindo: a habilidade de escrever código de qualidade acelera significativamente a resolução de problemas.
Mas isso não é tudo. Graças aos gerentes despreparados, há uma complicação – não temos motivo para escrever código de qualidade. O gerente não analisa o código, o cliente não analisa o código. Raramente mostramos nosso código uns para os outros, apenas em alguns projetos, onde há um 'revisor' designado ou um refatoramento periódico.
Portanto, na maioria dos casos, código de má qualidade vai para a produção ou para o cliente. A pessoa que escreveu o código de má qualidade forma uma conexão neural estável – não só pode escrever código de má qualidade, mas também deve – isso é aceito, e ainda pagam por isso.
Como resultado, a habilidade de escrever código de qualidade não tem chances de se desenvolver. O código escrito por um funcionário qualquer nunca é revisado por ninguém. A única razão pela qual ele aprenderá a programar adequadamente é a motivação interna.
Mas essa motivação interna entra em conflito com os planos e requisitos de eficiência e produtividade. Esse conflito não é resolvido a favor do código de qualidade, pois não há reclamações sobre o código de má qualidade. Mas o não cumprimento do plano – isso sim.
Como proceder? Vejo e proponho dois caminhos que podem ser combinados.
O primeiro é mostrar seu código a alguém dentro da empresa. Não de forma reativa (quando pedem ou forçam), mas de forma proativa (ei, cara, dá uma olhada no meu código, por favor). O mais importante aqui é não ficar com mimimi, não tentar disfarçar uma crítica ao código de maneira educada. Se o código é ruim, devemos dizer: o código é ruim. Com explicações, claro, e recomendações de como melhorá-lo.
Mas esse caminho também tem suas limitações. Sua aplicabilidade depende do ponto em que ocorreu o contato. Se o trabalho já foi para produção e descobrimos que o código é ruim, não adianta refazê-lo. Mais precisamente, isso pode impactar as métricas. Os gerentes vão pressionar com exigências de eficiência. E não tente explicar para eles que código ruim inevitavelmente voltará na forma de bugs — você só vai se prejudicar. A única coisa que podemos fazer é nos comprometer a não repetir o erro.
Se o trabalho ainda não foi entregue ou apenas começou, criticar o código (ou seu projeto, ideia) pode ter um sentido prático — a pessoa acabará por fazê-lo corretamente.
O segundo caminho, o mais bacana, é se dedicar ao desenvolvimento de código aberto durante o tempo livre. O objetivo é que um monte de programadores, programadores de verdade, veja seu código e opine sobre ele. Dentro da empresa, ninguém tem tempo. Mas programadores do mundo inteiro não têm nada para fazer, e se você desenvolver algo útil do ponto de vista prático, eles com certeza darão uma olhada.
A principal sacada, na minha opinião, é escrever código no tempo livre, pois não haverá conflito entre a qualidade do código e a velocidade de entrega do resultado. Pode levar um ano para desenvolver algo. Ninguém vai pressionar você com prazos, requisitos, dinheiro ou chefes. Total liberdade e criatividade.
Somente na liberdade criativa você entenderá e sentirá o que é um código de qualidade, verá a beleza das linguagens de programação e tecnologias, sentirá a delícia de resolver problemas de negócios. E, claro, você aprenderá a escrever código de qualidade.
É verdade que isso exigirá investimento de seu tempo pessoal. Como qualquer outro tipo de desenvolvimento. Encare isso não como um custo, mas como um investimento — em você mesmo.
Fonte: habr.com
