自学感想1——《构建之法》CH1&CH5&CH17

       《构建之法》这本书确实和以往的参考教材有所不同,它的讲述更加生动。在大二上学期学习的软件工程这门课程时，我会感觉内容有些枯燥和乏味，不能真正理解软件工程的作用，也无法区别软件工程和计算机科学有什么样的差别。读过本书的第一章，我理解了软件工程是一种实践，它应用于软件的开发。

        首先，软件从需求分析开始。顾客的需要有时是不明确的，多变的。因此为了更好的开展后续工作，必须做好需求分析。实际的需求，才是软件工程需要的。否则设计出来的软件顾客不买账，或者与同类软件相比没有人愿意使用，便成为一个失败的设计。在书中飞机安全功能这一例子时，我先选择了“做了，但是不用告诉用户”这一选项。阅读过后才明白，或许就是这十分小的使用概率，却成为软件安全的关键。我们设计的软件要尽可能的严谨。虽然在软件后期维护中问题可能层出不穷，但是一开始的设计就漏洞百出，维护也相当困难，甚至不能设计并完成成品。

        软件工程使用的方法是系统、有序、可量化的。在软件开发流程中，要尽可能做到开发、运营、维护的高效率，也要考虑到用户满意度、软件可维护性以及软件的质量。现实中我们看到，软件的开发流程提速远不及计算机硬件的发展速度。这是因为软件有它的特性，主要是复杂性、不可见性、易变性、服从性、非连续性等等。而计算机科学是理论研究。运用计算机科学理论研究的成果，可以更好的为软件设计的程序分析服务。软件工程与计算机科学有着各自的特点，可以相互为彼此的发展起促进作用。

        软件工程还有一个要求，便是“在预计的时间内发布‘足够好’的软件”。对于这句话，我觉得它给予我很好的警示。当有客户要求自己的团队写一个软件时，肯定需要考虑时间和成本。这些有限的资源下，需要我们尽可能设计出的满足顾客需求的软件。没有最好的软件，软件是一步步完善的。软件维护也有至关重要的作用。这些工作工作的完成，是需要一个默契的团队。

        团队应该有集体目标，各自的分工，相互依赖合作。对于不同的人员和需求，软件团队有着不同的形式。例如主治医师模式、明星模式、社区模式、特工团队模式、交响乐团模式等。这些模式有各自的特点。但是若想软件一个能处于稳定成长阶段，大多采用“功能齐全”的交响乐团模式。我在周二听了一场软件的“敏捷开发模式”的课程。在这堂课中提到的碎片思维，使我比较赞同。其实说到软件开发，虽然每个成员有相同目标，但是各自的思维方式不同，即便是实现相同的功能，有些成员也会编出不同的代码。为了更好地统一，便有不同的开发模型。瀑布模型是最典型的一种。但是用户只能在软件完全开发完成才能见到软件。如果效果不理想，很有可能“牵一发而动全身”，有着巨大的成本风险。而渐进交付式流程如今用的更广泛。我们现在使用的各种APP基本上每隔一段时间就会有版本更新提醒。不断地根据用户反馈进行改进，也是提高软件使用率的手段。

      团队的成长是需要彼此的磨合的，这也少不了绩效管理。一个团队里的成员，其实有着各自不同的期望，都希望为团队创造效益，也希望自己能在完成一个项目后自己有所收益。如何使得每个人都有各自的努力和作用，我们需要选择合适的绩效管理方法。在评价一个成员在团队的贡献，不能仅凭工作量，大家职责不同，工作量或多或少，但有的相同的重要性。在项目的进展中，问题是不断地。如果错误影响团队，反而探索出新的技术，是值得鼓励的。但影响整个团队，就要另当别论了。团队合作有几个阶段，不同阶段中大家有着不同的表现。我觉得书中所写的真的很符合我们现在组建团队遇到的情景。进入创造阶段的团队，是团队合作的最好的状态。

      最后来看看软件工程师的职业道德规范。八个原则概括性词语：公众、客户与雇主、产品、判断、管理、职业、同事、自身。光是看着几个词，就可以联想到现实的工作场景。无论我们以什么样的身份存在于一个软件项目，我们的身上都有责任，对这份责任的态度意味着我们的成长。专业知识只能帮助我们解决技术问题，然而实际生活中有许多交流是受到人的主观情感影响的。尽自己最大的努力为团队贡献，也会成员彼此间受影响的。