个人阅读作业

软件工程最后一次作业

总结

对软件工程的学习做一个总结。

这个学期有两个老师开了软件工程课。
我问了一下学长的建议，两个学长都说：一定要选罗杰的。
我觉得可能学长们的重点还是这两点，提高真实能力与充实简历这一块。
而另一个老师开的软工，主要是写文档，并且“开发”了一个虚拟的程序。

一开始罗杰老师的课有60人选，第一次作业过后就只剩下20人。

我问了其他退选的同学，普遍都说：

因为这个学期还有同样重要的两门课——数据库和编译，事情很多而且从学分的角度来说不值得。
以上是题外话 。

说起自己的软件工程的学习：

前几次作业感觉都还行，从团队项目alpha版本开始，就开始深陷自己编码能力的不足带来的问题了。

每个学期都深陷这样的问题：
不管是计组还是OO还是软工还是编译
由于我们的编码能力，好吧，准确地说是由于我的编码能力不足，导致我认为我并没有学习到这门课程最核心的一些理念，比如这次的博客作业我就完成得比较吃力，反倒是过了一年再回首才有了一些相对深刻一些的感受。
最明显的还是OO课，老师在上课时也表示，因为你们编码能力不足，所以跟你们细讲概念也没有意义。虽然我OO作业都完成了，完成情况较好，但是我还是对OO不能说出个所以然，所以打算进一步自学。
至于软工。在老师布置第一个阅读作业的之后，在我读构建之法的时候。我有个想法：我以后一定要把这本书好好地看一遍，把每个参考文献都看一遍，把扩展阅读都看一遍。
我这个想法可能不切实际。

有些书上前人总结的一些精炼的话，在第一遍阅读的时候由于经验不足不能得出什么深刻的理解。而软工偏偏又是一门做种学的课程，没有做的经历自然也得不出深刻的理解，最终还是需要有开发的经验才会有更深刻的体会。
所以我还是要把这些文献再仔细阅读一遍的。

关于能力的提升。

编码能力提升了，了解了软件开发的过程与难点，越来越有了这样的体会：我能用代码来完成一件事

其他体会

我的体会是，一个好的PM不管这个PM是 programming 还是 product 还是 project / managing 对于团队来说都是很重要的。

同时由于这个学期的一些问题，软件工程的一些流程还是没有体验，比如维护的环节。与获取用户反馈的环节。从头到尾需求比较稳定，所以没有体验过被用户追着赶需求的推背感，总体上说没有体验过跟用户交互的环节。

结合阅读材料谈谈自己的理解或心得

NO SILVER BULLET

首先是《no silver bullet》一文，作者观点很明确当前软件开发的过程中面临着complexity(复杂性)、comformity(软件整合)、changeability(易变性)、invisibility(不可见性)四个问题，紧接着文章介绍了过去解决软件开发解决事故性困难的方法：高级语言：使得开发者不用在意底层实现，更好地以更接近人类思维的方式设计软件；分时：只要分时的频率足够大，就能取到很好的效果；统一的编程环境：这个不多说，统一的格式会带来交流的便利，同时代码也无需修改就能在不同的开发者的电脑上运行。

至于能否找到解决软件生产率的银弹，作者就如下问题进行了讨论：

• ada和其他高级程序设计语言的发展
  -- 实际上，这只是一个新的高级语言，它只能带来新的设计程序的方法

• 面向对象编程的方法
  -- 这只能降低定义接口的复杂度，而软件开发需要的复杂度并没有被解决

• 人工智能和专家系统

• 自动编程

• 图形编程
  -- 由于软件开发具有不可见性，所以这一条路也显然不能走

• 程序验证
  -- 验证程序也是程序。

• 环境和工具
  -- 工欲善其事，必先利其器，但是环境和工具只是针对了软件开发中的其他矛盾，不能实际减小开发的复杂度。

• 工作站

  最后作者论述了寻找银弹的一些前景：

  Buy versus Build

  Requirements refinement and rapid prototyping

  Great designers

  就我们这次开发来说：

  great designer大大提高了软件开发的效率

  同时，关于第二点，我的思路更偏向快速成型，而其他组员更偏向要求完善，在这一点上，如果我们能在这两个方向上达成共识，找到折衷点，这对我们的开发应该能带来更大好处。

BIG BALL OF MUD

大泥球指指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。

而泥球的产生实际上是因为

对需求和设计的理解不透彻，对软件业务流程不熟悉，缺少开发经验，另外，就像滚雪球一样坏的代码会不断累计成更坏的代码，除非我们着手完善它。

实际上我们的代码里肯定存在泥球，但不是大泥球，因此受这个的影响较小。

CatB

关于这一点，我们的初衷是想做成一个大教堂，实际上我们也使用了很多开源库，也就是实用了集市里的东西，我们也不排斥集市这一方法。但前提是我们的项目要能够吸引人们来使用。

一个开放式的项目，如果加以良好的管理和运作，能取得比同等的封闭式项目大得多的成功。

引用阮一峰老师的博客来说：

开放式的文化会最终胜利，这或许不是因为"开放"在道德上正确，或者"封闭"在道德上错误，而只是因为开放式合作可以在一个问题上投入多几个数量级的技术工时，封闭的世界无法赢得这样的竞争。

以前的博客

链接

0.软件具有易变性，我们如何在最初的开发中设计好程序的结构使其易于扩展呢？或者说，我们如何能在最初的开发中就预见到未来不断改变的需求呢。尤其是当我们连一点用户反馈的时候都没有的时候。

这需要产品经理对市场敏锐的嗅觉来奠定基础。

1.官僚模式下，程序员应当如何正当提出领导者的错误同时不被领导反感并使其虚心听从技术人员的建议？

这个问题更倾向于人际交往而不是软件工程的范畴。

2.在结对开发的磨合环节中，如果此时面临严峻的任务要求，如何加快磨合进度，还是说，此时严峻的任务要求，就足够加快结对的磨合了？

这个问题同上。

3.在团队开发中，个人贡献量究竟如何衡量？根据代码量？跟据修复的bug量？由于团队中个体处于不同位置，个体的具体任务也不一样，这样如何公平，或者说有一个让团队信服的个人贡献衡量策略？

关于个人贡献衡量策略，衡量策略一定程度上能提高共事者的积极度，但是从我们这学期的开发经历来说，一开始（在开发初始）就制定好这种衡量策略并没有起到预期的作用。可能是因为我们组特别和谐。。。连架都没有吵过，而且对于贡献度大家都有一竿很公平的秤。另外还有可能是我们模拟的不够彻底。同时我的观点是对于我们这种首次开发的团队，与其一开始就制定好贡献衡量策略，不如等一个阶段的编码结束后，看看大家都干了些什么事，通过成果来衡量贡献，更有效一些。这时大家都积累了一定的工作量，同时经历了磨合，培养了一些默契，对相互的工作都有了解。这样能更高效地衡量贡献。

4.关于软件工程师的职业道德这个问题，关于阿里月饼案件，阿里开除涉事程序员这一举措，是否合理？是否过重了，这次事件对涉事程序员的职业生涯有多大的影响？

​关于这一点：好的员工要知道什么事情是自己能做的，什么事是不能做的，最基础的一点是，在做事之前问问老板的意见。