软件开发技巧和陋习

凑合
在日常开发中，使用或者测试中出现问题，一般都喜欢打补丁，补丁这个概念被用错了。补丁不是凑合。补丁不是简单粗暴，毫无业务逻辑性的凑合。
如果为了修复一个问题，而让你的代码变得不能体现或者表达它的业务含义或者污染了现有的代码逻辑，那么这个修复就埋下了一个日后潜在的更大的问题。
为了清晰性，为了功能的单一性，为了以后的可维护性，代码不能凑合。
陋习举例：比如业务调整，需要调用端新传入一个参数，但是为了省事，正好方法中有另外一个暂未使用的参数A，此时使用A来表示新增的参数，而A的参数名完全不是那个意思。

软件开发前提取并搞清楚核心领域对象
如果让你实现一个功能，包括增删改查，那么你非常清楚这个核心领域对象是什么吗？它业务含义是什么？什么是这个核心领域对象的属性？或者说这个核心领域对象包括的属性有哪些？
讨论需求的时候，也是如此，都要搞清楚或者把关注点放到核心领域对象建模和理解上。
比如，概念和术语都是什么含义等等。

应该给自测更多的时间和更多的关注
软件开发对过程中对于出现的设计或者开发问题，我们可以花费大量大量时间来排查，甚至推翻重来，那么为什么开发完成不进行好好自测，在自测上花点时间也能让你更加熟悉业务，因为看问题的角度变成使用者，因此自测时间要充足这个是值得的非常值得(多使用几个用例流进行测试)