今天读到一些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、可扩展原则:为将来做设计,因为它可能比你认为来的要快。
设计不在乎一开始就非常完备,并且考虑到所有情况和变化;设计的精髓在于当某种变化来临时,能够重新审视,甚至是调整全部的设计,让它能够兼容之后的“同种类”变化,从而使今后再有这样的变化时,带来最少量改动。为此目的,哪怕是推翻重来也在所不惜。
也即,我们不能将就第一次错误,这样才不会被同样的错误击倒第二次!
我想,这就可以指导我们在项目设计时并非要考虑得面面俱到,有些时候限于经验和能力也考虑不了那么周全,变化是无穷的。以自己的能力尽量有个好的开始,之后,关键是掌握一种应变的能力和决心。
就像自助旅游,第一次去陌生的地方,出门前做好N多功课,可能天气突变,车船晚点,所有计划都会改变,关键是遇变不惊,冷静处理。
瞎扯的,只是觉得之前做项目,总是到处比较各种方案,设计来设计去,耽误了大量时间,最后又会发现还是没想周全,这句话让我豁然开朗,我想是有道理的,共享给大家。