你编程时的首要原则是什么?

Keep It Simple Stupid
服务器君一共花费了269.553 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

刘未鹏的 blog 上写了一篇 编程的首要原则(s)是什么? ,很有意思。

你们认为编程的首要原则是什么?

作为我的学习原则的一个实践:

学习一项知识,必须问自己三个重要问题:

  1. 它的本质是什么。
  2. 它的第一原则是什么。
  3. 它的知识结构是怎样的。

很长时间过去了,这个问题到现在还有人回复,我得到了一大堆有意思的答案,忍不住翻译过来与大家分享:

1.  获得最多认同的答案

KISS – Keep It Simple Stupid

DRY – Don’t Repeat Yourself

一点不感到意外吧?

注:DRY原则倒是比较好理解和实践的。但KISS原则则是看上去直白,其实实践起来不那么容易的一个原则,因为simple和stupid的定义并不是每个人、在每个场景下都是一致且明显的,一个人的simple可能是另一个人的stupid,一个人的stupid可能是另一个人的unnecessary。一旦一个标准取决于具体场景,事情就不那么简单了。所以我们经常要说“It depends”。

如果换一句和 KISS 原则相当分量的话,我会说:不要用愚蠢的方法做事。很矛盾?Repeat Yourself 往往代表了一些愚蠢的方案,且并不 simple ,至少会付出更多的体力。我想,KISS 的最后一个 S 指的是大智若愚的愚,而自做聪明则是另一种愚蠢。

KISS 的大原则下,我想其实可以分出一些细节的东西,也是别人都提过的:

最近两年我对同事说的最多的几句话,“弄清你的问题是什么”,“你不一定需要解决这个问题” 。

因为什么都不做才是最简单的。要知道什么可以不做,必须了解你的问题。

面向对象以及复杂软件技术的滥用,或是找不到更 Simple 的方案解决问题(以性能、以需求等为借口去实现更复杂的方案)往往都是对需求了解不清,或者眼光太短。把手段当成了目的。(以为达到目的,必须采用某种手段,而如何应用这种手段就变成了目的)

同时,我觉得过度抽象也来源于对问题的认识不清。我还没想好后面要写什么,实现些什么,所以先利用“抽象” 把其它的部分搭起来。久而久之,不分析具体问题,先做抽象就变成了惯性。而抽象层本身往往是软件中最复杂的部分,离 KISS 原则最远的一块。

2.  获得第二认同的答案

写代码时时刻设想你就是将来要来维护这坨代码的人。

不要只低头的使你的代码完善,而要抬头看看他现在的样子。

在这个答案后面有人添加到:

最好设想你的代码会被一个挥着斧头的精神病来维护。

有人接着又YY道:

而且这个挥着斧头的精神病还知道你住在哪儿。 (( 事实上后面有人指出这是 Martin Golding 的一句名言 ))

注:其实这个原则在设计API时也有用:

写API时时刻设想你就是要去使用这坨API的人。

3.  一些众所不一定周知的答案

先弄清你的问题是什么!

弄清问题永远是问题解决过程中的第一步和最重要的一步。

这个问题是需要编程解决的吗,或者说编程能够解决的吗? 思考到这一点才能真正了解编程(或者说工具)在问题解决过程中的所起的地位,他应该如何和人,和人们做事的过程相匹配,能够调动人,调整人们做事的方法,过程,起到更好的作用。

代码只是工具,不是手段。

不知道怎么最好地解决你手头的问题(注:需求、架构、算法,技术选型,etc..),写上一万坨代码也是浪费比特。

软件研发的复杂度远远超过了人类的能力控制范围,“去想好后面要写什么”其实往往都是行不通的。使用抽象是延长软件生命周期的一种很有效的方法。

其实问题是出在,为了应对需求的变化,往往需要在抽象层做相应的调整。好的抽象和差的抽象之间的差别,就是好的抽象不仅简单、易懂、清晰,而且具有非常好的扩展性和应变性。

就好像,请一个架构师过来的目的不是希望他能做一套最完美的系统(因为是不存在的),而其希望他能在每次需求变更时都使用最少的成本去满足需求。

知道什么时候不该编码

(类似条目:YAGNI——“你并不需要编写这坨代码!”,针对你的需求编码,“写你所需”,别做“聪明事”,为一个不确定的未来编码。同时也注意模块化设计,以便能在未来新增需求时无痛扩充系统)

永远不要假定你已经了解一切了!

不作没有证据的推论。

想清楚了再编写。类似条目:如果方案在你脑子里面或者纸上不能工作,写成代码还是不能工作。

4.  一些众所很可能周知的答案:

  • 越懒越好。
  • 过早优化是一切罪恶的根源。
  • 不要重新发明轮子。
  • 测试通过前说什么“它可以工作”都是纯扯淡。
  • 了解你的工具。
  • 一切以用户需求为导向。
  • 利用分治、抽象,解开子问题之间的耦合。

5.  最幽默的答案

咖啡进,代码出。(Coffee in, Code out) (( 参见 Garbage in, Garbage out. ))

本文地址:http://www.nowamagic.net/librarys/veda/detail/2283,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2283

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《Python学习手册(第4版)》 鲁特兹(Mark Lutz) (作者), 李军 (译者), 刘红伟 (译者), 等 (译者)

《Python学习手册(第4版)》学习Python的主要内建对象类型:数字、列表和字典。使用Python语句创建和处理对象,并且学习Python的通用语法模型。使用函数构造和重用代码,函数是Python的基本过程工具。学习Python模块:封装语句、函数以及其他工具,以便构建较大的组件。学习Python的面向对象编程工具,用于组织程序代码。学习异常处理模型,以及用于编写较大程序的开发工具。了解高级Python工具,如装饰器、描述器、元类和Unicode处理等。

更多计算机宝库...