学习总结——谓软件工程为何物
关于软件工程的一点愚见
软件工程的根本出发点是要做好一个软件系统——尤其是在系统庞大、涉及人员众多、历时特别长、正确性要求特别高的情况下。那么我们简要思考一下需要考虑哪些方面。 在这之前，我们需要区分两种情况：第一种是需求是自己提出来的，第二种是需求是由客户提出来的。 自己提出需求是什么概念？比如说我是创业公司，公司的需求就是软件的需求。通常公司本身就有技术背景，因此可以省去很多协商磨合的时间。因此我们假定需求都是明确的，沟通上都没有问题，才能将两种情况归一而论。
那么做好一个软件系统，简要地说，可以是以下步骤：
系统的划分
根据需求，将系统从功能上划分为若干子系统。这时候细节可以忽略，主要看的是大体，比如一个社交网站可以简单分为用户系统、内容管理系统、内容推送系统。这样子我们可以从功能上分解庞大的系统，从而分解工作量。这个时候，每个系统可以递归分解子系统，直到一个系统的原子性充分展现为止——比如一个模块：登录模块、注册模块。当然这依照可分人员的数量，决定分离的粒度。划分的子系统功能即是工作目标。
联系的定义
在开始工作前，每个子系统工作组必须明确需要外界（其他工作组）提供什么样的帮助——比如内容管理工作组需要向用户系统工作组索要用户验证接口、获取用户信息的接口、获取用户授权的接口等等。当每个组根据自己的设计思路，整理出这一份需要帮助的清单，提交给别组。因此，自己本身也会收到其他组索要的帮助清单。这个清单可以辅助调整系统功能和设计方式，调整过之后把新增的帮忙清单部分再提交给别的组，这样迭代若干次，基本上每个工作组的设计方式和功能需求可以确定下来。这个子系统与其他子系统的联系也基本定型。
系统内角色分配
当系统划分完成之后，我们每一个子系统工作组可以分为四类人员：后端、前端、协调人员、测试人员。 后端负责数据相关的操作实现，前端负责界面的构建以及数据的展示，协调人员负责沟通需求、安排进度、汇总文档、代码复检等，测试人员负责测试样例构建、搭建测试框架等。
以上步骤再加上一些预先的规定，比如工具集的选定、文档格式规范等，理论上就可以work了。等项目进度到了某个程度，可以组织系统间的对接测试，此时需要更全局的工作组负责。
但是，还需要一些管理工作
可能这部分工作主要由协调人员，通常是PM完成。比如组织汇报会议，记录成员工作状况和贡献，在特殊情况下调整schedule等。
在我看来，这已经是相当完整的开发体系，其他的，似乎已经和软件工程无关，仅与个人素养有关；譬如，有一定经验的开发者在开发的时候会想到这个系统更好的特性，从而在未说明未来具体要增加什么的情况下，保留足够的扩展性。
然而，这就是最好的吗？
或者说这可能是最好的，但是不一定是最适当的。
前面提到了，这是大型软件系统需要的开发体系，对于小系统，那些连4个人都凑不齐的开发团队，显然这个标准不能一概而论。
笔者在完成数据库课程设计作业的时候，3天1人120KB代码前后端包揽，这时候你还要求我要有设计需求文档吗？两个人负责的项目还需要每天装模作样地开会吗？
我觉得，按实际情况去做就好。
那么这门课程我学到了什么？
毫无疑问，对于软件开发中的规范行为（Scrum会议、任务分配、贡献统计、燃尽图、各种记录）自然是比之前更了解。但是某种程度上这些规范行为对本门课程中小型项目开发并没有太多效率上的提升，也没有太多质量上的提升。除了API文档和依赖报告能够更好地帮助后人管理项目，其他内容基本对继承没有裨益。
原因是什么？
1. 时间少、项目小（主要原因）
2. 课程对代码质量、项目可扩展性没有针对性的教导，综合来讲就是项目设计不过关
因此我在这门课上学到的最有价值的东西，就是怎么把一个不可扩展的项目，改写整理成具有一定可扩展性的东西，并尽力让项目变得可继承。
至于管理部分，比如说缓冲区、比如说交付件、比如说自动化测试，时间就摆在那里，如果团队成员时间足够，经验足够丰富，这一切自然都会搞起来，否则无论是拖时间还是质量不达标，基本是无可奈何，只能顺延、放弃。
所以或许这门课重在养成规范观念，学习方法论，无论项目做成怎么样，只要以后真的以软件开发为工作时，稍微想起这些概念，不要肆意编码就好。
至于架构设计和编码技巧，不是这门课的重点。
不过，现在至少我能够做出一套相对体面的软工周期开发汇报，也算是学到了
教堂和集市
从集市开始建立教堂这是一种新的开放式软件工程建设方式，很多人把它说的很好，但是我觉得这种形式不能为公司带来盈利——核心都开放了，如何避免被复制？恐怕这种模式只能用于Linux这类造福人类的开源软件系统中。
反观瀑布模型
瀑布：测试主要集中于物理实验脚本，测试反馈通常均为程序结果正确，就算有误，直接反映给脚本改一改，也算是项目中唯一的瀑布模型的一部分。其次瀑布模型的思想其实是一个很普通的东西，正常的循环反馈是项目中遇到问题时会自然产生的。但是如果固定化这个行为反而没有必要，小团队中想反馈直接反馈，大团队中这个我们还没有相关经验。
敏捷开发
感觉也是很自然的东西，想要快点完成工作，必须多线并行，随时反馈，可能对软件可扩展性要求比较高。
回到课程开始的5问
http://www.cnblogs.com/toka/p/5877826.html
- 如何寻找开发效率和性能的均衡点？显然开发效率强调封装，重视代码重用。但是遗憾的是代码重用往往泛化了数据特征，降低了效率。 ——仍然未解决，但是大致上除了对效率要求特别高的情况，其他的都是开发效率优先。
- 如何“公平”分配工作？尤其是团队中人员参差时，如何能够使团队效率最大化？ ——水平相对较低的成员，可以做少些、做简单些，但是保持每人都充分有事干
- 测试需要进行到什么地步？众所周知，测试不可能完全覆盖，并且需要巨大的投入。 ——安全部分作形式化论证，UI部分只要常用操作不出现失误，数据部分将输入情况边界条件和特殊情况考虑完整，基本上就可以了。
- 如何控制适当的可扩展度？对于未来可能的需求，需要保留一定的可扩展性，但是在未来需求不清楚的时候，过大地保留扩展性反而可能使系统的效率降低？ ——逻辑上重复超过50%都可以合并提炼成可操作概念模型，任何主要内容都不能写死。
- 系统依赖太深真的好吗？ ——依赖的一大好处是大大减少造轮子的困难，但是给使用的用户带来了安装上的困难，因此最好的是软件自检依赖，自动安装。
各阶段知识点
需求：要真真切切找到痛点——一些或紧张或重要的问题。
设计：要有一定长远设计目光。保留适度可扩展性，一遍未来增加功能。
实现：保持良好的代码重用性和编码规范。
测试：即便不用测试工具，自己也要搭建测试框架，要做到一键回归测试。
维护：需要有人长期轮值，做到随时可以操作服务器。
发布：开发环境成功的功能，到发布环境还是要密切监测，反复测试无误后正式发布。
