Além do conhecimento de 100.500 tecnologias e abordagens, que, claro, também são importantes, há mais um ponto que é diretamente necessário e que por algum motivo raramente é falado.
Essa é a capacidade de construir em sua cabeça um modelo do que está acontecendo no software que está sendo criado. E lembre-se dela por muito tempo, pelo menos em termos gerais.
Você pode não dar a mínima para os benefícios dos negócios (olá, fillpackart), ou, pelo contrário, vive apenas de trabalho. Você pode ou não saber os detalhes da implementação do gc no jvm e girar as árvores vermelhas e pretas.
Tudo isso não importa se você não pode treinar sua rede neural cinza de modo a manter mais ou menos o sistema como um todo em sua cabeça. Algo que pertence à parte do software pela qual você é responsável e um pouco mais próxima.
Você mesmo pode transformar os murmúrios sem sentido do cliente em um modelo claro, ou pode definir um analista de negócios ou um e-mail nele, que fornecerá a documentação.
Mas mesmo assim, até que a cabeça "clique", a compreensão do que está acontecendo em geral não se acalma, você cometerá os mais estúpidos erros e falhas. Termine silenciosamente o absurdo óbvio do TZ, porque você não entenderá que isso é um absurdo. Será errado destacar entidades e abstrações no código, porque o código é o modelo de processos de negócios escritos em uma linguagem de computador estranha.
Várias abordagens como o DDD ajudam, mas apenas em parte, porque sem entender o sistema, sem fazer perguntas oportunas, contextos e entidades limitados também serão erroneamente distinguidos. Em seguida, ele terá que ser refeito e, ao mesmo tempo, haverá muitas dependências desnecessárias e nomes estranhos no sistema.
Jogadores de xadrez legais podem ter em mente uma dúzia de jogos em uma sessão de jogo simultânea.
Os programadores experientes e legais eliminarão uma característica delirante mesmo na fase de discussão preliminar, fazendo algumas perguntas corretas.
Aqueles que são capazes de manter o modelo na cabeça geralmente são feitos líderes de equipe, mesmo que tenham um desempenho pior em linhas de código por segundo.
PS Também seria bom poder explicar o que está acontecendo aos outros: ao explicar, você lembra e cristaliza melhor a essência.
Esta postagem é uma versão censurada de uma postagem do canal de telegramas Cross Join