使代码持久化的提示[关闭]

避免你最近读到的和想的任何事情,

这是一个有趣的语言特性、设计模式等。 我想这对我有帮助 降低我的代码复杂性。

因为某种原因,这以后总是会咬我。最好是将它放在侧边项目中,然后在产品代码中使用,一旦它被证明是一个好主意,而不仅仅是看起来像一个。

比特旋转…

在编译一个旧项目时,我经常遇到的问题是

• 缺少依赖项-最好列出您所依赖的任何库,包括从中获取的URL。您的包含路径可能与5年前不同!
• 编译器更改——这些通常不太麻烦,并且通常可以用C/C++定义固定在C/C++中。
• 数据大小的变化-当从16位移动到32位时,这是一个令人讨厌的变化。尽量不要假设变量的大小。
• 神秘的构建过程-对于某些项目,可能存在一些用于构建资源、库等的模糊构建步骤。请确保这些步骤都有良好的文档记录。
• 过于聪明的代码——我见过假定机器内存小于x兆字节的代码,因此使用指针的顶端来保存数据。别那样做!
• 错误检查-当事情确实中断时,良好的错误检查将帮助您找出为什么会更快。

有时,使代码持久化的关键不在于尝试在前面构建一些具有永恒耐用性的杰作,而在于继续做真正的 有用的 . 甚至可以接受预先做出某些假设,只要它们都有清晰的文档记录,可能通过注释、断言或单元测试。这提醒了我:编写大量的单元测试,以便随着代码的发展,关于它应该如何工作的假设会不断地被测试。

不要以为你写的任何东西都会一直保持不变。依赖于不断的重构,集中精力尽可能地简化重构。

我发现以下提示很有用:

1. 使用有意义的变量/成员/类/函数名,即使您的手指因键入而受伤。

2. 准确、简洁地评论每个类和函数、过程(除非它是样板文件,例如set/get方法)。如果这不可能或不容易,那么您的函数/子函数可能太复杂。

3. 保持功能/程序小-5-10行。这有助于使它们易于验证、测试、调试、记录和使用。

4. 当您检查您的代码(通常是在错误修复或进一步开发过程中)时,如果有什么事情使您感到不快,请记录问题或修复它。通常,稍后您会发现一个bug并将其关联起来,或者您将以违反这些假设的方式使用代码,文档将帮助您。

5. 记录你一整天所做的更改。当您保存到存储库时,您可以将日志的一部分从上一次保存剪切并粘贴到当前位置,这样您的代码存储库更改就会得到良好的记录。单独保存日志(存储库、电子邮件、博客)。

6. 将代码分解为独立的、可重用的组件。在过度工程、亲吻和泛化之间有一条细线,因此您必须权衡赞成和反对。制造可重用组件的好处在于,您倾向于更好地设计组件,以做出很少的假设、拥有干净的接口、具有很少的依赖性——所有这些都有助于更好的代码。此外,可重用组件在更多的地方得到使用,因此代码往往得到更好的测试。

7. 在代码可能失败的地方抛出异常或使用断言,这取决于如何调用它,即参数传递或依赖于函数/过程的任何外部因素。”“从不发生”只有理论上存在——例外使缩小bug变得容易得多。

8. 为需要做的事情或作为日志一部分的增强保持一个正在运行的TODO列表/bug列表。很可能这个列表永远不会完成,因为只要你能尽快完成列表上的项目,新的项目就会被添加。在某种程度上,列表将由低优先级或可延期的项目组成,您将转向生产或新版本。Word工作了多少年,现在完成了吗?

对我来说,这很像发送电子邮件或任何通信。

代码“完成”之后,我将重新阅读它,并在脑海中浏览所有场景。

之后是测试。

我所见过的最好的开发人员可以看完代码,把所有基本的东西都删掉。然后通过单元测试解决更多的问题。

还有,评论。我认为在汇编编程中,他们谈论的是“写一次,不读”的代码。如果不注释程序集代码,则无法维护它。HLL需要有用的注释。

在我看来,让程序发展并没有错。曾经有一段时间,我总是想预见每一个可能的变化,但我知道,大多数时候,这是不可能的。然而, 抽象化 比实现细节更持久。所以我的秘诀是 分离 您的应用程序尽可能多地 组件 (类和函数),接口尽可能抽象(隐藏实现细节)。这样,当某些事情必须改变时(不可避免地会发生),改变很可能被隔离在源代码的一小部分中。

我试着记住以下几点:

• 这段代码可能比任何人预期的要长得多,也可能比任何人预期的要短得多(我离开了一个项目,他们完全用不同的语言重新编写了我的应用程序——但是新开发人员很高兴,因为我留下了大量的评论!)
• 如果您返回到您的代码,您将发现它是可怕的。总是这样。在你忘记它是如何工作之前发表评论。
• 意识到别人会看你的代码,因为你没有很好地遵循OOP,所以认为这是垃圾代码,然后重构你的整个代码。然后,重构这个东西的人会来找你帮忙,因为它不起作用,你会发现为了可靠的原则而重新编写的人完全删除了应用程序的所有功能,这就是你最初破坏可靠原则的全部原因(抱歉,这是一个咆哮…)。

不管怎样,我想补充一句 很多评论 .注释可以解决上述所有问题,并使代码的使用时间更长。我建议你在冗长的方面犯错。

看看坚实的原则。例如 Getting a SOLID start .