这是一个创建于 800 天前的主题，其中的信息可能已经有所发展或是发生改变。
原载于我的独立博客 https://lutaonan.com/blog/things-i-learnt-after-6-years-as-software-engineer/
不知不觉今年是我学习编程的第 14 年，作为职业程序员的第 6 年。偶然看到 Addy 分享的在 Google 工作 10 年他学到的东西，我也思考了一下我多年来学到的，总结出了 10 条经验。现在分享给大家。
保持一颗解决问题的心
按照我的观察，那些在工作中用技术取胜的人们共同点都在于他们能保持一颗解决问题的心。他们可以率先想到一种更优的手段解决存在的问题(一般是效率问题)。他们不是嗅觉特别灵敏或者技术特别强，而是当他们遇到了问题，不是把它作为抱怨的话题，而是开始思考这个问题为什么没人解决、应该怎么解决，然后把它实现出来。这种心态在职场上特别稀缺。
我在创业公司的时候做一个图文排版的 App, 设计师会设计一些模板，然后交给我来实现。当时我们有很多模板，为了测试这些模板实现在不同的手机屏幕大小会有什么问题，我们要花特别多的精力。可以想象测试的数量 = 模板数量 * 屏幕尺寸的数量。后来我用 puppeteer 写了个自动生成不同屏幕和模板的截图，直接交给设计师一个一个地看。节省了大量的时间。这个事情没什么技术含量，但它解决了很重要的问题。
工作中需要解决的问题不仅仅在代码上，也有可能出现在非技术问题上。工作中我特别喜欢和非技术同事聊天，了解他们的工作。因为我常常觉得影响项目前进的原因不一定出在我们用了不适合的技术或者不够「先进」的技术。了解非技术同事的工作流程让我大有收获，我会发现他们有一些工作是可以通过写一段程序把原本的工作量做到指数级的下降，而通常非技术同事是很难察觉到的。
这样的例子特别多。有次我和一个运营同事聊天，我们当时在开发一个新闻内容的管理后台，他们常常用这个后台捞一些内容做分析。聊天的时候了解到他们有一部份的工作就是在上面按条件查询一些内容，再一条条地粘贴到 excel 里面，他说这常常要花一下午。后来我帮她做了一个一键导出成 excel 的功能。
她觉得这很不可思议，但这在技术的角度来说太简单了。我也因此了解到，对于不是做技术的人来说，他们很难察觉到哪一些事情是可以用技术解决的，所以我们不能希望他们主动地提出一个需求，只能我们作为掌握技术的人主动地去了解他们。
又一次我和我们的测试吃饭，聊到他们怎么做测试。我发现他们会用 mindmap 先梳理出来一些测试流程，然后一个个地做。但是痛点在于他们常常要手动维护一个文档列出这些 case 的测试结果，这些结果包括截屏，以及证明测试通过的请求返回信息等等。不但麻烦，还很难追踪。
于是我做了一个小 demo Web App ，他们可以直接上传他们做好的 Mindmap, 通过他们的 mindmap 直接生成出来 case item ，在项目的开发环境页面代码里面，只要注入这个 case id ，就可以在测试之前开始记录请求日志，结束之后会上传到这个平台，这样在这个平台就能直接看到每一个 case 操作的时候的整个过程的记录。这个小 demo 后来被用于花呗的大部份前端项目，当然听说现在已经做得和我当时做的小 demo 完全不同了。
了解你的用户
我自认为自己还算是一个有那么一些产品思维的程序员，因为经常也会写一些自己的小产品。但在刚出来工作的时候，我在工作中太沉迷于技术本身。把心思都放在了诸如怎么重构，怎么改进构建速度之类的问题。我在阿里 P5 升 P6 的答辩中，我被问了一个我至今印象深刻的问题：你有了解你的用户是怎么用你在做的这个东西吗？
这个问题是我从来没有想过的，我哑口无言。可能它只是一个晋升答辩问题模板中的一个问题，但对我来说这个问题让我清醒了许多。当时我们做的是内部用的新闻内容管理后台，这个后台的用户是一些小编。我们和这些小编有一个群，但基本是用来报 bug 的。我离这些用户这么近，却从来没有了解过他们的使用感受。我想，如果我当时找他们聊一聊，可能也会有意想不到的收获。或许他们会报怨这个后台的加载速度很慢，我们就可以着手解决加载速度的问题，而不是和同事纠结在用哪种前端状态管理库这种无聊事情上。用户并不关心我们用的是 MobX 还是 Redux.
不要拿自己的尺子去度量别人
我刚出来工作犯的最大的错误之一就是拿自己的尺子去度量别人。我因为从小对编程痴迷，写程序对我来说是人生中最大的兴趣，我把几乎所有的时间都花在了技术上。当时我天真地认为所有程序员都应该像我这样，对待技术也应该有一种理想主义，我在互联网上结交的技术朋友都是这样的。所以我当时对我的同事特别苛刻，甚至对那些把写程序只当成工作的人嗤之以鼻。后来回想起来，这是非常错误的想法。每个人有每个人的追求，技术也只是多个兴趣爱好的其中一种。在当时别人的眼里我可能是个「怪人」，甚至有点「装逼」。
保持学习、be open-mind
我每天都会在 Twitter 和 Hackernews 发现很多最新的技术和技术思考，我关注了很多开源库的作者，我可以第一时间了解到他们最近在思考什么，在接触什么。这种主动接收会扩大你的眼界，让你在解决问题的时候有更广的思路。
不要只关注自己的领域。我还关注了很多写 Rust, 写 Go, 写 iOS/Android 的人。学习主要是学习技术背后解决问题的方式，这些解决问题的方式说不准也能应用到你自己的领域。
保持学习一直是和同行拉开差距最重要的一点。
想清楚，再下手写代码
我写代码的速度非常快，因为我已经花了超过十年的时间在写代码了。很多东西想实现，对我来说基本是纯粹的堆代码。导致我非常容易不经过多的思考就开始动手写。我为此吃了不少亏，常常写到一半发现一些没有想到过的问题，导致需要重新设计，重新改写。我的一位前老板很了解我，他也是个多年经验的程序员了。有一次我们在讨论一个新东西，他对我说，「不要着急，想清楚了再写」。这句话我一直记在心里。后来每次动手写代码之前，我都会把整个流程的设计先思考清楚，避免了很多不必要的重写。
敬畏用户
在写自己的一些没什么人用的开源库或者公司内部用的平台的时候，通常不需要过多思考就能把代码发布出去。到了做花呗这种用户基数庞大的产品，才意识到代码发布和以前所体验到的完全不同。
蚂蚁金服有代码发布的「三板斧」，这是从入职培训到实际工作中就会被反复提及的 must-follow rule. 「三板斧」指的是「可灰度」、「可监控」、「可回滚」。在代码发布之前，要先想想自己的代码是不是符合这三个条件。
- 你的代码发布之后，如果出了问题，是不是可以被监控到的？
- 你的代码是不是可以灰度发布的，而不是一下子全量被推到线上的？
- 代码发布以后，出了问题，是不是可以回滚的？如何回滚？
在经历了用户基数如此庞大的产品开发之后，我对代码发布变得尤为审慎。我记得有次只是单纯改了某段 HTML, 但我还是盯着这个 PR diff 看了几分钟，在想这个修改会不会导致什么问题。
虽然蚂蚁的基础建设可以让这三板斧很容易实现(有成熟的发布平台进行灰度和回滚，有成熟的监控库)；虽然即使遵守了三板斧，还是会有 bug. 但是这种代码发布的思维模式是好的，即使我到了别的公司，我在代码发布前还是会问自己这三个问题。
跨团队合作是利益交换
在大公司里，有时在做一个事情的时候，需要别的团队一起合作，或许是用到别的团队的接口、或许是需要别的团队开发新的接口，但这通常很难。我以前天真地以为，只要我们做的事情是有利于业务的，别的团队自然就应该一起合作。但实际上，大家更看中的是这个事情对自己的团队有什么好处。
换位思考一下，我们和别的团队合作，对于他们来说，增加了工作量，增加了风险(带来更高的 qps, 写更多的代码会导致更多的维护成本)。决定是否合作，首先取决于这是否是自上而下的要求，其次就是合作对他们的 KPI 有没有好处。
所以我学会了在游说别的团队合作的时候，首先应该想明白合作能给别人带来什么好处，而不是对事情本身夸夸其谈。这样更容易促成合作。
用别人的语言交流，会有意想不到的收获
有研究发现如果你用别人的母语和他交流，他会更容易接受你的观点，对你也会更友好。我发现这个心理同样适用在技术交流中。作为一个前端程序员，在和后端程序员商量技术方案的时候，如果可以更多地使用后端的术语，从后端的角度反推前端的想法，他会更容易接受。
我自己业余是个 full stack 程序员，所以很容易切换到别人的语境，也能从别人的角度去理解他的想法。因此沟通会更加顺畅。
理解前人写的「烂代码」
这里的「理解」不是指理解烂代码的逻辑，而是理解为什么会写成烂代码。我经常会听到同事报怨他看到的旧代码写得如何烂，但是实际上很多烂代码产生的原因不是因为技术不行，而是受限于技术的发展和业务的复杂性。随着自己写的代码越来越多，就越能理解这些「烂代码」的存在。看出来了烂代码，也不要着急去重构，这些代码很有可能藏着一些你不知道的特殊业务需求。如果你不需要碰这些代码，那就尽量别碰。
在技术和工作之间找到平衡点
在刚出来工作的前几年，我特别陶醉在把自己学到的新东西试图用在工作中。我的想法是，只有我把这个技术用到实际的工作中，我才算学习了这个技术。
其实这个想法是不对的，学习技术并不一定要求你把他用到工作中。工作就是工作，学习就是学习。工作的内容是为了业务服务的。我在创业公司工作的时候，曾经因为把一个我刚学习到的库用在业务中，因为一些我不知道的坑导致业务进度出了点问题。老板生气地说：业务不是你的试验田。
我后来遇到很多「后辈」(我竟然也开始有后辈了) 请教我说觉得自己在工作中不能运用到自己平时学习的技术，因此觉得自己技术没什么长进。我认为这种想法不太正确。
能把学习到的技术运用到自己的工作中当然是最好的，但这是可遇不可求的事。但是这不代表没有用在工作中，就等于没有真正学习到这个技术。我认为很多人对技术学习有错误的理解，对我来说，学习技术的精髓在于理解这个技术的 Why, What, How. 和能不能用到工作中没有太大的关系。
举个例子，我在刚接触到 Redux 的时候，我去学习它，除了了解它怎么用以外，我特别关心的是，Redux 的哲学是什么？是什么启发了 Redux 的作者创造了 Redux? 他和别的库有什么不同？顺着这些问题，我就会了解更多的东西，比如我发现 Redux 是受了 Elm 的启发，我就会去了解 Elm -> 了解 Functional Programming -> 了解 Immutable, 然后关注 Dan (Redux 的作者) 的 Twitter, 看他日常会分享什么，看他对自己做的这个东西的理解是什么。即使我没有把 Redux 用在工作中(事实上我从来没有用过 Redux)，但我在学习这个库的时候，我学习到的不仅仅是 Redux 本身，还有它背后的更多东西。我可能很快就会忘掉 Redux 的 API, 但那又如何，那些它背后的知识才是最有价值的，是不会被忘掉的。
而工作则相当于是一个真实的场景，是在你学习新的技术的时候，帮助你进行实际思考的场景。你需要有意识地去想，这个技术如果用到我的工作中，它是否适合？它能解决什么问题？它为什么适合？它为什么不适合。当你在学习新技术的时候，结合这个技术，多思考这些问题，这才是真正的学习。
 |
1
random1221 2022-09-20 10:24:14 +08:00  6
这 10 条基本上都需要耐心，但是工作本身就是耗尽耐心的过程
|
 |
2
janus77 2022-09-20 10:48:43 +08:00 1
这些东西很大程度上已经不止是一个程序员的思考范围了，不过写的挺好的，人要成长的确需要经历这些过程
|
 |
3
Bridan 2022-09-20 10:53:05 +08:00
学到了
|
 |
4
god7d 2022-09-20 10:58:10 +08:00
写的很好，大部分内容我也深有同感。开发人员不仅仅只去关注技术层面的东西，其实软件开发整套流程都应该做到可以适度拿的起来，可以从这个角度想：如果我自己独立去开发一个产品，从产品设计到发布整个流程都要自己搞定，应该怎么做？开发人员不应该是流水线的一个零件，更应该把代码开发当作艺术来看待。过度的工程思维会消磨掉对计算机的热爱。
|
 |
5
v2defy 2022-09-20 11:05:08 +08:00
受教了，谢谢楼主
|
 |
6
312ybj 2022-09-20 11:14:16 +08:00
大佬牛逼，受教了
|
 |
7
microxiaoxiao 2022-09-20 11:16:12 +08:00 via Android
跨团队合作 利益交互这事深有体会。前阵子 BA 在设计的时候，就想别人增加接口，只是为了完成功能，但是没说清楚给别人带来的益处。搞得不欢而散，嘿嘿
|
 |
8
christin 2022-09-20 11:18:22 +08:00 via iPhone
学到了 感谢
|
 |
9
kiko12324 2022-09-20 11:20:30 +08:00
感谢前辈的经验，希望还能多多看到您写的博文。
|
 |
10
likunyan 2022-09-20 11:20:56 +08:00
我还没做编程的时候，也是为公司提出了一些建议，比如 2012 年，他们用 txt 写技术文档，我建议团队用有道云，还有很多，不一一列举，那时候我也觉得他们下班就下班了，没有跟我一样研究点东西。
也有用批处理、注册表进行一些效率性的改进、进行监控系统并发邮件。还有，原本 Windows 服务器，游戏开服需要开启关闭防火墙，需要一层一层点击 Windows 窗口，大概有五六层吧，还要输 IP 什么的，后面直接双击注册表图标即可，对于多个地图分线来说，效率大大增加。 后面学了编程，叫朋友或者网络的人一起写代码，要么拒绝，要么加入了，没有动静。 写代码，写了 API 给前端，自己代码要进行单元测试，API 文档要写好，自己走一遍流程。 技术好不好，用户不喜欢，市场不流行，那就没意思，要做调研。 自己写项目，写前端，我之前也是觉得我随便写，编写我随时可以进行改动。对于个人来说还行，两人以上的团队就不行了。 |
 |
11
fiypig 2022-09-20 11:21:52 +08:00
先马克
|
 |
12
noErr 2022-09-20 11:30:17 +08:00
我 k ，这也太优秀了。感觉有 12 年工作经验
|
 |
13
MonkeyJon 2022-09-20 11:33:45 +08:00
学习了，最近正迷茫着，发现学的东西并不能用于项目
|
 |
14
kkhaike 2022-09-20 11:34:32 +08:00 1
等你到了 12 年经验后，发现什么都顶不上"会吹牛"这个技能好
|
 |
15
per 2022-09-20 12:34:23 +08:00 via iPhone 8
最重要的一条经验，不要给别人传递经验。
更重要的一条经验，不要听别人的经验。 |
 |
16
subframe75361 2022-09-20 15:11:42 +08:00
感谢分享！
|
 |
17
magewu1223ll 2022-09-20 15:19:23 +08:00
大佬牛逼
|
 |
18
Xhack 2022-09-20 15:21:58 +08:00
写之前先设计，那么 如何去设计
|
 |
19
nekoneko 2022-09-20 16:05:35 +08:00
六年，六年了，你知道这六年我怎么过的吗？你知道吗？！
|
 |
20
mokiki 2022-09-20 16:37:27 +08:00
Gentoo ，有以下原因：
可控：USE 文件、word 文件、emerge --depclean 清理依赖。我至今不知道其它发行版怎么完全清理依赖。 清晰：软件名没有 lib 、dev 什么乱七八糟的 持续：滚动更新，不拙劣模仿微软搞定期发布的噱头。 务实：不会因为不开源或者其它什么哲学问题，自己就去 fork 改名维护一个软件。 |
|
21
mokiki 2022-09-20 16:38:26 +08:00
对不起，我发错地方了
|
 |
22
fzlqr091314 2022-09-20 17:13:10 +08:00
优秀，，，不过有些部门好像是很抵触的，本来他们可以靠着重复的工作换取工作量，这下要失业了
|
 |
24
ganzhen 2022-09-20 17:36:34 +08:00
记录一下，写的太好了 ，学习
|
 |
25
LING97 2022-09-20 17:50:47 +08:00
从博客一路看到 github ，楼主太优秀了，学习榜样
|
 |
26
sanqian 2022-09-20 18:25:09 +08:00
牛逼
|
 |
27
TripleZ 2022-09-20 18:33:57 +08:00 via iPhone
很受教，感谢楼主。
|
 |
28
cwliang 2022-09-20 18:36:10 +08:00
大学肄业，一路头部公司履历，很强啊
|
 |
29
vayci 2022-09-20 18:39:59 +08:00
学习了，同为 6 年程序员感到惭愧
|
 |
30
oxromantic 2022-09-20 18:46:26 +08:00
学习了，工作 16 年的程序员都总结不出来这么多
|
 |
31
WispZhan 2022-09-20 22:14:22 +08:00
这才是真的，解决以问题为核心的程序员，或者说工程师。
|
 |
32
sawyera 2022-09-20 22:26:36 +08:00 via Android
学习了，偶像
|
 |
33
lizhesystem 2022-09-20 22:32:29 +08:00
收藏！
|
 |
34
Daiwf 2022-09-21 09:02:49 +08:00 2
可惜有时候优秀的程序员不被人看到。想把事情做好，但是领导却觉得你在浪费时间。我们常常用程序员的角度看问题，热衷于此。但是有时候我们好心去解决的问题却被当成自作多情。渐渐的很多程序员就开始躺平，宁愿花时间提升自己也不愿意花时间打磨项目或者产品。
|
 |
35
yechentide 2022-09-21 11:23:19 +08:00 via iPhone
多谢前辈传授经验！
|
 |
36
xloger 2022-09-21 11:33:13 +08:00 2
有一些感触，有一些收获。比如「可灰度」、「可监控」、「可回滚」这一点就对我有帮助，毕竟一直在小公司没这种意识。
当然，对我最大的问题还是在于：我有这个想法且能付诸行动，但是工作安排很紧，我没有额外的精力和时间去更好的解决问题。总不能我自己加班帮别人优化这些吧？尤其是一想到薪资并不高，就满满的不值得的感觉。 不知道楼主对这种问题怎么看？ [当然，我可能知道答案，早点滚去一家值得的公司...... |
 |
37
xygod 2022-09-21 13:24:27 +08:00
羡慕你们 fullstack 可以和前后端顺畅沟通
我们游戏 pg 想和美术准确传达意图太难了 |
 |
38
xmtpw 2022-09-21 15:31:58 +08:00
感谢分享，受益良多
|
 |
39
teemobighero 2022-09-21 16:56:32 +08:00
写的很好，可以分享到朋友圈吗？我会附上博客地址的
|
 |
40
Moha 2022-09-21 17:11:25 +08:00
感谢大佬，增加见识了
|
 |
41
djyde OP @teemobighero 好的
|
 |
42
SKYFUXXER 2022-09-21 18:35:55 +08:00
关于「理解前人写的烂代码」那一条还是很有感触的。
前前司中有一个 FaaS 项目是用 JS 写的，后续我和另外一位组长用 TS 将这个项目几乎完全重写了。 但是考虑到业务的复杂性，有些模块的代码逻辑我们不能动只是做了类型的定义。 我离职时写的关于 FaaS 的交接文档上开头说了这么一句话：随着项目的推进，不可避免的会存在历史遗留债务，希望你可以明白这个情况存在于每一个长期存活的团队中，我从未停止削减债务，但还是无法使每一行代码都崭新闪闪发亮。 |
 |
43
Adelell 2022-09-22 04:20:45 +08:00 1
最近又看了一遍《社交网络》，发现 Facebook 的创始人并没有像普通工程师那样沉浸于自己亲手打磨优化产品，而是把精力转向给自己的产品提供更好的生存环境。
|
 |
44
ffkjjj 2022-09-22 08:29:17 +08:00 via iPhone
学习了
|
 |
45
snoopyxdy1 2022-09-22 09:43:58 +08:00
写的很真实，非常值得学习
|
 |
46
gitdoit 2022-09-22 10:05:00 +08:00
学习到了
|
 |
47
impl 2022-09-22 16:54:49 +08:00
聊天的时候了解到他们有一部份的工作就是在上面按条件查询一些内容，再一条条地粘贴到 excel 里面，他说这常常要花一下午。后来我帮她做了一个一键导出成 excel 的功能。
---- 其实他们更关心的是老板有没有给他们加薪 |
 |
48
fishball92 2022-09-22 17:09:56 +08:00
即将 3 年的 crud girl ，非常赞同， 因为身边的同事确实是这样的，很欣赏这种态度，背诵！
|
 |
49
jones2000 2022-09-22 18:26:25 +08:00
学习技术可以运用到公司项目种，否在就白学了， 但是在运用前必须自己了解这个功能，最起码就是你用的他的库里的某一个函数代码必须要过一遍，否则你敢用，你们老板也不敢用。一般保险的做法就是， 你用到这个库的哪几个方法或类， 直接扣源码移植到你自己的项目中（移植的时候代码规范走你们自己公司的规范，方便后人改和阅读）， 然后测试用例加一点， 去掉没用的东西（通用库一般会有好多冗余功能可以去掉）。这样才算是学会了，否则就是一个工具人， 没有前途。
|
 |
50
asutin 2022-09-29 21:10:36 +08:00
马克一下，写的很真实，希望我能真的学会
|
Select Language