最近没啥产出，心态不太好，想写的很多，但博客更新的比较少。
今天谈谈系统设计的感悟吧（虽然也没设计过NB的系统）。
做出一个系统和做功能是不同的，考虑的因素也不相同。相对来说，功能开发比较简单，系统设计考虑的内容比较多。
商业论证
这个是在项目启动阶段考虑的问题，所有的项目开发的目标都为了实现一定的有价值的目标而存在的。再美好的过程，再高深的技术，再精英的团队，开发出来的东西没人用，没产生价值，全部成了沉没成本，最后只能成为谈资而已。
时间、成本、质量
无论是系统还是功能开发，亦或者是二次开发，都要满足一个基本原则，即在有限的时间，投入适当的成本，去完成既定的功能，即达到目标要求的质量。无论代码写的多么漂亮，用的技术多么高大上，最终都是在制约因素的限制下，实现既定的功能。质量是唯一不能妥协的因素。
权责统一
这个是在项目启动阶段要明确的事，一个团队，一个项目组一定要明确谁是负责的人，谁应该对这个全局负责，明确权利和责任，是保障成功的关键。人人头上有指标 人人肩上有责任。模糊的角色设定，往往在开发的过程中让人捉襟见肘。
可持续性
日常开发和开源软件的写法还是有很大区别的。开源软件只需要暴露接口，即实现什么功能，调用什么方法就可以了。使用者很少去关心里面的实现逻辑，打开软件的源码，你会发现有些地方也是一大坨一大坨的，如果业务代码也写成这样，基本上后面很难保证不出问题。
日常开发则不是，你自己写的项目，是需要随着项目的使用周期，功能迭代需要无数次的修改。所以，注释，清晰的逻辑是十分重要。如果你的代码只是自己比较清楚，逻辑高度压缩，那么估计只能自己维护了，因为别人看不懂。这也是为啥背锅的总是离职人员的原因了。
在一个生命周期比较长的开发中，你是否考虑过产品的扩容，DB的缩容。是否能在现在的基础上，逐步升级你的系统。还是等到山前的时候，才去考虑方案？
文档
文档是对业务的说明，产品文档，技术文档一定要写。开发人员大多数不愿意写文档，其实这是不对的。
代码源于产品逻辑，而清晰的代码又可以总结出业务流，数据流。文档书写需要遵循几个宗旨。
- 清晰，文档一定要清晰，主要目标是告诉他人这是什么，怎么用等内容，所以一定要清晰的表达出自己的意思。
- 安全，文档一定要安全，安全的意思是，文档的服务器一定不要是临时的，自己搭建的。是有人在维护的，这样可以避免人员流失引起文档断更的尴尬。
每个角色都应该不断的总结，整理归纳。
人生不只有true或false
世界是丰富多彩的，我在定义变量时很少定义成true/false, 这个习惯不太好。不过我有我自己的想法，总在一些场景的时候考虑，如果来了第三种情况怎么办。结果就定义成了0和1，如果来了扩展第三种情况，就加个2即可。
代码也是如此，要考虑到有第三种情况。是加case。
先写到这里吧。