朋友C的邮件内容：
现在我们这边开发的主要状况，就是教授已经把任务分解好、安排好让我们去逐个实现。但是后期越来越多的事情可能需要我们自己从头开始做，一直到拿出完善的产品。
现在主要的困惑集中在如下方面：
1.到处都在说需求分析是基础，但是究竟怎么样开展需求分析，应该得到什么样的格式化、规范化的成果？说得再透一点，做需求分析之前和之后，差异体现在哪里？
2.书上说需求分析之后，就应该是任务的设计，说是要把“别人想要的东西”里不可实现、不好实现都给裁掉，并且给出要实现东西的（功能）和主要的组合方式。对这一块，文字上有认知，实践中无体会。
3.版本控制应该怎么实现，实现了之后有什么作用？
4.看代码的时候痛恨别人不写注释和技术文档。敲代码的时候自己也不愿意写。这个问题你们是怎么解决的？
5.程序的调试、编译、设置断点、查错报错这些，有没有什么可以分享的技巧。现在这块比较弱，经常出现敲完代码错了，找半天不知道错在哪儿的情况？
6.有时候碰到现实中的困难需要转化为工程问题，一开始还会心存畏惧，甚至是无从下手，这种情况有没有现成的工程经验、文档、规范可以分享一下，让我们少走弯路。
7.如何给系统预设容错报错的机制？否则的话系统如果出现闪退了，错在哪里都不知道！
8.该怎么估算一个工程或者一个项目的工作量、复杂度？
9.怎么进行过程控制和质量控制？
热切企盼现实经验现身说法^_^
交流记录
1.到处都在说需求分析是基础，但是究竟怎么样开展需求分析，应该得到什么样的格式化、规范化的成果？说得再透一点，做需求分析之前和之后，差异体现在哪里？
2.书上说需求分析之后，就应该是任务的设计，说是要把“别人想要的东西”里不可实现、不好实现都给裁掉，并且给出要实现东西的（功能）和主要的组合方式。对这一块，文字上有认知，实践中无体会。
这两个问题都归结为需求分析问题。
（1）找到沟通的对象，可能是直接客户，也可能是你的导师，或项目负责人。不断的深入沟通，写写画画，不断的寻求确认。
（2）需求分析无处无时不在，你做的每一个功能都存在需求分析。
（3）明确问题的定义。从客户的角度把问题描述出来。编程/软件不是唯一解决问题的方法。
（4）（确定要编软件了）需求是客户的需求，站在客户的角度描述软件系统应该做什么：功能需求、非功能需求（质量需求：安全、性能、可靠）。
（5）不要跨层描述，即不要描述非需求内容，如设计或实现内容。联想TCP/IP协议分层，层间通信是严格的，是不能跨层的。
（6）尽量的占有背景资料，深入学习了解客户，这样才能站在客户的立场上。最容易的事情，是站在别人的角度思考，最难的事情也是站在别人角度思考。
（7）把用户分类，描述每类用户要做的事，和做事的流程，用户拥有的（输入）与用户想要得到的（输出）。
（8）按事情分类，描述每类事情的数据处理流程（工作流程），数据在不同节点经历的人和变化。
（9）画草图与你的客户沟通，面对面的沟通。
（10）随着项目的深入，开发人员及客户对项目的理解也会更深入，需求可能会变更。世界上唯一不变的是变化，所以，拥抱她吧。关于如何适应变化，这是另一个话题。
（11）差异体现：需求分析之前不知道需求，需求分析之后知道了需求，哈哈。
（12）以“ＣＧ项目”为例，看一下相关需求文档、工作流程描述文档。
3.版本控制应该怎么实现，实现了之后有什么作用？
（1）推荐使用SVN版本控制工具（演示SVN使用过程）
（2）版本控制的作用：备份代码、团队协作、历史比较、分支发展、版本控制...
4.看代码的时候痛恨别人不写注释和技术文档。敲代码的时候自己也不愿意写。这个问题你们是怎么解决的？
（1）反复阅读《如何编写可读性好的代码》、《编写可读代码的艺术》、《代码整洁之道》。
（2）我想静静，三思而后行，通过注释或草图表达编程思路。先用文字注释列出思路题纲，之后，在提纲中填充代码。
（3）代码不仅是给机器看的，更是给人看的，更是给团队中其他人看的，更是给几天、几周、几个月后的你看的。今后的你，不是现在的你。
（4）保持代码简单、整洁、一致。简单，不是形式简单，而是思维简单，易于理解。整洁，要看着顺眼、养眼。一致，无歧义，不断的出现时都是一样一样的，让阅读代码的人心理是平稳的，不要让我猜。
5.程序的调试、编译、设置断点、查错报错这些，有没有什么可以分享的技巧。现在这块比较弱，经常出现敲完代码错了，找半天不知道错在哪儿的情况？
（1）没有欲望，就没有杀戮。没有代码，就没有错误。有错误，是因为有了新代码。把新写的代码删除掉，写一行测试一下，难道会找不到错误吗？最笨的方法，也是最有效方法，也是最快的方法！
（2）在开始学习编程的2-3年里，我一直不会用调试工具，但我丝毫没有感道不适。好的代码编写习惯是最好的除错利器。
（3）当然还是要掌握断点调试这一利器，如果它不管用请参考（1），呵呵。
6.有时候碰到现实中的困难需要转化为工程问题，一开始还会心存畏惧，甚至是无从下手，这种情况有没有现成的工程经验、文档、规范可以分享一下，让我们少走弯路。
（1）每个问题都不同，没有经验范本，只有思维方式。
（2）畏惧是因为模糊、不确定性。怕鬼是因为鬼存在很大的不确定性：不知长什么样、不知什么时候出来。如果你知道，你肯定可以对付它。如何把现实问题明晰化？
（3）分解问题！纵分、横分。分层次、分模块。道生一，一生二，二生三，三生无穷。分解到一定程度，问题自现。体现在你是否真的深入思考这个问题了，是否用心了。毛主席说，世上无难事，只怕有心人。
（4）问题的本质是输入与输出，即接口（广义的）。输入与输出之间的过程，是代码编写。没有搞清楚输入与输出，就立即编写代码是不道德的。
测试驱动本质是基于这一思想的。很多现在流行的开发方法或工具，本质上是思想的规范化。你不借助测试驱动工具，也可以做到测试驱动。当然如果有工具更好，但如果不理解工具，就成了工具的奴隶。你觉得是你在编程，还是程在编你？你动脑子了吗？你跟机器的区别是什么？
（5）你的真正水平体现在“现实转化为工程”的能力，你的价钱也体现在这里。否则，你只是个搬砖的，你还不是码农，码农是砌墙的，砌墙是需要一定技巧的。高程/主程是搭钢金架的，架构师是画设计图的，设计是需要符合现实需求的。
（6）设计无处不在，也不要妄自菲薄。学会分解问题，学会定义接口。
7.如何给系统预设容错报错的机制？否则的话系统如果出现闪退了，错在哪里都不知道！
（1）在关键处捕获异常，try..catch..。或设置全局的异常捕获机制。
（2）借助日志工具（如log4net）记录异常信息，信息可以根据需要，详细到出借代码行。
8.该怎么估算一个工程或者一个项目的工作量、复杂度？
（请Ｙ老师回答）
9.怎么进行过程控制和质量控制？
（1）必要的文档不能少，如需求、设计、数据库等，要干货即可。敏捷不是不要文档，敏捷是思想，不是唯代码论，不能走极端。
（2）里程碑意识。
（3）结对编程。
（4）代码复审。
（5）单元测试。
（6）严格的用户场景测试。
（7）注意：代码的质量，决定产品质量。测试很重要，但不是测试决定产品的质量，不要把希望都寄托在测试上。一栋楼质量好，是因为用料、施工等好，不是检测部门检测了才好的。
summer
2015-05-29
附：
1.导弹偏离问题（这是一个欢乐的故事）；
2.Linus：I’m Your Lord；假设有一个上帝，他无所不能，那么，需求、设计、编码、测试本质上是上帝对同一问题的不同视角/层面的描述；
3.复杂问题是简单问题的投影；
4.瀑布未死，瀑布永生。瀑布已像空气一样存在；
5.Plan is nothing, Planning is everything。
网友评论