其他人都在使用最新最好的技术，而我的团队是唯一一个使用劣质过时工具的人。(除了神秘的cobol恐龙)

My co-workers were/are producing supposedly bad code because they sucked/suck. It took me a while to learn that I should first check what really happened. Most of the times, bad code was caused by lack of management, customers who didn't want to check what they really wanted and started changing their minds like there's no tomorrow, or other circunstances out of anyone's control, like economic crysis. Customers demand "for yesterday" features because they are stupid: Not really. It's about communication. If someone tells them it everything can really be done in 1 week, guess what? they'll want it in 1 week. "Never change code that works". This is not a good thing IMO. You obviously don't have to change what's really working. However, if you never change a piece of code because it's supposedly working and it's too complex to change, you may end up finding out that code isn't really doing what it's supposed to do. Eg: I've seen a sales commission calculation software doing wrong calculations for two years because nobody wanted to maintain the software. Nobody at sales knew about it. The formula was so complex they didn't really know how to check the numbers.

这很尴尬，但很长一段时间以来，我一直认为嵌套方法调用或进行多个方法调用比在c#中创建一个变量来存储每个方法调用的值更节省内存。

我相信创建程序就像在课堂上教的一样……你和一群人坐在一起，讨论一个问题，想出一个解决方案，等等。相反，现实世界是“这是我的问题，我需要解决它，开始”，十分钟后你又遇到了另一个问题，让你没有真正的时间来有效地计划解决方案。

以某种方式，一个运营大量相当高调/高流量网站的公司实际上知道他们在做什么。结果他们在很大程度上毫无头绪，而且非常幸运地处于他们所处的位置。所以我想寓意是，

可靠的软件工程和最佳实践=业务成功

还是……

大多数关键的软件系统==垃圾

除了插入/冒泡排序之外，任何事情都是非常简单的黑魔法。