Como escrever código eficiente, apesar dos prazos pesados

Estou trabalhando em um ambiente em que temos muitos projetos com prazos estritos de entrega. Até conversamos diretamente com os clientes, portanto, fazer os trabalhos com rapidez é uma obrigação.

Meu problema é que eu sempre escrevia código para a primeira solução que me ocorria, o que, é claro, eu achava melhor naquele momento. Porém, sempre acaba feio e, mais tarde, eu percebo que existem maneiras melhores de fazê-lo, mas não podemos nos permitir mudar devido a restrições de tempo.

Existem dicas pelas quais eu poderia tornar meu código eficiente e entregar dentro do prazo?

Se o código precisar ser mantido, explique que é necessário tempo adicional para tornar o código mais sustentável, o que economizará dinheiro no back-end. Em outras palavras, torne um código sustentável um requisito.

Se eles não se importam com isso, acho que você não precisa fazer nada diferente, além de melhorar o tempo todo e fazer o melhor possível para incorporar as melhores práticas sempre que possível.

Ok, isso pode parecer um pouco louco, mas eu juro que funciona. Não é apenas para programação, é uma receita para aumentar a criatividade, a concentração e a memória:

• Coma bem
• Meditar
• Durma bastante (7-9hrs dependendo da pessoa)
• Soneca sempre que seu cérebro está confuso
• Vá dormir com um problema não resolvido. Não termine o seu dia com tudo completo. Deixe uma tarefa difícil pendente - seu subconsciente é notavelmente eficaz.
• Use roupas confortáveis
• Exercício
• Tire um tempo para fazer exercícios mentais rotineiros - sudoku (não programado), palavras cruzadas, exercícios de matemática, quebra-cabeças espaciais, etc.
• Realize experimentos objetivos consigo mesmo para ver quais comportamentos afetam o desempenho (você precisará de uma maneira confiável de testar o desempenho para que isso funcione).
• Cuide da sua saúde espiritual
• Cuecas de algodão
• Cuide da sua saúde sexual
• Arranje tempo para sua família e amigos
• Torne-se proficiente em algo fora da sua profissão (música, culinária, esportes, etc.) e socialize com outras pessoas fazendo a mesma coisa
• Para algumas pessoas, um animal de estimação é uma obrigação

Antes que você perceba, você verá uma melhoria acentuada na produtividade de programação e na qualidade das soluções (sem mencionar as melhorias em outras áreas).

Fontes:

1. Seu cérebro milagroso: maximize seu poder cerebral, melhore sua memória, melhore seu humor, melhore seu QI e criatividade, impeça e reverta o envelhecimento mental
2. O Eu Quantificado
3. Seth Roberts - na Scientific American

É contra-intuitivo, mas você provavelmente precisa desacelerar. Quando você implementa a primeira solução que vem à sua mente, cria muito trabalho extra para si no caminho. Por "no caminho", quero dizer o mais tarde naquela tarde. Os problemas que você cria para si mesmo não demoram meses para se desenvolver. Considere suas opções. Digite menos e pondere mais. Mesmo em um projeto curto, você descobrirá que menos codificação pode realmente acelerar você.

Se seus clientes se agruparem em setores específicos, tente criar projetos que tenham componentes reutilizáveis. Não escrever código é mais rápido do que escrevê-lo.

Do ponto de vista do seu cliente, isso cheira um pouco como " Rápido, bom e barato, escolha dois ". Claro, todos queremos o que desejamos imediatamente, mas seus clientes precisam considerar se isso é melhor a longo prazo. Tente articular as compensações e ajudá-las a tomar boas decisões.

Procurar por outro emprego.

Você verá que após cerca de 6 meses. a um ano em que você não se orgulhará do trabalho que realizou. Além disso, você não terá tempo para aprender sobre novas técnicas, tecnologias ou estruturas - portanto, depois de um ano, você não poderá acompanhar as novas tecnologias. Você será um programador pior em relação ao mercado após um ano do que era no início.

Se passar muito tempo (digamos, alguns anos ou mais), você terá dificuldades para ser contratado em qualquer lugar, exceto para esses tipos de trabalhos em ritmo acelerado, nos quais o código de qualidade não é apreciado, apenas velocidade.

Dito isto, como uma experiência de aprendizado no "mundo real", há algo a ser dito sobre o ambiente de ritmo acelerado, mas eu diria isso em cerca de seis meses. basta. Além disso, você deve procurar alguns recrutadores e procurar um lugar melhor. Você será muito mais feliz, honesto.

Na opinião de seus clientes, a eficiência do código pode não ser tão crítica e pode ser bastante cara. Atualmente, o tempo gasto na criação de código precisa economizar horas de CPU para justificar uma hora do seu tempo. Para a maioria dos programas, a eficiência não é tão crítica. Mesmo para quem está, a maior parte do código não precisa ser tão eficiente. Dada a escolha, minha preferência seria por uma solução de fácil manutenção, em vez de um código mais eficiente e mais difícil de manter.

Dedicar um tempo para planejar sua codificação antes de começar pode dar tempo para avaliar soluções e considerar abordagens alternativas. Isso economiza seu tempo na codificação e no teste. Eu descobri que o código geralmente mais simples é mais eficiente.

Faça um layout limpo do código usando quantas linhas forem necessárias. Código complexo pode confundir o otimizador e resultar em código mais lento. Compiladores modernos são muito bons em otimizar o código, confie nele para fazer seu trabalho.

Aceite que bom o suficiente é bom o suficiente. Quando você tiver abordagens mais eficientes, tome nota de si mesmo. Se você tiver algum tempo, compare alguns de seus projetos mais eficientes com os que você implementou. Experimente-os no pequeno (apenas o código afetado) e no grande (o programa que os utiliza). Isso lhe dará uma ideia de quando uma abordagem mais eficiente é apropriada.

Muitas pessoas consideram a otimização prematura uma má abordagem. Pode ser caro de implementar. Infelizmente, muitas otimizações prematuras na verdade não são eficientes como o código otimizado. Para otimizar o código corretamente, você precisa instrumentá-lo antes e depois da alteração para verificar se realmente possui uma eficiência aprimorada.

Estude técnicas que ajudam a escrever um código mais limpo com baixo acoplamento e alta coesão. Em muitos casos, reduzir a complexidade aumenta a eficiência. Técnicas que ajudam a minimizar os erros que você precisa corrigir durante o desenvolvimento ajudarão a fornecer mais rapidamente. Isso pode liberar tempo para você testar abordagens alternativas.

Robert cobriu os aspectos mais importantes.

Eu trabalhei nesses ambientes, nos quais o código não (não pode) viver por mais de seis meses. Existem algumas regras básicas que posso pensar:

1. Use bibliotecas de código aberto, soluções de terceiros, etc. O aprendizado envolvido é compensado por menos manutenção e depuração. No entanto, se você está preso a uma biblioteca de buggy, está condenado.
2. Garanta rigorosamente que seu design seja extensível. Um requisito obrigatório: a maior parte do trabalho vem como melhorias, não criando novos recursos.
3. Crie planos de teste rigorosos. Faça um controle de qualidade ou automatize os testes para garantir o teste de regressão.
4. Use ferramentas inteligentes - IDEs, utilitários de geração de código, etc.
5. Mantenha as coisas o mais configuráveis ​​possível. (O outro lado é o aumento dos esforços de teste)
6. Melhore a sua velocidade de digitação :-)

Na fase de design, converse com colegas .

Discuta seu design e como você deseja fazê-lo, e peça que eles examinem suas decisões. Se e quando todos concordarem com o que é inteligente, você terá um design muito mais sólido.

Prática. Pratique escrever um bom código até que ele se torne uma segunda natureza. Em seguida, pratique a codificação mais rapidamente. Em seguida, pratique a codificação melhor. E quando terminar, pratique um pouco mais.

Meu problema é que eu sempre escrevia código para a primeira solução que me ocorria, o que, é claro, eu achava melhor naquele momento.

Não, esse não é o seu problema. Isso é uma virtude. Está fazendo a coisa mais simples que poderia funcionar. Mas isso só funciona quando combinado com refatoração. É um processo contínuo: fazer a próxima coisa mais simples que possa funcionar repetidamente, para que seu sistema seja sempre uma expressão do seu entendimento atual do espaço da solução.

Seu problema é que você possui um gerenciamento que não entende o verdadeiro custo do ciclo de vida dos sistemas de software. 90% desse custo é de manutenção, não de implementação inicial. Teste e refatoração são nossas melhores ferramentas para reduzir o custo total do ciclo de vida de um sistema de software. Se seus gerentes não permitirem que você faça essas coisas, eles são irresponsáveis ​​e precisam ser reciclados. Ou você precisa encontrar um novo emprego.

Finalmente: como eu disse antes *, você precisa aprender a dizer não .

* Como codificar em um cronograma muito apertado?

Se eles fixaram o escopo e o tempo, tudo o que você pode fazer para cumprir o prazo é diminuir a qualidade.

Se possível, diminua a qualidade externa, visível para as partes interessadas, não comprometa a qualidade interna, coisas que prejudicam sua habitabilidade na base de código.

Eu realmente não acho que o auto-aperfeiçoamento ajudará você nessa situação. Se alguma coisa, então, lamento dizer, geralmente é assertividade.

Tente colocar um pé na porta quando o trabalho for estimado. Como seu chefe pode estimar quanto tempo você leva para fazer alguma coisa?

Traga opções ao seu chefe e / ou cliente. Muitas vezes, são os próprios desenvolvedores que optam por diminuir a qualidade sem comunicar nada. Projetos / trabalhos atrasados ​​são muito comuns e geralmente 'gerenciados'. Aja atempadamente, avise as pessoas se vir um prazo não atendido.

Eles não podem cortar o escopo ou mudar o prazo se você não lhes disser nada.

Se você pretende comprometer a qualidade de qualquer forma, tente deixar que seja a decisão deles. Dê a eles coisas que pesem umas contra as outras.

Apenas algumas coisas que VOCÊ pode decidir. Se você conseguisse funcionar. Mas é muito insustentável. Talvez você não tenha certeza se funciona em todos os casos. Não conte a ninguém que você terminou. Refazer. Muitas vezes, é uma decisão que somente você pode tomar. Ou porque o problema é muito demorado para articular ou você tem um gerente não técnico.

Às vezes, isso faz parte da sua ética de trabalho. Você costuraria um paciente sem lavar as mãos, porque 'não há tempo'?

Acima de tudo, lembre-se: não há mais tarde.

Sou desenvolvedor .Net que trabalha em aplicativos da web.

O que eu comecei a fazer é -

Se for um código C #, tento escrever esse código no LinqPad primeiro (se possível).

Se for código Javascript, primeiro escrevo esse código e o testo em jsfiddle / jsbin (se possível).

Descobri que isso ajuda na qualidade do código, mas não me deixa mais lento (e, em vários casos, achei mais rápido).