这篇文章不是建议,而是对我有效的方法。
养成坏习惯很容易,但培养好习惯却很难。记录下对我有效的方法可以帮助我保持我努力培养的任何好习惯。以下是10个无序列表,这些方法帮助我提高了速度,并在我目前开发的产品中保持了令人尊敬的质量水平。
保持提交足够小,以至于你会怀疑自己是否把"保持提交小"这件事做得太过了。你永远不知道什么时候需要回滚某个特定的更改,当你知道六天前在哪里引入了一个bug并且只需要回滚那个提交而不用经历合并冲突的痛苦时,会有一种幸福感。我的经验法则是:可编译的软件就应该可以提交。
践行Kent Beck的 智慧箴言[1] :"对于每个期望的改变,先让改变变得容易(警告:这可能很难),然后再进行这个容易的改变"。争取至少一半的提交是重构。持续重构就是思考我可以在10分钟内完成的改进。这样做的好处是,当一个更大的需求出现时,你会发现自己只需要做一个小改动就能满足它,这正是因为那些较小的改进。大规模重构是个坏主意。
所有代码都是负债。未部署的代码是负债中的死神。我需要知道它是否有效,或者至少不会破坏任何东西。测试给你信心,生产环境给你认可。虽然频繁部署可能会增加一些托管成本,但与知道你最后做的事情确实是进步的标志相比,这是一个小代价。 敏捷原则[2] 之一说,"工作的软件是进步的主要衡量标准"。在这句话中,"工作"和"进步"承担了很多重任,所以我为自己定义了它们。工作是指某些东西足够好可以部署,如果它是为某个功能做贡献的代码,那就是进步。
知道什么时候你在测试框架的能力。如果是这样,就不要这么做。框架已经被比你懂得多得多的人测试过了,你必须相信他们
useState()钩子会按预期工作。如果你保持组件小巧,那么你就减少了对大量测试的需求,因为框架将在组件中完成大部分繁重的工作。如果组件很大,那么你就引入了更多的复杂性,现在你需要编写大量的测试。如果某个特定的函数不适合任何地方,为它创建一个新的模块(或类或组件),你以后会找到它的归宿。创建一个新的独立结构比将它硬塞进一个你深知不合适的现有模块要好。最坏的情况下,它作为一个独立的模块存在,这也不是太糟糕。
如果你不知道API应该是什么样子,先写测试,因为这会迫使你考虑"客户",在这种情况下就是你自己。你肯定会发现一些情况,如果你先写代码后写测试,你是不会想到的。你不必对TDD太过教条,可以在更大的批次中工作(例如,在使其通过之前写多于几行代码)。处于红色/失败状态下要写的代码量不一定总是很小。你知道你在做什么,不要让教条妨碍生产力。
复制粘贴一次是可以的。第二次你引入重复(即三个副本)时,就不要这样做了。你应该有足够的数据点来创建一个足够好的抽象。在这一点上,不同实现之间出现分歧的风险太高了,需要进行整合。有一些奇怪的参数化比有多个几乎相同的实现要好。如果这种情况再次出现,改进参数会比整合四种不同的实现更容易。
设计会过时。你可以通过重构来减缓它们过时的速度,但最终你需要改变事物的运作方式。不要对放弃一些曾经对你很重要、你曾为之感到自豪的东西感到太难过。你当时做了正确的事,不应该因为没有做得足够好而不需要改变任何东西而责备自己。大多数时候,编写软件就是改变软件。接受它并继续前进。没有所谓的完美设计,变化是软件开发的核心。你改变事物的能力就是你在软件开发方面的能力。
技术债务可以分为三种主要类型:1)现在阻止你做事的东西,2)以后会阻止你做事的东西,3)以后_可能_会阻止你做事的东西。其他所有分类都是这三种的子集。尽量减少#1类的数量,试图专注于#2类。忽略#3类。
可测试性与良好的设计相关。某些东西不容易测试暗示设计需要改变。有时候那个设计是你的测试设计。举个例子,如果你发现很难模拟
em.getRepository(User).findOneOrFail({id}),那么你要么需要将该调用放入一个可以被模拟的独立函数中,要么编写一个测试工具,允许更容易地模拟实体管理器方法。测试之所以没有被编写,是因为测试很难,而不是因为你不想测试。
可能还有很多,但10是个不错的数字。
参考链接
- 智慧箴言: https://x.com/KentBeck/status/250733358307500032?lang=en
- 敏捷原则: https://agilemanifesto.org/principles.html
