《构建之法》这本书确实和以往的参考教材有所不同,它的讲述更加生动。在大二上学期学习的软件工程这门课程时,我会感觉内容有些枯燥和乏味,不能真正理解软件工程的作用,也无法区别软件工程和计算机科学有什么样的差别。读过本书的第一章,我理解了软件工程是一种实践,它应用于软件的开发。
首先,软件从需求分析开始。顾客的需要有时是不明确的,多变的。因此为了更好的开展后续工作,必须做好需求分析。实际的需求,才是软件工程需要的。否则设计出来的软件顾客不买账,或者与同类软件相比没有人愿意使用,便成为一个失败的设计。在书中飞机安全功能这一例子时,我先选择了“做了,但是不用告诉用户”这一选项。阅读过后才明白,或许就是这十分小的使用概率,却成为软件安全的关键。我们设计的软件要尽可能的严谨。虽然在软件后期维护中问题可能层出不穷,但是一开始的设计就漏洞百出,维护也相当困难,甚至不能设计并完成成品。
软件工程使用的方法是系统、有序、可量化的。在软件开发流程中,要尽可能做到开发、运营、维护的高效率,也要考虑到用户满意度、软件可维护性以及软件的质量。现实中我们看到,软件的开发流程提速远不及计算机硬件的发展速度。这是因为软件有它的特性,主要是复杂性、不可见性、易变性、服从性、非连续性等等。而计算机科学是理论研究。运用计算机科学理论研究的成果,可以更好的为软件设计的程序分析服务。软件工程与计算机科学有着各自的特点,可以相互为彼此的发展起促进作用。
软件工程还有一个要求,便是“在预计的时间内发布‘足够好’的软件”。对于这句话,我觉得它给予我很好的警示。当有客户要求自己的团队写一个软件时,肯定需要考虑时间和成本。这些有限的资源下,需要我们尽可能设计出的满足顾客需求的软件。没有最好的软件,软件是一步步完善的。软件维护也有至关重要的作用。这些工作工作的完成,是需要一个默契的团队。
团队应该有集体目标,各自的分工,相互依赖合作。对于不同的人员和需求,软件团队有着不同的形式。例如主治医师模式、明星模式、社区模式、特工团队模式、交响乐团模式等。这些模式有各自的特点。但是若想软件一个能处于稳定成长阶段,大多采用“功能齐全”的交响乐团模式。我在周二听了一场软件的“敏捷开发模式”的课程。在这堂课中提到的碎片思维,使我比较赞同。其实说到软件开发,虽然每个成员有相同目标,但是各自的思维方式不同,即便是实现相同的功能,有些成员也会编出不同的代码。为了更好地统一,便有不同的开发模型。瀑布模型是最典型的一种。但是用户只能在软件完全开发完成才能见到软件。如果效果不理想,很有可能“牵一发而动全身”,有着巨大的成本风险。而渐进交付式流程如今用的更广泛。我们现在使用的各种APP基本上每隔一段时间就会有版本更新提醒。不断地根据用户反馈进行改进,也是提高软件使用率的手段。
团队的成长是需要彼此的磨合的,这也少不了绩效管理。一个团队里的成员,其实有着各自不同的期望,都希望为团队创造效益,也希望自己能在完成一个项目后自己有所收益。如何使得每个人都有各自的努力和作用,我们需要选择合适的绩效管理方法。在评价一个成员在团队的贡献,不能仅凭工作量,大家职责不同,工作量或多或少,但有的相同的重要性。在项目的进展中,问题是不断地。如果错误影响团队,反而探索出新的技术,是值得鼓励的。但影响整个团队,就要另当别论了。团队合作有几个阶段,不同阶段中大家有着不同的表现。我觉得书中所写的真的很符合我们现在组建团队遇到的情景。进入创造阶段的团队,是团队合作的最好的状态。
最后来看看软件工程师的职业道德规范。八个原则概括性词语:公众、客户与雇主、产品、判断、管理、职业、同事、自身。光是看着几个词,就可以联想到现实的工作场景。无论我们以什么样的身份存在于一个软件项目,我们的身上都有责任,对这份责任的态度意味着我们的成长。专业知识只能帮助我们解决技术问题,然而实际生活中有许多交流是受到人的主观情感影响的。尽自己最大的努力为团队贡献,也会成员彼此间受影响的。