Involuntariamente se tornar um programador: como fazer isso certo? [fechadas]

Minha formação é em engenharia elétrica, DSP para ser mais preciso. Atualmente, a empresa em que trabalho realiza diversos projetos, principalmente a construção de hardware analógico. Por estar um pouco mais próximo dos computadores do que de todos os outros por aqui, geralmente sou o único código que escreve para dispositivos incorporados (com os quais eu estou perfeitamente bem) e sistemas operacionais Windows ou Linux. É o último território estrangeiro para mim.

Eu posso codificar e conheço algumas linguagens (C / C ++, Java, algumas VB.NET), mas as usei apenas para simulações de algoritmos no processamento de sinais e imagens, redes neurais e outros aplicativos similares. Para mim, a programação tem sido uma ferramenta computacional mais do que qualquer outra coisa. No entanto, recebo mais e mais projetos nos quais tenho que escrever um software completo adequado e realmente não sei como fazê-lo, porque nunca precisei fazê-lo e nunca fiquei realmente interessado o suficiente. Eu mesmo já vi vários engenheiros que foram convertidos em codificadores até certo ponto por causa das demandas de emprego, e a maioria deles não era tão boa no que fazia. Tenho certeza que muitas pessoas encontraram o mesmo.

Se eu aprender a escrever software adequado com boa interface do usuário, boa arquitetura interna e assim por diante, como faço? Não temos ninguém no trabalho que possa me dizer o que é uma boa prática e o que não é. Como posso escrever código no sentido mais bruto da palavra, o que mais há para saber sobre como escrever um bom software e como chego lá sozinho?

Existem alguns livros que o ajudarão muito. Sugiro ter sempre ao seu lado o Código Completo . É uma referência inestimável. Em uma empresa anterior em que trabalhei, esse também foi o livro que demos a todos os programadores juniores após serem contratados.

O Programador Pragmático também é um recurso realmente útil e é bastante curto, mas sugiro que você o leia após o Código Concluído.

Esses livros ajudarão você a começar e depois codificar, codificar e codificar mais ... mas saiba quando parar, seu software nunca será perfeito.

Minha empresa faz isso o tempo todo ... e isso me deixa louco.

"Sou desenvolvedor de software, como me torno um EE?"

Bem, acho que a resposta é bastante óbvia. Leva muito tempo e trabalho duro. E, claro, os materiais de aprendizagem certos. Os conhecimentos de engenharia ajudam, na minha universidade, as escolas de engenharia e de engenharia estavam no mesmo prédio com muita sobreposição. Os algoritmos e fundamentos matemáticos estão lá.

Um erro que vejo muitos recém-chegados cometem é morder muito mais do que conseguem mastigar. Materiais de aprendizagem na interface do usuário, arquiteturas, código de qualidade ... isso é muito importante . Algo que realmente leva anos e geralmente é feito por equipes de diferentes especialistas de empresas de software.

Para não dizer que você não pode ser bastante decente por conta própria, se você dedicar tempo. Apenas reconheça a magnitude dos materiais para não se sobrecarregar e A. Sair ou B. Construir uma dívida técnica importante em seus aplicativos, usando atalhos importantes no processo de aprendizado.

Por tudo isso, não há "catch-all" se tornando um desenvolvedor incrível com este livro por aí. Eu recomendo que você comece escolhendo um livro bem classificado no idioma mais usado e também participando da comunidade Stack, especialmente para revisões de código.

Tente Amazon.com, eles têm boas críticas de livros.

Livros : o principal é ler (bons) livros no idioma de sua escolha. Depois de conhecer seu idioma de escolha, você poderá obter " X mais eficazes " ou "Y práticas recomendadas" e assim por diante. Acho que os livros de receitas são muito bons para preencher as lacunas que você pode ter. Então, acho que são pelo menos três livros que você precisa obter. Uma coisa: faça exercícios e codifique kata para melhorar sua compreensão do idioma. Obviamente, você precisa de um bom padrão xUnit .

Os algoritmos são particularmente importantes e você deve escolher um livro que os detalhe - novamente, no idioma de sua escolha. Padrões de design e antipadrões valem a pena conhecer em qualquer idioma.

Conclusão: leva tempo. Não se apresse.

Você é péssimo em codificação. Sim.

Mas - isso não significa que você não pode entregar software, que faz as pessoas felizes;)

Seja humilde. Escreva o "negócio" da lógica, que você precisa. Use o código da biblioteca para todo o resto. Não tente escrever algoritmos fundamentais (como a classificação de array ), não use nenhum "truque de fantasia", siga algumas convenções draconianas de código.

Use um bom IDE. Isso é essencial, pois ajudará você a formatar seu código e rastrear erros de digitação / erros simples.

Leia livros como " Code Complete " e " Pragmatic Programmer ", tente se forçar e aprender OOP (é simples e ajudará você a manter seu código mais sustentável).

Use SVN , confirme com freqüência, - para poder reverter suas alterações (quando você estragar alguma coisa).

Encontre alguém que seja um verdadeiro programador , com formação acadêmica, se possível. Assim, você poderá conversar com ele, compartilhando seus problemas de novato e obtendo respostas esclarecedoras.

E, claro, o mais importante é também continuar codificando, codificando, codificando .

ps: se você é capaz de escrever código C ++ que funciona, e você escreve redes neurais (!) - então seu cérebro é adequado para programação;) Boa sorte!

Há boas respostas aqui.

Uma grande virada a seu favor é o simples fato de que você quer saber.

Grande parte da engenharia de software (que você deve considerar com ceticismo saudável, é claro) é sobre como fazê-lo de maneiras que você não se arrependerá mais tarde. Um exemplo é o uso de um sistema de controle de versão do código fonte. Outra é dividir o código em arquivos, para que seja mais fácil trabalhar gradualmente. Outra é ser um defensor da ordem - convenções de formatação e nomeação de código. As convenções exatas não importam tanto quanto são consistentes.

Dessa forma, quando você voltar ao código em um ano ou mais, não pensará em "Quem fez essa bagunça?" Você será capaz de encontrar coisas e alterá-las sem muito risco de quebrar. **

Uma boa maneira de começar é encontrar vários programas de exemplo e trabalhar com eles. Então você pode adaptá-los às suas necessidades.

** Uma das minhas maiores dores de cabeça é tentar trabalhar com código escrito por pessoas que não pensavam que formatação ou nomeação eram importantes.

Embora existam muitos e bons recursos sobre como fazer e não fazer coisas, no final, o mais importante é ver muito código e trabalhar com ele e ver como é fácil ou complicado manter por si mesmo.

Uma boa maneira de aprender é ter alguém experiente para fazer o design inicial e, em seguida, revisar seu código e mostrar-lhe técnicas úteis conforme você as utiliza. Portanto, se você, por acaso, conseguir convencer seus chefes a contratar pelo menos um engenheiro de software com experiência em liderar (pequenos) projetos de software e projetar software para liderar os projetos, acho que seria a melhor opção.

Se você não consegue convencer ninguém, há atualmente um forte movimento de código aberto. Talvez você use algumas ferramentas de código aberto no seu trabalho, então tente consertar bugs nelas ou adicione recursos simples que você usa e discuta como fazer essas coisas com a respectiva comunidade. É um exercício de aprendizado prático inútil aprender como aplicar as regras gerais que você encontrará nos livros sobre problemas práticos reais.

Uma coisa que eu realmente recomendaria para aprender a codificar com qualidade e as preocupações de arquitetura seriam os ensinamentos de "Tio Bob" (Robert Martin). Ele tem alguns vídeos de US $ 1 que são muito pequenos, se bem que extravagantes, além de alguns bons livros.