作者 | Esteban Gabriel
译者 | 弯月
责编 | 仲培艺
出品 | CSDN（ID：CSDNnews）

我觉得自己没有想象中那么聪明，而且还是一个健忘的人。正因如此，我写的代码才能一天比一天好，想知道为什么吗？

在过去的九个月里，我暗暗下定决心要成为一个“更加优秀”的程序员，而且还要直面困难，迎难而上。

大约在一年半前，我开始自我改造，而上述种种只是计划中的一部分，但本文我想重点聊聊编程。

让我们来看看经过九个月的努力，我都学会了什么——

自我剖析

首先，我决定直面一个于我而言最大的挑战：我是个没有条理的人，行动前缺乏深思熟虑，而且过于自信。这些缺点加在一起简直惨不忍睹，但是一直以来我的行事风格一贯如此，而且大多数情况下日子过得还算马马虎虎，但是在我深知自己还可以做得更好。所以我决定逐个克服这些缺点。

行动前深思熟虑

以前我的表现就像一只小狗，看到主人扔出小棍子，就奋不顾身地扑上去捡。每次拿到新的需求，我会不经大脑思考就一头扎进键盘里，将我认定的解决方法写成代码。

现在，每当遇到新的需求时，我就会想起钢琴老师在课堂上对我讲过的一句话：

首先，把你的手从钢琴上拿下来，深呼吸，做好准备，然后再开始表演。

想到这句话，于是我开始在纸上或用 draw.io（有时候我用这个工具记笔记）写出解决方案的伪代码。这个过程可以让我看到各个组件之间的交互、它们的职责划分（SOLID 原则），乃至设计模式。

如果开发过程发生了变化，那么我也会相应地更新我的笔记，以符合真实的解决方案。

没有条理

我强迫自己一步一步写下为了完成任务需要做的事情。在 Jira/Trello 中创建子任务列表，在显示器上贴便利贴，或在 IDE 的文本编辑器中写详细注释。这些主要是为了检查我在解决任务时所做的每一步。

这样做的第一个好处是可以减少工作中的健忘。一般来说，开发人员都面临着很多需要完成的任何，还需要考虑很多极端例子，所以我们很容易忘记一些关键点。

如果可以向别的同事展示你为解决方案建模的方法就更好了，也许他们之中有人可以看出一些可能存在的逻辑错误或你未发现的逻辑。

一般来说，我在做完整体的构思后会立即做这一步，因为这些步骤对应着上一步中构思的组件以及各个组件的职责。

做完这些，我就有了整体的构思以及详细的工作步骤。但这并不意味着情况不会发生变化，因为系统开发中的每个过程都是迭代的，并且需要及时调整实际的实现。

健忘

对付健忘的好方法就是记下来。但你不必非要画出标准的 UML 图表，一般的 IDE 都可以在多个文件和方法之间来回切换，这样就可以轻松地遵循解决方案的流程了。但是，每个开发人员都会面临这种情况：

开发→重构→完成→过段时间/开始新功能→上次开发中的 bug→修复 bug→过段时间/继续做没做完的功能......依此类推。

支持旧功能会导致旧代码、新代码、修复 bug 的代码以及所有可能的代码之间盘根错节：你需要记住整个功能的工作原理。出于这个原因，我使用 Javadoc 或 JSDoc 在方法开头做详细注释，或者用一个简单的注释来描述这个方法的目的是什么。

如果你是为了应用程序的将来更新代码，那么也请你为了你和你的伙伴们的未来更新注释。

冒傻气

正如本文的标题所示，我的为人很有几分傻气。

我需要知道正在开发的功能的每个交互案例，这样才有了参照，我才能知道我所做的东西是对还是错。有一段时间我做了一些傻事，在游戏玩家术语中被称为“脸探草丛”，意思是说拿身体探，而不是用技能，一般来说这都是测试人员的工作。如果他们在测试环境中发现每个部署中都存在大量 bug，则意味着这些代码未经过我的测试。

有一种很让人头疼的现象是：代码中的 bug 比我需要修复的还要多。在大多数情况下，每次发现 bug 回过头去改旧功能就意味着我需要中断手头正在开发的新功能。这种上下文的切换（旧功能/新 bug 与正在开发的新功能之间的切换）真的很烦人。

所以在决定的时候，我认为最好的选择是：测试我的代码。我指的不是功能测试，功能测试肯定是要做的，我指的是技术方面的测试——单元测试和集成测试。这听起来很像废话，很多人都会回一句“那还用说嘛，这是你必须做的，这是基本规则。”但事实上，并非所有开发人员都能做到这一点。我发现测试不仅可以减少由于 bug 造成的开发中断，而且还可以验证我正在开发的解决方案的应用场景，对我来说是双赢的。

我无意宣扬代码测试的神奇，事实上测试拥有完整的体系，而且已经很多年了。我只是想告诉你，我发现测试可以提高我的编程技巧和代码质量，而且希望你也开始这么做。

首先，测试花费的时间很多，但是测试你的代码应该成为一种习惯。一旦测试成为编程工作的一部分，那么你会自动编写单元测试和集成测试。这不是魔法，只是工作，但是我可以保证你将获得丰厚的回报——bug 更少，解决方案更清晰，同时还能很好地理解你的解决方案及其在不同场景下的工作方式。

你已经掌握了一切吗？

距离心目中那个理想的自己，我还未及一半。但是每天我都会关注可以提升自我的方法。与你做分享也许对我有所帮助，我说的这些可能你心知肚明，但由于种种原因你并没有付诸行动。我也想告诉那些跟我一样在编程工作上“做傻事”的人，你并不孤单。

我将继续努力总结出更加具体的方法，因为我从中获益匪浅。我并不会在每个问题上都采用这些步骤，除了测试，因为测试是必不可少的，但是在对我、我的伙伴们以及程序有帮助的时候，我也会拟定一定的顺序，并理清需求。

最后，我想说：我们还有很多工作需要做，有很多东西需要学，还有很多挑战需要实现。

原文：https://medium.com/@garciawarneckee/because-im-dumb-i-write-better-code-f7e355722131

本文为 CSDN 翻译，如需转载，请注明来源出处。

【完】

 热 文 推 荐 

☞ IT 从业者要如何在国企「活」下去？

☞ 官宣：Linux 内核主要贡献者 Linaro「喜提」新任 CEO！

☞ 年后跳槽 BAT 必看，10 种干货帮你 Offer 拿到手软！

从倾家荡产到身价百亿，这个85后只用了8年

☞ 难逃寒冬裁员的“大追杀”，30 岁女码农该何去何从？

☞ OpenStack 2018 年终盘点

拼多多黄峥给陆奇“兼职”，欲挖掘这类AI人才

☞ 老程序员肺腑忠告：千万别一辈子靠技术生存！

print_r('点个好看吧！');
var_dump('点个好看吧！');
NSLog(@"点个好看吧！");
System.out.println("点个好看吧！");
console.log("点个好看吧！");
print("点个好看吧！");
printf("点个好看吧！\n");
cout << "点个好看吧！" << endl;
Console.WriteLine("点个好看吧！");
fmt.Println("点个好看吧！");
Response.Write("点个好看吧！");
alert("点个好看吧！")
echo "点个好看吧！"

点击“阅读原文”，打开 CSDN App 阅读更贴心！