当我们编程时，我们都会开发我们使用和依赖的实践和模式。但是，随着时间的流逝，随着我们的了解，成熟度以及技术使用的变化，我们逐渐意识到，一些曾经认为很棒的做法是不可行的（或不再适用）。
我曾经经常使用但最近几年有所改变的一种做法是使用Singleton对象模式。
通过我自己的经验和与同事的长期辩论，我逐渐意识到单例并不总是令人满意的 -它们会使测试变得更加困难（通过禁止诸如模拟之类的技术），并且会在系统各部分之间产生不良耦合。相反，我现在使用对象工厂（通常使用IoC容器）来隐藏无关紧要或需要知道的系统部分中单例的性质和存在。相反，他们依靠工厂（或服务定位器）来获取对此类对象的访问权限。
我本着自我完善的精神向社区提出的问题是：
Answers:
//Coming out of university, we were taught to ensure we always had an abundance
//of commenting around our code. But applying that to the real world, made it
//clear that over-commenting not only has the potential to confuse/complicate
//things but can make the code hard to follow. Now I spend more time on
//improving the simplicity and readability of the code and inserting fewer yet
//relevant comments, instead of spending that time writing overly-descriptive
//commentaries all throughout the code.
单返回点。
我曾经为每种方法都选择了一个返回点，因为这样做可以确保例程所需的任何清理都不会被忽略。
从那时起，我开始使用小得多的例程-因此减少了忽略清理的可能性，并且实际上减少了清理的需要 -并且发现早期返回降低了代码的表观复杂性（嵌套级别）。单个返回点的伪像-保留“结果”变量，保留标志变量，未完成情况的条件子句-使代码看起来比实际复杂得多，难以阅读和维护。尽早退出市场和采用较小的方法是可行的方法。
一言以蔽之，过度设计。
匈牙利表示法（形式和系统）。我曾经给所有内容加上前缀。strSomeString或txtFoo。现在，我使用someString和textBoxFoo。对于新来的人来说，它更具可读性，也更容易上手。作为额外的好处，保持一致很容易-camel选中控件并附加一个有用的/描述性的名称。Forms Hungarian的缺点是不能始终保持一致，而Systems Hungarian并不能真正为您带来很多好处。将所有变量集中在一起实际上并不是那么有用-尤其是对于现代IDE。
“完美”的架构
几年前，我想到了THE体系结构。从技术上尽我所能，使存在100％松散耦合的层，大量使用委托和轻量级对象。那是技术天堂。
真是胡扯。该体系结构的技术纯度使我的开发团队放慢了速度，他们追求的是完美而不是结果，而我几乎完全失败了。
现在，我们有了更简单，技术上不太完美的体系结构，并且交付率猛增。
使用咖啡因。它曾经使我保持清醒，并充满了光荣的编程情绪，其中代码从我的手指间飞奔而来，流淌着狂热。现在它什么也没做，如果没有，我会头疼。
注释掉代码。我曾经以为代码很宝贵，您不能仅仅删除自己制作的那些美丽的宝石。现在，我删除遇到的任何注释掉的代码，除非附加了TODO或NOTE，因为它太危险而无法保留。断言，我遇到了带有大量注释掉的部分的旧类，这确实使我感到困惑，为什么他们在那里：他们最近被评论了吗？这是开发环境的变化吗？为什么要执行此无关的块？
认真考虑不要注释掉代码，而只是删除它。如果需要，它仍在源代码管理中。虽然YAGNI。
#region指令的过度使用/滥用。只是一件小事，但是在C＃中，我以前会在各处使用#region指令来组织我的类。例如，我将所有类属性分组到一个区域中。
现在，我回头看看旧的代码，大部分只是被它们烦恼了。我认为大多数情况下这并不能使事情变得更清晰，有时它们只是会使您慢下来。因此，我现在改变了主意，觉得布置良好的类在没有区域指令的情况下通常更干净。
总体而言，特别是瀑布式开发的实践是编写完整且全面的功能和设计规范，这些规范和规范在某种程度上应该是规范的，然后期望这些规范的实现是正确且可以接受的。我说，我已经看到它被Scrum取代了，对此我感到很高兴。一个简单的事实是，客户需求和欲望的不断变化的性质使得任何固定的规范实际上都无用；真正正确解决问题的唯一方法是采用迭代方法。当然，并不是说Scrum是灵丹妙药。我已经看到它多次滥用和滥用。但是它胜过瀑布。
永不崩溃。
似乎是个好主意，不是吗？用户不喜欢崩溃的程序，所以让我们编写不会崩溃的程序，而用户应该喜欢该程序，对吗？我就是这样开始的。
如今，我更倾向于认为如果它不起作用，就不应假装它正在起作用。尽快失败，并显示一条错误消息。如果不这样做，您的程序将在以后的几条指令中崩溃甚至更加严重，但是由于存在一些无法描述的空指针错误，您将需要花费一个小时来调试。
我最喜欢的“不要崩溃”模式是这样的：
public User readUserFromDb(int id){
User u = null;
try {
ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
if (rs.moveNext()){
u = new User();
u.setFirstName(rs.get("fname"));
u.setSurname(rs.get("sname"));
// etc
}
} catch (Exception e) {
log.info(e);
}
if (u == null){
u = new User();
u.setFirstName("error communicating with database");
u.setSurname("error communicating with database");
// etc
}
u.setId(id);
return u;
}
现在，您不必要求用户复制/粘贴错误消息并将其发送给您，而是必须深入研究日志以查找日志条目。（由于他们输入了无效的用户ID，因此不会有日志条目。）
null或空字符串）相比，显示错误消息要好得多，对用户来说更诚实。
我认为每当我识别出设计模式时就应该应用它们。
我几乎不知道我实际上是在从外国编程语言复制样式，而我所使用的语言允许使用更优雅或更简单的解决方案。
使用多种（非常）不同的语言使我大开眼界，使我意识到，我不必将别人的解决方案错误地应用于并非属于我的问题。现在，当我看到将工厂模式应用到像Ruby这样的语言中时，我就发抖了。
强迫症测试。我曾经是测试优先开发的狂热拥护者。对于某些项目来说，这很有意义，但我已经意识到，这不仅不可行，而且不利于许多项目坚持为每个功能编写单元测试的学说。
确实，盲目地坚持任何事情都是有害的。
这是一件小事，但是：关心括号的位置（在同一行还是下一行？），建议最大代码行长，变量的命名约定以及其他样式元素。我发现，每个人似乎都比我更关心此事，因此，我随和与之共事的人。
编辑：当然，这是一个例外，当我是最在意的人（或者是能够为组设置样式的人）时。在这种情况下，我会做我想做的！
（请注意，这与没有一致的样式不同。我认为代码库中的一致的样式对于可读性非常重要。）
实用程序库。我曾经带着各种辅助方法和类进行组装，其理论是有一天可以在其他地方使用它们。
实际上，我只是创建了一个巨大的名称空间，其中包含许多功能组织不善的功能。
现在，我将它们留在创建它们的项目中。很可能我将不再需要它，而且如果需要，我可以随时将它们重构为可重用的东西。有时我会用// TODO标记它们，以便可能提取到通用程序集中。
设计超出我的编码范围。一段时间后，它变成了分析瘫痪。
使用DataSet执行业务逻辑。这将代码过于紧密地绑定到数据库，而且DataSet通常是从SQL创建的，这使事情变得更加脆弱。如果SQL或数据库发生更改，则它会滴流到数据集所涉及的所有内容。
在对象构造函数内执行任何业务逻辑。继承和创建重载构造函数的能力往往使维护变得困难。
我在1984年阅读Smalltalk时就第一次听说了面向对象的编程，但是直到1992年我使用cfront C ++编译器后，我才可以使用oo语言。我在1995年终于使用了Smalltalk。技术，并认为这将节省软件开发。
现在，我只是将oo视为具有某些优势的一项技术，但这只是工具箱中的一种工具。我的大部分工作都是使用Python进行的，而且我经常编写不是类成员的独立函数，而且我经常在过去创建类的元组或列表中收集数据组。当数据结构复杂，或者我需要与数据相关联的行为时，我仍然创建类，但是我倾向于抵制它。
我有空的时候实际上对在Clojure中进行一些工作很感兴趣，尽管我理解正确，但是它不提供oo设施，尽管它可以使用Java对象。我还不想说oo已经死了，但就我个人而言，我不是以前的粉丝。
在C＃中，_notation用于私有成员。我现在认为这很丑。
然后，我改为this.notation使用私有成员身份，但发现我在使用它时前后不一致，因此我也删除了它。
this或Me（分别为C＃和VB.NET）。IMO，这使我的代码更易于阅读和理解，尤其是当该特定范围内有四个或更多对象时。
检查异常
在纸上的一个奇妙的想法-清楚地定义合同，没有错误的余地或忘记检查某些例外情况。第一次听说时我就被卖了。
当然，实际上这真是一团糟。到目前为止，拥有像Spring JDBC这样的库，该库将隐藏的经过检查的异常作为其主要功能之一。
有价值的东西仅用一种特定的语言编码。就我而言，我相信C是有史以来最好的语言，而且我从来没有任何理由用其他任何语言编写任何代码。
从那以后，我开始欣赏许多不同的语言以及它们提供的好处/功能。如果我想编写一些小代码-快速-我会使用Python。如果我想从事大型项目，则可以使用C ++或C＃进行编码。如果我想发展脑瘤，我会用Perl编写代码。
初始化所有班级成员。
我曾经用某种东西（通常为NULL）来显式地初始化每个类成员。我已经意识到这：
像您一样，我也采用了IoC模式来减少应用程序各个组件之间的耦合。只要我可以使每个组件尽可能独立，它就使维护和零件更换变得更加简单。我还利用更多的对象关系框架（例如NHibernate）来简化数据库管理工作。
简而言之，我正在使用“微型”框架来帮助更快，更有效地构建软件。这些微型框架可以节省大量时间，而且如果操作正确，可以使应用程序的维护变得非常简单。即插即用，取胜！