我的阅读做业

软件工程最后一次做业

总结

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

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

一开始罗杰老师的课有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.关于软件工程师的职业道德这个问题，关于阿里月饼案件，阿里开除涉事程序员这一举措，是否合理？是否太重了，此次事件对涉事程序员的职业生涯有多大的影响？

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