Como Praticar Deliberadamente Engenharia de Software? [duplicado]

Há uma diferença entre o que fazemos como engenheiros de software e o que um violinista (ou qualquer outra coisa que exija prática física faria). Um violinista passa horas praticando metodicamente porque está ensinando a seu cérebro padrões muito específicos de como interagir com um instrumento.

Praticar engenharia de software também envolve padrões de aprendizado. Quanto mais projetos você fizer, mais aprenderá (espero) sobre o que funciona e o que não funciona. Não há receita padrão para escrever ótimos softwares (é por isso que algumas pessoas comparam nossa profissão a um "ofício" em vez de pura ciência). Então, meu conselho # 1, escreva código e escreva mais código. E não pense que se o que você está trabalhando é divertido, não está ensinando muito. Eu digo escolha algo que seja divertido; vai manter o seu interesse por mais tempo e você vai se divertir muito mais.

Você não precisa participar de um projeto de código aberto se não quiser. Basta definir uma meta para você, algo lhe interessaria e começar a codificar. Você nem precisa terminar, então não fique desapontado se no meio do projeto você decidir soltá-lo e ir para outra coisa. O mais importante é que, enquanto você se afasta desse projeto, você precisa se afastar com melhores habilidades e mais conhecimento da tecnologia que usou.

Conselhos # 2, leia Programador Pragmático . A principal parte desse livro é que, assim como você pensa sobre como escrever um software, de vez em quando você precisa dar um passo atrás e rever seu processo para pensar em escrever um software. Toda vez que você trabalhar, não basta colocá-lo em uma prateleira e seguir em frente, mas dê outra olhada nele e pense em maneiras pelas quais você poderia ter feito melhor. Você não tem que ir e realmente refazê-lo, mas, pensando nisso, você exercitará seu cérebro para reconhecer os padrões que mencionei na introdução.

Conselhos # 3, fale com outras pessoas que são apaixonadas por escrever código. Ouça o que eles fizeram e como eles abordaram as coisas. E explique a eles o que você está fazendo. Eu tenho poucos amigos no trabalho e, periodicamente, eu simplesmente entrava no cubo e rapidamente esboçava o design do software no qual estou trabalhando. Às vezes eles apenas assentem, mas outras vezes, eles podem dizer, bem, se você mudar esta caixa para cá e se livrar dessa classe, você poderia economizar 2 dias de trabalho e ganhar vantagens A, B e C.

Conselho # 4, depois de ter feito alguns projetos e encontrado alguns padrões. Volte e leia livros como o famoso livro do GoF . Se você já trabalhou, você a) reconhecerá algumas das coisas sobre as quais os autores estão falando e b) descobrirá diferentes maneiras pelas quais você poderia ter abordado seus projetos.

O conselho # 5, sempre continue lendo e desafiando a si mesmo. Nunca entre no modo que agora conheço a tecnologia X, portanto sou um especialista. Não importa o quanto você acha que aprendeu, lembre-se, há infinitamente mais para você absolver, então, no esquema geral das coisas, você ainda não sabe muito. Continue lendo blogs; aprenda um novo idioma. Por exemplo, eu tenho lido sobre F # e programação funcional, embora eu principalmente programa em C + + e comecei a aplicar conceitos funcionais para o meu código orientado a objeto. Em alguns lugares isso simplificou muito o uso de vários threads e sincronização de dados.

Nenhuma das opções acima é engenharia de software. Tudo é apenas programação de maneira aleatória.

Engenharia de Software (SE) é uma disciplina de engenharia preocupada com uma abordagem sistemática, rigorosa e disciplinada para o projeto, desenvolvimento, operação e manutenção de software, e o estudo dessas abordagens; isto é, a aplicação da engenharia ao software.

Em particular, o software pode ser projetado quando você aplica técnicas de engenharia. Para aprender tais técnicas, o melhor é estudar um Grau de Mestre SE relevante. Quando você ensina a si mesmo, você pode aprender sobre programação, mas eu não consigo imaginar você aprendendo engenharia por conta própria.

Exemplo: O programador vem e começa a escrever código, otimizar código, etc. (tudo o que importa para um programador é código e nada além de código). Projetos complexos geralmente atrasam, o orçamento é excedido em até algumas ordens de grandeza e o software não resolve bem os requisitos. Isso é conhecido como crise de software. A resposta para isso é a disciplina SE.

SE vem e quer entender o domínio do problema como a primeira coisa. Uma abordagem de engenharia é aplicada, em especial a Engenharia de Requisitos (RE) (elicitação de requisitos - > análise de requisitos - > especificação de requisitos - > validação de requisitos).

O resultado do RE é tipicamente um conjunto de modelos, como modelo contextual, modelo comportamental e modelo de processo de negócios. A partir desses modelos, a SE entende o problema de negócios e projeta uma solução de software.

O design geralmente significa que o SE traduz modelos de requisitos em arquitetura de sistema baseada em componentes e, em seguida, projeta o design de componentes para cada componente individualmente. Isso resulta em uma determinada especificação de limites de componentes, interfaces de componentes e classes para compor componentes.

O próximo passo é alguém que chega a essas interfaces (geralmente autogeradas) e cria sua implementação. Essa pessoa pode ser um programador. Finalmente, o SE segue com validação de software, onde tudo é testado em relação ao design e aos requisitos originais.

No SE, os projetos normalmente têm um plano de projeto que permite aos engenheiros planejar, controlar e monitorar projetos. Em particular, o software é projetado dentro do prazo, do orçamento e da especificação.

Durante a fase de implementação do software, a documentação é produzida para cada artefato e muitos Itens de Configuração (ICs) são gerados. Estes precisam ser gerenciados de alguma forma. Normalmente, no SE, há um repositório de Gerenciamento de Configuração de Software (SCM) e Gerenciamento de Mudanças. Outra parte do SE é o Software Process (SP), ou seja, RUP, Scrum, DSDM, Crystal, Waterfall, ...

O SP deve ser documentado e rigorosamente seguido como na documentação, sem qualquer exceção, para que os resultados sejam sempre reproduzíveis. (ISO 9000). Isso se refere à qualidade de software.

Outro tópico do SE é Medição e Estimativa de Software, que permite medir a eficiência do seu SP, o desempenho da equipe, o tamanho estimado do projeto (LOC - Linhas de Código), ou seja, COCOMO, entrega estimada do projeto (homem-dia) e similar. / p>

Ainda há muito mais para SE do que esta breve resposta descreve. Aplicando abordagens SE em vez de apenas escrever código é como você pratica SE.

Como o SE ainda é um campo emergente, acontece que os não engenheiros se chamam de engenheiros. A menos que estejam aplicando abordagens de engenharia, elas são meramente programadoras.

Para mais informações, consulte Engenharia de Software por Ian Sommerville e www.ieee.org / www.computer.org. Nestes recursos, o SE é a disciplina de engenharia. No Stack Overflow e em muitas empresas, infelizmente, eles pegam emprestado o termo SE e o usam como outro nome para programação.

Duas coisas que vêm à mente são o Projeto Euler e o Desafio AI do Google a>. Especialmente se você fizer isso em um idioma diferente de sua linguagem de trabalho diário, esses tipos de problemas são restritos o suficiente para esticar suas habilidades, mas também simples o suficiente para ter abordagens claras.

Eu tenho feito o desafio da AI este ano, e o que eu acho mais fascinante é que o problema é simples o suficiente para ser resolvido com algoritmos básicos, mas você atingirá o limite de tempo por turno se fizer isso o caminho ingênuo. Você tem que entender não apenas a parte mecânica do básico, mas também as razões subjacentes por trás deles, a fim de fazê-lo funcionar dentro dos limites de tempo.

Depois de escrever um bloco de código que funcione e passe em um teste, pergunte a si mesmo "esse código pode ser melhor?". Nesse contexto, melhor não significa necessariamente mais rápido ou mais eficiente, embora isso seja parte disso. Clareza do código também é importante - alguém pode olhar para ele e entender o que está fazendo. Pergunte a si mesmo se você enviaria esse código a um empregador em potencial como representante de seu melhor trabalho.

Não faça isso apenas para o seu próprio código pessoal. Visite sites como este e responda a perguntas que exijam que você forneça um exemplo prático. Escrever código que possa algum dia ser copiado e usado por pessoas que estão apenas aprendendo pode ser um poderoso motivador. Certifique-se de fazer isso com seu nome real, para que você não tenha outra escolha a não ser reivindicá-lo como seu.

Outra maneira de fazer isso - e vejo que você é - é escrever um blog que exige que você forneça código. Mais uma vez, isso obriga você a escrever códigos que serão vistos publicamente, abertos a críticas.

Quando você escreve um código que será lido e examinado por outras pessoas, acho que é o equivalente a praticar escalas.

Uma abordagem pode ser a de um projeto não-trivial relativamente (digamos, mais de 1000 linhas), e portá-lo para outros idiomas. Você descobrirá que isso destaca muitas suposições feitas para você pelo seu idioma.

Outra abordagem pode ser determinar um projeto maior - pelo menos 10KLoC de acordo com sua estimativa - e começar a escrevê-lo, escrevendo rapidamente. Continue escrevendo, e depois que o objetivo for cumprido, mantenha-o. Isso vai te ensinar sobre o gerenciamento de codebases em mutação ao longo do tempo.

Apenas alguns pensamentos.

Como um escritor pratica escrever livros?

OK, o que eu quis dizer é que escrever código não é como dominar um instrumento musical. O papel de um programador é mais um escritor ou um compositor tentando encontrar o acorde certo. Então, você deve se perguntar como esses profissionais praticam seu ofício. Na verdade, acho que nossa profissão tem mais em comum com aqueles do que com outras disciplinas de engenharia.

Um escritor pratica escrever escrevendo livros e um compositor pratica compor compondo música, então um programador deve praticar programação por programação.