速读《构建之法》（Build to win）有感

通过这两天时间，我粗读了《构建之法》这本书。老实说，对于这样四百多页的一本书，刚开始把这样的任务当作是一种负担，然而当我开始真正接触它时却被它幽默有趣的风格所深深吸引，它不同于以往学习的教科书晦涩难懂，书中以“阿超”为代表举了很多有趣小例子，读完让人印象深刻，不到一会儿就读了小几十页，同时也让我对软件工程这个概念有了初步的认识。

问题一： 说起来，学习编程也已有两年多的时间，然而回想这段学习，自己似乎从未对编程的内容有过深入的思考，一直以来自己似乎都停留在完成布置任务，无论代码内容如何，只要能达到结果目的即可。读完这本书的目录让我知道，一个完整的软件工程需要很多步骤，它是一个需要整个团队精诚合作所完成的一件事情，每个人的工作都有着相互的依赖性，个人的编程习惯也许能在一时达到某个目的，却也许会因为这样的习惯在后期让整个团队付出很大的代价，那么我们在实际的操作中应当如何使得自己负责的模块不会影响其他模块？应当如何使得自己的模块的质量得到保证呢？

问题二：如何才算得上是一个合格的软件工程师，或者说优秀的东西似乎都具备着一些共同的特质，那么一个合格的软件工程师所写的代码应当都具备哪些特质呢？这些特质该如何融合到我们平时的练习当中去？

问题三：书中P52页提到，“”软件工程师不宜过早的优化，不能过于积极的解决所有依赖性问题”，在平日里写代码时，遇到问题及时解决在最后才不会花费太多精力和代价在代码的改进和优化上，小的工程代码尚且如此，在大一点的软件工程项目中后期岂不是要付出更大代价？

问题四：一个软件的诞生似乎源于用户对于这款软件的需求度，人们在现实社会和生活中遇到各种问题时，需要求助于各种软件，人们的需求往往五花八门。在本书P165页中邹欣老师也曾提到“原来我并不了解海量中国用户，原来真实的用户并不是我想像的那样”。我相信任何一个做软件的程序员一开始都认为自己做的东西是被用户所需求的，所以才会有去设计软件的冲动，只有这样这样自己所做的东西似乎才被赋予了意义，那么做软件的人在做软件前就一定会对这个软件进行需求分析，既然是在做过需求分析后得到的软件，为什么依然存在需求不对称的问题呢，书中提到“不理解为什么有那么多人为了qq上的虚拟形象付钱，现实中的很多人喜欢漂亮和虚荣，因而她们不在乎花点钱打扮自己”，我在想在做软件时有时更重要的也许是这样的“隐性需求”，并不是简单的“用户调查问卷”一类的需求分析所能体现出来的，那么这样的需求分析是否还有必要呢？

问题五：“好的开始，不一定会有好的好的结尾，坏的开始，结果往往会更糟" 对于软件工程这门课程我们都是刚刚开始的学徒，在书中所介绍到的包括软件工程师，项目经理，软件测试人员等等都是软件开发工程中必不可少的关键人员，每个人的分工不同，侧重点也不同，那么作为现在的我们来说侧重点应该放在那里呢？ 或者说为了以后更好的完成这些工作，我们现在最应该做好的是什么？

------记于课程的开始

期望自己执着的热情，期待课程后续的内容，但愿在这一学期自己能真正从中学习到些什么……