设计软件系统需要权衡,很难做出权衡决策。 您总是觉得自己正在失去一件事或另一件事,但这不是我们今天要谈论的。
我们将谈论几乎总是双赢的小事情。 当我找到一个在所有方面都是双赢且没有缺点的解决方案时,我是最快乐的。 在设计系统时,这是您的首要任务。 寻找一些降低复杂性的优雅解决方案。
基于我自己的错误,代码审查以及阅读他人代码的经验,我试图列出一些人们在编写代码时通常不会关注的双赢局面。 人们通常同意这些事情,但是他们肯定不会像以前那样行事。
通过您的行动跟踪您认为的代码质量
在大多数情况下,除非人们自己必须这样做,否则人们不会不同意某件事。 例如,如果您与大多数人谈论编写小型方法,您甚至都不会找到一个不同意的人,但是如果您查看大多数书面代码,您会发现人们不会像他们相信小型方法那样行动。 因此,请注意自己的想法以及实际行为 。 这将帮助您以切实可行的方式实际进行改进。
测试驱动的开发
大多数情况下,测试是通过说它们将捕获回归来出售的,以后您可以更改代码,而不必担心某些事情会破裂以及它的正确性。
但是我认为进行测试驱动开发的最大价值是设计正确的东西。 如果您只专注于在编写实际代码之前最小化编写测试并使它们更简单,则您将意识到您的设计是自动正确的,并且您已经掌握了大多数被认为是好的东西。 像定义良好的小型方法,组织良好的依赖项,更少的耦合以及没有全局状态等。因为所有这些事情都很难测试。
专注于编写简单,较小和简洁的测试,其他所有后续工作。
小型方法/功能
承认这很困难,但要自动执行此操作是一种可学习的技能。 一旦您擅长了,那么很多事情就会变得简单。
描述性变量名称
在计算机科学中只有两件难事:缓存无效和命名。
—菲尔·卡尔顿
这当然是正确的,并且有很大的不同。 使用变量表示概念。 不要将变量用于非显而易见的事情,例如在特殊情况下返回-1。 对具有良好描述性名称的变量具有一致,严格的含义。 正确使用具有单个含义的null。 练习这意味着您将自动编写更好的代码。
这是一篇很好的文章,有一些建议。 ( 20个更好命名的技巧 )
这些都是可以永久改善的事情,一旦您不知不觉地做到,就不会花费很多时间。
欢呼和快乐的编码!
From: https://hackernoon.com/software-design-principles-doing-little-things-right-md203y02