阅读后感

软件工程期中做业（阅读和提问）

原本打算每篇文献写一份读后感来着，读了”There is a Silver Bullet”，借鉴其中把模块的复用做为银弹的作法，决定把经历总结和读后感穿插成一篇去写。

part1 主要关于经验总结

在写这一篇以前，我已经经历了一次alpha阶段的开发（对联项目），beta阶段换了一个组（Julia-AI），此时，beta阶段也已经经历了一半。
在alpha阶段的开发中，主要作的是前端的一个demo界面，这里一方面是对前端的工做不熟悉，另外一方面是在开发开始的时候就定下来此次的开发是以一个demo界面为主，不太须要考虑以后的发展（也就是笃定了以后要重构的）这样的念头，因此基本也没有作到对原型进行很好的设计

• Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design.
  
• Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct.
• Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency.
• Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.
• cited from"Worse is Better"

关于worse is better里面这样的设计理念，我是以为很好的。一方面来讲，尽可能好的设计能够知足大部分常见状况下的需求，也就是说几乎能够知足市场，另外一方面，这种作法能够合理的划分主次，把主要精力放在攻克主要的领域上，同时又足够的简单，能够说是在“多快省”这三个方面权衡下的最好设计方式了。可是这种方法会对编程人员的项目经验和架构能力与洞察力有比较高的要求。在此次10天的alpha冲刺，这个原型的设计确实是被我忽视了的，只作到了足够的简单，完成了一个算是完成各项功能模块的demo，可是正确性和持续性几乎是彻底忽视了的。这也形成了最后的先后端逻辑是一个大泥球。

Therefore, focus first on features and functionality, then focus on architecture and performance
("Big Ball of Mud")

这篇文献至关因而给出了一个系统变成一个大泥球（一个杂乱无章的系统）和如何进行解决的方法。

反思，在冲刺的过程当中作了什么事情让这个系统变成了泥球了呢？首先像上面引用的那样，只关注系统的功能，而对架构缺少设计，这个能够说是最根本的缘由了。其次的一些缘由，

Therefore, produce, by any means available, simple, expedient, disposable code that adequately addresses just the problem at-hand. “Big Ball of Mud”

开发的时候确实抱着最后再进行整理的心态，可是到了后期整合各个部分的时候，发现因为缺少前期的总体设计，最后将各个模块整理到一块（好比接口调整等）就花费掉了最后的冲刺时间。这就是在时间规划上出现的问题。作增量式改进的时候，也就是每次对需求做出改进的时候，过于急于看到效果，作的是最不经大脑的修改，没有考虑到各个模块之间的解耦和对可扩展性的支持。到了后期增长新的功能每每须要改动的函数就会变得不少。不过beta阶段总体架构和代码都在进行重构，也是符合“Big Ball of Mud”中的从新让项目有条理的作法的。

在冲刺的过程当中，为了提高开发的效率，不少模块功能的实现并非依靠本身去认真的翻库，而是经过寻找功能相似的代码去进行复用，也就是寄但愿于银弹来提高开发的效率。确实，这样效率是提升了很多，可是，像这篇“有人负责，才有质量：写给在集市中迷失的一代”中阐述的那个样子，如今的开源部分的代码更多的像是一个大集市，不少代码的质量是没有办法保证的，特别是网上那些发布了代码可是做者仿佛忘记了本身的帐号密码的博客中对应的代码，常常能够见到有人在下面评论在运行过程当中遇到了什么问题可是并无可以解决，可是每每过了一两年这样一条仍是了无音信（固然，也和提问的人询问的方式有关）。而后这些代码彼此依赖，从一方面来讲，给项目的代码中增长了许许多多没有必要的冗余代码，从另外一方面，这些代码（尤为是做者失踪的）更多的是只是应付在某一种特定状况下的功能，并不会有任何的设计构造或者是异常处理可言，盲目的复用代码以后使得本身的代码更加像一个泥球。综上而言，在实现demo原型的阶段，复用是一个很好的提升效率的方式，可是作一个成熟的项目的时候，代码复用要考虑的事情应当会有不少。包括对于使用的库函数也应当有合理的挑选，好比以前的圣诞节图标狗啃事件。若是所有考虑（好比使用限制，应用大小，可扩展性等等），感受代码复用并不可以很是显著的提升效率？
在利用已经成熟的模块时候，我遇到的两个问题：

1. 虽然仅仅须要其中的一小部分功能，可是为了使用这个模块有的时候不得不将模块总体包含在项目文件内，致使项目总体体积偏大，运行效率可能比较慢，然而查不清楚具体缘由
2. 借助Web App实现部署的时候，须要将项目代码打包成规定的格式，因此致使部署的代码和github上的代码结构不一样，同时因为运行环境不一样等进行路径问题等的修改也花费了大量时间，对于Web App模块自己的运行逻辑不了解也增长了调试的困难，虽然部署方便了不少。

此外，

And for us who are concerned with the success of object-oriented programming, this is chilling—the future will be in the hands of the worst of our fruits. "Is worse really better"

简单的，考虑的状况比较少可是又相对足够全面的代码相对于设计实现复杂，为了一个不多用到的功能而大费周章去设计的代码来讲应当是更容易被阅读和理解的，也就是更容易被入门的人去接受阅读的，也就是受众是更广的。（这里没有什么依据，只是看到以前资料收集的时候，看到你们对一个功能的实现，互相转载的博客中更多的是实现方法比较简单的作法而作出了的一个假设。）那么相对而言，加上软件工程的教育和练习在初学者中普及不充分这样一个状况，更多的项目容易陷入一个泥团的局面。

part2 如何学习软件工程

一点牢骚

这个方面，我想更多的聚焦于学校里的软件工程课。由于各类缘由，我是本身上过一节软件工程课，同时经过听同窗吐槽的方式旁观了第二学期的软件工程课。这门课里我听到最多的吐槽是哪几个呢？回想起来，是

1. 这个做业ddl的时候立刻就要考试了，哪有时间来应付这个
2. 忽然要求干XXX，这个东西根本没有接触过啊
3. 团队里XXX是个大腿，只要他干活就好了
4. 课程上得很是无聊，老师也不介绍编程技巧。。。
   为何计算机系的老师教很差软件工程水平的编程这样一篇文章里，做者吐槽了软件工程这门课没啥锻炼的东西，老师教学仿佛是一种应付差事。这篇文章里，有这么一句话

就咱们系来讲，在学习软件工程这么课以前，好像一直都处于理论学习的阶段，平时的做业都只是一些简单的练习。甚至有些课程，如今都还不知道本身该在什么地方去应用它们，感受真是白学了。

在某些程度上，这句话彷佛能够解释一下你们会以为软件工程这门课无聊的缘由。由于课程上不少东西是从理论的角度出发的或者是方法论同样的东西，而这两个东西，理论的东西须要大量实践的验证，方法论的共鸣也是须要不少实践，经验同样的东西才能够有同感。在缺少共鸣的时候就像是给原始人讲流水线生产是多么高效同样。在这篇博客中，团队成员对于如何学好programming摘出了几个意见：

1. 请企业中的开发者参与programming的教学
2. 学生本身应该有自我发现的能力，you develop software on your own，teacher give you time to develop your skills semi—autonomously
3. programming更须要在实际的工做经验中学习

这三个方面的建议都是颇有道理的，可是若是按照重要性排序的话可能我会选择2，3，1这样的顺序。经验丰富的开发者开设的programming课程，若是针对的仍是第一篇博客中提到了“感受本身白学了“这样的同窗，可能纯理论的东西又会被抱怨无聊，作偏工程的项目又会被抱怨课程难度大。这是一个两难的局面。从自身出发来讲，软件工程的困境一方面是来自于可能部分老师脱离工业环境，致使某些方面让人感受说服力不强，另外一方面（更大的方面）是来自于学生自己的矛盾性。这个矛盾性主要是体如今全部的课程要求的结题项目更多的是demo性质的而非一个真正的有要求的软件工程，而被忽然施加了不少要求的软件工程无疑是走出温馨区；另外一方面就是传统的浮躁，想要短时间内提升软件能力而又缺少足够的自觉动手能力。

软件工程教学最好的方式应该仍是作中学，兼顾基础好和很差的两种状况（关于ddl重叠这种状况，按照道理来讲并不该当成为一个顾虑，可是这个顾虑每每是真实存在的，尤为是在看重绩点的地方），如下的思考是创建在不存在ddl重叠而且你们真实想学不依赖大腿的状况下。

软件工程和计算机科学的gap在哪里？

CS != SE，这应该是一个公认的道理，相对而言，计算机科学更偏向于理论，而软件工程更偏向于更称，软件工程的东西相对而言更和人相关，没有一些很严谨的研究方式。在阅读这篇博客的过程当中，做者对计算机科学和软件工程的区别有着更明确的定义，计算机科学严谨，而且各类理论相对比较固定，算法有着严格的分析，而软件工程中的各类不肯定性大大增长，并且缺少明确的定义。理论更新换代速度很快，须要人不断的根据实践去调整理论分析的方法，软件工程是一种将计算机科学的相关成果转换成为人类可使用的软件的一种粘合剂，也就是说，软件工程是直接和人所打交道的。是一种和人类相关的，包括创意人文等多学科的综合系统，而非传统的软件工程。这篇文章解释了一个长久以来的疑惑，为何大学里不少学习的材料都是一些比较老旧的东西，好比知乎常常吐槽的一个问题，为何大学的C语言教学还在使用VC6.0这样一个过期的编译器。由于大学更多的偏向于一些理论知识的教学，大学内的教学包括实验部分，更多的是注重于促进对计算机科学的理解，好比可计算性，编译原理，计算算法的复杂度等等，因此，从工业的角度来看，大学里面的不少东西是很是过期落后的，并且学生受到的训练是能够忽略不计的，也就是“动手能力极差“。这些东西都是不涉及人的，甚至可能不涉及团队合做的有关内容（不过不少时候大学的团队合做更多的也都是一人带飞一对人），也就是和人打交道的部分形同虚设。哪怕是大做业，也就是开发一个软件项目，更多的也都是小打小闹性质，没有达到必定的规模，不须要软件工程相关的理论指导，不须要考虑软件的架构等等。那么，如何去准备软件工程的有关内容呢？计算机科学的内容，教学安排都是显然地显示在教学大纲上的，好比密码学图论等等。若是想成为一个软件开发者应该去培养学习啥技能嘞？

软件工程应该教什么？

"What Should We Teach New Software Developers? Why?"阐述了软件工程和正常教学之间存在的问题，分析了学术和工业之间存在的gap，指出学术界更关心一些计算机科学的核心理论知识点，工业界则更但愿一些有经验的开发者，理论和实践之间如何取得一种平衡是教学过程当中须要关注的重点。关于教学的方案，针对教授的四年本科时间仅仅只够教完计算机科学的理论知识点，目标是软件工程师的人应该须要一个master学位而有志于计算机科学研究的人则应该去学习一个PHD。可是计算机科学的最终目标是进行获得一个更好的系统，因此编程的技能是不管从事学术研究仍是工业开发都不可或缺的。关于如何培养一个软件工程师，我以为这篇参考文章的阐述更加的详细一些，也更有一些共鸣。也就是，用工做室的方式来进行学习，换成如今常见的作法，也就是实习这样一种方式来参与实践。在这篇文章里，做者指出软件工程是一种能够经过实践加反思来自我感悟自我提升的学科。经过工做室的方式参与实践，学习软件开发过程当中架构设计，与团队成员沟通等多方面的技能，在经验丰富的工程师引导下对本身的软件开发流程进行反思，经过接触新的项目，考虑不少实际的问题，同时锤炼与人合做的技能等，在这样一个边学边反思的过程当中，可让人一步步的脱离温馨区，经过一种百炼自得地方式获取软件工程所须要地各项技能。软件工程应当是与建筑等学科无异的同样的实践方式。从我的地角度来讲，在学校中所作地项目一方面更像是展现本身所学地demo，也就是所谓地三无产品，无用户，无反馈，无维护。作完就丢掉，也不须要管运行速度之类地东西。然而在实习地过程当中，经过scrum等方式去听成熟地软件工程师对一个实际项目地看法，考虑的方方面面的要素，在本身工做的过程当中去询问学习的方式，会更快的去领会该如何去真正的开发一个软件。作中学的方式，而不是开发一个玩具去自娱自乐的方式，更容易让人在这样一个偏工程的学科中得到成长。