16,471
社区成员
发帖
与我相关
我的任务
分享谈谈编程(3下) 编程实践
一些基本的编程思想起源于更普遍的智慧。例如：
心智的活动，除了尽力产生各种简单的认识之外，主要表现在以下三个方面：1)将若干简单认识组合成一个复合认识，由此产生出各种复杂的认识。2)将两个认识放在一起对照（在这样做时并不将它们合而为一），不管它们如何简单或者复杂，由此得到有关它们的相互关系的认识。3)将有关认识与那些在实际中和它们同在的所有其他认识隔离开，这就是抽象。所有具有普遍性的认识都是这样得到的。
--- John Locke, 有关人类理解的随笔
程序员从这段1690年的文字中能看到什么。组合、对照、抽象，这些基本的思维工具同样也是程序员最基本的工具。
2 编程规则
编程是一门技艺，如同我们必须跳到水里才能学会游泳，我们必须多看、多写程序，才能学会编程。
任何技艺的学习都包括知识和能力两个部分。知识是明确的，可以用时间换取。能力是说不清的，不易掌握的。一般而言，能力高的人能够更快地积累知识，善于从已有的实践中总结规律，善于复用已有的模式，他们能更快地对复杂的环境形成清晰的认识，用最简洁、优雅的方式解决问题。如何提高编程能力应该是因人而异，每个人应该找到自己的学习路径，有自己的规划。
编程的表象千变万化，但在表象背后，还是有一定规律的。在某些条件下，这样做会比那样做更好一些。我们可以将这些东西称作经验、原则、规则，或者其它任何名词。
下面松散地列举了一些规则。我们应该在实践中检验已知的规则，总结自己的规则。
规则一 这世界上唯一的真理就是不要盲目相信真理
从某种意义看，原则、规矩这类东西就是用来打破的。所谓原则，就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近，我们可以参考前人的经验。我们是主动地拿来，而不是被动的遵守。
规则二 未蕴而变，自欺也；知律而变，智者之道也
这句话谈的是学词，必须先了解格律，然后才谈得上变化，否则就是自欺欺人了。在编程上，也是一样。在有资格打破一条原则前，首先要了解这条原则。先了解事物的规律，然后才是变化和灵活的应用。不要打倒自己不了解的东西。
规则三 寻找结构和成本的平衡点。当结构不能容纳变化时，重构代码到新的平衡点
开闭原则要求：一个软件实体应该对扩展开放，对修改关闭。即软件的结构要达到：允许在不修改软件的前提下扩展软件功能。
但好结构是要花成本的。程序员总是在折衷，寻找结构和成本的平衡点。我们会放一些余量，让结构能承受一定的变化。
规则四 要针对接口编程，不要针对应用编程
前面谈过了。我们总希望通过工作得到一些收获，积累一些经验。只有将代码分解成尽可能独立的模块，然后针对接口编程，才能保护我们的成果，让我们有所积累。
规则五 最少知识原则：模块对外界的了解应当尽可能少
前面也谈过了。所谓“圣人之治”，经常是“虚其心，实其腹；弱其志，强其骨，常使民无知无欲”。让被管理的对象尽可能得弱，对象间的关系尽可能得简单，可以降低管理的成本。
在面向对象编程中“组合优于继承”，就是因为继承将基类的实现细节暴露给子类，两者的耦合性太强了。另外，继承的实现是静态的，而组合可以更灵活地实现。
规则六 尊重习惯
在任何领域编程，应该尽量了解这个领域的习惯，尽量符合这些习惯。这样，别人可以更容易地理解和使用我们的程序，更不容易出错。
规则七 程序中不要出现magic number或其它神奇的东西
magic number就是诸如17、42这类数字。请用有描述性的常数名替代它们。常数名、变量名、函数名就是最好的注释。结构清晰的代码甚至可以不需要其它注释。
“需要很多注释的代码”是代码坏味道的一种，常常意味着需要重构代码，使它更容易被理解。
规则八 “两顶帽子”和“小步前进”
“两顶帽子”前面讲过了。面对复杂的问题，我们不仅要从结构上分解它，还要将实现步骤尽可能地分小，在一时一地以压倒性优势解决问题的一小部分。n-1个总比n个好对付，我们越来越强大，敌人越来越弱小，我们要做的只是将优势保持到最后。“保持优势”的关键是正确的理解、合理的划分。
规则九 适当地引入中间层，可以解决所有问题
这条规则是实质是“抽象”。在遇到问题时，多引入一层接口，将问题封装起来。
抽象本身并没有消除系统的复杂性，但它减少了在某个时刻需要处理的细节的数量。或者说，抽象将复杂性控制在接口和模型的后面，可以推迟我们处理这些复杂性的时刻。
这条规则的另一个说法是“多做白日梦”。假设我们已经得到了需要的东西，然后会怎么样？通过“白日梦”我们可以在更高的层次考察问题，可能找到解决问题的线索，也有可能发现这个问题毫无价值。即使毫无收获，我们也的损失也很小。
规则十 不要依赖调试，尽可能地依赖分析和推理
我经常会在头脑中预演调试的过程，计算我要做什么，我能得到什么。“预演”的结果经常是我没有必要这样调试，或者应该试一试另一个方法。
根据测不准原理，任何实际的测量、调试都会改变、影响被研究的对象。用调试辅助、验证我们的推测，但不要依赖调试。
心智的活动，除了尽力产生各种简单的认识之外，主要表现在以下三个方面：1)将若干简单认识组合成一个复合认识，由此产生出各种复杂的认识。2)将两个认识放在一起对照（在这样做时并不将它们合而为一），不管它们如何简单或者复杂，由此得到有关它们的相互关系的认识。3)将有关认识与那些在实际中和它们同在的所有其他认识隔离开，这就是抽象。所有具有普遍性的认识都是这样得到的。
--- John Locke, 有关人类理解的随笔
程序员从这段1690年的文字中能看到什么。组合、对照、抽象，这些基本的思维工具同样也是程序员最基本的工具。
2 编程规则
编程是一门技艺，如同我们必须跳到水里才能学会游泳，我们必须多看、多写程序，才能学会编程。
任何技艺的学习都包括知识和能力两个部分。知识是明确的，可以用时间换取。能力是说不清的，不易掌握的。一般而言，能力高的人能够更快地积累知识，善于从已有的实践中总结规律，善于复用已有的模式，他们能更快地对复杂的环境形成清晰的认识，用最简洁、优雅的方式解决问题。如何提高编程能力应该是因人而异，每个人应该找到自己的学习路径，有自己的规划。
编程的表象千变万化，但在表象背后，还是有一定规律的。在某些条件下，这样做会比那样做更好一些。我们可以将这些东西称作经验、原则、规则，或者其它任何名词。
下面松散地列举了一些规则。我们应该在实践中检验已知的规则，总结自己的规则。
规则一 这世界上唯一的真理就是不要盲目相信真理
从某种意义看，原则、规矩这类东西就是用来打破的。所谓原则，就是对历史上某种经验的总结。如果我们踏入的河流和前人非常接近，我们可以参考前人的经验。我们是主动地拿来，而不是被动的遵守。
规则二 未蕴而变，自欺也；知律而变，智者之道也
这句话谈的是学词，必须先了解格律，然后才谈得上变化，否则就是自欺欺人了。在编程上，也是一样。在有资格打破一条原则前，首先要了解这条原则。先了解事物的规律，然后才是变化和灵活的应用。不要打倒自己不了解的东西。
规则三 寻找结构和成本的平衡点。当结构不能容纳变化时，重构代码到新的平衡点
开闭原则要求：一个软件实体应该对扩展开放，对修改关闭。即软件的结构要达到：允许在不修改软件的前提下扩展软件功能。
但好结构是要花成本的。程序员总是在折衷，寻找结构和成本的平衡点。我们会放一些余量，让结构能承受一定的变化。
规则四 要针对接口编程，不要针对应用编程
前面谈过了。我们总希望通过工作得到一些收获，积累一些经验。只有将代码分解成尽可能独立的模块，然后针对接口编程，才能保护我们的成果，让我们有所积累。
规则五 最少知识原则：模块对外界的了解应当尽可能少
前面也谈过了。所谓“圣人之治”，经常是“虚其心，实其腹；弱其志，强其骨，常使民无知无欲”。让被管理的对象尽可能得弱，对象间的关系尽可能得简单，可以降低管理的成本。
在面向对象编程中“组合优于继承”，就是因为继承将基类的实现细节暴露给子类，两者的耦合性太强了。另外，继承的实现是静态的，而组合可以更灵活地实现。
规则六 尊重习惯
在任何领域编程，应该尽量了解这个领域的习惯，尽量符合这些习惯。这样，别人可以更容易地理解和使用我们的程序，更不容易出错。
规则七 程序中不要出现magic number或其它神奇的东西
magic number就是诸如17、42这类数字。请用有描述性的常数名替代它们。常数名、变量名、函数名就是最好的注释。结构清晰的代码甚至可以不需要其它注释。
“需要很多注释的代码”是代码坏味道的一种，常常意味着需要重构代码，使它更容易被理解。
规则八 “两顶帽子”和“小步前进”
“两顶帽子”前面讲过了。面对复杂的问题，我们不仅要从结构上分解它，还要将实现步骤尽可能地分小，在一时一地以压倒性优势解决问题的一小部分。n-1个总比n个好对付，我们越来越强大，敌人越来越弱小，我们要做的只是将优势保持到最后。“保持优势”的关键是正确的理解、合理的划分。
规则九 适当地引入中间层，可以解决所有问题
这条规则是实质是“抽象”。在遇到问题时，多引入一层接口，将问题封装起来。
抽象本身并没有消除系统的复杂性，但它减少了在某个时刻需要处理的细节的数量。或者说，抽象将复杂性控制在接口和模型的后面，可以推迟我们处理这些复杂性的时刻。
这条规则的另一个说法是“多做白日梦”。假设我们已经得到了需要的东西，然后会怎么样？通过“白日梦”我们可以在更高的层次考察问题，可能找到解决问题的线索，也有可能发现这个问题毫无价值。即使毫无收获，我们也的损失也很小。
规则十 不要依赖调试，尽可能地依赖分析和推理
我经常会在头脑中预演调试的过程，计算我要做什么，我能得到什么。“预演”的结果经常是我没有必要这样调试，或者应该试一试另一个方法。
根据测不准原理，任何实际的测量、调试都会改变、影响被研究的对象。用调试辅助、验证我们的推测，但不要依赖调试。
...全文
请发表友善的回复…
发表回复
sharpshootor 2005-09-27
- 打赏
- 举报
好,顶
phoenix01 2005-09-27
- 打赏
- 举报
n!!
up
up
legendhui 2005-09-27
- 打赏
- 举报
up
bobob 2005-09-27
- 打赏
- 举报
等写完了汇总一下，加精
KennyLiu 2005-09-27
- 打赏
- 举报
好文章
老夏Max 2005-09-27
- 打赏
- 举报
先Mark，中午看看！
nkwesley 2005-09-27
- 打赏
- 举报
顶
fmddlmyy 2005-09-27
- 打赏
- 举报
最近写了些讲义用于部门内部培训，这几篇是编程基础部分。大家帮着看看有什么错误和不足，谢谢。
