前言

今天技术博主不聊技术，聊聊生活聊聊情感。先叠个甲，我纯纯乐子人，对婚介所无任何恶意，可能后面还得用上，本次纯纯试探下婚介所是个什么路数！事件源于上周五的一通红娘电话，我一听要给我介绍有钱有颜的小姐姐，直接挂断，这天底下哪有这样的好事。当天下午的时候，又给我来了一通电话，仿佛不知道我给她挂断了一样，基于一些奇妙的想法，我想尝试以及找找素材，我决定让她微信跟我聊。然后因为博主工作比较忙，打了招呼后，就没理她，最关键是到晚上下班后，我也忘了这档子事。周六的下午四点左右，一通电话开启了本次的故事，即使315曝光了相关产业，但是博主依然要冲，就是头铁。

阳光下午的微醺时光

接到电话的时候，我挺疑惑的，这次上来就问我现在是不是有空，出于礼貌，并且我也听出了她是昨天那个红娘，我就没有挂断电话。上来就说，弟弟，我是XX老师，今天来电话主要是聊一下，看能不能进一步推荐小姐姐。说她那里看资料我是97年的程序员，年收入XX，对吗？然后我说是，她就跟我说这里有个小姐姐挺合适的，北京XX工作的，身高165身高，本地的，收入XX。哥们一听就懵了，本地的，心里OS是，那咋遭得住，咱也不是高富帅，纯纯普男。红娘一听就问我有没有考虑常驻北京，然后就问我老家哪里的，我说四川的，她就在资料库里找了找，说真有个四川在北京的，快速给我念了一遍女生的资料。

接着就离谱了，问我怎么称呼？我说姓王，哪里工作，海淀XX公司？红娘直接薄纱，诶，没听过耶( •̀ ω •́ )y，咱们一般服务百度、阿里和字节的比较多。好好好，北京人中龙凤就是多，哥们就是菜中菜，脸都绿了。接着问我加班如何，公司福利啥的，然后说我这个181cm的身高在四川挺高的，她知道的四川男生都不太高来着。然后聊到了哥们的毕业学校，说前两天有个大连理工的女孩，真绝了，大家都这么爱走婚介所吗？我感觉聊到啥，都有女孩能配上，后面说到工作，又聊到一个大二的姑娘还没工作就来找对象了，好好好，走上了人生快车道。

然后聊到了我父母的职业，就说哥们的条件在当地不错，怎么没找上对象？我当时就说到了我的前对象，网恋的，就在掘金找的，一说到这个，好兄弟们，掘金真的能找对象的，不骗人。我的失败不是网恋的问题，纯属我自己的问题，第一次谈吧，不知道咋谈，自己也是摸不准进度，达不到对象的期待，慢慢地就淡了。我也是无脑纯爱战士，这是红娘听了之后的评价，哈哈，不过我觉得前对象确实挺不错的，当时要是硬扛着也能继续，但是我感觉可能是热情燃尽了，她也算是太忙了太累了，无论是生活还是工作，我都挺佩服，主动退出，我感觉应该是我被甩了。不后悔，男人就该当断即断，她也不小了，继续耗着，对她不公平。说远了啊，核心意思就是，网恋也有靠谱的，掘金这质量高的离谱，大家多去相亲角看看。

说着说着，突然红娘聊到了星座，说我应该了解了解星座，也说到了一些星座的小知识。然后顺嘴提到了应该门当户对，不只是能力，还有三观，阶层之类的。接着说道，我条件还行，为啥这么晚谈恋爱，是不是打游戏了？我说姐，没毛病，游戏真好玩！又接着问我单身多久了，身边还有没有介绍的呀，同事父母啥的资源。接着就进入正题了，就说小弟弟你呀，身边没有资源，姐姐这里有呀，你又有点慢热，男人花期这么短，这不得抓紧时间。你没谈就是没有遇到合适的人，圈子太小，北京这边初婚太晚了，25岁才准备开始，你想想四川重庆那边20左右就开始准备结婚了，你回去那就是大龄青年了，不是市场上最合适的那一批了。姐姐之前认识一个大哥，一年给女生花了七八万，环球影城去哈尔滨各种礼物砸下去结果手都没牵上。我？？？这不是大冤种嘛，移动ATM。红娘就跟我说，弟弟你啊，现在这恋爱能力，跟女生比划比划半年结果嘴都亲不上，咱们也不要浪费时间，选对人比胡乱去试强多了。姐姐我这啊，适合你的资源还蛮多的呀，你是B站来的资源，这种比较少，一般只占15%，我们婚介所大部分都是线下和国企政府合作的，所以需要你提供一定的身份和征信资料，因为我们这的姑娘都是认证过的，要对大家负责。接着又说觉得我性格比较好，很坦诚，就问我对女生有没有什么要求，我说年龄上不超过我三岁吧，不抽烟不去酒吧夜店，然后红娘跟我说，你这就没别的要求啦，那还挺低的，然后就问我三观、家庭情况之类的要求，问的很细。然后谈笑间，红娘给我猛推三个女生，嘎嘎读资料，听得哥们心里发慌，动不动就是大厂，家里有矿，问女生条件是否符合我的要求.......我真蚌埠住了，哥们真的配嘛，这条件谷歌，父母地方小领导或者开公司，问我符不符合，好好好，我能傍富婆不？

有一说一，专业红娘就是能聊，我俩聊了得有一小时，最后说让我去线下谈，给我预约了她明早10点半的时间。她想要了解下我这个人的衣着品位、谈吐举止、再做下深度的了解，以及一些信息的认证，同时也给我一些情感上的建议，让我少走些弯路。哥们听到情感上的建议，真的心动了，教练，俺就缺这个，确认了下这次聊天不收钱，就是个单纯的信息认证，我就决定去了。

小雨霖霖的春日午前

因为约好的时间是10点半，我住在石景山，婚介所在朝外SOHO那里，差不多一小时十几分钟的路程，我就九点出发了。到了地方之后，周围有好几个SOHO，没有明显指示牌，而且感觉周日早上那里人也少，当时就觉得奇怪了。因为事前的时候，跟亲友和群里的小伙伴下过军令状，不掏一分钱，实时播报进度，没消息就赶紧救我，所以我倒也没有特别慌。我的想法就很纯粹，想通过红娘的眼睛来认识我在相亲市场中是什么样的，因为我接触的人相对少嘛，所以也算是练练胆，特别是这种情感上的，多积累积累经验总没错。没找到地方，我就拍了个附件的标识给红娘老师，她就指挥我上了楼，上楼之后还蛮吓人的，左边黑的，右边就她家灯亮的。

进门之后有个助理来接待，给了我一张表单去填，相对详细哈，但是身-份-证这敏感信息可以选择不填，其实这会儿我觉得还挺不错，放下了防备，但是打开了录音，哈哈。把我领到一个逼仄的会议室，大概两平米吧，首先给我拍了一张坐着的照片，然后在我填表的时候，说要看下我的征信，简单点的就看芝麻信用就行，看了我的八百多分吧，就说你这还蛮高的。又试探性的问了能不能看下花呗借呗之类的，我寻思着也没多少额度，那就看呗，他一看就挺奇怪的，就说按你这个分数应该有好几万才对呀，你是自己调了吗？我说是呀，没事搞那么多干啥，又问我有没有信用卡，我说就拿花呗当信用卡。又说想看我支付宝里的资产，我寻思着没几个钱，那就看呗。他一看就说，你没炒基金股票啥的嘛，我说没，他就顺着话说，昨天有个姑娘和你一样，也是这样的，她就喜欢这种稳赚不赔的。浅聊了一下就说，去给我叫红娘老师，说红娘老师特别看重我，昨天周六来了好多姑娘，很多都不错的，让我跟红娘老师好好学学。哥们一听这个就来劲了，好啊，就是要这个，我不就缺这套恋爱情商嘛。

热情似火的夏日狂欢

红娘老师进来首先点评了我的头发，有点长还有点凌乱，说怎么还没理发呀。这一点说的挺对，我快一个月没理了，因为头发烫过，又有点长，显得乱。然后又说我好白呀，南方人皮肤就是好，因为我有痘痘嘛，就聊了聊油性皮肤。然后就跟我说想看看我短发的照片，说比较难想象我短发的照片，又说我这个是不是渣男锡纸烫，认出来了我这是前刺发型，感谢我的四川托尼，摩根前刺音容犹在。然后又说我字写的还不错，我说着就没必要硬夸了吧，她说跟其他人对比算是工整了。因为看到我手机壳了，就问我是个什么图案，我给她看了是二次元，她就问我是不是老爱玩B站，是不是博主，我说我哪是啊，只是喜欢看。她就说你声音还蛮好听的有点像肖战，可以整点视频啥的，说不定还能火。我说没那颜值，哈哈，谈笑间我就给她发了几张我的生活照，还有全身照片。她就说没有很胖呀，看着还好，而且家里还蛮干净的，弟弟习惯不错。

我也比较能说嘛，我就说红娘老师怎么不开个号啥的，吐吐槽啥的，比如B站上的XX说媒啥的。她跟我说她们上班很忙的，周一周二休息，平时都是快九点才下班，哪有时间开视频吐槽，都是朋友之间聊聊。然后她就很好奇我之前电话里说的前对象嘛，就聊了聊我前对象的事。因为我是抱着想要咨询的目的来的，所以我也说的相对比较详细，红娘比较在意的点是各阶段时间点、怎么认识的、告白怎么做的、准备了什么样的礼物和GG的理由。大致说了一遍，我觉得我前女友挺好的，无奈博主高攀不上，也没有达到人家的期望，就选择了默默退出。前女友说实话很不错的，情侣头像是我先换她才换的，我说话她也会回我，是我感觉被甩了，也是她有点冷吧，就放弃了。说这些呢，也是跟前面一样，说一下兄弟们要勇敢冲，掘金相亲角也靠谱，哪有那么多渣女，大部分还是好女孩，希望大家都把握得住，找到合适的另一半！

红娘老师跟我说了几个之前来聊的哥们，就说谈恋爱不能太晚，有一些大哥因为圈子比较小，导致来婚介所就想找个合适的姑娘一步到位。但是哪有这么合适的呀，一点攻略和目标都没有，怎么可能一口吃个胖子！我也附和老师说，对啊，心急吃不了热豆腐。然后就跟我说，昨天来了两哥们，一个京东一个百度的，还有00年来找对象的，我一听都懵了，这不都是人中龙凤嘛，这还愁对象，有没有大厂哥们来现身说法的，让小弟我长长见识。聊着聊着，就跟我看了个小姐姐，大四左右吧，想找个大五岁左右工作稳定的哥们，本身条件很优秀的，北交大硕士进国企，所以想要个稳定的生活。反正红娘老师意识就是说，现在女生吧，恋商普遍比男生多个三五年，现在这么卷，考虑得都比较现实。然后就说现在女生都是要求有钱有颜，小弟弟你也没钱，正在发展期嘛，颜的话还算周正，需要打理打理。然后就说想看看我之前的照片，要看我手机，emmm，这时候我没发现这是个套路，应该之前有哥们也做过这事儿。我有开录音嘛，左上角有小标，很烦，红娘应该是特意盯了这个地方，一开始问我怎么不给她看手机，而是直接发给她。我也没在意，她就老找理由看我手机，然后我也不小心被她看见了，她就问我是不是忘了关导航，哈哈，我打了个马虎眼就过了，然后后面过了一阵又看到了，就直接问我是不是录音。我非常坦诚的告诉她就是在录音，有顾虑，然后我也当着她面关了，我俩嘻嘻哈哈也就把这事过了。

想要摸一下秋天的老虎

聊了聊我的家庭，跟我聊了聊她最近咨询过的男生，有成功也有失败案例，反正都是会员。比较隐晦地指出了我这个水平在北京不够看，在成都也不算特别优秀地类型，但是结合家庭和年龄来讲，也算是还不错，至少还有操作空间。我一开始就想知道我在婚恋市场是个什么档次，以及从红娘视角来看我是什么样的，所以我就直球问她了。或许是基于职业素养，或者我问的有点子收费味道了，她顿了一下，从两方面给了我建议，一是从我初恋这段历程总结出来的，说我就是没有技巧的纯爱战士，需要提高情商，反正套话居多。二是不要乱撒网，要精准定位，选择自己合适的人，基于星座啥的跟我聊了半天，我这金牛座适合什么样的人。然后就说我这个改是来不及了，27也不小了，没救了，就从选对人开始，然后就开始围绕她们的服务开始聊。

总共聊了得有三小时左右吧，前一个半小时唠家常，根据你的资料聊细节，时不时说说女生的资料。后面就开始猛攻，围绕中介所的两项核心服务，一是心动女生匹配筛选，二是全程跟踪指导，结合真实案例开始跟我介绍。比如女生这个，真的是拿了五六份女生的资料，就跟简历似的，问我有没有眼缘，又跟我说这几天来了什么什么姑娘，有还没毕业的，有点子真实案例掺点焦虑的感觉。比如全程指导，给我看了她手下成功的案例，放了点截图和视频啥的，让我看效果。

中间插一下哈，聊聊我对红娘的看法，真的很强。能干这行的都是社牛，还有很强的气场，我确实能感觉出来她是很快乐地在撮合，觉得是在做正确的事，收的钱理所应当。说真的，要不是我去之前就抱着分文不出的想法，她一顿吹我真给了，业务能力太强了。她聊天的话，目的性很强，总是往婚介服务，这个筛选方向去带，会弱化你的劣势，不会很明显地贬低你，但也不会特别夸耀你的长处，就把你当作一个朋友一样，所有都是围绕我们能给你找一个天造地设的对象这一核心点展开。说实在的，动不动认个亲弟弟这操作也太骚了，见面第一次，这社交强度直接拉满，很热情。

聊聊收费啥的，好像每个人都不一样，给我的标准是1年49990，半年29990，3个月19990，后面我说不用了，拉扯半小时，认我做亲弟弟，然后给我亲属价对赌协议，先交10100等成功了再补9890或者给她介绍2个就不用给尾款了。最后博主一是领导在催干活，嘎嘎电话，朋友在催吃饭，也微信电话不停，就想润了，红娘就说要不先交500定金，不行再退，我确实没这想法，就发了50红包给姐买奶茶。反正这吃相一出来就有点尬住了，我这确实是很好说话，没有一甩脸子直接走了，就这么耗着。说实在的，我确实觉得人家说了3小时，这总得有点收益，50块钱在北京不是什么大钱，但是我本来也是抱着聊聊的想法，没想到上来就这么狠，直接2W起步，真恐怖，润了润了。

又到了白色相簿的季节

最后聊聊博主的收获，有用信息不多哈，大部分是一些套话，这大概就是免费内容吧。她给我看了客户的跟踪记录，红娘会全程指导男生的行为，会推一些书或者情感内容啥的，当然，这都是收费内容。怎么说呢，这一次三小时的激烈battle，我也能感觉出来，我还是该在情商上做一些提升，红娘有提到男女之间的情商和朋友之间的情商是两码事，说我上一次挂了就是技巧不足，竟然半年连嘴都没亲，这还是人？？？跟我说她们那里的都是一个月速通，我这样的已经没救了，好好好，这年头纯爱战士就是鲨BEE。

我其实对这家婚介所没啥意见，我也是想着既然聊上了那就去看看呗，没想到第一次这强度就这么大，哈哈，离谱。我看了下女生资源都很不错，男生也很厉害，都是人中龙凤，不知真假。XX爱恋，她跟我说主要还是线下，我的资料是从B站过去的，就离谱，不知道我填啥了，一开始就知道我的性别年龄和手机号，其他一概不知，可能是我资料被卖了吧，根据年龄给我推送的。喔，对了，说是每周给政府或者国企办公益相亲会，我之前倒是没怎么了解，不知道她家是不是在北京属于厉害的了，还是纯诈骗，摸不清楚，这也是我没交钱的理由之一。因为我在B站上看过XX说媒嘛，我就问她，怎么不开个自媒体号吐吐槽，还能挣点外快。哈哈，这姐非常真实，说剪辑、化妆、文案太累了，线下就够赚了，没必要混线上。

写着写着，突然想起来这姐还说过我一个坏毛病，说我没有底线，有点舔狗，女生一般不喜欢姿态放低的男生，希望我有点神秘感，或者说装一点。哈哈，下一个更好，咱们有的是资源，看得出姐是相当洒脱，成年人不改变只选择这话倒是诠释的清清楚楚。还说我应该有个底，不要一上来就跟人托底，比如她一看我就是个逗比的人，结果跟我一聊还真是个嘻嘻哈哈的乐天派，这样就没有神秘感，她说女生一般不太喜欢这种。

最后的最后，她把经理叫来了，做个回访，我是很欣赏红娘老师的，因为我这次没谈成业绩我也是相当抱歉，所以当着经理面说了很多红娘的好话，没有谈成也确实是我的问题。哈哈，经理直接问我，免费给我介绍同意不，我都懵了，这太狠了，我也没答应，这种形式还是太超前了。相亲说实话还是摆条件，看见女生资料搁面前一遍遍刷，人中龙凤太多啦，哈哈，不由得想起了我初恋也就是我前对象，我也得好好努力呀！

锵锵！我闪亮登场！

今天突然想到，好像真是在B站一个UP那里填过资料的，是我错怪人家了。红娘这姐姐挺有意思的，我是真的觉得她干这行很快乐，她还问我对这行有没有兴趣，哈哈。这种撮合有情人就能收钱的事可太行了，我也蛮喜欢这种做好事的感觉。不过骗人的也不少，315曝光过了，大家也长个心眼吧，学会识人。

最后做个总结吧，博主从昨年开始琢磨男女大事，经历了人生第一次相亲会、初恋、婚介所，虽然都只有一次，但都是挺有意思的。哎，母胎SOLO真的太难了，不会谈啊，盲目冲锋的纯爱战士真的不是版本答案了，红娘老师也跟我说，女生感情上比男生早熟三四年以上，难难难，但是博主依旧对生活抱有期望，哈哈，毕竟我是个乐子人。

我的人生信条是，我要让这痛苦压抑的世界绽放幸福快乐之花，向美好的世界献上祝福！！！

写作背景

写背景之前先放一张网图，侵删。

有一个活跃应用包含了2个相似业务场景，所以共用了底层模型。

1. 前期在开发过程中，强行将两波研发组正在研发的产品底层模型和能力统一。底层能力统一遇到了挺多问题，比如数据库字段适配、转换、冗余；repo 层 SQL 条件拼接用了大量 if else，导致建索引困难…等等。


2. 一些历史原因，该应用经手了十多个研发，代码是垒了又垒，出现一个很有规律的现象，大家都是只增代码不减代码。


3. 代码性能随着数据规模增加不断降低，靠着优化补丁缝缝补补支撑着，业务高峰期经常被运维同学拿着 SQL 光顾。

重构该项目想法不止10次，想逮着机会拉着各方大佬商讨重构事项，因为重构对业务是没有收益的，并且重构难度相当大，所以迟迟没有下定决心。

最近刚好产品需要打磨下一个版本，需要挺长时间，几个后端研发商讨要不重构吧。嗯，我想可以，于是我找上前端负责人沟通拉他入伙，找上前端之前测试已经同意了。

于是一场重构拉开序幕了。

1. A 同学负责梳理和收敛模型、数据订正、向上提供能力。


2. B 同学负责梳理前端接口，编排底层能力，提供原子接口给前端(最复杂，直接面向Web端业务，接口有很多特殊逻辑）。


3. C 同学负责引擎层，和一些计算类逻辑，另外就是打打杂。

重构

大型重构耗时不说还费人力，搞不好重构完你拿不到业务结果，所以重构前你要明确收益是啥？无非就是下面几种

1. 性能提升产品体验更好；


2. 简化架构并提升架构扩展性（后面迭代基于重构后架构能快速开发上线）；


3. 历史债清理，历史代码可读性差维护费劲(大部分程序员看别人代码都是这样吧）。

我们是三种情况都中，下面简单总结重构的思路吧。

模型梳理和能力收敛

底层模型我认为最重要，要可靠、稳定且变动少，如果在迭代中你的模型变来变去，上层业务根本开发不了或者边开发边改，到项目收尾就是另一坨屎山。

上层业务是根据底层模型长出来的，所以一定要跟产品讨论确定最终模型，若有好的竞品参考更好了，你的设计可能会看的更远，以防过度设计，架构设计满足未来1-2年迭代即可。

模型设计需要预估数据规模，数据规模决定是否采用分库分表/分区表。如果不好预估采用简单原则先上线看看业务效果，但基础框架这些能力一定要预留好，上量后能快速开发上线。

底层模型和能力收敛了，上层业务编排对能力的复用性更高。ps：这次模型梳理我们干掉了 2 张千万级表。

数据订正

模型梳理和收敛一般会涉及数据订正，特指线上模型对应的数据割接在新模型。一般会有下面几种方式

1. 写脚本从数据库捞数据订正数据，一般会先 select 查询到内存中，重新组装数据再 insert 新模型。数据量小场景完全可行，但数据量大是跑不动（已踩过坑，线上数据几天没跑完最后发布失败）。


2. 写 SQL 直接操作数据表，简单的数据处理场景、数据量小场景可行，数据量大场景不可靠，容易超时并且会有数据库稳定性风险，另外订正逻辑复杂是搞不定的（已踩过坑，线上跑数据失败导致发布失败）。


3. oplog、binlog.... 日志采集同步到消息队列（kafka、pulsar 等），启消费组消费订正数据（我最常用也是最可靠的），数据量大的场景特别爽，处理存量数据的同时还能保证增量数据同步处理。

数据订正是清理过期数据最佳时期。假若平台过期数据体量大，这部分数据不迁移新表，留在历史表中当备份就行，亦可快速恢复。ps：本次重构过期数据预估是千万级别。

API 接口

接口是你对外的门面，应该提前规划明确，不能新增需求就干一个接口，需求迭代到后期，大大小小接口加起来几十上百个维护成本是很高的。

我们一般会按照下面几个原则：

1. 按操作分类比如：增、删、改、查是一类，只会定义4个接口上游业务方调用需传入 source 区分调用源。


2. 接口保持简洁，不耦合非当前业务的复杂数据。比如业务上需要回显组织架构数据（员工名称、部门、员工上级等），这类数据需要业务方自行编排组织架构 byids 接口。


3. 接口具备降级能力，不能因为接口内部编排的非重要接口、逻辑报错导致整个接口不可用。
   降级指将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。

这次重构 B 同学和前端面临了巨大压力，接口多、混乱、逻辑不清晰，决定梳理业务逻辑按照上面 3 个原则重写接口。

代码重构技巧

代码重构也是本次重构重点，经过长时间迭代已经闻到了坏代码味道。怎么重构早就心中有数，很早就盘点和推演了，下面是我常用的一些重构技巧，这些技巧都是非常经典的，如果看过「重构改善既有代码设计」应该都不陌生。

内联临时变量

项目里有一些临时变量，只被简单赋值了一次。将这些临时变量的赋值语句直接嵌入到使用它们的地方，而不是创建一个新的变量来存储这个临时值。

func Publish() error {

  // ... 省略一部分代码

	err = Producer(context.TODO()).ProducerOne(&obj)

	if err != nil {

		return err

	}

	return nil

}

临时变量内联改造后👇👇👇

func Publish() error {

   // ... 省略一部分代码

	return Producer(context.TODO()).ProducerOne(&obj)

}

魔幻数字"（Magic Number）

指代码中使用未经解释或定义的常数值，这些值通常没有命名并且没有给出其含义或用途。这样的数字使代码难理解和维护，项目里面很多魔幻数字使用。

func Update(ids []string, nodeID string) {

	// ... 省略一部分代码

	Report(context.TODO(), nodeID, "6", ids)

}

要解决魔幻数字比较简单，只需你把业务逻辑理解定义成枚举就可以了，这个数字6表示朋友圈类型，魔幻数字改造后👇👇👇

type TargetType int



const (

	QWMoment TargetType = 6

)



func Update(ids []string, nodeID string) {

	// ... 省略一部分代码

	Report(context.TODO(), nodeID, QWMoment, ids)

}

删除注释、未引用代码「俗称死代码」

根据我 review 代码的经验，不少研发同学会把已注释、未引用代码保留，这部分代码是非常影响后面维护者思路的，我们在重构过程中遇到不少这类代码，来来回回找测试和研发确认为什么会保留，哪些业务常用在用？带来了不小负担。（尤其是越上层的死代码引用了一堆下层代码，比如controller 引用 service，service 再引用 repo ，若重写 repo 非常上头）

所以我强烈建议，一旦代码不用了，应该立刻删除。若删除这部分代码后面迭代可能会使用，我建议重新开发。我列一些删除代码后的收益。

1. 清晰度和简洁性；


2. 减少维护成本；


3. 减少冗余和混乱；


4. 避免误导。

卫语句取代条件表达式

卫语是用来提前结束方法执行的结构。通常情况下，卫语句用来检查某些前置条件是否满足，如果条件不满足，则立即退出方法执行，以避免进入后续的代码块。有助于减少代码嵌套深度，增加代码的可读性和可维护性。

按照我的经验，卫语句应该有下面 2 种情况：

1. 两个条件分支都属于正常行为；


2. 有一个条件分支是正常行为，另一个分支则是异常的情况。

我们review过的代码一般是第二种情况比较严重。

func Recall(exclusion constant.ExclusionType)error  {

	if exclusion == constant.OnlyOneExec {

		if detail.TargetID == "" {

			return nil

		}

		_, err := repo.Update(ctx,....)

		if err != nil {

			return xerrors.Wrapf(err, "Update")

		}

	}

	return nil

}

调整后代码👇👇👇

func Recall(exclusion constant.ExclusionType)error  {

	if exclusion != constant.OnlyOneExec {

		return nil

	}



	if detail.TargetID == "" {

		return nil

	}

	_, err := repo.Update(ctx,....)

	return err

}

变量改名

好的命名能让读者一目了然，变量名可以很好的解释一段代码干了什么。我发现项目里面很多字段名、类名、包名很模糊，很难理解具体的业务（包括我自己也经常命名错）。

下段代码是我整理的坏的命名

TaskCommand 是 Kafka 消费者依赖的实体，收到消息后根据 Type 和 Status 撤回数据。但你看 struct 名 跟撤回没有任何关系。

// TaskCommand 任务相关命令

type TaskCommand struct {

	Type   int8 `json:"type"`   // 执行类型

	Status int8 `json:"status"` 

}

所以我选择把 TaskCommand 替换成跟业务更贴切的名称👇👇👇

type RecallDataParam struct {

	Type   int8 `json:"type"` // 执行类型

	Status int8 `json:"status"`

}

引入参数对象

以一个对象取代一些参数，可以改善代码的可读性和维护性，尤其是在函数参数列表较长或者参数之间存在复杂关系的情况下。将一组相关的参数封装到一个对象中，将该对象作为函数的参数传递，简化函数签名并提高代码的清晰度。

在一些历史比较久的代码里过长参数真的很常见，从 controller 透传到 service 再透传到 repo 层，代码复用性也非常低。

type AppImpl struct {

}



func (app *AppImpl) List(tp []int, status, page, pageSize int, keyword string, domain string) ([]interface{}, error) {

	// .... 省略业务逻辑

	return nil, nil

}

上段代码我一般会在 controller 和 service 中间抽一个 dto 实体。👇👇👇

type AppImpl struct {

}



func (app *AppImpl) List(listDTO *ListDTO) ([]interface{}, error) {

	// .... 省略业务逻辑

	return nil, nil

}



type ListDTO struct {

	tp                     []int

	status, page, pageSize int

	keyword, domain        string

}

提炼类

一个类应该是一个明确的抽象，它的职责是单一的，只处理一些明确的职责。

提炼类一般是下面两种情况

1. 需求是在不停变化和累加，你会这儿加一个函数，那儿加一个方法。导致某些文件或者类非常臃肿。


2. 相似的能力，散落在不同的业务板块，涉及的开发都在重复建设，有一个需求建一个烟囱。

典型案例是项目中事件上报能力，本应该是一个通用能力集中收敛上报代码，据我梳理代码散落在多处，上报触点有 10 来个，每个触点都在写同样的上报代码，假设某一天上报逻辑变化必须在这 10 多处做出许多小修改。

所以我决定把上报能力收敛在一个类，将复杂逻辑封装到该类，定义有限参数露出给使用方。

上报通用能力封装在 EventTracking。👇👇👇

// Tracker 埋点上报接口

type Tracker[T any] interface {

	EventTracking(in T) error

}



type CMSReachDTO struct {

}



type CMSReachTracking[T any] struct {

	ctx context.Context

}



func NewCMSReachTracking[T any](ctx context.Context) Tracker[*CMSReachDTO] {

	return &CMSReachTracking[T]{ctx: ctx}

}



func (t *CMSReachTracking[T]) EventTracking(in *CMSReachDTO) error {

	// ....逻辑省略



	return nil

}

提炼超类

如果两个类在做相似的事，可以利用基本的继承/组合（GO 只有组合）机制把它们的相似之处提炼到超类。一般会把字段、方法都搬移过去。

我遇到的 case 在 entity 上会多一些，比如下面这两个 struct。

type Task struct {

	ID           string `gorm:"column:id"`

	Tenant       string `gorm:"column:tenant"`

	SubDomain    string `gorm:"column:sub_domain"`

	IsDel        int8   `gorm:"column:is_del;default:1" `

	CreateAt     int64  `gorm:"column:create_at;autoCreateTime:milli"`

	UpdateAt     int64  `gorm:"column:update_at;autoUpdateTime:milli"`

	CreateUserID string `gorm:"column:create_uid"`

	UpdateUserID string `gorm:"column:update_uid"`

   // ... 省略其他字段

}



type TaskDetail struct {

	ID           string `gorm:"column:id"`

	TargetID     string `gorm:"column:target_id"`

	Tenant       string `gorm:"column:tenant"`

	SubDomain    string `gorm:"column:sub_domain"`

	IsDel        int8   `gorm:"column:is_del;default:1" `

	CreateAt     int64  `gorm:"column:create_at;autoCreateTime:milli"`

	UpdateAt     int64  `gorm:"column:update_at;autoUpdateTime:milli"`

	CreateUserID string `gorm:"column:create_uid"`

	UpdateUserID string `gorm:"column:update_uid"`

   // ... 省略其他字段

}

上面这段代码他们都有共性的代码，并且我非常熟悉业务是不可能更改的，所以我会提炼一个超类。👇👇👇

type SuperParty struct {

	Tenant       string `gorm:"column:tenant"`

	SubDomain    string `gorm:"column:sub_domain"`

	IsDel        int8   `gorm:"column:is_del;default:1" `

	CreateAt     int64  `gorm:"column:create_at;autoCreateTime:milli"`

	UpdateAt     int64  `gorm:"column:update_at;autoUpdateTime:milli"`

	CreateUserID string `gorm:"column:create_uid"`

	UpdateUserID string `gorm:"column:update_uid"`

}



type Task struct {

	ID string `gorm:"column:id"`

	SuperParty

	// ... 省略其他字段

}



type TaskDetail struct {

	ID       string `gorm:"column:id"`

	TargetID string `gorm:"column:target_id"`

	SuperParty

	// ... 省略其他字段

}

当然某些场景还有一些配套的方法，也可以一并搬迁到 SuperParty 里面。

提炼方法/函数

提炼函数/方法是我常用的一种手段，我不喜欢长函数/方法。我看过一个说法，一个函数/方法应该能在一屏中显示，我一直奉为经典语录（我写的代码函数/方法基本不会超过一百行）；另外只要有一段代码不止被用一次，我就会把他们单独放进一个函数。

有这样一个场景，调用外部 byids 查询员工信息获取 externalId 执行业务逻辑，封装外部接口调用。

type Client struct {

	ctx context.Context

}



func (c *Client) GetByIDs(id []string) ([]*User, error) {

    // ....省略业务逻辑

	return []*User{}, nil

}



type User struct {

	ID         string `json:"id"`

	ExternalID string `json:"externalId"`

}

下面是业务方使用 GetByIDs() 方法

func TestGetUserByIDs(t *testing.T) {

	ids := []string{"1", "2"}

        

	client := &Client{}

	users, err := client.GetByIDs(ids)

	if err != nil {

		panic(err)

	}



	l := make([]string, 0, len(users))

	for _, v := range users {

		l = append(l, v.ExternalID)

	}



	// ...执行业务逻辑

}

 业务方调用 GetByIDs() 方法，遍历 users 获取 ExternalID 执行业务逻辑。在业务上这种操作还真不少，所以决定优化复用一部分代码。👇👇👇

1. 定义 Users 切片。


2. GetByIDs() 方法返回 Users。


3. Users 提供 GetExternalIDs 方法。

type Client struct {

	ctx context.Context

}



func (c *Client) GetByIDs(id []string) (Users, error) {

    // .... 省略业务逻辑

	return Users{}, nil

}



type Users []*User



func (u Users) GetExternalIDs() []string {

	out := make([]string, 0, len(u))

	for _, v := range u {

		out = append(out, v.ExternalID)

	}



	return out

}



type User struct {

	ID         string `json:"id"`

	ExternalID string `json:"externalId"`

}

下面是业务方使用 GetByIDs() 方法

func TestGetUserByIDs(t *testing.T) {

	ids := []string{"1", "2"}

        

	client := &Client{}

	users, err := client.GetByIDs(ids)

	if err != nil {

		panic(err)

	}



	l := users.GetExternalIDs()

	// 执行业务逻辑

   // ....

}

代码空行

我非常非常不喜欢代码从头到尾写下来没有任何空行，难以阅读让读者很难提起兴趣。空行在我看来是必不可少的，在代码中使用空行来分隔不同功能或逻辑块之间的代码，空行使得代码更易读。

下面段代码是没有任何空行的，代码比较短阅读起来可能并不费劲。

适当进行空行优化后👇👇👇

上段代码先不关注逻辑，优化后可读性更强了，代码分为3段逻辑，每段逻辑都有各自的职责。

空行是用来区分不同逻辑块的，过度空行也会影响代码阅读，如下：

引入设计模式

设计模式是被大佬们验证过的、开发经验的总结，可以帮助我们更好地组织和管理代码，并提高代码的可维护性、可读性、可扩展性和可重用性。下面链接是我最常用的设计模式，也在这次重构过程中全部用上了，有兴趣可以看看。

最后总结

1. 如果你的项目不是外包项目（交付了就完事儿），一定要多回头看看自己写的代码，跟着版本迭代持续优化和改进，你才能进步。另外对代码一定要有洁癖。


2. 重构是持续的过程，如果是重要项目，每个版本我们都会推进代码优化，保证代码可维护性、可扩展性、另外就是高性能。千万别堆积最后，那可是大工程到后面很多人是没有决心干这个事儿的，所以大家应该平时迭代中不断优化和完善，才可持续性。


3. 大型重构时，一定要明确收益并且是可量化的，比如重构后 qps 提升了10%，应用消耗资源降低了…等等，你才有跟老板谈判的筹码。

大家好，我是树哥，好久不见啦。

作为一个工作了 10 多年的开发，写业务代码总是写了不少的。但你想过做到零 bug 吗？我可是想过的，毕竟我还是有点追求的。不然每天都是浑浑噩噩地过，多没意思啊。

大概在一年多前，我给自己立下一个目标 —— 尽量将自己经手的业务需求做到零 bug。不试不知道，一试吓一跳，原来零 bug 还真的还不容易。今天，树哥就跟大家分享关于「业务开发零 bug」的一些思考。

要做到业务开发零 bug，其实挺难的。这涉及到非常多方面，有些方面可能还不只是你能控制的，例如：产品 PRD 详尽程度，产研组织的稳定性等等。经过一段时间的思考与摸索，我自己总结出一些影响因素，分别是：

针对上面说到的影响因素，我们一个个详细聊聊。

需求文档清晰程度

对于研发、测试人员来说，他们获取信息的源头就是产品的 PRD 文档。因此，需求文档是否写得清晰、明确，就显得非常重要。

如果产品自己对功能都不了解，那么输出的需求文档肯定「缺斤少两」，到时候就是边开发边补充需求，甚至是在测试过程中补充需求。遇到这种情况，想要做到零 bug 真的非常难。

因此，清晰明确的需求文档，是我们实现业务开发零 bug 的重要前提。如果这个前提保证不了，那要做到零 bug 真的很难。毕竟想做成啥样都不知道，程序员又不是神仙，咋能猜出你想要什么。但这块内容，更多是对于产品人员专业能力的要求，开发人员无法控制。

在一些公司，会再需求评审之前先对需求文档进行一次初审，筛除那些有明显重大问题的需求，这样可以减少一部分劣质需求。

但初审的作用还是有限的，它没办法对功能的细节做较多的判断。很多时候恰恰就是一些功能细节的缺失，导致了一些 bug 的诞生。

需求的复杂程度

需求的复杂程度，对于实现业务开发零 bug 也有很大的影响。举个简单地例子：一个改文案的需求，和一个完全重新做的功能。

这样的两个需求，其复杂程度差别很大，肯定是改文案的需求实现业务开发零 bug 的难度低很多。对于一个完全重新做的功能，要做到完全零 bug，对于开发人员的要求非常高。

对于越复杂的项目，零 bug 的可能性就越低。因此，很多项目为了追求产出功能的高质量，会采用将功能点拆得非常细的方式，来减少单个需求的复杂度。

笔者公司在去年做过这个尝试，确实是可以较大地提高产出功能的质量。

细心程度

前面说到需求文档的清晰程度很重要，这取决于产品人员对于业务的理解程度，以及对于对于功能的熟悉程度。开发人员的细心，就像是一个质检关卡一样，在开发之前就对产品的需求内容进行详尽的思考与提问。

对于粗心的开发人员来说，其可能不看需求文档就直接参加需求评审，等到开发的时候边写代码边看需求文档，其写得代码也是一边熟悉需求一边改。这样写出来的系统功能是比较差的，没有一个统一、全局的设计与思考，很容易在细节处发生问题。

一个细心的开发人员，其会在评审之前就详细阅读需求文档，甚至会前前后后翻阅好几次。他甚至会逐字逐句地阅读，弄懂每个文字、句子的意思，甚至有时候会让你觉得他是在玩文字游戏（但不得不说，确实有必要细致一些）。

最后会联系上下文思考功能的合理性。如果发现一些不合理的地方，他会积极与产品沟通反馈，以确保其对于需求的理解，与产品经理对于需求的理解是一致的。

通过对比，我们知道细心的开发人员对于产品经理来说，是一个莫大的帮助，可以帮助他查漏补缺，让其对于功能的考虑更加细致、严谨。

这里的开发人员不仅仅指的是后端开发人员，也包括前端开发、移动端开发，他们都会从不同角度提出问题。

对于后端开发人员来说，他们可能会提出性能问题。对于前端开发以及移动端开发同学，他们可能会提出交互问题、样式统一等问题。

简单地说，细心的开发人员可以弥补需求文档的缺陷，从而让大家对于需求的理解更趋于一致，从而减少 bug 的发生。因此，开发人员的细心程度也是决定业务开发能否实现零 bug 的关键因素！

是否详细自测过

即使写过 10 多年代码的开发人员，刷 Leetcode 也不敢说 bug free 一把过，对于更加复杂的业务代码更是如此。因此，要做到业务开发零 bug，其中一个很重要的操作便是 —— 自测。

自测可以帮你再次检查可能出现的问题，从而提高零 bug 的概率。对于我而言，我习惯性在自测的时候再次对照一遍需求文档，从而避免自己遗漏一些功能的细节点。

对于自测而言，业界有很多种自测方法，包括：单测、集成测试、功能测试。一般情况，建议自己选择适合自己的自测方法。

很多时候，功能测试是相对来说性价比较高的方式。除此之外，自测的详细程度也根据实际情况有所不同，例如有些人只会测试正常情况，但有些老手会测试一些边界情况、异常情况。

毫无疑问，你越能像测试人员一样测试，你的提测质量肯定就越高，bug 当然也就越少。

对项目的熟悉程度

这里说的项目熟悉程度，既指技术层面的熟悉程度，也指业务功能层面的熟悉程度。

技术层面的熟悉程度，指的是项目之间是用什么技术栈搭建的，你对这些技术是否都熟悉。举个很简单的例子，项目中采用了微服务的方式进行调用，那么你是否清楚是什么微服务调用？

如果采用了 ElasticSearch 进行搜索，那么你是否对 ElasticSearch 有一些了解，知道一些基本使用及最佳实践？等等。

这些算是技术层面的熟悉程度，你对这些越熟悉，你在技术层面发生问题的可能性就越小。

业务功能层面的熟悉程度，指的是你对项目其他模块的业务是否熟悉。例如你经常负责 A 模块的功能，你对 A 模块肯定很熟悉。

但下个迭代你就要去做 B 迭代的需求了，这时候你肯定不是很熟，相对来说出错的可能性就更大一些。

无论是技术层面，还是业务层面的熟悉程度，都会随着你做了更多的需求，变得更加熟悉。到了后面某个阶段，你基本上就不存在踩坑的问题了，也为你业务开发零 bug 奠定了基础。如果你是一个刚刚进入公司的新手，那么做到零 bug 还是很难的。

开发时间是否充足

开发时间是否充足，决定了你是否有充足的时间去熟悉需求，去和产品经理确定细节。有了充足的时间，你也才能有一定时间去进行更详细的自测。更为关键的一点，有充足的时间，你写代码才能写得更好。因此，开发时间是否充足是很重要的。

在实际的开发过程中，会因为各种各样的原因，其实并没有办法给你留出特别理想的开发时间。这时候该怎么办？有些人选择接受，去压缩自己的时间。

有些人则会选择去沟通，或者协调资源，保证自己有充足的时间。其实，正确的做法还是第二种，这样会更好一些。

这需要开发人员有更强的综合能力（沟通、协调能力），但并不是每个开发人员都具备的。关于这点，又是可以聊的一个话题 —— 当你的需求被压缩工时的时候，你应该怎么做？这里暂不展开，后续有时间可以聊聊。

简单来说，开发时间是基础，没有合理、充足的时间保障的话，要做到业务开发零 bug 是不可能的事情。

总结

要做到业务开发零 bug，其实就是要消除功能开发过程中的所有不确定性，包括：需求功能的不确定性、自己写错代码的不确定性等等。而发生这些不确定性的地方，可能就有：

除了上面说到的 6 个影响业务开发零 bug 的因素之外，肯定还有其他影响因素。

你能想到什么影响业务开发零 bug 的因素吗？欢迎在评论区留言与大家分享。

好了，今天的分享就到此为止，希望大家都能做到业务开发零 bug，业务开发代码一把过！

如果你觉得今天的文章对你有帮助，欢迎点赞转发评论，你的转发对于我很重要，感谢大家！

说下背景

来公司的第二周，上面下发了新需求，也是我参与公司的第一个项目。

我先说下公司一个项目的大体配置

产品经理 1~2人  一般中小版本就1人

UI      1~2人

研发前端 1~3人 

研发后端 1~5人（包含协同团队）  

   ps:其中后端中1人为项目负责人，负责整体项目进度和协调资源

测试    1~2人

好的，故事由此开始。先铺垫下，该项目是我从业以来最无力最绝望最想扯呼的一个。

需求评审

周一刚来公司，就被公司给我安排的导师L 叫到身边

导师L：「一会儿有个需求评审，我文档先发你，你先抓紧时间看看」

懵懂的我：「好的，我先熟悉下任务」

说实话文档看起来真的有点头疼，主要是上面的一行字我真的无语至极【与线上保持一致】。公司的项目还是比较大的，我上哪儿去了解保持一致是个啥意思......问下导师吧，他也在排查线上问题；问下其他同事吧，也刚来没多久不了解这块业务....

好吧时间应该够，我先打开系统，看看这功能到底在哪里。

「走，A2评审会」 导师L给了我一个眼神

大哥，我才看了不到20分钟，功能我都没看完......

我的情况稍微有点特殊，一般来说，大家跟随导师的节奏，问题都不大

看不懂的需求，一定要整懂了在动手，否则返工风险很大

时间不允许？那要再考虑下该公司是不是适合你了哦！！！总不能说能跑起来就行吧

过程我全程梦游，大家都在提问题：各种数据的兼容方案、功能冲突怎么兼容、有类似功能是否能套用、数据权限是否考虑、特殊逻辑的兜底方案.......

开始还能记一下笔记，后面发现 跟不上，根本跟不上 直接 弃笔，从容 面对现实了

从会议室走出来，嗯~~ 怎么形容心情呢。我高考语文作文那一页名字忘了写出考场都没这么忧虑过（当然作文最后还是有得分）。

分配任务

直接上对话详情，后端加上我一共3人

导师L：「任务我这边大概分配了下，你们先选吧」

我内心很慌，我一个都看不明白要怎么做

不知所措的我：「要不我拿剩下的」

同事P：「那把这个、这个、这个给我吧，剩下的你们分？」

导师L看着我：「那就这样分，你做那个、那个、那个，有问题随时找我」

不知所措的我：「好的，我主要是不熟悉这块业务，有问题我先整理出来再一起问下你呗」

这里有个关键点，整理完问题再一起咨询，切记遇到一个问一个

态度摆正，表现得自信点，第一次在同事面前“刷脸”，印象要留好一些

研发阶段

我的任务主要是客户群统计模块

导师给我开了两个服务的权限，让我先看看代码

懵逼的我：「L哥，要不大概说下在那部分写的统计数据？我应该从哪些表出结果？」

导师L：「你先看代码，里面都有逻辑，你看得懂」

无语的我：「好的」 内心（这么玩儿是吧）

知道那代码有多难懂吗？全都是A队列推到B队列，判断后再推C队列，并且还有了很多观察者模式。可能有兄弟姐妹问：「看不懂注释？」。注释少得可怜，也就一些字段含义，不过看单词也能看出来。

队列和队列之间很难看懂，并且很多跨服务的队列，给我开的两个服务根本不够，前后一共加上4个服务才把统计的逻辑串起来，我还专门画了个流程图出来

不管代码设计和质量如何，作为新人别公开喷前辈的代码

前期不要加入太多个性化的代码和设计，每个公司的要求不一致，最好的方式还是模仿

逻辑复杂的话，建议画一个流程图or时序图，架构图的话还是问下老同事，自己画可能不准确

不要轻易下手编码，确保自己很明确整体逻辑了再跟熟悉的同事复述一遍先

好吧，我终于找到逻辑线了（花了1天半时间，留给我开发的时间很近很近），但我发现，结果表很多很多，有AAA_statistics、BBB_statistics、CCC_statistics...... 我拿不定主意，刚好我也对这几个服务熟悉得差不多了，于是我拿着这些成果去问导师L

诚恳的我：「L哥，帮忙看看这几张表，我感觉有一些数据是重复的，还对不上数，帮忙看看呢？」

导师L：「逻辑都捋清楚了吗？」

我直接掏出了我的流程图

导师L：「这是JW（我们组的TL）给你的吗？」

求知的我：「我自己画的，不晓得准确性怎么样，帮忙check下呢」

导师L：「主要是我这还有点事，你再看看吧，晚点我们过一下」

前期难免会有很多问题，但自己也要有点准备，否则被问成麻瓜，印象分直接拉低

不知道的不要说"不知道"，可以说"我还不太熟悉，我先去看看逻辑，X哥要不跟我说下大概位置或则有啥文档？"

到了晚上7:00左右，我发现L哥不见了，后来才晓得那天他溜得挺早的。只剩我原地爆炸，明天要联调了，我关键的数据组装service还只有一行//TODO。没招了，我按照我的想法和数据指标，找了几张最合适的表，把数据产出了。

第二天

我早早地来公司，重新check了下代码并又调试了几次，除了数据对不上没啥其他问题。导师L带着早饭来到公司，我还等到吃完早饭再去问了下。

疲惫的我：「L哥，你看我用这张统计表去输出功能有问题没？」

导师L：「就那么几张表，你造几条数据不就看出来了」

疲惫的我：「我造了几条数据，但是昨天的数据我看今天才过来，昨天忘了记录过程」

导师L：「怎么可能，你怎么造的数据，算了等会儿我看一下」

......

过程就不细讲了，总之，不好受...... 最后问题也定位到了，是导师L当初做测试，把定时任务往后延了1天。好吧，这还有定时任务的事儿？我只能看代码看到一堆数据同步的接口，真的是应征了那句话：【最怕的是：我不知道我'不知道'】。

时间允许的话，着手开工前还是留一份概要设计的存档，别把坑都留给后面的人了

流程图、时序图、架构图等，前期多花时间，少走弯路

心态摆好，我们是来打工挣钱的，交不交朋友是其次而已，关系不恶化怎么着都行

而后，比较顺利地进行到提测阶段，bug真的是多得要命，主要是以下几点：

1、数据权限没加（就是prd文档上写的跟xxx模块保持一致逻辑）

2、数据同步时好时坏，排查后发现是定时任务不稳定，大家都在一个环境提测版本，都在修改功能

3、未做改造的功能点测出历史bug（功能类似，故测试同学也纳入了测试范围）

4、服务被其他版本覆盖

导致最终版本交付时，我个人产生了大概20+个bug。周五下午TL专门找我谈话，约谈此事，大概意思是版本复杂度不高，但bug数过多，对我的版本质量不满意。对此，我也阐述了我的解释，这里我就不细说解释的话，大概从以下几点去阐述

不要丢锅，先把由自己粗心产生的bug讲一下，记得提一下数据，因自身代码质量产生了X个bug，后续会加强编码质量，多自测

也不要背锅，说下由于环境问题导致了X个bug的产生，并给出自己的建议，是否能做环境隔离，一个环境只能容纳服务不冲突的1~2个版本

注意下，TL直接对话的机会并不是很多，可以结合自身入职以来的经历，提一些建议（不用管是否重要）

总之，事事多总结，否则像这种情况下TL突然找咱们约谈，说不出个123，印象分会很差

项目总结

在项目研发中，不一定能得到公司前辈们的"关照"，这时候就需要先自己憋一下（注意合理安排时间），怎么着也能憋出点内容，那这这些内容再去咨询，效果会好很多。像我这种被孤立的情况，我也不好说是不是常态，我个人还是认为好同事还是居多的。总之还是与同事搞好关系，或者关系一般遇事能帮忙也行，不要跟任何同事把关系闹僵（哪怕脾气差、技术菜、背后勾心斗角）。

还是那句话，遇事不要慌，先调整好心态（道理都看得懂，但希望大家都能做得到），尽力吃透项目再开始施工，否则返工或者低质量产出不好避免。

多做总结，不甩锅不背锅，不管是项目总结还是转正答辩还是晋升答辩，都能有个有条理有依据的总结出来。这点在职场中至关重要。

怎么来定义低谷期？

我觉得真正的低谷期是迷茫，挫败，痛苦，自我怀疑等等，反正一定是比肉体上的痛苦更煎熬！

可能你会觉得暂时性找不到工作，面试受挫，分手等是你的低谷期，实则不然，这大概是一个不敢面对自己的借口。

因为多数人找到工作后，只要能在温饱线上，那么90%的人就会心安理得摆烂，和男女朋友复合后，依然是维持原样，不会被爱情去刺激自己成长。

如果用工作和分手这两件事情来描述真正的低谷期，那么我觉得应该是这样描述的：

自己付出了很多，每天都像一条疯狗干，工作和学习的时长维持在18个小时左右，坚持了很久，但是没有收获自己想要的东西，希望还是如此渺茫，于是产生严重的自我怀疑，挫败，深圳绝望！

自己一直在努力，在慢慢成长，目标越来越近，但是自己爱得死去活来的女朋友实在等不了自己成长，自己变强，所以无情的选择离开。

经过上面的描述，成为了毋庸置疑的低谷期。

因为没经过描述之前其实你是没有任何斗志的，目的就是能安心混日子，可以用摆烂来形容，和女朋友在一起，自己也不需要啥成本，她也没有啥诉求，所以算得上是互相将就。

但是经过描述后，实际上你的努力近乎疯狂，对于成功是无比的渴望，但是迟迟没降临到你的身上，而女朋友是在你身上压了筹码的，而你又非常爱她，但是迟迟不能让她压的筹码赚个翻倍，所以离开成了定局。

这下就一目了然了吧。

所以这时候你再去回想一下自己所谓的低谷期，是否真的是低谷期？还是自己矫情？

从上面的场景我们能看到深刻二字，第一个是根本谈不上深刻，而第二个是无比的深刻，如果你经历过，那么你自然能理解！

只有让自己刻骨铭心和痛苦的事情才能让自己成长，其他的基本不能。

就像你比较肥胖，三高找上你，家里人叫你不要再吃垃圾食品，不要喝饮料，但是这时候你还没真正躺在病床上，你基本上不会去听。

但是如果此刻你躺在病床上，插着呼吸管，医生给你说，如果你再不注意饮食，那么你很快就会死掉。你看你还会不会再去吃垃圾食品，喝饮料。

所以说，只有让自己脱一层皮，自己才会意识到问题的所在。

那么低谷期里，也自然会脱一层皮，甚至还会换骨头，那么你觉得这难道不是最佳的成长期吗？

所以一个人能遇上真正的低谷期，其实是一种幸运，应该要感谢这个遭遇。

就像一个朋友，因为一些原因导致自己不能再继续读书，家里为了自己的事情而负债累累，自己承受巨大的压力，想死的心都有了。

但是在这段堪称被恶魔惩罚的时期，他没有一蹶不振，反而置之死地而后生，最后无论是财富还是个人能力，阅历都有很大的提升！

后面和他聊天的时候，他说那是自己最痛苦，最无助的时候，但是自己庆幸没有放弃，才造就了一身钢筋铁骨？

所以你说这个低谷期是不幸的吗？

不是，这算的上是恩赐，因为并不是谁都有这种机会。

所以我们在低谷期的时候，如果能有把它作为翻盘的机会的思想，那么它一定是很难得的机会！

但是如果把它作为上天对自己的惩罚，从而一蹶不振，那么其实是错失一次很好的机会，并且也学让自己越陷越深！

前言

Hi 你好，我是东东拿铁，一个正在探索个人IP&副业的后端程序员。

个人IP探索的第三个月，不再是一往无前的埋头苦干，一腔热血之余，对自己的能力探索与兴趣挖掘，成为了日常生活的主线。

为了更好的坚持下去，希望自己能够找到自己最擅长、做起来最愉悦、自身价值观又认可的事情。但最近一段时间，我意识到，我其实并不了解我自己。想认识自己，也不是一件简单的事情。

古希腊哲学家苏格拉底曾说：“未经审视的人生不值得过。“

话不多说，看看最近一段时间，我身边发生的事情与思考吧。

经历AI的诱惑，坚定内心的方向

其实在23年年底刚开始写作的时候，自己就对自己列了几个方向

其中，AI一直是我自己认为一个很重要的方向，时代大趋势下，所有行业只要加上AI，似乎都变得有些不一样。

24年年初，我第一次试着去了解AI的工具，是因为那时看到一个圈友，做了一个AI艺术二维码。于是我也下载下了stable-diffusion，准备大展身手一把。

本来是这样想的，发个朋友圈，如果有想要做艺术二维码的，我5块钱给他生成一个，怎么着也算开启了副业收入对吧。

结果人家做出来的是这样的，蛮好看。

我生成出来的，丑就不说了，问题是扫都扫不出来，就很搞笑。

苦于周边暂时没有大佬支持，也有着别的事情需要做，就暂时被我搁置了。

我的内心其实对AI感兴趣，但实际上，还是以一个程序员思维来考虑的。举一个例子，就想现在.NET的就业环境已经逐渐减少，如果我毕业时选择了一份.NET的工作，那么市场需求一定是很小的。

所以我才会对AI感兴趣，我的思路还是，或许5年后，Java已经不行了，但是算法开发、模型开发可能成为市场需求主流，为了找到工作，不得不去学习AI相关。

这件事情埋在我心里，虽没干成，但毕竟没有搞出来，心里还是有点不甘心的。

从过年伊始，就通过各种渠道，了解到了AI破局社群，即将迎来拉新。那时候我了解到，原来搞AI类应用，其实是有一个专门的社群的，里面也有各种各样的项目让你去落地，还有专业的人给你指导，我之前没跑出来的AI二维码，只要加入，遇到的问题肯定就能解决。

面对着铺天盖地的宣传，自己内心也逐渐有些动摇，一边是追求热点，迅速满足。一边是继续学习写作，延迟满足，看着许多圈友入局，内心还是挺焦虑的。

最终还是克服了自己短期尝试AI的想法，两个原因：

人的精力有限，需要放在有用的地方。

关于写作

上了热榜，占据首页

经过一周时间的打磨，之前经历的一篇文章，竟然上了热榜第一，6000多字的碎碎念能被大家看到，不少朋友给我说能够感同深受，一切的努力都值得了。

被更多的人看到，固然是好事，但在写这篇文章的过程中，也发现了不少问题，其中低效、内耗的问题，最为严重。

首先，6000多字的文章，完全是个人经历与思考，纯手写的话，如何组织语言，安排好顺序，就是一个最大的问题。

其次，如何把结构梳理好，能够更有连贯性，才能让大家在看的过程中，不枯燥乏味，我花费了非常多的时间。

最后，因为事情涉及到不少真实经历，受限于篇幅，不能完全的呈现给大家，如何选择最能让大家共鸣，最能给大家带来价值的地方，也蛮头疼的。

与现在利用AI工具，一天能够四五篇文章的作者比起来，效率简直低的可怕，虽然带来的价值不一样，但是流量就是这么多，想让更多人看到，效率如何提高，是我接下来要重点思考的事情。

关于输出的“困扰”

经过3个月的输出，我不出意外的遇到了“缺少话题”的情况，这也是最近更新频率变低的最主要的原因。

在这段时间，虽然输出频率降低，但话题的收集没有落下，每当有一些小点子，我就会先记录下来，每天翻一翻，去看看哪些是最想写的。

但实际上，即使收集了很多素材，如果你没有太多想说的话，无疑也只是罗列旧知识，没有新观点，我只想说点新颖的，所以迟迟没有动笔。

为了解决这个问题，两个方法和大家分享下

先立后破

先立后破，虽然话题素材减少，但强制要求自己，每周都要有所输出。

为了达成这个任务，我被迫搜集很多素材，先丰富自己的素材库，然后选择自己最有表达欲的主题，详细去写。

为什么要先立后破

任何事情都有一个逻辑，就是先别管技巧或者合理性，也别管效果如何，先给它规定一个数量，把数量做到了，慢慢的，你就会因为数量而倒逼自己去琢磨如何研究质量。

写作这件事也一样，即使我不知道写什么，也要强迫自己动笔去写，自己在输出这件事上，依然坚信着一句话。

数量不一定能决定质量，但一定能决定重量。

定扩联思维

先确定

能输出的点有很多，技术、副业、写作、复盘，先把内容方向定下来，比如我今天选择的方向就是复盘。

后扩展

扩展的话就好说了，既然是复盘，每一件事情都可以展开来讲，AI的一些经历。关于输出的困扰，输出一些方法论。

再联想

根据自己阅读、学习过的内容，进行发散。比如我深入思考的个人定位问题，最近的所学所想，都可以随着复盘输出出来。

个人定位

这个月花费最多的时间，就是在思考如何有一个清晰的定位。思考过程中问自己的几个问题，也在此罗列出来，如果你也想找到个人定位，也不妨对着这几个问题问一下自己。

职业与专业知识

7年后端研发工程师，北漂回二线城市的大厂程序员。毕业半年裸辞北漂，但经过几年北漂后，为了追求内心、照顾家庭，6年后回到二线城市发展。

北漂阶段，从30人小公司，最终进入大厂。大厂期间面试人数50+，对于求职面试、职业规划有着不少宝贵经验。

完成北漂回归二线城市，完成了城市选择，公司判断，薪资谈判，心里建设等一系列流程，各种有些许挫折，但都一一完成拆解。

善于在复杂项目中抽丝剥茧，但缺乏创造力。经手的项目无论难度多大，都可以极快的完成梳理与上手。但每当新业务开展，思路总会比较局限。

喜欢的博主

个人非常喜欢的博主是，半佛仙人，18年从公众号关注至今，文章几乎一篇不落。

为什么喜欢？我简单的想了下，有一下几个原因。

以上，羡慕。在我眼中，能毫无顾及的表达出自己的看法，让这么多人看到，对于一个爱写东西的人来讲，无疑是一件幸福的事情了。如果这件事情还能赚到钱，那更是锦上添花。

业余爱好

大学业余时间除了打游戏，就是谈恋爱，一上高数就睡觉，下课铃响就起床，

直到看了一本书《皮囊》之后，开始热爱上了阅读。虽然自己生在城市，完全没有农村经历，但对《皮囊》《活着》《兄弟》等很多农村作品，阅读的时候却有着特别大的感触，文中主人工经历越苦难，我的感受越心酸。

后来发现，老读这种文章，人都快看emo了（许多穷苦的事情，自己又没有能力改变什么）。

后来大学期间看了《嫌疑人x的现身》（短篇小说，非常精彩），了解了东野圭吾，对悬疑类作品有了极大兴趣，花了半年的时间就把他大多数重要的作品都看了一遍。印象最深的是《白夜行》，从第一次打开《白夜行》到最终看完，几乎过去了半年的时间，但是《嫌疑人x的现身》只需花了2天时间我就看完了。

但最终读完《白夜行》后，其中的精彩程度让我认为这是东野圭吾小说系列在我心中的No.1。这本书也让我意识到长篇小说的精彩之处，前面之前认为的枯燥的铺垫，到最后都是拍手称绝的伏笔。让我对延时满足这四个字，有个更深的体会。

后来又听说了村上春树，《挪威的森林》目前为止读了四遍，闲下来仍然会打开翻一翻。里面一些句子，一直在潜移默化的影响着我

不要同情自己，同情自己是卑劣懦夫干的勾当。

所谓绅士，就是做自己该做之事，而不是想做之事。

擅长的事情

我的盖洛普第二名和第五名，是和谐和体谅，遇见冲突解决冲突，并能够设身处地的体会他人的感受。所以之前有很多朋友和我说过，和我聊天，即使问题解决不了，心理上也能舒服很多。

或许你想找对象，我能帮你发现一些你潜在的问题，帮你去想应该怎么做，才能得到妹妹。

或许你面临裁员、换工作，我能根据你现有的能力与过往的经验，帮你规划提升方向。

或许你面临职场困惑，我也可以根据过往经验给出一些意见。

如果你有类似的问题，也欢迎你来找我聊聊。

说在最后

这次的复盘就先聊到这里了，有小的高光时刻，也有阻碍和自己的思考，感谢你能看到这里。

估计谁都没想到2023年，疫情恢复的第一年竟然如此：大厂裁员、楼市继续下跌、年底股市暴跌等。

这篇文章说下笔者对宏观经济的一些理解和判断，以试图解释过去一年发生的一些事情。

宏观经济周期

笔者看来，由于美元具备全球货币属性，美元加息是全球的麻烦。所以总体而言，全球经济处于美元加息影响下的结果中，也就是处于美元回流，全球货币紧缩，全球经济处于下行周期中。

但每个主要经济体又有其自身的宏观经济周期，比如说我们国家，疫情三年为了人民的生命健康，我们国家没有像西方打开方便之门，大肆放水，而是选择严守死防。

三年疫情，我们国家保护了人民的生命健康，但我们也封闭了三年，紧缩了三年。我们国家处于疫情恢复周期中，处于上行周期中。但始作俑者的美国因为超发货币，自身经济过热，所以需要降低过热经济，所以宏观经济也处于下行周期中。

这里说一个题外话，宏观经济是通缩好还是通货膨胀好呢？实际上，过分的通缩和过分的通货膨胀都不好，适度的通胀最好，一般来说维持在2%左右是比较好的，这也就是美国一直想通过加息实现的通胀水平。

不管是通缩还是通胀代表的都是一种趋势，通缩经济逐渐下行，规模逐渐减小，反之通胀经济处于上行，规模逐渐扩大，这样才能实现GDP的增长，实现经济的发展。

回来继续说宏观经济周期，当下国家要做的就是让经济处于扩张区间，或者说实现经济的适度通胀。

2023年CPI和PPI一直不温不火，其实有一点通缩的迹象，所以国家在出台各种手段改善这种迹象：

但改变趋势谈何容易，同时还要考虑美国的加息节奏。所以出台的手段并不是那么尽如人意，也因为受到美国加息节奏的影响，为了维持外汇的稳定性，出台的时机也并未尽如人意。

笔者觉得正因为上述原因：美元加息周期、国内降息周期导致2023大厂裁员、楼市继续下跌、年底股市暴跌。

2024年宏观经济

目前美国已经暂停加息半年，加息周期已经到顶，预期5、6月份后降息。也正因为暂停加息，加息到顶我国央行今天进一步降低5年期贷款利率。

2024年的国内的宏观经济依然是将经济恢复为适度通胀的水平。笔者的判断是在汇率稳定的前提下，稳定楼市，因为楼市涉及的面太大。稳定了楼市才能稳定经济稳定预期，才能稳定股市。

完全有可能的是央行在美国降息后选择再一次降息贷款利息的方式，加强人们的信心，加强人们对国家进一步搞活经济的决心，给人们信心。

稳定楼市而不是大力发展楼市。笔者认为未来国家的发展会逐渐向高科技产业倾斜，从依靠楼市带动GDP增长改为依靠科技带动。

综上，一些配套的改革一定也会有：比如真正支持优秀公司发展的证券市场，比如政府职能转变为服务好企业，比如更加开放的区域市场（现在的浦东新区）等等。

而笔者比较关心的股票市场，隶属于证券市场，笔者觉得未来中国的股市一定会越来越好，尤其优秀的科技公司。

（本文完）

《肖申克的救赎》是一部令人震撼的电影。其给我留下深刻印象的不止男主的筹谋，还有终获假释，却选择上吊自杀的老布。老布是一个悲剧人物。

老布被关押监狱五十年。半个多世纪，老布从青年变为白发苍苍的老头，他最终熟悉了监狱的一切，适应了监狱的一切，也和监狱捆绑在了一起。用电影中的话来说，老布被监狱“体制化”了，包括他的自我认同，自我习惯。他依赖这个监狱。

也正因为此，出狱后的老布因为无法适应、融入发生巨变的社会环境，选择结束自己的一生。

体制化是指是个人或群体在某种环境中逐渐适应并接受其中的规则、习惯、意识和氛围，以至于这些成为其思考和行为的一部分。比如说销售人员更会自我激励，司机师傅更容易记下位置路线，财务人员更细致……

现代社会高度发展，每个人都不可避免的依赖某个组织或企业。为了融入组织或企业，被体制化是必然。但过度被体制化，比如长期生活在农村的老人，长期在高速口收费的收费员，长期无法晋升的公司老白兔……不利于人的发展，应该主动避免。

分工

现代企业建立的基础之一是大规模生产下的分工，分工可以提高生产效率，但分工也让人失去独立性。就拿上面长期在高速口收费的收费员举例，几年前河北高速一个收费员被辞退，就闹了起来，原因是他别的什么都不会了。

长期单一职责一旦被离职很容易陷入困境，轻者生活质量下降；重者长期失业；更重者，如老布一般选择终结自己的生命，事实上前几年就发生了这种事……

企业机会狼多肉少

几年前读过一句话：我们的社会实际是一个精英筛选系统，大多数人存在的意义是辅助筛选。这句话套用在企业也适用，企业是一个小型的精英筛选系统。

这些年互联网行业流行的所谓35岁职场危机，背后实际是部分企业认定35岁没能成为精英，也就不具人力性价比，选择不再对其招聘。

35岁大部分都有了家庭，要是35岁没有成为精英，相关企业招聘的意愿又不强，只能等着被辞退。要是在被过度体制化，被拴在一家企业，那无疑是雪上加霜。

体制化是放弃整个森林

我对企业有很多定义，其中之一企业是社会当中满足一系列特定需求的组织。一系列特定需求实际是局部市场。在局部市场里，企业注定机会有限。而市场本身比企业拥有更多机会，被过度体制化会被动放弃拥有更多机会的可能。

积极培养第二曲线甚至第三曲线

随着技术的提高，经济的发展，现代职业的生命周期在缩短。我认为每个人应该积极培养第二甚至第三职业。第二职业可以是自媒体，比如写作、比如up主、再比如小红书博主……可以是其他擅长的，可以利用下班时间去做的事业。

第三职业可以是投资人，投资是坐顺风车的学问，重要的是识别顺风车。做投资可以先从二级市场，也就是股票市场开始(投资需谨慎)。要能够借国家发展的大势，享受国家发展带来的红利。

我之前写过一篇关于宏观经济的文章《宏观经济的一些判断》。目前，我国经济处于上行周期中，受房地产拖累，经济爬坡有些缓慢。上个月CPI同比上涨0.7%，消费意愿在加强；上个月社融处于增长态势，经济活动相对活跃，上个月规模以上企业工业增加值显著增长……

种种迹象表明经济在好转，我也相信经济一定会好起来，经济好起来叠加国家对证券市场的进一步规范，不久以后股市完全有可能成为新的国民财富蓄水池。

结尾

总之，在工作过程中要识别哪些规则、习惯、意识和氛围，长期来讲是真正的机会，哪些不是。到了一定年龄，看不到成为公司精英的希望，应发展更多社会生存技能，在社会这个更大市场中生根发芽，创造财富，获取财富。

也希望能够直接借到国家发展大势，直接享受国家发展红利。

前言

一年一度个税年度综合汇算清缴的时间又到了，作为开发者的你，肯定过了起征点了吧。🫤

去年退税退了 5676 ，今年看这个估计得补好几千，但是个税年度汇算清缴还没有预约到，抓紧提前算算金额，做做心理建设。\同时，了解个税都扣在哪了，才可以让我们合理避税~

下面我们简单聊聊 补税 和 预缴 ，顺便讲讲专项附加扣除应该怎么填。

以及带大家写一个个税计算器。你可以通过码上掘金查看 在线 svelte(无UI) 版 ，后续也会推出其他框架版。

为什么你需要补税？

大多数情况下，公司发工资会替你把税交了，这个行为叫预缴。

为什么预缴呢？因为国家规定：

《个人所得税扣缴申报管理办法(试行)》(国家税务总局公告2018年第61号发布)

第六条：扣缴义务人向居民个人支付工资、薪金所得时,应当按照累计预扣法计算预扣税款,并按月办理扣缴申报。

这也就是我们每个月发工资都会扣税的原因。

那为什么需要补税呢？因为预缴是根据你在当前公司的收入进行缴税，公司会计算你的累进税率，你会发现每到年底税交的越来越高了，这是累进预缴导致的。

有些人在年中换了工作了，新公司不知道你之前已经交到哪个阶段的个税了，因此预缴时计税金额会重新累计。

因此补税的原因不外乎：

• 工作变更


• 公司主体变更（如：公司拆分）

为什么说预缴是天才发明？

预缴制简直是个天才发明，不但会大大减少逃税人数，而且能减轻税务工作量（转移至各公司），且可以让缴税的人对税率的感知没有那么强烈。

达成这种效果主要原因有两点，分别是 损失厌恶 、 心理账户 。

损失厌恶

人们对损失的敏感程度通常远远大于对同等价值的收益的敏感程度

人们对损失的敏感程度通常远远大于对同等价值的收益的敏感程度

人们对损失的敏感程度通常远远大于对同等价值的收益的敏感程度

牢记这句话。

一个最简单的例子，短视频中经常会出现的 最有效的 6 条学习方式，最后一条最重要 。这种放大损失的语言，常常能诱发更高的完播率。

虽然我很讨厌以这种方式留住用户，但常常在刷到这类视频时，也忍不住多看一样，虽然知道它最终可能也没什么实质内容。

还有一种就是我们常常刷掉一个视频，又返回去看一眼，又刷掉又返回去。我常常会有这种心理，这个视频我是不是应该看一看的纠结。

个税也是同理，个税预缴是减少我们的收益，而个税年终汇算则是直接让我们从口袋中掏钱。

就算汇算综合到月度计算，同样也是，一种是公司扣完发给你，另一种是发给你之后你再掏出来一部分。大家感受一下这其中的区别。

心理账户

人们可能会将个税缴纳视作开销，而且是意外开销，意外开销总是让人痛苦的。

比如我每个月 1w 块，其中 3k 拿来租房，3k 拿来吃饭， 2k 拿来娱乐，2k 拿来缴五险一金。

这时候到年终汇算时，人们则容易苦不堪言。

且这种带来的直接后果是，我想把税留到最后一天交，同时最后一天也很容易忘记交，因为大脑也不想要这种意外支出。

最终则导致 漏交、拒交 个税的人数大大增加。

专项附加扣除严谨度

• 子女教育（未婚，无接触）


• 赡养老人（容易被查）


• 继续教育 - 学历提升（基本不查）
  
  
  
  • 学历提升可以选择一个对应学历，每个学历 4 年，共 16 年左右抵税
  
  
  
  


• 继续教育 - 证书获取（基本不查）
  
  
  
  • 证书获取有人一个证书可以一直抵税，建议： 营养师证、焊工证等
  
  
  
  


• 租房买房（基本不查）


• 大病医疗（未填过，未知）

开发

首先咱们先写个个税计算器的 class ，个人所得税英文简称 IIT （Individual Income Tas） 。

class IITCalulator {}

添加需要计算的内容

众所周知，

个税计算法：应缴税款 * 对应税率 - 速算扣除

应缴税款计算法：工资 - 五险一金缴纳额 - 专项附加扣除

因此我们先添加 工资 、 五险一金 、 专项附加扣除 的属性。

工资

我们工资有两个组成部分，分别是 固定工资 和 年终奖（如果有的话）。

class IITCalulator {

  private salary: {

    monthlySalary: number;

    yearEnd: number;

  } = {

    monthlySalary: 0,

    yearEnd: 0,

  };

  

  /**

   * @description 添加工资（通过工资计算年薪）

   */

  addSalary(

    monthlySalary,

    yearEnd?: { value: number; type: "month" | "amount" }

  ) {

    this.salary.monthlySalary = monthlySalary;

    if (yearEnd) {

      this.salary.yearEnd =

        yearEnd.type === "amount"

          ? yearEnd.value

          : monthlySalary * yearEnd.value;

    }

  }

}

五险一金

这里直接给了固定金额，可以通过查看每月扣除得知。

考虑到有人不太清楚自己的五险一金缴纳基数，这里直接用了固定金额，后续可以扩展出通过缴纳比例自动计算

class IITCalulator {

  private socialInsuranceMonthlyAmount = 0;

  

  /**

   * @description 添加五险一金，计算年五险一金缴纳额

   * @param {number} monthlyAmount 月度缴纳金额

   */

  addSocialInsurance(monthlyAmount) {

    this.socialInsuranceMonthlyAmount = monthlyAmount;

  }

}

专项附加扣除

专项附加扣除通过数组的方式存储扣除项。

// 专项附加扣除类型

type SpecialDeductionType =

  | "children"

  | "elder"

  | "education-school"

  | "education-certificate"

  | "housing"

  | "medical";

  

class IITCalulator {

  private specialDeductionTypes: Array<SpecialDeductionType> = [];

  private medicalAmount = 0;



  /**

   * @description 添加专项附加扣除

   * @param {string} type 专项附加扣除类型

   */

  addSpecialDeduction(

    SpecialDeductionType: SpecialDeductionType,

    medicalAmount?: number

  ) {

    this.specialDeductionTypes.some((t) => t !== SpecialDeductionType) &&

      this.specialDeductionTypes.push(SpecialDeductionType);



    if (medicalAmount) {

      this.medicalAmount = medicalAmount;

    }

  }

}

计算 工资 、 五险一金 、 专项附加扣除

我们添加了基础属性，可以根据基础属性计算出对应金额。

工资

工资 = 月薪 * 12 + 年终奖

getYearSalary() {

    return this.salary.monthlySalary * 12 + this.salary.yearEnd;

}

五险一金

五险一金 = 月缴纳额 * 12

getYearSocialInsurance() {

    return this.socialInsuranceMonthlyAmount * 12;

}

专项附加扣除

专项附加扣除 = 扣除项的扣除金额合集

需要注意的是：大病扣除项是固定金额的

这里直接采用 reduce 进行累加。

/**

 * @description 计算专项附加扣除

 */

private getSpecialDeduction() {

  return this.specialDeductionTypes.reduce((r, v) => {

    switch (v) {

      case "children":

        return r + 2000 * 12;

      case "elder":

        return r + 3000 * 12;

      case "education-school":

        return r + 400 * 12;

      case "education-certificate":

        return r + 3600;

      case "housing":

        return r + 1500 * 12;

      case "medical":

        return r + this.medicalAmount;

      default:

        return r;

    }

  }, 0);

}

计算纳税金额

我们基础数据都有了，就只差计算了。先通过基础数据计算应纳税所得额，再通过应纳税所得额计算个税。

计算应纳税所得额

calcIIT() {

  // 计算年薪

  const yearSalary = this.getYearSalary();

  // 五险一金缴纳金额

  const yearSocialInsurance = this.getYearSocialInsurance();

  // 专项附加扣除金额

  const specialDeduction = this.getSpecialDeduction();

  // 计算需要缴纳个税的金额

  let taxableAmount =

    yearSalary - yearSocialInsurance - specialDeduction - 60000;

  // 计算个税

  return this.calcTaxableAmount(taxableAmount);

}

计算应缴个税

个税计算参考：

// 计算个税（金额 * 税率 - 速算扣除）

private calcTaxableAmount(taxableAmount: number) {

  if (taxableAmount <= 36000) {

    return taxableAmount * 0.03;

  } else if (taxableAmount <= 144000) {

    return taxableAmount * 0.1 - 2520;

  } else if (taxableAmount <= 300000) {

    return taxableAmount * 0.2 - 16920;

  } else if (taxableAmount <= 420000) {

    return taxableAmount * 0.25 - 31920;

  } else if (taxableAmount <= 660000) {

    return taxableAmount * 0.3 - 52920;

  } else if (taxableAmount <= 960000) {

    return taxableAmount * 0.35 - 85920;

  } else {

    return taxableAmount * 0.45 - 181920;

  }

}

完整代码：

// 专项附加扣除类型

// 1. 子女教育

// 2. 赡养老人

// 3. 继续教育(学校)

// 4. 继续教育(证书)

// 5. 住房贷款

// 6. 大病医疗

type SpecialDeductionType =

  | "children"

  | "elder"

  | "education-school"

  | "education-certificate"

  | "housing"

  | "medical";



class IITCalculator {

  private salary: {

    monthlySalary: number;

    yearEnd: number;

  } = {

    monthlySalary: 0,

    yearEnd: 0,

  };

  private socialInsuranceMonthlyAmount = 0;



  private specialDeductionTypes: Array<SpecialDeductionType> = [];

  private medicalAmount = 0;



  constructor() {}



  /**

   * @description 添加工资（通过工资计算年薪）

   */

  addSalary(

    monthlySalary,

    yearEnd?: { value: number; type: "month" | "amount" }

  ) {

    this.salary.monthlySalary = monthlySalary;

    if (yearEnd) {

      this.salary.yearEnd =

        yearEnd.type === "amount"

          ? yearEnd.value

          : monthlySalary * yearEnd.value;

    }

  }



  getYearSalary() {

    return this.salary.monthlySalary * 12 + this.salary.yearEnd;

  }



  /**

   * @description 添加五险一金，计算年五险一金缴纳额

   * @param {number} monthlyAmount 月度缴纳金额

   */

  addSocialInsurance(monthlyAmount) {

    this.socialInsuranceMonthlyAmount = monthlyAmount;

  }



  getYearSocialInsurance() {

    return this.socialInsuranceMonthlyAmount * 12;

  }



  /**

   * @description 添加专项附加扣除

   * @param {string} type 专项附加扣除类型

   */

  addSpecialDeduction(

    SpecialDeductionType: SpecialDeductionType,

    medicalAmount?: number

  ) {

    this.specialDeductionTypes.some((t) => t !== SpecialDeductionType) &&

      this.specialDeductionTypes.push(SpecialDeductionType);



    if (medicalAmount) {

      this.medicalAmount = medicalAmount;

    }

  }



  /**

   * @description 计算专项附加扣除

   */

  private getSpecialDeduction() {

    return this.specialDeductionTypes.reduce((r, v) => {

      switch (v) {

        case "children":

          return r + 2000 * 12;

        case "elder":

          return r + 3000 * 12;

        case "education-school":

          return r + 400 * 12;

        case "education-certificate":

          return r + 3600;

        case "housing":

          return r + 1500 * 12;

        case "medical":

          return r + this.medicalAmount;

        default:

          return r;

      }

    }, 0);

  }



  calcIIT() {

    // 计算年薪

    const yearSalary = this.getYearSalary();

    // 年终奖是否单独计税



    // 五险一金缴纳金额

    const yearSocialInsurance = this.getYearSocialInsurance();

    // 专项附加扣除金额

    const specialDeduction = this.getSpecialDeduction();

    // 计算需要缴纳个税的金额

    let taxableAmount =

      yearSalary - yearSocialInsurance - specialDeduction - 60000;

    // 计算个税

    return this.calcTaxableAmount(taxableAmount);

  }



  // 计算个税（金额 * 税率 - 速算扣除）

  private calcTaxableAmount(taxableAmount: number) {

    if (taxableAmount <= 36000) {

      return taxableAmount * 0.03;

    } else if (taxableAmount <= 144000) {

      return taxableAmount * 0.1 - 2520;

    } else if (taxableAmount <= 300000) {

      return taxableAmount * 0.2 - 16920;

    } else if (taxableAmount <= 420000) {

      return taxableAmount * 0.25 - 31920;

    } else if (taxableAmount <= 660000) {

      return taxableAmount * 0.3 - 52920;

    } else if (taxableAmount <= 960000) {

      return taxableAmount * 0.35 - 85920;

    } else {

      return taxableAmount * 0.45 - 181920;

    }

  }

}

最后

我最开始尝试写一个 UI 版。但后续感觉，UI 版对于不同语言的用户，会看起来很痛苦。

因此我通过纯 JS 实现，大家可以通过不同的 UI 调用该类，可以在各个框架中使用。

同时也通过 svelte 做了一个简略 UI 版，大家可以直接尝试。

最后，点赞、关注、收藏 ，祝大家多多退税~~

买房攻略

2023 年至今，上海房价一跌再跌。俺已经蠢蠢欲动了，磨刀霍霍向"买房"。但是奈何手里钞票不够，只能向天再借 500 年打工赚钱。但是作为倔强的互联网打工人，想知道自己会被银行割多少韭菜。于是就写了个程序，用于计算我贷款买房需要多给银行还多少钱。这样我就能知道银行割我的韭菜，能省下几辆迈巴赫的钱了。

贷款利率

• 公积金的贷款利率。
  
  
  
  
  • 首房：贷款时间 <=5 年，利率为 2.6% ；贷款时间 >= 5 年，利率为 3.1% 。
  
  
  • 非首房：贷款时间 <=5 年，利率为 3.025% ；贷款时间 >= 5 年，利率为 3.575% 。
  
  
  
  

• 商业险贷款利率
  
  
  
  
  • 贷款时间 <=5 年，利率为 3.45% ；贷款时间 >= 5 年，利率为 3.95% 。
  
  
  
  

代码实现

• 以下代码，实现了：我贷款买房需要多给银行还多少钱。

public class LoanAmountCalculation {

​

    //首套住房5年以内公积金贷款利率

    private static final double FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS = 2.6;

    //首套住房5年以上公积金款利率

    private static final double FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS = 3.1;

    //二房5年以内公积金贷款利率

    private static final double NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS = 3.025;

    //二房5年以上公积金款利率

    private static final double NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS = 3.575;

    //5年以内商业贷款利率

    private static final double COMMERCIAL_LOAN_RATE_WITHIN_FIVE_YEARS = 3.45;

    //5年以上商业贷款利率

    private static final double COMMERCIAL_LOAN_RATE_MORE_FIVE_YEARS = 3.95;

​

    public static void main(String[] args) {

        Scanner scanner = new Scanner(System.in);

​

        double houseAmount = getInputValue(scanner, "请输入预计买房金额(单位:W)：", "请输出正确的买房金额（>0）！");

        double principal = getInputValue(scanner, "请输入您的本金(单位:W)：", "请输出正确的买房金额（>0）！");

        if (principal >= houseAmount) {

            System.out.println("全款买房，崇拜大佬！");

            return;

        }

​

        double accumulationFundLoanAmount = getInputValue(scanner, "请输入公积金贷款金额(单位:W)：", "请输出正确的公积金贷款金额（>0）！");

​

        double commercialLoanAmount = houseAmount - principal - accumulationFundLoanAmount;

        if(commercialLoanAmount <= 0){

            System.out.println("您的本金+公积金贷款已经够买房啦，恭喜大佬！");

            return;

        }else{

            System.out.println("您的本金+公积金贷款还不够买房哦，需要商业贷款金额为(单位:W)：" + commercialLoanAmount + "\n");

        }

​

        int accumulationFundLoanYears = getInputIntValue(scanner, "请输入公积金贷款年份(单位:年)：");

        int commercialLoanAmountYears = getInputIntValue(scanner, "请输入商业贷款年份(单位:年)：");

​

        int isFirstHouse = getInputIntValue(scanner, "请输入是否首房(0:否，1：是)：");

​

        LoanAmount loanAmount = calculateLoanAmount(

                accumulationFundLoanAmount, accumulationFundLoanYears,

                commercialLoanAmount, commercialLoanAmountYears, isFirstHouse);

        System.out.println("详细贷款信息如下：" + "\n" + loanAmount);

    }

​

    /**

     * 获取double类型的输入

     * @param scanner：Java输入类

     * @param prompt：提示信息

     * @param errorMessage：输入错误的提示信息

     * @return 一个double类型的输入

     */

    private static double getInputValue(Scanner scanner, String prompt, String errorMessage) {

        double value;

        while (true) {

            System.out.println(prompt);

            if (scanner.hasNextDouble()) {

                value = scanner.nextDouble();

                if (value > 0) {

                    break;

                } else {

                    System.out.println(errorMessage);

                }

            } else {

                scanner.next();

                System.out.println(errorMessage);

            }

        }

        return value;

    }

​

    /**

     * 获取int类型的输入

     * @param scanner：Java输入类

     * @param prompt：提示信息

     * @return 一个int类型的输入

     */

    private static int getInputIntValue(Scanner scanner, String prompt) {

        int value;

        while (true) {

            System.out.println(prompt);

            if (scanner.hasNextInt()) {

                value = scanner.nextInt();

                if (value > 0) {

                    break;

                } else {

                    System.out.println("请输入正确的年份（>0）！");

                }

            } else {

                scanner.next();

                System.out.println("请输入正确的年份（>0）！");

            }

        }

        return value;

    }

​

    /**

     * 功能：贷款金额计算

     * 入参：

     * 1.accumulationFundLoanAmount：公积金贷款金额  2.accumulationFundLoanYears：公积金贷款年份；

     * 3.commercialLoanAmount：商业贷款金额；        4.commercialLoanAmountYears：商业贷款年份

     * 5.isFirstHouse：是否首房

     */

    private static LoanAmount calculateLoanAmount(double accumulationFundLoanAmount, int accumulationFundLoanYears,

                                                           double commercialLoanAmount, int commercialLoanAmountYears, int isFirstHouse){

        LoanAmount loanAmount = new LoanAmount();

        //公积金贷款还款金额

        double accumulationFundRepaymentAmount;

        if(isFirstHouse == 1){

            accumulationFundRepaymentAmount = accumulationFundLoanYears <= 5 ?

                    accumulationFundLoanAmount * Math.pow((100 + FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS) / 100, accumulationFundLoanYears)

                    : accumulationFundLoanAmount * Math.pow((100 + FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS) / 100, accumulationFundLoanYears);

        }else{

            accumulationFundRepaymentAmount = accumulationFundLoanYears <= 5 ?

                    accumulationFundLoanAmount * Math.pow((100 + NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_WITHIN_FIVE_YEARS) / 100, accumulationFundLoanYears)

                    : accumulationFundLoanAmount * Math.pow((100 + NOT_FIRST_HOUSE_ACCUMULATION_FUND_LOAN_RATE_MORE_FIVE_YEARS) / 100, accumulationFundLoanYears);

        }

        loanAmount.setAccumulationFundRepaymentAmount(String.format("%.2f", accumulationFundRepaymentAmount));

​

        //公积金贷款每年还款金额

        loanAmount.setAccumulationFundAnnualRepaymentAmount(String.format("%.2f", accumulationFundRepaymentAmount / accumulationFundLoanYears));

​

        //商业贷款还款金额

        double commercialRepaymentAmount = commercialLoanAmountYears <= 5 ?

                commercialLoanAmount * Math.pow((100 + COMMERCIAL_LOAN_RATE_WITHIN_FIVE_YEARS) / 100, commercialLoanAmountYears)

                : commercialLoanAmount * Math.pow((100 + COMMERCIAL_LOAN_RATE_MORE_FIVE_YEARS) / 100, commercialLoanAmountYears);

        loanAmount.setCommercialRepaymentAmount(String.format("%.2f", commercialRepaymentAmount));

​

        //商业贷款每年还款金额

        loanAmount.setCommercialAnnualRepaymentAmount(String.format("%.2f", commercialRepaymentAmount / commercialLoanAmountYears));

​

        //公积金贷款超出金额

        loanAmount.setAccumulationFundLoanExceedAmount(String.format("%.2f", accumulationFundRepaymentAmount - accumulationFundLoanAmount));

​

        //商业贷款超出金额

        loanAmount.setCommercialLoanExceedAmount(String.format("%.2f", commercialRepaymentAmount - commercialLoanAmount));

​

        loanAmount.setTotalExceedLoanAmount(String.format("%.2f", accumulationFundRepaymentAmount - accumulationFundLoanAmount + commercialRepaymentAmount - commercialLoanAmount));

        return loanAmount;

    }

    @Data

    static class LoanAmount{

        /**

         * 公积金贷款还款金额

         */

        private String accumulationFundRepaymentAmount;

        /**

         * 公积金贷款每年还款金额

         */

        private String accumulationFundAnnualRepaymentAmount;

        /**

         * 商业贷款还款金额

         */

        private String commercialRepaymentAmount;

        /**

         * 商业贷款每年还款金额

         */

        private String commercialAnnualRepaymentAmount;

        /**

         * 公积金贷款超出金额 = 公积金贷款还款金额 - 公积金贷款金额

         */

        private String accumulationFundLoanExceedAmount;

        /**

         * 商业贷款超出金额 = 商业贷款还款金额 - 商业贷款金额

         */

        private String commercialLoanExceedAmount;

​

        /**

         * 总共贷款超出金额

         */

        private String totalExceedLoanAmount;

​

        @Override

        public String toString() {

            return "1.公积金贷款还款金额=" + accumulationFundRepaymentAmount + "万元\n" +

                    "2.商业贷款还款金额=" + commercialRepaymentAmount + "万元\n" +

                    "3.公积金贷款每年还款金额=" + accumulationFundAnnualRepaymentAmount + "万元\n" +

                    "4.商业贷款每年还款金额=" + commercialAnnualRepaymentAmount + "万元\n" +

                    "5.公积金贷款超出金额=" + accumulationFundLoanExceedAmount + "万元\n" +

                    "6.商业贷款超出金额=" + commercialLoanExceedAmount + "万元\n" +

                    "7.总共贷款超出金额=" + totalExceedLoanAmount + "万元\n";

        }

    }

}

代码输入，输出示例

由上图可知，我要贷款买一套 400w 的房子，本金只有 120w，使用组合贷：公积金贷款 120w（10年），商业贷款 160w（20年）。最终我需要多还银行 230.07w，相当于买两辆迈巴赫的钱了，巨亏！

以上就是全部内容了，如果涉及到真实场景，还是需要根据具体的情况计算的！

大家好，我是树哥！

昨天，我在文章《业务开发做到零 bug 有多难？》和大家聊了下影响零 bug 的一些因素。其中，我提到了开发时被压缩工时，应该怎么做。今天，我们就来聊聊这个话题。

只要工作过几年的小伙伴，必然会遇到过背压工时的情况。面对这种情况，不同的工作年限、在不同的公司、不同的团队氛围下，都会有不同的反应。如果你是一个刚刚毕业的萌新开发，很大情况下你会选择自己加班服从。甚至加班都完不成的情况下，你还吭哧吭哧不出声。

最后等待你的结果就是 —— 成为被复盘的对象，被批评。那么如果遇到了开发时间被压缩，或者被质疑的情况下，我们除了默默加班接受之外，还能做些什么来让自己没那么苦逼吗？

在我看来，自己一个人傻傻加班是下下签，是最后实在没办法才做的无奈之举。一旦有其他选择，你都不应该提出自己加班加点做完。那么，到底有什么办法可以解决工时被压缩这一问题呢？

解释工时构成

如果你的开发时间被压缩，那么较大可能是 leader 质疑你评估出的工时。假设你的工时评估并没有问题，那么就是你考虑到了一些风险点，而你的 leader 并没有考虑到。毕竟这也很正常，对于一个很久没有写代码的管理者来说，其会习惯性地忽略一些细节性的东西。

这个时候，你要做的不是胆怯地接受。而是要主动去找 leader ，跟他解释工时是怎么评估出来的。你考虑到了某些风险点，为什么是这么多工时。如果你的 leader 不是傻子，那么相信他会接受你的解释。但这里要注意的是，解释的时候记得要语气好些，不要怒气冲冲地找别人，不然话没说然就吵起来了。

减少需求内容

假设你和 leader 已经进行了友好地沟通， leader 也认可了你的评估时间。但是他说：没办法，老板就要求那个时间点做完，没办法给你更多时间了！

这时候，萌新小白就会老老实实回去座位上加班，最后还是干不完被批斗。但对于职场老油条来说，他就学会与 leader 以及产品沟通 —— 能不能少点需求内容。例如：我们要做一个员工列表，那是不是只做列表就可以，不用做筛选和搜索了？员工详情是不是也可以先不走了？

老板可以指定最终完成的时间，但是他基本不会干涉到具体的细节上面。这时候就给我们留下了沟通的空间，这也就是作为开发的你可以争取的东西。对于一个有经验的产品经理来说，如果研发给他提出了减少非核心功能的诉求，他一般也会答应的。

申请更多资源

如果产品说：不行，我们每个功能点都得做，一点需求都少不了！

这时候你可以再向你的老板提出诉求 —— 申请更多资源。

前面你也解释过工时的构成，做这么多功能确实需要这么多时间。如果最终上线时间不能推迟，那么就只能投入更多的资源了。

在这种情况下，如果公司还有富裕的研发资源，那自然会优先考虑你这边的诉求。对于你来说，你的研发压力也自然变小了。

分摊开发压力

如果实在又申请不到更多资源，这个项目又只能由你们团队 5 个人来完成，怎么办？

很多时候，不同开发人员的开发压力不一样。可能你开发压力比较大，其他人开发压力比较小，这时候你可以提出 —— 是否可以让其他小伙伴帮忙做点工作，这样可以减少一些压力？

我想，如果你的 leader 也应该会考虑你的诉求。千万不要自己明明完成不了，还要硬抗。到最后加班干了几个星期，需求还是完成不了，不仅辛苦的付出得不到理解，还被批斗。那可就真的是赔了夫人又折兵啊！

千万不要觉得这种情况不会发生，在我去年工作的时候，就发生了这样一个事情，我也是很同情那位同学的。如果那位同学能看到这篇文章，那么或许他后面就不会踩坑了吧。

推迟上线时间

上面说得是最终上线时间无法变更的情况，但很多时候并没有这种倒排需求。很多需求的上线时间并不是一成不变的，你只要给出足够合理的解释，也都是可以沟通的。

因此，如果在上面的沟通方法都行不通的情况下，你也可以沟通看看是否可以推迟上线时间。毕竟相对于研发速度来说，研发质量肯定更加重要。

终极绝招

大多数情况下，如果你能合理应用上面提到的几种沟通方式，被压缩工时的问题一般都能解决。但有些小伙伴会问：那如果真的所有办法都失效了呢？那怎么办？

其实，大多数情况下，不太可能到了需要使用绝招的地步。但如果真的到了这一步，那你就做好「殊死一搏」的准备，用上这个绝招吧 —— 调预期、表态度。

调预期，就是给你的 leader 打预防针，提前告诉他这样做的后果就是 —— 质量差、很难做得完。如果他还是这么坚定地推进，那么如果真的做不完，相信他也理解，不会太过于责怪你。

表态度，就是得加加班。如果你之前已经说了压力很大，甚至加班都做不完。那么你至少还是得表表态度，不能像往常一样早早下班，这样即使最后搞砸了。由于你态度还算端正，还不至于被责怪得太狠。但如果你要是又说做不完，又每天早早下班，那别人就觉得是你态度问题了。

走到这一步，实属是无奈，但这也是最后的保命之举了，除非你不想在这干了。

总结

今天分享了几种沟通解决「被压缩工时」的方法，包括：

• 解释工时构成


• 减少需求内容


• 申请更多资源


• 分摊开发压力


• 推迟上线时间

本质上来说，就是不要自己一个人傻傻地抗压力，不要让自己背负着太大压力。我们要明白自己能做到什么程度，而且不要早早把「自己加班」这一最后的保命、卖惨利器祭出。他应该是自己的保命技能，而不是为别人锦上添花的技能。

特别是，不要因为赶进度、赶工时，而去牺牲开发质量。因为如果你这么做了，后果就是你付出了很多时间和精力，最后你会在项目复盘会上检讨 —— 为什么你的功能代码质量这么差。这是另一个话题了，后续有时间我们继续聊。

希望大家都能够活学活用，下次在和 leader 以及产品沟通的时候，用上这些沟通技巧吧！希望大家都不要加班，准时下班！

如果你觉得今天的文章对你有帮助，欢迎点赞转发评论支持树哥，你的支持对于我很重要，感谢大家！

近年来，职场竞争越来越激烈，每个员工都希望通过努力工作，赢得领导的认可和提拔机会。

然后，不可否认的是，有人粉墨登场，就有人卸妆离场。离职是职业生涯中一个重要的转折点，它不仅是结束一段工作关系，也是展示个人素质和职业态度的重要时刻。

人们常说“离职见人品”，这句话凸显了离职时人品的重要性。而对于某些管理岗位，往往在招聘时，都是会背调的。

离职时的表现往往能够反映出一个人的职业素养和道德水准。

在离职过程中，一个有良好人品的人会以积极、负责的态度对待工作交接，尽力确保工作流程的顺畅进行，不给公司和团队带来不必要的麻烦。

他们会与上级和同事进行充分的沟通，表达对公司的感激之情，并保持良好的合作关系。

相反，一些人在离职时可能会表现出不良的行为。

他们可能会消极对待工作交接，甚至故意隐瞒重要信息或破坏工作进度，给公司和团队带来困扰。不要认为你在这家公司做的不爽，你就也想让公司不爽，这样的行为不仅缺乏职业道德，也可能对个人的声誉和未来的职业发展产生负面影响。

我身边一个真实的案例，我的前同事（主管级别）因为不服空降领导，在持续了三个月与领导发生冲突和争吵后，愤然离职甩脸色，再其离职后，仍发邮件给公司高层打报告。现在他基本在杭州很难混下去，因为背调基本上打电话过来给目前的领导，询问其人品，结果可想而知了。上个月还听到领导跟我交流，说某某公司找他背调前同事。

那么，在离职时如何展现良好的人品呢？我们如何体面的告别自己的工作呢？

01. 提前通知

在离职前，提前向上级和同事发出离职通知是一种负责任的行为。

这样做可以给予公司足够的时间来安排工作交接，确保工作流程的顺畅进行。

通过提前通知，公司可以有足够的时间找到合适的人选来接替你的职位，避免因你的离职而导致工作的中断或延误。

同时，这也为你的同事提供了准备和适应的时间，以便他们能够顺利接手你的工作职责。这样的做法不仅展现了你的职业素养，也有助于维护良好的人际关系。

2. 积极配合

在工作交接期间，积极配合同事和上级，确保工作流程的顺畅进行。比如：
1、制定详细的交接计划：与上级和同事一起制定详细的交接计划，明确交接的内容、时间和责任人。这样可以确保交接工作有条不紊地进行。
2、分享工作文档和资料：将你的工作文档、资料和相关信息整理好，并与同事和上级分享。这将帮助他们更好地了解工作的细节和进展，以便顺利接手。
3、提供培训和指导：如果同事需要，你可以提供培训和指导，帮助他们熟悉工作流程和项目。这将有助于他们更快地适应新的工作职责。
4、积极回答问题：在同事和上级有疑问或需要帮助时，积极回答问题并提供支持。保持沟通畅通，确保他们能够顺利进行工作。
5、参与重要会议和项目：如果可能的话，参与一些重要的会议和项目，以便更好地了解工作的最新情况，并在必要时提供帮助。

3. 保持联系

离职时，你要向公司领导和同事表达感激之情，感谢他们在工作中给予的支持和帮助。不要因为工作的事情，搞得自己不开心。
还有你一定要清楚，离职了不是永别了，在你工作中积累的同事和领导关系，都是你日后在这个社会中的潜在资源，离职时把关系维护好，说不定哪天，他们能在某个地方帮助到你。

离职后，与前同事和上级保持联系，建立良好的人际关系。

4. 不抱怨不诋毁

静坐当思己过，闲谈莫论人非。在离职过程中，不要抱怨公司或同事，也不要在背后诋毁他们。抱怨和诋毁只会让自己显得狭隘和小气，对于未来的职业发展也没有任何好处。即使在离职过程中存在一些不愉快的事情，我们也应该以成熟的方式处理，保持良好的沟通和合作。

5.结语

总之，“离职见人品”这句话提醒我们，在职业生涯中，我们的行为和态度不仅影响着当前的工作环境，也会对未来的发展产生深远的影响。在离职过程中，我们应该保持积极的态度，不要抱怨或诋毁公司或同事。学会感恩，以成熟的方式处理事情，保持良好的人际关系，这些都是我们未来职业发展的宝贵财富。因此，无论离职与否，我们都应该始终保持良好的职业素养和道德标准，以展现自己的优秀品质。

写在前面

从上家公司离职已经有一段时间了，当我打开备忘录翻看以前每天的todolist，成长历程历历在目，也觉得有必要写一篇文章对我毕业后的第一份工作做一个阶段性的总结。

离职原因

我的第一家公司是杭州某大型车企旗下的一家网约车公司，19年11月份拿到校招offer就开始进入公司实习了，2020年6月份正式转正，在2023年11月底离职，所以满打满算应该在这家公司呆了有四年的时间。

至于为什么离职，有以下几点原因：

成长历程

在这家公司一共有过两次晋升，一次是在2022年，一次是在2023年，算上普调，应该是有过三次涨薪。

刚开始进入公司的时候，是以实习生的身份，那时候我刚从一家几百人的小公司实习结束，也是我第一次亲身经历了比较正规的研发流程和研发规范。刚开始的时候，每天都有很多低级问题要问，和测试、产品同学沟通起来也是十分的不流畅，加上当时刚好赶上了疫情，在家办公了一段时间，好在实习的表现还算满意，我的4个月实习让我免去了试用期，拿到毕-业-证以后直接转正了。

毕业后分配到了营销小组，这是我第一次做To C的业务，经常会出一些线上问题，收到用户的投诉，当时的老板对于线上问题的忍耐程度很低，很小的问题都会被无限放大，导致我当时在做需求，需求的上线都是处于一种极度紧张的状态，一旦出现线上问题，都会默默的打开Boss 直聘，做好找下一份工作的准备。

在之后的1 ~ 3的工作经历中，我渐渐找到了工作的节奏，以及如何应对一些人际关系，处理起线上问题也比以前镇定多了。第二年和第三三的绩效都比较好，而且后来的某一段时间内，公司优化掉了大部分的测试同学，我们研发写的代码需要研发进行自测，我们的需求研发周期变成了研发时间 + 自测时间，我觉得这给了我们研发更多的Buffer，能把一个需求做的更好，甚至我经常能留出多余的时间来做一些okr相关的项目。

在离开公司的前半年时间，我的工作又发生了很大的变化，在完成日常的工作之外，我还积极参与了公司的游泳社团、羽毛球社团、篮球社团。分别在周二、周四、周五跟着公司的小伙伴一起参加体育运动，这对我的身体状况有了很大的改善。

这三年半有什么成长？

健康状况

除了我的胃，其他都没有什么大毛病，这里要告诫一下大家一定要注意保护自己的胃，胃病真的想象的那么简单。

由于疫情期间在家里没怎么活动，加上暴饮暴食，饱腹后继续喝茶... 以及后来复工之后在公司天天吃外卖，导致我的胃经常胀气。中午午睡的时候顶的难受睡不着觉，晚上睡觉的时候肚子也胀胀的，需要起身好几次打几个嗝才能睡得着，对我的睡眠造成了很大的困扰。

期间也去医院看过，做过胃镜，吃过中药，但是效果不是那么明显。后来很长一段时间没有吃辣的，也按时吃饭，不吃夜宵，经常跳绳锻炼一下，渐渐有所好转。

面试历程

其实跳槽这件事情是我在一两年前就计划好的。在22年底的时候，其实就出去面试过，不过当时没有准备的特别充分，加上当时太天真，还是一副刚毕业时年轻气盛的样子，导致很多面试官对我的印象都不是特别好。

一些感谢的人

首先感谢一下我上家公司的几位直系上司。我呆过两个组，两个组长都对我十分不错，一位在我实习期间给了我很多引导，帮我快速熟悉公司的业务。另外一位则是在我成为正式员工之后，帮我担下了很多的责任，并且帮助我快速的成长，成功获得了两次晋升的机会，并且都顺利通过。

另外感谢一下我的专家，真的是一位特别好的人，从来不会PUA下属，总是会以过来人的角度给你一些很好的建议。

有没有什么要吐槽的

如果非有什么需要吐槽的，还是公司的文化吧。并不是说现在的文化有什么问题，我想吐槽的是变化。因为曾经美好过，所以当注入新鲜血液之后的变化，其实让很多经历过美好的人会有一些失望😂😂😂

写在最后

感觉这四年时间过的很快，从一个职场新人变成了拥有三年多经验的打工人。昨天晚上还在家里翻出之前入职培训时的一些合影，当时我记得校招入职的时候有54人，算上被优化和自己主动离职的，目前应该还剩下不到10人。

希望老东家越来越好，早点实现盈利上市！！！

也希望自己在下一份工作中能够快速适应，能够给N年后的自己也交上一张满意的答卷。

看了看天气预报，从明天开始天气就变暖了，路两旁的花也开了，有些树也冒出了新芽，再过一段时间，就可以真正意义上感受春天的气息了。昨晚做了一个梦，梦到了好多小伙伴，大家一起去爬山，因为还有几个妹子一起，所以我就像孙悟空一样这棵树爬一下，那棵树吊一下，以至于今天早上醒来后，全身酸痛，差点班都不想去上，此刻，打着字，手依然是酸痛的。

我感到有点后悔，因为现实中，我算是已经很少去装X了，但是梦里居然还是那个德行，不过想一想，这怪我了？梦啥我能决定吗？瞬间心里好受了一点，就当锻炼了吧，平时很少锻炼，梦里能锻炼一下也不错。

大概从明天开始后就不会再有多过分冷的天气了，所以这个梦就当做真正意义上春天的开场曲了，春夏秋冬这四个季节，我最喜欢春天，因为这个季节里有美好的回忆，也有令人痛苦的回忆。

我爷爷家门口有一片竹林，春天的时候，竹林里面会长很多竹蛋，竹蛋开花后就是竹荪，是很不错的美味，竹林下面是一条小沟，整个村子农作物灌溉的水都需要从这里过，而那会我们经常要去堵水，堵水的意思就是去几公里外的源头抢一点水，然后让水流向往村子里的小沟，途中不断有支流，直到流到自己家的田里。

从源头到我家田里大概有四五公里的路程，那会我经常顺着小沟走到田里，因为是丘陵地带，所以一直在半山腰上走，而山腰下面全是农田，到处都是一片绿油油的，那时候家里养了一只小狗，因为比较贪吃，名字叫做馋瓢，我偶尔还会带着它顺着小狗走，它经常还会捉到一些小野生动物。

那会对外界没有什么概念，连乡镇都没去过，只是在我爷爷家墙上的报纸上能了解一点，所以每当看到田野，高山的时候，心中都会产生一些幻想。

三年级是在乡镇上读书，那会拳皇97和三国战记2007特别风靡，于是那会我经常在游戏厅里打上几个小时，三国经常一个币打到通关，那会父母在浙江打工，后面他们回来直到我经常去打游戏，于是经常被骂，后面就很少去了。

不过狗改不了吃屎，虚拟的我玩不了就不玩，但但是现实中我可不放过，于是和一个比我小几级的同村小伙伴，两个用木棒自己做武器，我喜欢孔明，于是做了一把剑，他喜欢赵云，于是搞了一杆长枪。

那时候正是春天，我们两个每天都去别人家地里将菜和秸秆当作小兵，疯狂冲杀，于是经常被别人骂上好几个小时，现在回想起来，看着别人心疼的捡起碎了的蔬菜，真的觉得自己做了好大的孽了。

四年级的时候，捡到了一个类似于MP3那种小玩意，可以收音，于是我在租房子过去的坟头上收音，那会信号是很弱的，需要来回走动才能收到信号，就听了一些什么国际形势的东西，但是啥也不懂，只是觉得能够收入来自于外面的声音，就觉得很幸福，因为小镇上没有网吧，每次都会在坟头来回走几百次，坟头草都给别人踩没了，不过还好，春天里的生命力是无比顽强的，没了又会快速长出来。

我只在小镇待了一年半，但是那段发生在春天里的故事至今无法忘怀，因为都有点作孽，所以教学了以后我要善良一点。

到了县城读书后，因为南方的雨水比较多，春天和夏天经常水淹县城，那会我妈在街上买水果，每当下大雨的时候，我都赶快去给她收摊，记得有一次雨特别大，我给她收完摊子，看到路上好多被雨淋着的背篼(贵州的一种职业)。

于是回到家里，我搞了两把雨伞，冒着大雨就出门了，在街上遇到一个六十多岁的背篼，我就主动给他伞，然后送他回家，送他到家后，我就原路返回回家了，一路上水淹到了膝盖，还有电闪雷鸣，特别吓人。

回到家后，我全身湿透了，被骂了一顿，我记得我妈说：关你什么事，这么危险，你要是被水淹死了怎么办。

我当时哭着说：我还不是希望有一天你们遇到这种事情的事情，有人也能帮助你们，我有错吗？

那会特别委屈，多年后我才意识到，父母不是反对你做这种事情，而是太危险了，要是真的运气不好，被水冲走了怎么办。并且在我说出那句话时，她明显带有微笑。

后面她继续卖了四五年的水果，后面又卖烧饼，不知道在我没看到的时候，有没有人帮她推过三轮车，不过这一切都不重要了。

在后来初高中岁月里，我遇上了第一个喜欢的女孩子，并且也谈恋爱了，也是在春天，凌晨六点我家在她家门口等她，然后拉着她在东山下面跑步，呐喊，不过相处的时光依然很短，后面她辍学了，打了一个电话给我爸，叫我去她家，于是分手了。

那天夜里，我在东山下面转了很多圈才回去，后面的几个月里，也比较颓废，不过在那个年纪一切都情有可原。

几年后，我顺着火车路跑步到她家，然后做了一碗面条给我吃，瞎聊了很久，过了一年她就结婚，也是在春天，我不再顺着火车路跑步去她老家，而是骑着摩托车过去了，从那会起，我才算真正的放下。

后面，就没有再联系过了，东山的春天依然没变，只是那片土地变成了一个风景区，那些小路与菜地已经楼阁挺立，迎接了来自外地的游客，越来越多的人进来跑步，我刻在那颗核桃树上的字现在应该已经结痂了。

春是那么让人着谜，不单单是因为气候，更多的是因为它能带给我许多东西，让我从中反思，收获！

笔者是一名程序员老司机，局限于笔者文笔一般，想到哪写到哪，胡乱写一通，希望通过文章的方式简单的回顾过去、总结现在和展望未来，顺便记录一下，方便以后总结。

你好，37岁👇

37岁的自己你好，接下来的几个“重要”是36岁的自己在过去一年中所得到的感悟，希望能够帮助37岁的自己更好的前行。

人生就是不停的打怪升级的过程，从2009年到今天，已经是第15个年头了，如果说程序员的职业生涯有20年的话，从现在算起至少还有5个年头可以继续拼搏。

春节快乐

在这里先祝各位春节快乐！

还有2天就到春节了，和前两年一样，还是一直在公司坚守到最后一天，也是利用最后比较清闲的时间，总结一下自己过去一年，把感想写下来，希望能够帮助自己更好的看清内心。

说真的每一年总结的时候，都会有不一样的收获。

运气很重要

再回头看自己15年成长的过程，运气和努力其实是各占一半，5分是不断努力的提升自己生存的技能，5分是在每个阶段也是很幸运遇到了能够帮助自己的贵人。但是这几年也很有感触，随着年龄的不断增长，运气很有可能是往后几年职业生涯是否能顺利的决定性因素。那什么是运气？比如你是否进入了一个没有被社会抛弃的行业，你是否正处于公司的重要赛道，你是否能和你的领导惺惺相惜，你正在做的事情是否能够发挥你的自身价值等等，以上这些当然和前期的努力是有关系的，通过你的努力让你有可能接受这一份运气的可能性，但是最终做决定的并不是自己。加入正好某个政策出现拯救了行业、正好公司的战略调整让你们部门还能招人、正好你领导看你顺眼并委以重任...那么请珍惜眼前，走好眼前每一步，努力付出，不辜负这一份运气！

写这篇文章的时候，正好在这家厂干满3年，这三年真是各种心酸，经历了整个公司业务的缩编裁撤，跌宕起伏，经历了团队连换3个领导，在最艰难，最焦虑的时候，选择了放下焦虑，在团队动荡的时候，更需要努力找机会向隔级领导证明自己，努力寻找过程中的那点不起眼的运气成分，同时做好准备，最坏的情况无非就是拿大礼包。但是如果就此躺平，那运气只会飘向其他人。终于在第三个领导的时候，运气来了，惺惺相惜的感觉出现了，逐渐被委以重任，这个时候就只管抱紧大腿往前冲就行了。

谨言慎行很重要

懂得在什么场合说什么样的话，以及能够听得懂别人的话外话，分得清对什么样的人应该说什么样的话，做到不给自己惹麻烦，不给领导惹麻烦。

程序员都是比较单纯的，和机器打交道最多，有一说一，不会拐弯抹角，这也使得我们在沟通或者有利用冲突的时候，经常是处于弱势的那一方，一不小心就会被别人当枪使，但我遇到的大部分同事都很nice的，也会有一些个卧龙凤雏，目前公司里确实遇到了一两个，有时候因为想用真心换真心，换来的却是冷枪暗箭，但俗话说吃一见长一智，以后和他们说话多留个心眼，不能被同一个坑埋两次吧。

这里举个例子，有一次我们有个研发主动去找产品同学，希望他们能够在下个需求时能从用户体验优化一些体验差的产品逻辑，我们可以加人优化，这个时候如果是靠谱的产品肯定是会一起配合梳理，但是我们的这个产品的领导真是个卧龙，这件事情传到他耳朵里，就变成了我们有资源也不给他们排期某某需求，反手就向上面老板投诉我们研发工作不饱和，真是能给人气死。这里并不是说我们同学没有情商，而是因为程序员所处的环境造就了我们，直面目标和结果的推进方式，容易全盘托出。我们喜欢沉浸在技术的世界里，这里所见即所得，绝对的平等，没有小人得志，没有尔虞我诈。

所以这里需要做到对人下菜，踩过的坑要记得，该设防的时候得设防，不能啥都说，拿不定主意时，少说多做。

身体健康很重要

作为家里的顶梁柱，可不能倒下，拼归拼，但身体健康还是要放在首位。35岁以后注意养生吧，现在发量真的比之前少了很多，头皮明显暴露在阳光下了，都是上有老下有小，没天的睡眠质量真的是大不如前。这个时候保持心情愉悦很重要，如果一只处于焦虑烦躁的状态，很容易导致身心疲惫，各种毛病就会接踵而至。由于睡眠不足，导致眼睛血丝严重，眼角膜出现问题，去年有大半年的时候都是往医院跑，在医生的叮嘱下，及时调整作息时间，工作生活保持适当躺平，保持心情愉悦，总算是没有往恶化的方面发展，以后只需要注意养生即可。

还是要保证适当的锻炼，但是不能过量，比如跳绳、跑步，对于我来说过量会膝盖疼，所以也不是很适合，每天适当的散散步是个不错的选择。

家庭和睦很重要

我们每天努力工作，就是为了多挣钱，为了给家人一个幸福美满的生活。在工作中难免会遇到很多委屈，心中自然会有很多不满，这时就需要自己找到发泄不满的方式，如果说家里人可以倾听，那可以和家里倾诉，如果不希望让家里知道，那可以通过刷剧、钓鱼、打球等方式，非常管用。

在过去这两三年，我媳妇是我很大的精神支柱，在21、22年团队业务动荡的时候，作为家里的顶梁柱，那时候压力山大，但她成为了我的坚强后盾，她鼓励我坚持学习充实自己，事情并没有到最坏的时候，只要时刻做好准备，其他的看运气，大不了就是失业，或许年纪大了可能会经历很长一段时间的空窗期，但慢慢找总能再找到工作的。她真正做到了陪伴、倾听、鼓励，没有不满、没有抱怨，这就是夫妻同心，其利断金。没有了后顾之忧，少了很多自身的精神内耗，学习效率、工作效率都会有很大的提升，随着公司业务的回暖，目前至少也算是在不断的稳步前进中。

现在媳妇有了、娃有了、房子有了、车子有了，这不就是人生最好的运气么，接下来我的目标其实就是努力经营好这个家，为他们遮风挡雨，家庭健康和睦比啥都重要。

适当旅游很重要

我们每天生活在高度紧张、快节奏的环境里，很容易把自己搞得紧张兮兮的，这个时候需要定期找时间出去放松一下，带上家人来一趟说走就走的旅行。慢节奏的旅行，不仅不累，还能促进家庭和睦，千万不要吝啬，该花钱的地方就得大胆的花。

今年一直想着找时间去一趟海南，所以等老大考试完第二天，立马就出发了。不过也许是许久没坐飞机了，竟然还忘记了45分钟不让值机的事情，也没有提前值机，一直排队托运，结果过时了没有完成托运和值机搞得还改签加钱体验了一把头等舱，但说实话北京坐飞机一路躺着去海南也是挺舒服的，空姐真的是服务周到。

1月初去海南温度刚刚好，完美的体验了一把反季节的旅行。

夕阳下的美好，这感觉又回到了十几年前弹恋爱的感觉：）。

介绍自己

本人女，16年本科毕业，学的机械自动化专业，和大部分人一样，选专业的时候是拍大腿决定的。

恍恍惚惚度过大学四年，考研时心比天高选了本专业top5学校，考研失败，又不愿调剂，然后就参加校招大军。可能外貌+绩点优势，很顺利拿到了很多工厂offer，然后欢欢喜喜拖箱带桶进厂。

每天两点一线生活，住宿吃饭娱乐全在厂区，工资很低但是也没啥消费，住宿吃饭免费、四套厂服覆盖春夏秋冬。

我的岗位是 inplan软件维护 岗位，属于生产资料处理部门，在我来之前6年该岗位一直只有我师傅一个人，岗位主要是二次开发一款外购的软件，软件提供的api是基于perl语言，现在很少有人听过这个perl吧。该岗位可能是无数人眼里的神仙岗位吧，我在这呆了快两年，硬是没写过一段代码...

inplan软件维护 岗位的诞生就是我的师傅开创的，他原本只是负责生产资料处理，当大家只顾着用软件时，他翻到了说明书上的API一栏，然后写了一段代码，将大家每日手工一顿操作的事情用一个脚本解决了，此后更是停不下来，将部门各种excel数据处理也写成了脚本，引起了部门经理的注意，然后就设定了该岗位。

然而，将我一个对部门工作都不了解的新人丢在这个岗位，可想我的迷茫。开始半年师傅给我一本厚厚的《perl入门到精通》英文书籍，让我先学会 perl 语言。（ps：当时公司网络不连外网，而我也没有上网查资料的习惯，甚至那时候对电脑操作都不熟练...泪目）

师傅还是心地很善良很单纯的人，他隔一段时间会检查我的学习进度，然而当他激情澎拜给我讲着代码时，我竟控制不住打起了瞌睡，然后他就不管我了～～此后我便成了部门透明人物，要是一直透明下去就好了。我懒散的工作态度引起了部门主管的关注，于是我成了他重点关注的对象，我的工位更是移到了他身后～～这便是我的噩梦，一不小心神游时，主管的脸不知啥时凑到了我的电脑屏幕上～～～😱

偶然发现我的师傅在学习 php+html+css+js，他打算给部门构建一个网站，传统的脚本语言还是太简陋了。我在网上翻到了 w3scool离线文档 ，这一下子打开了我的 代码人生。后面我的师傅跳槽了，我在厂里呆了两年觉得什么都没学到，也考虑跳槽了。

后面的经历也很魔幻，误打误撞成为了一名前端开发工程师。此时是2018年，算是前端的鼎盛之年吧，各种新框架 vue/react/angular 都火起来了，各种网站/手机端应用如雨后春笋。我的前端之路还算顺利吧，下面讲讲我的经验吧

如何入门

对于外行转码农还是有一定成本的，省心的方式就是报班吧，但是个人觉得不省钱呀。培训班快则3个月，多的几年，不仅要交上万的培训费用，这段时间0收入，对于家境一般的同学，个人不建议报班。

但是现在市场环境不好，企业对你的容忍度不像之前那么高。之前几年行业缺人，身边很多只懂皮毛的人都可以进入，很多人在岗位半年也只能写出简单的页面，逻辑复杂一点就搞不定～～即使被裁了，也可以快速找到下家。这样的日子应该一去不复返了，所以我们还是要具备的实力，企业不是做慈善的，我们入职后还是要对的起自己的一份工资。

讲讲具体怎么入门吧

看视频：

b站上有很多很多免费的视频，空闲之余少刷点段子，去看看这些视频。不要问我看哪个，点击量大的就进去看看，看看过来人的经验，看看对这个行业的介绍。提高你的信息量，普通人的差距最大就在信息量的多少

还是看视频：

找一个系统的课程，系统的学习 html+css+js+vue/react，我们要动手写一些demo出来

做笔记：

对于新人来说，就是看了视频感觉自己会了，但是写起来很是费力。为啥呢？因为你不知道也记不住有哪些api，所以我们在看视频学习中，有不知道的语法就记下来。

我之前的经验就是手动抄写，最初几年抄了8个笔记本，但是后面觉得不是很方便，因为笔记没有归纳，后续整理笔记困难，所以我们完全可以用电子档的形式，这方便后面的归纳修改。我更多是将它当成一个手册吧，我自己也经常遗忘一些API，所以时不时会去翻翻。

回顾：

我们的笔记做了就要经常的翻阅，温故而知新，经常翻阅我们的笔记，经常去总结，突然有一天你的思维就上升了一个高度。

• 慢慢你发现写代码就是不停调用api的过程


• 慢慢你会发现程序里的美感，一个设计模式、一种新思维。我身边很多人都曾经深深沉迷过写代码，那种成就感带来的心流，这是物质享受带来不了的

输出：

就是写文章啦，写文章让我们总结回顾知识点，发现知识的盲区，在这个过程中进行了深度思考。更重要的是，对于不严谨的同学来说，研究一个知识点很容易浅尝则止，写文章驱动自己去更深层系统挖掘。不管对于刚入行的还是资深人士，我觉得输出都是很重要的。

持续提升

先谈谈学历歧视吧，现在很多大厂招聘基本条件就是211、985，对此很是无奈，但是我内心还是认可这种要求的，我对身边的本科985是由衷的佩服的。我觉得他们高考能考上985，身上都是有过人之处的，学习能力差不了。

见过很多工作多年的程序员，但是他们的编码能力无法描述，不管是逻辑能力、代码习惯、责任感都是很差的，写代码完全是应付式的，他们开发的代码如同屎山。额，但是我们也不要一味贬低他人，后面我也学会了尊重每一个人，每个人擅长的东西不一样，他可能不擅长写代码，但是可能他乐观的心态是很多人不及的、可能他十分擅长交际...

但是可能的话，我们还是要不断提高代码素养

• 广度：我们实践中，很多场景没遇到，但是我们要提前去了解，不要等需要用、出了问题才去研究。我们要具备一定的知识面覆盖，机会是给有准备的人的。


• 深度：对于现在面试动不动问源码的情况，很多人是深恶痛绝的，曾经我也是，但是当我沉下心去研究的时候，才发现这是有道理的。阅读源码不仅挺高知识的广度，更多让我们了解代码的美感

具体咋做呢，我觉得几下几点吧。（ps:我自己也做的不好，道理都懂，很难做到优秀呀～～～）

• 扩展广度：抽空多看看别人的文章，留意行业前沿技术。对于我们前端同学，我觉得对整个web开发的架构都要了解，后端同学的mvc/高并发/数据库调优啥的，运维同学的服务器/容器/流水线啥的都要有一定的了解，这样可以方便的与他们协作


• 提升深度：首先半路出家的同学，前几年不要松懈，计算机相关知识《操作系统》《计算机网络》《计算机组成原理》《数据结构》《编译原理》还是要恶补一下，这是最基础的。然后我们列出自己想要深入研究的知识点，比如vue/react源码、编译器、低代码、前端调试啥啥的，然后就沉下心去研究吧。

职业规划

现在整个大环境不好了，程序员行业亦是如此，身边很多人曾经的模式就是不停的卷，卷去大厂，跳一跳年薪涨50%不是梦，然而现在不同了。寒风凌凌，大家只想保住自己的饭碗（ps：不同层次情况不同呀，很多大厂的同学身边的同事还是整天打了鸡血一般）

曾经我满心只有工作，不停的卷，背面经刷算法。22年下半年市场明显冷下来，大厂面试机会都没有了，年过30，对大厂的执念慢慢放下。

我慢慢承认并接受了自己的平庸，然后慢慢意识到，工作只是生活的一部分。不一定要担任ceo，才算走上人生巅峰。最近几年，我爱上了读书，以前只觉得学理工科还是实用的，后面慢慢发现每个行业有它的美感～

最后引用最近的读书笔记结尾吧，大家好好体会一下论语的“知天命”一词，想通了就不容易焦虑了～～～

自由就是 坦然面对生活，看清了世界的真相依然热爱生活。宠辱不惊，闲看庭前花开花落。去留无意，漫随天外云卷云舒。

又到了一年一度的报税阶段。相信现在很多人都是把年终奖分出来单独计税的，但是最近在计算年终奖交税的时候，突然觉得有些怪怪的，网上一查，不止我一个人发现有问题，这里记录一下，也听听大伙有什么看法。

前置工作，我们先来看看个税是怎么计算的。

单独计算

应纳税额 = 年终奖金额 × 适用税率 - 速算扣除数

出处：财政部税务总局公告2023年第30号，自己百度

假设我拿了 40000 年终奖，而且设置单独计算，按照 2023 年税法规定，年终奖适用的七档分阶段税率以及速算扣除数如下（税表三）：

全年一次性奖金单独计税的优惠政策曾在2021年12月延续2年，原本将于2023年年底到期。23年发布的《关于延续实施全年一次性奖金个人所得税政策的公告》将该政策再延4年

来源：http://www.gerensuodeshui.cn/index_gsslb…

适用税率使用的是年终奖总额除以12，分摊到12个月里的均值：40000 / 12 = 3333.33..., 查表后显示我在第 2 档，速算扣除数是 210，税率 10%.

按照计算公式，我的应交税额是：40000 * 10% - 210 = 3790.

合并计算

综合所得应纳税额 = {累计综合所得收入（含全年一次性奖金）－累计减除费用－累计专项扣除－累计专项附加扣除－累计依法确定的其他扣除－捐赠} × 适用税率－速算扣除数

顾名思义，就是将年终奖并入工资计算，这就适合税率表一了：

比如你每月工资 10000，允许扣除的三险一金每月为 2000 元，专项附加每月扣除 2000 元。并入以后全年收入所得：10000 * 12 + 40000 = 160000，查表可得在第三档。税率 20%：(160000 - 2000×12 - 2000×12）* 20% - 16920 = 5480.

交的税明显多多了，你会想，只有傻子才会合并计算啊！

单独 or 合并 ？

但是也有例外，比如你一个工资 5000，年终奖 500000，允许扣除的三险一金每月为 2000 元，专项附加每月扣除2000元，没有其他扣除项目。则单独计税时，年终奖缴纳：500000 * 30% - 4410 = 145590，若是合并计算（全年 56w 收入，在表一的第五档）需缴纳：560000 - 2000 × 12 - 2000 × 12）× 30% - 52920 = 100680，这时候合并计算反而划算了。

大多数情况，当你工资比较多，年终奖相对较少时选择单独计算会更好；当你的年终奖在全年收入中占大头时，合并计算更有利。

临界点问题

你以为这就完了？问题才刚开始，看一下知乎有人的帖子：为什么年终奖个税会存在BUG？

讲的是在现行的税法和相关文件中，年终奖（全年一次性奖金）的个人所得税存在人为设计的「临界点问题」。这个问题新华网也证实了：新华网关于税费计算，即：高收入者的税后收入反而会比低收入者的税后收入还要低的问题。

我们以单独计算为例，假设我年终奖拿了 36000，那么交税：36000 * 3% - 0 = 1080，那么我到手 34920. 假设老板发了善心，给我长了一块的工资，现在是 36001，那么查表可得，在表三中我跨档了，要交税：36001 * 10% - 210 = 3390.1, 此时我到手：32610.9，反而到手还低了！？

网上说是计算公式”弄错“了速算扣除数。速算扣除数并非税法规定，而是根据税法推算出来的一个方便计算的系数。至于速算扣除数怎么来的，可以看这篇知乎文章，写的很详细。我这里总结一下，就是速算扣除数是反推计算的：

• 税率3%对应速算扣除数为0


• 税率10%对应速算扣除数为3000*（10%-3%）+0=210


• 税率20%对应速算扣除数为12000*（20%-10%）+210=1410


• 税率35%对应速算扣除数为25000*（25%-20%）+555=2660


• ...

按我们这个例子：

36,000元，除以12得3000.0000，对应税率3%，速算扣除数0,

税金: 1080 元；

36,001元，除以12得3000.0833，对应税率10%，速算扣除数210，

税金: 1590.1；

据那篇文章所说，问题出现在速算扣除数上，这里的速算扣除数应该用年的，而公式只用了月的。

如果你还是不清楚，我们不用速算扣除数计算，我们按照税法规定的：

• 不超过1500元的 3


• 超过1500元至4500元的部分 10


• 超过4500元至9000元的部分 20


• 超过9000元至35000元的部分 25


• ...

按照税法规定，36,000 年终奖，月平均是 3000，按照他“修订”的公式，应该缴纳：(3000 * 3% + 0 * 10%) * 12 = 1080，36,001 年终奖，月平均 3000.0833, 按照他“修订”的公式，应该缴纳：(3000 * 3% + 0.0833 * 10%) * 12 = 1080.1，等价于现行算法 (3000.0833 * 10% - 210) * 12 相对合理？

文章指出现行算法是这样的： 36001 * 10% - 210 = 3390.1。只减了一个210，就是说每个月都多算了 7%。

总结

按照推论，现有的速算扣除数 * 12 才是真正的速算扣除数。所以计算公式应该是：

应纳税额 = (年终奖金额 / 12 × 适用税率 - 速算扣除数) * 12

按照这个公式，上面36,000 年终奖，月平均是 3000，应该缴纳 (36000 / 12 * 3% - 0) * 12 = 1080，36,000 年终奖，月平均是 3000，应该缴纳 (36001 / 12 * 10% - 210) * 12 = 1080.1

依据: 财政部税务总局公告2023年第30号

所以，写到这里，我也糊涂了，年终奖交税到底要怎么算？谁能告诉我😓

今天听到了堂弟考编上岸的消息，挺为他感到高兴的，因为准备了很久，也失败了多次，最终取得了胜利的果实，真的可以用苦尽甘来来形容。

对于小县城家境一般的孩子，如果不去职场历练，那么唯一的路就是就是考编，但是这条路是充满艰辛的。

去年和一30几岁的同事聊天，他说很羡慕那些考上编制的，即使编制内的工作强度和职场上的工作强度不相上下，但是也是让人望尘莫及。

我思考了下，在职场中为什么感觉累？其实就是两点。

1.对未来的不确定而感动担忧。

2.对当下的不稳定性而焦虑。

对未来的不确定而感动担忧

对于大多数人而言，在职场中就是充当一颗螺丝钉，没有啥核心竞争力，工作所获得的报酬也不可观，面对职场上越来越高的要求，而自己的能力却在原地踏步，坑位越来越少，但是新人却不断在涌入。

这时候就会产生对未来的担忧，这种担忧是对未来是否能在职场里混下去，如果混不下去，那自己又能做什么？

如果现在自己尚未成家立业，那么这种担忧可能不会很强烈，但是如果已经成家，并且身上的担子也不轻，那么这种担忧就会愈加强烈。

这个担忧里面还可以剖解出两个点，职业是否有第二曲线和接受现实的能力。

第一，如果自己已经想好，并且规划好了路线，也有收获了，那么其实是不会有太大的担忧，充其量就是离开平台，换到一个自己有利用价值得平台，或者自己干，这就是职业得第二曲线。

比如年龄大了写不了代码了，那么是否具备做销售的能力，或者是否具有跨行业去做和现在收入不相上下的能力。

第二，是否具有接受现实的能力，比如离开当前的行业，是否愿意跨行去做其它行业并且收入会下降很多，这也和个人消费情况有关。

比如之前的一个同事，因为快40岁了，在职场上已经没有竞争力了，于是他就跨行业去做建材销售，收入肯定比之前的行业低了不少，但是我和他聊的时候，他说其实自己早就意识到这个问题，所以今天走到这一步，其实是在自己的预料里，所以是能坦然接受，不会有很大的心理负担。

那么这种情况其实也不会过于焦虑，就像我们读书的时候，有些同学每天都在玩，你问他如果考不上好的大学怎么办，他会说：我已经准备好去读专科了。那么最后去读专科已经在他的意料中，所以当下自然不会焦虑。

但是有的人又不想学，但是又想考一本，那么当下自然就会焦虑，因为自己希望变好，但是又不去行动。

对当下的不稳定性而焦虑

对于当下的不稳定在我们这个时代其实更加明显，因为到处都在裁员，找工作的人大把。

如果自己所在的公司效益不好，一段时间就会裁员一波人，而自己对于目前的市场又不太了解，那么就会焦虑。

因为今天自己没有拿大礼包，不代表明天不拿，明天不拿，不代表后天不拿，只要效益一日不变好，那么就会提心吊胆的。

所以这就是为什么那些多人击破头脑去考公务员的原因，其实就是不敢面对不稳定性，不敢面对市场的跌宕起伏，并且也意识到自己能力很平庸，没有啥竞争力。

因为就目前来说，考上编制，即使工资不如自己之前，但是他是确定性的，只要你不犯大的错误，那么呆一辈子其实是可能的。

只要你没有太大的支出，并且没有太大的消费欲望，那么其实是可以安安稳稳过日子的，这就是体制的魔力。

以上两点，基本就能概括职场中感到累的原因。

但是我们多数人是考不上编制的，你可以去报一个名试试，相信你会怀疑人生。

那么面对职场的焦虑，这是就需要去做一些实质上的行动和心态上的调整。

实质上的行动就是深耕领域，提升竞争力，或者发展第二曲线，俗话说得好，闲时养兵，战时亮剑，有些现在看似没有用的东西，实际上会在某个时间点发挥作用。

前段时间和几个朋友聊的时候，一朋友说自己还在医院上班的时候，虽然只是个小护士，但是医院里面的机器总是会坏，每次坏的时候，都要等好几天别人才来修，并且也要花费几万块钱，于是在别人修的时候自己就偷学，后面机器坏了，自己就悄悄修好，自己也不说，后面领导发现是他修的，于是对他更加器重。

那么这样的人，即使不做这一行，到了别的行业，他也能从中找到自己的竞争力，也会发光发亮，事实也是如此，他现在转行了，估计也是做得不错。

心态上的调整就是避免去想很多还没有发生的东西，即使知道这一天早晚要来，心态上也要若无其事，因为总是去想那么暂时还没有发生的事情一点卵用都没有，只会把心态搞崩。

其实如果我们仔细观察，我们会发现那些厉害的人，都比较乐观。

因为只有拥有乐观的心态，自己做事情的时候效率才会更高，才不会去想这想那，专注才是进步最好的基石，而专注的前提是乐观。

今天的分享就到这里，感谢你的观看。

不久前开源圈子里的一则消息在网上引起了一阵关注和讨论。

一个由国人开发者所打造的开源项目被 Redis 公司官方给收购了，作者自己也发了动态，表示感谢项目9年以来的陪伴，同时也希望她未来一切都好。

这个开源项目的名字叫做：ioredis，相信不少小伙伴也用过。

目前在GitHub上我们可以看到，ioredis项目的开源地址已经被迁移至 Redis 官方旗下了。

iosredis是国人开发者所打造的一个Redis客户端，基于TypeScript所编写，以健壮性、高性能以及功能强大为特色，并且被很多大公司所使用。

截止到目前，该项目在GitHub上已累计获得超过 13000 个 Star标星和 1000+ Fork。

作者自己曾表示，自己创建这个开源项目的初衷也很简单，那就是当年在这方面并没有找到一个令自己满意的开源库，于是决定自己动手来打造一个，于是就利用闲暇时间，自己从零开发并开源了 ioredis 。

直到2022 年 8 月 30 日，历时整整7年，ioredis 成为了 Node.js 最流行的 Redis 客户端。

而直到如今，这个项目从个人的 side project 到被开源公司官方收购，作者9 年的坚持属实令人佩服，吾辈楷模啊！

而拜访了这位开发者的GitHub后我们会发现，作者非常热衷于创造工具，除了刚被收购的名作ioredis之外，主页还有非常多的开源项目，并且关注量都不低。

而且从作者发的一些动态来看，这也是一个热爱生活的有趣灵魂。

有一说一，个人开源作者真的挺不容易的，像上面这样的个人开源项目被官方收购的毕竟是个例，其实好多个人的开源项目到后期由于各种主客观原因，渐渐都停止更新和维护了。

大家都知道，伴随着这两年互联网行业的寒意，软件产业里的不少环节也受到了波动。行业不景气，连开源项目的主动维护也变得越来越少了。

毕竟连企业也要降本增效，而开源往往并不能带来快速直接的实际效益。付出了如果没有回报，便会很难坚持下去。

而对于一名学习者而言，参与开源项目的意义是不言而喻的，之前咱们这里也曾多次提及。

参与开源项目除了可以提升自身技术能力，收获项目开发经验之外，还可以让自己保持与开源社区其他优秀开发者之间的联系与沟通，并建立自己的技术影响力，另外参与优秀开源项目的经历也会成为自己求职简历上的一大亮点。

所以如果精力允许，利用业余时间来参与或维护一些开源项目，这对技术开发者来说，也是一段难得的经历！

近两年互联网行业不景气，很多程序员都在寻找新出路。很自然的，独立开发成为一个充满吸引力的选择 —— 背靠自己的开发技能，不用看老板脸色，靠产品养活自己，想想就很美好。

但恕我直言，保守点说，90%的程序员不适合做独立开发。

这篇文章全是大实话，虽然会打破一些人的幻想，但也提供解决方案，希望对迷茫的同学有些帮助。

独立开发赚钱么？

如果你满足如下画像：

• 程序员工作多年，编程水平不错


• 收入完全来源于工资


• 日常学习的目的是提升技术

那对你来说，独立开发是不赚钱的。不赚钱并不是说做这事儿一分钱赚不到，满足以上画像的大部分独立开发者在持续经营半年到一年产品后，还是能稳定获得几刀～几十刀收益的。只是相比于付出的心血来说，这点收益实在是低。

以至于出海独立开发圈儿在谈收益时的语境都不是我开发了1年，现在每月能赚50刀，而是我开发了1年，现在拥有了等效于3w刀年化2%的货基（3w * 2% / 12 = 50）

这么一换算，欣慰了许多。

为什么不赚钱？因为独立开发的重点并不在于开发，叫独立产品会更准确些。

对于一款形成稳定变现闭环的产品，有3个最重要的环节：

• 流量获取


• 运营转化


• 产品交付

程序员只是产品交付环节下的一个工种，与你同处产品交付环节的工种还包括产品经理、QA、项目经理、运维......

做独立开发的本质就是你一个人抗下上述所有工种。

话又说回来，如果你即会编程又会流量获取，会运营转化，这样的复合人才在公司根本不用担心被裁，也没必要做独立开发。

所以，对于满足以上画像的同学，我劝你不要把独立开发当作失业后的救命稻草。

认识真实的商业世界

虽然我不建议你all in独立开发，但我建议有空闲时间的同学都去尝试下独立开发。

尝试的目的并不是赚钱，而是更具象的感知流量获取 -> 运营转化 -> 产品交付的路径。

大部分互联网产品往简单了说，都是表格 + 表单的形式，比如推特就是2个大表单（推荐流、关注流）以及描述用户之间关系的表格。

既然如此，当我们有了独立开发的想法时，首先考虑的应该是 —— 我的产品能不能用表格 + 表单 + 高效沟通实现，比如腾讯/飞书文档 + 微信群交流。

像多抓鱼（做二手书业务）早期验证需求时，就是几个用户群 + 保存二手书信息的excel表组成。

如果你发现需求靠微信群交流就能解决，付款靠微信转账就能解决，那还有必要写代码开发项目，对接微信支付API么？

当聊到微信交流时，其实就触碰到另一个工种的工作范围了 —— 私域运营。在私域运营看来，通过微信（或其他社交软件）成交是再正常不过的商业模式，但很多程序员是不知道的。

这就是为什么我不建议你把独立开发当作被裁后的救命稻草，但建议有空闲时间的同学都去尝试下独立开发 —— 涉猎其他工种的工作范围，认识真实的商业世界。

当达到这一步后，我们再考虑下一步 —— 发掘你的长处。

发掘你的长处

当我们认识到一款完整的产品有3个最重要的环节：

• 流量获取


• 运营转化


• 产品交付

就应该明白 —— 如果我们想显著提高独立开发的成功率，最好的方式是找到自己最擅长的环节，再和擅长其他环节的人合作。

这里很多程序员有个误区，会认为程序员擅长的肯定就是产品交付下的开发。

实际上，就我交流过的，或者亲自带出来的跑通变现闭环的程序员中，很多人有编程之外的天赋，只是他们没有意识到罢了。

举几个非常厉害的能力（或者说天赋）：

有一类同学敢于把自己放到当前可能还不胜任的位置，然后通过不断学习让自己完成挑战。举几个例子：

• 在不懂地推的时候，参与到校园外卖团队做地推，学习市场和推广的知识


• 在只看了一本HTML书的情况下，敢直接接下学校建设国际会议网站的任务


• 在不懂做运营的时候，有老板找他当公司运营负责人，他也接下来，并也做得很好

这类同学很容易跑出有自己特色的非标服务，再包装成产品售卖。

2. 源源不断的心力支持

前文

10年前我非常好奇这个长得和MySQL一模一样的东西的发展，直到今天有了答案，MariaDB股价大跌，陷入财务危机，没有营收，砍产品，裁员，更换管理层，借债等等。

MariaDB曾经有一个InnoDB加强版的说法，但是从开发者的视角，没有必要关心里面是什么。 即使page head加强、page tail优化，page directory综合做了完善的更改。开发者只关心它在应用业务性能上有没有体现，使用是不是与MySQL一模一样。

从WEB应用体验，MariaDB与MySQL做比较，MariaDB的使用与MySQL的外模式和内模式一样。外模式指MySQL常用的SQL语句【等值查询、范围查询、聚合查询、窗口查询、两表关联、多表关联】，内模式指MySQL内部的元数据信息【数据字典、动态视图、静态视图】。

几乎可以把MariaDB当成套壳的MySQL，以此为镜， 300多个国产数据库可以感受到自由市场的竞争残酷。截至2月份， dbegines排行13名的MariaDB处于分崩瓦解的边缘。它给国产数据库的启迪是什么？我们怎么去发展建设国产数据库品牌。

千年前，明太祖朱元璋征求学士朱升对他平定天下战略方针的意见，朱升说：高筑墙，广积粮，缓称王。国产数据库可以遵从此道 ，高筑墙建立自己的品牌壁垒，广积粮营造自己的商业生态 。

从数据库的本质为应用服务、目标人群是商业实体，使用者多是开发者、DBA，我想到的三点有助于数据库品牌的建设。

协助建设应用

从目标利用的角度，天下应用分为以下三种系统建设，数据库作为系统中的核心服务,始终是为应用服务，应用是最终的变现。

信息系统建设方案： 传统的应用建设，主要是将现象生活反映到电子流，往往是单条业务流程整合，包括企业流程制度、企业控制管理、员工权限授权访问，常说的烟囱系统建设以及企业信息系统以及ERP、CRM、OA、交易系统、分析系统都属于这个范畴。此处数据架构较简单。

大数据系统建设方案: 此不仅仅包括我们常说的大数据建设，该应用建设表现往往高并发、高吞吐、低延迟、快响应，有时候需要整合较多的数据源，将集成较多的数据集，主要与业务系统联通或者其它设备的数据汲取过来，通过清洗、整合、编排后，输出一个错落有致、规范得体的数据指标，再反哺业务系统。用户跟踪、业务监控管理、实时需求预测都属于大数据系统的建设方案范围，主要它是能整合不同的数据，此处数据架构较复杂。

智能系统建设方案: 该系统建设属于高端信息应用范畴，需要智能算法以及更有效率的计算框架，包括音、视频、 边缘计算 、AI、 大模型、 AIGC等等，同时也包括基本的信息系统建设方案和大数据系统建设方案，智能系统建设是应用优化的永无止境的追求。主要表现是提供更加友好验证手段，以及更加便利的识别方法提供相应的服务，一般智能系统会搭承其它技术手段完成客户端需求的闭环。

目前信创改造以及国家信息发展项目，大部分以信息系统建设方案和 大数据系统建设方案居多，所有的国内厂商创收盈利来自此处。因为有逐利的目的性，厂商有目标奔向这些项目。

但是对一些开源信息系统的适配，没有厂商愿意接入，因为没有任何利润可言。例如wordpress目前只支持MySQL，从技术上的改造，这个是简单的，但是没有人愿意做这样的事。大部分国内数据库厂商已经完成国内头部ERP厂商的适配兼容，数据库兼容wordpress是轻而易举的事情。

数据库厂商可以试着从基于利润创收的目的性适配应用，切换到主动适配发展应用创新的模式。

从信息系统建设方案来看，目前国内大多的开源系统底层使用MySQL，这个在侧面反映在中国MySQL为什么比postgreSQL火的原因，postgreSQL在世界很流行，但是在中国普及不如MySQL。

大数据系统建设方案较复杂，单一的数据库无法解决所有的问题，但是可以作为方案其中的一个实力支撑点，目前许多厂商都与上下游产品已经完成适配兼容， 但是没有脍炙人口的成熟的技术栈自成一套的解决方案。

例如某管理系统平台的技术栈如下， Hadoop +Hive +Kafka +Zookeeper + HBase +Sqoop +Flume + 国产厂商产品，国产厂商产品的位置也许随便用国际主流数据库产品就可以替代。为什么还用不熟悉的国产厂商产品？

这里需要宣传，需要推广，需要实践使用，需要生根发芽，了解国际的现状，认清与国际的差距，他们能做的，我们也能做。

这是文化使用习惯的问题，同样是碳酸水，可口可乐和百事可乐已经是有口皆碑，国内的炭酸水的味道和质量不比可乐差，为什么销量比不过这两家。其中一个原因，可乐不仅在饮料行业生根发展，而且在食谱行业也有建树。例 如可乐鸡翅，可乐不仅可以用于消暑解渴，而且可以用于烹饪食物。

严格科学上来说，可乐是越喝越渴的，根本不能够解渴，但是可乐的口感还不错，价格还可以，人们就建立喝可乐可以解渴的信仰。这信仰一时三刻撼动不了。国产可乐要摇动 可口可乐和百事可乐的位置，长期宣传推广是必不可少，多搞点可乐鸡翅、可乐鸭掌是根本，可乐应用于烹饪，可乐应用于清洁用途，可乐应用于除味。

智能系统建设方案这里比较特别，传统数据库与智能应用的依赖相对弱，一些数据库厂为了加强核心能力，已经推出向量型数据库。标准的现代化的数据库的基本能力，无论是结构化数据、半结构化数据、全结构化数据都可以在库中进行处理。

事实上智能系统建设方案更偏重应用端的处理能力，识别特征、应用模型、计算方式非常重要，这些都不是数据库能够兜底的，真正的智能系统建设方案可以不靠虑数据库产品选型，但是数据持久化落地，必定要选择其一款数据库。

智能系统建设方案应用场景比 信息系统建设方案、大数据系统建设方案更加变幻莫测。

信息系统建设方案建设重点，数据库作为数字基座提供能力如下，包括系统稳定、高并发访问性能、交易查询请求功能、各种业务函数、友好的使用方式 ， 满足项目级、部门级应用发展的需求。

大数据系统建设方案方面，数据库原有的基础能力新增，包括分布式处理能力、多模型构建能力、事务交易同体能力、内外数据集成能力 、动态伸缩能力 ，满足跨部门的集团级应用发展的需求。

信息系统建设方案和 大数据系统建设方案的对比区别，一个是简单，一个复杂，而智能系统建设方案则是强调应用端的建设，服务端获取特征参数，在后端联调大量的模型，连接不同的数据库、知识库、文件系统做特征识别匹配，返回给客户。

那么智能系统建设方案 普及的应该如何建设？数据库厂商大力投入，带头组织活动，鼓励应用创新，推动金融智能应用、电信智能应用、制造业智能应用的发展，有助于提高厂商的品牌力，暴光厂商在智能系统建设方案 方面的实践经验，增强厂商的威望值。

笔者看来，信创及国产化大多属于信息系统建设方案和大数据系统建设方案， 智能系统建设方案则是未来社会发展的应用硬性需求，厂商可以大力投入。

建设产品的长宽高壁垒

产品品牌力犹如一个盒子，由长宽高组成， 长度不够、宽度不及、高度不深都会造成品牌力的短板，无法把客户的信心牢牢装在里面。

下面列出产品长度、产品宽度、产品深度相关的指标来量化一个国产数据库的综合实力，努力往这三方面发展应该是没有错的。知己知彼，百战百胜，产品长宽高是知己，知道自己已经做的事和即将要做的事。

产品长度重点考察应用案例

• 确定行业头部企业覆盖范围【金融行业、通信行业、制造业】


• 确定行业相关企业覆盖面积【企业个数】


• 确定行业主流应用场景【生产、经营、交易、办公】


• 确定应用场景影响范围【核心业务、辅助业务 、边缘业务】


• 确定产品基于生产环境运行的稳定性【精确到年】


• 确定产品具备满足未来业务几年的性能【数据量增长】


• 确定产品利于业务展开运行的功能【产品功能与业务需求匹配度】

产品宽度重点考察生态适配

• 软件上游 CPU、芯片、操作系统、文件系统


• 软件下游 BI软件、数据集成软件、ORM框架、数据可视化


• 与Oracle、Postgresql、MySQL的适配兼容


• 基于产品基础上的二次github技术开源


• 同类软件的适配兼容调度集成


• 行业标准接口JDBC\ODBC的适配兼容


• 建立合作伙伴战略关系


• 打造用户的社区【成熟度评估】


• 高校教育培养使用人群

产品深度重点考察产品是否与时俱进

• 行业主流技术【向量化计算、向量化数据类型、边缘计算】


• 社会趋势【区块链】


• serverless平台


• 云计算系列


• 内置支持人工智能、机器学习、数据分析、业务函数


• 高校实验室底层研究

构建购买者和使用者的体验闭环

知己知彼，百战百胜，构建体验是知彼，知道对方对产品的感受以及使用者的反馈。

数据库作为一个商品，处处展现着生产者、购买者、使用者的关系。 生产者【厂商 】根据市场上的需求，丈量自家的研发实力开发了这么一个商品，当务之急就是要找到客户【购买者】，客户选择商品的背后有1000个原因。成交之后，使用者进场。购买者与使用者之间是甲方与乙方的关系，乙方根据产品的使用说明，使用相关解决解业务中的一系列问题。

厂商做的事情，包括引起购买者的兴趣，千方百计使用各种营销方式或者推广手段使购买者甘心付费成单，并且使用使用者的产品使用，包括质量反馈和功能缺点。

购买者体验

商品列入购买者的采购清单范围 ，可能原因是是产品的【协助建设应用】和【长宽高壁垒】做了大量铺垫，举例某产品应用于人工手势智能系统中，XX商品充当核心服务存储，XX商品应用于同行业的用户画像分析业务场景，或者XX商品联同BI软件已经在驾驶舱系统运行中。

在商品已经得到购买者的侧目，下一步是实践得到客户的肯定。下面的POC以及持久的技术支持将证明产品具备满足客户业务需求的功能和性能。

厂商对客户的进一步输出，可以量化为以下三个指标。依次为服务响应时间、竞品对应亮点、应用迁移经验。

服务响应时间，包括解决具体问题花的时间，到达现场花的时间，响应客户问题花的时间，原则上客户提出的问题 和疑问都要第一时间解答， 为此企业会有相应的知识库储备 ，针对问题可以马上解答。

竞品对应亮点, 建立同类相关产品对标，并突出本产品优势、亮点，数据库产品大同小异，全部产品都有数据存储、管理、使用的功能，但是单机产品与分布式无法100%进行匹配度。可以参考**【协助建设应用】和【长宽高壁垒】。**

应用迁移经验，客户关心第数据底座搬迁后的稳定性，基于数据库的应用迁移工作包括 具体数据迁移、数据结构迁移、SQL相关迁移，保障迁移后是无缝迁移状态。

具体数据迁移主要包括数据一致性、数据数量是否同、数据内容是否同等、数据是否转换等等。

数据结构迁移主要包括表结构、数据类型、数据长度、存储过程、函数、同义词等等，基于新底座转换后运行逻辑流程是否与原来相同 。

SQL相关迁移主要指SQL语句以及SQL相关的SHELLl调用、ETL语句，ORM框架内置SQL，基于新底座转换后运行逻辑流程是否与原来相同。

使用者反馈

在客户正式成为购买者后，使用者成为高级产品反馈者，厂商收集使用者和项目的相关信息，同时也是在进行**【协助建设应用】和【产品长宽高壁垒】**。

厂商对客户的进一步输出，可以量化为以下三个指标，包括项目业务背景，技术套件、文件使用、产品使用状况。

业务背景，包括项目驱动因素，领导愿景、发展目标、立项初衷等等，根据这些已知信息，掌握项目的痛点和痒点，评估项目预期可以做到的效果。

技术套件，记录包括项目中原来的和准备用上的技术套件，包括前端、UI、ORM框架构、中间件、数据库等相关解决方案一切用上的技术工具。

文档使用，建立用户对文档使用过程中的体验，根据厂商的提供的资料，是否足够工程师独力完成任务，不需要与厂商 互动。

产品使用状况，构建用户与研发互动和反馈的平台系统和制度流程， 包括API使用、DEMO操作、无法解决的问题。

总结

总的来说，品牌力不可能一蹴而就。围绕三点协助建设应用、建设长宽高壁垒、构建购买者和使用者的体验闭环进行数据库品牌力建设，笔者也是泛泛而谈展开铺叙，细节方面可以有更多补充。

最后概括以协助建设应用、建设长宽高壁垒为基本点，以此为线，赋能项目成单，增进客户的信心，交付项目使用。同时从购买者体验、使用者反馈搜集信息和数据，促进产品良性发展以及项目拿下订单，周而复始，不断循环。

自从ChatGPT带动全球AI热潮，AI席卷着各行各业。编程界也不例外，最出名的摸过OpenAI与GitHub联合开发的Github Copilot。Github Copilot带动了一大堆AI编程工具的出现。后来Github Copilot付费了，再加上网络方面的问题，在国内使用Github Copilot还是有一定门槛的。那么在国内有没有适合国内程序员使用的类Github Copilot产品呢？下面分享一下个人安装使用的一些AI编程插件：

p.s.以上的下载量与评分均只是plugins.jetbrains的marketplace数据，仅供参考。

基本AI编程工具的功能都差不多：

• 代码补全：根据当前代码上下文自动补全代码。


• 根据注释生成代码：根据注释描述生成相应的代码。


• 方法和函数生成：根据方法名或函数名自动生成该方法或函数的代码。


• 生成测试代码：生成测试代码。


• ....

具体选择可以自己体验一下，国内用户可能试用下codegeex、aixcoder。

1、Github Copilot

GitHub Copilot是一款由GitHub和OpenAI共同开发的基于云的人工智能工具，它可以帮助开发者自动生成代码、分析代码、调试代码以及进行安全检测等。Copilot是基于OpenAI的GPT-4模型开发的，可以通过文本问答的方式与开发者进行交互。

• 效果

生成代码文档

当然大家可能比较关心的是如果不花钱，免费使用Github Copilot。除了官方试用，另外在国内自然是有大神

去破解它。如果你破解过idea的话，再关注下那个大神的博客基本就可能以找到这个了。

国内到国外访问Copilot Chat，会时不时的会抽风。

• 评分(3.0)

• 下载量(7,476,947)

2、Codeium

Codeium是一款免费的智能编程助手，由美国一家公司开发。它提供了超过40种编程语言的代码完成工具。这个工具支持几乎所有主流的编程语言和IDE，特别适合个人用户使用。Codeium的主要功能包括自动完成代码，从样板文件到单元测试节省时间，以及使用自然语言问题搜索存储库。此外，它还提供了一个Playground体验，可以直接在浏览器上试用Codeium的功能。

• 界面截图

安装后需要登录，不过国内打不了。我登录后使用的效果很一般，估计网络太差。。。

• 评分(4.7)

• 下载量(328,213)

• 小结

• 
  
  
  
  • 国内不怎么好用，登录不了
  
  
  
  

3、CodeGeeX(开源)

CodeGeeX是一个强大的基于LLM的智能编程助手。提供代码生成/补全、注释生成、代码翻译、AI聊天等功能，帮助开发人员大幅提升工作效率。CodeGeeX是由清华大学知识工程实验室研发。它支持20多种编程语言，并适配多种主流IDE。

• 效果

• 评分(3.6)

• 下载量(258,540)

4、Amazon CodeWhisperer

亚马逊CodeWhisperer是AWS提供的一种AI驱动的工具，它帮助开发者更高效地编写代码。它提供实时代码建议，支持自然语言到bash的翻译，并能进行安全扫描。此外，它还包含了Amazon Q，这是一个交互式AI助手，能在IDE中提供专家指导和代码解释。CodeWhisperer设计用于多种编程语言和集成开发环境（IDE），并且可以定制以更好地理解您的内部库和API。

由于idea版本的问题没有安装上

不过下载量还是比较高，但评分就相当的低

• 下载量(6,213,740)

• 评分

5、Tabnine

Tabnine是一款AI编程助手，它通过实时代码补全、聊天和代码生成功能，帮助开发者提高编码效率。

Tabnine是由以色列的开发者创建的，它是一款基于人工智能的编程助手，旨在提高代码编写的效率和质量。

自2018年推出以来，Tabnine已经成为软件开发领域生成式AI技术的先驱，并且在全球范围内拥有超过一百万的月活跃用户。Tabnine支持所有流行的编程语言和IDE，能够根据您的代码和模式提供个性化的建议。它还提供私有部署选项，确保代码的安全性和合规性。

• 效果

免费版只提供自动补全代码，别的功能需要付费

Tabnine Pro提供全线和全功能代码完成，这是免费版本中不包括的

• 评分(3.9)

• 下载量(3,528,356)

6、aiXcoder

aiXcoder是一款基于人工智能的软件开发助手，它通过深度学习技术提供代码自动生成、代码自动补全、代码智能搜索等功能，旨在提升开发者的开发效率和代码质量。

• 效果

• 评分(4.1)

• 下载量(455,879)

7、ChatGTP-EasyCode

EasyCode是一个基于IntelliJ IDEA开发的代码生成插件，它通过自定义模板来快速生成Java、HTML、JS、XML等代码。这个工具特别适合Java程序员进行CRUD操作，因为它可以自动搭建MVC三层架构，从而减少重复性工作，提高开发效率。EasyCode支持与数据库相关的代码生成，并允许用户根据个人需求定制模板。

• 效果

没有自己补全，但可以使用右键把机器人对话窗口调出来

• 评分(4.0)

• 下载量(727,619)

8、TONGYI Lingma(通义灵码)

通义灵码是阿里云推出的一款智能编码助手，它基于通义大模型，提供了一系列编程辅助功能，包括代码智能生成、研发智能问答、代码注释生成等。它能够根据当前代码文件及跨文件的上下文，为开发者生成行级或函数级的代码、单元测试和代码注释，从而提高编码效率和质量。通义灵码还支持自然语言生成代码，即开发者可以用自然语言描述想要的功能，通义灵码会根据描述生成相应的代码和注释。

• 效果

右键效果

• 评分(3.3)

• 下载量(961,347)

有什么事是你当了程序员之后才知道的？

地铁上刷到一个话题，觉得挺有意思的，如下。

看到很多朋友在下面吐槽，有说加班是真的多，有说找对象是真的难，有说程序员爱穿格子衫是假爱背电脑是真的等等，大家吐槽得都挺欢乐的。

老猫也开始复盘这些年的经历，更多想聊的可能还是一个后端程序员的真实感悟。

入行

俗话说“男怕入错行，女怕嫁错郎。”相信很多朋友在进入一个行业之前都是深思熟虑的，亦或者是咨询过一些人，亦或者是查阅了挺多资料。然而老猫入行则相当奇葩，不是蓄谋已久，而是心血来潮。

一切都得从一部电视剧开始，不晓得大家有没有看过这部电视剧，佟丽娅主演的“我的经济适用男”。

12年的一部电视剧，挺老了，主要女主放弃富二代的追求和"成熟稳重老实巴交的IT男"好上了的桥段。当时心智单纯的老猫可谓看的是热血沸腾啊。一拍桌子，“发可油，劳资今后就要当那个男主，这结局多好啊，抱得美人归啊这是，我要学IT!”。当时老猫的专业是电子信息类的专业，后来基本就放弃了本专业，大学基本逃课就跑去学软件去了。

就这么上了贼船，一晃十年过去了。多年前，躲在实验室里，开发了一个简单的坦克大战的游戏，感觉自己是最牛逼的，子弹爱怎么飞怎么飞，坦克能开多块就开多快，那时候觉得自己就是这个IT世界的主角，“control evety thing”。在这样一个程序的世界里，所有的事儿都是自己说了算。

踏上社会后，遭遇社会惨无人道地毒打之后，发现要做的就是提升造火箭吹牛逼的能力，工作中是个crud-boy。键盘上磨损最严重的那几个键是“ctrl”,“c”,“v”,“x”。当年那个意气风发的少年已经不复存在，我是一个弱鸡螺丝钉。

工作十年

大部分后端程序员也主要是围绕着业务在转，所以crud可能占了大部分时间。

话虽如此，但还是有点除此以外的收获，这些收获甚至潜移默化地影响着我的生活。

技术日新月异，今天这个框架，明天那个架构，今天这种实现牛逼，明天那种部署更6等等，到头来发现自己一直都是在追着技术跑。也确实如果不奔跑的话，可能就会被淘汰。作为程序员来说适应变化也是程序员的一种品质，但是老猫觉得具备下面这些可能会更加重要一些，这些可能也是唯一不变的。

抽象思维很重要

第一次听到“架构师”这个职位的时候，觉得那一定是一个需要超强技术能力的人才能胜任的岗位。

后来才发现原来架构师也分种类，“业务架构”，“技术架构”等等。再后来发现无论哪种架构，其实他们身上会有一种共同的东西，那就是优秀的抽象思维。

啥是抽象思维？百度百科上是这么说的：

抽象思维，又称词的思维或者逻辑思维，是指用词进行判断、推理并得出结论的过程。

抽象思维以词为中介来反映现实。这是思维的最本质特征，也是人的思维和动物心理的根本区别。

说的比较官方，甚至有点不好懂。

大家以前上语文课的时候，有没有做过阅读理解，老师在讲课的时候常常我们概述一下这段文字到底讲了什么东西，越精简越好，可能要求20个字以内。其实这个过程就是在锻炼咱们的抽象思维能力以及概括能力。

在软件后端领域，当业务传达某一个需求的时候，往往需要产品去提炼一道，那么此时就是产品抽象，继而产品又将需求传达给相关的研发负责人，研发负责人设计出相关的实现模型，那么这又是技术抽象，这些抽象的过程就是将复杂的业务流程和逻辑转化为可管理和可重用的组件的过程。它的目的是简化系统的实现，聚焦于应用程序的核心功能，同时隐藏不必要的细节。抽象后设计出各种基础能力，通过对基础能力的组合和拼接，支持复杂多变的业务逻辑和业务形态。

具备抽象思维，能够让我们从复杂的业务中迅速切入业务关键点。在生活中可能表现在透过现象看到本质，或者碰到问题能够快速给出有效解决方案或思路。例如老猫上次遇到的“真-丢包事件”。

分层思维很重要

说到分层思维，应该准确地来说是建立在能够清晰的抽象出事务本质的基础上，而后再去做分层。

很多地方都会存在分层思想。生活中就有，大家双休日没事的时候估计会逛商场，商城的模式一般就是底层停车场，一层超市，二层卖服装的，三层儿童乐园，卖玩具的，四层吃饭看电影娱乐的等等。

再去聊到技术上的分层思想，例如OSI七层模型，大家在面试的时候甚至都碰到过。

抛开这些，其实我们对自己当前负责的一些业务，一些系统也需要去做一些分层划分，这些分层可以让我们更好地看清业务系统之间的关系。例如老猫之前梳理的一张图。

通过这样的分层梳理，我们可能更好地理解当前的系统组成以及层级关系。（备注一下，老猫这里画图工具用的还是wps绘制的）。

结构化思维很重要

结构化思维又是咋回事儿？
不着急，打个比方，咱们看下面一组数据：
213421790346567560889
现在有个要求，咱们需要记下这些数字，以及出现的次数。短时间内想要记住可能比较困难
如果我们把这些数字的内容调整下，变成下面这样：
00112233445566778899
是不是清晰了很多？

所谓的结构化思维，就是从无序到有序的一种思考过程，将搜集到的信息、数据、知识等素材按一定的逻辑进行分析、整理，呈现出有序的结构，继而化繁为简。有结构的信息更适合大脑记忆和理解。

人类大脑在处理信息的时候，有两个特点：

第一，不能一次太多，太多信息会让我们的大脑觉得负荷过大；乔治·米勒在他的论文《奇妙的数字7±2》中提出，人类大脑短期记忆无法一次容纳7个以上的记忆项目，比较容易记住的是3个项目，当然最容易的是1个。

第二，喜欢有规律的信息。有规律的信息能减少复杂度，Mitchell Waldrop在《复杂》一书中，提出一种用信息熵来进行复杂性度量的方法，所谓信息熵就是一条信息包含信息量的大小。举个例子，假设一条消息由符号A、C、G和T组成。如果序列高度有序，很容易描述，例如“A A A A A A A … A”，则熵为零。而完全随机的序列则有最大熵值。

老猫在写文章的时候喜欢先列一下要写的提纲，然后再跟着提纲一点一点的往下写，写定义，写实现，写流程。

虽然本文偷了个懒，没有写思维导图，老猫一般再聊到干货的时候都会和大家先列一下提纲。这种提纲其实也是结构化的一种。当我们遇到复杂系统需求的时候，咱们不妨先列个提纲，将需要做的按照自己定义好的顺序罗列好，这样解决起来会更加容易一些。

太过理性可能也不好

程序员做久了，做一件事情的时候都会去想着先做什么然后做什么一步一步，有时候会显得过于机械，不知变通，
有时候可能也会太过较真，大直男显得情商比较低，会多多少少给别人带去一些不便，记得在银行办理业务的时候会指出业务员说话的逻辑漏洞，然后不停地追问，最终可能导致业务员尴尬地叫来业务经理解释等等。

程序员思维做事情，可能在日常生活中比较严谨，但是很多时候还是会显得比较死板。

总结

以上是老猫觉得除了技术以外，觉得一个后端程序员应该具备的一些思考方式以及工作方式，当然也可能只是老猫的方法论，如果大家有其他的工作领悟，也欢迎大家留言，大家一起分享一下经验。

数学博士吐槽华为招聘

今天刷到一篇帖子：

文中来自川大的数学博士吐槽了华为对数学博士的招聘。

作者强调自己是川大的本硕博（算子分析方向），有论文，也拿过国家一等奖。

但自己投的华为简历，却石沉大海，了无音讯。

还直言道：自己在数学系待了 10 年，没有任何一个数学博士能够满足华为招聘三条要求中的两条，如果数学博士干的是华为招聘上的事情，毕业都难。

这事儿，怎么说呢，从不同角度，会有不同的理解。

首先，在企业招聘中，学历往往是起点门槛要求，而非唯一要求。

因此肯定不是说满足数学博士要求，就必然入面试，这一点和「本科/硕士」一样。

其次，企业招聘中，往往是「应用类」人才占比要比「科研类」人才占比更高。

因此在学历（数学博士）要求上，往往还会有企业所期望的技能要求，例如文中说的「熟练使用计算机编程语言」，也算是常规操作。

至于原帖作者说的，因为「华为招聘中有很多不是数学博士专业领域知识要求」，就得出「华为觉得不到这个水平就不算是博士」的结论，多少有点偏激了。

...

回归主线。

来一道不是数学博士也能做出来的算法题。

这道题曾经还是华为的校招机试原题。

题目描述

平台：LeetCode

题号：172

给定一个整数 $n$ ，返回 $n!$ 结果中尾随零的数量。

提示 n! = n * (n - 1) * (n - 2) * ... * 3 * 2 * 1

示例 1：

输入：n = 3



输出：0



解释：3! = 6 ，不含尾随 0

示例 2：

输入：n = 5



输出：1



解释：5! = 120 ，有一个尾随 0

提示：

• $0 <= n <= 10^4$

进阶：你可以设计并实现对数时间复杂度的算法来解决此问题吗？

数学

对于任意一个 $n!$ 而言，其尾随零的个数取决于展开式中 $10$ 的个数，而 $10$ 可由质因数 $2 * 5$ 而来，因此 $n!$ 的尾随零个数为展开式中各项分解质因数后 $2$ 的数量和 $5$ 的数量中的较小值。

即问题转换为对 $[1, n]$ 中的各项进行分解质因数，能够分解出来的 $2$ 的个数和 $5$ 的个数分别为多少。

为了更具一般性，我们分析对 $[1, n]$ 中各数进行分解质因数，能够分解出质因数 $p$ 的个数为多少。根据每个数能够分解出 $p$ 的个数进行分情况讨论：

• 能够分解出至少一个 $p$ 的个数为 $p$ 的倍数，在 $[1, n]$ 范围内此类数的个数为 $c_1 = \left \lfloor \frac{n}{p} \right \rfloor$


• 能够分解出至少两个 $p$ 的个数为 $p^2$ 的倍数，在 $[1, n]$ 范围内此类数的个数为 $c_2 = \left \lfloor \frac{n}{p^2} \right \rfloor$


• ...


• 能够分解出至少 $k$ 个 $p$ 的个数为 $p^k$ 的倍数，在 $[1, n]$ 范围内此类数的个数为 $c_k = \left \lfloor \frac{n}{p^k} \right \rfloor$

我们定义一个合法的 $k$ 需要满足 $p^k \leqslant n$，上述的每一类数均是前一类数的「子集」（一个数如果是 $p^k$ 的倍数，必然是 $p^{k-1}$ 的倍数），因此如果一个数是 $p^k$ 的倍数，其出现在的集合数量为 $k$，与其最终贡献的 $p$ 的数量相等。

回到本题，$n!$ 中质因数 $2$ 的数量为 :

$n!$ 中质因数 $5$ 的数量为 :

由 $2 < 5$，可知 $k_2 \leqslant k_1$，同时 $i$ 相同的每一项满足 $\left \lfloor \frac{n}{5^i} \right \rfloor \leqslant \left \lfloor \frac{n}{2^i} \right \rfloor$，可知最终 $\sum_{i = 1}^{k_2}\left \lfloor \frac{n}{5^i} \right \rfloor \leqslant \sum_{i = 1}^{k_1}\left \lfloor \frac{n}{2^i} \right \rfloor$，即质因数 $5$ 的个数必然不会超过质因数 $2$ 的个数。我们只需要统计质因数 $5$ 的个数即可。