孤尽班第七天笔记 -- 一周总结

人都说，一个程序员在开发一个项目中真正花在写代码的时间只占他花的总时间的百分之二十到三十。那大部分时间都花在哪里了？在项目的架构设计、数据模型设计、以及其他方面如异常处理和日志规范等的设计。而在这个总共31天的训练营里，我们要在7天内完成这些工作，我想说好南啊。

但是难，不影响收获。过去7天的学习，算是我见识了“🐖是怎么跑的”。在这里先简单回顾一下。

框架

一个项目的开发起始于用户需求的收集和分析。这部分很像记者采访，这阶段采访做得越扎实，后期对于需求的分析就越做的到位。要不然，回头还得回去找用户解释需求。

需求都捋顺了，下一步将它结构化。我们可以从里面提炼出用户用例（use case），罗列出实现这些用例需要开发的功能，然后按照职能或者其他标准将功能划分成多个模块。有了用户用例，我们可以再深入地研究在用例中用户是如何与系统交互的，然后形成用户活动图。我们还要分析用例中系统在处理用户请求时状态的变化，然后设计出用户状态图。用例中用户与系统交互活动的时间顺序也需要搞清，然后形成时序图。最后，我们做的是OOD，自然少不了要搞清每个功能中所使用的关键的物件，这些物件及其属性又可以形成关键类图

数据模型

与框架类似，设计数据模型也要从收集用户的需求开始，然后将需求尽可能详尽地罗列出来。然后从里面挑关键字，主要是名词和动词。名词将是数据模型中的实体和属性，而动词将表示实体间的关系，或者用户的动作。

在把名词和动词转化成关系型数据库中的表和关系，并用E-R图来表示出来。然后最重要的一步是对E-R图进行验证。我们可以用用户路径来对图进行验证，确保用户与数据库每一次的交互，都能够CRUD正确和完整的数据。比如，用户注册账户这样一个简单的用户动作，我们设计的用户表就必须包含姓名、生日、证件号等属性，如果少了就得补上。

等把项目需要支持的用户路径全验证完毕以后，我们就可以绘制数据的物理模型，这里可以用PowerDesigner来绘制，然后直接输出Sql的建表语句，非常方便。

异常和日志

框架的设计主要聚焦于用户的需求，目标是把核心需求支撑起来，也就是我们常说的happy path要能走得通。想清楚happy path不算难，只要有常识和逻辑，就能把一个用户路径分解出来，画个八九不离十。但是，在过去几天里，我发现真正难的实际上是搞清楚happy path上的枝枝杈杈，也就是各种edge cases。不仅要把它们枚举出来，还要想明白如何处理和记录，即异常处理和日志设计。这非常考验一个人的逆向思维能力，也是见一个程序员真功夫的地方。整个周末我都在思考该如何设计异常处理和日志，但始终没有头绪。这回知道自己的功力有多浅了。这方面今后还需多用心刻意地训练。