Como passo de escrever código para ser um bom desenvolvedor?

Estou frustrado com a falta de explicações concretas sobre como passar do script (bash, awk) e escrever aplicativos simples (c, php, python) ao design e desenvolvimento de software maior e mais complicado. Parece que, por um lado, existem livros sobre linguagens de programação e, por outro, os livros sobre engenharia de software / gerenciamento de projetos, projetados para equipes de programadores.

Eu li muitos de ambos. Eu li os clássicos XP / Agile e tenho um entendimento teórico decente do processo de desenvolvimento de software. Eu gosto de ler o código de outras pessoas e posso segui-lo bastante bem. Mas quando tenho uma idéia para um projeto ou quero ir de "aqui está o problema / necessidade" para "aqui está a solução", minha mente fica em branco e não sei por onde começar.

Eu apenas corto isso? Existem fluxos de trabalho estruturados para desenvolvedores individuais que não trabalham em equipe ou para uma grande casa de software? Realmente não tenho nenhum desejo de obter um PMP ou trabalhar para uma empresa de software. Estou apenas procurando um fluxo de trabalho eficaz, eficiente e prático.

Na minha opinião, você se torna um bom desenvolvedor, tendo experiência e trabalhando com várias maneiras de fazer as coisas. Você declarou que tem um problema passando de "aqui está a minha ideia" para "aqui está a minha solução". Isso é algo mais voltado para as metodologias de desenvolvimento de software, além de ser um desenvolvedor experiente.

Usar uma metodologia de desenvolvimento de software é mais do que "apenas extrair código", e essas metodologias fornecem fluxos de trabalho estruturados. A família Agile fornece uma boa estrutura para equipes de desenvolvimento menores (ou indivíduos) que você pode seguir para ajudá-lo a passar da fase "idéia" para a fase "produto acabado".

Há algumas coisas que aprendi ao longo dos anos com outras pessoas e através do trabalho em vários projetos, como:

• Torne tudo testável, isso facilitará sua vida muito;
• Você não pode esperar ter um design perfeito e ser capaz de projetar aplicativos corporativos / o próximo maior título do jogo / inserir mais aqui, sem ter experiência em fazê-lo;
• É difícil projetar um bom software se você não teve experiência e aprendeu com outras pessoas;
• Você nunca terá um design perfeito na primeira vez, mesmo como um desenvolvedor experiente - as coisas mudam e, portanto; seu design também pode;
• Escreva as coisas: Escrever / desenhar / quadro branco / pintar / o que quer que seja que você se sinta confortável, facilita a vida se você escrever as coisas. Como projetos de GUI, diagramas de classes, etc. Na minha experiência, apenas "hackear algo juntos" tem o potencial de falhar catastroficamente;
• Não reinvente a roda, você não deveria. Se você está tentando implementar seu próprio HashMap, provavelmente está fazendo algo errado. Pesquise coisas e pense antes de escrever o código.

Espero que algo disso tenha ajudado.

Bem, na minha opinião, como em qualquer profissão, para ser um bom profissional, tudo o que é necessário - além da formação teórica - é experiência .

Como um médico não pode ser bom apenas com as aulas realizadas na faculdade de medicina, ou um advogado não pode conhecer todo o lado político de ser uma jornada apenas com seu diploma, ser um bom desenvolvedor precisa de experiência e tempo.

A experiência não vem da leitura de códigos de terceiros. Se você receber um estudante de medicina, ele / ela poderá apontar muitos procedimentos, doenças, medicamentos etc., mas a aplicação real dessas coisas (quando aplicar um procedimento, que desejo diagnosticar etc.) só vem com supervisão e experiência.

Como você não deseja trabalhar para uma grande empresa (ou qualquer outra empresa), sugiro que você comece a desenvolver pequenos aplicativos, uma etapa de cada vez. Desenvolver software sozinho leva muito tempo, acredite.

Outra coisa que sugiro que você se torne um bom desenvolvedor / engenheiro de software é contribuir para o software de código aberto. Muitos caras ganham uma boa quantia de dinheiro (e experiência, btw) ajudando a desenvolver software de código aberto e dando consultas depois. Eles fizeram um nome para si mesmos com suas contribuições para o código aberto.

De qualquer forma, acho que não há um atalho para ganhar experiência, e deve ser buscado com disciplina e paciência .

Você pode começar aprimorando o código de outras pessoas. Pegue um projeto que você tem e adicione um recurso a ele. Você terá que decidir o que o recurso fará e como deve fazê-lo. Trabalhando dentro da estrutura do código existente, projete sua solução.

E não tenha medo de cortar coisas. Muitos novos desenvolvimentos são feitos refinando (ou de preferência reescrevendo) protótipos rápidos e sujos. Vá em frente e use todas as piores práticas e antipadrão do livro, apenas faça algo que faça o que você deseja. Depois, volte e projete-o corretamente. Normalmente, eu me pego pensando "Sabe, uma maneira melhor de fazer isso seria ..." enquanto codifico alguns parâmetros de configuração na minha monstruosidade de três procedimentos de 800 linhas.

Sei que atualmente está fora de moda, mas as técnicas de análise estruturada realmente me ajudaram a entender o design de software. Brinque com alguns gráficos de bolhas e DFDs para ter uma ideia dos problemas em decomposição e projetar diferentes partes de um sistema para trabalharem juntos.

Como outros já disseram, a experiência vem da escrita de código. Mas você também deve ter alguém para revisar seu código, se possível. Um programador mais experiente pode apontar problemas no seu código e mostrar melhores maneiras de fazer as coisas. Contribuir para um projeto de código aberto lhe dará a chance de fazer as duas coisas.

Para mim, ajuda a dividir um pedaço maior de software em pedaços menores. E então quebre esses pedaços em partes ainda menores e assim por diante. Todo programa de software é uma coleção de pequenos pedaços de lógica.

Considere um blog, por exemplo. Você deseja criar e editar postagens que outras pessoas possam ler. Imediatamente, você pode dividir o projeto em seções administrativas e públicas. No mínimo, o administrador exigirá usuários, uma página de login e uma seção para gerenciar o blog. A seção para gerenciar o blog pode ser dividida em uma interface CRUD (Criar, Ler, Atualizar, Excluir). A criação de uma nova postagem no blog exigirá uma verificação para garantir que o usuário administrador tenha os privilégios corretos, um formulário, validação de formulário e a capacidade de salvar no banco de dados. E assim por diante.

Quanto mais você quebra um problema ou um recurso, mais ele se torna administrável. É dividir e conquistar. Depois de conseguir mapear seu software dessa maneira, você pode ver como diferentes partes dele interagem entre si. Onde você pode repetir o código? O que pode ser abstraído? Esse deve ser um processo iterativo, conforme você planeja e ao escrever o próprio código.

Eu recomendaria descobrir qual é o seu conjunto mínimo de recursos e implementá-lo antes de adicionar outros itens a ele. Você deseja codificar na defensiva para que futuras alterações não sejam muito difíceis, mas ao mesmo tempo, você não deseja implementar meios-recursos que talvez nunca sejam concluídos. É uma linha difícil entre permanecer flexível e estar disposto a matar seus queridos sem piedade, emprestando uma referência literária. Ficar bom nesse ato de equilíbrio específico só vem da experiência.

E é nisso que tudo se resume, como as outras respostas mencionaram: experiência. A única maneira de obtê-lo é apenas começar. Não se preocupe tanto em torná-lo perfeito desde o início. Primeiro, faça o código funcionar, depois faça bonito e depois rápido.

Além disso, ao contrário deste parágrafo, não adote a segurança no final como uma reflexão tardia. Você deve ter uma idéia de como o seu software pode ser comprometido, mas, para começar, nunca confie em nenhuma entrada do usuário.

Sei que você diz que não quer trabalhar para uma empresa de software, mas esse é um bom lugar para obter a experiência de que muitas das outras respostas mencionam. E se você deseja ou não trabalhar em grandes projetos, é bom ter uma exposição ao trabalho e aos estilos de trabalho de outras pessoas.

Você não pode experimentar a Programação de pares sozinho, por exemplo. E se você estiver emparelhado com alguém mais inteligente do que você, terá o benefício adicional de obter melhores práticas deles e obter experiência nessa metodologia.

BTW, eu fiz minha prática de tentar trabalhar com grupos nos quais sinto que estou abaixo da média em experiência, habilidade e coisas do gênero. Isso eleva meu jogo tremendamente. É muito mais difícil fazer isso sozinho ou onde você é o cara "experiente".

O que você está procurando é a habilidade de resolver problemas . Percebi que é assumido que o desenvolvedor já pode fazer isso, o que é bobagem. Felizmente, a resolução de problemas é uma habilidade geral, usada em matemática, pesquisa, vida cotidiana e assim por diante.

Primeiramente, você deve seguir o método científico, com alguns detalhes.

1. Você tem um problema (use ferramentas e técnicas para ajudar a definir isso)
2. Você propõe uma solução (ajuda de padrões e experiência)
3. Hipótese de teste (talvez você nem tenha código aqui)
4. Repita as etapas 2 e 3 até que a hipótese seja mantida. Agora você tem uma teoria (programa de trabalho para resolver o problema)
5. Desenvolva um experimento para enfatizar a teoria, procurando buracos (casos de teste!)
6. Se os casos de teste persistirem, você terá uma solução! Caso contrário, enxágue e repita

Observe que este é um nível bastante alto. Cada etapa normalmente envolve várias subetapas, como determinar qual é realmente o problema. Como exemplo, observe a solução de problemas de palavras em matemática. Você coleta fatos (uma ferramenta) e determina o que é realmente desejado. Em seguida, você examina seus fatos, tentando mapeá-los para a solução.

Isso acaba se tornando subproblemas do problema principal. Então, siga as etapas novamente. Precisamos de um item intermediário para obter o resultado final, para que ele se torne nosso novo problema. Isso decompõe o problema em seções pequenas e fáceis de entender. À medida que cada peça é resolvida, a solução é montada.