Uma das profissões mais idiotas são os gerentes que gerenciam programadores. Não todos, mas aqueles que não eram programadores. Aqueles que pensam que é possível “aumentar” a eficiência (ou aumentar a “eficiência”?) utilizando métodos de livros. Sem nem se preocupar em ler esses mesmos livros, o vídeo é cigano.
Aqueles que nunca escreveram código. Aqueles para quem são feitos filmes de Hollywood sobre programadores - bem, aqueles para quem assistem e-mails usando a linha de comando. Aqueles que não se interessam por nada além de indicadores, prazos e salário próprio.
Aqueles que são a maioria.
Mas eles são idiotas por um motivo diferente. Querem eficiência, ou pelo menos eficácia (vamos lá, gestor, Google qual é a diferença), sem entender nem um nem outro. Sem compreender de forma geral a essência, o processo de obtenção do resultado, as perdas que ocorrem nesse processo, os custos de desenvolvimento. Resumindo, trabalhar com um programador como se ele fosse uma caixa preta.
Eles entraram na gestão de programadores exatamente por um motivo: há exagero, dinheiro, mercado e um bando dos mesmos idiotas. Existe um lugar para se perder.
Se houvesse entusiasmo na produção de montagens mecânicas, nós correríamos para lá. As peruas são uma droga. Eu não ficaria surpreso se o cara que vendeu árvores de Natal em nossa vizinhança em dezembro fosse gerente de TI de férias.
Resumindo, se possível, atire no pescoço desses caras. Não se preocupe, eles encontrarão um emprego. Nenhum deles fará algo decente até que se tornem programadores. Porque ele não entende a essência, o mecanismo, a lógica do processo que controla.
Ok, chega de falar sobre gerentes. Agora, direto ao ponto, para programadores. Como aumentar a eficiência do desenvolvimento aprendendo a escrever código de alta qualidade.
Para aumentar a eficiência, você precisa resolver os problemas com mais rapidez e sem perder qualidade. Para resolver problemas mais rapidamente, você precisa ser capaz de escrever imediatamente código de alta qualidade. E “alta qualidade” e “escrever” e “imediatamente”. Deixe-me explicar com uma metáfora.
Escrever código de alta qualidade é como falar corretamente uma língua estrangeira. Quando você não conhece um idioma, você passa muito tempo tentando formular seus pensamentos nele.
Se você precisa dizer algo com urgência, você apenas se fixa em algumas palavras, muitas vezes não as corretas, você se esquece dos artigos, da ordem correta das palavras, sem falar nos tempos verbais e na pronúncia ruim.
Se você tiver tempo para formular uma resposta, terá que abrir um dicionário ou tradutor online e gastar muito tempo formulando seus pensamentos. A sensação, porém, ainda será desagradável: você diz a resposta e não sabe se está correta ou não. O mesmo acontece com o código – parece ter sido escrito, parece funcionar, mas se é de boa qualidade ou não é um mistério.
Acontece que é uma dupla perda de tempo. Leva tempo para encontrar uma resposta. Também leva tempo para formular essa resposta – e não tão pouco.
Se houver habilidade para escrever código de alta qualidade, a resposta poderá ser formulada imediatamente, assim que amadurecer na cabeça, sem gastar tempo adicional na tradução.
A habilidade de escrever código de alta qualidade ajuda no projeto de arquitetura. Você simplesmente não considerará opções incorretas, irrealizáveis ou de segunda mão em sua cabeça.
Resumindo: a habilidade de escrever código de alta qualidade acelera significativamente a resolução de problemas.
Mas isso não é tudo. Graças aos gerentes das botas de feltro, há um problema: não temos motivo para escrever código de alta qualidade. O gerente não olha o código, o cliente não olha o código. Raramente mostramos código uns aos outros, apenas às vezes, em alguns projetos onde há um “verificador” de código designado ou refatoração periódica.
Acontece que na maioria dos casos o código de merda vai para a produção ou para o cliente. Uma pessoa que escreveu um código de merda forma uma conexão neural estável - não só é possível escrever um código de merda, mas também é necessário - é aceito e eles até pagam por isso.
Como resultado, a habilidade de escrever código de alta qualidade não tem chance de se desenvolver. O código escrito por um funcionário condicional nunca é verificado por ninguém. A única razão pela qual ele aprenderá a programar normalmente é a motivação interna.
Mas esta motivação interna entra em conflito com planos e requisitos de eficiência e produtividade. Esta contradição claramente não é resolvida em favor de códigos de alta qualidade, porque as pessoas nem sequer criticam outras pessoas por códigos de merda. E por não cumprimento do plano - mesmo assim.
O que devo fazer? Vejo e proponho dois caminhos que podem ser combinados.
A primeira é mostrar seu código para alguém de dentro da empresa. Não de forma reativa (quando solicitado/forçado), mas de forma proativa (uh, cara, olhe meu código, por favor). O principal aqui é não postar meleca açucarada, não tentar criticar o código de forma educada. Se o código for uma porcaria, dizemos: o código é uma porcaria. Com explicações, claro, e recomendações sobre como melhorar.
Mas esse caminho também é mais ou menos. A sua aplicabilidade depende do ponto em que ocorreu o contacto. Se o trabalho já entrou em produção e o código está uma porcaria, não adianta refazê-lo. Mais precisamente, os motivos - as métricas também cairão. Os gerentes entrarão correndo e esmagarão você com requisitos de eficiência. E nem tente explicar a eles que o código de merda definitivamente retornará na forma de bugs - o tiro sairá pela culatra para você. Você só pode assumir o compromisso de não fazer isso novamente.
Se o trabalho ainda não foi entregue, ou apenas começou, então despejar merda no código (ou em seu projeto, ideia) pode ter um significado bastante prático - a pessoa fará isso normalmente.
A segunda maneira, a mais legal, é fazer desenvolvimento de código aberto fora do horário comercial. Qual é o objetivo: que um grupo de programadores, nomeadamente programadores, vejam o seu código e falem sobre ele. Todos dentro da empresa não têm tempo. Mas os programadores de todo o mundo ainda não têm nada para fazer, e se você escrever algo útil do ponto de vista da aplicação, eles definitivamente olharão para dentro.
O principal truque, na minha opinião, é escrever código fora do horário comercial, pois a contradição entre a qualidade do código e a velocidade de entrega do resultado não funcionará. Escreva seu desenvolvimento por pelo menos um ano. Nem prazos, nem especificações técnicas, nem dinheiro, nem chefe irão pressionar você. Total liberdade e criatividade.
Somente com a criatividade livre você entenderá e sentirá o que é um ótimo código, verá a beleza da linguagem e da tecnologia e sentirá o encanto das tarefas de negócios. Bem, você aprenderá a escrever código de alta qualidade.
É verdade que isso exigirá que você gaste tempo pessoal. Assim como qualquer outro desenvolvimento. Veja isso não como um custo, mas como um investimento – em você mesmo.
Fonte: habr.com