Melhor resposta
Pergunta interessante. Para mim, o termo “habilidade” implica algo sobre a maneira como o código real é escrito, ao invés do design do sistema de nível superior. Eu diria que um código bem elaborado faz o seguinte:
- segue padrões externos
- segue padrões internos
- usa bons padrões
- É legível
Segue padrões externos. Se o seu grupo tem padrões de codificação, siga-os. Se não ” t como os padrões, ainda os siga.
Segue os padrões internos. Isso significa que o código deve ser internamente consistente. Métodos que fazem coisas semelhantes devem ser apresentados da mesma maneira. Se um método seguir o padrão:
if (success) {
doSomething();
} else {
handleError();
}
não tenha outro método que comece:
if (!success)
{
handleError();
Usa bons padrões. Com isso, quero dizer padrões de codificação em vez de Design Patterns. Seu código deve usar expressões idiomáticas apropriadas para a linguagem. (Use scoped\_ptrs para gerenciamento de memória em C ++, por exemplo.) Deve evitar ineficiências óbvias, como iteradores C ++ pós-incremento ou criação objetos que não são usados em todos os caminhos de código.
É legível. Outros engenheiros lerão seu código e você lerá novamente daqui a anos. O código deve ser o mais fácil de entender possível. Todos os itens mencionados acima se preocupam principalmente com a legibilidade e com a minimização de elementos inesperados no código. Seus leitores devem se preocupar com a lógica de seu código, não em tentar descobrir por que uma construção não padrão foi usada. Se houver uma construção não padrão, seus leitores devem saber que ela existe por um motivo, não porque você cometeu um erro. (Pense no seu código como uma peça de mobília. A superfície deve ser lisa e você não deve pegar uma farpa se passar a mão sobre ela. Qualquer irregularidade deve existir por um motivo.)
A legibilidade também é melhorada por nomes de métodos e variáveis razoáveis e por comentários apropriados. Não exagere nos comentários. Se for óbvio, não se preocupe em explicar. Mas tenha algum tipo de visão geral para que o leitor conheça o contexto. (Pode ser óbvio que o código está transformando a entrada X em saída Y, mas ajuda se o leitor tiver alguma ideia de por que isso é necessário.)
Resposta
Os gerentes são como crianças. Eles querem o que querem e querem AGORA ! Mas, ao contrário de crianças pequenas, os gerentes se lembraram pela metade dos artigos Harvard Business Review que citam (sem fornecer referências) para justificar suas demandas. Eles aprenderam um conjunto de argumentos que confundem alguns desenvolvedores.
Eles dizem: “Não podemos ter recursos para fazer isso direito. Temos que obtê-lo no mercado AGORA ! ”. Não é verdade, você sabe. Se eles colocarem seu código espaguete em produção, eles terão a chance de irritar seus clientes de lançamento agora, mas o código não pode escalar. Significa apenas que seus negócios desmoronam por um tempo antes de entrar em colapso.
Eles dizem: “Vamos lançar uma versão beta para nossos clientes de lançamento”. O que eles querem dizer é que eles querem que você libere um código perfeito e que agrade ao cliente mais cedo do que você faria, apenas porque eles concordaram em chamá-lo de programa de teste beta. É um pensamento mágico, como acreditar no Papai Noel.
Eles dizem: “Prometo que reescreveremos o código mais tarde se você liberar seu código ruim e incompleto AGORA ! ” Isso não soa como “Vou limpar meu quarto mais tarde, pai, se puder assistir TV e comer lanches açucarados AGORA ?” O problema é que o mais tarde nunca chega. Todos os dias, o gerente tem a opção de adicionar novos recursos ou limpar a bagunça que é sua base de código. Adivinhe a quem eles dão prioridade. E adivinhe, a sala fica cada vez mais bagunçada, de modo que vai demorar cada vez mais para limpar. É mais difícil trabalhar (para criar novos recursos) por causa de toda a confusão também.
No final, eles dizem: “Investimos muito nesta base de código. Vai demorar muito para reescrever. Precisamos de recursos AGORA ! ” Apenas cada recurso leva duas ou três vezes mais tempo para codificar, por causa da bagunça que os desenvolvedores de software chamam de dívida técnica.
Bons desenvolvedores, como pais pacientes e amorosos, precisam parar a loucura. Eles precisam insistir firmemente: “Desculpe, amor, mas seu artigo HBR diz: A receita quanto antes é melhor, todas as outras coisas sendo iguais . Você precisa lê-lo com mais atenção.Todas as outras coisas não são iguais se você acumula dívida técnica. Que tal se priorizarmos os recursos, e talvez haja algo para você vender mais cedo. ”
Você tem que ser o adulto e dizer a eles que Papai Noel não existe e não algo como um código perfeito e agradável ao cliente até que todos os bugs sejam removidos e todos os recursos sejam implementados.
Você precisa dizer a eles: “Não podemos pagar não para usar boas práticas. Vivemos ou morremos, mas temos que fazer certas coisas para viver, como escrever testes e documentação. Não é uma opção. ”
Você tem que sorrir e dizer:“ Nunca iremos reescrever este código. Eu sei que você tem boas intenções, mas quando se trata de consertar o código ou adicionar novos recursos, eu sei o que você dirá. É o que você sempre diz. ”
Por ser um pai firme, você ajuda seu gerente a crescer e se tornar o tipo de líder empresarial que você gostaria de trabalhar.