在产品代码中没有反射的位置

反射破坏了静态分析，包括重构工具和静态类型检查。反射还打破了开发人员对代码的正常假设。例如:向类中添加一个方法(它不会影响类中的其他方法)应该永远不会有任何影响，但是当使用反射时，其他一些代码段可能会“发现”新方法并决定调用它。实际上，确定这样的代码是否存在是很难的。

我确实认为在代码生成器中使用反射和测试是很好的。

是的，这确实意味着我试图避免使用反射的框架。(Java缺乏适当的编译时元编程支持，这太糟糕了)

意见:不应该有任何编译器警告，只有错误。你应该总是使用-Werror编译你的代码。

原因:要么编译器认为这是一个应该被纠正的错误，要么它不需要修复，在这种情况下编译器应该直接关闭。

c++的STL库是如此通用，以至于它对任何人都不是最优的。

继承是邪恶的，应该被摈弃。

事实是，在任何情况下，聚合都更好。静态类型的OOP语言不能避免继承，它是描述方法想从类型中得到什么的唯一方法。但是动态语言和鸭子类型可以没有它。Ruby mixins比继承强大得多，也更可控。

您不应该停留在您发现的编写“有效”代码的第一种方法上。

I really don't think this should be controversial, but it is. People see an example from elsewhere in the code, from online, or from some old "Teach yourself Advanced Power SQLJava#BeansServer in 3.14159 minutes" book dated 1999, and they think they know something and they copy it into their code. They don't walk through the example to find out what each line does. They don't think about the design of their program and see if there might be a more organized or more natural way to do the same thing. They don't make any attempt at keeping their skill sets up to date to learn that they are using ideas and methods deprecated in the last year of the previous millenium. They don't seem to have the experience to learn that what they're copying has created specific horrific maintenance burdens for programmers for years and that they can be avoided with a little more thought.

事实上，他们似乎甚至没有意识到做一件事可能有不止一种方法。

I come from the Perl world, where one of the slogans is "There's More Than One Way To Do It." (TMTOWTDI) People who've taken a cursory look at Perl have written it off as "write-only" or "unreadable," largely because they've looked at crappy code written by people with the mindset I described above. Those people have given zero thought to design, maintainability, organization, reduction of duplication in code, coupling, cohesion, encapsulation, etc. They write crap. Those people exist programming in every language, and easy to learn languages with many ways to do things give them plenty of rope and guns to shoot and hang themselves with. Simultaneously.

But if you hang around the Perl world for longer than a cursory look, and watch what the long-timers in the community are doing, you see a remarkable thing: the good Perl programmers spend some time seeking to find the best way to do something. When they're naming a new module, they ask around for suggestions and bounce their ideas off of people. They hand their code out to get looked at, critiqued, and modified. If they have to do something nasty, they encapsulate it in the smallest way possible in a module for use in a more organized way. Several implementations of the same idea might hang around for awhile, but they compete for mindshare and marketshare, and they compete by trying to do the best job, and a big part of that is by making themselves easily maintainable. Really good Perl programmers seem to think hard about what they are doing and looking for the best way to do things, rather than just grabbing the first idea that flits through their brain.

如今，我主要在Java世界中编程。我见过一些非常好的Java代码，但我也见过很多垃圾代码，而且我还看到了更多我在开头描述的心态:人们选择了第一个看起来可以工作的丑陋代码块，而不理解它，也不考虑是否有更好的方法。

You will see both mindsets in every language. I'm not trying to impugn Java specifically. (Actually I really like it in some ways ... maybe that should be my real controversial opinion!) But I'm coming to believe that every programmer needs to spend a good couple of years with a TMTOWTDI-style language, because even though conventional wisdom has it that this leads to chaos and crappy code, it actually seems to produce people who understand that you need to think about the repercussions of what you are doing instead of trusting your language to have been designed to make you do the right thing with no effort.

我确实认为你可能会在另一个方向上走得太远:例如，完美主义完全忽略了你的真正需求和目标(通常是你的业务的真正需求和目标，通常是盈利能力)。但我不认为任何人都能成为一个真正伟大的程序员，除非学会投入一些高于平均水平的努力来思考寻找最好的(或至少是最好的一种)方法来编码他们正在做的事情。

如果开发人员写不出清晰、简洁、语法正确的注释，那么他们就应该回去补习英语。

我们有开发人员和(可怕的)架构师不能连贯地编写。当他们的文件被审查时，他们会说“哦，不要担心语法错误或拼写错误——那不重要”。然后他们想知道为什么他们复杂的垃圾文档变成了复杂的bug代码。

我告诉我所指导的实习生，如果你不能口头或书面表达你的伟大想法，那就不如没有它们。