成员变量不应该声明为private(在java中)

如果你声明了一些私有的东西，你就阻止了任何未来的开发人员从你的类派生和扩展功能。从本质上讲，通过编写“private”，您暗示您现在比任何未来的开发人员都更了解如何使用您的类。当你写“private”的时候，你应该写“protected”。

类永远不应该声明为final(在java中)

类似地，如果您将一个类声明为final(这将阻止它被扩展—阻止它被用作继承的基类)，那么您就意味着您比任何未来的程序员都更了解使用类的正确方法。这从来不是个好主意。你不是什么都知道。有人可能会提出一个完全合适的方法来扩展你没有想到的类。

Java bean是一个糟糕的想法。

java bean约定——将所有成员声明为private，然后为每个成员编写get()和set()方法——迫使程序员在不需要代码的地方编写样板、容易出错、冗长的代码。只要将public成员变量设为public!如果您需要更改实现，请相信您以后有能力更改它(提示:99%的情况下，您永远不会更改)。

原始数据类型是不成熟的优化。

有些语言只使用一种数据类型，即标量，它们做得很好。其他语言就没有这么幸运了。开发人员只是把“int”和“double”扔进去，因为他们必须写一些东西。

What's important is not how big the data types are, but what the data is used for. If you have a day of the month variable, it doesn't matter much if it's signed or unsigned, or whether it's char, short, int, long, long long, float, double, or long double. It does matter that it's a day of the month, and not a month, or day of week, or whatever. See Joel's column on making things that are wrong look wrong; Hungarian notation as originally proposed was a Good Idea. As used in practice, it's mostly useless, because it says the wrong thing.

小代码总是更好，但是复杂?:而不是if-else让我意识到有时大代码更可读。

观点:单元测试不需要预先编写，有时甚至根本不需要。

推理:开发人员不擅长测试他们自己的代码。我们所做的。这就是为什么我们通常有测试团队或QA团队。

大多数情况下，我们编写的代码与其他需要单独测试的代码交织在一起，因此我们最终会跳过模式框框来提供可测试性。并不是说这些模式不好，而是它们有时会增加不必要的复杂性，所有这些都是为了单元测试……

．.． 这通常是行不通的。编写一个全面的单元测试需要大量的时间。通常是我们不愿意付出的时间。测试越全面，如果测试对象的接口发生变化，就会变得越脆弱，迫使重写不再编译的测试。

计算机科学或其他IT领域的学位确实会让你成为一个更全面的程序员

我不在乎你有多少年的工作经验，读过多少博客，参与过多少开源项目。一个资格证书(我建议超过3年)会让你接触到一种不同的思维方式，给你一个很好的基础。

仅仅因为你写了一些比计算机科学学士更好的代码，并不意味着你比他更好。你所拥有的，他可以在瞬间学会反之则不然。

拥有资格证书表明了你的承诺，你会超越经验，成为一名更好的开发人员。擅长自己的工作并且有资格的开发人员可能会非常令人生畏。

如果这个答案被否决，我也不会感到惊讶。

而且，一旦你有了资格，你就会慢慢停止和其他有资格的人比较(我的经验)。你意识到到最后一切都不重要了，只要你们能很好地合作。

始终仁慈地对待其他开发人员，无论其资格如何。

vb6可以用来做好事，也可以用来作恶。在编码过于复杂的时代，这是一个快速应用程序开发环境。

我过去非常讨厌VB，现在还在嘲笑VB。NET(可能是开玩笑)作为一种Fisher Price语言，因为我不喜欢经典的VB，但在它的时代，没有什么能打败它完成工作。