Um dos idiotas sobrecarregados é o gerente que gerencia os programadores. Nem todos, mas aqueles que não eram programadores. Aqueles que pensam que é possível "aumentar" a eficiência (ou aumentar a "eficiência"?) Pelos métodos dos livros. Sem sequer se preocupar em ler esses livros - o Vidosik é, afinal, um cigano.
Aqueles que nunca escreveram código. Aqueles para quem os filmes de Hollywood sobre programadores são feitos - bem, aqueles em que assistem e-mails na linha de comando. Aqueles que não estão interessados em nada, exceto indicadores, termos e seu próprio salário.
Aqueles que são mais.
Mas eles são idiotas por outro motivo. Eles querem eficiência ou pelo menos produtividade (vamos lá, gerente, google, qual é a diferença), sem entender um ou outro. Geralmente, não compreendendo a essência, o processo de obtenção do resultado, as perdas que ocorrem nesse processo, os custos de desenvolvimento. Em resumo, trabalhar com um programador como com uma caixa preta.
Eles se depararam com o gerenciamento de programadores por exatamente um motivo: aqui há exageros, dinheiro, mercado e muitos idiotas. Há onde se perder.
Se houvesse um hype na indústria de montagem mecânica, nós correríamos lá. Os vagões da estação são ruins. Não vou me surpreender que o cara que vende árvores de Natal em nosso trimestre em dezembro seja gerente de TI nas férias.
Em suma, se possível, persiga esses caras no pescoço. Não se preocupe, eles vão encontrar um emprego. Nenhum deles fará nada decente até que ele se torne um programador. Porque ele não entende a essência, mecanismo, lógica do processo que ele controla.
Bem, já chega dos gerentes. Agora, para programadores. Como aumentar a eficiência do desenvolvimento aprendendo a escrever código de alta qualidade.
Para aumentar a eficiência, é necessário resolver rapidamente problemas sem perder qualidade. Para resolver problemas mais rapidamente, você deve poder escrever imediatamente um código de alta qualidade. E "qualidade", "escrever" e "imediatamente". Vou explicar com uma metáfora.
Escrever um código de qualidade é como falar com competência em uma língua estrangeira. Quando você não conhece o idioma, gasta muito tempo para formular seus pensamentos.
Se você precisar dizê-lo com urgência, basta colar algumas palavras, muitas vezes não as que você precisa, esquecer os artigos, a ordem correta das palavras, sem mencionar os tempos dos verbos e a pronúncia incorreta.
Se houver tempo para a redação da resposta, você precisará abrir um dicionário ou um tradutor da Internet e gastar muito tempo na redação de seus pensamentos. O sentimento, no entanto, ainda será desagradável: você diz a resposta e não sabe se está correto ou não. Da mesma forma com o código - parece ter escrito, parece funcionar, mas é de qualidade ou não - HZ.
Acontece uma dupla perda de tempo. Leva tempo para chegar a uma resposta. Também leva tempo para formular essa resposta - além disso, não tão pouco.
Se a habilidade de escrever código de alta qualidade estiver presente, a resposta poderá ser formulada imediatamente, assim que amadurecer na cabeça, sem gastar tempo extra na tradução.
A habilidade de escrever código de qualidade ajuda no projeto arquitetônico. Você simplesmente não considerará as opções erradas, irrealizáveis ou corpo a corpo em sua cabeça.
Resumindo: a habilidade de escrever código de alta qualidade acelera significativamente a solução de problemas.
Mas isso não é tudo. Graças aos valenki-managers, existe um problema - portanto, não temos motivos para escrever código de alta qualidade. O gerenciador de código não parece, o código do cliente não parece. Raramente mostramos um ao outro código, apenas ocasionalmente, em alguns projetos em que há um “inspetor de código” designado ou refatoração periódica.
Acontece que, na maioria dos casos, o govnokod vai para a produção ou para o cliente. A pessoa que escreveu o govnokod forma uma conexão neural estável - o govnokod não é apenas possível escrever, mas também necessário - é aceito e até pago por isso.
Como resultado, a habilidade de escrever código de alta qualidade não tem chance alguma de se desenvolver. O código escrito por um funcionário condicional nunca é verificado por ninguém. A única razão pela qual ele aprende a programar normalmente é a motivação intrínseca.
Mas essa motivação intrínseca entra em conflito com os planos e requisitos de eficiência e produtividade. Essa contradição é resolvida claramente não em favor de um código de alta qualidade, porque eles nem culpam o govnokod. E por não cumprir o plano - de que outra forma.
Como ser Vejo e ofereço duas maneiras que podem ser combinadas.
A primeira é mostrar seu código a alguém dentro da empresa. Não reativamente (quando solicitado / forçado), mas proativamente (er, cara, veja meu código, por favor). O principal aqui é não travar o açúcar, não tente colocar um código educado nas críticas ao código. Se o código é uma merda, dizemos o seguinte: o código é uma merda. Com explicações, é claro, e recomendações sobre como torná-lo melhor.
Mas esse caminho também é mais ou menos. Sua aplicabilidade depende do ponto em que o contato ocorreu. Se o trabalho já entrou em produção e se revelou que o código é uma merda, não há sentido em refazê-lo. Mais precisamente, as ocasiões - as métricas também cairão. Os gerentes atacarão e esmagarão os requisitos de eficiência. E nem tente explicar a eles que o govnokod definitivamente retornará na forma de bugs - ele sairá para você de lado. Só se pode comprometer-se a não fazê-lo mais.
Se o trabalho ainda não foi entregue ou apenas começou, despejar merda no código (ou em seu projeto, idéia) com merda pode ter um significado bastante prático - uma pessoa o fará normalmente.
A segunda maneira, a mais legal, é desenvolver o código aberto depois de horas. Afinal, qual é o objetivo: um monte de programadores, ou seja, programadores, veem seu código e falam sobre ele. Não há tempo para todos dentro da empresa. Mas programadores em todo o mundo ainda não têm nada a fazer, e se você escrever algo útil do ponto de vista do aplicativo, eles definitivamente olharão para dentro.
A principal característica, na minha opinião, é escrever código depois de horas, porque a contradição entre a qualidade do código e a velocidade do resultado não funcionará. Pelo menos um ano, escreva seu desenvolvimento. Nem cronogramas, nem TK, nem dinheiro, nem o chefe pressionará você. Total liberdade e criatividade.
Somente com criatividade gratuita você entenderá e sentirá o que é um código legal, verá a beleza do YaP e da tecnologia e sentirá o charme das tarefas de negócios. Bem, você aprenderá a escrever código de alta qualidade.
É verdade que isso exigirá que você gaste tempo pessoal. Como, de fato, qualquer outro desenvolvimento. Considere isso não como um custo, mas como um investimento em si mesmo.