⭐⭐⭐ Spring Boot 项目实战 ⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》 《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》 《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》 《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》 《Java 面试题 + Java 学习指南》

摘要: 原创出处 网络 「Jake Rocheleau」欢迎转载,保留摘要,谢谢!


🙂🙂🙂关注**微信公众号:【芋道源码】**有福利:

  1. RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表
  2. RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址
  3. 您对于源码的疑问每条留言将得到认真回复。甚至不知道如何读源码也可以请教噢
  4. 新的源码解析文章实时收到通知。每周更新一篇左右
  5. 认真的源码交流微信群。

软件开发工作充满了挑战性。人无完人,对于程序员来说,写出有 bug 的代码是在所难免的。有些人很淡定,也有一些人会感到生气、沮丧、不安或气馁。在修复 bug 的过程中我们都经历了什么?这个值得我们一探究竟。

本文列出了程序员在修复 bug 时可能会说的一些话或者想法。我敢说很多程序员都曾经历过编程的艰辛,但在事后都会一笑而过。

1. “我不知道该把它删掉还是该重写”

看着旧代码,你总有一种想要重写它们的冲动。丑陋的逻辑语句和啰嗦的语法极大降低了代码可读性!但是,如果代码跑得好好的,为什么要去修改它们呢?我经常会陷入这样的两难境地,而且我相信这也困扰着很多其他程序员。

2. “我先到 GitHub 上找个框架”

我想大多数人都知道 GitHub,这个网站每天都会有很多开源项目发布出来。开发者们加入这个网站,给已有的项目拉取分支,在 wiki 上讨论,或者创建自己的代码库。网站提供了很多很好的插件和模板,可以被用在各种各样的项目中。

3. “为什么这个脚本要用这么多库?”

如果你要使用热门的编程语言,比如 Java 和 Objective-C,那么项目依赖库的数量会变得非常大。在采用一个需要大量依赖项的框架时这一点就变得非常明显。一些 JavaScript 插件也需要大量的额外文件。有时候这些杂乱的东西会让人厌烦,但至少它们是可以用的!

4. “网上一定能找到解决方案”

在碰到难题时,我的第一反应是上网。很多程序员会在论坛上问问题,这些问题最终会得到解答。谷歌非常善于挑选与你的问题相关的关键字,并为你提供这些有用论坛帖子。但可惜的是,有时候对于某个特定的问题并没有太多的信息。

5. “这个功能有没有对应的插件?”

为什么要重复发明轮子呢?要扩展用户界面、程序或网站,插件是一种很好的方式。另外,插件还能提供定制化功能。如果找不到相应的插件,为什么不自己开发一个?

6. “网站没问题,就怕遇到 IE”

在 IE 中渲染网页给我们带来了很多考验和磨难,这个就不用多说了。从 IE 5.5 到 IE 9/IE 10,人们一直在为获得更好的浏览器支持而做着艰苦卓绝的斗争。Web 开发人员可能很担心网页调试,因为在 IE6 中打开一个网页可能就是一场噩梦。值得庆幸的是,那些日子正慢慢成为过去。

7. “这条逻辑语句的逻辑性不是很强”

if/else 循环、for 循环、while 循环、do 循环,这些都是逻辑语句,除了这些之外还有很多。在阅读示例代码时,我会反复回想我代码里的逻辑应该怎样写更好。大量的非运算符和比较符号会让你晕头转向。所以,我会经常回头去修改之前写好的逻辑。

8. “半小时写的函数,花两个小时调试”

你一股脑儿写了一个函数,然后函数输出了一个致命的错误。为了找到问题所在,你不得不把其他代码删掉,只留下出问题的那几行代码。当你最终找到问题并把它修复,你会感到筋疲力尽,但同时也松了一口气。

9. “在看了几篇文章之后,我才意识到之前的做法是错的”

我通常喜欢用自己的方式做事,但如果事情没有按照原计划进行,可能就会有麻烦。有好多次,我开始一个项目遇到了麻烦,然后开始在网上搜博客寻找解决方案。最后我发现我的方法是错误的,重新开始也许会更容易些!所以,在一开始先做一些调研,从长远来看肯定会节省时间。

10. “StackOverflow 上好人多,他们会帮我的”

我已经记不清有多少次是通过 StackOverflow 解决难题的。这个社区有很多有才又友好的人,如果你愿意寻求帮助,他们就会帮助你。在所有的在线社区中,StackOverflow 无疑是能够提供最广泛支持的地方。

11. “少了右括号,麻烦一大堆”

调试代码就是跳来跳去,向前两步,后退一步,再向前两步,如此往复。花上几个小时盯着代码看,查找函数名或变量作用域中的错误,最后却发现少了右括号,那种感觉很怪异。所有的时间都浪费在了一个很小的语法错误上,感觉自己真是个天才,也是个傻瓜。

12. “休息一下”

有时候你需要站起来,离开显示器一会儿。在敲了几个小时的键盘之后,休息一会儿肯定有助于你思考。大多数的健康指南建议每 30 到 60 分钟休息一次,但这完全取决于你的需要。如果总是在半途中断,你可能也会感到恼怒。

13. “手头的项目先停下,稍后再继续”

除了离开电脑,这是另一种休息方式。或许你还有其它工作可以做,那就去做吧。这是一种更好的分配时间和资源的方式,特别是如果你已经花了 5 个小时还解决不了一个问题的时候。

14. “有没有能够激发我编程能力的古典音乐?”

有一种观点认为,在植物生长的初期,播放古典音乐有助于植物的生长。我个人很喜欢古典音乐复杂的音符和音乐理论。爵士乐、钢琴、大乐队,古典音乐在人类文化中都占有一席之地。那么,在编程时听音乐真的能让你在调试代码时变得更聪明吗?可能不会,但希望它也不会让你变得更笨。

15. “或许现在是检验鲍尔默巅峰理论的好时机”

我想很多人都知道鲍尔默巅峰理论:

https://xkcd.com/323/

该理论认为,程序员在摄入一定数量的酒精后,其编码能力将达到巅峰。这是由史蒂夫·鲍尔默的古怪行为引起的,它可能只是一个酒鬼的胡言乱语。不过这有点讽刺,因为鲍尔默在微软并不是一名程序员。我想我们得等别人来试验一下这个理论。

16. “谁动了我的代码?”

这听起来就像是一种妄想症,但有时你不得不怀疑,正当你忙着补觉时,是谁在写了这些代码。过去几周或几个月忙的项目让你感到沮丧。有时候你会不记得自己往代码库里添加过东西——甚至是上周刚刚查看过的项目!

17. “我不知道这是什么意思”

最糟糕的情况是,你一边阅读源代码,一边不知道该做点什么。可能是你自己的项目,也可能是其他人的项目,但问题是一样的。现在,你必须决定是花更多的时间查找替代方案,还是花时间分析脚本,把它看懂。

18. “我要在谷歌上搜一下这个错误消息”

在做了多年 PHP 开发之后,我不得不说谷歌是我的好朋友。如果你使用的是其它编程语言,比如 Objective-C、C++、Java、Python 等,应该也会有同样的体会。错误消息试图为我们提供帮助,但除非你已经记住了各种错误代码的含义,否则它们看起来更像是经过翻译的计算机语言。值得庆幸的是,网上有很多内容可以帮助我们确定这些错误消息到底是什么意思。

19. “今天应该到此为止,但我真的很想解决这个问题!”

我们都知道,当你想要放弃一件事情,会有一种挫败感,同时又觉得放弃并不是正确的选择。你希望继续前进,并尝试新的解决方案。但如果你发现你又因此浪费了一个小时呢?我经常遇到这种情况,这让人感到非常沮丧。

20. “天哪,我为什么没写注释?”

在写前端 HTML/CSS/JS 代码时,并不总是需要写注释。但对于复杂一些的脚本和程序,就需要某种类型的注释,以便你在几个月后甚至几年后回过头来查看。有时候你会忘记给函数及其参数、输出格式和其他基本数据添加注释。当出现错误时,你需要调试整个脚本才能找到解决方案时,这无疑会给你添乱。这个时候你就会想,如果当初加一些有用的注释就好了。

21. “刚才它还能运行……”

开发程序最令人感到沮丧的,可能是什么都没做——既没有更新,也没有修改代码——程序却突然不能正常运行了。我发誓,这种事请经常发生。也许是因为其他程序正在运行旧的版本?有时候,更新一小段代码就会导致整个程序崩溃,然后只能恢复到最近的可运行版本,并从那里接着往下开发。

22. “就因为忘记加个分号,整个程序都崩溃了”

我用过的每一种编程语言几乎都需要行终止符,当然并不是所有的都需要,但 C/C++ 族编程语言通常是这样的。如果你忘记添加结束分号,只是一个无心的错误,但解析器不理解这一点,它会无情地抛出一个致命错误。然后,你必须再花 20 分钟来查看代码,最后你发现缺少了一个分号。也许这就是调试的“乐趣”。

23. “我想知道如果请人来修复我犯下的错误要花多少钱?”

聘请其他开发者来修复问题,这种想法很诱人,但显然财务上不允许。另外,如果你不亲自动手,怎么能从这些错误中吸取到教训呢?在经历了多次失败之后,当你最终对一个编程概念有了透彻的理解,你才会感觉良好,但这并不能阻止我的脑子里出现想要聘请更多人的想法。

24. “快速浏览一下 Hacker News 肯定能提高工作效率”

很多程序员喜欢在 Hacker News 上了解与软件及初创公司相关的社会新闻。这个网站上有很多关于自由职业、时间管理、软件开发、新公司启动和融资的信息。虽然浏览这个网站会给你带来高效的感觉,但它也在消耗你的时间。每隔几个小时休息一下,趁这个时候去看看新闻或许会更好。

25. “这个 API 怎么能没有文档!”

如果你使用的插件或框架没有文档,那么最令人感到沮丧的是你必须自己深入查看它们的源代码。我喜欢那些开发人员会花时间专门设计文档的项目。文档解释了所有可用的参数和选项,甚至可能还会提供一些示例代码片段。但遗憾的是,并不是所有的项目都会这样。最简单的方法就是远离那些没有详细文档的项目,这样你就不会那么痛苦了。

26. “我多么希望给数据库做过备份……”

在开发和调试代码时,我并不总是会想到给数据库做备份。但是,数据备份提供了一个保障,在做出某些变更之前可以及时回退。记住,请在本地保留网站项目文件和数据库的副本,以备不时之需!这可能是一项烦人的任务,但绝对没有重建被损坏的 SQL 数据库那么烦人。

27. “要解决这个问题,最快的方案是什么?”

在经过了几个小时毫无头绪的工作之后,很明显,你可能需要尝试一种新的方法。在设计接口之前,程序员希望先让功能正常运行起来。确定最快速、最准确的解决方案,并保证 100% 的时间都可以正常运行,然后继续做那些锦上添花的东西。

28. “我打赌,更新新版本就可以解决这个问题”

负责管理编程语言依赖项和插件的团队不需要经常发布新版本。有时候,更新 PHP/Ruby/Python/SQL 版本就可以解决将文件从本地传输到服务器时的调试问题。本地更新很少有助于修复源代码中的 bug,除非你的版本已经过时。值得一试!

29. “我应该学习 Git……但我想从下周开始”

版本控制系统 Git 在程序员中非常流行,它的学习曲线比其他竞争对手要容易些,被用于管理很多在线代码仓库,比如 Github 和 Bitbucket。开发人员之所以想要延后学习,是因为对于初学者来说,它的入门曲线非常陡峭。但是,一旦理解了它的基本命令,Git 就变得非常简单了。

30. “扔掉这个,我要从头开始”

有时候,在花了几个小时尝试某个解决方案之后,你会将工作文件移动到存档目录(或删除它们),然后从头开始。之前几个小时的辛苦工作几乎没得到有什么回报,所以做出这个决定是很艰难的。但当我陷入困境时,重新开始往往正是完成一个项目所需要做的事情。

看看,这是不是你自己?

文章目录