项目初期是需求变更的最频繁时期，这个时候产品都没成熟，甚至没找准产品定位，而这个时候工程师就开始把技术限定在某一框框之内，显然是不正确的，这个时期最重要的就是保持业务逻辑的简单和模块的松散性，这样后面才会更容易整合。即使后面遇到了性能上的问题，因为你保持了简单和松散性，所以有很多替代方案可以选择，但是前提是你的设计是松散的，不能上来就把模块之间的关系给定死了。其实这类设计原则一直以来都有人在强调，我不是第一个说的也不是最后一个说的，但是总有一些人喜欢贪图设计上的投机取巧的便宜，无法坚持大原则，实则得不偿失。此等奇技淫巧，如非必要，一定千万万万不要使用在设计上。
人的思考能力是有限的，业务逻辑复杂了会增加出错的概率，因为人的思考能力和理解能力是有限的，即使设计框架的人的这方面能力出众，但是不代表其他人水平跟你一样高，除非这个项目全部代码由此人写，并且此项目从开始到消亡也全部由此人维护，并且其记忆力还算不错，交给其他人维护的话，这显然是不现实的 ，所以业务逻辑还是必须要回归简单。
《代码大全》中作者也有说道，“我得到了一个教训，如果没有测量性能变化，那么你想当然的优化结果不过是代码变得更为晦涩难懂了。”(Page.604)
个人总结起来就是，前期设计的时候一定要业务逻辑尽量简单，到后期遇到瓶颈的时候再回过头来审视，决定是否要牺牲简洁换取性能的提高。
---------------------------------- 分割线 -----------------------------------------------
最近斯诺登事件挺热闹的，看到有张趣图，分享如下：
扫一扫
2594
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
