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

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

嗯,这是一个有趣的语言特征、设计模式等。 降低我的代码复杂性。

出于某种原因,这总是会在以后对我产生影响。最好把它放在副项目中,然后在证明是个好主意后在生产代码中使用,而不是仅仅看起来像个好主意。

我在编译旧项目时最常遇到的问题是

• 编译器更改-这些通常不会太麻烦,通常可以用C/C++中的#define来修复++
• 数据大小变化-从16位移动到32位时,这是一个令人讨厌的变化。尽量不要对变量的大小做出假设。
• 神秘的构建过程——对于某些项目,构建资源、库等的构建步骤可能很模糊。确保它们有很好的记录。
• 过于聪明的代码——我见过一些代码假设机器的内存小于X兆字节,因此使用指针的顶部来保存数据。不要做那种事!
• 错误检查-当事情确实发生故障时,良好的错误检查将帮助您更快地找出原因。

有用的 。甚至可以预先做出某些假设,只要它们都有明确的记录,也许是通过评论、断言或单元测试。这提醒了我:编写大量的单元测试,这样随着代码的发展,关于它应该如何表现的假设就会不断被测试。

不要想当然地认为你写的任何东西都会随着时间的推移而保持不变。依靠不断的重构,并专注于使其尽可能简单。

我发现以下提示很有用:

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

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

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

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

6. 将代码分解为独立的、可重用的组件。在过度工程、KISS和泛化之间有一条细线,所以你必须权衡利弊。制作可重用组件的优点是,你倾向于更好地设计组件,减少假设,拥有干净的接口,减少依赖关系——所有这些都有助于更好的代码。此外,可重用组件在更多地方得到使用,因此代码往往得到更好的测试。

7. 根据调用方式,在代码可能失败的地方抛出异常或使用断言,即传递给函数/过程的参数或对任何外部因素的依赖性。“永远不会发生”只存在于理论中——例外情况使缩小错误范围变得容易得多。

8. 将需要完成的事情或增强功能的待办事项列表/错误列表作为日志的一部分。这个列表很可能永远不会完成,因为你会尽快完成列表上的项目,并添加新的项目。在某个时候,列表将由低优先级或可推迟的项目组成,您将进入生产或新版本。word已经开发了多少年,现在完成了吗?

代码“完成”后,我将重新阅读并遍历我脑海中的所有场景。

之后是测试。

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

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

在我看来,让程序进化并没有错。曾经有一段时间,我总是想预见每一个可能的变化,但我了解到,大多数时候,这是不可能的。然而, 抽象 分开 你的应用程序尽可能多地变成很多 组件 (类和函数),接口尽可能抽象(隐藏实现细节)。这样,当必须更改某些内容时(这不可避免地会发生),更改可能会被隔离在源代码的一小部分中。

我试着记住以下几点:

• 代码的寿命可能会比任何人预期的都长,也可能比任何人期望的都短(我曾经离开过一个项目,他们用另一种语言完全重写了我的应用程序——但新开发人员很高兴,因为我留下了大量的评论!)
• 如果你回到你的代码,你会发现它很可怕。总是这样。在忘记它是如何工作的之前发表评论。

无论哪种方式,我都会补充 很多评论 注释将解决上述所有问题,并使代码持续更长时间。我建议在冗长的方面犯错。

Getting a SOLID start .