反思

有人说过我们正在临近代码的终结点。很快，代码就会自动产生出来，不需要再人工编写。程序员完全没用了，因为商务人士可以从规约直接生成程序。
扯淡！我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。 ——马丁(Robert C. Martin). 代码整洁之道（异步图书） (Chinese Edition) (p. 39). 人民邮电出版社. Kindle 版本.

在撰写本文之前，我犯了所有新手会犯的的错——在需求确定之前，就立刻动手开发。前端的开发过程会给人带来极大的成就感，但随着时间的推移，这种成就感逐渐被混乱的开发体验所替代。
我总结了以下几个混乱特征：
1. 结束了日常生活后，再次回到开发工作中，要重新花时间梳理代码和开发进程。
2. 写出的代码结构存在问题(不是不能用，但不好用😢),又得返工重构。
3. 完成了阶段性的工作后，需要花不合理的时间去思考下面该选择做哪个模块。

先穿裤子再穿鞋，先当孙子再当爷。

当开发过程逐渐不再优雅，是时候还债了，下次可以做得更好。

确定需求

1. 用例图
   是不是觉得还挺简单？让人感觉中午起床后，晚上就能用上自己写的博客了。但实际上，恶魔藏在细节里。构建一个优雅现代的网站往往要耗费我们数周的时间。下面，进一步梳理流程图。
2. 流程图

   1. 用户浏览文章-流程图

   2. 管理员删除文章-流程图

   3. 管理员编辑文章-流程图
      

   4. 管理员添加文章-流程图不少朋友已经开始产生困意，甚至觉得这些流程图过于简单，不如一边开发一边梳理。个人认为，这些流程图读者不看也罢，只要了解即可。流程图对实际开发者才有最大的价值。当你着手开发程序时，一定要自己动手画一遍流程图，加深对业务逻辑的熟悉，随着开发的推进，就越发了解它的威力。

最后的准备？梳理接口和数据

如果按照教科书上的，这时梳理好面向业务的接口，并且按照数据库范式建表，确定好数据字典，此时就皆大欢喜，仿佛前路一片光明。但这必须在技术选型之后！在开发中，项目往往会使用一些优秀的开源库，而各个开源库有着自己的接口规定。

如果能预先参考各个开源库的接口，会避免不少麻烦(也许这是面向接口编程的原因之一？)。特别是在个人博客这种轻量级，有着浓厚敏捷开发色彩的项目中，预先设定好数据库的数据字典，往往不是一件好事。因为开发者随时可能会喜新厌旧，拥抱新的开源库。所以数据字典就留在后面在慢慢确定吧！

至少现在，我们可以最后总结梳理一下所需要的接口和业务流程，以方便技术选型。梳理至此，终于可以继续撸代码了！