七年程序员生涯，我学到的重要六课

时间如梭，不是吗？

我的编程之旅始于 2012 年，当时我还只是个 C++ 编程实习生。说实话，我根本不知道自己在做什么。即使是到了现在，这种状况依然没有改变。不过，在这个过程中，我确实学到了很多东西。

问题来了：在编程过程中，什么语言才是最重要的？

是英语？西班牙语？中文？波兰语？还是其他在工作中用来与其他人进行沟通的语言？

编程是一项团队活动。很少有出色的软件产品是完全由一个人从头到尾做出来的（CodeSandbox 算是一个，但后来 Ives 还是请了一些人），大多数产品需要一个团队来打造。

沟通技巧可以成就一个项目，也可能会毁了它。相比存粹的技术，软技能对一个项目的成功起到更重要的作用。试想一下，你把世界上最好的 5 个数据库专家都请来了，但如果他们各自为政，互不沟通，最后他们会给你搞出 5 个不同的 MySQL、Aurora 或 MongoDB 实例。

人一旦有了目标感，就会感觉好一些，这在工作中也是一样的。

作为软件开发人员，你的目标不应该只是把 JIRA 中的问题变成 JavaScript，或者把 Trello 中的项目变成 C#。

你的目标应该是用代码来解决问题。

如果你对正在构建或维护的系统很了解，就可以抛开技术做决策。这个功能是必需的吗？它解决了什么问题？可以用其他方式来解决这个问题吗？真的有必要解决这个问题吗？

这些都是业务问题，如果你想把工作做好，不仅要理解这些业务，还要主动参与其中。即使你在公司里不是 C 级别的人，也不影响你这么做，至少，你要明白自己在做什么。

虽然我们没有必要那么想，但把自己写的代码放出来让其他人“围观评论”，这种体验跟写代码还真是有点不一样，也难怪人们会感到焦虑。

有人因为不堪忍受某些人的吹毛求疵，选择在这个人不在公司的时候提交代码评审。试想，如果你在一个新手的 PR 底下轰炸式地给出 50 个不那么友好的评论，你其实不只是在证明自己作为一名高级程序员的优越感，也是在证明你不是一个“好人”。

那么，正确的打开方式应该是怎样的？

你可以私底下找那个人，跟他好好聊聊，问他为什么把代码写成那样。

其实大多数人也不想把代码写臭，如果你看到臭代码，可能其中会有一些不为人知的原因。当然，也有可能是因为他们的编程技能还不够好，这个时候你要承担起“导师”的角色，给他们提供一些指导。

墨菲定律：会出错的事情就一定会出错。

这就像是一个真理，在设计系统时总会有一些东西会出错。

在开发一个登陆表单时，你要假设会有一些居心叵测的人把整本书的内容拷贝到密码输入框里。

在开发一个可见即所得的窗口时，你要假设会有人试图搞破坏，而且他们通常都能如愿以偿。

如果系统中使用了数据库，它一定会在某个时刻挂掉。如果你没有尝试使用备份来恢复数据库，那它们就算不上是备份。

如果你在给别人做演示，请确保这个演示在任何情况下都能正常进行，哪怕把它翻个底朝天，甚至是把它丢到水底下。

作为高级程序员的一个好处是，当别人问一些我不懂的问题时，我可以很淡然地告诉他们：

这个东西我也不懂，因为以前没有遇到过，不过我可以看一下，然后再告诉你。

当我还是一个初级程序员的时候，我总是很害怕别人会看到我的无知。经过几年的磨练，我才明白，如果碰到了自己不懂的东西，说明学习的机会来了。终身学习绝对不只是一个“口头禅”，它应该被付诸实践。

等你把不懂的东西搞懂了，就要把它们分享出来。写一篇博客，录个教学视频，或者在公司里搞个分享演讲……你不要认为你刚学会的东西别人也都懂，即使是一个非常资深的人，他们也能从初级人员身上学到东西，反过来也是。

分享的过程其实是一个检验你是否真正理解所学的东西的过程。有句话说得好：

当你在教一个人的时候，其实有两个人在学。

https://dev.to/tlakomy/7-years-as-a-developer-lessons-learned-29ic

在你的职业生涯中，学到了哪些受益一生的道理呢？

欢迎在留言区和大家一起交流。

点个在看少个 bug