[转]编程的首要原则(s)是什么？
2009-08-25 13:16
851 查看
半年前，JoelOnSoftware和CodingHorror合搞的stackoverflow.com刚上线不久，我兴冲冲地跑过去扔了一个问题：
你们认为编程的首要原则是什么？
作为我的学习原则的一个实践：
8. 学习一项知识，必须问自己三个重要问题：1. 它的本质是什么。2. 它的第一原则是什么。3. 它的知识结构是怎样的。
5个月过去了，这个问题到现在还有人回复，我得到了一大堆有意思的答案，忍不住翻译过来与大家分享：
1. 获得最多认同的答案：
KISS - Keep It Simple Stupid
DRY - Don't Repeat Yourself
一点不感到意外吧？
注：DRY原则倒是比较好理解和实践的。但KISS原则则是看上去直白，其实实践起来不那么容易的一个原则，因为simple和stupid的定义并不是每个人、在每个场景下都是一致且明显的，一个人的simple可能是另一个人的stupid，一个人的stupid可能是另一个人的unnecessary。一旦一个标准取决于具体场景，事情就不那么简单了。所以我们经常要说“It depends”。
2. 获得第二认同的答案：
写代码时时刻设想你就是将来要来维护这坨代码的人。
在这个答案后面有人添加到：
最好设想你的代码会被一个挥着斧头的精神病来维护。
有人接着又YY道：
而且这个挥着斧头的精神病还知道你住在哪儿。 (( 事实上后面有人指出这是 Martin Golding 的一句名言 ))
注：其实这个原则在设计API时也有用：
写API时时刻设想你就是要去使用这坨API的人。
3. 一些众所不一定周知的答案：
先弄清你的问题是什么！
弄清问题永远是问题解决过程中的第一步和最重要的一步。
代码只是工具，不是手段。
不知道怎么最好地解决你手头的问题（注：需求、架构、算法，技术选型，etc..），写上一万坨代码也是浪费比特。
知道什么时候不该编码。
（类似条目：YAGNI——“你并不需要编写这坨代码！”，针对你的需求编码，“写你所需”，别做“聪明事”，为一个不确定的未来编码。同时也注意模块化设计，以便能在未来新增需求时无痛扩充系统）
永远不要假定你已经了解一切了！
不作没有证据的推论。
想清楚了再编写。类似条目：如果方案在你脑子里面或者纸上不能工作，写成代码还是不能工作。
4. 一些众所很可能周知的答案：
越懒越好。
过早优化是一切罪恶的根源。
不要重新发明轮子。
测试通过前说什么“它可以工作”都是纯扯淡。
了解你的工具。
一切以用户需求为导向。
利用分治、抽象，解开子问题之间的耦合。
5. 最幽默的答案：
咖啡进，代码出。（Coffee in, Code out） (( 参见 Garbage in, Garbage out. ))
最后，整个问题的 thread 在这里。
发表于 @ 2009年03月09日 19:09:00 | 评论( 6 ) | 编辑| 举报| 收藏
旧一篇:[BetterExplained]为什么你应该（从现在开始就）写博客 | 新一篇:逃出你的肖申克（二）：仁者见仁智者见智？从视觉错觉到偏见muzisoft2008 发表于2009年3月10日 7:23:02 IP:举报
如果站在最高的角度看编程，就会看到编程者，冯氏机系统模型，图灵语言模型，应用，如何将四者结合产生冯氏机上基于图灵开发模型的dsl的，自然语言编程。
只有这样想面对四大问题并解决它，才能使一切讨论开始变得有现实意义
首先我们来看待问题本身，编译原理告诉我们，
图灵机语言模型提供形式语法但不提供非形式形象的写法，
冯氏提供类型，它主导代码，为什么说冯氏是数据主导代码的呢，因冯氏机就是一台本质上的io机，开发者眼睛里只有类型（就是数据模板），在过程式语言内就是plain old dates,在OO语言内就是abstract datas,函数也是一种型，不过他只能传指针的方法跟其它数据类型交互，class就更是一种高级型，一方面是adt,一方面是udt(比如可以重载给以操作符),而模板呢，在udt的基础上generic了，但模板绝不是一种型，而是一种表现形式，代码结构，或写法结构都可由它来表现，与类搭配的模板就是表现类代码，函数模板就是表现函数
编程者需要写法而不是语法，
dsl需要写法上的idoms,领域相关的logics
我们可以整理一下上述所有概念的对应关系，
编程者（需要泛语法跟泛型） 写法 --- adt,udt
冯氏机 (需要类型pod或class)
图灵开发模型(需要形式语法)形式语法对应编程者的泛语法，即写法
应用(需要dslogics) (就对应冯氏的型和编程者方面的udt,adt)
而现在的语言，都只是解决了上面中的四个当中的一个。 那么我们如何把他们结合起来呢？对，是抽象！
抽象是解决问题的最好哲学，对于这四个问题，我们可以抽象它们，因为编程就是遵照语法写代码，根据我们在前面谈到的对四大问题的理解，我们可以首先把它抽象为：在写法下的类型，于是我们可以设置两大抽象，即抽象写法，和抽象的代码就是数据(冯氏是用数据主导代码的)
具体如何抽象呢？一种抽象的方法是参数化，参数化类型就参数化了冯氏机，参数化语法就参数化了图灵开发模型，这样就做到了泛语法加泛型，写法和类型，这两者都可用模板来呈现, 力求idoms跟logics的书写产生一致的编程泛式
什么是idoms,什么是logics呢？
idoms是语法规则，泛语法就是idoms(写法习惯)， 比如怎么组合logics.是参数语法，logics是参数类
比如idoms也可定义词性，特化某个词性，甚至某个词
于是这种编译器就是一种参数化了语法的和图灵形式的通用编译器，而不是跟普通编译器一样，有一套严格的语法而是语法被参数化可变了。而且它是参数化了类型的，即是参数化了冯氏机的。而它又可以很自然地跟dsl,编程者相结合。
只有4种文件在这个工程中：.idioms,.logics,progs(projects).docs
你们认为编程的首要原则是什么？
作为我的学习原则的一个实践：
8. 学习一项知识，必须问自己三个重要问题：1. 它的本质是什么。2. 它的第一原则是什么。3. 它的知识结构是怎样的。
5个月过去了，这个问题到现在还有人回复，我得到了一大堆有意思的答案，忍不住翻译过来与大家分享：
1. 获得最多认同的答案：
KISS - Keep It Simple Stupid
DRY - Don't Repeat Yourself
一点不感到意外吧？
注：DRY原则倒是比较好理解和实践的。但KISS原则则是看上去直白，其实实践起来不那么容易的一个原则，因为simple和stupid的定义并不是每个人、在每个场景下都是一致且明显的，一个人的simple可能是另一个人的stupid，一个人的stupid可能是另一个人的unnecessary。一旦一个标准取决于具体场景，事情就不那么简单了。所以我们经常要说“It depends”。
2. 获得第二认同的答案：
写代码时时刻设想你就是将来要来维护这坨代码的人。
在这个答案后面有人添加到：
最好设想你的代码会被一个挥着斧头的精神病来维护。
有人接着又YY道：
而且这个挥着斧头的精神病还知道你住在哪儿。 (( 事实上后面有人指出这是 Martin Golding 的一句名言 ))
注：其实这个原则在设计API时也有用：
写API时时刻设想你就是要去使用这坨API的人。
3. 一些众所不一定周知的答案：
先弄清你的问题是什么！
弄清问题永远是问题解决过程中的第一步和最重要的一步。
代码只是工具，不是手段。
不知道怎么最好地解决你手头的问题（注：需求、架构、算法，技术选型，etc..），写上一万坨代码也是浪费比特。
知道什么时候不该编码。
（类似条目：YAGNI——“你并不需要编写这坨代码！”，针对你的需求编码，“写你所需”，别做“聪明事”，为一个不确定的未来编码。同时也注意模块化设计，以便能在未来新增需求时无痛扩充系统）
永远不要假定你已经了解一切了！
不作没有证据的推论。
想清楚了再编写。类似条目：如果方案在你脑子里面或者纸上不能工作，写成代码还是不能工作。
4. 一些众所很可能周知的答案：
越懒越好。
过早优化是一切罪恶的根源。
不要重新发明轮子。
测试通过前说什么“它可以工作”都是纯扯淡。
了解你的工具。
一切以用户需求为导向。
利用分治、抽象，解开子问题之间的耦合。
5. 最幽默的答案：
咖啡进，代码出。（Coffee in, Code out） (( 参见 Garbage in, Garbage out. ))
最后，整个问题的 thread 在这里。
发表于 @ 2009年03月09日 19:09:00 | 评论( 6 ) | 编辑| 举报| 收藏
旧一篇:[BetterExplained]为什么你应该（从现在开始就）写博客 | 新一篇:逃出你的肖申克（二）：仁者见仁智者见智？从视觉错觉到偏见muzisoft2008 发表于2009年3月10日 7:23:02 IP:举报
如果站在最高的角度看编程，就会看到编程者，冯氏机系统模型，图灵语言模型，应用，如何将四者结合产生冯氏机上基于图灵开发模型的dsl的，自然语言编程。
只有这样想面对四大问题并解决它，才能使一切讨论开始变得有现实意义
首先我们来看待问题本身，编译原理告诉我们，
图灵机语言模型提供形式语法但不提供非形式形象的写法，
冯氏提供类型，它主导代码，为什么说冯氏是数据主导代码的呢，因冯氏机就是一台本质上的io机，开发者眼睛里只有类型（就是数据模板），在过程式语言内就是plain old dates,在OO语言内就是abstract datas,函数也是一种型，不过他只能传指针的方法跟其它数据类型交互，class就更是一种高级型，一方面是adt,一方面是udt(比如可以重载给以操作符),而模板呢，在udt的基础上generic了，但模板绝不是一种型，而是一种表现形式，代码结构，或写法结构都可由它来表现，与类搭配的模板就是表现类代码，函数模板就是表现函数
编程者需要写法而不是语法，
dsl需要写法上的idoms,领域相关的logics
我们可以整理一下上述所有概念的对应关系，
编程者（需要泛语法跟泛型） 写法 --- adt,udt
冯氏机 (需要类型pod或class)
图灵开发模型(需要形式语法)形式语法对应编程者的泛语法，即写法
应用(需要dslogics) (就对应冯氏的型和编程者方面的udt,adt)
而现在的语言，都只是解决了上面中的四个当中的一个。 那么我们如何把他们结合起来呢？对，是抽象！
抽象是解决问题的最好哲学，对于这四个问题，我们可以抽象它们，因为编程就是遵照语法写代码，根据我们在前面谈到的对四大问题的理解，我们可以首先把它抽象为：在写法下的类型，于是我们可以设置两大抽象，即抽象写法，和抽象的代码就是数据(冯氏是用数据主导代码的)
具体如何抽象呢？一种抽象的方法是参数化，参数化类型就参数化了冯氏机，参数化语法就参数化了图灵开发模型，这样就做到了泛语法加泛型，写法和类型，这两者都可用模板来呈现, 力求idoms跟logics的书写产生一致的编程泛式
什么是idoms,什么是logics呢？
idoms是语法规则，泛语法就是idoms(写法习惯)， 比如怎么组合logics.是参数语法，logics是参数类
比如idoms也可定义词性，特化某个词性，甚至某个词
于是这种编译器就是一种参数化了语法的和图灵形式的通用编译器，而不是跟普通编译器一样，有一套严格的语法而是语法被参数化可变了。而且它是参数化了类型的，即是参数化了冯氏机的。而它又可以很自然地跟dsl,编程者相结合。
只有4种文件在这个工程中：.idioms,.logics,progs(projects).docs
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐