五档尼卡引爆全场

前言

个人身边发生的事，分享自己的一些思考，有不同意见是正常的，欢迎探讨交流

来龙去脉

上周坐我前面的前端开发工程师突然拿了张纸去找业务线领导签字了，领导坐我旁边，我看两人表情都认真严肃，一句话没说，那个前端同事签完字就坐自己工位上了，似乎有什么事发生

微信上问了一句：什么情况？

前端同事：裁员，做好准备

公司现状

从我去年入职公司后，就在喊降本增效了，周一晨会时不时也会提一下降本增效，毕竟大环境不好，公司的业务这两年也受到不小的影响

今年好几个项目组人手不够，两三月前还在疯狂面试前后端测试产品，我们这边的业务线前端都面试都超过五十个人了，最后招了一个前端一个后端一个测试

想着这种情况，公司薪资给的也不高，新员工不大量招就算降本了吧，再优化优化各方面流程等提提效率，没想到降本的大刀直接落下来首先砍掉的是技术开发人员

裁员情况

公司北京总部这边，目前我们部门是裁了两个前端一个后端，其他部门也有有裁员，人数岗位就不清楚了

从被裁掉的同事那边了解到的消息，上周三下班后下午找他们谈的，周四交接，周五下班后就走了，按照法律规定赔偿

上周只是一个开始，应该是边裁边看，什么时候结束最终裁员比例目前还不清楚，由其他来源得到的消息来源说是这次裁员力度很大

现在如果不是核心项目员工，如果不是和领导关系比较好的员工，每个人头上都悬着一把达摩克利斯之剑

个人思考

看待裁员

我认为首先是放平心态吧

国际经济形去全球化，贸易战，疫情，到现在的各种制裁，俄乌战争等，极端气候频发，真是多灾多难的年代

裁员这几年大家也见多了，该来的总会来

我认为裁员好说，正常赔偿就行，好聚好散，江湖再见

企业层面

裁员也是企业激发组织活力的一种方式，正常看待就行，关于企业组织活力介绍的，这里推荐一本前段时间刚读完的一本书 《熵减:华为活力之源》

熵是来源于物理科学热力学第二定律的概念，热力学第二定律又称熵增定律。熵增表现为功能减弱直到逐渐丧失，而熵减表现为功能增强...

个人层面

1.如果公司正常走法律流程，拿赔偿走人，继续找工作，找工作的过程也能发现自己的不错，更加了解市场，甚至倒逼自己成长

2.如果公司只想着降低成本，不做人事，有那种玩下三滥手段的公司，一定要留好证据，拍照，录音，截图，保存到自己的手机或者云盘里，不想给赔偿或恶意玩弄手段的，果断仲裁，我们员工相对企业来讲是弱势群体，这时候要学会用法律武器保护自己（可能也是唯一的武器）

这年头行情不好，老板损失的可能只是近期收益，有的员工失去的可能是全家活下去的希望

日常准备

做好记录

日常自己工作上的重大成果，最好定期梳理一下，或者定期更新简历，也可以不更新简历，找地方记录下来，例如项目上的某个重大模块的开发升级，或者做的技术上的性能优化等，我是有写笔记博客的习惯，技术相关的有时间一般会写成文章发到社区里

保持学习

日常保持学习的基本状态，这个可能我们每个人都会有这个想法，但是能定期沉下心来去学习提升，系统地去提升自己的时候，很少能坚持下来，万事开头难，开头了以后剩下的是坚持，我自己也是，有些事情经常三天打鱼，两天晒网，一起加油

关注公司

如果公司有查考勤，或者重点强调考勤了，一般都是有动作了，我们公司这次就是，年中会后的第二周吧，大部门通报考勤情况，里面迟到的还有排名，没多久就裁员了

保护自己

有的公司可能流程操作不规范，也有的可能不想赔偿或者少赔偿，可能会在考勤上做文章，例如迟到啥的，如果公司有效益不好的苗头，一定要注意自己这方面的考勤，以及自己的绩效等，做好加班考勤截图，领导HR与自己的谈话做好录音，录屏等，后面可能用的上，也可能会让自己多一点点谈判筹码

经营关系

虽然裁员明面上都是根据工作表现来的，好多时候大家表现都差不多，这个时候就看人缘了，和领导关系好的，一般都不是优先裁员对象，和领导团队成员打成一片真的很重要

以前我还有过那种想法：

我一个做技术的，我认真做好我自己的工作不就行了？专心研究技术，经过多年的工作发现，很多时候真的不行，我们不是做的那种科研类的，只有自己能搞，国内的大部分软件开发岗可能都是用的开源的技术做业务相关的，这种没什么技术难度，技术上来看基本没有什么替代性的难度

可能可替代性比较难的就是某个技术人长期负责的某个大模块，然后写了一堆屎山吧，毕竟拉屎容易，吃屎难

越是优秀的代码，可读性越强，简洁优雅，像诗一样

关于简历

如果是刚毕业的，可能简历上还好，大部分都优化都是已经是有一定的工作经验了，简历的更新就比较重要了，尤其工作了两三年了，如果简历看起来内容很少，不是那么丰富或者看起来很简陋，在简历筛选这一关会降低自己的面试几率，这时候一定要丰富一下，也有一些可能不知道自己简历是否丰富的，网上有那种简历模板可以搜搜看看，也可以找大佬帮忙看看，也有技术圈提供简历优化的有偿服务

再找工作

我个人的感觉是如果还是继续老本行继续打工，这年头行情不好，最好第一时间找工作，不能因为拿了赔偿就想着休一个月再说之类的，我周围有那种本来准备休半个月或一个月的，结果一下子休了一年以上的，我面试的时候如果遇到那种空窗期很长的，如果第一轮技术面能力都差不多的情况，到第二轮的领导面或者HR面，他们有优先考虑让空窗期短的人加入

关于空窗期

基本所有的公司都会关注离职空窗期，如果这个空窗期时间长了，那么求职的竞争力会越来越小，我在面试的时候我也会比较关注空窗期，因为我会有如下思考(举个例子，纯属乐子哈)

1.为什么这个人求职者三个月多了不找工作，家里有矿？家里有矿还上班，工作不会是找个地方打发时间的吧

我朋友的朋友就是这样，北京土著，家中独子，前几年拆迁了，家里好几套房，自己开俩车，人家上班就是找地方交个社保，顺便打发一下时间

2.能力不行吗？找工作这么久都没找到，是太菜了吗？还是太挑剔了？长时间不敲代码，手也生疏了，来我们团队行不行呀，我们这里赶项目压力这么大，招进来万一上手一段时间干不了怎么办，自己还被牵连了

几年前在某家公司做团队leader的时候，我们做的又是AI类项目，用的技术也比较前沿，当时AI的生态还不完善，国内做AI的大部分还处于摸索阶段，项目中用的相关技术栈也没个中文文档，由于公司创业公司，价格给的很低，高手招不进来，没办法只能画饼招综合感觉不错的那种，结果好几个人来了以后又是培训，又是有把手把手教的，结果干了没多久干不动走了，留下的烂摊子还得自己处理

关于社保

如果自己家里没矿，最好还是别让社保断了，拿北京举例，社保断了影响医疗报销，影响买车摇号等等

如果实在没找到工作，又马上要断缴社保了，可以找个第三方机构帮忙代缴，几千块钱，这时候的社保补缴相对来讲代价就比较高了

我遇到的情况是，社保断了一个月，后来找到工作了，第三方机构补缴都补不了，后来一通折腾总算弄补缴上了

关于入职

先拿offer，每一家公司的面试都认真对待，抱着一颗交流开放互相尊重的心

如果自己跳槽频繁，再找公司，可能需要考虑一下自己是否能够长待了，跳槽越频繁，后面找工作越困难，没有哪个公司希望招的人干一年就走了

所以面试结束后，最好根据需要面试情况，以及网上找到的资料，分析一下公司的业务模式了，分析这家公司的行业地位，加入的业务线或者部门是否赚钱，所在的团队在公司属于什么情况，分析团队是否是边缘部门，招聘的业务线是否核心业务线，如果不是核心业务线，可能过段时间效益不好还会被砍掉，有时候虽然看拿了对应的赔偿，但是再找工作，与其他同级选手对比的话，竞争力会越来越低

不论是技术面试官，还是负责面试的HR，大部分也都是公司的普通员工，他们可能不会为公司考虑，基本都会为自己考虑的，万一招了个瘟神到公司或者团队里，没多久自己团队也解散了怎么整

这里也许迷信了，基于我的一些经历来看有些人确实会有一些人是看风水，看人分析运势的

之前在创业公司的时候，有幸和一些投资人，上市公司的总裁，央企董事长等所谓的社会高层接触过，越是那些顶级圈里的人，有些人似乎很看中这个，他们有人研究周易，有人信仰佛教，有人招聘必须看人面相，有人师从南怀瑾等等

再次强调

每个人的经历，认知都是不一样的，同样的人不同角度下的世界也是不一样的，有不同意见是非常正常的，欢迎探讨交流不一样的心得，互相学习，共同进步

标题前言

  我想看见这个标题，可能要是近两年，换工作或者刚毕业的小伙伴们最身有体感吧。我先从我自身出发，来讲一下这个我理解，也可能是大家遇见的最多的。

须知：

  我是7月25号晚上被辞退，什么原因我上篇文文章已经写过了，就不细细描述了。本人男，25岁，专科，工作经验三年。个人能力不出众，没做过什么可以拿出来吹嘘的东西。就这样平平无奇的开始了，在找工作的路上征战，征战地（上海~杭州），目前是已经入职2个多月了，今天也是有时间上来谈下感受，当然也谢谢上篇文章下各位小伙伴以及各位前辈的鼓励以及帮助。

进入正题

  刚刚被辞的时候，我是调整了半个月，准备了一个星期*（一定要自己准备好，别浪费机会，现在的机会很可贵，花点时间没关系的），当时我想的是要走两条路，一个是产品助理，一个就是接着前端了。我其实已经在思考变局这件事。所以也算是一次尝试。虽然尝试的结果并不好，没有什么机会




  回归正题，我当时还是首选的上海，在上海找工作，也面试了几家。大概我总结一下啊，8月份的行情可以说是，一塌糊涂。首先我个人比较跨，特别大的公司，因为我学历的问题，基本是约不到面试的。我就讲我面的几家公司，总体是体量100多人的公司双休很少，大部分是大小周，100以下可能就是双休，但是你基本上要独立负责了。（当然我是没面过外包的，外包我个人觉得是可以的，但是我个人不怎么喜欢外包的氛围。如果给的多的话，无脑冲，哈哈）。后来因为个人感情问题也是决定去杭州，当时也是网上也是各种传递说，专科真别去杭州，一点机会没有，去了也是白去。但是我也是对感情一腔热血啊，直接就冲了。发现没有想象的那么差，机会也是有的。也大大小小的面了不少的公司。就突然觉得运气大于努力了！为什么这么说，因为无论是我在上海或者是杭州，面试的时候都会有觉得不错，而且回答的很好的时候。但是往往这些就是说，回去等通知，因为我这边还有约的。到时候通知你，当然也可能遇见过。这时候你自己回家的时候就会有幻想，觉得嗯，可以，应该没啥问题。可是这些往往没了后续。也遇见过说，技术面过以后，说你要的薪资我们肯定给不到的，你能接受多少多少吗？这时候你看下招聘信息，你就挠头，心里想着：“啊，不是，招聘信息上不是有吗”。为啥又给不到，那你就要说的低一点，试试能不能行。然后照常等通知。再遇见，去面试，花了很久过去，然后人事说 技术开会，人事说，技术出差，人事说，技术这会在忙。然后让你等一会，等一会人事就会告诉你，今天不行了，等晚上技术给你电话面试。然后你就点头说，好好好，那晚上几点呢？8点钟吧。ok这时候你已经得到了有用的信息，准备回家了。开始回家准备，7点半就已经严阵以待，8点钟没有电话，8点半没有，9点了你开始想用招聘信息联系一下，然后得到的信息是，技术忙忘了，明天吧，，我只想说别等了，等不到的。再有的，在面试过程中，面试官上来用他自己很明白很清楚的话术问你问题的，你知道，但是你听不懂他先问啥的。这时候你就怀疑自己，我是不是不会，没遇见过。不妨你再问一边，你说，你能把这个问题举个例子吗？可能这时候你就会豁然开朗，原来他问的是这个。我个人遇见get 跟git 一个发音的，导致他觉得我没用过。我为什么会知道，因为他问的问题我基本没答上来。最后他让我问他有什么问题的时候，我才给他说，我说你想问什么呢？你问的我咋都没听过，然后他就开始给我解答，他问的问题是什么，我知道以后我都裂开了。你这问的跟你刚刚问的有关系吗？害，当时觉得自己小丑。当然结果肯定不过。那时候就陷入了一个很奇怪的误区，我每天那么努力，去背，去准备。结果完全用不上。




  看了看那些找工作的群，很多人不如你，却都拿着比你高的工资，嘴里说着不知道为啥就过了，也没问啥问题，就过了，听见后。心理一阵恍惚。觉得自己运气真差啊。真不争气啊。不知所措，迷茫冲上心头，就是不知道差哪了，虽然不入那些真正的大佬牛皮，可是也比刚出来的培训生好吧（这里解释一下，没有其他意思，个人帮很多培训的看简历，以及回答问题，如有冒犯，本人现在就很对不起，可私聊喷我，当场对不起，评论区还是正向一点），为啥事事不如意。然后就那种失望的情绪会笼罩你，会让你觉得，努力不过如此。




  努力，百度百科里是这么解释的：努力指用尽力气去做事情，后来指一种做事情的积极态度，当我们失去积极的态度的时候我们其实压根就没努力。那运气，百度百科里是怎么写的呢,某种事件发生的概率微小、随机性强、无法计算且不可控制的情况下，事件结果产生后恰好与某人的猜想或个人情况决定一致，并且在现实中发生一般为不可思议或完全不可能存在的背景下发生的事件。这句话不做任何解答，自己多读两遍，然后再去认知你的努力。

结束啦

  其实我写的东西很简单，又很生活，讲不出来大道理，聊不出人生观。只有生活，也只是我自己的生活。你们的生活嘛，当然是要 努力 .那运气呢？你们肯定都是有的，如果自己最近运气不好也没有关系。去走一走，转一转，可能你的运气，就会来了。各位也可以评论一下，各位对运气还有努力的看法，评论我会认真回。这篇文章如果有冒犯到的地方，也请见谅。

第一次爬北京的山，看到了不一样的风景，也收获到了意外的体验。虽说是3A级景区，但这次给我的体验远不止3A，恰巧赶上了日落，路上遇到了小猫，2000多米的爬山体验，给我的感觉是，棒极了。

千里之行，始于足下

也许是最近在学校待久了吧，课堂上一些公式化的学习生活有时让人觉得些许枯燥，刚好最近特别想去爬山，想去那就去呗！于是乎，我咨询了一下经常在北京各大山区骑行游览的同学，他随手推荐了离学校不远的蟒山。我上地图搜了一下，在网上简略地看了一下攻略，就决定出发了。没想到的是，另外有两位同学也打算出去走走，我说，那就一起呗，反正也不远。就这样，我收获了两个小伙伴。出发前，我东西收拾得差不多了，但我依然还在想是不要再准备些什么？思索了一下，我觉得不用再考虑太多了，千里之行，始于足下，想做就直接去做先，直接行动起来！

山路崎岖，拥抱自然

在到达正式爬山之前，其实还是经历了许多的小插曲。当天我们三人是坐地铁到达关东站，然后骑着共享单车去到蟒山国家森林公园的入口。但是骑到一半突然觉出似乎山区附近没有停车点，于是本来已经快到山脚下的我们决定原路返回一段距离去最近的停车点。好在最近停车点不远，也没有迂回多少。之后我们开始等公交，可等了一会儿也没见车来，我索性提出直接打车，然后刚打车就有师傅接单了，发现路费也不贵，其实也就10来分钟的路程，不过上山有点坡度，所以骑车可能会久些。就这样我们来到了入口。检完票进去后就面临路线的选择，我想着先从山脚走起吧，就先往文化广场的方向走去。蟒山森林公园其实好多小景点都别有一番风味。

一走进森林公园，给我的感觉就是：“清爽”！在这里，你可以深吸一口气，不用担心烟尘啥的，这里的空气让人很舒服。旁边这些小树林也别有也一番风味，阳关透过枝叶映射在地面上，一条一条的，很有感觉。最重要的是，这里人流很少，是真正的清净！路上有很多的休息椅子，累了也能随时坐会儿，开始给我一种真正世外桃源的感觉。

在体验一番过后，突然来到了观蟒台，说实话， 我好像没咋观出哪里是蟒，可能是还在蟒山脚的缘故，看得不是很开阔，但是风景还是不错的。之后我们开始往山上的方向走去，途中经过了蟒山叠翠、碑林、然后就到了文化广场，广场上面有个水池（忘记叫什么了）。这些景点我个人感觉不是很惊艳，但也算是有该有的吧，水池是个环形的，能看到山的倒影，也算还行吧。

山不向我，我向山去

经过这些小景点的兜兜转转后，我们才算最终踏上了通向山顶的道路，也能明显地感到坡道有些坡度了。我们往五观台的方向爬去，五观台，听说是观五样东西，一个是京城什么的，一个是水库什么的，其他几个也记不太清了，反正就是看五样不同的景观。开始上去的时候有路牌提示，说据顶点还有2000来米，大约需要2个小时，当时看了还是有些吃惊的，竟然这么高吗？没事，反正我也没咋去过，就直接上呗。于是，一个接着一个的台阶就这样在我的脚下流过。

开始的山景似乎没特别惊艳的，因为也许还没到半山腰，景色不是很丰富，但也有不同的植被，也能看到一些小山的景色。一开始觉得没什么难爬的，可能会稍微耗点体力，但是走了一小阵后发现确实有些小累，于是我们开始稍微歇会儿。歇会儿过后又继续前进，路上也碰到了一些来爬山的人，不过也不多。我们一路走着，路上也有不一样的景色，当我们走着走着时，发现太阳似乎快要落山了，有一个角度望去特别的好看，突然的这样的景色也让我给惊艳到了。





不知为什么，从此刻起，突然觉得现在山上的景色好好看，让原本些许累的我们也放松了一下，脚上的累也消了不少。就这样，我们一边欣赏着夕阳，一边继续前行。路上还遇上了一只“学长”，“学长”挺胖挺可爱的。

太阳马上就落山了，我们也目睹了这场绝美的日落

其实太阳落得很快，估计就几秒的时间，可能美好的东西总是很短暂吧！这也让我想起了“夕阳无限好，只是近黄昏”，但是呢，我又觉着“莫道桑榆晚，为霞尚满天”，虽然从岁数来说，放在我们身上不太合适吧，但是我觉得从做事角度，其实还是要怀抱希望，做自己热爱的，现在出发去做，不会太迟。我没有用手机录下它日落那一瞬，而更多是用眼睛去感受了。

半山腰有些拥挤，到山顶看看

太阳已经落山了，但距离山顶还有一段距离，考虑到待会还要下山，心里有些犹豫。但是呢，山顶就在眼前了，总得去看看吧，反正现在也不算太晚，路上还有些人，于是我们就一鼓作气，冲向了山顶。

可能是冬天+北方吧，天黑得比较快，这会儿月亮也出来了，人们也点起了灯火，从山顶上望去，夜景还是挺好看的。

天黑了，也不敢待太久，稍微看看后就下山去了，幸好我们有三个人，不然我还真不敢上来。

总结

本次爬山给我的收获还是挺大的，在山里面，花花草草，虫虫鸟鸟，一山一木，一水一露，让人感到十分清净。我觉得的是，得顺其自然，做你想做的事，有想法就直接行动；做你热爱的事情，喜欢才会有动力；做能让你感到开心和快乐的事情，不必背着自己的内心，做一些不开心不快乐的事。很喜欢的的一句话：“为什么要登山？因为山就在那里”。是的，山就在那里，它们不会走动，你去它那，它就会给你反馈，给你舒心。也许它们不会说话，但是它又无时无刻不在与你互动呢？偶遇的绝美日落，半山腰出现的“可爱学长”，问鼎山峰后的夜景，这才是真正的交流，所以，喜欢就去做呗，不用太在意结果，路途中的美景本身就是一种收获，在过程中，也许就能找到答案了。

最近新工作的编程语言换为了Golang，同时也在面试招聘相关岗位的人才。通过简历面试（别人的经历），以及自己的亲身学习经历，真切的感受到学习能力将是未来的一大竞争力。

从面试方面来看，大多数人工作稳定之后便失去了学习能力，以为现在的工作可以长久的干下去。结果，互联网的风停下来之后，市场的需求变了，从单一的编程语言、单一业务的能力变成更加综合的能力，需要的人逐渐变为T型人才甚至π型人才。此时，学习能力就变得更加重要。否则，面临的只能是市场的淘汰。

下面分享一下自己最近三周学习Golang的一些经验和方法，大家可以拿来借鉴的其他学习方面上：

第一、实践。任何的学习都离不开实践。不能够运用到实践中的学习大概率是无效学习，而实践也是学习最有效的手段。在刚开学学习Golang时，找了一份基础语法的文档，花一两个小时看了一遍，知道常见的语法结构怎么用的，便开始搭建项目，写业务功能。其实这样的效果最快，以具体的功能实践来驱动学习，同时把对这方面的手感和思路锻炼出来。

第二、系统学习。单纯动手实践的过程中会掺杂着业务逻辑的实现，学习效率和范围上会有一些局限，属于用到什么学什么，缺点是不够系统。这时还需要一两本书，通读全书，帮助系统的了解这门语言（或某个行业）是怎么运作的，整个生态是什么样的，底层逻辑是怎样的，以便查漏补缺。在系统学习这块，建议以书籍为主，书籍的优势就是方便、快捷、系统、准确。

第三、交流。之前找一个懂的大佬请教和交流不是那么容易。但随着AI的发展，交流形式不仅仅限于大佬了，也可以是GPT。GPT最强大的能力是无所不知，知无不言。当然，对于它提供的结果也需要辩证的去看，某些地方可能会有错误，但大方向基本上是没错的，再辅以佐证，基本上能够解决80%的问题。

如果有机会参与面试，无论是作为面试官或者被面试者，都是一个交流的过程。在相互沟通的过程中了解市场需要什么，市场流行什么。

最后，针对某些问题，还是得去跟大佬交流才行，交流的过程中会碰撞出很多火花来。比如，不断的迭代某个算法，学到更好的实现方式，了解到你不知道的知识点等。曾经，一个字符串截取的功能，与大佬交流了三次，升级了三版，也学到了不同的API的使用方法和特性。

第四，输出。检验是否学会的一个标准就是你能否清晰的给别人描述出来，让别人听得懂。这一条是否很耳熟？对，它就是费曼学法，世界公认的最快的学习法。如果没办法很好的表达，说明这块掌握的还不是很清楚。当然，这个过程中也属于交流，也会拿到别人的反馈，根据别人的反馈来认识到自己的掌握程度和薄弱点。

第五，利用别人的时间。个人的时间总是有限的，不可能什么事情都自己做，也不可能都亲手验证。而作为管理者，最大的技能之一就是靠别人、靠团队来实现目标。那么，一个技术方案是否可行，是否有问题，也可以交给别人来调研、实践、验证。这样，可以让学习的效率并行起来。

另外，我们可能都听说过“一万小时定律”，这个概念是极具迷惑性的，会让你觉得学习任何东西都需要花费大量的时间的。其实不然，一万小时定律指的是学习一个复杂的领域并且成为这个领域的专家。

而我们在生活和实践的过程中，往往不需要什么方面都成为专家，只需要知道、掌握或会用某一领域的知识即可。对于入门一个新领域，一般来说，可能只需要20小时、100小时不等，没有想象中那么难。对于一个懂编程语言的人来说，从零学习另外一门语言，一般也就一两周时间就可以上手了。因此，我们不要对此产生畏惧心理。

上面讲的是学习方法，但最根本的是学习的意愿。你是选择花一年时间学习一门技术，然后重复十年，还是愿意每年都不断的学习迭代自己？两者的结果差距超乎你的想象。

做了几年的技术管理，简单几点经验可以分享交流一下，管理比起程序还复杂很多，因为一个面向人，一个面向机器，不能以相同的方式来思考，重点是找到平衡，不能用一种方式解决所有问题；好的管理者日常要看的面相非常多，尤其是一、二线带团队，不仅要关注好每个人，同时还要能做好承上启下的作用，要做到面面俱到难度十分高，以下就根据几个维度来分享我自己的经验。

做一个自己都喜欢的团队

每个人带的团队都会有自己的风格，我对自己的要求就是创造自己都愿意待的团队，至于什么是我自己喜欢的团队，简单归类了几个要点，有目标、有空间、有坚持，有明确且有挑战的目标，有足够的空间和舞台来发挥所长，有耐心能坚持做正确的事，能有机会和一群伙伴来达成目标真的是再幸福不过的事，这过程肯定会遇到无数的问题，只要确认不断保持向前，坚持就是胜利✌️

找到共同的目标，坚持做对的事

很多时候团队会存在支持多个目标/业务，这时候就必须类似技术抽象一样的来找到团队内的最大公约数，不一定只有一个但必须要有，核心点还是找到共同的目标，有了共同目标、愿景后可以更好的凝聚方向。

如果一个管理者只是在做分配资源的事，那么还不如不要这个管理者，毕竟传声筒的工作完全可以交给系统解决，例如团队 OKR 只是把每个小方向聚合，那么团队大概率是没方向，等待着别人来推进。

换位思考，保持沟通，面对的是人不是机器

任何沟通最重要的就是换位思考，如果能做到这件事大概率沟通上可以减少很多问题；沟通的过程重点应该是通，关键点不是自己说了多少或做了多少，而是对方获得了多少，多理解对方背后考量的因素，去解决问题而不是解决出问题的人。

过去常听到对于技术人的评价是 “无法沟通”，这种情况大概率是双方没找到频率，每个人都有自己习惯的沟通方式，作为管理者应该要在团队内帮助大家达成一种沟通默契，不应该要求所有人都能使用同一种方式来交流，以及该有的底线划清楚；非常多优秀的人是很有个性的，懂得如何把这样的人摆好位置，会比起把这样的人驯服更有意义，只要在影响范围可控的情况下，应该多花点时间思考在整体排兵布阵。

团队成长 > 个人成长

带团队后最大的不同点就在于需要思考的是整个团队的产出，而不是自己的产出；尤其是原先自己是同团队最优秀的成员因此被提拨出来作管理，自己原先是其他人的 150% 以上的贡献度，但开始带团队后必须要能接受自己的产出会大幅下降，可能自己剩下 50%，团队其他人提升 20%，达到团队整体产出提升。

放权、给予试错空间很重要，想要让团队成员成长势必要让他逐步能承担起更重要的责任与任务；以战养兵是在工作中很好的方案，过程给予适度的辅助与容错，很多错没经历过是不会懂，读万卷书不如行万里路。

建团队，招聘 培养 汰换

建团队是每个管理者都会面对的问题，团队人才密度、人才水平都会决定采用不同的管理方式，其中招聘我认为是最重要的，这关卡的越严格后面就会越轻松，强烈建议这关必须把握好底线，水桶永远会从最低的那一边开始漏水。

招聘是一门大学问，坊间也有很多相关的书籍介绍，并且有专门的服务和职位，在这就以用人的部分来谈谈，一般我自己决定用人就两个原则，“我是否愿意汇报给他/她？”或 “我是否愿意把背后交给他/她？” 这两个问题概括大量的信息和判断，包含当前/未来是否需要这样的能力、团队匹配度、潜力和领导力等，团队整体布局上最好能保持更多元，并且别怕团队成员能力超越自己，就像曾子说的 “用師者王，用友者霸，用徒者亡。”

培养简单可以分为两块专业和软素质，专业部分培养一般相对容易，刚好是相同专业可以直接指导，如果是不同的领域可以找外部进来帮忙，软素质部分大多还是依靠团队日常培养，这块重点主要还是言传身教，身为主管日常的一举一动都会成为团队同学的标杆，因此必须对于自己的言行有一定的要求，尤其是公开场合。

汰换对管理者来说是个很重要的责任，尤其在面对这个环节一定要慎重的考量，要对于每个汰换最好都能有记录留底，帮助自己复盘；一般来说必须找到当前的瓶颈，究竟是卡在事还是人，如果是卡在人，也必须分析清楚原因，因为造成团队不稳定因素？潜力？阻碍团队发展？包含考虑这个瓶颈是不是自己。

1 to 10，10 to N，定义规则

团队 <10 的时候可与所有团队成员都非常的亲近，能明确的知道每个人在做些什么，甚至是团队成员家里的猫受伤了都能知道，在这个时期管理的负担并不是特别大，至少能有一半的时间能在执行日常工作，这时期可能会出现蜡烛两头烧的情况，必须要能尽快的找到平衡点，不需要扣每个细节，但要抓准方向。

团团在 >10 后在 <=15 可能整体变化不大，不过可以很明显的感受到管理成本提升，这个时期会慢慢的开始发现到靠着过去手把手了解细节方式精力会严重不足，需要靠着各种规则、规范来达到找寻最大公约数。

随着管理的范围越大会发现想要知道每个同学的情况不现实，靠着规则来减少管理精力，引导团队走向正确的方向，这其中会有很多的权衡，出现很多错误解读或过度解读信息的问题，通过不断的调整来达到平衡，然而这个平衡是来自于成熟度及规模。

Netflix 的团队有出了一本《零规则》，描述的是大多更像是以原则来取代规则减少理解成本，相信每个人都能按照规则走，再定期抽查的机制保障，从书中来看是可行的，为了适配不同地区文化不同也做了适度的调整，是一种感觉可行的模式，但还是要根据当前团队情况调整。

绩效管理

绩效只是管理的工具和手段，通过这个工具来帮助团队发展和个人提升，让每个同学知道自己阶段的优缺点以和校正方向，让好的更好，阶段性不好的同学能找到方向，达到个人和团队的成长。

绩效管理一定要记得 “功在平时”，绝对不能把绩效管理作为周期性的工作处理，日常付出的越多在绩效评分的时候问题就越少，同时也能帮助绩效沟通上更顺畅，把事情放到最后一刻很容易造成意外，一个不小心就成了事故。

不能忘本

大多技术管理者都是从 IC 开始，保持手感很重要，随着管理的幅度增加会大量降低自己的时间，最好还是能保持着写代码的手感，过往的经验能帮助增加判断力，但技术是不断在翻新，缺少了手感短期可能问题不大，要是习惯了会逐步脱节，严重点就会出现 “技术官僚” 问题，毕竟迭代这么快，哪怕知道原理也容易出现多个类似产品出现后该如何更好的判断问题。

多体验自己做出来的东西，感受技术带来的价值，相信自己每一行代码都在提升人的生活水平，而不是完成一个个任务；技术是个很不同的工种，除了使用工具还能够创造新的工具，为别人提升效率同时也能为自己提升效率。

小结

修身 齐家 治国 平天下，先能以身作则才能更好的要求其他人，让更多人能一起朝着相同方向前进，就像优秀的技术管理者大多也会是个优秀的 IC；保持同理心，多换位思考，帮助更多人激发潜力，各自发挥所长并找到其中的平衡点，这门学问就像是艺术一样的有趣。

到今天仍然觉得自己不是个合格的管理者，还有很多事要学，还有很多要改，没办法做到完美，只能尽可能在前往更好的路上加速前进着，欢迎各种交流讨论，互相学习🤝

原则一：乙方来做决策

• 最终拍板人是谁？是甲方，如果你非要抢板子，那你以后就没有甲方了


• 但是，如果甲方也觉得“我花钱了，当然要听我的（那些只对上级负责又不能拍板的底层打工人，总是这样认为）”，那这种甲方的项目你就不要接


• 因为在这种甲方眼里，你只是“施工方”，他们即不需要你的经验价值，更不会为你的经验买单。所以这种甲方你会做得很累，当他们觉得“你的工作强度不足以匹配付给你的费用时（他们总这样觉得）”，他们就会不停地向你提出新的开发需求


• 所以，你要尽量找那种尊重你经验价值，总是向你请教，请你帮他做决策的甲方

原则二：为甲方护航

• 甲方未来会遇到什么问题，你们双方其实都不知道，所以你需要一边开发一边解决甲方实际遇到的问题。


• 因此，不要为了完成合同上的工作内容而工作，要为甲方遇到的实际问题，为了甲方的利益而开发，要提前做好变通的准备。


• 永远不要觉得你把合同上的功能列表做完，你就能休息了。你要解决的真正问题是，为甲方护航，直至甲方可以自己航行。

原则三：不做没有用户的项目

• 如果甲方的项目没有太多用户使用，这种项目就不要接。


• 除了代码的累计经验，还有一种经验也很重要，那就是“了解用户的市场经验”


• 只有真正面对有实际用户的项目，你才能有“解决市场提出的问题”的经验，而不是停留在“解决甲方提出的问题”


• 拥有市场经验，你就会有更高的附加价值，再配上尊重你经验价值的甲方，你就会有更高的收入


• 永远记住：真正愿意在你身上花钱的甲方，他的目的一定是为了让你帮他赚钱！

以上只是我根据自己经验的一家之言，可能对我有用，不一定对别人也有用。肯定还有很多有价值的原则，希望大家根据自己的经验一起来分享。

下面是一些有意思的讨论

原则 2 、3 都是虚的，就不讨论了。

只说原则一：

一般而言，甲方跟你对接的，一定不是老板。

所以他的核心目的一定是项目实施成功。

但项目是不是真的能给企业带来效益，其实是优先级特别低的一个选项。

拿日常生活举个例子。夫妻、情侣之间，你媳妇儿托你办个事，比如让你买个西瓜。

你明知道冬天的西瓜又贵又不好吃，你会怎么办？

A ，买西瓜，回去一边吃西瓜一起骂水果摊老板没良心。

B ，给你媳妇儿上农业课。然后媳妇儿让你跪搓衣板。

C ，水果摊老板训你一顿，以冬天吃白菜豆腐好为由，非卖你一颗大白菜。你家都不敢回。

这里面，你就是那个甲方对接人。你怎么选？

所以乙方一定不能做决策。乙方做决策的结果，就是甲方对接人被利益集团踹开或者得罪甲方对接人，最终导致项目失败

---

我也来说三个原则

1.要签合同，合同越细越好；

2.要给订金，订金越多越好；

3.尾款不结不给全部源码。

---

原则一:外包大部分就是苦力活，核心有价值的部分有自己公司的人干轮不到外包，你不干有的是人干，不会有人尊重你经验价值，甲方说怎么干就怎么干，写到合同里，按合同来，没甲方懂自家业务，别替甲方做决策，万一瞎建议导致项目出现大问题，黄了，外包钱都拿不回来

原则二:给多少钱办多少事，如果甲方给钱痛快，事少，可以看自己良心对甲方多上点心，否则别给自己加戏，不然很可能把自己感动了，甲方却想着好不容易碰上这么个人，白嫖

原则三:不做没有用户的项目,太片面，不是所有外包项目都是面对海量用户，但是做所有外包项目都是为了赚钱，假如有个富二代两三万找你做个毕设，简单钱多不用后续维护，这种接不接？假如某工厂几十万定制内部系统，可能只有几个人用，这种接不接

总之外包就是赚个辛苦钱，别指望这个来提升自己技术和自我价值，外包行业水太深，你这几个原则都太理想化

---

某富豪要盖一栋私人别墅，招建筑工人，现在缺一名搅拌水泥的工人，

找到了张三，张三说我去过很多工地，啥活儿都干过，经验极其丰富，我可以指导一切事物，我再给你兼职当个总设计师吧，一切事物听我的决策没错。

我每天做完我的本职工作搅拌水泥砂浆，我还能熬夜给建筑设计布局，风水，房间规划，材料采购等等，我啥都会，直接干到建筑完工

富豪很感兴趣，说那你来吧，我盖的是自己住的别墅，张三一听连连摆手:你是盖私人别墅啊？不行不行，我不去了，我以前盖的都是高楼大厦，住户多对我技术水平有严峻的考验，做成了对我有很大提高，私人别墅才几个人用，对我职业生涯一点帮助都没

---

永远不要接外包

这才是正确的答案

做私活的时间

不如自己休息休息，陪陪家人

---

屁事真多，有钱就行了，管他项目有没有人，人家产品低能你还得兜底，接外包考虑的是能不能满足需求。啥条件啊还能挑三拣四，给多少钱干多少活。 招投标接的 30 万以上的项目才有可能考虑你说的这些东西。

---

呵呵 我的意见是：

1. 给钱就做（前提是合规，不是合理），先给定金，拿到定金开工。


2. 遇到扯皮，就停止开发。


3. 要有空闲的时间，偶尔做做（上面说的对：永远不要做外包）。

展开来说，做外包的长期收益很低。就当临时玩一下，所以给钱就做，不管你的需求合理不合理，比如甲方想给智障人士开发一款数独小游戏，好，给钱，签合同，支付定金，开工。

开工了3天，甲方突然说，那个我想加个魔方游戏。不好意思，不行，立即停止开发，开始和甲方掰扯，如果掰扯不明白，就终止合同，如果掰扯明白就继续。

不说了，我要和甲甲甲甲甲方掰扯去了。

再高级的打工人也只是打工人！

OpenAI CEO 奥特曼被罢免的事情人尽皆知「虽然，今天又复职了。。」，我们能从中学到什么呢？

CEO 也能被裁，这应该是最近几年被裁名单里面，职级最高的一个人了吧。你再也不用担心给别人说自己被裁有多丢人了，因为 CEO 都会被裁。

另外，我想说，再高级的打工人也只是打工人！

作为打工人，被裁，尤其是这几年，是在是再正常不过的事情。尽管 CEO 的罢免和总裁的辞职对于外界来说可能是一个令人震惊的消息，但在公司内部，这些变动可能只是公司内部的调整和重组的一部分。

因为，再高级的打工人对于整个公司来说，都不是不可替代的。甚至，连公司的老板也不是不可替代的。国内很多大公司都开始这么培养接班人，离开了老板，公司照常运转的公司，才是一个体制健全的公司，这样的公司才能实现基业长青！当然，老板的不同在于，自己能决定自己什么时候离开。

不管是谁，当公司想裁你的时候，你就不再重要，就跟我上次被裁一样，上午还在写需求、改 bug，下午 6 点多通知被裁，第二天就不用来了！虽然这个对比优点不恰当，毕竟我对于公司来说只是一个普通打工人。

一声被裁，马上就得搬着东西走人。

当然，对于奥特曼（Sam Altman）这样的人来说，被裁不像我们大多数人一样需要考虑下一份工作、生活有没有保障、房贷能不能还上等一系列生存问题。

但是这件事也提醒了我们，无论我们的职位有多高级，我们仍然处于职场中不可忽视的变化之中。因此，我们应该时刻保持敏感和警觉，不断更新自己的知识和技能，以应对潜在的职业变动和挑战。

尤其是对于很多大厂中低层管理者而言，放弃了技术，管理能力也不见得有竞争力，毕竟国内大部分管理者都是野路子，没有经过系统的学习与培训。

如果你放弃了技术，之后因为各种原因被裁，那你可能还不如底层员工，他们还能更好的获取下一份工作，毕竟金字塔的底层岗位最多。

那我们能做什么呢？

做一家「一人企业」。什么是「一人企业」，就是把自己当做一个企业、一个产品来运营，来推销，把自己的能力最大化。

什么人适合做「一人企业」呢？借用饭大的话来说：主业稳定、有时间&有乐趣、不躺平&能利他。

所以，我不是在劝你无脑去干，而是满足了这三个条件，你再去干，你也应该是去干。

当自己的老板！

🙈 序言
时光弹指一挥，三十而立的年纪，生活在自己眼里，可以说一地鸡毛…
我通过这篇文章来分享我的经历,在软件行业栉风沐雨的六年…

🚂 茫
16年专科毕业，确切的说是在英雄联盟游戏里毕业，夙兴夜寐的三年，在游戏、吃喝上忙碌，一周7天，五个通宵。就这样，从学校出来，开始做销售，第一份工作，卖鞋油，给别人擦鞋，三月后，去了企业管理咨询公司，卖课，做了半年，兜里比脸还干净，又去做保险，更惨淡，就这样，17年，踏上北漂之路！

🪂 17 入行

17年三月，清楚记得自己报道的日子。七天的基础班，倒数第一名的成绩，差点把我劝退，硬着头皮坚持，扛下来了，我是最笨的人，但也是最努力的人，培训的那半年，每天早八点，晚12的敲代码。只因为，这是自己唯一的退路！半年后，我是班里第二个找到工作的人，入职某外包公司，现在想想自己那时候的选择，还是有一些遗憾。

☠ 18 踩坑最多的一年
拿到第一个月工资的时候，简直不敢相信，激动的和家里人分享。如果不做这个行业，我觉得月薪1万1很可能就是做梦，现在我也能理解到认知那句话了。这算是第一次找到了自信，在工作上有了结果。工作没想象的难，但也非常难受，学习能力方面确实和本科是有差距，纯野路子，没有什么专业基础，为此，18年，加了很多班，通宵达旦的修复很多自己写的Bug，后来，能力得到认可，当然，这是一点一滴的积累，血和泪只有自己知道。

🔥 19 裸辞
18年上半年买了房子，开始背负房贷，又贷款买了车位，这个时候每月贷款就需要还6K，去掉房租，生活费，身无分文，很多个夜晚挣扎着无法入睡，在压力驱使下，不得不找一个薪水更高一些的工作，找工作的过程对我的打击很大，找了将近一个月，才得到一份工作，比原来高2K，14薪，不过是内部员工，这一点是值得欣慰的。在找工作的过程中能明显感觉到社会对专科的歧视很大，因为有很多聊的很好的场面，但都是因为学历失之交臂！
这一年，我成了开发组长，管理四五个人开发，说组长感觉又不太合适，因为自己的开发任务也比较大，就算这样，也还好，因为房贷压力小了，能腾出手忙一点发展的事儿了，这个时候，没有时间谈个人的私事，这一年，工作中忙碌，兼顾生活，贷款，家庭，遇到了很多研发方面的困难，不过都一一克服了，还获得了客户的好评，这儿就不细说了，后续博客会写一部分。

🤡 20 裸辞
这一年，房子交房了，要装修，除了贷款的压力，还得装修房子，在工作上，已顺风顺水，有啥困难都能解决，个人能力团队也都很认可，但薪水成了一个生活发展的阻碍，为此向公司提了一下涨薪，被驳回了。然后我又提出裸辞，公司开始打算涨薪挽留，我拒绝了！然后我又去了外包公司，只为多拿点钱，让压力小一些，把家里的事情处理完。

下图来纪念以下公司的前台！！！

🦧 21 沉淀
裸辞也算非常顺利，半月的时间就接上了，薪资的话18K。工作很轻松，很多任务都能快速高效完成，在这个空闲的时间里，也没有闲着，会读读书，思考一下人生的意义！以下是我读完的书！

读书给我带来了一些动力和精神的慰藉，我也没有想到，一个大学不务正业的人能够静下来看书看到一千多个小时！我读的书没有太多技术方面的，在那个时候最大的作用应该是抵抗那些来自生活得压力和孤独吧。这一年的收获和前几年相比来说，应该是人更平和了，不在那么功利和浮躁，开始看淡一些物质相关的东西！

🧸 22 被解雇
作为一个外包公司，服务的项目做完了，又赶上疫情，被解雇也算是顺理成章的事情，这个时候也没有埋怨，也赶上春节，在家里呆了半个月，就开始投递简历，心里想的是在奋斗一年，找个离家近一点的工作。这个时候的就业环境已经不太乐观了，就学历门槛就很卡了，复习了几天，然后面了三四家吧，就又踏上北漂征程，这次也是外包公司，薪资22K。
三月入职，9月晋升，薪水涨到24.3K，工作上没怎么加过班，工作时间内也都能很出色的完成任务，这一年的总结就是遇到了很多优秀的人，学到了很多方法论，自己更能独立解决问题，在研发层面能够结合业务提出更多的解决方案，的确，这一年做方案的能力很强了。

🎨 23 前篇裸辞
23年五月，通过了PMP项目管理考试，顺利获得证书。作为一个山东人，深受孔孟思想的影响，不孝有三，无后为大！如今也快30岁了，别说结婚，对象的影子也没见！这个压力也慢慢加到了生活了。当我感受到痛苦和不想漂泊的时候，今年五月底，我递交了辞职申请！
离职需要在呆一个月，处理一下自己手头的尾部工作和交接事宜，7月1号，踏上了回家的征程。我很感谢这个公司，让我经历压力没那么大了，房子装修完了，就剩贷款了！
用此图来纪念一下！！！

🎨 23 中篇挣扎
回到家，作为一个驾-照拿了八年没摸过车的人，这个时候买了车，找了个教练，练了练车，差不多了，就开始闭关一月，学习，看视频，属于恶补吧。
8月开始投递简历，本是泰安人，想在家乡谋一份差事，为家乡发展做点贡献，自己钱包也多一点，这个双赢的机会在我面了两三家公司后打消了念头。
开始投递济南的公司，面了一家，项目经理职位，16k,就去工作了，也是一家外包公司。局方公司背景还是不错的！
工作了三个月，我又裸辞了，原因是太累，在提升自己层面上，得到的比较少。因为有贷款的压力，我辞职是做了很大心理建设的！

🔅 23 后篇 展望
辞职后，无缝衔接了一家公司，就是专门做研发，薪资12K，大小周。没有嫌弃，没有抱怨。目前自己的想法很简单，就是打造自己的产品，能够拿得出手一些东西，比如博客，比如项目，比如情感的一些价值！以前的自己好高骛远，现在的自己更脚踏实地，一步一个脚印，把自己的价值分享出来，成就别人，也成就自己！

⚜ 未来我会怎么做

• 做好自己的本职工作-核心


• 少花一点时间放在娱乐上


• 多做一些有价值有产出的事儿 比如博客 比如读书分享 比如研究新项目


• 跟随趋势走 拥抱变化


• 更好的利用技术而不是沉迷技术


• 更平和的心态处事


• 简单的态度生活处世 己所不欲 勿施于人

概述

工作这10多年来，也经常做招聘的工作，面试过的人超过50人次了，而看过的候选人的简历则有几百份了，但是清晰且能突出重点的简历，确实很少遇到。这里基本可以说明一个问题，很多候选人是不太清楚如何写出一份好的简历的。

下面基于简历中的项目经历，重点铺开说一下。在社招中，项目经历面试官重点考察的地方。

写项目经历需要注意的地方

项目经历是介绍你实战经历的地方，同时也能反映你对已掌握的技能的使用情况。对于应聘偏技术类的岗位来说，这块非常的重要。

下面会以支付中心作为例子进行阐述。

• 
  

  项目背景，也即是你一定要非常清楚启动这个项目的缘由是啥。如果这个都说不清楚的话，那说明，你真的就是埋头干活，偏执行的角色。对项目并没有一个整体的认识。就算你只是这个项目的普通参与者，也需要主动的去了解和理解该项目立项的原因。有个注意的地方是，项目背景的文字描述不要太长，一两句就可以了。比如说：当前支付中心耦合在订单系统中，为了提升支付模块的稳定性、维护性、性能和扩展性，需要将支付模块独立出来，统一为其他内部系统提供支付能力;

  
  


• 
  

  项目功能介绍，介绍一下这个项目能做什么，有什么核心模块，需要应付什么量级的流量。以支付中心为例子：为内部的订单系统提供支付能力，对内提供了微信、支付宝、抖音、海外、信用卡、钱包、礼品卡以及组合支付的支付、回调、退款、查询、业务对账等能力。平时需要应付每秒1万的支付请求。

  
  


• 
  

  技术架构设计，这里考察的是技术选型的严谨性和模块设计的合理性。如果项目用到了RabbitMQ、Redis、Kafka等一些技术，你自己心里一定有个底，就是当时为什么选用这些技术，是经过深思熟虑的吗？是经过了很多轮的技术栈对比后决定使用的吗。也即是技术选型是一个严谨的论证的一个过程。而设计这块，则要说清楚模块划分的缘由以及解决方案。还是以支付中心为例子：通过支付网关，对外提供统一的接口，而内部则通过支付路由模块，进行具体的支付方式路由，并把单独的支付方式，以物理单元进行隔离，避免各种支付方式在出故障时，相互影响。为了应付高频的支付动作，采用数据库分库的方式缓解写的压力。

  
  


• 
  

  我负责的模块，如果你参与的项目是部门核心项目，但是自己参与的模块确是边缘模块或者只是参与了很小的一部分，虽然你也能在这个项目里，得到成长。但是那是称不上个人亮点的。因为面试官会更倾向于：你为这个项目做了什么贡献，因为你，项目有了什么好的改变和突破性进展。因此，做项目的时候，不妨跟自己的领导多反馈一下，希望能独立主导一些重要的模块。如果领导觉得当前的你还无法独立hold住重要的模块，你也不要气馁，平时多多提升自己，争取后续能主导一些重要模块。这个真的很重要，为了将来的自己，你必须得这么做。在做项目的时候，如果你长期一直起着螺丝钉的作用的话，对你极其不利，甚至可以说，你是在浪费时间。

  
  


• 
  

  难点和踩过的坑，难点也即是亮点。在你负责的模块里，具体的难点是什么，你是通过什么方案解决的。而解决的过程中，又遇到什么大坑？怎么优化的。这个其实是一种引导，把面试官引入到你自己比较熟悉又印象深刻的领域，如果你准备充分的话，是能给面试官一个好的印象的，是能加分的。同时能解决掉难点，对自身成长也是有利的，且还能说明的你韧性不错，有追求。

  
  


• 
  

  取得的成效，不能只是重视过程，而不重视结果，这是不可取的。你需要用结果和数据体现你的价值。比如说，支付中心上线后，你负责的业务模块，慢调用和慢SQL消失了，接口响应速度提升了10倍，上线半年，无任何大故障。等等。

  
  

项目经历写几个合适？

如果按照上面的的方式来书写项目的话，那每个项目的文字描述是不短的，一个项目的描述就大概要占用半页了。因此，简历里的项目不能太多，2到3个就可以了。项目主要在精不在多，把自己负责比较多的且能作为自己的一个亮点的核心项目，说清楚道明白，更为重要。

现在的你应该做什么？

赶紧好好总结一些当前和之前做过的项目，按照上面列的方式，好好梳理和思考一下，提炼一些重要的内容出来。争取能作为自己履历的亮点。如果你发现到目前为止，还没有能为自己带来竞争力的项目，那赶紧好好反思一下，赶紧争取去做。

小结

如果你不是什么名人或者知名大佬，学历和履历也一般般，那么你只能通过曾经做过好的项目来增强自己的竞争力了。HR也会通过你的项目经历来了解你的能力。项目经历一定要真实，要突出亮点和难点，并说清楚自己在项目起到什么作用。

工作满意度是幸福感的重要预测指标。对于工作有多满意，很大程度上也决定了对人生有多满意。有研究表明，在幸福感的所有预测指标中，工作仅次于婚姻。盖洛普公司主导了一次针对全球十几万人的调查研究，包括了从原始部落到现代文明的不同工作形态，结果表明，不管在地球的哪个角落，「一份有意义的工作可以显著地预测幸福感。」

在希腊神话里有这样一个故事，一个叫西西弗斯的国王，他自作聪明，戏弄了死神和冥王等众神。众神把他抓到阴间，给他一个恶劣的惩罚，他需要每天把一块大石头从山脚推到山顶，每当他正好要到达山顶的时候，大石就会滑落回山脚，西西弗斯只有顶着烈日，日复一日地将石头从推到山顶，如此循环往复。「西西弗斯这个故事代表了没有意义工作的极致，也是一项非常残酷的惩罚。」

著名的富士康连续自杀事件，在工厂车间，几百个工人，日复一日地做着重复而简单的工作，不就是西西弗斯的神话在现实中发生？在无休止的加班和重复劳动中，不知道工作的意义是什么，如此麻木而紧张的工作状态，导致了最终的悲剧。

上班如上坟：最糟糕的工作状态

现在有一句话描述的特别贴切——“上班如上坟”，这句话非常形象地表达出了最糟糕的工作状态。

马云曾经说过一个深受大家认同的观点，一个人离职，原因无外乎两点：

• 钱没给够


• 受委屈了

其实真实发生的离职情况来看，第二点的因素占绝大多数，当我们工作中遇到了很多不快乐的事情时，就会触发大脑的情绪思维，从而产生了离职的念头。

在互联网行业，大多数产生这种“上班如上坟”的状态是以下几种情况：

• 「内卷」，一种是**「工作时长」上的卷，一天有做不完的工作，干不完的活，每天工作可能超过12个小时，甚至没有周末，类似于富士康的模式，简单低效且麻木，没有基本的休息时间保障；另一种是「内心」上的卷，可能是过高的要求，无法完成的目标，带来的无尽压力，产生了「绝望感和窒息感」**，长期在这个状态下非常容易出现心理问题。


• 「得不到认可」，一直被领导PUA，这会导致一种无论如何努力都不被认可的无力感，产生非常大的精神内耗，会怀疑自己和否定自己，有很大的负面情绪产生。

一旦达到“上班如上坟”这个状态，实际上已经是非常糟糕的情况了。往往这种状态下，大家会选择摆烂，消极对待工作，逃避，有离职冲动等等，工作和生活都会受到极大影响。

金钱不过老六

在正式工作之前，我们对于薪资有无比强烈的渴求，那时的offer选择真的很简单，哪一家给的钱多就去。在工作之后，很多公司挖人的手段也是以高薪涨幅为第一吸引力，在环境比较好的时候，往往跳槽才是获得更高薪酬的最有效手段。

大多数打工人面临的是生存问题，大城市高额的生活成本，房贷车贷子女教育，是压在每个人心头的大山，尤其在深圳这样的地方，无数人在这个地方有着共同的目标——搞钱，金钱的重要性不言而喻。

但是，我们是否过于重视金钱而忽视了其他？在赫兹伯格的研究中，「金钱排在成就、认可、工作本身、责任、晋升之后」，在第6位，「前5项因素才是真正驱动员工的动力所在」。

在赫兹伯格提出的著名的双因素理论中，金钱属于保健因素，它是必要的保障，只会让员工产生不满的情绪，而无法得到满意的情绪：

image

实际上，我们在跳槽拿到高薪的最快乐的阶段，是在拿到Offer后的那段时间，以及拿到第一个月的薪水的时候，其他的时间的情绪感受都与金钱本身关系不大了。

物质资源永远是有限的，在大幅度提高的情况下才能产生激励的效果。钱并不是万能的，从员工的角度来说，个人的身心健康应该是更重要的东西。

快乐工作的价值

谷歌在早些时候平均年薪仅在美国科技公司中排12位，但是却获得了最佳雇主排行榜的榜首。谷歌对员工开出了丰厚的条件：

• 免费用餐


• 班车接送


• 股票期权


• 发放IPad


• 社交活动，比如瑜伽、葡萄酒、足球比赛、露天烧烤、吉他等


• 健身房、免费按摩、免费理发、体能训练等等

这些福利并非浪费，盖洛普指出，员工满意度提高5%，连带提升11.9%的外部客户满意度，同时企业效益也会提升2.5%。

后来这一类的福利策略也被其他公司纷纷效仿。快乐工作的第一步是需要有一个舒心的环境，让大家能够对公司满意，才能更加自发地了解探寻工作的意义。

Denison Consulting公司调查显示，员工心情不愉快的企业年销售额仅增长了0.1%，而心情愉快的同期增长15.1%。企业若能将员工满意度提高20%，便可将财务绩效提升42%。

快乐工作，会让企业产率、质量、销售额、客户满意度、创新性、适应性都有一定的提升，降低员工缺勤率、跳槽率、紧张与疲劳感，这是雇主与雇员的双赢策略。

「我们需要追求的终极目标是，让工作成为一种享受。」

管理是控制还是服务

相信绝大多数的管理者认为管理是服务，但是在实际行为中却不一定，比如：

• 不应该对员工说“谢谢”，这种假客气只会产生距离感？


• 不需要征询员工意见，我对结果要负责应该我说了算？


• 成功来自于能力和实力，与其他因素无关？


• 无法容忍下属的挑战，有悖于合作的伦理并产生糟糕的示范效应？


• 每个人都得为自己的情绪负责，管理还有更重要的事情要做？


• 保持开放的沟通固然重要，但是很容易让员工自以为是，需要保持距离？


• 比起目标、绩效、团队的前途，友善和蔼的风格只会让权威旁落？


• 每天压力这么大，谁能有时间去培养员工提升他们的能力呢？


• 授权并不靠谱，现在这个环境，更适合各司其职，稳稳当当？


• 说实话，所谓的愿景和将来就是忽悠，我如何与员工谈论自己都不相信的未来？

这些问题能够帮助我们反思，自己究竟是在控制还是在服务，作为管理者，一个细微的举动可能在员工看来就会引起不小的情绪波动。

我们冷漠吗

工作氛围的糟糕，上班如上坟，十有八九跟管理者有很大的关系，更多的时候，冷漠与氛围直接相关，比如：

• 同事见面都会热切的打招呼吗？


• 同事们互相信任，困惑、焦虑和感受都能相互分享吗？


• 大家在各种沟通场合中能够畅所欲言吗？是否藏着掖着？


• 吃饭时会形成若干个自发团体吗？有人形单影只吗？


• 下班之后同事还有可能有聚会吗？


• 团队稳定性很高吗？团建大家都积极参与吗？


• 新人容易融入吗？会有计划培养新人吗？


• 奖励时常发生吗？无论是物质上的还是精神上的


• 大家认可自己的工作是有价值的吗？


• 领导的压力和情绪会透传给下属吗？


• 领导愿意和员工单独交流吗？


• 领导与员工相处舒服吗？


• 领导善于夸奖人吗？

这些问题有助于判别团队的氛围如何，一个好的工作氛围，才能享受工作，激发更大的动力，这样的团队才能创造更大的价值。

内心驱动模式

从个人内心的动力上，大概可以分为三类驱动模式：

恐惧驱动

• 害怕最亲近的人离开？


• 害怕失去工作，失去工作能力？


• 害怕失去健康？


• 害怕不成功，窝窝囊囊过一辈子？


• 害怕资产缩水，辛辛苦苦的钱贬值？


• 害怕晚年凄凉，孤苦伶仃？


• 害怕被领导同事瞧不起，不被认可？


• 害怕家庭解体？


• 害怕死亡？

责任驱动

• 要对工作负责，我做事是有品质的


• 要对同事负责，不能给别人带来麻烦


• 要对领导负责，不能辜负他的信任


• 要对父母负责，懂得报恩


• 要对那一位负责，已经是利益共同体


• 要对孩子负责，作好的榜样


• 要对银行负责，需要还贷


• 要对朋友负责，有真心的朋友不容易


• 要对国家负责，民族的脊梁


• 要对自己负责，希望回首往事不留遗憾

梦想驱动

• 我想赚很多钱，可以衣食无忧想要什么就有什么


• 我想成为大家都喜欢的人，因为我而快乐


• 我想周游世界，看看外面的风景


• 我想健康长寿，尽量活得久一点


• 我想每天能够幸福满足，活出质感


• 我想好日子延续下去，不要大起大落要平安喜乐


• 我想大家都能够快快乐乐在一起


• 我想做自己喜欢的事，可以不要为了钱而工作


• 我想帮助更多需要帮助的人，人本来应该善良

在工作上，「责任驱动、梦想驱动占据主导地位的人是非常稀缺的」，作为一个管理者，如果因为自己，把这类人变成了行尸走肉，只剩下恐惧驱动，真的是最大的过错，令人发指，天理难容！

个人感悟

上班如上坟这种状态，十有八九都是跟管理者有很大的关系。在目前互联网增速放缓的今天，物质金钱上已经无法带来激励的时候，这类问题尤为突出。若工作氛围很糟糕，更是雪上加霜，团队没有凝聚力，无法获得更高的产出，导致更多的裁员，形成恶性循环。

在目前的大环境下，企业面对生存压力，沉重的指标压在管理者的身上，更需要管理者能够创造快乐的工作氛围，即使在互联网这个不得不加班的大环境下，也能够让工作成为一种享受，不要再让员工产生额外的内耗，驱动团队创造更大的价值，共克时艰。

时间线

2020 年 9 月 10 日，华为召开了开发者大会，正式推出了 HarmonyOS 2.0 系统，并宣布为开发者提供完整分布式设备与应用开发生态。

2023年10月17日，小米集团首席执行官雷军正式公布了这款操作系统，并称该系统将逐步接替之前小米开发的MIUI系统，成为小米智能硬件互联生态的统一计算平台。首款搭载HyperOS的智能手机为小米14系列手机。10月20日、23日，MIUI的微信、微博等公众平台账号陆续将MIUI改为其中文名“小米澎湃OS”。

2023年11月3日消息，在此前举行的 2023 vivo 开发者大会上，vivo 已经宣布首款搭载蓝河操作系统的设备将是 vivo WATCH 3 手表。vivo 副总裁周围在接受媒体采访时明确表示，vivo 自研蓝河操作系统不兼容安卓应用。

以上这几年国内著名手机厂商公布自研操作系统的时间线。笔者最近比较对国内操作系统的发展动向比较感兴趣，所以就开始了解收集这方面的信息，想通过这篇文章帮我看清操作系统发展脉络或者说补充一些相关认知盲区。

先用一张图厘清操作系统发展脉络

大家应该都知道华为、小米和Vivo分别是国内三个著名的Android手机厂商。国内移动互联网快速的发展，也是得益于Android的开放性，国内手机厂商基本都是基于ASOP(Android Open Source Project)魔改源码逐渐形成自己的定制操作系统，比如HarmonyOS、小米的MIUI和Vivo的OriginOS。如下图所示：

iOS 是由苹果开发的移动操作系统。苹果最早于2007年1月9日的Macworld大会上公布这个系统，最初是设计给iPhone使用的，后来陆续套用到iPod touch、iPad上。iOS与苹果的macOS操作系统一样，属于类Unix的商业操作系统。苹果凭借它极具竞争力的软硬件创新产品，妥妥是一方巨头，跟Android开放生态不一样，苹果的操作系统并不开源。

但从2023年国内手机厂商公布的操作系统来看，从曾经套壳Android逐渐演变成去安卓化趋势。那为啥会有这种趋势发生，或者说这真的是未来操作系统发展趋势吗，国内厂商可能会面临什么样的挑战？这个问题的答案我们需要时间去验证，我们只能先做些畅想。

国内手机厂商是如何发展起来的？

国内手机厂商的发展主要经历了以下几个阶段：

1. 初步阶段（2000-2003年）：在这个阶段，国内手机市场刚刚起步，消费者对手机的需求逐渐增加。一些国内厂商开始生产手机，主要以低端和中端产品为主，如联想、TCL等。


2. 品牌竞争阶段（2004-2006年）：随着消费者对手机品牌的关注度增加，一些知名品牌开始崛起，如华为、中兴、酷派等。这些品牌通过自主研发、产品创新和技术积累，逐渐在中高端市场占据一席之地。


3. 智能手机时代（2007-2010年）：智能手机的兴起，为国产手机厂商提供了新的发展机遇。在这个阶段，小米、OPPO、vivo等厂商迅速崛起，通过高性价比、良好的用户体验和市场营销策略，逐渐在国内市场占据重要地位。


4. 全球化竞争（2011年至今）：随着国内手机市场的逐渐饱和，国产手机厂商开始将目光投向海外市场，如印度、东南亚等新兴市场。此外，厂商也在积极布局5G、物联网等新兴领域，以寻求新的增长点。

Android系统最早于2008年9月23日正式发布。进入中国市场的时间则是在2009年左右，随着第一款搭载Android系统的手机HTC Dream（在中国市场称为G1）的上市，Android系统开始在中国市场逐渐普及。

华为、小米和vivo这些手机厂商开始使用Android系统的时间如下：

1. 华为：华为早在2009年就推出了第一款搭载Android系统的智能手机——华为U8220。此后，华为逐步发展成为全球领先的手机厂商之一，并在Android系统上推出了自家的EMUI（Emotion UI）用户界面。


2. 小米：小米成立于2010年4月，同年8月推出了基于Android系统的MIUI定制系统。2011年8月，小米发布了第一款搭载Android系统的手机——小米1。凭借高性价比和出色的用户体验，小米迅速崛起成为国内外知名的手机品牌。


3. vivo：vivo成立于2009年，2011年推出了第一款搭载Android系统的智能手机——vivo X1。随后，vivo在Android系统上推出了自家的Funtouch OS用户界面，并逐步发展成为市场份额较高的手机厂商之一。

从上面我们回顾了下国内手机厂商的发展历史，可以说没有Android系统进入国内市场，中国的智能手机时代历史进程就不可能这么快，国内手机厂商也正是抓住了这波机遇完成了国产化，并且发展至今。

更具象化分析智能手机厂商发展

从我个人的分析理解，国内手机厂商发展分为以下几个阶段：

1. 第一阶段：本土化定制，实现自主可控
   这个阶段国内手机厂商主要关注于对Android系统进行本土化定制，通过开发自家的用户界面（如华为的EMUI、小米的MIUI、vivo的Funtouch OS等），满足国内用户的需求和使用习惯。同时，厂商也开始关注硬件研发和生产，逐步减少对外部供应商的依赖，提高自主可控能力。


2. 第二阶段：自家产品生态化拓展建设
   在第二阶段，国内手机厂商开始关注产品生态的构建，将手机作为核心，围绕其开发各类智能硬件和应用服务，如智能家居、可穿戴设备、云服务等。这有助于提高用户粘性，形成闭环的生态系统，从而提升品牌竞争力和市场份额。


3. 第三阶段：公布自研操作系统，引入AI大模型完善产品体验
   在第三阶段，国内手机厂商开始研发自家的操作系统，如华为的鸿蒙OS（HarmonyOS），以降低对Android系统的依赖，提高自主创新能力。同时，厂商也开始引入人工智能技术，通过AI大模型优化产品性能、提升用户体验，为未来5G、物联网等新技术应用做好准备。

目前手机厂商已经来到第三阶段，自华为公布鸿蒙系统之后，小米和Vivo也相继公布自家的自研操作系统，自主创新似乎是国内厂商不约而同的战略共识。

避免被“卡脖子”再发生

2019年5月15日，华为被美国正式制裁，截止目前，已经过去了4年。那么这些年华为到底被制裁了什么？

华为受到的制裁主要包括以下几个方面：

1. 美国实体清单：2019年5月，美国政府将华为及其关联公司列入实体清单，禁止美国企业与华为进行商业往来，除非获得特别许可。这意味着华为无法从美国供应商处购买关键零部件和技术，如芯片、软件等。


2. 芯片供应限制：2020年5月，美国政府进一步收紧对华为的制裁，要求全球芯片制造商在向华为供应美国技术含量超过25%的产品时，必须获得美国政府的许可。这使得华为的芯片供应受到严重影响，尤其是高端芯片。


3. 软件限制：华为受到制裁后，谷歌停止为华为新款手机提供GMS（谷歌移动服务），包括谷歌应用商店、Gmail、YouTube等关键应用。尽管华为推出了自家的HMS（华为移动服务）替代GMS，但在全球范围内，GMS仍然具有很高的市场需求和用户粘性。


4. 网络设备限制：美国政府将华为视为国家安全威胁，禁止美国电信运营商使用联邦补贴购买华为的网络设备。此外，美国还在全球范围内施压，敦促其他国家在5G网络建设中排除华为。


5. 金融制裁：美国政府还对华为进行金融制裁，限制华为及其关联公司在美国的金融交易，使其在全球范围内融资和开展业务受到限制。

这些制裁对华为的业务造成了很大影响，尤其是在芯片供应、软件服务和5G网络设备方面。然而，华为在此期间加大了自主研发投入，努力寻求突破和替代方案。

华为是如何应对技术封锁的？

• 推出麒麟9000S芯片突破5G芯片断供

今年爆火的Mate60系列手机搭载就是这款芯片，华为终于扬眉吐气了一番。

• 推出自研鸿蒙全场景分布式操作系统

• 推出HMS 替代 GMS

当然还有很多自主创新的突破，从这些战略手段来看，华为确实非常值得尊敬的企业，至少给国内众多科技企业打了个样。

从华为被制裁的案例来看，国内其他一众手机厂商谁都无法预测自己可能是下一个华为。那么实现自主可控就显得非常迫切了，除非国内一众厂商放弃海外市场这块蛋糕，但这看起来是不太可能的事情。

万物互联生态蛋糕

我们知道不管是华为还是小米，它们的产品可不仅仅只是手机和PC，还有全场景的IoT智能硬件（包括智能家居、可穿戴设备，平板等等），未来还有智能驾驶汽车业务，比如现在小米正在如火如荼正在进行的造车运动。

小米IoT平台设备接入数据

小米IoT万物互联布局

小米智能汽车

面对如此庞大的设备和连接数，小米需要一套融合的系统框架统一支持全生态设备与应用，要成为未来百亿设备、百亿连接，万物互联的公有底座。这也能理解这为什么小米会推出澎湃OS来替代MIUI，未来构建万物互联的大格局所做出的战略性布局。

然而国内手机厂商的产品布局大致相同，属于强竞争关系，虽说鸿蒙系统较早就发布，但从商业竞争来看，这是另外一个层面的自主可控，让小米、Vivo这些厂商投入到鸿蒙怀抱目前来看是不太现实的，毕竟谁都不想当谁的小弟，或许形成操作系统联盟生态更合适。

写在最后

从最开始时间线开始我们了解到国产厂商纷纷入局自研操作系统，然后通过一张图理解了操作系统的发展脉络，再了解到国产手机厂商是如何发展起来的，Android的进入让国产手机进入智能化时代，我们再具象化理解目前如华为、小米和Vivo这些手机厂商发展的几个阶段。从华为被美国制裁，国内厂商引发的担忧和战略布局万物互联生态，最终为了能够实现自主可控，摆脱外部依赖的风险，纷纷入局自研操作系统。从各家厂商分别分布自己家的自研操作系统，说明这件事相比于自研芯片的难度要小很多。从操作系统发展脉络来看至少是站在巨人的肩膀上，完全自主产权这样的说法听听就好。要撼动Android和iOS的地位，要看开发者买不买单，这么多年所沉淀下来的生态要是这么容易就能够替代，那么当年Windows Phone就不会落寞而去，相比于微软大家觉得我们的差距还有多大呢。

面试官提问

面试官：候选人你好，请解释下面的现象：

1. 数组1000个元素，shift操作和对象delete操作的benchmark 差不多。


2. 数组10w个元素时，shift操作和对象delete操作的benchmark 相差巨大。

场景如下：
数组1000个元素时：shift和delete相差无几

数组100000个元素时，shift比delete慢了100倍

开始表演！

候选人：总的来说，这是因为数组在1k长度时，v8引擎能申请到一段连续内存做shift运算，在利用L1缓存的优势下，速度能和object的delete有得一比。

顺便一提，利用L1缓存思想做性能优化，也是最近游戏界中ECS架构为何能获得如此高的关注度的原因之一。

我们回到咱们前端来讲，口说无凭，眼见为实，让我们直接打开V8引擎源码一睹为快。

第一步、我们找到[].shift相关v8引擎源码。

我们可以看到ArrayPrototypeShift代码会尝试执行TryFastArrayShift函数，若该函数抛出Slow或者Runtime标志，则运行相应的逻辑。

第二步、我们进入 TryFastArrayShift 这个函数继续看，这个函数有两个逻辑：

1. 若没有连续内存，则抛出Slow


2. 若数组长度>100，则抛出Runtime

回到我们案例：我们数组长度如果在1000，则抛出的是Runtime标志；如果在10W，则抛出的是Slow标志。

第三步、查看Slow和Runtime的逻辑。

• 
  

  slow对应的GenericArrayShift函数逻辑如下 ：

  
  
  
  
  • 先把数组转换为对象
  
  
  • 再遍历对象的key，每一个key都往前移一位。（这也是ECMAScript-262规范定义的算法）
    
  
  
  
  


• 
  

  runtime对应的ArrayShift函数逻辑如下：

  
  
  
  
  1. 申请连续内存
  
  
  2. 遍历并移位
     
     
  
  
  
  

最后总结，从上面三步我们确认了V8引擎的执行逻辑：

1. 10W数据，很难申请到连续内存，通常就无法利用L1缓存，导致比较卡慢


2. 1000数据，较容易申请到连续内存，通常能利用到L1缓存，速度较快。
   
   
   
   1. 100长度以下的数组，直接走C++逻辑。
   
   
   2. 100长度以上的数组，走汇编逻辑加速。
   
   
   
   

这也就说明了为什么1000数据和10W数据执行上有一定差异的原因。

注意：ArrayShift函数源码可能有误，也请大佬指点。

PS：这个ArrayShift源码不在v8中，而在汇编中。

PS：这是因为buitin的代码需要在vs上编译出来才能查到相关代码的引用地址，目前比较忙，先分享思路，我后续会进行更新订正。

小结

上诉面试经历是我刚编的，希望能来更多的朋友讨论，毕竟大家对v8源码或多或少有一点陌生的畏难心理，我也如此。本问题实际是来自我交流群的某一次讨论。

不过道理是真的：

平时遇到某些问题，咱们也不妨从V8源码入手分析。

有时候源码比各类文章讲得更清晰。

日积月累，总会有一些意想不到的收获。

参考文章

• chromium开源源码在线工具


• v8引擎array源码解析


• V8引擎builtin源码解析

工作开始,一直被程序猿=修电脑的，厌恶感十足,很可惜打脸来的太快，经历了公司换新电脑，坏了几次，再到工作变动自己搞了新电脑，直到红盘,被迫开启了自己的电脑救赎之旅，本次以这次被迫优化为例,主要想说的是搞程序的解决红盘的问题。

装系统

    之前配备的电脑新拆就一直有莫名重启，移动电源无法使用的情况，随后到了彻底无法忍受的程度，你能想象，你正敲着代码毫无征兆就重启吗，还是一天10几次那种，好在常年随时保存的好习惯避免了重大事故,于是开始了反反复复的系统重装,直到确认是硬件问题,拿去报修，完了之后，当系统安装已经成为了本能，让我彻底的不再恐惧重装系统这个事儿，你们应该都懂，作为一名开发，系统重装这个事儿到底是有多恐惧、

    在这之后,由于工作变动的原因,又仓促的买了新电脑，安装已经驾轻就熟，大概是对纯净版，专业版系统的执着，微PE工具箱让我感觉到装系统和纯净版是一个让人愉悦的事儿,夹带私货的系统让人头皮发麻,我大概经过了这个几个阶段,
系统安装->升级专业版->C盘分区扩容->提权administrator(普通用户对权限引起的bug和问题深度受害者)->驱动/开发工具安装，一顿操作搞下来，我的C盘大概控制在了40G以内,其他软件的安装严格的装在了指定盘符，结果半年多下来，我的120G的C盘坎坎到今天只剩下了5个G,可能这个就是全栈加全干带来的深度后果吧。

C盘红盘过程

     像是npm 、cargo、vs、maven、Android Studio、python等工具C盘盘符产生缓存的问题我已经极度的进行了处理,但从120G-40G=80G的过程，你应该能想象我这大半年都经历了啥、找的c盘批处理完全解决不了我的困难，至于现有的C盘瘦身啥的软件要么收费要么夸大,感觉跟搞程序用的电脑不吻合，完全解决不了啥问题，没办法，我只能挨个的分析文件夹,定位这些内容产生自哪里。

@echo off



echo 正在清除系统垃圾文件，请稍等……



del /f /s /q %systemdrive%\*.tmp



del /f /s /q %systemdrive%\*._mp



del /f /s /q %systemdrive%\*.log



del /f /s /q %systemdrive%\*.gid



del /f /s /q %systemdrive%\*.chk



del /f /s /q %systemdrive%\*.old



del /f /s /q %systemdrive%\recycled\*.*



del /f /s /q %windir%\*.bak



del /f /s /q %windir%\prefetch\*.*



rd /s /q %windir%\temp & md %windir%\temp



del /f /q %userprofile%\cookies\*.*



del /f /q %userprofile%\recent\*.*



del /f /s /q “%userprofile%\Local Settings\Temporary Internet Files\*.*”



del /f /s /q “%userprofile%\Local Settings\Temp\*.*”



del /f /s /q “%userprofile%\recent\*.*”



echo 一键清理系统垃圾完成！



echo. & pause

优化前C盘只剩下5个G，没有先见之明，只能把优化后的结果贴图了,从D盘应该看得出端倪

在这个截图之前，C盘的用户数据大约是60多个G,20多G的优化空间也从此处来的

C盘救赎

• C:\Users\Administrator\AppData\Local如果作为前端，大概率空间的占用是从这里开始的
  


• 如果作为服务端

1. JAVA检查一下你的maven包缓存位置，我开始就设置了，因此没有占据C盘空间，很多都放在D盘了。


2. c# 检查一下nuget的包缓存，可能会很大


3. python的可以检查一下pip相关的包


4. 总之现在的开发工具都很热衷于你的用户数据存储包,你如果分析一下c盘空间会有惊喜发现

• 我之前也搜过很多教程，然并卵，很多压根没考虑过C盘用户数据造成的问题。

     整的比较简单，算是个程序猿群体避免重装系统的一个方案吧，求人不如求己，实在是在重装的边缘挣扎的老哥，可以尝试从这几个方面去做处理,尝试把相关的批处理删除加到以上的脚本中，做个自己的专清小工具，别被各种C盘瘦身垃圾软件折磨了。

结束

马上2023，还是在修电脑的过程中度过，为程序奋斗的一年画上句号、祝愿各位的电脑利器更加畅快随心，在新的一年里创造新的，专属于自己的程序传奇。
----------最后，新年快乐！！！

写在前面：

不知不觉已工作一年有余，好像毕业后的时光是一匹发疯的马，用尽全身气力疯狂向前，人生前半段是缓慢成长，后半程却加速变老。我以为越长大越沉默，没想到我还是一以贯之的废话一大堆。他日再回首时，恐已不复如今的心境，生活是值得记录的，无论好坏呀～

正文：

校招篇：面试官，你好

校招的记忆已然有点模糊了，有点后悔之前怎么没有记录生活。但我记得每次面试时的自我介绍，开场白的第一句话就是面试官，你好。我校招那一年互联网寒冬还不太寒，至少我周围熟悉的同学基本都手握好多大厂offer，所以当时有点小沮丧，总觉得自己菜菜的。也曾想过先去北京工作，不过考虑到我的性格以及离家近，最终还是选择来到成都。其实从小到大我没有什么目标，只是跟着周围同学朋友的节奏学习与生活，不掉队一路走到了现在，我不知道我喜欢什么，只是明确的知道不接受什么，排除掉不接受的，其他范围内我都可。

工作篇：我的前端初体验

依稀记得入职第一天，leader来楼下门口接的我，然后参加早会自我介绍与相互介绍，从此就正式开启了我的搬砖之路。刚入职时有好多不懂的，不懂开会时说的许多缩略词（连PM、PRD、RD啥的都不知道），还不懂从哪里开始看项目代码，对于提交代码、联调、部署、Nginx配置等环节，我就如同面对迷雾，一片茫然。挺感谢leader和同事们的指导与帮助，不仅仅是工作上的，还有帮助我融入团队，因为刚毕业时的我有点轻微社恐，不敢也不好意思多说话（然而现在笑声最大的就是我哈哈哈哈），虽然社恐不过我也是爱笑的社恐，即使很多不会，每天也是笑嘻嘻的，后来年终述职时同事的评价，以及晋升的其中一条理由，都是说我心态好哈哈哈哈哈哈。虽然网上挺多骂我司的，但从我自己的角度来看，我司的应届生培养确实还行，会给你充足的时间学习与成长，长期有耐心不仅仅是空口号。入职3个月时，我每天的工作还是培训和学习，除了已定的学习计划，mentor也会问我还有啥想学的嘛，可以调整。

当我害怕自己做不好时，同事：领导问啥都要说“好，能做到”，反正工作又不是造火箭，不难的，而且不会就问嘛。结果真的不难耶哈哈哈，人最大的恐惧是对未知的恐惧。当我出现了线上事故时，同事：这有啥，我以前还有更严重的，大家都是这么过来的。当我提前想工作跳槽时，同事：我是一年一跳，自从帮leader筛选简历后，才发现我还可以，你也要相信你是比较靠前的。还有好多诸如此类的对话，缓解了我的焦虑与迷茫，偷偷在这里谢谢大家呀。

后来我才开始慢慢接触项目，从最开始修改一个小bug，到后来完成一个小模块的开发，再到现在可以独立负责一个项目的开发上线。与刚入职时相比，现在更大的感受可能是更从容（也可能是开始摆烂哈哈哈），不再害怕新的任务不会怎么办，不再担心我的提问在别人看来是否有点笨笨的，不再纠结晚上早10分钟走会不会不太好……原来技术方案评审、CodeReview、述职等都没有想象中的可怕，很多事经历后才发现不过如此，一切都没关系哒。

生活篇：程序媛的日常

来成都后，经历了第一次震感强烈的地震，经历了高温限电于是居家办公，也见证了从全民防疫到全面放开。新冠全面放开后，leader说：大家如果身体有不适的就请假，别硬撑着，这只是一份工作而已。其他同事基本请了将近2周的假，我申请了一周，其实我只发烧了一天就没啥症状了，中间还去了一趟都江堰玩。后来的二阳、三阳大家都波澜不惊了。

程序员只是一份工作，并不是生活的全部，周围同事有沉迷于养花的，有每周都骑行一天的，也有喜欢跳舞的……至于我，喜欢美食，喜欢小裙子，喜欢一切可爱的东东(๑• . •๑)。成都真的有好多好吃的，至少很对我的胃口，来了以后胖了8斤多呜呜呜。

还有一个绕不开的话题，可能是我一生最悲伤的事情之一，工作一年时我的奶奶去世了，我哭了好久好久，现在提起仍然很难过，个中辛酸就不在此赘述了。

其实还经历了好多事，但有些事只适合收藏。凡所发生，必有来意，不管开心还是难过，都想记下那时的感受，等我老了再来看，当时开心的事我是否依然会笑，当初觉得悲痛万分的坎坷，是否又轻舟已过万重山了(^-^)

最后：

这篇博客是我工作总结系列的第一篇，我希望通过这个平台，记录我在编程之旅中的点点滴滴，记录代码之外的日常生活。如果通过分享我的经历和感受，或多或少能够帮助和鼓励更多的人，那就更好啦。

我想以喜欢的史铁生的一段话结尾～～
我一直要活到我能够历数前生，你能够与我一同笑看，所以死与你我从不相干。

主题

   昨天遇到了一个比较有意思的服务器问题,然而就这么发生了,有些异形问题在多方协作模式下发生,协调甩锅、“坐等靠”,证明等乱七八糟的内容太消磨热情,本次通过一个异常的问题排查分享,来谈谈横向能力的问题,谈谈看法

起因

  事情的起因是这样,运维的堡垒机访问发布一直未发生任何问题,但节后,C系统出现统一认证异常的情况,但其他集成系统均无任何问题,堡垒机同样，这个C系统是正常的、出现了一方正常其他方不正常的情况,一般规律,软件出现问题,这个情况会在某些场景下复现,出现异常情况.

注： 这里补充一下,统一认证起到的作用是保证内部系统的统一，同样承担着接入外部系统以及接入外部认证逻辑的作用，而此时的异常系统为自身系统、因此才有了排查的前提
认证的逻辑,基本上是通过,统一存储服务域下的localStorage,通过ifame隐藏打开指定页,通过postMessage 进行唯一交换进行的（唯一交换的好处是不用源头统一,不用处理乱七八糟的不一致问题）

经过

  基于以上前提,经过异常反馈的情况和代码的确认,剔除了自身逻辑的问题(之所以要确认一次，是为了核实),怀疑问题出自于服务器网络问题,了解到之前一直没有任何问题,C系统中间经过发布,而且都笃定之前没出现过此种情况，因此有了退版本的情况，但情况依然不正常,又找到了我这里,此时有了远程的可调试环境,此时观测到一个特殊标记，在域下明明有token的情况下,通过这种方式获取不到、又核实了其他系统均正常。

  此时的问题已基本定位到服务器上了,但如何在当前条件下快速的验证证明此项结论的正确性,是个问题（业主方服务器相关已经过沟通,绕进了鸡生蛋、蛋生鸡的循环种）。

   过程大略是经过nginx的重新代理访问,达到切换服务的目的,通过路径配置进行更改验证,一番操作下来,验证了外部认证逻辑的正确性,但又产生了跨域问题，原因是C系统的发布用的是绝对地址，配置有服务指定访问地址,源码替换，重新docker镜像发布之后,添加服务的nginx访问后,问题得到了解决,当然过程回溯很容易,中间也是各波折。

如何证明

   说实话,这个问题,我也属于第一次遇到,怀疑可能是安全策略的问题导致的,两个服务器的连通性是没有任何问题的,期间怀疑过nginx配置问题，docker问题,就也不知道怎么证明服务器的什么因素影响到了无法有效获取localStorage,有知道的老哥，也还请赐教、

回溯

  这个问题,现在分析来看,涉及到前端、后端、运维的三重交接处,nginx这个问题，经常被甩来甩去，均认为是运维的职责、而此项问题,运维也无法跟踪排查得出结论，试错的条件和成本较大（并非别人想不到），但问题需要解决,此时的情况下,最小化的验证和解决问题就需要有横向的能力去综合评判、某方面缺失,很容问题就变成三方证明，这个问题不是我的问题,结果显而易见，就跟死锁一样得不到解决,当然这只是很小的一方面、

分析

  每个人的想法和态度,会随着不同阶段变化,在某一个情况下希望努力学习新的知识内容用以变化成薪资、某个阶段需要安稳,又可能在某个阶段变成需要休息和清闲,但这一切的选择，有个前提是事前的努力,运气和时代的洪流并不是一直都有,求而不得是常态,为啥都经历过高考,却想不明白,更高的分数才有更多的选择,未来也才有更多的机会、至于年龄大转行这个问题，这是个人姿态的问题,积极向上总是好的,丧着也不是不能过,各自容忍，毕竟过的都是自己的人生,不是他人的，姿态和态度总要有，那么，你的态度又是啥？

在租房躺尸好几天了，自从周一从滴滴离职就一直待在租房打游戏，瞬间没有工作的负担是真的彻底让我释放了心中的欲望，实际上游戏纯属发泄欲望和转移注意力的工具，我是一个喜欢瞎想的人(这可能就是我胖不起来的主要原因)，放纵完实在是太无聊了，想写点什么。
说实话我这文章写得毫无章法，完全是想到哪里写到哪里，也不想去分门别类了，我觉得真实的想法最重要，如果有语义错误就略过吧哈哈。

说说业务

对这段实习做一个小小的总结，先说一说业务吧，我所在的是滴滴商旅的一个技术部门，主要负责企业版这块的业务，我去的第一天上午看团队规范文档，下午跑项目看代码，第二天接需求，当然是比较简单的需求，后面陆陆续续做了滴滴企业版的小部分 pc 端官网和大部分移动端官网，如果你现在用手机搜滴滴企业版，那么你看到的页面大概率就是我做的，除此以外还有一个经典后台管理项目，其实项目用的技术栈都还好，没有说很有难度的，对于业务来说我觉得最难的应该就是项目的搭建和部署，然后就是技术方案，开发代码确实是最基础的事情了，这几个月完成的代码量并不大，这也完全在意料之中，实习生嘛，能确保自学到东西就行，当自学到一定的程度会很迷茫，不知道下一个进阶的领域是什么，但是在这段时间我逐渐感觉前端的一个瓶颈就在前端工程化，其实早就在学了，但是没有实际的项目经验加上网上教程比较匮乏，大多是讲解 webpack 的基本使用甚至一度让大部分人认为 webpack 就是前端工程化，如果有后端基础我觉得理解工程化那就太简单了，只不过可惜的是参与前端开发的大多是后端经验为 0 的同学，因此对于常年在浏览器玩 js 的我们很难理解在编译阶段能做的一些工作的意义所在，不管是现在的 Node 或是 Go 和 Rust，其实都可以作为一个深入挖掘的方向，至少我感觉业务是真的很无聊，偶尔当玩具写写还行，每天写真的没意思。

除了业务以外认知到一些原来不知道的职场"内幕"。

第一点：面试冷知识

走之前组内一直在招社招的员工，当面试官的兄弟和我说了我才知道，原来面试通一个部门甚至是同一个面试官可能真的会因为面试官心情或者其余外在因素决定你面试是否通过，比如最近部门比较忙，那可能面试也就比较水一点，大概考察没问题就直接过了没有那么多的时间去做横向比较(那我面的部门基本都还是比较闲啊哈哈)，又或者是面试官看你比较顺眼性格也比较符合他的要求，大概率会给一些比较简单的题，这些都会影响面试官的判断从而决定你是否能通过面试最终拿 offer，所以经过这件事之后看开了很多，如果原来你一直不理解平时技术没你好的同学最后能拿到同公司或者同部门 offer，现在应该慢慢也就看开了，一旦挂了及时投递下一个部门，这不一定是自己的原因。

第二点：大厂其实不全是 996

不要被危言耸听，这其实大概率取决于你的部门而非公司，我在的部门经过这两年的形势成功变得小而精，小组的氛围很好，平时开发大家都合作得很开心，不管是导师还是 leader，休息了也会偶尔一起打打游戏，在这个部门我感觉挺好至少没有看到所谓的大厂 996，基本上大家 10 点来，最晚 8 点也都走了。离职的前一天刚好赶上了部门团建于是狠狠地去蹭了一只烤全羊，leader 把商旅的大 leader 请过来了，我对大领导的刻板印象是电视里那种懂得都得，但是没想到和我想的完全相反，大家举杯畅饮吹牛逼，欢声笑语，挺好，，后来想想有可能是因为大家都是技术出身很多时候也都很讨厌那一套，这也是我对互联网最满意的一点，凭本事吃饭，对于出身不是那么地依赖，也不是尔诈我虞，阿谀奉承。

第三点：学会装菜，不要没事找事

作为实习生，懂的都懂，其实在哪里都一样，如果你太着急表现自己，别人就会觉得你过分刺毛，能装菜的地方千万别装逼，艹，我感觉我就是傻逼了，这也许也是我离开的原因之一，作为实习生老老实实完成自己的工作就好，能够保质保量完成任务对于导师来说基本就差不多了，至于一些 pua 话术里面说的额外价值，我觉得对于没有转正的实习生来说毫无意义，反而会自找麻烦，因为并不会因为你原本安排 2 天切完的图你一天切完导师就给你放松自学，很多时候你做的事情是否有意义完全取决于你的导师是否愿意安排有意义的工作给你，所幸我在滴滴完整地参与了项目的技术方案到代码编写直至最后部署上线，里面沉淀了我自己的思考，经过这段实习确实让我受益匪浅。

最后一点是软实力

我觉得这也是我在这段实习中收获到的最重要的东西之一："学会总结，及时复盘"，每次周会给导师和兄弟们讲方案总是要准备很久，会去看很多的自己不知道的东西，以此来让我写的东西显得足够的高大上，记得有一次上线官网出问题了，意料之中做了一个复盘，倒不是说学到了什么代码层面的东西，更多的是让我了解了整个项目从开发到部署上线的流程，这个远远比写代码有意义，不得不说这极大地培养了我的能力，包括新技术的敏感程度，技术的深度以及口才，总结出来的东西一方面加深了自己的记忆和理解，往小了说，让我可以在以后的技术面试中就这段经历侃侃而谈，往大了说，这个让我学会从更高的视角去看问题，不再是盯着代码的一亩三分地，更多的是学会从项目的技术架构层面去看问题，第二是学会表现自己并且及时纠正自己的错误，没错，就是给别人看，自己瞎学总结是没有意义的，你是一个无比努力的人，可是大家不知道那也毫无意义，他能知道的仅仅是你能写上简历的东西，只有向别人更好的展示自己，下一次面试官看到你才会觉得你是一个善于总结和反思的人，程序员这一行也是这样，其实参与一个开源项目远远比你基础扎实更让人刮目相看，尽管你只是为一个看起来无比高大上的开源切了图，对我自己来说我只是把曾经在 wps 或者 typora 的写作 转移到了掘金或者 github，内容并没有太大的变化，这样的事情何乐而不为呢。

最后做一个收尾。

这两天想去北京附近转转，今天跑到了天安门，还是想吐槽地铁站一些人地素质问题，经典的钱包鼓起来了素质教育没跟上来，或者换句话说富起来很多并非接受过良好教育的一批人。

马上快开学了，要回学校拿保研名额，说实话我到现在都不确定哪条路是对了，大厂？还是保研？还是国企公务员？谁知道呢，每个人有每个人的说法，老员工会劝你保研进编制，新员工会劝你尽早进大厂捞钱，每个人追求的往往都是目前最缺失的，也许正是因为未来充满未知所以才无限期待，不然像我这样躺尸一周那该多无聊，脑袋都睡麻木了，这两周陆陆续续也面试了四五家公司，不得不说有大厂背书投简历就是好使，曾经拒绝过我的那些公司都拿到了 offer 然后全给拒了哈哈，不为别的就是解气，基本都是一些 b 格还比较高的独角兽公司，比如教育，云服务器，游戏行业等等，大厂我肯定还是没这个底气的哈哈我依然是大部分大厂的舔狗，不过结果不算坏，下一站是老铁厂了。

不知道是否会有之前一起工作的兄弟看到这篇文章，如果认为我有说得不恰当的地方欢迎指正。

前言

大家好，我是路由器没有路。今天跟大家聊下关于技术人该如何准备晋升答辩的话题。

每到年中或者年底，都会有一波晋升答辩潮。所以在这个时间点，想跟大家聊聊我的个人经验，以及一些对技术人该如何准备晋升的一些启发。

在公司里，我曾参与过各个职级的晋升答辩，也见到过各种各样的答辩现场。就在前阵子，公司部门刚结束了年中职级晋升答辩，我也花了不少时间在团队成员的答辩辅导上。今天我就把一些晋升答辩的技巧和常见的坑跟大家说说，希望能够在晋升之路上对你有所启发。

争取获得答辩机会

现在很多公司都有完善的员工职级晋升管理制度。职级晋升的答辩当然是少不了的了。既然是答辩，就会涉及答辩内容及现场答辩发挥，每一个环节都不容忽视。

也有一些公司的年中或年度晋升是需要在时间范围内先自主提报的，也就是说每个人都有机会，但有些公司是按提名制的，需要你自己去争取答辩机会。下面我们就来说说怎样才能获得提名资格：

• 自身能力能够达到了下一个职级的要求。但有些人可能会认为，要晋升了之后才需要具备下一个职级的能力，这观点是不正确的。


• 公司对人才的要求具备高度的确定性。通常不会冒太大风险去晋升能力不确定的人。因此，你可以提前参考目标职级的要求或同事，关注他们的技术深度和业务能力。


• 主动找领导沟通，确定努力发展方向。对发展方向制定可落地的措施。其实上级对于希望得到成长的员工都是非常欢迎的。

接下来，在争取获得答辩晋升机会后，就可以着手为答辩做准备了。

准备答辩素材

说到述职晋升答辩，当然少不了一份晋升汇报的 PPT。那么该如何准备晋升答辩素材呢？内容当然是包含近一年来的工作成果。

在答辩时，晋升答辩评委通常是跨团队或跨部门的领导。他们往往是不了解你工作成果的业务背景和技术实现细节，因此你需要在短时间内将业务背景、工作成果介绍清楚，这对不善演讲的技术人来说确实有比较大的挑战。

有人可能会说，平时是不是需要记录项目素材呀，我只能说，关系不太大。答辩素材是需要你去实践并产生的，而并非是靠记录。所以我建议，如果有机会，要尽可能多的去参与比较有挑战的项目建设，当然这可能开发难度较大、工作量大、比较累，但相比简单的项目则更容易创造价值、得到收获。

当然如果你没有参与过这种项目，那么你也可以对项目或者线上问题的点作技术深挖。

比如线上有这么个问题：经常性的发生 CPU 占用突然飙高，停顿一两秒后又恢复正常。或者内存间歇性的发生 OOM 了。虽然这对业务影响不算大，很多人可能也不会在意和处理这种问题，最多重启下服务，恢复正常就好，但是如果你去深挖问题背后产生的原因，找到问题的根源和涉及的底层技术点，并在团队内部给大家分享。

这就是很有价值的内容，因为你不仅主动的解决了看似不起眼问题，而且还通过分享的方式让其他同事也明白其中的原因，帮助了其他同学的成长。

根据素材，编写答辩 PPT

在上面准备了答辩素材案例之后，接下来需要根据准备好的素材，编写答辩素材 PPT。这里有几个需要遵循的原则：

1. 在讲述结果的同时，需要把问题点和解决方式也讲清楚。比如在这一年里，你负责了一个大型项目，并成功完成了上线。切记在 PPT 里花大篇幅介绍项目是什么，以及项目成功上线这一结果。因为评委无法通过结果评估你的能力和价值。所以，在介绍素材时，首先要介绍背景，然后介绍这个项目案例中存在哪些问题，你是如何解决的？


2. 结果要有价值和数据体现。说到结果时，很多人习惯讲解项目如期上线等内容，但在评委看来，这是基本的要求，并不是加分项。正确的做法是通过一些上线后的数据说话。比如介绍上线后的系统性能、数据质量等相关内容。这里强调一点，很多研发同学习惯写上线后的一些业务数据。如新增用户数带来的金额、收入等，这类数据其实与产品、业务同学联系更紧密一些。研发应该更多的把关注点应放在技术层面上。


3. 素材要匹配晋升的职级定位。像只有苦劳的内容，比如在赶工期的项目里，加班加点的保证他如期上线，且获得了领导认可等，建议不要写，原因很简单，就是不能体现你的技术价值，这些活，说不好听点，刚毕业的同学都可以完成。

晋升答辩素材 PPT 的一些建议

这里和大家分享下编写晋升答辩 PPT 的一些建议，可以参考一下：

1. PPT 的基本格式要统一。答辩的 PPT 的内容不要太过绚丽。除了要保证基本的工整，细节也很重要，一定要注意审查错字。有些评委会认为错字多，可能写代码 bug 也多。还要注意统一字号，不要一页字大一页字小。此外，还要避免过多动画。注意控制字数，重要的内容标红、加粗。答辩一般都是集中评审，评委一天要评审，很多人没有耐心看太多字。把你想要表达的重点内容标红加粗，这样评委才能快速吸收。


2. 不要放一张大而全的架构图。很多同学都习惯在 PPT 里放一张大家全的架构图。但在答辩时，你只讲解了其中的一小部分。你可能会认为大而全的架构图可以彰显自己系统的完善性。但如果你只讲解了其中一二，其实是很难讲出价值内容，毕竟时间有限，反而容易给评委留下浮于表面的形象。你可以对自己负责实现的那个模块单独拿出来讲，可以采用更优雅的方式进行展现，就具体问题的架构，加上细节问题描述，代替大而全的架构图，才能让评委快速了解问题的背景和解决方法，进而更好的评判你到底做的好还是不好。


3. PPT 上不要露马脚。我曾经遇到过答辩人在 PPT 中写了幂等两个字，我想他写出来的目的是想表示如何实现它，但评委一直对这个点穷追不舍，导致答辩人最终答辩挂了。你写在 PPT 上的每一个字都需要十分熟悉，每一个内容都可能是地雷。

要写答辩稿并加以练习

写完 PPT 后，在正式答辩前的这段时间里，可以不断的加强练习。在练习时也有以下几个建议：

1. 写出答辩稿。很多人没有写答辩稿的习惯，撰写文字稿能够帮助你发现答辩的逻辑是否通畅，还能够框定你的表达内容。咱们前面提到过，答辩是有时间限制的，如果没有固定的稿子，每次发挥的时长都不一样，最后很容易因为超时影响答辩效果。


2. 你要准确按照答辩的时间完整练习至少十遍以上，注意是完整练习。非完整的零碎练习和完整的练习节奏差别非常大。


3. 做预答辩。不同公司的晋升评委组成不同，有的是管理者，有的是技术专家，还有的是管理者加技术专家。因此，在做预答辩练习时，最好邀请相对应的人员辅导你答辩，比如选择你的 leader，相信部门 leader 还是比较乐意的。

调整答辩心态

在答辩将至时，大家都会跟你说，答辩时不要紧张，会影响发挥。但过来人都知道，不紧张好像太难了。下面就说说具体有什么方式可以抑制紧张。

• 首先还是上一节的内容，答辩稿必须写出来，跟着稿子来。人在紧张时，智力和反应能力会呈指数级下滑。没有预先练习，顺溜的稿子你是临场发挥不出来的，只能满嘴跑火车或者照着 PPT 念，效果会大打折扣。


• 一个能够避免紧张的好办法是做最坏假设。紧张是因为想通过晋升，你可以想象一下此次晋升没有通过的场景，你会怎样对待这个答辩结果，如果最坏的结果你都接纳了，还有什么是不能面对的呢？这也能反过来激励你好好准备。


• 回答问题要言简意赅。一般答辩时都会设提问环节，很多时候答辩演讲的很好，但回答差，也会被一票否决，这种情况就比较可惜。作为过来人，我在这里给你提个醒，评委比较喜欢回答问题，言简意赅，直达重点的人印象分都比较高，你可以换位思考一下，评委提了一天的答辩，理解能力也下降的厉害，如果你半天收不到点子上，评委可能会认为你知识储备和逻辑能力薄弱。


• 不会的问题不要直接回答不知道。如果评委临场抛出了一个较难的问题，你可以短暂思考，尝试从几个角度简单回答一下，一定不要直接回答不知道。

总结

最后用一句话总结下：有些人工作五年，但只有一年的经验，但有些人工作一年却拥有了五年经验，那是因为一直在学习、思考和总结。

希望这篇文章能够对你在晋升道路上有所帮助。

前言

所谓语义化版本控制，就是要求你的版本号能按照特定规则及条件来进行约束，以期达到见到版本号即能了解其修改内容的信息或相邻版本间的更新迭代关系。通过阅读本文，你将能够对语义化版本控制规范能够有一个全面的了解，同时也对各平台上依赖版本时的语法有个大体的了解。

背景

在正式开始之前，先问大家几个问题：

我们经常在类似 Github、npm、或者 pub.dev 上看到一些软件或者库的版本号包含如下信息，你是否会疑惑他们之间的区别是什么？分别适用什么场景？

• alpha


• beta


• rc


• release

再看看下面几组版本号，你是否能弄清楚各个版本号之间谁更新更大？

• 1.0.0 1.0.1 1.1.0


• 1.0.0-beta 1.0.0


• 1.0.0-release 1.0.0


• 1.0.0-alpha 1.0.0-alpha.1


• 1.0.0-alpha 1.0.0-rc.1

这次将借着我们在做组件管理平台的机会，像大家介绍一下日常软件开发中的语义化版本控制规范。相信通过下面的学习，上述的问题也能够迎刃而解。

常见先行版本号标识

上面说到 alpha、beta、rc、release 等版本号中常见的一些标识，有一个正式的名称叫做：先行版本号标识。我们可以通过一个生活中的例子来通俗易懂的说明它们之间的差异和联系。

现在假设你是一个蛋糕店的老板，你打算给你的蛋糕店推出一个新品，那么上述所谓的先行版本号就是如下几个阶段的蛋糕：

Alpha 版就是你对于你蛋糕的最终形式还在脑海当中，只有一个蛋糕的基本样子，口味应该是什么味道你心里还没谱，对于装饰如奶油、水果还有蜡烛这些甚至都还没有放在一起（你的软件各功能甚至都没有打通）。由于过于简陋，并且口味还没固定，你还不能将其给你的顾客品尝。你只能自己反复摸索尝试，或者让自己店里的员工对口味、外观以及一些缺陷进行点评。

Beta 版就是你的蛋糕已经开始尝试将部分奶油涂抹在蛋糕上，你已经尝试将所有的元素组装起来，这时候的蛋糕还处于不能拿出去卖的阶段，但口味和后续方向已经基本固定。你甚至可以邀请你店里的熟客来参加小规模的试吃活动，并让他们针对你的这款蛋糕进行全方面的点评。

RC 版就是你的蛋糕已经基本做完了，其最核心的口味和外观已经确定下来，你可以再检查一下蛋糕是否有裂缝、哪些地方需要针对性的进行一些美化或修补。

release 版就是你已经把蛋糕装饰好了，插上蜡烛，撒上曲奇，进行裱花。这时候蛋糕已经完成了，你可以正式的将这块蛋糕摆上橱窗，向大家兜售你的艺术品了。

通过上述的蛋糕制作过程，你应该对这些先行版本号标识有了自己的认知。接下来我们再总结下这些先行版本号标识的常见含义：

相信阅读到这里，上面的第一个问题你已经有了答案。那么明白这些标识的具体含义之后，它到底应该怎么用呢？具体要放在版本号里的哪个位置上呢？接下来我们将通过对语义化版本控制规范的详细介绍，来帮助你解答这些疑惑。

何为语义化版本控制规范

在介绍什么是语义化版本控制规范之前，我们先需要了解为什么需要语义化版本控制规范。

大家先设身处地的设想这样一个开发场景：

你现在的项目现在分别依赖了 foo : 1.0.0、bar : 2.0.0、baz : 3.0.0

同时 foo 组件也依赖了 bar : 2.0.0、baz : 3.0.0

同时 bar 组件也依赖了 baz : 3.0.0

现在你很幸运，项目可以跑起来。

突然有一天因为要修改一个问题，需要升级你项目中 baz 组件的版本号，需要将它从 3.0.0 升级到 3.0.1。但很不幸的是，baz 组件这个小小的版本升级却发生了破坏性的 API 改动。然后你发现你不仅需要修改主工程 example_app 的版本号，还需要升级 foo 组件的版本号以及 bar 组件的版本号。而在你做完这些之后，发现 foo 依赖的其他组件的版本又和你主工程 example_app 项目中依赖的组件的版本冲突了，于是你崩溃了。

这就是软件管理领域中被称作“依赖地狱”的死亡之谷。即当你的系统规模越大，引入的包越多，你就越可能遇到由于依赖导致的问题：

• 如果依赖关系过高，可能面临版本控制被锁死的风险（必须对每一个依赖包改版才能完成某次升级）


• 而如果依赖关系过于松散，又将无法避免版本的混乱（假设兼容于未来的多个版本已超出了合理数量） 当你项目的进展因为版本依赖被锁死或版本混乱变得不够简便和可靠，就意味着你正处于依赖地狱之中。

通过上述的场景我们可以看到，版本号的管理（包括依赖关系的控制以及版本号的命名）并不是一个随心所欲的事情：管理好了，能给你带来极大便利，反之则会给你的开发带来很多没必要的麻烦。那么我们应该如何解决这些事情呢？

基于上述的一些问题，Gravatars 及 Github 的创始人之一的 Tom Preston-Werner 提出了一个名为语义化版本控制规范（Semantic Versioning）的解决方案，它期望用一组简单的规则及条件来约束版本号的配置和增长。这套规则是根据现在各种封闭、开源软件所广泛使用的版本号命名规则所设计。为了让这套理论运作，必须要定义好你的公共 API。一旦定义了公共 API，你就可以透过修改相应的版本号来向大家说明你的修改。考虑使用这样的版本号格式：

版本格式：主版本号.次版本号.修订号，版本号递增规则如下：

0. 主版本号：当你做了不兼容的 API 修改


1. 次版本号：当你做了向下兼容的功能性新增


2. 修订号：当你做了向下兼容的问题修正

先行版本号及版本编译信息可以加到“主版本号.次版本号.修订号”的后面，作为延伸。

以上这套规则或者说系统，就是所谓的”语义化版本控制”，在这套规则之下，版本号以及版本号的更新都潜在包含了代码的修改信息，而这套规则被简称为 semver (Semantic Versioning 简写)。

接下来我将基于 semver 2.01 向大家介绍 这套规则的一些细则。

语义化版本控制规范细则

语义化版本控制规范的细则有很多，有兴趣的同学可以直接到semver 2.01 的官方文档 查看即可，我们这里将其主要内容总结给大家。

X.Y.Z（主版本号.次版本号.修订号）修复问题但不影响 API 时，递增修订号；API 保持向下兼容的新增及修改时，递增次版本号；进行不向下兼容的修改时，递增主版本号。

其实所谓语义化版本控制规范，本来也只是一种约定，它并不能完美适合每一个团队，我们也没必要完全生搬硬套，这里以 Google 官方推出的 mockito2 的版本号为例，可以看到其也没有严格按照细则进行遵守。

所以如果你团队内已经统一认知，了解版本号中每个地方代表的含义，做到“见号知意”：看到 1.0.0-npeFixed.8 就知道这个组件是从 1.0.0 拉出来 为了修复 NPE 的；看到 2.3.0-addFaceIdSupport.1 就知道这个组件是基于 2.3.0 来做 FaceId 支持的；见到 5.0.0-nullSafety.6 就知道这个版本是为了空安全的。那么我们的语义化版本控制规范的目的也就达到了，不是吗？

版本语法

就像人类的烹饪方式从最开始的单纯用火烤到发明陶器之后的烹煮，再到现代社会中基于烤、煮、蒸而演化出来的各类五花八门的烹饪方式一样，语义化版本控制规范在各个平台上也衍生出不同的版本规范和版本语法（Version Syntax），但万变不离其宗。接下来我将大致介绍下常见平台版本语法的异同，期望能对你有所帮助。

由于 PyPI上的版本规范及版本说明符比较特殊且繁琐，这里就不进行比对，有兴趣的同学可以查看PEP 440 – Version Identification and Dependency Specification3 了解更多细节。

有些平台中还有一些特定的其他语法和规则，如果感兴趣，可以点击平台名称的超链接进入对应平台的官方文档自行查看。

相信你读到了这里，对语义化版本控制规范已经了然于胸。那么开篇的两个问题你是否也有了答案，欢迎在评论区留言。

Q&A 环节

经过上面的分享，相信大家对语义化版本已经有了一个整体的了解，那么我们来检验一下你的学习效果，请尝试回答下面几个问题：

Q：“v1.2.3” 是一个语义化版本号吗？

首先，“v1.2.3” 并不是的一个语义化的版本号。但是，在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。在版本控制系统中，将 “version” 缩写为 “v” 是很常见的。但是我们可以通过 npm-semver 来进行处理并转化成语义化的版本。

Q：这么多规则及要求，我该如何验证我的语义化版本是否符合规范或者比较他们之间的大小关系呢？

这里就推荐 npm 的 github.com/npm/node-se…

对于脚本上对版本是否符合要求进行验证，可以使用 semver 2.0 文档中推荐的如下两个正则表达式。

第一个用于支持按组名称提取的语言，PCRE（Perl 兼容正则表达式，比如 Perl、PHP 和 R）、Python 和 Go。参见： regex101.com/r/Ly7O1x/3/

/^(?P0|[1-9]\d*).(?P0|[1-9]\d*).(?P0|[1-9]\d*)(?:-(?P(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:+(?P[0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)*))?$/gm

第二个用于支持按编号提取的语言（与第一个对应的提取项按顺序分别为：major、minor、patch、prerelease、buildmetadata）。主要包括 ECMA Script（JavaScript）、PCRE（Perl 兼容正则表达式，比如 Perl、PHP 和 R）、Python 和 Go。 参见： regex101.com/r/vkijKf/1/

/^(0|[1-9]\d ).(0|[1-9]\d).(0|[1-9]\d )(?:-((?:0|[1-9]\d|\d*a-zA-Z-)(?:.(?:0|[1-9]\d |\da-zA-Z- )) ))?(?:+([0-9a-zA-Z-]+(?:.[0-9a-zA-Z-]+)))?$/gm

Q：万一不小心把一个不兼容的改版当成了次版本号发行了，或者在修订等级的发布中，误将重大且不兼容的改变加到代码之中，我能通过重复发布当前版本来解决问题吗？

首先必须强调一点，不管如何都不能去修改已发行的版本（这点在部分平台已经帮你处理掉了，例如 pub 本身已经做了这种限制）。然后最好根据场景升级一个对应级别的版本来回滚逻辑，最后再将你的重大且不兼容的改版升一个主版本号进行发布。记住，语义化的版本控制就是透过版本号的改变来传达意义。

尾声

至此，我们已经了解了语义化版本控制规范的具体细则，常用的先行版本号标识的含义及应用场景，希望能在大家日后的工作生活当中所有帮助。你还见过哪些常见的先行版本号，你们团队又是如何避免包依赖地狱的，欢迎在评论区补充。感谢大家的观看，再见。

起因

大约一个月前，在学校大病一场（不知道是不是🐑了，反正在学校每天核酸没检测出来）在宿舍休息了整整一周。当时因为发烧全身疼所以基本一直躺着刷刷视频。看了一周倪海厦老师讲的天纪，人纪感悟颇多，中华传统中一些优秀的东西竟然在现代教育下被丢失了而现在的人也只有在身体不得不休息的情况下才会停止内卷慢下来好好思考。

当然有人会说算命啥的都是封建迷信，作为接受了科学思想洗礼的新时代人慢慢也不再去接受那一套，在这里呢我不对这些想法做任何评价。信则有不信则无，存在即合理嘛。

因为疫情原因呢学校早早就给我们放了假，有了更多的空闲时间可以思考在学校没时间想的事情，做一些除开看论文、做项目之外的事

开始

前几天买的服务器刚好到家了，花了几天配置好环境（最重要的是花了大半天解决todesk、向日葵远程黑屏的问题）。今天下午写好代码丢到阳台让它自己慢慢训练去，剩下的时间就开始写今天关于算命的小程序。

六壬法

六壬法

根据倪师讲的，计算现在的农历日期加上时辰就可以推算当前某个想法适不适合去做。以大安开始每次从当宫开始顺时针数，下面是例子。

• 假如今天是农历十二月十号 子时

1. 
   

   首先从大安开始数1到12，结果是空亡

   
   


2. 
   

   再从空亡开始数1到10，结果是速喜

   
   


3. 
   

   然后从速喜开始子丑寅卯这样数，子是1

   
   


4. 
   

   所以上面例子最后的结果就是速喜

   
   

计算过程都理解了怎么写成代码呢。这里需要知道三个条件，农历的月日以及当前的时辰，农历的月日这个地方我借鉴了这篇博客【C/C++】:用C实现输出日期的阴历日子直接复制了主要内容，打表直接计算农历日期，只需要输入当前阳历的年月日。

然后当前时间转为十二时辰也很简单，首先得到当前的小时时间hour，那么十二时辰就是(hour+1)/2<12?(hour+1)/2:0;这里子时记为0。

整个程序如下：

#include<iostream>

#include<string>

#include<ctime>

#include<vector>



std::vector<std::string> MAP{"大安","留连","速喜","赤口","小吉","空亡"};



unsigned int LunarCalendarDay;  

unsigned int LunarCalendarTable[199] =  

{  

0x04AE53,0x0A5748,0x5526BD,0x0D2650,0x0D9544,0x46AAB9,0x056A4D,0x09AD42,0x24AEB6,0x04AE4A



,/*1901-1910*/  





0x6A4DBE,0x0A4D52,0x0D2546,0x5D52BA,0x0B544E,0x0D6A43,0x296D37,0x095B4B,0x749BC1,0x049754



,/*1911-1920*/  





0x0A4B48,0x5B25BC,0x06A550,0x06D445,0x4ADAB8,0x02B64D,0x095742,0x2497B7,0x04974A,0x664B3E



,/*1921-1930*/  





0x0D4A51,0x0EA546,0x56D4BA,0x05AD4E,0x02B644,0x393738,0x092E4B,0x7C96BF,0x0C9553,0x0D4A48



,/*1931-1940*/  





0x6DA53B,0x0B554F,0x056A45,0x4AADB9,0x025D4D,0x092D42,0x2C95B6,0x0A954A,0x7B4ABD,0x06CA51



,/*1941-1950*/  





0x0B5546,0x555ABB,0x04DA4E,0x0A5B43,0x352BB8,0x052B4C,0x8A953F,0x0E9552,0x06AA48,0x6AD53C



,/*1951-1960*/  





0x0AB54F,0x04B645,0x4A5739,0x0A574D,0x052642,0x3E9335,0x0D9549,0x75AABE,0x056A51,0x096D46



,/*1961-1970*/  





0x54AEBB,0x04AD4F,0x0A4D43,0x4D26B7,0x0D254B,0x8D52BF,0x0B5452,0x0B6A47,0x696D3C,0x095B50



,/*1971-1980*/  





0x049B45,0x4A4BB9,0x0A4B4D,0xAB25C2,0x06A554,0x06D449,0x6ADA3D,0x0AB651,0x093746,0x5497BB



,/*1981-1990*/  





0x04974F,0x064B44,0x36A537,0x0EA54A,0x86B2BF,0x05AC53,0x0AB647,0x5936BC,0x092E50,0x0C9645



,/*1991-2000*/  





0x4D4AB8,0x0D4A4C,0x0DA541,0x25AAB6,0x056A49,0x7AADBD,0x025D52,0x092D47,0x5C95BA,0x0A954E



,/*2001-2010*/  





0x0B4A43,0x4B5537,0x0AD54A,0x955ABF,0x04BA53,0x0A5B48,0x652BBC,0x052B50,0x0A9345,0x474AB9



,/*2011-2020*/  





0x06AA4C,0x0AD541,0x24DAB6,0x04B64A,0x69573D,0x0A4E51,0x0D2646,0x5E933A,0x0D534D,0x05AA43



,/*2021-2030*/  





0x36B537,0x096D4B,0xB4AEBF,0x04AD53,0x0A4D48,0x6D25BC,0x0D254F,0x0D5244,0x5DAA38,0x0B5A4C



,/*2031-2040*/  





0x056D41,0x24ADB6,0x049B4A,0x7A4BBE,0x0A4B51,0x0AA546,0x5B52BA,0x06D24E,0x0ADA42,0x355B37



,/*2041-2050*/  





0x09374B,0x8497C1,0x049753,0x064B48,0x66A53C,0x0EA54F,0x06B244,0x4AB638,0x0AAE4C,0x092E42



,/*2051-2060*/  





0x3C9735,0x0C9649,0x7D4ABD,0x0D4A51,0x0DA545,0x55AABA,0x056A4E,0x0A6D43,0x452EB7,0x052D4B



,/*2061-2070*/  





0x8A95BF,0x0A9553,0x0B4A47,0x6B553B,0x0AD54F,0x055A45,0x4A5D38,0x0A5B4C,0x052B42,0x3A93B6



,/*2071-2080*/  





0x069349,0x7729BD,0x06AA51,0x0AD546,0x54DABA,0x04B64E,0x0A5743,0x452738,0x0D264A,0x8E933E



,/*2081-2090*/  

    0x0D5252,0x0DAA47,0x66B53B,0x056D4F,0x04AE45,0x4A4EB9,0x0A4D4C,0x0D1541,0x2D92B5      



    /*2091-2099*/  

};  



int MonthAdd[12] = {0,31,59,90,120,151,181,212,243,273,304,334};  

int LunarCalendar(int year,int month,int day)  

{  

    int Spring_NY,Sun_NY,StaticDayCount;  

    int index,flag;  

    //Spring_NY 记录春节离当年元旦的天数。  

    //Sun_NY 记录阳历日离当年元旦的天数。  

    if ( ((LunarCalendarTable[year-1901] & 0x0060) >> 5) == 1)  

        Spring_NY = (LunarCalendarTable[year-1901] & 0x001F) - 1;  

    else  

        Spring_NY = (LunarCalendarTable[year-1901] & 0x001F) - 1 + 31;  

    Sun_NY = MonthAdd[month-1] + day - 1;  

    if ( (!(year % 4)) && (month > 2))  

        Sun_NY++;  

    //StaticDayCount记录大小月的天数 29 或30  

    //index 记录从哪个月开始来计算。  

    //flag 是用来对闰月的特殊处理。  

    //判断阳历日在春节前还是春节后  

    if (Sun_NY >= Spring_NY)//阳历日在春节后（含春节那天）  

    {  

        Sun_NY -= Spring_NY;  

        month = 1;  

        index = 1;  

        flag = 0;  

        if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

            StaticDayCount = 29;  

        else  

            StaticDayCount = 30;  

        while (Sun_NY >= StaticDayCount)  

        {  

            Sun_NY -= StaticDayCount;  

            index++;  

            if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20) )  

            {  

                flag = ~flag;  

                if (flag == 0)  

                    month++;  

            }  

            else  

                month++;  

            if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

                StaticDayCount=29;  

            else  

                StaticDayCount=30;  

        }  

        day = Sun_NY + 1;  

    }  

    else //阳历日在春节前  

    {  

        Spring_NY -= Sun_NY;  

        year--;  

        month = 12;  

        if ( ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20) == 0)  

            index = 12;  

        else  

            index = 13;  

        flag = 0;  

        if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

            StaticDayCount = 29;  

        else  

            StaticDayCount = 30;  

        while (Spring_NY > StaticDayCount)  

        {  

            Spring_NY -= StaticDayCount;  

            index--;  

            if (flag == 0)  

                month--;  

            if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20))  

                flag = ~flag;  

            if ( ( LunarCalendarTable[year - 1901] & (0x80000 >> (index-1)) ) ==0)  

                StaticDayCount = 29;  

            else  

                StaticDayCount = 30;  

        }  

        day = StaticDayCount - Spring_NY + 1;  

    }  

    LunarCalendarDay |= day;  

    LunarCalendarDay |= (month << 6);  

    if (month == ((LunarCalendarTable[year - 1901] & 0xF00000) >> 20))  

        return 1;  

    else  

        return 0;  

}  



void output(int year,int month,int day,int &d_month,int &d_day)

{

     const char *ChDay[] = {"*","初一","初二","初三","初四","初五",  

                           "初六","初七","初八","初九","初十",  

                           "十一","十二","十三","十四","十五",  

                           "十六","十七","十八","十九","二十",  

                           "廿一","廿二","廿三","廿四","廿五",  

                           "廿六","廿七","廿八","廿九","三十"  

                          };  

    const char *ChMonth[] = {"*","正","二","三","四","五","六","七","八","九","十","十一","腊"};

    char str[13] = "";

    strcat(str,"农历"); 

    if (LunarCalendar(year,month,day)){  

        strcat(str,"闰"); 

        d_month=(LunarCalendarDay & 0x3C0) >> 6;

        strcat(str,ChMonth[(LunarCalendarDay & 0x3C0) >> 6]);  

    }  

    else{

        d_month=(LunarCalendarDay & 0x3C0) >> 6;

        strcat(str,ChMonth[(LunarCalendarDay & 0x3C0) >> 6]); 

    } 

    strcat(str,"月");  

    d_day=LunarCalendarDay & 0x3F;

    strcat(str,ChDay[LunarCalendarDay & 0x3F]);  

    puts(str); 

}





int ChangeHourToPeriods(){

    time_t now=time(0);

    int hour;

    std::tm* t=std::localtime(&now);

    hour=(int)t->tm_hour;

    hour=(hour+1)/2<12?(hour+1)/2:0;

    return hour;

}





int main(){

    int year,month,day;

    std::cout<<"Please input the number of year,month,day:"<<std::endl;

    std::cin>>year>>month>>day;

    int d_month=0,d_day=0;

    output(year,month,day,d_month,d_day);

    int hour=ChangeHourToPeriods();

    int SumAll=d_month+d_day+hour-2;

    std::cout<<"The result is : "<<MAP[(SumAll%6)]<<std::endl;

    return 0;

}

因为每次从当宫开始数也就每次都少数了1，但是由于最后子时以0开始所以只减2。

测试结果(测试的时间是21点亥时)

占卦法

占卦法

还有傅佩荣教授的三组三位数占卦法，这个更多就是易经中的内容太过于深奥，所以直接说计算方法。

三组三位数分别代表下卦，上卦和爻，卦象的三位数对8取余爻对6取余，如果整除就记为除数本身。

然后再去六十四卦中复制打表，最后得到卦象以及爻

整体实现如下

#include<iostream>

#include<string>

#include<vector>





std::vector<std::string> TRIGRAM=std::vector<std::string> {"乾","兑","离","震","巽","坎","艮","坤"};

std::vector<std::string> TRIGRAMMAP {

    "乾为天","泽天夬","火天大有","雷天大壮","风天小畜","水天需","山天大畜","地天泰",

    "天泽履","兑为泽","火泽睽","雷泽归妹","风泽中孚","水泽节","山泽损","地泽临",

    "天火同人","泽火革","离为火","雷火丰","风火家人","水火既济","山火贲","地火明夷",

    "天雷无妄","泽雷随","火雷噬嗑","震为雷","风雷益","水雷屯","山雷颐","地雷复",

    "天风姤","泽风大过","火风鼎","雷风恒","巽为风","水风井","山风蛊","地风升",

    "天水讼","泽水困","火水未济","雷水解","风水涣","坎为水","山水蒙","地水师",

    "天山遁","泽山咸","火山旅","雷山小过","风山渐","水山蹇","艮为山","地山谦",

    "天地否","泽地萃","火地晋","雷地豫","风地观","水地比","山地剥","坤为地"



};



int main(){

    std::vector<int> LowToHigh(3);

    std::vector<std::string> results(3);

    std::cout<<"Input 3*xxx like(111,222,333),means from up to high"<<std::endl;



    for(int i=0;i<3;++i){

        std::cin>>LowToHigh[i];

    }

    

    LowToHigh[0]=LowToHigh[0]%8==0?8:LowToHigh[0]%8;

    LowToHigh[1]=LowToHigh[1]%8==0?8:LowToHigh[1]%8;

    LowToHigh[2]=LowToHigh[2]%6==0?6:LowToHigh[2]%6;







    for(int i=0;i<2;++i){

        results[i]=TRIGRAM[LowToHigh[i]-1];

    }

    results[2]=std::to_string(LowToHigh[2]);



    std::cout<<"下卦:"<<results[0]<<" 上卦:"<<results[1]<<" "<<results[2]<<std::endl;

    std::cout<<"卦象: "<<TRIGRAMMAP[(LowToHigh[0]-1)*8+LowToHigh[1]-1]<<std::endl;

}

这里测试的例子是视频中的数字

结尾

有的时候真的需要一些自己的沉淀时间，不能忘了最初的目标。写这篇Blog也并不是为了宣传封建迷信，而是希望让更多程序圈的人想想当初我们喜欢敲代码到底是为了什么？我们喜欢的是将代码作为工具实现一些有趣的功能，并不是为了水论文或者工作被迫的去东拼西凑弄出一些用处不大的东西。

好多想吐槽的话最终还是打了又删，无法改变现状的时候只能屈服于现状，我相信不止我一人如此。但是请不要忘了 潜龙勿用见龙在田，终日乾乾飞龙在天

流量就是钱，这是一个很原始的认知。但最开始我并不清楚流量和钱之间是如何相互转化的。

微创业，认知很低

大学时期，不管是出于积累项目经验、还是折腾新技术的需要，我有做过一个相对完整的项目。

没记错的话，应该是在20年10月份启动的。当时在宿舍里买了一台激光打印机，做起了点小买卖。所以就发现如果我手动给同学处理订单会非常麻烦。他们把文件通过qq发给我，我这边打开，排版，确认格式没有问题之后算一个价格，然后打印。

所以根据痛点，我打算开发一个线上自助下单，商户自动打印的一整套系统。

百折不挠，项目终于上线

21年年中克服各种困难终于实现整套系统，提供了小程序端，商户客户端，web端。

用户在手机或网页上上传文件后会自动转换为pdf，还提供了在线预览，避免因为格式与用户本地不同的纠纷。可以自由调节单双面、打印范围、打印分数、色彩等参数。实时算出价格，自助下单。下单后服务器会通知商户客户端拉取新任务，拉取成功后将文件丢入打印队列中。打印完成后商户客户端发送信息，并由服务器转发，告知用户取件。

大三下学期，宿舍里通过线上平台，在期末考试最忙那段期间经过了“订单高峰”的考验，成交金额上千块钱。看着我商户端里面一个个跳动的文件，就像流入口袋里的💰，开心。

商业化的很失败

没想到，我自己就是我最大的客户。

期末考完，其实想拉上我的同学大干一场，让校里校外的所有的商户，都用上我们的软件，多好的东西啊。对于盈利模式的概念非常模糊，同时也有很强的竞品。我的同学并不看好我。

我对商业化的理解也源自美团模式，美团是外卖的流量入口，所以对商户抽佣很高。滴滴是打车的流量入口，对司机的抽佣也很高。所以我认为，假设我未来成为了自助打印的流量入口，那应该也可以试试抽佣模式。

而且就算我不能为商户引流，也能解放他们的双手。

当时的我，一个人做技术，做UI，还要做商业计划，去地推，真的搞得我精疲力尽。反正后面觉得短期内变现无望，就去腾讯实习了。

其实也推广了2个商户，但是他们因为各种原因不愿意用。一个是出于隐私合规风险的考虑，一个是订单量少，不需要。

所以基本这个自助打印只能框死在高校。大学生打印的文件私密性很低，但是单价低，量多，有自助打印的需求。还有一部分自助打印的场景是在行政办事大厅，这种估计没点门门道道是开不进去的。

看不懂的竞品玩法

商户通过我的平台走，我这边并不无本万利。

因为开通了微信支付、支付宝支付，做过的小伙伴应该都知道办这些手续也会花一些钱，公司还要每年花钱养。还有需要给用户的文档成转换成pdf，提供在线预览，这很消耗算力和带宽，如果用户的成交单价非常低，哪怕抽佣5%都是亏的。比如用户打印了100份1页的内容，和打印了1份100页的内容，对我来说成本差别很大，前者很低，后者很高。

当时学校里已经有一部分商户用上自助打印了。一共有3个竞品。

竞品A：不抽佣，但是每笔订单对用户收取固定的服务费，界面简陋，有广告。

竞品B：不抽佣，不收用户的服务费，界面清爽无广告。

竞品C：彻彻底底走无人模式，店铺内基本没有老板，店铺是自营或加盟的。

前期缺乏市场调研，后期缺乏商业认知

当时我在没有摸清自己商业模式，市场调研也没怎么做好的情况下。一心想的就是先把东西做出来再说，卖不成自己还能学到技术。毕竟技术这个玩意不在项目里历练，永远都是纸上谈兵。所以对于商业化的设想就是搞不成就不搞了。

我当时的想法就是要“轻”运营，就是最好我的利润是稳定的，不会亏损的。商户如果要用就得每笔订单都给我一笔钱。

后面为了补齐和竞品的功能差距，也耗费了大量心力。让我把项目从一个大学课程设计，变成了一个有商业化潜力的产品。

竞品玩法的底层逻辑

商业化的时候，就发现这个市场还是蛮卷的，不可能直接和商户收钱。竞品B不仅免费，还想着帮商户创造额外收入，做“增益”。那我确实是没有精力去对抗的。

我当时也没搞懂自己的定位，我究竟是tob还是toc。当时想着我精心设计的界面，怎么可以被广告侵蚀？那可是我的心血。所以一心想把产品体验做的比竞品好，就会有人用。但这个定位也很模糊，因为如果商户不用你的，用户怎么可能用你的下单呢。

其实应该to rmb。面向利润开发。美，是奢侈品，那是属于我内心的一种追求，但他很难具有说服力让商户使用。在国内的各种互联网产品，不盈利的产品最后都是越来越粗糙，越来越丑的，都要降本增效。而rmb是必需品，如果不能为各方创造价值，那就没有竞争力。

所以后续分析了一下各家的玩法：

竞品A：传统商业模式，依靠用户强制付费和广告，市占率一般，和第一差了10倍数量级。

竞品B：烧钱模式，免费给商户用，免费给用户用，自己想办法别的渠道做增益，还要补贴商户。市占率第一。先圈地，再养鱼，变现的事之后再说。

竞品C：不单单做打印软件，卖的是项目。一整套自助打印店的解决方案，不知道店铺能不能赚钱，但是可以先赚加盟商的钱。这个对商业运作的要求会很高，我一时半会做不了。

大佬指点了一下我

他说，你看现在什么自助贩卖机，其实就是一个流量入口。至于别的盈利不盈利再说，但是流量是值钱的。

我最近去查阿拉丁指数，了解到了买量和卖量的观念，重新认识了流量，因为知道价格了。

买量和卖量是什么？

买量说的就是你做了一个app，花钱让别人给你引流。

卖量就是你有一个日活很高的平台，可以为别人引流。

买量和卖量如何结算？

一般分为cpc和cpa两种计价方式。前者是只要用户点击了我的引流广告，广告主就得掏钱。后者是用户可能还需要注册并激活账号，完成一系列操作才掏钱。

一般价格在0.1-0.3元，每次引流。

后面我查了一下竞品B在卖量，每天可以提供10-30w的uv，单次引流报价0.1元。也就是理想情况下，每天可以有1-3w的广告费收入。

侧面说明了竞品B的市占率啊，在这个细分市场做到这个DAU……

关于流量，逆向思维的建立

流量是实现商业利益的工具。

工具类应用通过为别人引流将流量变现，内容类应用通过电商将流量变现的更贵。

依靠流量赚钱有两种姿势，主动迎合需求，和培养需求。前者就是你可以做一些大家必须要用的东西，来获得流量。比如自助打印小程序，只要商户接入了，那么他的所有顾客都会为这个小程序贡献流量。比如地铁乘车码，所有坐地铁的人都会用到，比如广州地铁就在卖量，每天有几百万的日活。

培养需求就是做自己看好的东西，但是当下不明朗，尝试发掘用户潜在的需求。

流量，如果不能利用好，那就是无效流量。所以正确的姿势是，发掘目标人群 -> 设计变现方案 -> 针对性的开发他们喜欢的内容或工具 -> 完成变现。而不是 自己发现有个东西不错 -> 开发出来 -> 测试一下市场反应 -> 期盼突然爆红，躺着收钱。

研究报告也蛮有意思，主打的就是一个研究如何将用户口袋里的钱转移到自己口袋里。做什么产品和个人喜好无关，和有没有市场前景相关。

互联网是基于实体的

互联网并不和实体脱钩，大部分平台依赖广告收入，但广告基本都是实体企业来掏钱。还有电商也是，消费不好，企业赚不到钱，就不愿意投更多推广费。

一个人真正的成长一定是极其不容易的，如果想通过一两本书，一两个鸡汤文案，一两场培训就能够获得成长，那简直是痴人说梦，真正的成长一定不会是轻松的，一定是经过一次又一次的跌倒，然后爬起，对所做过的事，所经历的事进行一次又一次的复盘，总结，思考，最终才能慢慢认识到事物的本质，成长不是时间的堆积，也不会因为年龄递增而获得。

思考的难关

毫不夸张的说，思考是这个世界上最难的事，因为思考是要动脑的，而在现在这个信息爆炸的时代，我们想要任何资讯，任何知识，都可以找到现成的答案，所以懒惰就此滋生出来，“都有现成的答案了，我干嘛还要去动脑，我动脑得到的东西也未必有现成的好，而且动脑肚子还消耗能量，这种消耗不亚于体力劳动”，所以思考是最难的，而思考也是获取知识最快的途径。

我们在读书的时候，有些同学看似十分努力，一天感觉都是泡在书本里面的，但是成绩往往都不理想，初高中时，班上有些同学十分努力，对于我这种混子来说，我一定是扛不住的，就比如背英语单词，我发现有一些同学采用“原始人”的方式去背诵，因为我们整个初中换了三四个英语老师，而每个老师的教学方式不一样，其中一个老师就是教死记硬背，英语单词就比如“good”，她的方式是，“g o o d ， g o o d”，也就是一个字母一个字母的背诵，后来因为一些原因，又换了老师，老师又教了音标，但是最后我还是发现，很多同学依旧还是“g o o d”，后来我才发现，因为学音标还需要花时间，还要动点脑子，对于一个单词，还有不同的情况，所以还是司机硬背好，这种方式就是“蛮力”，其实只要稍微花点时间去研究一下音标，然后再好好学学，背单词就会轻松很多，所以初高中英语成绩一直比较好，当然，现在很差，词汇量很少，完全是后面吃了懒惰的大亏。

所以，思考虽然是痛苦的，但是熬过痛苦期，就能够飞速成长，如果沉浸在自我感动的蛮力式努力中，那么只会离成长越来越远。

懒惰的魔咒

说到懒惰，我们可能会想到睡懒觉，不努力学习，不努力工作，但这其实并不是懒惰，每天起得很早去搬砖，日复一日地干着重复的事，却没有半点成长，这才是真正的懒惰。

没有思考的勤快是一文不值的，在现在这个社会，各种工具十分普遍，如果我们依旧保持原始人的工作方式，那么最终只会把自己累死，就像很多统计工作，如果认为自己加班到十二点，人工统计出数据来，老板就会很欣赏你，觉得你很吃苦耐劳，那么这是愚蠢的，因为有很多工具可能五分钟就能够搞出来，可偏偏固执去搞一些没用的东西，这有用吗，还有现在是人工智能时代，各种GPT工具那么爽，直接让效率翻倍，但是我就是不用，我就喜欢自己从头搞，那也没办法。

很多时候，所谓的勤快不过是为了掩饰自己的懒惰而已，懒惰得不愿意去接受新的事物，不愿意去学习新东西，总觉得“老一套“万能。

成长过程中，要不断打破自己的认知，冲破自己的心灵上的懒惰，拥抱新鲜事物，这样才不至于和主流脱节。

环境的影响

在南瓜里度日,就成圆形;在竹子里生活,就成长形。

一个人的环境同样是塑造成长的重要因素。环境不仅指物理环境，也包括人际环境和心理环境。在环境中，我们需要学会适应和改变环境，让环境成为我们成长的动力。

人以类聚,物以群分，如果我们身边的人都是不思上进，终日惶惶，那么长时间下来，我们也会受影响，读书时，如果身边的同学都好学，那么自己也绝对不会变得很烂，相反，如果同学都整天无所事事，那么自己自然也不会好到哪里去，当身边的人都是勤于思考，有想法，那么大家就会有一个良好的氛围，这样成长得就比较快，工作中，如果大家都很有热情，分享很多，学习很多，那么自己也不好意思，自然也会去学习。

但是我们每个人的能力都不一样，所以遇到的环境也不一样，所以很多时候，这并不是我们能选择的，所以说在自己没能力选择的时候，那么就要克制自己，别人混，自己不能混，要时刻提醒自己不能松懈，也不要因为别人的闲言碎语而去”同流合污“，始终记住，一切都是为了自己变得更好，不要太在意别人的看法。

保持良好的心态

在这个浮躁的社会，我们的思想和意志总是被这个社会所影响，特别现在短视频如此火爆，”脉脉上面低于百万年薪不好意思发言，抖音上面人均劳斯莱斯，自己同学朋友又买了几套房“，我们的心态时不时会受到打击，原本平稳的步伐一下变得不稳了，想一步升天了，但是当步子迈大了，可能就受伤了。

我们要时刻提醒自己自己是为自己而活，无论别人是真还是假，和自己关系不大，不要被外界过于影响，这个世界上没有一个人的成功是轻易的，都是在黑暗中努力发光的，如果相信了速成，相信快速致富，那么镰刀造已经嫁到脖子上了，而且还割坏了很多把，一茬接着一茬！

即使此刻多么的不堪，也不要放弃，积累自己，也许有一天，我们再相逢，睁开眼睛看，我才是英雄，他日若遂凌云志，敢笑黄巢不丈夫！

今天的分享就到这里，感谢你的观看，我们下期见！

起因是这样的，我发现我的工资代扣个税，相较以前翻了三、四倍，工资也没给我涨呀，怎么交税还多了。怀疑给我算错了，于是我翻了翻资料找到一张税务总局的个人所得税税率表。

它是这样计算的：

1. 一年分成12个月，交纳税也分为12期



2. 本期应预扣预缴税额 = （累计预扣预缴应纳税所得额 * 税率 - 速算扣除数）- 累计已预扣预缴税额



3. 累计预扣预缴应纳税所得额 = 累计收入 - 累计免税收入 - 累计减除费用 - 累计专项扣除 - 累计专项附加扣除 -  累计依法确定的其他扣除



4. 其中，累计减除费用，按照5000元/月乘以纳税人当年截至本月在本单位的任职受雇月份数计算

举个例子，假设张三每月工资收入20000，各项社会保险金（五险一金）扣除为1000。

在八月份：

• 张三累计减除费用是5000*8=40000


• 累计专项扣除是1000*8=8000


• 排除张三有免税收入等情况，他的累计预扣预缴应纳税所得额为20000*8-40000-8000=112000，


• 累计预扣预缴应纳税所得额112000对应税率表的2级数，所以第八期应预扣预缴税额为(112000*0.1-2520)-累计已预扣预缴税额。


• 累计已预扣预缴税额是前7个月的纳税总和。这样计算，20000*7-5000*7-1000*7=98000 对应税率表的2级数，前7期累计已预扣预缴税额为98000*0.1-2520 = 7280


• 最后，张三在八月份，他要纳税为(112000*0.1-2520)-7280=1400

等等，文章还没完呢，不然又有人怼我纯水了。

我发现网络上像这类纳税计算器参差不齐，计算公式差得离谱，所以决定自己动手撸一个。

个税计算器

由于html、css、js代码内容长，所以我把这部分内容拼接成一张大图，也方便读源码。css布局大量使用Flex弹性布局，不了解的同学先学习一波《和我女神王冰冰一起学display: flex布局》。

描述下js逻辑层：

• 本月工资、社保（五险一金）、专项附加扣除都要乘以纳税期数，分别计算出各自的累计数


• 本月工资、社保（五险一金）、专项附加扣除、累计减除费用累计数相减计算后，就是累计预扣预缴应纳税所得额（累计应缴税款）


• 个人所得税税率表转化成taxRates数据结构，累计预扣预缴应纳税所得额作为参数调用getTaxRate方法返回税率、速算扣除数


• 累计已预扣预缴税额（已缴税款）计算为纳税期数减1，然后以减后的纳税期数再重复一遍上述计算过程


• 本期应预扣预缴税额（应交税额）= 累计预扣预缴应纳税*税率-速算扣除数-累计已预扣预缴税额（已缴税款）

布局兼容到了PC端、移动端，它们分别是这样的：

想要源码的同学，可以访问下面👇链接保存页面即可。

个税计算器在线链接：http://www.linglan01.cn/c/salary/

最后的话

文章中一类的个税计算器，一般计算出来的结果是有偏差的，原因如下：

• 每月工资不是固定的，受KPI影响工资会有一定起浮


• 奖金类的收入也要计算进去，如果有奖金没有计算进累计预扣预缴应纳税所得额，那计算的结果就是会偏差

所以说，个税计算器只能计算出大概的税。

想要准确的计算自己纳税情况，建议下载个人所得税APP。

当工资收入越高，应纳税所得额比重也会增大，比重在到一定程度后，我想我们应该要考虑如何合法避税。

每年年未都会有一次在个人所得税APP提交专项附加扣除，它能一定程度上补返回税额给我们。

另外，开通个人养老金帐户也可以进行一定额度的避税，将来养老滋不滋润重点看这个帐户。我收入还不足以供个人养老帐户，有条件、有需要的同学可以去了解一下。

如果我的文章对你有帮助，您的👍就是对我的最大支持^_^。

学习的心得

记住两个概念，终值和峰值。这是一个心理学专家提出来的。

峰值是指这段体验中的最高峰。终值是指这段体验结束后的感觉。它们都分为两个方向，正向和负向。

在学习的过程中，想体验到正向的终值和峰值，是比较困难的。我如何让学习变得相对愉悦一点呢？穿插自己比较喜欢的，即自己比较擅长的。例如，我每次学习时，都会划分时间片，因为目标越小，压力越小。学习计算机网络，我每次强制自己学 25 分钟，时间一到就立刻停止，即使我还没学完整，此时去做一点自己喜欢的输入，例如去吃点水果零食，看会儿朋友圈。之后就是两种任务来回切换。如果让我连续学习几个小时的计算机网络，我可能很难坚持到最后。

为了避免终值是负向的，我们制定计划的时候，要考虑量力而行，以天为最小单位，不要给自己一天安排太多任务，根据自己的情况灵活决定，每天我们都能总结自己的收获，一目了然。人的大脑，都喜欢看到眼前的利益，我们的远大理想和目标，很难满足大脑。让自己能从每天的学习上得到正反馈。学东西，制定计划，不是为了用某种标准框架自己，我们是为了成长，而不是为了满足框架，专注做事本身。

• 戒掉手机。物理隔绝。


• 收集素材，整理输出。


• 不搞形式主义，直接开始。


• 带着问题去探索，做到记少忆多。


• 要允许自己写出来垃圾，否则连垃圾都写不出来。


• 检测自己获得了什么，也就是做题，实践应用。这样才能实现闭环。


• 加工自己的知识，即仔细的思考、精细化的提问，多问自己“为什么”。

坚持的秘诀

• 要么此时做，要么不再做。


• 不要花大量的时间做容易的环节。
  
  
  
  • 例如学习数据结构与算法，长时间都去学习最基础的数组、链表、队列，这就是伪勤奋。相对的真勤奋，是真的那些让你需要感到思考、克服困难的任务。
  
  
  
  


• 番茄模式。轮换式工作，投资式休息。


• 如果不去做完成这个任务，就要去做更难得任务。
  
  
  
  • 例如学习计算机网络，我不想学习的时候，就告诉自己要去看 CSAPP。
  
  
  
  


• 领先自己的计划。如有偷懒，也可接受，不至于一日崩盘。


• 完成每天的目标后，其余时间，自由安排，一切感兴趣之事。


• 要么自律，要么他律。
  
  
  
  • 什么是他律？大声的告诉你在意的人，你在学什么。
  
  
  
  


• 不想学的时候，也先打开看看。根据惯性定律，改变状态往往是最难的，但维持状态却是相对简单的。

做笔记

笔记有两个方向，四个作用。
关于方向，一个方向记录别人说的话，另一个方向是记录看过的书、视频。关于作用，请看下图。

总结

没有完美的方法论，只有完美的行动，祝愿看完的同学们，都能有完美的人生。

有修养的程序员才可能成长为真正的工程师和架构师，而没有修养的程序员只能沦为码农，这是码农和工程师的关键区分点。

修养指的是：英文能力、提问的能力、写代码的修养、安全防范意识、软件工程和上线规范、编程规范等。这些能力的训练和培养将为后续的学习和发展夯实基础。

在学校的时候，计算机相关专业的同学应该都或多或少都被“大作业”折磨过，没有为“大作业”熬过夜通过宵的大学生活可以说是不完整的。步入公司后才发现，校园里的“大作业”就像玩具一样，需求明确、解决方案明确、最终产品效果明确、甚至还有前人的作品可以参考，而在公司里要做的东西，上面说的特点至少有一个不具备，甚至通通不具备。

而我在字节实习的过程中，所经手的恰恰就是这么一个需求不明确、解决方案不明确、最终产品效果不明确的项目。整个过程中有过焦头烂额毫无进展的时刻也有过欲哭无泪的时刻，还好有我的mentor带着我一路披荆斩棘、过关斩将。

首先和大家讲一下项目背景，当时我在的组是视频会议移动端，经历了近三年大流感的洗礼，相信大家对于视频会议中可能遇到的各种问题如数家珍，包括但不限于没声了、没音了、没画面了、画面卡顿、画面不清晰、画面和语音不同步、同步屏幕时闪退等等等等。作为一个服务企业级的B端产品，出现以上问题时就可能会投诉，然后经过客户成功部门转手到运营再转手到研发这里，研发就需要判断分析一下究竟是我们产品的原因、还是客户本身设备的问题、或者是第三方环境的因素，当用户的量级上来后，这样的客诉就会很多，会严重占用oncall的研发人员的时间以及精力。

我的mentor，一个专注于解决问题、避免重复劳动的人，一个字节范我觉得有E+的人，一个虽然身处移动端但是前后端甚至网络也都会的人，觉得这样很不OK，应该有个工具，能够自动的分析出来客户究竟遇到了什么问题，分析不出来的再找研发进行排查。没有这个工具也不影响业务开发的进展，所以整个项目并不存在时间上的紧迫性，但是呢，有这个工具做出来后肯定会大大降低研发的开发时间，所以项目的必要性还是有的。于是，我作为刚入职的实习新人，这个项目就交给我来做了。

而我，一个还没有从校园中完全出来的新兵蛋子，说实话面对这样的场面是一脸懵逼的，对于要做啥、要怎么做可以说是一无所知，我的mentor在我入职后，让我先了解了解背景，第一周就带着我oncall了，让我知道都可能有样的客诉，手把手给我演示他们正常的排查问题的方式。先了解客户反馈的情况，然后捞出来客户对应时间的设备信息以及设备日志。

说实话，作为一个新人，或者说我本身对于项目有一种畏难心理，碰到一点难题就总是想着往后拖，或者摆烂先不管然后就搁置在一边不想再问津了，但是我的mentor是一个有着坚定信念的人，差不多就是见山开山，见水架桥这种，遇到问题会主动找到相关人员一起解决，可以说就是有那种主人翁，项目owner的意识。于是，我就跟在他的后面，和整个团队的不同角色沟通他们遇到问题时排查的思路，试图总结出来一种通用的流程。在过程中，难免有许多困难，我的第一反应是退缩，但是导师的第一反应是拉会拉上相关人员一起讨论，看看用什么方式可以解决。比如在如何确定设备日志和故障表现的映射关系时，先后调研了多种方式看看相关团队有没有类似的做法以及他们最后实现的效果，包括大数据机器学习、代码状态流转图、自定义规则引擎等多种方式，最后调研后决定采用自定义规则引擎的方式。在实现需求的时候，需要其他团队协作时，他总是直接向前提出自己的需求，而我向一个陌生人发消息之前总要做一些心理建设，总是在担心些什么、害怕些什么，而事实上大家都是打工人，谁也不比谁厉害多少，对方不配合那就拉+1进群一起看看，解决不了就向上暴露问题。

于是，导师披荆斩棘在前，我在后面跟着实现他的设想。我们很快就做出来了第一个版本。通过Python自动化下载设备日志，然后正则匹配筛选出含有特定标记的日志，并对他们的出现频率次数做出判断。因为Python是解释型的语言，所以可以把规则直接写成python语言，用eval或者exec函数进行执行。第一个版本做出来后，导师又积极的带着我去给其他人宣传我们的这个工具。然后根据他们的反馈继续进行相关改进，最后我离职前实现的效果就是@ 一个群里的机器人，告诉他出现问题的ID，他就能自动化的拉下来日志进行排查，然后告诉你他分析的结果，整个交互非常的方便。

一个成功的项目必须要有一个负责的owner，我的导师就向我展示了一个优秀的owner是如何一步步解决问题、排除项目中的难关，如今我也正式成为一名打工人，希望我也能早日如他一般自如的面对工作。

我是日暮与星辰之间，出道两年半的Java选手，相信时间的力量，一起成为更好的自己！

就在昨天 10.17 号，同时收到了三个同学面试的消息。他们的基本情况都是双非院校本科、没有实习经历、不会消息中间件和 Spring Cloud 微服务，做的都是单体项目。但他们投递简历还算积极，从今年 9 月初就开始投递简历了，到现在也有一个多月了。

来看看，这些消息。

为什么会这样？

9 月中旬就开始正式批校招了，而且从往年的数据来看，每年参加秋招的公司大概有 1700 多家，为什么大多数双非本科，到了 10 月中旬才有面试机会呢？

主要原因是软件行业这两年的情况是“供大于求”，一方面是软件公司的业务趋向平稳，招聘需求量不大；而另一方面是应届生逐年增多，而且涌向软件行业的人也越来越多。

a.毕业生增多

从图片可以看出，每年本硕毕业生都在增多，而 2022 年本硕毕业生已经达到了惊人的 1076 万人了，请问咱们国家的就业缺口有这么大吗？

b.业务平稳期

软件的生命周期中有两个大的阶段：

1. 程序开发期：需要大量的人力协同开发一款程序，这时候需要大量的研发人员。


2. 程序维护期：程序开发完了，只有一些小的需求和功能维护等工作，这个时候只需要少量的开发人员就可以搞定了。

而目前大部分互联网公司都已经进入了第二个阶段“程序维护期”，如果程序开发期需要 1000 人的话，那么维护期 50 个人就够了，因为没有很多的功能要做，只是少量修修补补的工作。

c.越来越多人的涌入

2018 年之后，计算机成为中国薪资最高的行业，一举超过了多年霸榜的金融行业，所以大家慢慢全部都明白了“计算机行业赚钱啊”。

所以，综合上述情况大家可以看出，目前的供需关系是：供给方（毕业的学生）远远大于需求方（用人单位），所以目前计算机行业就业严峻是一个必然事件。

如何获得Offer？

既然想拿高薪、既然没有其他的出路、既然已经上了贼船，那么怎么才能在竞争激烈的校招中找到满意的 Offer 呢？

你需要做以下四件事：

1. 海投简历


2. 面试前充分准备


3. 准备好自我介绍


4. 调整好心态&积极面试

1.海投简历

海投简历是指，你要把你能找到的、你能看到的所有和你岗位相关的职位都投递一遍（简历）。

举个例子，例如你在 Boss 上投递 Java 研发工程师的工作，那么就搜索“Java”，然后把你能找到的（看到的）所有公司，且没投递的公司（投递的公司用 Excel 记录下来），全部（打招呼）投递一遍简历。

注意：不用去看 HR 发布的职位要求，很多公司发布的职位要求是比较高的，但大部分情况下，她们都会减低标准，给更多应聘者笔试和面试的机会。所以说，不要看到很高的职位要求就退缩了，任何机会都不要放过，海投就是投递所有和你职位相关的所有公司，一家都不放过，因为他的失败影响不大，但万一成功了就有工作了。

海投简历什么时候结束？
答：海投简历通常是到 11 月中下旬，或拿到第一个保底 Offer 之后，才会逐渐停止，所以做好打持久战的准备，没有任何事是一蹴而就的。

2.面试前充分准备

面试之前，一定要把该公司的岗位技能要求，以及该公司的往年历史真题全部过一遍。

对于自己不会的技能一定要提前学习，还有往年的历史真题也要仔细过一遍，把不会的问题在面试前一定要搞定，防止面试时再次被面试官问到。

3.准备好自我介绍

细节决定成败，面试本质上是“自我推销”的过程。如何在短短的几十分钟内打动面试官，从来都不是一个简单的问题。

所以怎么开场？怎么让面试官对我产生兴趣？非常关键。

好的自我介绍，一定要讲明白以下 4 点：

1. 你是谁？


2. 你会啥？


3. 你有什么成就？


4. 为什么是你？

a.你是谁？

自我介绍的第一步一定是自报家门，例如，我是张三，2015 年毕业于西安电子科技大学，毕业之后一直从事 Java 开发的工作，做过 XXX 公司的高级研发工程师，也很高兴参加贵公司的面试。

校招版本：我是李四，24 届学生，目前就读于西安电子科技大学，硕士学历，就读的专业是软件工程（非软件相关专业就不要介绍你的专业了），很荣幸参加贵公司的面试。

b.你会啥？

技术岗位，最看重的就是你的技术能力，所以这一步一定要好好准备，并详细的介绍你会的技能。

要做好这一步，在面试前一定要查阅应聘公司的岗位要求和使用的技术栈，这样你就能针对性的进行技能介绍了。而当面试官看到一个应聘者的技术栈，和自己公司的技术栈完全匹配的时候，你的面试成功率就大幅提升了。

例如，你可以这样介绍。
我会的技能是并发编程、MySQL、Redis、Spring、Spring MVC、Spring Boot、Spring Cloud Alibaba Nacos、Sentinel、Seata、Spring Cloud Gateway、Skywalking、RabbitMQ 等技术栈。

c.你有什么成就？

学以致用很重要，尤其是校招，你上面说你会，那么怎么证明你真的会你说的哪些技术呢？你使用上述技能获得过什么成就？或做过什么项目呢？

如果你参加过 ACM、蓝桥杯等编程竞技大赛，可以在自我介绍的时候详细的说一下，参赛情况和获奖经历。

如果你没有参赛经历和获奖经历，那么你可以介绍你用上面的技能做过什么项目？

例如，我使用 Spring Cloud Alibaba 全家桶 + Spring Cloud Gateway + MySQL + Redis + RabbitMQ 总共做过 3 个项目，其中有两个项目我已经写在简历上了，等会您有任何关于项目或技能点的问题都可以问我。

d.为什么是你？

前面三点是陈述，而最后这点就要升华了，这也是你进行“自我吹嘘”最后的机会，也是打动面试官最关键的时刻，“峰终定律”就是讲这个事。

为什么要你？就是你要介绍自己的优点了，例如（但不限）以下这些：

1. 我的技术栈和公司非常匹配：因为我的技术栈和公司的技术栈非常匹配，所以来了之后就能直接干活，大大节省了新人培养成本。


2. 我对公司的业务比较熟悉：我之前从事过，或者详细的了解过公司的相关业务，所以来了之后直接能干活，大大节省了业务培训成本。


3. 我做事比较专注：例如，去图书馆看书，经常忘记吃中午饭，等到肚子饿的不行了，抬头一看表已经下午 3 点了。


4. 我自学能力比较强：例如，整个微服务，像 Spring Cloud Alibaba 整个技术栈，我只用了 2 周的时间就全部学会了，并且能用它开发一个 Java 项目，期间遇到的所有问题，我都能自行解决。


5. 我喜欢编程：例如，您可以看我的 GitHub 我每天都有练习和提交代码。

4.调整心态&积极面试

a.避免过度紧张

学的好也要面的好，尤其是第一次面试，紧张是不可避免的事情，所以你要告诉自己“允许自己适当紧张”这是正常的表现。

你越在意什么就越容易失去什么，所以不要过度的在意“自己比较紧张”这件事，它是正常的情况，我工作 13 年了，现在出去面试依然会紧张，所以“紧张”这些事，本身就是人类正常的情绪。

如何缓解紧张？

答：把注意力和精力放在面试官问的问题上，而不是过度的关照自我，面试前深呼吸，面试时把注意力放在自身以外的其他事情上，这样就能大大的减少紧张的情绪。

b.不要害怕失败

越害怕什么就越容易失去什么，所以不要害怕失败，失败乃成功之母，任何事情都是有意义的，即使失败也不例外，它能让你变成更好的自己。

你把每次面试都当成是自我检验和自我提升的机会，无论结果如何，你都能收获成长，越不在意结果，可能结果越理想。

c.不要太在意薪资

万事开头难，尤其是校招第一份工作，不要太在意薪资，你真正赚钱是 3-5 年工作经验之后，所以事情不可能一蹴而就，也不可能一口气吃成一个大胖子。所以先入行比什么都重要，熟练之后才能真正的赚到钱。每个人都是一样，所以不要太在意入行薪资。

小结

软件行业业务趋于平稳，涌入的人越来越多，所以也会越来越卷，每年都是当下最好的一年，所以你只有做到最好，才有可能拿到满意的 Offer。多投简历、面试前做好充足准备、准备好自我介绍、调整好心态、积极去面试，相信做好这些，结果就不会太差。加油，少年。