以下内容翻译自 stackoverflow.com 上的一篇文章：
What's your most controversial programming opinion?
每个争议的论点后面是我的点评,蓝色代表赞成,绿色代表中立,红色代表反对.
1）不在空闲的时间开发有趣内容的程序员不是好程序员
热情和能力当然不能画上等号，但是不能不说没有关系。
在中国,不光要在空闲时开发自己感兴趣的,还要开发能赚钱的.
2）唯一的最佳实践就是使用你的大脑
最佳实践是用来限制那些糟糕程序员的破坏力。
尽量少用开源项目,如果一定要用到,必须先对其十分了解.
3）”Googling it” is okay!
Google可以用来寻找答案，但并不能提升你自己的思考能力。
先思考,再百度/Google. Google is ok, but not all.
4）很多的注释和代码是重复的
注释应该是注释Why，而不是How和What。
前提是命名首先要词能达意并且尽量用一个词表示清楚,实在不行再考虑用多个词做类名/方法名,实在还是不行才考虑写注释.
5）XML的能力是被高估的
Java项目中的XML使用量会告诉你什么叫"过犹不及"和"弄巧反拙".
6）不是所有的程序员可以画为等号
不光IT这行,所有行业都是,任何希望量化程序员能力和工作量的手段都是带有偏见的.
7）我不明白为什么大学教程里说Java是最好的“第一”编程语言
个人认为大学里第一要学的语言是那些着重讲述控制流程和变量的，不是对象和语法。自然的流程应该是我是学习我是怎么实现它，然后再使用我怎么使用它。
Java绝对不是,特别是在中国,Java让初学者浪费大量时间在非编码的工作上.
8）如果你只会一种语言，不管你有多精通都不会成为一个好程序员。
看地域和行业而论,但也建议多学一两种语言.
9）性能确实很重要
看项目和客户类型而论,但也建议追求性能和效率.
10）打印代码执行结果是一个最有效的调试方案
单元测试不见得能解决多少问题,打印结果是轻量级的单元测试,没必要硬性要求单元测试.
11）你的工作是让你脱离现有的工作
聪明的人才能体会这点,这点是程序员的本质.
12）Getter 和 Setter 被过度的使用
大部分时间都是花瓶,甚至从来没用到过的.
13）UML的作用被高估了
主要是好用又方便(针对适合大部分IT从业员而论,非纯码农)的IDE太少.
14）SQL是代码，你需要格式化它
触发器和存储过程的确需要.
15）代码可读性是你代码最重要的指标
代码可读性关系到维护效率、调用方便性和性能.
16）不是所有的开发人员都应该会写代码
不是所有的开发人员都应该参与写代码,但全部都必须会写.
17）使用匈牙利命名法的人应该被处死
罪不至死,但确实极度影响代码可读性.
18）设计模式正在破坏好的设计
100%是,跟风,滥用,乱用,并且还拿出来忽悠人,笔者对经常吹嘘DP的人十分反感.
19）代码越少越好
不是越少越好,是越精简越好.
20）PHP是糟糕的
你使用才才会明白为什么
事物都是相对的,如果PHP是糟糕的,J2EE根本就是一坨屎.
21）单元测试不会帮助你写好代码
视乎程序员的逻辑思维方式而论,有些人需要自下而上,有些则需要自上而下,但强制别人用单元测试的人确实是偏见了.
22）写简短的方法
不是简短,是精简,并且绝对不要学<重构>一书所说的切分得那么短,那是过犹不及了.
23）在一段时间内写垃圾代码是可以接受的
这是必经之路,所有人(包括高手)所有项目都必须经历重构的阶段.
24）软件开发只是个工作
这主要看从业员是为钱还是为兴趣,这种话题所有行业都存在争议.
25）软件设计和架构是被高估的
反对者表示很多软件架构师不再每天写代码但是要教别人怎么写代码是不可取的。
有经验的程序员会毫不犹豫的赞同这点.
26）代码==设计
重构了超过100次的完美代码(包括CSS) = 设计
27）软件开发中没有银弹
银弹如果指技术,确实没有,如果是指人和团队,是可以做到的.所有行业都可以实现波峰叠加效应,看团队领军人的能力.
28）每个开发人员都应该熟悉基本的架构和技术及知识
尽管秦始皇不这么认为,但的确是需要.
扫一扫
1580
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
