Quais são as piores coisas que os desenvolvedores inexperientes esquecem de pensar? [fechadas]

Como um desenvolvedor jovem, eu consideraria útil obter alguns conselhos sobre o que pensar para desenvolver um aplicativo de alta qualidade. Nos meus cursos universitários, a maioria dos professores enfatizou a validação de entrada e alguns falaram sobre preocupações de segurança, mas ninguém abordou a importância de outras coisas, como o registro de dados, por exemplo.

Quais são alguns erros que desenvolvedores inexperientes tendem a cometer, o que pode levar à frustração de desenvolvedores mais experientes?

Acho que a principal coisa que os desenvolvedores esquecem é que, no mundo real, eles frequentemente trabalham como parte de uma equipe. Isso se mostra como ..

• Verificando código que quebra a compilação
• Não reutilizando código que já está lá
• Fazer as coisas do seu jeito e não da mesma maneira que todos os outros - o que torna a manutenção cara

Isso não quer dizer que o código deles não seja tão fácil de isolar, mas eles não estão mais trabalhando isoladamente.

1. Testes.
2. Testes.
3. Mais testes.
4. Fonte de controle
5. Impostos apropriados para o programa que você segmentar.

No Windows, esses impostos são :

• Lidando com ambientes de alto DPI
• Perfis de usuário móvel
• Troca rápida de usuário
• Área de trabalho remota (por exemplo, você não deseja usar o buffer duplo quando o RDP estiver em vigor
• Jogando bem com o Hierarchical Storage Management
• Monitores múltiplos
• Windows de 64 bits

Em praticamente todas as plataformas, você terá que lidar com:

• Unicode
• Localização
• Gerenciamento de energia

Na minha experiência, a única coisa que quase todos os desenvolvedores inexperientes não têm em mente é que você (quase sempre) trabalha em um ambiente comercial. Seu código precisa ser bom, mas não perfeito. O mais importante não é a perfeição, é que o seu código é enviado.

Em outras palavras, entregar o código perfeito três meses após a falência da sua empresa não é bom para ninguém.

Na minha opinião, esta é uma das maneiras mais significativas pelas quais o desenvolvimento no mundo real difere do desenvolvimento, como ensinado na universidade.

Pergunta realmente ampla; responder em detalhes é ... vários livros.

Aqui está uma lista de verificação geral de definição de sistemas para você começar -

• Quais são os recursos críticos no sistema e como as demandas sobre eles podem mudar?
• Quais são os recursos de desempenho do sistema e como eles precisam crescer?
• Quais áreas de requisitos podem se tornar desnecessárias e removíveis?
• Existe a possibilidade de haver versões diferentes do sistema com recursos diferentes?
• Quais são as implicações na mão de obra e nos recursos do computador se as mudanças identificadas ocorrerem?
• Qual o impacto do novo sistema nos sistemas operacionais existentes?
• Quais áreas de função têm maior chance de exigir mudanças à luz da experiência com o sistema?
• Quem são os futuros usuários do sistema?
• Quais são os futuros mantenedores do sistema?
• Quais são os aprimoramentos futuros que os futuros usuários do sistema podem identificar como prováveis?
• Como o sistema se encaixa nos planos gerais do usuário e como eles devem se desenvolver?

A dissociação limpa do sistema na máquina de desenvolvimento de uma pessoa e na máquina de destino, para que não se acabe com as situações "Bem, funciona na minha máquina".

E com que rapidez você pode reconstruir sua máquina de desenvolvimento?

• Você sabe quais pacotes você precisa?
• Você tem uma solução de botão de pressão para reconstruir seu banco de dados?
• Você tem uma solução de botão de pressão para testar a integridade no código-fonte?

Acho que provavelmente é o design - ou seja, a abordagem de pensar sobre o que você fará antes de fazê-lo.

Muitos codificadores inexperientes (lembre-se de quando você começou) gostam de entrar em ação e começar algo, depois adicionar um pouco mais e anunciar um pouco mais e adicionar um pouco mais. Essa abordagem pode funcionar se você planejou fazer dessa maneira (cada bit pode ser testado à medida que você for, afinal), mas a maioria dos codificadores inexperientes se concentra apenas na parte que está escrevendo. Portanto, todas as adições tendem a ser hackeadas em cima. E todos nós vimos código que evoluiu assim!

A organização é a próxima coisa, muitas vezes eles se concentram demais no código que escreveram para lembrar como o fizeram e o que era necessário. Portanto, eles esquecem de agrupar ou documentar uma dependência necessária. Eles também tendem a colocar as coisas onde caem. Eu tive que criticar um júnior na semana passada que verificou seu código no diretório raiz, incluindo 3 wsdls, 2 dos quais eram o mesmo arquivo e um conjunto de dlls de terceiros que ele cometeu em um subdiretório e o diretório raiz. O código também não estava formatado para qualquer padrão, e havia várias funções presentes, mas nunca chamadas.

Obviamente ele conseguiu funcionar, mas não estava arrumado, e isso significava que instalação e manutenção teriam sido problemáticas.

Eu acho que as maiores diferenças estão na técnica de codificação. Todo mundo tem uma abordagem um pouco diferente, mas desenvolvedores inexperientes tendem a produzir código que:

• não lida com casos de fronteira
• é muito mais longo que o necessário
• possui características de desempenho ruins em cenários relevantes
• tem pouca separação de preocupações
• não possui técnicas de autoproteção, como o uso de const, selado, somente leitura, etc.
• maneiras estranhas de retornar dados e coleções de dados
  • isso demonstra mais inexperiência com uma plataforma

Como você perguntou as piores coisas, minha resposta é a seguinte:

1. Esqueceu-se de pensar em higienizar a máquina de desenvolvimento contra spywares, malwares e vírus de trojan.
2. Esqueceu-se de pensar em fazer um backup regular salvo em armazenamentos seguros que estão em diferentes localizações geográficas.

O maior deles é lembrar de planejar a flexibilidade. Nas aulas, os requisitos quase sempre são estabelecidos no início e nunca mudam. No software, muitas vezes é o oposto: você recebe um conjunto vago de requisitos, e eles mudam frequentemente (até mesmo diariamente). A melhor coisa que você pode fazer para ajudar nisso é codificar de forma flexível: acoplamento flexível, pequenas funções que podem ser usadas de maneira confiável em várias situações e evitar o máximo de codificação possível.

Com o tempo, é provável que você aprenda a) o que as coisas provavelmente mudarão e, inversamente, o que provavelmente não mudará eb) como antecipar as solicitações de mudança e planejar para elas.