热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

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

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

刘未鹏的 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,欢迎访问原出处。


推荐阅读
author-avatar
有颜色的狼的天空
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有