随机记事

在Stack Overflow上有这样的一个贴子《What’s your most controversial programming opinion?》，翻译成中文就是“你认为最有争议的编程观点是什么？”，不过，在400多个主回贴，以及 千把个子回贴中，好像并不是很有争议，而是令人相当的茅塞顿开，下面罗列一些，并通过我自己的经历和理解发挥了一些，希望对你有帮助。

1） The only “best practice” you should be using all the time is “Use Your Brain”.

唯一的“Best Practice”并不是使用各种各样被前人总结过的各种设计方法、模式，框架，那些著名的方法、模式、框架只代码赞同他们的人多，并不代表他们适合你， 你应该更多的去使用你的大脑，独立地思考那些方法、模式、框架出现的原因和其背后的想法和思想，那才是“best practice”。事实上来说，那些所谓的“Best Practice”只不过是限制那些糟糕的程序员们的破坏力。

2）Programmers who don’t code in their spare time for fun will never become as good as those that do.

如果你对编程没有感到一种快乐，没有在你空闲的时候去以一种的娱乐方式去生活，无论是编程，还是运动，还是去旅游，那么你只不过是在应付你的工作， 无时无刻不扎在程序堆中，这样下来，就算是你是一个非常聪明，非常有才华的人，你也不会成为一个优秀的编程员，要么只会平平凡凡，要么只会整天扎在技术中 成为书呆子。当然，这个观点是有争议，热情和能力的差距也是很大的。不过我们可以从中汲取其正面的观点。

3）Most comments in code are in fact a pernicious form of code duplication.

注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你 How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和code是重复的，毫无意义。

4）XML is highly overrated

XML可能被高估了。XML对于Web上的应用是不错的，但是我们把其用到了各种地方，好像没有XML，我们都不会编程了。

5）Not all programmers are created equal

这是那些junior经理或是流程爱犯的错，他们总是认为，DeveloperA == DeveloperB，只要他们的title一样，他们以为他们的能力、工作速度、解决问题的方法，掌握的技能等等都是一样的。呵呵。更扯的是，在某些时 候，就算是最差的程序员，他们也会认为其比别人强十倍，这就是现代的SB管理。

6）”Googling it” is okay!

Google只会给你知识，并不会教给你技能。那里只有“鱼”，没有“渔”，过度的使用Google，只会让你越来越离不开他，你越来越去要去立马 告诉你答案，而你越来越不会自己去思考，自己去探索，去专研。如果KFC快餐是垃圾食品对我们的身体没有好处，那么使用Google也一种快餐文化对我们 的智力发展大大的没有好处。

7）If you only know one language, no matter how well you know it, you’re not a great programmer.

如果你只懂一种语言，准确的说，如果你只懂一类语类，如：Java和C#，PHP和Perl，那么，你将会被局限起来，只有了解了各种各样的语言， 了解了不同语言的不同方法 ，你才会有比较，只有了比较，你才会明白各种语言的长处和短处，才会让你有更为成熟的观点，而且不整天和别的程序在网上斗嘴争论是Windows好还是 Unix好，是C好还是C++好，有这点工夫能干好多事了。世界因为不同而精彩，只知道事物的一面是有害的。

8）Your job is to put yourself out of work.

你的工作不是保守，那种教会徒弟，饿死师父的想法，不但是相当短浅的，而且还是相当脑残的。因为，在计算机世界里，你掌握的老技术越多，你就越没 用，因为技术更新的太快。你对工作越保守，这个工作就越来越离不开你，你就越不越不能抽身去学新的东西，你也就越来越OUT了。记住：If you can’t be replaced then you can’t be promoted!

9）Design patterns are hurting good design more than they’re helping it.

很多程序员把设计模式奉为天神，他们过度的追求设计模式以至都都忘了需求是什么，结果整个系统设计被设计模式搞得乱七八糟，我们叫这种编程为“设计模式驱动编程”，正如第一点所 说，如果你不懂得用自己的大脑思考的话，知其然，不知所以然的话，那么你不但得不到其好处，反而受其所累。

10）Unit Testing won’t help you write good code

准确地说，我们可以认为这是Test-Driven开发，其实，这种开发就是先写unit test case，这样的开发方式的主要目的是，为了防止你不会因为一个改动而引入Bug，但这并不会让你能写出更好的代码。这只会让你写出不会出错的代码。同第 一点，这样的方法，只不过是防止糟糕的 程序员，而并不是让程序员或代码质量更有长进。反而，通过Unit Test会为程序员的为自己代码做辩解的一种托辞。

最后，顺便说一下，以前去那个敏捷的公司面试，发现那个公司的某些技术人员中毒不浅，具体表现在上述的1）9）10）观点上。

杂事编程

不久前，NHibernate的主力开发人员Oren Eini在博客上发表了一篇名为“怎样才算易于维护”的文章，许多网友围绕这个问题表达了自己的看法。

事情的起因是由于NDepend的开发人员Patrick Smacchia认为NHibernate 2.1的代码“变得很难维护，容易牵一发而动全身”，Oren Eini撰文予以回应并认为NHibernate 2.1的代码依然很容易维护。话题慢慢转移到对“易于维护”标准的讨论上，如Frans Bouma在回复中谈到：

已经花费很长时间来深入代码的人自然能够顺利地修改代码，对他来说代码便是易于维护的。但是对于新接触这些代码的人来说，如果需要花费很长时间才能知道应该从哪里入手，以及更重要的：“为什么”要这样修改，这已经意味着这些代码的可维护性需要提高。

Oren对此有不同看法，他谈到：

我必须说我完全不同意这个看法。

“可维护性”对那些熟悉代码的人来说才有意义，如果这些人认为代码令人难以接受，则表明可维护性较差。如果某人对代码还缺乏必要的了解，那么他认为“难以维护”并不能说明代码本身的任何问题。

不少回复支持Oren的看法，如Phil Haack（微软ASP.NET MVC框架开发人员之一）回复到：

我完全同意你的看法。例如，如果我接触一个较大规模的Python程序，那么我自然难以对它进行维护。除非我学习了Python，它的风格和约定，那么我可能就会觉得那些有经验的Python程序员写的代码容易维护了。

……然而，熟悉代码所需要的时间，与在了解代码的情况下，是否容易进行维护并没有直接的关系。我们还必须区分领域本身的复杂程度，以及低劣的实现方式所带来的复杂性。

不过也有人认同Frans Bouma的说法：

如果你足够了解代码的话，就算是一堆狗食（dog-breakfast）也是容易维护的。我见过许多代码本身很有问题，但是它们的作者还是能够轻松地维护代码。

所以衡量可维护性的正确方式，应该让作者和熟悉的人回避，让其他的人来尝试着进行维护。如果难以进行，则这段代码早晚会出问题。这在我的定义中代表了较差的可维护性。

也有人认为应该区分一些概念：

在我看来，可维护性是指那些已经熟悉代码的人，在修改系统时需要承担多少风险的问题。如果你有自信可惜在修改时不破坏无关的部分，那么系统就是易于维护的。

至于“可学习性（learnabiliy）”则是另一个问题了。

但是事件的“始作俑者”Patrick认为“可维护性”和“可学习性”是一回事情：

我同意Bouma的说法。一个人不可能永远熟悉每一行他写的，或者他曾经维护过的代码。我经常遗忘两星期前写的代码。但是有了组件化，结构化，分层……我可以在遗忘之后很快地重新掌握它。

可学习性和可维护性表示的是同一类事情，它们都意味着代码必须被独立地分割，独立地开发，重构，测试，学习和增强。这是“分而治之”原则。违反这个基本原则的代码规模很难提高，对于大型IT组织来说，违反这个原则会是最主要的问题。

Jason认为影响“可学习性”的因素有时并非单纯的实现问题：

我认为我们应该通过观察代码的耦合性，内聚性，以及一个人能否根据接口和文档（而不是深入代码）了解代码的作用和使用方式来评价它的“可维护性”。

而可学习性与可维护性不同，因为领域本身的特点会影响学习难度。不过可学习性的其他一些因素也会涉及到可维护性，因此它们是有关系的。

此后，大部分人在回复中认为“代码的可维护性不应该和开发人员等外部资源有关”，因为没有人能够保证这些外部资源是永远充足的。

您的看法是什么呢？您认怎样的代码“易于维护”呢？

技术文档编程