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