As Companhias Do Software, Não sabotage Seu Sucesso Long-Term!

Sobre os anos, I.ve pagou muitos da atenção a como as companhias recrutam programadores de computador.  Durante esse tempo, I.ve observou como os gerentes fazem freqüentemente as decisões empregando que parecem fazer o sentido no termo curto, mas que resulte no caos a longo prazo.  I.ve visto o tipo do havoc que isto wreak da lata, e de como devastating o pode se realizar ao futuro de company.s.

A identificação gosta de dizer hoje algumas palavras sobre aquela.

As companhias que I.ve observou tipicamente matérias da atenção do pagamento tais como os fundos da indústria, anos da experiência, e assim por diante.  Querem conhecer que tipos de projetos os pretendentes trabalharam sobre, que o familiar dos compiladores e se operar dos sistemas they.re com, que protocolos de comunicação e os pacotes de software they.ve se usou, e assim por diante.  Muitos querem também saber sobre as éticas e a personalidade do trabalho de employee.s, mas na extremidade, as decisões empregando fervem freqüentemente para baixo à experiência de trabalho de employee.s e quanto treinamento que a pessoa requereria.

Toda a aquelas é considerações importantes, sensible.  Porque eu observei estas companhias though, eu observei que a maioria de them.about 80% ou de more.paid quase nenhuma atenção se o pretendente teve um estilo de programação limpo, readable.  Foram concernidos profundamente aproximadamente se o pretendente poderia começar o trabalho feito, e didn.t parecem importar-se muito aproximadamente se seu software poderia fàcilmente ser compreendido e modificado por outro, anos tragam a estrada.

A alguma extensão, isto é compreensível.  Apesar de tudo, o objetivo imediato de a maioria de companhias é desenvolver os produtos trabalhando que podem vender.  O que muitos se esquecem, entretanto, é que estão supostos para ser marathoners, não sprinters.  Necessitam pensar mais nos termos de terminar a raça inteira, e em menos nos termos de conseguir vitórias a curto prazo.

Betrays também algum naivete sobre os danos imediatos que podem resultar do estilo de programação pobre.   Apesar de tudo, mesmo o mais melhor software é raramente bug-free.  Um programador que escreva o software limpo, legible poderá eliminar erros mais confiantemente de seu próprio trabalho do que alguém que escreve o código do patchwork.  O último pode arguably fornecer reparos mais rapidamente (e mesmo that.s discutível!), mas os resultados serão unreliable.and quando o tempo é curto, that.s um luxo que as companhias não possam ter recursos para.

Os empregadores devem também recordar que isso bom programar o estilo não é algo that.s ensinado fàcilmente.  Todo o programador competente pode aprender os mecânicos de ligações de controle da sintaxe e da língua; entretanto, alguém que compreende pouco sobre o artistry da programação estruturada ou da orientação apropriada do objeto é improvável dominar estas coisas no trabalho.  I.ve vistos isto acontecem (ou rather, falha a acontecer) tempo e outra vez.  Isto, apesar da abundância de livros e jornais que discutem esta matéria no comprimento grande.

Eu penso também de que as companhias devem pagar uma atenção mais grande às habilidades técnicas em perspectiva da escrita de employee.s; apesar de tudo, a documentação externa (por exemplo manuais de usuário, documentação do projeto) pode ser crítica ao maintainability de software.s.  Adicionalmente, em minha experiência, os programadores que escrevem bem em inglês são mais prováveis escrever demasiado o software.  E por que não?  As línguas de programação são that.languages finalmente justos.  Alguém que pode se expressar bem em inglês é mais provável comunicar-se claramente e eficazmente em seu código de fonte também.

Para estas razões, eu incito toda a companhia that.s que emprego um programador para fazer perguntas incisive sobre um estilo do coding de applicant.s.  Como nomeia suas variáveis?  Quantas linhas do código deve uma função ocupar?  Usar variáveis globais, e se assim, quando?  Que tipos dos livros leu no estilo de programação?  Idealmente, as companhias devem também pedir amostras de um código de fonte de applicant.s e de uma documentação técnica, para verificar que estas lições estão postas na prática.  Isto faz exame de pouco esforço extra, mas pode ajudar a uma companhia evitar de sacrificar o sucesso a longo prazo para a causa de ganhos a curto prazo dubious.

Sobre o autor:

O Jr. de V. Berba Velasco, Ph.D. é uma Software Engineer sênior elétrica e tecnologia celular Ltd (http://www.immunospot.com, http://www.elispot-analyzers.de, http://www.elispot.cn, http://www.elispot.co.jp) onde serve com orgulho grande. Viu como a atenção apropriada à usabilidade, ao maintainability e ao elegance do software pode soletrar a diferença entre produtos mediocre e os grandes.