我的软件开发中经验教训

作者：追梦1819
原文：https://blog.csdn.net/weixin_39759846/article/details/116780540
版权声明：本文为博主原创文章，转载请附上博文链接！

楔子

本文是在在软件开发中的一些经验总结。有的看似很神奇，没有科学依据，但是在使用时确确实实有效果。

本文目的，一为记录，二为分享给后来者。

另，文中图片源自网络，与内容无关，仅供娱乐，精髓在于文字。

正文

开发

1.由易及难，由小及大

无论是一个新项目还是一个二次开发的项目。我总是从一个最简单的版本或者功能开始，然后逐步延伸，直达达到预期目的为止。

项目开始时无法详细计划所有事情。取而代之的是，我在学习的过程中学习了这些新发现的经验教训，并在后续方案中使用它们。形成一个螺旋上升的趋势。

我喜欢约翰·加尔（John Gall）的话： “我们会发现，一个有效的复杂系统，总是从一个有效的简单系统演变而来的。”

2.学会拆分

我们在开发时，某些测试失败或某个功能失效时，如果仅更改一件事，发现问题就容易得多。换句话说，就是使用短迭代。

做一件事，确保它起作用，然后重复。这同样适用于每次提交代码的场景。如果必须在添加新功能之前重构代码，请首先提交重构，然后（在新提交中）添加新功能。

3.尽早添加日志记录和错误处理

在开发新系统时，我要做的第一件事就是添加日志记录和错误处理，因为两者从一开始就非常有用。

对于较大的功能或者系统，我们需要某种方式来了解程序中会发生什么。也许它无法按预期运行时，但是一旦无法按预期运行，我们就必须能够看到正在发生的事情。

错误处理也是如此，错误和异常也从一开始就发生，因此我们越早以系统的方式处理它们就越好。

4.所有新代码必须至少执行一次

在完成一项功能之前，我们必须对其进行测试（单元测试）。否则，如何知道它已经达到了预期？

通常，最好的方法是通过自动测试，但并非总是如此。但是无论如何，每行新代码都必须至少执行一次。

有时很难触发正确的条件。但是，我们可以手动制造一些异常。例如，可以通过暂时拼写错误的列名来检查对数据库调用的错误处理。或者，可以暂时将if语句反转（“ if error”变为“ if not not”），以触发很少发生的事情，只是确保代码已运行并且应执行应做的事情。

有时我会看到一些错误，这些错误表明开发人员永远都不可能运行特定的代码行。审查时看起来不错，但上线后仍然无法正常工作。

如果我们始终测试了每一行新写的代码，则基本上可以避免上述问题。

5.整体测试组件

经过良好测试的组件可以节省时间。集成不同的组件时经常会出现问题，例如模块之间的接口不匹配或理解不正确。如果每个组件可以按照预期工作，那么查找集成问题将变得更加容易。

6.一切花费的时间比想象的要长

特别是在编程中。即使一切进展顺利，也很难估计功能将花费多少时间。但是，在开发软件时，遇到意外问题是很常见的：简单的合并会导致细微的错误，升级框架意味着必须更改某些功能，或者API调用无法按预期进行。

我认为霍夫施塔特定律很有道理：即使考虑到霍夫施塔特定律，它也总是比您期望的更长。

7.首先了解现有代码

大多数编码都需要以某种方式更改现有代码。即使它是一项新功能，也需要适配现有程序。并且，在将新内容放入其中之前，我们需要了解当前的解决方案。否则，可能会意外破坏某些现有功能。

这意味着阅读代码是与编写代码一样必要的技能。这也是看似小的更改仍需要较长时间的原因的一部分-必须了解进行更改的环境。

8.阅读并运行

阅读并运行，幸运的是，有两种互补的方法可以理解代码。可以阅读代码，也可以运行代码。

在弄清楚代码的功能时，运行代码可能会提供很大的帮助。确保同时使用这两种方法。

故障排除

9.总是会有bug

我不喜欢所谓“第一时间正确”的软件开发方法。无论我们投入多少精力，总会有bug（bug的定义几乎是：“我们没有想到这一点”）。更好的方法是定位一个可以使我们快速解决问题，修复错误并部署修复程序的系统。

10.解决故障报告

每个开发人员都应将一部分时间花在处理客户的故障报告和修复错误上。

它使我们可以更好地了解客户真正需要什么，如何使用系统，进行故障排除的难易程度以及系统的设计水平。这也是对自己的责任心的训练。我们不要错过这些好处。

11.重现问题

修复错误的第一步是重现问题。然后，请确保在添加修复程序后，问题就消失了。这个简单的规则可确保我们不会以为某件事不是问题，并确保解决方案确实按照我们的方案去实现的。

12.修复已知的错误

修复完已知问题后，然后看看还剩下什么问题。

有时我们会遇到一些其他问题。不同的bug可能相互影响，并引起奇怪的事情发生。不要尝试解决在这些情况下会发生的情况，而是要解决所有已知问题，然后查看仍然存在哪些现象。

13.假设没有巧合

在进行测试和故障排除时，请不要相信巧合。我们更改了计时器，现在系统重新启动的频率更高。不是巧合。

添加了新功能，但不相关的功能变慢了吗？不是巧合。而我们要做的事，要调研原因。

14.与时间戳相关

在进行故障排除时，请使用事件的时间戳作为辅助名称。例如，如果系统重新启动，并且在大约3000毫秒之前发出了请求，则可能是计时器触发了导致重新启动的操作。

合作

15.面对面办公效率最高

在讨论如何解决问题时，有面对面视频，通话，聊天和电子邮件。不过我的经验来讲，面对面讨论的方案和效率最好。

16.学会请教

当我们遇到困难时，应去找同事并向他们解释问题。

很多时候，即使我们同事不回复，但是在我们描述问题时，可能会意识到问题出在哪里。听起来像魔术，但经常会出奇的效果。

17.咨询

读代码和运行代码，通常对于弄清代码的功能和工作方式非常有用。但是，如果我们咨询一个很厉害的人（也许是原始作者），也可以弄清楚我们的疑问。

18.分享他人对你的帮助

在讨论问题或者业余聊天时，尽量多提及别人对你帮助，包括给你解决问题的思路甚至灵感。

其他方面

19.试试看

如果不确定某个语言功能的工作方式，我们可以先编写相同的Demo。测试正在开发的系统时也是如此。

如果将此参数设置为-1，会发生什么？重新启动系统后，如果该服务关闭，会发生什么情况？探索它的工作原理–-随便摆弄经常会发现错误，同时也加深了您对系统工作原理的理解。

20.在睡眠中"解决"问题

如果我们正在解决一个难题，且没有任何思路时，我们可以好好睡一觉。这样，即使没有积极考虑问题，潜意识里也可能可以解决该问题。有时候可以发现，第二天的思路比前一天更加开阔。

21.改变

不要害怕偶尔改变角色或工作。

与不同的人，不同的产品或不同的公司一起工作很令人兴奋。

在我看来，太多的人年复一年地被动地呆在同一份工作中，只有在被迫离开时才改变。

22.持续学习

软件开发者的一大优点是，学习能力强。这是由于职业因素导致的。因为，对于这样一个行业，必须得保持持续学习的习惯，不然很容易被淘汰。