谈谈一个程序员的职场心得（真有用）

谈谈一个程序员的职场心得

• 我会分为三个部分：软件开发，职场协作和认知成长，每个部分精简成 7 条心得。

软件开发

若无必要，勿增实体。

• 这是奥卡姆剃刀的定义，所谓剃刀就是法则，是奥卡姆这个英国学者提出来的。这个剃刀核心的点在于不要浪费较多东西去做，用较少的东西同样可以做好的事情。放在软件领域，就是不要过度设计，添加当前不需要的功能，也不要一开始就做的非常复杂，难以维护。

• 不需要用设计模式，就不用硬套。不需要用额外功能，就不要写扩展。用设计模式和写功能扩展，必须要有不得不这么做的理由。

• 无论是新创建的软件系统，还是添加功能到现有系统中，都应该从一个最简单的版本开始，这个最简版本甚至几乎没有可用功能。然后，再一步步迭代与重构，扩展它的功能，完善它的设计。简单的系统自然而然会演变成复杂的系统，而不是人工注入复杂，影响它的正常进化。

日志记录，错误处理。

• 开发新系统必须要做的一件事就是搭建日志记录和错误处理能力，系统上增加功能也要接入日志记录和错误处理。虽然这不会影响正常场景的功能，但是非常重要。

• 日志和错误可以告诉我们程序运行的时候发生了什么，程序有没有按照预期工作，通过日志和错误我们可以基本知道程序运行的路径，也可以用来做监控，统计和预警。

每行新代码都要能被执行到。

• 新写一个功能，一定要保证你的新代码都能被执行到，也就是你的测试用例能够覆盖到代码的每一行。有些特别的分支可能很难走到，但你要想办法走到，比如构造符合该分支的请求入参，再比如异常分支可以使用 mock 工具 mock 异常出来做触发。

一次只改一个地方。

• 这是种变量思维。在你开发时，发现程序挂了，如果你只改一个地方，很容易定位到问题所在，因为就一个变量，不可能是别的原因了，但如果你改了好几个地方，之前也没有测试，找出原因就会花费你大量的时间和精力。

• 所以，要小迭代，每迭代一个点确保功能符合预期，再进入下一个迭代，如此重复，而不是一股脑改掉所有的内容。

集成测试前要单元测试。

• 你负责一个单元，你的同事负责另外一个单元，入口侧集成了这两个单元，入口有专门的测试同学来测，以验证整体功能的正确性。如果单元测试充分，就能使测试同学只关注各个单元之间协调的正确性，从而节省整体的时间和复杂度。

开发时间往往比预期长。

• 有时候，你可能会把事情想简单，真正写代码的时候才会发现评估有遗漏，工期会比预期长。

• 有时候，代码写的非常顺利，测试的时候可能就会被某个不符合预期的场景卡主，需要花很长的时间解决。

• 有时候，你依赖的下游未能按期向你交付服务，你的开发工作就要延期。

• 写代码容易，让代码正常无误的跑起来，就比较费劲了，所以评估工作量要给自己留点 buffer（缓冲），以应对一些特殊情况。

读代码并且跑代码。

• 对于一段代码，想要理解它做了什么事情。一种方法是阅读它，凭借自己的大脑去得出代码运行的逻辑。

• 但这种方式并不可靠，毕竟人往往是靠不住的，不过系统是可以靠得住的。

• 那我们就可以跑这段代码，去分析真实系统环境运行的结果。

职场协作

• 作为职场人，我的工作除了写代码，还有就是和各个角色的协作，像产品经理，项目经理，其他开发，测试，以下是职场协作方面的 7 条心得：

选择适当的沟通方式。

• 就沟通效率而言，当面>视频>电话>聊天软件>邮件。

• 打扰强度和正式程度是反方向。

• 紧急的问题就当面或视频或电话，抢夺对方的注意力，尽快解决。

• 重要的结论一定要落在聊天软件或邮件里。毕竟电话没有存档，出了问题没法追溯。

• 但如果你什么小事都要发邮件，那也太浪费自己时间了，什么事情都要给人打电话，那也容易让别人厌烦。

• 所以大多数场景，还是聊天软件，你留言，对方看到了再回复，不必把双方的沟通绑定在同一时间段。

借助身边人的力量。

• 有些时候，你做事情可能会卡主，这非常困扰你，而你也毫无头绪。

• 这个时候你就可以借助下身边人的力量了。

• 比如一件事你在三个方案里面纠结，你就可以整理好自己的思路，分析各个方案的优劣，然后带着这些信息和同事或老板沟通，寻求他们的建议。

• 有时候，你在向他们表达的时候，可能就意识到自己的方向了。当然，你也可以得到不同视角的建议，这对你方案的完善是很有帮助的。

• 所谓：好风凭借力，送我上青云。

善于提问。

• 很多事情自己是可以搞定，比如读代码和运行代码可以理解这一块逻辑，但这要花很多时间。如果你直接问作者，几分钟内你就可以拿到这些信息。

• 信息是可以换能量的。所以多提问，多获取信息，你可以少做很多无谓的工作，从而把精力投身到重要的事情上。

不轻易承诺。

• 承诺并能顺利完成事情，是值得佩服的。

• 但过分过早承诺不适合自己做的事情，对自己无疑是一个负担。如果你本身带团队，对团队也是个负担。

• 承诺要慎重，如果还不明朗，就带回去再评估考虑下。对外部团队如此，对团队同事也应该如此。

• 不要给了对方期待，又给对方失望，弄得自己信用也不佳。

分享利益。

• 一件事，如果有他人的贡献，我们要感激这个人，也要分享利益给他。

• 比如你写的专利里某个人帮助了你，作者中一定要加入他的名字。

• 比如你在向领导汇报你主导的项目的时候，一定要提到其他参与者的名字。

• 《史记》里记载了这样一件事情。汉朝开国皇帝刘邦问从项羽阵营投过来的陈平：“我和项王有何区别？”

• 陈平答道：“项王宽和，您粗野傲慢”。刘邦又问：“那你为何弃项王而投我呢？”

• 陈平讲：“项王对于有功之人，舍不得封赏，而大王您不吝恩赐”。

• 这个故事说明，再好的人，如果舍不得分享利益，大家就会离他而去

• 之前看周杰伦演唱会录影带的时候，有一段是杰伦专门介绍场上乐队各个成员的名字，当时看这段挺动容的，怪不得像方文山，杨瑞代这些人能和杰伦合作 20 多年。

清楚自己的角色，做角色份内的事情。

• 一张地图上，首先要有定位，然后要有目标，才能去看走什么样的路径。

• 角色就是这样的定位。你把自己的角色定位成纯开发，一般来讲专注技术就好了。

• 但如果你想和产品经理更好的沟通，最好还是培养一些产品思维。这样有个好处，就是一些技术类需求，你可以自己判定和定义了，此时你的角色就转换成产品经理了。

• 如果需求比较多，不能马上都做，需要排下期，周期长的项目还要管理下项目节奏，此时也没有专职的项目经理介入，那你就可以尝试做项目经理的角色。

• 你技术一路发展，对自己负责的领域了如指掌，你开始接触了一些架构设计和决策的工作，那此时已经有新角色了，就是架构师的角色。

• 所以一个人是可以有多种角色的，角色决定了职责，因此一件事情中，要清楚自己的角色，做好角色份内的事情，不要越界，也不要失职。

让子弹飞一会儿。

• 如果一件事存在争议，你并不是争议双方的领头人，只是这件事可能会涉及到你落地。那么不要急着去介入具体方案和落地，让他们再争会儿，很可能最终的结论是你啥也不用做。

认知成长

• 作为终身学习者，职场工作的同时，也关心着自己的成长，以上更多是技能方面的，以下是认知成长方面的 7 条心得：

技术是工具，也可以是资产，还可以是商品。

• 技术有三个阶段：技术支撑业务，技术驱动业务，技术创造商业价值。这三个阶段技术是分别作为工具，资产以及商品存在的。

• 我们看到的一个个互联网产品，背后都是由技术搭起来的，技术只是工具。

• 随着业务发展，逐步沉淀面向某个问题的解决方案，有些以专利的形式体现，技术就成为了资产。

• 把通用的技术提炼出产品能力，像阿里云的很多服务那样，技术就变成了商品。

提升效率。

• 什么叫效率？

• 效率就是你完成了多少事，除以你开始了多少事。你开始了一百件，只完成了一件，你的效率就是 1%。

• 所以提高效率的办法，一个是你多完成事，第二个是你少开始事。

打造自己的知识系统。

• 人的大脑天生喜欢记忆结构化系统化的知识。零碎的知识点太多，也只是隐藏在大脑的某个角落，经常被忽视。

• 关键是建立体系化的知识结构，去帮助生活和工作上的决策。

机会留给主动的人。

• 主动向项目组同步进展，主动向领导汇报，主动把事情推向正确的方向。你会发现自己的运气在变好。

凡事需要平衡。

• 一个算法要想获得更快的时间，势必要牺牲更多的空间。

• 同样，无论项目方案还是架构设计，都没有对和错，要权衡当下更重视什么，可以容忍什么，做出适当的选择即可，后边可以再调节。

任何事都是一个 IPO。

• I 是 Input，P 是 Process，O 是 Output，凡事都可以归为 输入-处理-输出 的路径，想好依赖方，处理方式以及交付物，事情就可以变得简单。

公司是你的放大器也是你的限制器。

• 公司是一种组织，组织能辅助个人做成一些事，比如个人在组织中做项目得到成长，能得到优秀同事的帮助，能享受公司发展的红利，能获得公司的学习资源和其他福利。

• 但个人做事往往会受组织的限制，比如制度约束，工作时长，发展方向等等。

• 需要好好利用放大器，同时也要评估限制器是否超出了自己的容忍度。