另眼相看“那些争议最大的编程观点”
太阳火神的漂亮人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
转载请保留此句：太阳火神的漂亮人生 - 本博客专注于 敏捷开发及移动和物联设备研究：iOS、Android、Html5、Arduino、pcDuino，否则，出自本博客的文章拒绝转载或再转载，谢谢合作。
有感于中国小孩背9x9乘法表，而印度小孩背19x19乘法表！
补充：再进一步扩展到 100 以内随意两数相乘
假设把100以内的数分为10级，那么，10以内的数就是 0级，20以内的数就是1级，以此类推，90以内的数就是8级，100以内的数就是9级；
按此分级，随意两个100以内的数，如83和57就各自是8级和5级的数，这两者的级差是3；
由此级差概念的引入，我们能够方便计算 100 以内随意两个数的乘积，当然了，数越大，记数越难，但相对来讲通过算式的分解，就能够非常easy口算得出结果；
例如以下列中：
37 x 26
= (27 + 1x10) x 26
= 27 x 26 + 1x10 x 26
= (7+6+20)x20+7x6 + 1x10x26
再或者 ：
83x57
先进行级差分解：
= (53+3x10)x57
=53x57 + 57x3x10
接下来就对前面的同级两个数相乘运用之前的方法：
=(3+7+5x10)x5x10+3x7+57x3x10
那么，我们归纳整理一下：
假设100以内随意两个数的个位分别为 M、N(N为小数的个位)，级数为K，级差（即十位之差）为P，那么
=(M+N+10K)*10K + M*N +(10K+N)*P*10
此式做了再进一步的分解，以级差和级数取代了整十位数的參与，这样，全部问题都转化成了十以内的数和十的运算；
不同级数的100以内两数相乘，无非就是后面要再加上大数多出来的整十部分与小数的乘积；
整十部分与人相乘，无非就是个位与人相乘，再在结果后面加个0；
乘10嘛，就是总体左移，右面补零占个数。
----------------------------------------------------------
19x19 此类20以内乘法也非常easy：
13 x 16
= 16 x 13
= 16 x 3 + 16 x 10
= 10 x 3 + 6 x 3 + 10x10 + 6 x 10
= 10 x (3 + 10 + 6 ) + 6 x 3
= (10 + 6 + 3 ) x 10 + 6 x 3
以上为本人推导过程，以下为印度乘法表算法：
= （16 + 3）x10 + 6 x 3
即为：被乘数 加上 乘数的个位，再乘以十，最后加上 乘数 与 被乘数 的 个位 乘积；
按我的观点是，乘数 和 被乘数 因 十位都是 10，所以，仅仅取个位，个位无非是从 0 ～ 9：
= （（6 + 3）+ 10）x 10 + 6 x 3
即为：个位之和，进个位，左移位，再与个位之积求和；
进个位，就是 加10；移个位，就是 乘10；
终于把 两个数的个位用 M 和 N 表示，那么结果就是：
=（（M + N）+ 10）x 10 + M x N
这个方案，好像真的不适用于超过19的数，仅仅适用于十位为 10 的两数相乘，但这个局部的规律足以应对该范围的问题解决，这就足够了。
并非全部的事物都有共同的法则，但当你把范围缩小到特定时间、空间时，非常多适用于这个特定小范围的规律就会应运而生，那也得看你是否愿意去总结。
那么上面，我是用推导的方式推出来的十几这种数相乘，那么二十几的两数相乘是否有规律可循呢，我们再推导一下试试吧：
26 x 29
= 29 x 26
= 29 x 20 + 29 x 6
= 20 x 20 + 9 x 20 + 20 x 6 + 9 x 6
= 20 x (20 + 9 + 6) + 9 x 6
假设假设个位分别为 M 和 N ，那么
=（ M + N + 20）X 20 + M X N
再进一步扩展，十位假设为随意 0 ～ 90，用 K 表示
= （M + N + K）X K + M X N
这样一来，100以内，各十位段的两个数相乘的通用公式就是：
个位之和，加段乘段，再与个位之积相加；
试试 78x 73 ? 口算等于：5694
再用竖式来算：坚式用口算好像算不出来呀！！
那用计算器吧：5694，正相符。
只是这么大的数尽管也能算出来，但还是要复杂些了，脑袋中记数的能力要强，只是总比坚式算法要强，竖式要记的数不太easy用脑子记住 。
通过以上的论证、推导，就非常easy理解，规律分大小，适应面儿越大的规律，越少，也越难理解；适应面儿小的规律往往更实用，但相对要多得多，尽管非常easy理解和应用。
那么接下来，再看以下转载的文章中的观点，事实上非常多观点都不一定是对或是错，所处的环境不同，就得因地置宜，当然了，大多数情况，是求广范。
所以对待每个问题，还是得辩证地看，多角度地看，适合自已的才是最好的，不要盲从！
www.MyException.Cn 公布于：2013-08-30 19:33:18 浏览：17203次
知名问答站点StackOverflow之所以成功，合理的规则与严格运行是重要的原因，所以删帖是常常的。只是有时候运行得过严了，被删的问答不时会有惊艳之作。这不，他们的博客8月29日的文章“20个最受争议的编程观点”说的就是这样一个被删帖。此文一出，立马在Reddit、Hacker News等各大技术新闻站上引起了热议。
实际上2010年酷壳以前有文章介绍过当中的十条，但观点本身没有翻译。
最初的问题“你最受争议的编程观点是什么？”（这里还能看到存档），由Jon Skeet在2009年1月提出。此人可不是无名小卒，C#社区大名鼎鼎的人物，多年微软MVP，所著《深入理解C#》（英文版C# in Depth）一书是C#领域少数不可不读的名著（老赵就说过C#他仅仅推荐两本，这本和CLR via C#），如今Google英国公司任project师（还真不知道他在那里干什么）。
那么，这个问题当时都有哪些热门答案呢？顺序是随机的。
1. 业余时间不会为了好玩而编程的程序猿，永远比不上那些以编程为乐的同学。
我觉得即使是最聪明、最有才华的人，假设仅仅是将编程作为工作，也永远成不了真正优秀的程序猿。以编程为乐的人会在业余时也搞些小项目，或者弄弄各种不同的编程语言和编程思想。
2. 单元測试无助于编写优秀代码。
编写单元測试的唯一理由仅仅是确保已经能工作的代码不会出问题。先写測试或者按測试来写代码是无比荒谬的。假设在代码之前写測试，你都不知道边界情况是什么。尽管能让代码通过測试，可是在没有预见到的情况时还是会出问题。并且，好的开发者会尽量减少内聚性，新增代码不可能使已有的出问题。
3. 唯一能放之四海而皆准的最佳实践，是“用脑子思考”。
太多人喜欢追逐众多时髦技术，想方设法把各种方法、模式、框架用到不适合的地方。新技术和名人大牛的观点并等于适用于实际情况。
4. 大多数代码中的凝视实际上都是代码反复的恶性表现。
我们大部分时间是在维护其它人（或者我们自己）写的代码，而糟糕、错误、过时和误导性的凝视肯定是代码中最令人纠结的东西之中的一个。非常多人终于会将它们干掉。应该把精力放在提高代码的可读性、必要时就重构、少用惯使用方法和奇技淫巧上。另外，很多教材还在宣扬什么凝视甚至比代码还重要，结果导致了大量废话连篇的凝视。
5. 依赖Google没什么错。
这种言论肯定会让那些学富五车的饱学之士恼火。可是谁都须要查资料不是？正确答案就是正确答案，管它是来自哪本秘籍或者私相传授，还是Google出来的呢？重要的是能真正理解，并给出成功的编程解决方式，让客户和老板惬意。
6. 程序猿不是生而平等的。
经理往往觉得程序猿A==程序猿B，由于他们的年头差点儿相同。实际上，一个开发者的效能能够是还有一个的十倍甚至百倍。
7. 我实在不能理解为什么Java是最适合大学教学的第一门语言。
首先，我相信第一门编程语言应该重在学习控制流和变量，而不是对象和语法。其次，我觉得没有调试C/C++内存泄漏经验的人，根本无法全然理解Java的初衷。并且，自然的发展过程应该是从“我如何做这事”到“我如何找到能做这事的库”，而不是倒过来。
8. 假设你仅仅会一门语言，不管多么精通，仍然不是优秀的程序猿。
有人觉得，仅仅要精通了C#、Java或者其它什么你学会的第一门语言，就足够了。我不敢苟同。我学习的每一种新语言，都教了不少编程新知，能够反过来用于工作中。不论什么人仅仅局限于一种语言，都无法充分发挥自己的潜力。并且缺乏求知欲和探索意愿，都不符合优秀程序猿的特质。
9. 偶尔写写垃圾代码也无妨。
有时候一些特定任务，快而脏的代码能搞定即可了。模式、ORM、SRP（单一职责原则）啥的算了吧。
10. print语句是有效的调试方式。
我觉得用 System.out.println 之类的输出语句调试代码挺好。这常常比正式的调试要快，并且能够比較不同运行的输出结果。可是投入生产环境之前一定要删除这些语句，或者将它们放入日志语句中。
11. 你的工作是要把自己摘出来。
你写的软件都应该让其它不论什么开发者花一点时间就能理解并接手。软件应该设计优雅，代码清晰和一致，格式干净，文档合适，每日构建，有恰当的版本号管理。假设你被车撞了、被开了、辞职了，公司应该非常快能有人非常快替代你。假设不能，那你就太悲剧了。有意思的是，你越这样做，你对公司的价值越大。
原帖以下有人评论：你假设无法被替代，也就无法升职啦。
12. getter和setter被极度滥用了。
成千上万的人都说公共字段是罪恶的，应该设为私有，提供getter和setter。我觉得事实上没啥不同，除非程序是多线程的，或者訪问方法中有业务或者展示逻辑（这可够怪的）。我并非赞成用公共字段，仅仅是反对用訪问方法或者属性包一下，就号称封装、信息隐藏了。
13. SQL也是代码，请等而视之。
SQL和C#, Java或者其它对象、过程语言没什么不同，请注意代码的格式、可读性和可维护性。
14. UML图被高估了。
有些图当然是实用的，比方Composite模式的类图。但很多UML图都毫无价值。
CSDN编者注：记得Robert Martin在《敏捷软件开发（C#版）》里讲UML时，基本上是讲一个图然后说，好像没什么用，我就没怎么用过……同一个问题以下还有一个相关的答案：代码==设计。觉得高级语言代码比UML图和文档更有效。
15. 可读性是代码最重要的方面。
比正确性还重要。可读的代码也easy修正，easy优化、改动、理解。并且其它开发者也能从中获益。
16. XML被大大高估了。
非常多随波逐流跳上XML这黑船的人都没过脑子。XML用于Web应用不错，由于它本来就是干这个的。此外的问题定义、设计思路应该尽量不用XML。
17. 软件开发仅仅是一份工作而已。
我热爱软件开发， 我如今一家创业公司干，每周公司60小时，并且工资不高，仅仅由于团队非常棒，工作非常有趣。但站得高一点来看，这仍然仅仅是一份工作而已。它不如家庭、我的女友、其它朋友、幸福等等重要。要是有足够的钱，我宁愿去玩摩托、游艇或单板滑雪。很多开发者忘记了敲代码不是终于目的，它仅仅是为我们提供条件，去高高兴兴地做生命中最重要的事情。
CSDN编者注：这条和第1条好像有点对着来嘛。
18. 开发者就应该能够写代码。
去年做了非常多面试，我主要会測人们的思路，如何在白板上实现比較简单的算法。我往往从这种问题開始：
已知Pi能够用函数4 * (1 – 1/3 + 1/5 – 1/7 + …) 计算，项越多越精确，请写一个函数，计算小数点后5位的Pi。
这是一个10行C#就能搞定的问题。但很多面试者甚至毫无思路。所以我仅仅好接着问这种问题：
已知圆的面积是Pi乘以半径的平方，写一个函数计算。
竟然有超过半数的人无法用不论什么语言完毕这个函数！唉，开发者应该能够写代码，如今连这个都成有争议的观点了……
19. 设计模式弊大于利。
软件设计，尤其是好的软件设计千变万化，没法有意义地用模式去总结，尤其是那些大家记得住的几个模式，并且这些模式也太抽象了，事实上没几个人真正记得住太多。所以设计模式事实上没啥用。而还有一方面呢，又有太多的人为设计模式的概念迷住，想方设法到处用——结果代码中往往除了一些毫无意义的单例和抽象工厂之外，差点儿找不到什么设计。
20. 代码少少益善。
假设用户看不到你的工作，才是做对了。荣耀在别处。
其它比較热门的答案还有：
21. 性能真的非常重要。
22. 企业应用非常滑稽。须要n年经验是胡扯。计算机科学学位课程纯忽悠。
23. 单元測试无助于编写好代码，软件project大多数所谓的最佳实践都是为了防范烂程序猿搞太多破坏。
24. 每个程序猿都应该熟悉现代计算机的体系结构。
25. 编写小方法。
26. PHP真烂！
27. C++是有史以来最差的语言之中的一个。
28. 大多数职业程序猿都非常烂。
29. 要想成为程序猿，你得先学会打字。
30. 编程之外的各种流程规矩越多，代码质量越差。
资深的游戏程序猿James Hague（名博Prog21是也）也看到此文，觉得这些观点都没啥太大争议性。他专门写了一篇博客，又提出了他自觉得更具争议性的观点，当中不少观点指向他之前发表的其它文章：
31. 计算机科学专业应该仅仅作为辅修学位。
32. 新程序猿还没有弄懂分解问题和将解决方法变成代码之前，就给他们介绍面向对象是大错特错。
33. 复杂的编译器优化差点儿都没什么价值，即使能得到更快的代码。它们会大大减少编译速度并且非常可能产生难以处理的bug，使性能问题的处理更加困难。
34. 不能同意没有十年编程经验的人编写供他人使用的库。忽略此条，抱憾终身。
35. 代码丑陋与否无关紧要。有没有格式与代码是否工作、可靠没什么关系，能够让自己主动化工具来整理格式。
36. 纯函数式编程没啥用。但在命令式代码里杂用一些效果不错。
37. 软件project的既定思维反而会阻碍你做出伟大作品。