程序员的道

作为一个程序员最基本的技能就是敲代码吧，在《UNIX编程艺术》书中看到14条原则，觉得相当不错，打出来一为自我提醒，温习，再为服务大家。

1.模块原则：使用简介的接口拼合简单的部件。

       编制复杂软件而不至于一败涂地的唯一办法就是降低其整体复杂程度——用清晰的接口把若干简单的模块组合成一个复杂的软件。

2.清晰原则：清晰胜于技巧。

       维护如此重要而成本如此高昂，在写程序时，想到你不是写给执行代码的计算机看的，而是给人（包括你自己）看的，这不仅仅是意味着代码注释，为了取得程序一丁点的性能提升就大幅度增加技术的复杂性和晦涩性是不可取得，因为复杂的代码容易滋生BUG，也会使得日后阅读和维护艰难异常。

        永远不要去吃力地解读一段晦涩的代码3次，第一次也许侥幸成功，但是如果发现必须重新解读一遍——离第一次太久了，具体细节无从想起——那么你该注释代码了，这样第三次几相对不会那么痛苦了。

                                                                                                                              —————Henry Spencer

3.组合原则：设计时考虑拼接组合。

       如果程序彼此之间不能有效地通信，那么软件就难免会陷入复杂度的泥沼。在输入输出方面，UNI传统极力提倡采用简单 文本化 面向流 设备无关得格式。这是因为如果程序不采用简单的文本输入输出流就极难衔接。

4.分离原则： 策略同机制分离，接口同引擎分离。

5.简介原则： 设计简洁，复杂度能低则低。

      避免错综复杂，不拿自己能编出多复杂 多抽象的代码为荣，真正美的代码是简洁的。

      “错综复杂的美妙事物”听来自相矛盾。Unix程序员相互比的是谁能够做到“简洁而漂亮”并以此为荣，这一点虽然只是隐含在这些规则之中，但还是值得公开提出来强调一下。

                                                                                                     ——————Doug Mcllroy

6.吝啬原则： 除非确无它法，不要编写庞大的程序

7.透明原则： 设计要可见，以便审查和调试。

8.健壮原则： 健壮源于透明和简洁。

       软件的健壮不仅是能在正常情况下运行良好，而且在超出设计者设想的意外条件下也能够运行良好。保证软件健壮性得一个相当重要得策略就是避免在代码中出现特例。bug通常隐藏在处理特例得代码以及处理不同特殊情况的交互操作部分的代码中。

9.表示原则： 把只是叠入数据以求逻辑质朴而健壮。

      数据要比编程逻辑更容易驾驭。所以接下来，如果要在复杂数据和复杂代码中选择一个，宁愿选择前者。更进一步： 在设计中，你应该主动将代码得复杂度转移到数据之中去。

10.通俗原则： 接口设计避免标新立异。

         最易用的程序就是用户需要学习新知识最少的程序——或者,换句话说，最易用的程序就是最切合用户已有知识的程序。

         最小立异原则的另一个方面是避免表象相似而实际却略有不同。这会极端危险，因为表象相似往往导致人们产生错误的假定。所以最好让不同的事物有明显区别，而不要看起来几乎一模一样

                                                                                             ——————Ken Arnold

11.补救原则： 出现异常时，马上退出并给出足量错误信息。

         软件在发生错误的时候也应该与在正常操作的情况下一样，有透明的逻辑。最理想的情况当然是软件能够适应和应付非正常操作；而如果补救措施明明没有成功，却悄无声息地买下崩溃的隐患，直到很久以后才显示出来，这就是最坏的一种情况。

12.经济原则： 宁花机器一秒，不花程序员一分。

13.生成原则： 避免手工hack，尽量编写程序去生成程序。

         由程序生成代码几乎（在各个层次）总是比手写代码廉价并且值得信赖。

14.优化原则： 雕琢前先得有原型，跑之前先学会走。

        90%的功能现在能实现，比100%的功能永远实现不了强。

        过早的优化是万恶之源。在还不知道瓶颈所在就匆忙进行优化，这可能是唯一一个比乱加功能更损害设计的错误。

         先求运行，再求正确，最后求快。

         我最有成效的一天就是扔掉了1000行代码。

                                                               ——————Ken Thompson

15.多样原则：绝不相信所谓“不二法门”的断言。

         即使是最出色的软件也有其缺陷和限制。设计一个僵化，封闭，不愿与外界沟通的软件，简直就是一种病态的傲慢。

16.扩展原则： 设计着眼未来，未来总比预想快。

        绝不要认为自己找到了最终答案。要为数据格式和代码留下扩展的空间，以便日后的改进

。

                                                                    keep it simple,stupid!