［转］感触最深的几条设计哲学

iptton

感触最深的几条设计哲学        
        今天读到一些UNIX下的编程哲学，对自己相当的有冲击力，把我觉得有用并且有道理的，自己组织了一下：

“编程的核心是数据结构，而不是算法”，即使最简单的程序逻辑人类来验证也很困难，但就算复杂的数据，对人类来说也相对容易推导和建模。五十个节点的指针树要比五十行程序的流程图更清楚。

“编程的本质是控制复杂度”，而流程图、过程化、结构化、面向对象以及其它方法论恰好“成功”将复杂度提升到人脑不能处理的地步。所以，降低整体复杂度的方法是用清晰的接口把若干简单模块组合成一个复杂软件。

“简洁最美”，最错综复杂的美妙设计，常常使我们的设计能力超出排错能力，结果是代价高昂的废品。

“接口和引擎分离”，把复杂的GUI界面与后台处理分做两端，中间用简单协议架桥。

“可见才可掌控”，软件系统的透明性就是说，你能一眼看出它在干什么，要能监视到内部状态。

“撑不下去，马上退出”，出现异常，补救措施明明又没成功，还挺在那里，很久才发现是最坏的一种情况。要么“响亮的倒塌，要么为工作链下一环程序输出一个严谨干净的正确数据”。

“过早的优化是万恶之源”，先要求运行，再求正确，最后再求快。还不知道瓶颈就匆忙优化，是唯一一个比乱加功能更损害设计的错误。“最强大的优化工具是DELETE键”。

“善用工具”，教会电脑生成一些简单的代码；一旦有人解决了某个问题，就直接拿过来用，尽可能一切都自动化。

“宁花机器一分，不花程序员一秒”。

综上所述，4个字母：KISS－－Keep It Simple, Stupid!


最后，还是把UNIX哲学的17个原则完整列一下：
1、 模块性原则：写简单的，通过干净的接口可被连接的部件。
2、 清楚原则：清楚要比小聪明好。
3、 合并原则：设计能被其它程序连接的程序。
4、 分离原则：从机制分离从策略，从实现分离出接口。
5、 简单原则：设计要简单；只有当你需要的时候，增加复杂性。
6、 节俭原则：只有当被证实是清晰，其它什么也不做的时候，才写大的程序。
7、 透明原则：为使检查和调试明显更容易而设计。
8、 健壮性原则：健壮性是透明和简单的追随者。
9、 表现原则：把知识整理成资料，于是程序逻辑能变得易理解和精力充沛的。
10、最小意外原则：在接口设计中，总是做最小意外事情。
11、沉默原则：当一个程序令人吃惊什么也不说的时候，他应该就是什么也不说。
12、修补补救：当你必须失败的时候，尽可能快的吵闹地失败。
13、经济原则：程序员的时间是宝贵的；优先机器时间节约它。
14、产生原则：避免手工堆砌；当你可能的时候，编写可以写程序的程序。
15、优化原则：在雕琢之前先有原型；在你优化它之前，先让他可以运行。
16、差异原则：怀疑所有声称的“唯一真理“。
17、可扩展原则：为将来做设计，因为它可能比你认为来的要快。

对 15、优化原则：在雕琢之前先有原型；在你优化它之前，先让他可以运行。特别感触...

[ 本帖最后由 iptton 于 2007-12-5 22:28 编辑 ]

iptton

部分原则之间看起来互相矛盾...取舍的度就看经验了...

powerwind

我只知道一点，TMD需求变动真TMD快。

满足顾客需求，老板却不顾我的需求。

iptton

16、差异原则：怀疑所有声称的“唯一真理“。

jinry

需求变动真的是一个大问题,特别是在设计阶段,往往一个修改会让人吐血....

hjack

同感.
都到Detail Design了.还要改HLD文档....

jinry

关键问题不是这种改动,而如果改动大的话会很吐血,前面做的设计会让自己很无奈,可能不只一个地方要改...然后包括HLD,ITC,UTP,UTC,LLD文档所有都要刷新才有归档意义,但是问题在于项目计划就摆在那里,周例会我抗议已经很紧了还要抽走一个人,PL上面的老大说没有办法,这些计划已经跟再上面老大承诺过的...改不了,于是,OT,不停的OT出现了....