5.1 概述
技术是为业务服务的，所有的技术工作的目标都是为了解决业务问题，此外技术的选择还要符合软件工程学，学习软件工程自然要拜读被称作软件工程圣经的《人月神话》，用生动的语言和故事，深入浅出地揭露了软件工程的本质，并有大量软件工程的实践，让你少走弯路。无论有志于软件开发团队中的任何一个岗位，都应该了解软件工程的方方面面，与团队保持一致的价值观，志同道合，团结协作，共同完成目标。
另一本在软件管理领域的优秀著作《人件》，是软件管理领域的传奇经典，被誉为“对美国软件业影响最大的一本书”。全书从管理人力资源、创建健康的办公环境、雇用并留用正确的人、高效团队形成、改造ag真人试玩娱乐的文化和快乐工作等多个角度阐释了如何思考和管理软件开发的最大问题——人（而不是技术），以得到高效的项目和团队。
然后就是《软件工程–实践者的研究方法》，全面、系统讲解了软件开发的方方面面。最新版好像是第8版。
1.2 敏捷开发
敏捷开发目前已经普及到了软件开发的各种规模的企业，虽然系统地应用敏捷开发方法体系的企业并不太多，但或多或少得都实践了部分敏捷开发的实践，比如每日立会、结对编程、测试先行等。敏捷开发包括很多种方法体系，使用最广泛的当属于scrum和极限编程（xp），而且scrum是一个框架，与xp可以完美结合。
《敏捷软件开发》、《scrum敏捷软件开发》、《解析极限编程–拥抱变化》这三本基本把敏捷开发主要内容了解清楚了。
还有一本值得一读，甚至作为手册的小书《scrum要素》非常精炼地总结了scrum的方方面面，并且有作者的独到见解，读完前面三本后再读一下这本，并以后作为手册翻阅还是不错的。比如“故事点”的概念，本人与该作者有着同样深的感觉，太难了，太难了，真的太难了。所有scrum的概念里，这个是最难的，可操作性比较差，最后都只能以“人天”来代替。一方面，团队内部很难就一个参考的故事作为参考点达成共识，其次，团队的成员很难保持不变，再者，很难保证所有团队成员在一个完整的sprint中不被打断。看到作者也解决不了的问题，我也释怀了，后来再不纠结于“故事点”了 ：）。
1.3 软件设计
uml是软件设计必学技能，无论是产品经理、架构师、程序员都应该理解常用的用例图、时序图、类图、部署图、通讯图、活动图等，都是非常好的表达工具，整个团队有了统一的交流语言，在沟通上既准确又高效。读一本《uml用户掼》也基本就够了，如果想深入了解，可以再买一本《uml参考手册》。很多软件都可以支持uml，并通过代码生成类图，试过好多，magicdraw是最专业、最好用的软件，没有之一，只是收费的。star uml试过很多次，可能用magicdraw太习惯了，感觉太难用。
软件设计的核心还是软件，uml只是表达语言，比编程语言更高一层次的表达语言，然后就是如何使用这个语言表达需求、架构的设计。《架构之美》让最优秀的设计师和架构师来描述他们选择的软件架构，剥开架构的各层，展示他们如何让软件做到实现功能、可靠、易用、高效率、可维护、可移植和优雅。
再向下就到了架构的实现层面，设计模式是这一层的基础，”四人帮“的《设计模式》中必读教材，没读过这本书好像都不好说自己是架构师。
正如”好的文章不是写出来的，而是改出来的“一样，“好的架构不是设计出来的，而是改出来的”，好的程序也是改出来的，软件架构、代码经过不断的重构、提炼、优化才能越来越精炼、灵活、高效、稳定，可维护性也才能越来越好，这是一个持续的过程，可能是每天都在做的事情。《重构–改善既有代码的设计》则从更具体的代码层次，指导程序员如何改出高质量的代码和设计。
这是一个良好实践的行为指南，告诉我们应该怎么做，同样还有另一本书告诉我们不应该怎么做：《反模式-危机中软件架构和项目的重构》。非常遗憾，这本书在豆瓣中的评分并不高，看来还是被很多人没有很好地理解，相反在实际工作中真的见太多由于坏的习惯和实践导致的问题和资源的浪费。比如“复制-粘贴”模式，复制别人的代码，不去深入理解，一运行正常结果是对的，然后就用于产品中，这是一个很可怕的做法，因为复制过来的代码中隐藏着的魔鬼很难被发现，因为代码不是你的。
项目成本、进度评估是软件开发一个非常重要的技能，软件开发中不确定性最强的因素就是人，如何能够准确评估项目成本及进度，把握市场与开发的节凑，配置合理的资源，顺利交付项目和成本，两本书需要读，并且需要不断地实践，在实践中锻炼评估的感觉，真的这个真的靠长时间锻炼出来的感觉。
（待序）