Ontem, o filho do meu amigo se inscreveu em engenharia de software e me perguntou o que estudar em engenharia de software? Então fiz uma lista de livros para ele.
Agora, faculdades e universidades abriram vários cursos famosos:
Categoria de tecnologia parcial: computação em nuvem, big data, inteligência artificial, Internet das coisas
Aplicações parciais: e-commerce, gerenciamento de informações
Mas, pessoalmente, sinto que há muitas pessoas que conhecem linguagens de programação e usam estruturas de código aberto, mas a China carece de talentos em análise de sistema, design de sistema e arquitetura de sistema, e pessoalmente acho que esses cursos deveriam ser os cursos básicos de engenharia de software, mas parece que os cursos de engenharia de software nas faculdades e universidades de nosso país não ensinam essas coisas.
（1）
Engenharia de software também é engenharia.
Quando pensamos em engenharia, pensamos em:
Planejamento, pesquisa, design, verificação de teste, revisão
Especificação padrão, registro e certificação
Construção, pré-fabricação, grandes ferramentas de construção
Supervisão de Qualidade Garantia de Qualidade, Supervisão de Segurança da Produção
Gerenciamento do cronograma do projeto/gerenciamento de custos/gerenciamento de mudanças, gerenciamento de documentos de engenharia
(2) Análise do Sistema
Não estudei nenhum livro bom sobre análise de requisitos e análise de sistema e não passei no exame de analista de sistema quando estava na faculdade.
O único livro que li em termos de análise de requisitos é: "User Stories".
O livro que li sobre análise de sistemas, recomendo: "Analysis Patterns: Reusable Object Model". Na verdade, este livro pode ser melhor chamado de "Padrões analíticos", sem um subtítulo.
Se falamos de metodologia de análise, sinto que recomendo um livro: "Princípio da Pirâmide".
(3) Projeto do sistema
No projeto do sistema, presto atenção especial à relação entre camadas e blocos. Como desacoplar e associar essa relação requer habilidade. Portanto, recomendo dois livros: "Domain-Driven Design: How to Cope with the Complexity of Software Core" e "Design Patterns".
Símbolos padrão de design: "UML Essence". Há também um livro "Elephant: Thinking in UML" escrito por um chinês, que também é muito bom.
(4) Projeto de arquitetura
Em relação à arquitetura, esses dois livros são muito bons: "Enterprise Application Architecture Patterns" e "The Way of Clean Architecture"
Estilo de arquitetura de software, de componentes a serviços SOA e microsserviços nesses anos, então eu recomendo:
Era orientada a objetos: não vi um bom livro. Além disso, o "Análise e Projeto Orientado a Objetos" de Master Booch, eu pessoalmente sinto, não é um bom livro sobre o uso de métodos orientados a objetos para projeto arquitetônico.
Era Componente: "COM Essence", "Desenvolvimento J2EE sem EJB"
Era SOA: "Soa Core Technology and Application"
A era dos microsserviços: "Padrões de design de arquitetura de serviço"
(5) Desenvolvimento de software
Existem muitos livros sobre linguagens de programação e frameworks de programação, mas poucos livros sobre desenvolvimento e implementação de software sob a perspectiva da engenharia de software.
Recomendo alguns livros:
"Desenvolvimento Orientado a Testes"
"Reestruturação"
"A maneira de limpar o código"
"Programação extrema"
(6) Garantia de qualidade
Originalmente, o teste de software e a garantia de qualidade são partes muito importantes da engenharia de software. Infelizmente, nunca vi um bom livro. Pode-se ver que nem todos prestam atenção ao fato da qualidade do software.
(7) Ferramentas
Falando em várias ferramentas para desenvolvimento de software, todos estão familiarizados com o desenvolvimento de IDEs, estruturas, componentes de interface do usuário front-end, middleware em execução e bancos de dados. Do ponto de vista da engenharia de software, todos estão familiarizados com várias ferramentas de integração contínua de CI, lançamento contínuo de CD e DevOps.
Talvez eu seja ignorante, o único livro bom que li pessoalmente sobre esse assunto é: Continuous Delivery: A Systematic Approach to Publishing Reliable Software.
(8) Gestão de processos
Para gerenciamento de engenharia de software, se você quiser aprender com a visão geral da estrutura geral, recomendo primeiro o "TOGAF Standard Manual". Não sei por que, mas muitas pessoas consideram o TOGAF um método de arquitetura de software e, pessoalmente, me sinto errado. Se você realmente quer fazer arquitetura de software, sugiro que leia os livros que recomendei na seção de projeto de arquitetura de sistema acima.Somente esse conhecimento pode tornar seu software verdadeiramente arquitetônico. Depois de ler o TOGAF, você não tornará seu software arquitetônico. Muitos tomadores de decisão de TI corporativos gostam especialmente de apresentar o TOGAF, pensando que depois de aprender e usar o TOGAF, o software pode ser estruturado, o que é realmente...
Para a categoria abrangente, recomendo "Code Encyclopedia" e, para a categoria prática, recomendo "Microsoft's Secret".
Nos livros de gerenciamento de projetos, recomendo o "Guia PMBOK". Eu recomendo fortemente a introdução de um gerente de projeto em tempo integral no processo de desenvolvimento de software. Não deixe o gerente de produto, gerente de departamento de desenvolvimento ou líder de desenvolvimento assumir a responsabilidade do gerenciamento de projeto. Isso é um grande mal-entendido.
"The Mythical Man-Month" é um livro muito conhecido na engenharia de software, mas não recomendo a leitura.
Quando você pensa em engenharia de software, pensa em um ciclo de projeto muito longo, um grande número de participantes e um processo de projeto muito pesado. Pessoalmente, tenho trabalhado no campo de pesquisa e desenvolvimento de software por muitos anos e tenho a sensação de que os objetivos de vários departamentos profissionais são inconsistentes e a eficiência do compartilhamento e transmissão de informações é lenta / as informações são distorcidas e deformadas . Portanto, sempre defendi equipes pequenas, equipes pequenas enxutas, equipes com recursos completos e equipes no estilo cirurgião. Recomendo um livro a todos: "SCRUM Agile Software Development".
Além disso, eu pessoalmente não gosto da expressão Ágil. Sinto que esta palavra tem sido mal interpretada por todos. Prefiro usar a palavra Lean, que é a correspondência produto-mercado e correspondência realização-demanda de que se fala frequentemente agora. Nos últimos anos, com o aumento da localização da Huawei, todos correram para aprender com a Huawei, então o vocabulário e o método muito antigos de IPD se tornaram populares na indústria chinesa de TI. Todos pensam que esse método é complicado quando pensam que o IPD vem da IBM. No entanto, recomendo dois livros: "IPD Huawei's R&D Way" e "IPD Refactoring Product R&D". Esses dois livros foram escritos por ex-funcionários da Huawei, mas na verdade não foram escritos pelo IPD, muito menos pelo IPD da IBM, mas são chamados de IPD, mas o conteúdo é bastante novo e a correspondência mercado-produto , correspondência de realização de demanda, mercado -demand-product-realization, como conectar cada departamento e posição.
