十条不错的编程观点
在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微信公众账号和微信小程序
（转载本站文章请注明作者和出处 酷 壳 – CoolShell ，请勿用于任何商业用途）
(51 人打了分，平均分： 4.49 )
Loading...
《十条不错的编程观点》的相关评论
仁者见仁，智者见智
不要再英文中使用中文引号‘，要用英文引号’
@sjinny
哦，原来是这样：D
我对第3条是有争议的：比如一个函数的注释，只要将这个函数的功能、形参和返回值解释清楚就可以了。用户一看这个函数的注释就知道这个函数的功能及怎样用这个函数，对用户来说，他有必要知道这个函数为什么要这么编写吗？
TDD过程中不是需要不停的进行重构么？为什么说 不是让程序员或代码质量更有长进呢？
“最后，顺便说一下，以前去那个敏捷的公司面试，发现那个公司的某些技术人员中毒不浅，具体表现在上述的1）9）10）观点上。”
不会是说Thoughtworks这个公司吧？
很多都不是一个是或非就能说清楚的，有道理，但也应该有范围来范围。
一般是TDD + 持续重构， 重构后是否就质量高了， 还是要看人自身的能力， TDD这些都仅仅是实践方法而已。
呃，收集编程格言。
书里要用。
看怎么操作一下好？
在书里提一下参考了这里的帖子并表示感谢行吗？
対第六条的理解是不是有歧义，原文的意思是正面的，博主好像写的是自己的观点。
第六条，博主的写的注释和原文的意思反了吧，原文是说googling是可以的，只要有自己的理解并且正确就可以了。
呵呵 。谁有谁的观点
9.10很好理解。队伍大了，管理不过来，需要有个尺去标明。还需要一说就明白的大体思想的设计模式。
10）Unit Testing won’t help you write good code
对于第十条有点没明白。没有真正参与过公司的项目开发，不清楚单元测试是否这个意思，见谅。
我在写题目时，对于一个问题，会模块化考虑，然后一个个实现函数模块。顺手作个模块测试。最后全部完成了，再测试。我觉得这样会让代码更清晰，并且更容易发现错误。比直接写完代码后，发现错误再调试要容易定位错误。
为什么第十条认为这样做是不利于写出优秀代码？正确的做法应该是怎么样的呢？
不能同意你更多
对于第六条，StackOverflow原文是： Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. 显然作者主观化解读了，应该改正–否则这才叫快餐文化吧？
XML is highly overrated, too.
JSON is highly overrated, too.