开发体验心得总结

阅读总结与联系实际

【No Silver Bullet: Essence and Accidents of Software Engineering】

本文介绍了软件开发的要点以及开发过程中将碰到的问题，目的在于说明在软件开发中没有“银弹”，也就是没有解决一切问题的绝对武器。

无论是在技术上还是管理上，要想在生产力、可靠性和复杂性上面有一个数量级的改善都是无法保证的。在这篇文章中从软件问题的本质以及对各种被提出的解决方案进行分析，从而来证明没有绝对的银弹。

软件的本质就是要将data set， relationships among data items, algorithms, and invocations of funchtions这四个关联紧密的概念构建成一个具体的软件实体。

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

而软件本身有着以下这些特点：

Complixity复杂性

在软件中，每一个部分都将是不同的。这不仅带来一个问题，在软件的开发和功能扩充是复杂性的增大远远超过了线性增幅；同时也意味这团队中的每个开发人员的工作都存在很大的独特性，不是别的队员能够很轻易理解的。所以这时需要为队员之间的模块设计接口，队员也要有经常的沟通交流，在管理层面上要总揽全局也会有很大的困难性。
Conformity整合

整合就意味着上面所说的各部分的差异性，以及在错误组合上面是通过乘法规律来变化，最终将会无法判断工程问题的具体所在。
Changeability易变的

软件产品需要面对应用、用户、法律等很多方面，即使是在维护过程中，稍微的改变就会引起一连串的变化，这些无情的变化是软件开发的重要性质，同时也是难度的重要来源。

Invisibility不可见

软件开发中的很多东西都无法通过图来进行表示，这导致我们在设计思考和交流的过程中存在很大的难处。

联系实际

 在这段时间的开发经历中，其中的个人项目和结对项目还比较好说，规模不是很大，所以出现的上述问题不是很多。但是在团队项目中我们确实有遇到很多问题。

我们团队项目做得是Xueba项目的网页客户端，称作XuebaOnline。我主要负责的是后端的开发中与前端联系比较紧密的那些功能模块，同时在前期也参与了设计工作。由于负责面还比较宽，所以对开发过程中的项目变化以及项目遇到的问题有比较深刻的认识。

复杂性变化的不可估计性

由于敏捷开发中很重要的一个就是使用成熟的第三方产品来构建定制我们自己的项目，所以前期我们打算就使用Django作为后端的“骨架",使用semantic-ui作为前端框架，使用solr来定制我们专属的搜索引擎。在这个的基础上，我们分配了各个模块的分工，1人负责配置搜索引擎方面，1人负责前端，2人负责后端Django部分。 但是后面出现了这些问题

 1. 使用的工具开始不断增长

• 搜索方面sorl不够用，我们又开始使用Nutch
• 由于Nutch的Hadoop底层需求，我们开始使用Hadoop分布式系统
• 服务器的配置方面产生了一些问题
• 问答数据获取方面使用py-stackExchange，运用提供的API
• 前端方面寻找很多其他的插件，比如多说评论、pdfjs、在线聊天界面……
• 在处理任务时采用celery异步处理工具
• ……

2. 每个工具的学习成本大，渐渐的分工上出现改变，变得不明确

• 在开发过程中PM由于没能直接参与到开发中，反而出现了对系统各功能不了解的情况，无法预估时间，从而造成在时间的安排上不能很好管理。
• 出现了一些难以解决的问题，大家的分工开始流动，有些混乱，所以任务的安排有点无法严格得完成。

整合问题

我们Xueba Project分成了三个组来去完成，所以与其他组进行交流沟通也变得很重要，我们需要前面两组提供数据以及数据的分类和定义。
同时我们的代码托管在GitHub上面，由于每个人要做的东西有所不同，但是又有互相关联的部分。然后开发过程中发现了一下一些问题：

1. 对于不同模块间的规范没有实现做好，导致较多的时间花在了修改整合上面
2. 大家的交流很多，同时大家的进度也都完成得很好，但是成果不能及时更进让大家都知道。
3. 由于其他组的进度和项目实现方案的采用问题，我们有一段时间的进度是被卡住了的，最后对任务安排产生了一定影响。

易变性上的问题

主要是由于数据提供方式的变化，以及合作伙伴的一些变化，导致在M1开发过程中有挺多变故的，给开发造成了很大的困扰。

由于无法可视化带来的一些问题

在开发过程中，前期的设计，的确像文章中说的那样无法通过平面图将结构上的一些细节问题表现出来，导致很多设计方面没有很好的后续指导意义。
同时在开发过程的交流环节，最后的文档解说上面，都存在着抽象度过高，无法很好得表意这方面的困扰。

【Big Ball of Mud】

所谓“泥球”，直接说就是指代码得堆砌和拼凑没有按照结构化，从而导致整个系统过于随意化、很杂乱，从而导致到了开发后期出现了很多错误和缺陷。

其实这里讲究的是健壮结构的重要性，其实就我们团队在这个方面的处理来讲，总得来说还是很好得控制了泥球的大小。原因有二：

1.  我们的架构选的很好，Django的MVT框架很好得起到了骨架的作用，它的机制导致代码复用更加方便，结构也能更加清晰。
2.  在各个模块之间的交互方面都有制定好专门的接口，没有出现直接的使用，同时大家在开发过程中有尽力去维护这一点，所以泥球仅仅是出现在每个模块内部。

但是就模块内部而言还是存在泥球的，泥球的出现和代码量成正相关，在开发过程中或多或少会产生一些。

那么我们可以采取哪些方法来使开发过程可以更加顺畅，先不管是否是不是“银弹”，我们总要通过实践来寻求优化和进步。

所以接着往下阅读后发现：

 【 Cathedral and the Bazaar】

所谓大教堂就是那种分工明确的团队管理任务分配模式，而集市则更偏向于大家根据兴趣积极主动得请求任务。前者更像是要求严格的企业制度化的项目，后者则更像是偏向与自由的开源性质类项目。不能直接说那种方式更好，这必须得看项目的类型以及团队成员的情况而定。如何项目本身能够易于划分功能，同时队员们都很积极且很有实力，那么这个时候采用集市式的管理方式能够极大得发挥队员们的开发积极性。但是这时往往会因为任务本身的趣味性、以及时间上的安排问题导致集市模式不能很好地运行下去，必须有一个主导者来制定明确的任务分工和要求，好然任务按照计划推进。

那我们团队这次的开发来说，虽然是有教堂模式那种任务分工，但是实际上却走的是集市模式。从而在任务运行过程中，没能很好的把握时间节点和任务间的依赖关系，导致开发过程中因为很多问题而影响了进度。

从这次开发过程上，再次感受到了设计和规划的重要性，需要有专门的从大局上考虑的任务分配，并且给出严格的监督。PM在一个团队中确实是一个很重要的角色，他需要将深入局部细节的开发人员整合起来，而我们团队在M1环节上很不幸得遇上了“PM危机”，经过观察，我们选定了更加认真负责的同学担任下一阶段的PM，相信在前期经验教训的指导下我们能够重开火力，大步向前。

 【瀑布模型】

  前面的易变性里面提到了软件开发过程中不断发生的各种变化会给开发成本带来很大的提升。但是为了得到让用户满意的产品，我们需要不断的根据反馈进行修改和调整。这时根据瀑布理论的概念，我们可以更加细致得来划分阶段，然后每个节点上进行一次反馈和调整，趁着积压量还不是特别大的时候进行修正，整体来说是最优的选择。

  从用户角度出发，及时反馈调整，加大各个模块负责人员之间的交流沟通，在保证工作责任化前提下开发。

 这将是我们后面阶段的行动纲领。