“小森林” 码工版

2020-06-28 作者： Fisherworks

明．陈全之《蓬窗日录》卷八：“春耕夏耨（nòu），敢辞涂足之勤；秋获冬藏，实切资身之望。”

日剧《小森林》，前后两部四集，全面的描绘出一个不甘挣扎于城市枯燥生活的妹子，返乡后独居，靠自己一双手打造返璞归真“小确幸”的图景，唯美、静心。本是2014/2015的片子，不知为何，去年突然火爆国内，还盖上“日版李子柒”的标签，颇觉给脑袋里整日萦绕“逃离北上广”的年轻人们一丝抚慰。

“农协开的小超市，冬雪中需步行一个半小时，而去临镇的大型城外超市购物，来回要一整天”，一句话下来，心凉半截；前可着村，但后不着店，换言之，一切靠自己了。

剧集展现给我们的，也确实如此：一日三餐，每餐结束之后，手头活计如果不是在准备下一餐，应该就是在准备下N餐（腌制发酵食品，或晾晒干制食品），日复一日，周而复始。另有国产美食剧集《一人食》好像也是在2014年上线的，并没有很火，我也没有看过，家里那口子倒是个不折不扣的美食爱好者。

洋洋洒洒说了这么多，跟码工又有几毛钱关系呢？码工嘛，又称“互联网从业者”，算是近年实体经济普遍乏力后，苦出身底层娃们为数不多的上升通道了。

所谓互联网大厂，自然有大厂的好处。流水线作业毕竟分工细，需求有人出，测试有人做，UI有人画，运维有人管，自己聚焦自己的一亩三分地；即使起新项目，研发主管还给脚手架工程做参考，说到底，搬砖就搬自己的砖，搬多少块结多少账，公平合理。要在大厂晋升，当然也是有讲究的。真材实料不可或缺，搬砖一路搬到CTO多半不可行；即使做技术主管，也得有点架构意识，当个“流水线线长”，知道不同目标需求下的技术组合和性能指标，关注外界趋势，跟合作项目组打太极，了解手底下那几个货适合搬什么砖，以及他们万一不干了，排队来搬砖的还有谁，等等。

言而总之，大厂工作如果不来点自黑，比拼个端午、中秋礼包设计，那真像极了城市生活两点一线，日子不停复制粘贴的感觉。作为移动互联网时代流水线工人，面对“弹性工作”、“996”等潜台词，再看看蒸蒸日上的业务，合同上不菲的现金和RSU，照旧叹一口气，进会议室继续抢项目撕B。

那你的意思是，码工也能回村自给自足，搞“一人码”？

也是，也不是。

全栈工程师不新鲜，算得上自给自足。至于要不要回村，您请自便，如果是农业创业，老板、市场、销售、PM、DevOps、运营、物流啥的您都一人扛了，咱也佩服；如若仅仅实现一人码，那大可不必，怎么也得考虑对接需求方要顺畅吧。

呃……废话太多，来点干货。

好吧，这篇围绕“一人码”的博文，其实来自于处理我“一人码”的一次线上故障。

故障现象：

• 早上送娃出门前，发新版代码上线。
• 开车路上，收到服务报警短信。
• 娃上楼后，车内开热点连服务器看日志，花5分钟找到问题。

直接原因：

• 新需求设计，需要使用用户二级权限。
• 需求实现时，发现老的二级权限设计缺乏灵活性。于是新建用户二级权限表，完成需求。
• 代码上线后，重启API服务，线上前端功能验证无误后，移除旧的二级权限表。
• 异步框架未同步重启，导致给用户的微信模板消息无法推送（原因是join不到旧的二级权限表），10分钟内服务监控报警

解决方案：

• 异步框架重启，30秒内积压消息尽数推送，无一失败，线上业务恢复。

深层原因：

• 测试不足。
• 进一步讲，一人码因为repo里不会出现不愿意碰的代码，因此看到之前实现不佳的地方，就会主动重构。在重构涉及面广的时候，加上自测不足，有可能造成线上故障。

内心感受：

• 幸亏从第一次线上故障就花时间做了简单的服务监控报警，真的是太及时了！

如此这般 “一人码” 是何种体验呢？

见图，所有实线模块（虚线部分是合作团队开发）都是在下一人建设。没有黑科技，也没有新技术，自己写的code自己要能长期维护，可靠，可扩展。

• 需求设计是不是匹配需求逻辑？没人评审；
• 架构是不是合理，够不不够性能，有没有过度设计？没人参考；
• 编码是不是符合规范？没人监督。
• 自己两年前金光闪闪的产出，现在看着那一坨嵌套判断就坑爹，要不要重构？没人逼你。

爽！整个一个“我不要你觉得，我要我觉得。”

一人吃饱全家不饿，再没有开不完的会和甩不完的锅，听起来是不是不错？

一切靠自己，若设计合理，自然自己省心；不合理也好办，自己运维，自己背锅，喜欢后半夜处理线上故障，也没人拦着你。

时间长了，发现反而对自己要求变高了 —— 格子间上班，不愿做饭就点外卖，活儿干砸了上司先扛 —— 现在自己屁股自己擦。而且时间变慢了，不用盯着排期交出自己都懒得做“冒烟”的渣代码，为了API响应时间调查一个慢查询可以调试一下午。

当然，以上还只是需求实现的coding层面，别忘记你还需要基础设施。

什么基础设施，sudo apt install mysql-community-server？还好吧？

非也……

• 先选个机架式服务器，Xeon Silver/Gold，双电，SSD/SAS盘，RAID啥的配好。
• 再来个虚拟化环境，什么openstack、esxi、proxmox的自己选择；客户要求高的，服务器再来仨，带上超融合玩一圈。
• 客户机房实施环境提前规划好，占几个VLAN，NAT怎么做，维护咋弄，把网络接入计划报给客户评审。
• 虚拟机搭起来，镜像之类准备好，vm定期snapshot什么的琢磨清楚，别上线没跑仨月，自己挖坑把自己埋了。
• 然后可以准备一般意义上的基础设施了，vm需要的Linux发行版选择，DB的主备和proxy，各种库版本和环境变量……

What？要吃个大盘鸡，我还得从孵鸡蛋、播小麦和种土豆开始？

干不干您随意哈，但还是那句话，没人评审你的设计，也没人替你背锅。所以从Day One就得考虑架构设计（包括vm host选哪款CPU），越是没人看着越是小心谨慎，古人那句话怎么说来着？

“君子慎独”

窃以为不敢自视君子，也不算道德高尚，唯有一点“just wanna make the life easier”。对客户负责就是对自己负责，多测一个场景，多catch一个exception，将来就少接一个电话，生活就轻松一点，不是么？

只从自己的角度出发，忘记客户的多样性，少年，你想简单了

别忘记离开了大厂，你就不再是螺丝钉，客户也都不再是PM提供的user profile那个样子，变成了真实的“甲方爸爸”。

因此你的设计不是简单到自己能handle就好，更不是能满足当前需求就好，因为没人给你拆好可实现的需求，真实需求往往就是甲方爸爸的微信截图几句话……

• 自己分析客户意图（以及冰山之下的部分）。
• 自己琢磨交互、UI、动效。
• 遇到不可实现的情况，自己联络客户或销售，workout出可实现的产品。
• 预估实现后可能遇到的反馈，以及同类型客户可能提出的延伸需求，在设计上留有扩展余地。

以上就是“一人码”的普遍生活图景，多数时候每天都不重复，很少有时间去深入把一个东西搞到极致（举例，集群中的高可用块存储）；你自己评估实现成本+运维风险，与客户需求及系统扩展性之间的均衡，提出合理的实现方案，跟甲方爸爸做好沟通。

所以这就是“小森林”码工版？

嗯，差不多了。

还有最后一点，你有时间读书、也有时间看新技术，跟着文档搞Hello World。不管经史子集，创业理论，还是新技术新框架的自学自练；原来在大厂听个分享就来的知识点，现在全靠你自己了。

不搞也可以，手头那点吃饭本事，再忽悠5年或许也玩得转。但搞了新玩意之后，哪怕上手的时候并不为某个具体需求，也没有明确目的，而一旦遇到适用场景，采用新技术解决又快又稳还不造轮子的时候，那种成就感着实不是一笔季度奖就能cover的。

一人生活，也要规划好每一天，食必知味，过的有仪式感。

一人coding，同样做好架构，拆分模块，准备两份以上的异地冗余，降低代码重复度，适时重构，排除slow query，跨服务调用尽量异步，应对故障准备好服务报警和降级措施，高风险场景提前演练；没事练练左右互搏（自己开发的两个系统间调用也遵循不信任原则），让多个子系统对接起来，就像个团队作品。

一句话，人，要过的有点念想，别轻易放过自己，也别轻易苛责他人（因为他们也同你一样，不愿轻易放过自己）。

文章的脚注信息由WordPress的wp-posturl插件自动生成