四年了，谈谈一个程序员的职场心得
The following article is from 蜗牛互联网 Author 白色蜗牛
如若转载请联系原公众号
引言
时间好快，转眼间作为一个程序员在职场上已经摸爬滚打四年了。大学毕业以来的四年里，我都是在同一个公司（阿里），在同一个业务领域（电商）和技术领域（Java）发展，第一年结束完成了第一次晋升（P5->P6），第三年结束完成了第二次晋升（P6->P7）。大学也是四年，就时间段而言，四周年是有纪念意义的，可以把这个节点当成是过去四年的毕业，只不过毕的是职场四年的业。
那么毕业之际，分享一些我的职场心得。我会分为三个部分：软件开发，职场协作和认知成长，每个部分精简成 7 条心得。
软件开发
作为程序员，接触最多的当然是软件开发了，以下是 7 条心得：
若无必要，勿增实体。
这是奥卡姆剃刀的定义，所谓剃刀就是法则，是奥卡姆这个英国学者提出来的。这个剃刀核心的点在于不要浪费较多东西去做，用较少的东西同样可以做好的事情。放在软件领域，就是不要过度设计，添加当前不需要的功能，也不要一开始就做的非常复杂，难以维护。
不需要用设计模式，就不用硬套。不需要用额外功能，就不要写扩展。用设计模式和写功能扩展，必须要有不得不这么做的理由。
无论是新创建的软件系统，还是添加功能到现有系统中，都应该从一个最简单的版本开始，这个最简版本甚至几乎没有可用功能。然后，再一步步迭代与重构，扩展它的功能，完善它的设计。简单的系统自然而然会演变成复杂的系统，而不是人工注入复杂，影响它的正常进化。
日志记录，错误处理。
开发新系统必须要做的一件事就是搭建日志记录和错误处理能力，系统上增加功能也要接入日志记录和错误处理。虽然这不会影响正常场景的功能，但是非常重要。
日志和错误可以告诉我们程序运行的时候发生了什么，程序有没有按照预期工作，通过日志和错误我们可以基本知道程序运行的路径，也可以用来做监控，统计和预警。
每行新代码都要能被执行到。
新写一个功能，一定要保证你的新代码都能被执行到，也就是你的测试用例能够覆盖到代码的每一行。有些特别的分支可能很难走到，但你要想办法走到，比如构造符合该分支的请求入参，再比如异常分支可以使用 mock 工具 mock 异常出来做触发。
一次只改一个地方。
这是种变量思维。在你开发时，发现程序挂了，如果你只改一个地方，很容易定位到问题所在，因为就一个变量，不可能是别的原因了，但如果你改了好几个地方，之前也没有测试，找出原因就会花费你大量的时间和精力。
所以，要小迭代，每迭代一个点确保功能符合预期，再进入下一个迭代，如此重复，而不是一股脑改掉所有的内容。
集成测试前要单元测试。
你负责一个单元，你的同事负责另外一个单元，入口侧集成了这两个单元，入口有专门的测试同学来测，以验证整体功能的正确性。如果单元测试充分，就能使测试同学只关注各个单元之间协调的正确性，从而节省整体的时间和复杂度。
开发时间往往比预期长。
有时候，你可能会把事情想简单，真正写代码的时候才会发现评估有遗漏，工期会比预期长。
有时候，代码写的非常顺利，测试的时候可能就会被某个不符合预期的场景卡主，需要花很长的时间解决。
有时候，你依赖的下游未能按期向你交付服务，你的开发工作就要延期。
写代码容易，让代码正常无误的跑起来，就比较费劲了，所以评估工作量要给自己留点 buffer（缓冲），以应对一些特殊情况。
读代码并且跑代码。
对于一段代码，想要理解它做了什么事情。一种方法是阅读它，凭借自己的大脑去得出代码运行的逻辑。
但这种方式并不可靠，毕竟人往往是靠不住的，不过系统是可以靠得住的。
那我们就可以跑这段代码，去分析真实系统环境运行的结果。
职场协作
作为职场人，我的工作除了写代码，还有就是和各个角色的协作，像产品经理，项目经理，其他开发，测试，以下是职场协作方面的 7 条心得：
选择适当的沟通方式。
就沟通效率而言，当面>视频>电话>聊天软件>邮件。
打扰强度和正式程度是反方向。
紧急的问题就当面或视频或电话，抢夺对方的注意力，尽快解决。
重要的结论一定要落在聊天软件或邮件里。毕竟电话没有存档，出了问题没法追溯。
但如果你什么小事都要发邮件，那也太浪费自己时间了，什么事情都要给人打电话，那也容易让别人厌烦。
所以大多数场景，还是聊天软件，你留言，对方看到了再回复，不必把双方的沟通绑定在同一时间段。
借助身边人的力量。
有些时候，你做事情可能会卡主，这非常困扰你，而你也毫无头绪。
这个时候你就可以借助下身边人的力量了。
比如一件事你在三个方案里面纠结，你就可以整理好自己的思路，分析各个方案的优劣，然后带着这些信息和同事或老板沟通，寻求他们的建议。
有时候，你在向他们表达的时候，可能就意识到自己的方向了。当然，你也可以得到不同视角的建议，这对你方案的完善是很有帮助的。
所谓：好风凭借力，送我上青云。
善于提问。
很多事情自己是可以搞定，比如读代码和运行代码可以理解这一块逻辑，但这要花很多时间。如果你直接问作者，几分钟内你就可以拿到这些信息。
信息是可以换能量的。所以多提问，多获取信息，你可以少做很多无谓的工作，从而把精力投身到重要的事情上。
不轻易承诺。
承诺并能顺利完成事情，是值得佩服的。
但过分过早承诺不适合自己做的事情，对自己无疑是一个负担。如果你本身带团队，对团队也是个负担。
承诺要慎重，如果还不明朗，就带回去再评估考虑下。对外部团队如此，对团队同事也应该如此。
不要给了对方期待，又给对方失望，弄得自己信用也不佳。
分享利益。
一件事，如果有他人的贡献，我们要感激这个人，也要分享利益给他。
比如你写的专利里某个人帮助了你，作者中一定要加入他的名字。
比如你在向领导汇报你主导的项目的时候，一定要提到其他参与者的名字。
这个观点来自吴军的谷歌方法论：
https://www.dedao.cn/article/7EGBgdkRbn1mKg495VY890D3rvPOAN
《史记》里记载了这样一件事情。汉朝开国皇帝刘邦问从项羽阵营投过来的陈平：“我和项王有何区别？”
陈平答道：“项王宽和，您粗野傲慢”。刘邦又问：“那你为何弃项王而投我呢？”
陈平讲：“项王对于有功之人，舍不得封赏，而大王您不吝恩赐”。
这个故事说明，再好的人，如果舍不得分享利益，大家就会离他而去
之前看周杰伦演唱会录影带的时候，有一段是杰伦专门介绍场上乐队各个成员的名字，当时看这段挺动容的，怪不得像方文山，杨瑞代这些人能和杰伦合作 20 多年。
清楚自己的角色，做角色份内的事情。
一张地图上，首先要有定位，然后要有目标，才能去看走什么样的路径。
角色就是这样的定位。你把自己的角色定位成纯开发，一般来讲专注技术就好了。
但如果你想和产品经理更好的沟通，最好还是培养一些产品思维。这样有个好处，就是一些技术类需求，你可以自己判定和定义了，此时你的角色就转换成产品经理了。
如果需求比较多，不能马上都做，需要排下期，周期长的项目还要管理下项目节奏，此时也没有专职的项目经理介入，那你就可以尝试做项目经理的角色。
你技术一路发展，对自己负责的领域了如指掌，你开始接触了一些架构设计和决策的工作，那此时已经有新角色了，就是架构师的角色。
所以一个人是可以有多种角色的，角色决定了职责，因此一件事情中，要清楚自己的角色，做好角色份内的事情，不要越界，也不要失职。
让子弹飞一会儿。
如果一件事存在争议，你并不是争议双方的领头人，只是这件事可能会涉及到你落地。那么不要急着去介入具体方案和落地，让他们再争会儿，很可能最终的结论是你啥也不用做。
认知成长
作为终身学习者，职场工作的同时，也关心着自己的成长，以上更多是技能方面的，以下是认知成长方面的 7 条心得：
技术是工具，也可以是资产，还可以是商品。
技术有三个阶段：技术支撑业务，技术驱动业务，技术创造商业价值。这三个阶段技术是分别作为工具，资产以及商品存在的。
我们看到的一个个互联网产品，背后都是由技术搭起来的，技术只是工具。
随着业务发展，逐步沉淀面向某个问题的解决方案，有些以专利的形式体现，技术就成为了资产。
把通用的技术提炼出产品能力，像阿里云的很多服务那样，技术就变成了商品。
提升效率。
什么叫效率？
效率就是你完成了多少事，除以你开始了多少事。你开始了一百件，只完成了一件，你的效率就是 1%。
所以提高效率的办法，一个是你多完成事，第二个是你少开始事。
打造自己的知识系统。
人的大脑天生喜欢记忆结构化系统化的知识。零碎的知识点太多，也只是隐藏在大脑的某个角落，经常被忽视。
关键是建立体系化的知识结构，去帮助生活和工作上的决策。
机会留给主动的人。
主动向项目组同步进展，主动向领导汇报，主动把事情推向正确的方向。你会发现自己的运气在变好。
凡事需要平衡。
一个算法要想获得更快的时间，势必要牺牲更多的空间。
同样，无论项目方案还是架构设计，都没有对和错，要权衡当下更重视什么，可以容忍什么，做出适当的选择即可，后边可以再调节。
任何事都是一个 IPO。
I 是 Input，P 是 Process，O 是 Output，凡事都可以归为 输入-处理-输出 的路径，想好依赖方，处理方式以及交付物，事情就可以变得简单。
公司是你的放大器也是你的限制器。
公司是一种组织，组织能辅助个人做成一些事，比如个人在组织中做项目得到成长，能得到优秀同事的帮助，能享受公司发展的红利，能获得公司的学习资源和其他福利。
但个人做事往往会受组织的限制，比如制度约束，工作时长，发展方向等等。
需要好好利用放大器，同时也要评估限制器是否超出了自己的容忍度。
总结
四年的心得体会其实还有很多很多，限于篇幅就先分享这么多。如果对你能有启发，请你给我点个赞，也非常欢迎一起交流~
推荐阅读：
长见识了！Github标星32K，程序员最需要的网站全部在这了