十条不错的编程观点
在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）观点上。
（转载本文请注明作者和出处，请勿用于商业用途）
（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）
(52 人打了分，平均分： 4.50 )
Loading...
《十条不错的编程观点》的相关评论
第十点确实是敏捷公司里都会有的情况，从上面管理层到开发人员，大家都在重复的提倡TDD，但是TDD确实可以保证你在Refactoring的时候，不会因为一些小Bug而导致整个代码的出错，TDD不一定写的出好的代码，但是TDD可以保证代码在可控范围内的正确保证。一年生的粗浅认识
第二点原意是：“不会在业余时间以编程为乐的家伙永远不会成为和那些会以此为乐的人一样优秀的程序员。”把这一行仅仅当作工作而感受不到乐趣的同学确实很难有所成就吧
第六点我倒是挺支持的，前提是将搜索的答案作为reference而不是唯一的solution
第九点尤为同意
这年头，懂得一些基本道理，能看清基本事实的，能有基本思考能力的，就是精英了
同理，说某人“不脑残”也变成了一种夸奖。
这10条里面有好几条都在强调独立思考的重要性。不可否认独立思考确实很重要，但是好的模式和编程规范对于新手和一般的开发人员来说是很有用的指导，可以避免在初期犯错误。只有真的成了高手之后才能随心所欲不逾矩吧:)
只懂一门语言，甚至是只会在一个平台上开发，确实难以成为高手，所以才会有每年都学习一门新的语言的说法。
第二点很同意啦，缺失热情是无法写出高质量的代码的。
来访……留个脚印，博主不要见怪，哈哈。
是啊，方法本身没有错，但过分追求方法就是舍本逐末了。
关于第十条，代码写好之后的测试当然不可能让代码本身变好，但是写代码之前先写测试用例是不同的，它的作用不是为测试做准备，而是帮助理清目标：我们要写出什么样的东西，要满足什么样的要求，而之后测试用例的变化也反映了需求或目标的变化。
同意全部观点。
礼尚往来，哈哈，来过，希望博主有空回访小站。
“这种开发就是先写unit test case”，TDD即便有缺点，也肯定不是这个。建议楼主认真的试一下，也许会改变你的看法的。
“这种开发就是先写unit test case”。建议楼主认真的试一下，也许会改变你的看法的。
第四点有点价值。其余的嘛，我认为过分强调思维，而没有注重如何去“做”，去“实现”。在现代企业，这样显然是不可取的。
单元测试不能帮助你写好代码，但是，这也不应该成为你把代码写烂的借口，设计模式也是一样。
只有当你真正深入理解了这些东西，才可能更客观的评价它。
一个成功的程序员背后一定有一个默默支持他的老婆
有不同的想法才好玩，
都想的一样就没意思了。
#10, 这就是为什么（unit）test code 和 app/program code不是一个人写出来的理由了。
作为一个程序员应该多想实践，保持独立的精神。概念上的噱头很多，要对自己的直觉有信心，在批判的角度下用热情来驱动，才能有所作为。
想讨论一下第10条：
10）Unit Testing won’t help you write good code
英文原文是：
The only reason to have Unit tests is to make sure that code that already works doesn’t break. Writing tests first, or writing code to the tests is ridiculous. If you write to the tests before the code, you won’t even know what the edge cases are. You could have code that passes the tests but still fails in unforeseen circumstances.
翻译成中文的大致意思是：
单元测试唯一的好处是保障写好的代码不会被破坏。先写测试，再为测试写代码是一件很荒谬的事情。如果你不清楚自己应该测什么，如何能在写代码之前写出测试代码呢？你的代码可以通过测试，但在一些无法预料的场景下仍然可能会失败。
下面有一位的读者回复如下：-1 for attempting to turn developers off a valuable technique with which you clearly have little experience. – TrueWill Aug 29 ’09 at 21:39
这也是我的观点。明显这位作者自己的开发经验有限，至少TDD的经验非常有限。他连把 TDD和单元测试之间的区别都没搞清楚。
第一句话是说：单元测试唯一的好处是保障写好的代码不会被破坏。单元测试本身的作用确实如此。接着作者就说TDD很荒谬，原因是没有写代码之前不知道如何写测试。不是TDD荒谬，是作者自己很换缪。也许是作者不知道如何先写测试。如果真正不知道如何写单元测试，那是一个smell，应该停下来思考和理解业务，想清楚自己到底要做的是什么东西。你都不知道如何写测试，我很好奇你如何知道写实现代码的。
最后一句就是更荒谬了。如果连人自己都想不到的测试场景，我们又如何寄期望于单元测试呢？
如果你是一个普通的程序员，不是用了TDD实践之后，你就全身充满着力量，一下子变成了高手或者大师。用了TDD之后，你还是你。但是，它能督促你从使用者来思考自己的代码；它能督促你对代码进行解耦；它能督促你做一个比以前更好的设计；它能督促你写更好的代码。你比以前进步了，但只是一个比以前更好的普通程序员罢了！
的确受益良多。不过更像个总结，没有什么新鲜的观点。个人以为，无论语言也好，模式也好，甚至被炒得很热的OO思想也好，都是只是一种工具。既然是工具，那就有优缺点，有使用范围，不可能是万能的。只有在合适的时间、合适的地点、以一种合适的方式来使用它才能真正发挥它的价值，能做到这么多的“合适”正是智慧之所在。而智慧源于思考。
都是非常感同身受的观点。
如果一个团队的程序都能满足这些，这个团队的实力和前景将无可限量
3）Most comments in code are in fact a pernicious form of code duplication.
↑这个应该是表达现状。
“注释应该是注释Why，而不是How和What，参看《惹恼程序员的十件事》，代码告诉你How，而注释应该告诉你Why。但大多数的程序并不知道什么是好的注释，那些注释其实和code是重复的，毫无意义。”
↑但是不同意这个观点。注释发挥了自然语言的威力，也许我花10秒钟看一个注释就能可以明白一个函数的功能以及使用要点，但是看code可能要花10分钟（何况有时候定位代码都不见得能做到）。当我不需要明确实现的时候，这就是显著的浪费。
所以并非描述所有How和What的注释都是不必要的。
语言都是博大精深的，中文的诗歌用英文简直不是一个调儿，英文用中文去翻译往往丢掉了其中的韵味 如果所有的东西都阐述出来 会非常冗长