故事背景

在我的老家，西南边陲的某个小县城，因为物资匮乏、基础设施落后，“赶集”这项活动不知流传了多少年。以县城北部区域的四个乡镇为界，每天都有一个集，暂且就叫A、B、C、D集吧。没有官方通知，也没有统一组织方，到了日子大家就会不约而同的前往集市，采购生活用品、炫点小吃、添置衣物、卖点家里的劳动剩余。
赶集的规律是“空三赶四”，ABCDABCD如此循环往复，就A集来说就是A _ _ _ A _ _ _ A。
在早些年间农忙时节，家里人不知白天黑夜地在田间地头劳作，根本记不住今夕是何年，为了确定今天是什么集，经常需要跑出家门问问其他邻居，亦或是看看路上有没有前往集市的“马的”。日子一天一天过，集市的规律就如二十四节气般从来没有混乱过。
2020年新冠肆虐，为减少人员流动，很多自然村封村封路，更别提集市了。就这样集市暂停了一段时间，待情况好转，集市恢复了往常的热闹，还是固定的时间、固定过的地点，大家又聚集在了一起。周期循环规律并没有因为集市暂停而被打断，这让我好生惊讶。

抽象一下

观察规律

其实上面已经给出规律了，就是ABCDABCD循环，每隔三天重复一个集。
假设第1天是A集，那么第5天、第9天都是A集，按常见程序数组从0开始的惯例，那就是
第0天是A集，第4天、第8天都是A集。 

如果我们已知2017-02-05是A集，要计算今天是什么集，其实就是计算今天距离2017-02-05相差多少天，然后对4取余，根据余数可得：

• 余数为0就是A集
• 余数为1就是B集
• 余数为2就是C集
• 余数为3就是D集

代码实现

Java版

import java.text.DateFormat;

import java.text.ParseException;

import java.text.SimpleDateFormat;

import java.util.Calendar;

import java.util.Date;



public class Test {



    public static void main(String[] args) throws ParseException {



        String[] names = new String[]{"A集", "B集", "C集", "D集"};



        DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");

        Date standard = dateFormat.parse("2007-02-05");

        Calendar c1 = Calendar.getInstance();

        c1.setTime(standard);



        Calendar now = Calendar.getInstance();

        int diff = now.get(Calendar.DAY_OF_YEAR) - now.get(Calendar.DAY_OF_YEAR);

        System.out.println(names[diff % 4]);

    }



}

Go版

package main



import (

	"fmt"

	"time"

)



const (

	STANDARD = "2017-02-05"

)



var names = []string{"A集", "B集", "C集", "D集"}



func main() {

	today := time.Now()

	standard, _ := time.Parse("2006-01-02", STANDARD)

	fmt.Println(names[int(today.Sub(standard).Hours()/24)%4])

}

快捷指令

最后

借助一个简单的数学求余就能解决生活中的问题，即使现在常年在外，但每当回想起家乡、回想起家乡的集市，我还是会掏出手机看下今天是什么集，大概这就是乡愁吧！

人比山高

大家好，我是寒草，一只工作两年的程序猿。农历七月初五，阳历八月七日是我的生日，小时候总是期盼生日的到来，而且总有一种我过生日的那天我就是山大王的错觉，毕竟可以吃香的，喝辣的。但是我也早就度过了无忧无虑的年纪，而生日这一天的意义也早就有所不同。

长大后，每当生日临近，总是思绪万千，或是思考过去，或是展望未来，年少时的悠哉不再，而思绪确是一年比一年多，有一位著名工程师曾经说过：

思绪和发量是负相关的。

虽然上面这个定律在我身上还没有印证，但是我不妨借生日这个难得的机会整理一下，收拾行囊，以便整装待发。

脚比路长

写文的当下，我正在思考，去年写文章的时候是什么样的心理：

• 持续亢奋？
• 充满希望？
• 活力四射？

反正在我印象里，去年的我心中是充满希望和活力的，但是现在的我肯定和去年大不相同，可能是因为这一年出现了很多的变化：

• 停不下来的裁员潮
• 一座座楼（公司）塌了

听了很多悲伤的事，也经历了很多令人消沉的事，使得我并不会如去年那般纯粹的充满活力，也以更加理性和辩证的去看待问题，世界也不再非黑即白，这大概就是“成长”吧，在此推荐：《少有人走的路》

在夜晚一个人走在回家的小路，我会思考很多很多事，但多数像泡沫一样飞散了，但是有一件事是我不会放弃的，也算是我长久以来的梦。

见下文

白山旭日

前一段时间，我开了一个新坑：程序猿之梦！星辰大海的前端建站之路「第一周」，没错，现在的我有一个理想，想创造一个自己的产品，我对她寄托了很多很多情感：

• 我希望她可以承载更多的美好
• 我希望她可以创造一股清流在网络社会流淌
• 我希望她可以为社会提供向上的价值
• ...

但是这个事情已经停摆了一个月了，毕竟我上个月大概上了 250 个小时的班，工作饱和度也基本来到了 150% ，整个人特别特别疲惫，掘金技术圈的群也是会经常 cue 到我的加班。

不要说我卷，我是很期望刘慈欣摸鱼写《三体》的那种生活的，但是生活所迫。

即使工作比较辛苦让我疲惫至极，我也会想把我的产品搞下去，我总是做不切实际的梦，我总是有一堆幻想，我总希望我从事的事业可以让世界更加美好，我总是焦虑，我总是烦躁，我总是有一种奇奇怪怪的理想主义，还有那么一丝丝的浪漫情怀。

所以，无论如何，我欣赏我，我会是我。

黑水金光

前几天农历生日的时候，同事们陪我过了一个生日：

我作为一个东北人，也是第一次吃到铁锅炖大鹅（我怕不是个假东北人），还是很开心的，我从小到大还是第一次这么“正式”的过生日，近几天也陆陆续续的收到一些礼物：

• 一把工学椅：这样我在家就可以更舒适的创作了
• 一个木制密码箱：最关键还需要我自己拼（其实我没有什么特别值得放在密码箱里的东西）
• 特利迦奥特曼：这肯定是很了解我的人才会送的礼物～
• ...

羁绊越来越多了呢🌟还是要充满阳光的好好生活呀～

旅程

如果大家有耐心读到这里，一定有这样的一个疑问：“你这前四个标题是什么意思？”，其实只是我摘取了我母校校歌中的几句词，同时我也想到很多关于母校的指引我前进的故事：

• 黄大年教授：振兴中华，乃我辈之责

已故，纪念文：「振兴中华，乃我辈之责」于75周年校庆使用 canvas 纪念黄大年老师

• 张希校长：群居不倚,独立不惧
• ...

最后，祝我自己 25 岁生日快乐 🎂

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

江山如此多娇，引无数英雄竞折腰。
惜秦皇汉武，略输文采；唐宗宋祖，稍逊风骚。
一代天骄，成吉思汗，只识弯弓射大雕。
俱往矣，数风流人物，还看今朝。

— 《沁园春.雪》

✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨✨

各位，感谢阅读，一起加油！也欢迎各位加我微信：hancao97 和我交流。

-寒草写于2022.08.06 🔥 To Be Continued-

今天来跟大家讨论一下技术主管需要什么样段位的技术？

首先我要说明的一点，技术主管前提一定是技术出身。对于那些完全不懂技术，但是又身兼技术主管或者总监的同学，我这里就不再赘述，毕竟这个已经超出我目前理解力的范围。比如阿里云的王坚博士，基本上不懂技术细节，但是依然是阿里云的CTO，一手缔造了阿里云。

那我们这里再详细讨论一下，作为一名技术主管，到底应该有什么样的一个技术的段位？或者换句话来说，你的主管的技术水平需要到达什么样的一个水位？

先说结论，作为一名技术主管，一定是整个团队的技术架构师。像其他的一些大家所讨论的条件我觉得都是次要的，比如说写代码的多少，对于技术深度的钻研多少，带的团队人数多少等等，最核心的是技术主管一定要把控整个团队整个业务技术发展的骨架。

为什么说掌控团队技术架构是最重要的？因为对于一个团队来说无非就两点，第一点就是业务价值，第二点就是技术价值。

对于业务价值来说，有各种各样的同学都可以去负责业务上面的一些导向和推进，比如说产品经理，比如说运营同学。技术主管可以在一定程度上去帮助业务成功，甚至是助力业务成功，但是一定要明白技术同学一定要有自己的主轴，就是你对于整个技术的把握。因为业务上的决策说到底技术主管是只能去影响而非去决策，否则就是你们整体业务同学太过拉胯，无法形成战术合力的目的。

对于一线开发同学来说，你只要完成一个接一个的技术项目即可。但是对于技术主管来说，你就要把握整体的技术发展脉络。要清晰的明白什么样的技术架构是和当前的业务匹配的，同时又具备未来业务发展的可扩展性。

那为什么不能把整个技术架构的设计交给某一个核心的骨干研发同学呢？

所以这里就要明白，对于名技术主管来说，未必一定要深刻的钻研技术本身，一定要把技术在业务上的价值发挥到最大。所以在一定程度上来说，可以让适当的同学参与或者主导整个技术架构的设计，但是作为主管必须要了解到所谓的技术投入的产出比是什么。但是如果不对技术架构有一个彻底的理解，如何能决定ROI？

也就是在技术方案的选型里面一定要有一个平衡，能够用最小的技术投入获取到最大的技术利益，而非深究于技术本身的实习方式。如果一名技术主管不了解技术的框架或者某一些主干流程，那么就根本谈不上怎么样去评估这投入的技术产出比。一旦一名技术主管无法衡量整个技术团队的投入产出比，那就意味着整个团队的管理都是在抓虾和浑水摸鱼的状态，这时候就看你团队同学是否自觉了。

出现了这种情况下的团队，可能换一头猪在主管的位置上，业务依然运行良好。如果在业务发展好的时候，可能一直能够顺利推动，你只要坐享其成就可以了，但是一旦到了要突破困难的时期，或者在业务走下行的时候，这个时候你技术上面的优势就一点就没有了。而且在这种情况下，如果你跳槽到其他公司，作为一名技术主管，对方的公司对你的要求也是非常高的，所以这个时候你如果都说不出来你的技术价值对于业务上面的贡献是什么那想当然，你可能大概率就凉凉了。

那问题又回到了什么样的水平才能到达架构师这个话题，可以出来另一篇文章来描述，但是整体上来说，架构的本质首先一定要明白，为的就是业务的增长。

其次，架构的设计其实就是建造一个软件体系的结构，使得具备清晰度，可维护性和可扩展性。另外要想做好架构，基本的基础知识也必不可少，比如说数据库选型、分布式缓存、分库分表、幂等、分布式锁、消息架构、异步架构等等。所以本身来说做好架构师本身难度就非常大，需要长期的积累，实现厚积而薄发。如何成为一名优秀的架构师可以看我的公众号的其他文章，这里就不再详细的介绍了。

第二点是技术主管需要对于技术细节有敏感度。很多人在问一名主管到底应该具备什么样的综合能力，能不能用一种更加形象的方式来概括，我认为就有一句话就可以概括了。技术主管应该是向战略轰炸机在平常的时候一直遨游在大气的最上层能够掌控整个全局，当到了必须要战斗的时候，可以快速的补充下去，定点打击。

我参加过一次TL培训课程，讲师是阿里云智能交付技术部总经理张瑞，他说他最喜欢的一句管理概括，就是“心有猛虎，细嗅蔷薇”，也就是技术主管在平常的时候会关注于更大的宏观战略或策略，也就是注重思考全局，但是在关键的时候一定要关注和落地实际的细节。

换句更加通俗的话来说，就是管理要像战略轰炸机，平常的时候飞在万丈高空巡视，当发生了战斗的时候，立即能够实现定点轰炸。

所以如果说架构上面的设计就是对于整个团队业务和技术骨架的把握，那么对于细节的敏感度就是对于解决问题的落地能力。

那怎么样能够保证你自己有一个技术细节的敏感度？

我认为必要的代码量是需要的，也就是说对于一个主管来说，不必要写太多低代码，但一定要保证一定的代码量，让自己能够最好的，最快的，最贴近实际的理解实际的业务项目。自己写一些代码，其实好处非常多，一方面能够去巩固和加深自己对技术的理解，另外一方面也能够通过代码去更加理解业务。

当然贴近技术的方式有很多种，不一定要全部靠写代码来完成，比如说做code review的方式来完成，做技术方案的评审来完成，这都是可以的。对我来说，我就会强迫自己在每一个迭代会写上一个需求，需求会涉及到各方各面的业务点。有前端的，有后端的，也有数据库设计的。

自己亲自参与写代码或者code review，会让自己更加贴近同学，能够感知到同学的痛点，而不至于只是在空谈说教。

总结

所以对于一个技术主管来说，我认为首要的就是具备架构设计的能力，其次就是要有代码细节的敏感度，对全局和对细节都要有很强大的把控能力。

当然再总结一下，这一套理论只是适用于基础的管理者，而非高层的CTO等，毕竟不同的层级要求的能力和影响力都是不一样的。

引言

2023年，前端开发作为IT行业中备受关注的领域之一，正在经历着巨大的挑战和变革。然而，在当前行业不景气、失业率居高不下以及裁员潮席卷而来的情况下，许多人开始质疑前端开发的未来前景以及学习它是否依然有意义。本文将探讨这个问题并试图给出一些启示。

第一部分：前端的价值

前端开发作为网页和移动应用程序开发的重要组成部分，扮演着连接用户与产品的桥梁。前端技术的发展不仅推动了用户体验的提升，也对整个互联网行业产生了深远的影响。随着移动互联网的普及和技术的进步，前端在用户与产品之间的交互变得越来越重要。

对于企业而言，拥有优秀的前端开发团队意味着能够提供更好的用户体验、增强品牌形象、吸引更多用户和扩大市场份额。因此，前端开发的技能依然是企业争相追求的核心能力之一。

第二部分：行业不景气的背后

然而，正如每个行业都经历高低起伏一样，前端开发也面临着行业不景气带来的挑战。2023年，全球经济增长乏力、市场竞争激烈以及萧条的就业市场等因素，使得许多公司紧缩预算、停止招聘，并导致了失业率的上升和裁员的潮水。

在这种情况下，前端开发者需要重新审视自己的技能和市场需求。他们需要具备综合能力，包括对最新前端技术的深入了解、与其他团队成员的良好沟通合作能力以及持续学习和适应变化的能力。

第三部分：自我调整与进阶

面对市场变化和就业压力，前端开发者需要主动调整自己的发展路径。以下是一些建议：

1. 多元化技能：学习并精通多种前端框架和库，如React、Vue.js和Angular等。同时，了解后端开发和数据库知识，拥有全栈开发的能力，将会让你在就业市场上更具竞争力。
2. 学习与实践并重：不仅仅是学习新知识，还要将所学应用于实际项目中。积累项目经验，并在GitHub等平台分享你的作品，以展示自己的能力和潜力。同时，参加行业内的比赛、活动和社区，与他人交流并学习他们的经验。
3. 持续学习：前端技术发展日新月异，不断学习是必需的。关注行业的最新趋势和技术，参加培训、研讨会或在线课程，保持对新知识的敏感度和学习能力。

第四部分：面对就业市场的挑战

在面对行业不景气和裁员的情况下，重新进入就业市场变得更加具有挑战性。以下是一些建议：

1. 提升个人竞争力：通过获得认证、实习或自主开发项目等方式，提升自己在简历中的竞争力。扩展自己的专业网络，与其他开发者和雇主建立联系。
2. 寻找新兴领域：探索新兴的技术领域，如大数据、人工智能和物联网等，这些领域对前端开发者的需求逐渐增加，可能为你提供新的机会。
3. 转型或深耕细分领域：如果市场需求不断减少，可以考虑转型到与前端相关的领域，如UI设计、交互设计或用户体验设计等。或者在前端领域深耕细分领域，在特定行业或特定技术方向上寻找就业机会。

结论

 虽然当前的行业环境确实严峻，但前端开发作为连接用户与产品的重要纽带，在未来依然有着广阔的发展空间。关键在于前端开发者要不断自我调整与进阶，持续学习并适应市场需求。通过多元化技能、学习实践、提升个人竞争力以及面对市场挑战，前端开发者依然可以在这个变革时代中谋得一席之地。

前言

1、人情世故

如果做得好就会说是情商高，做不好会说是世故，这是冯仑老师一段话，然后怎么做不世故呢，也很难评判。

借着这个聊聊人情世故，在我看来它也是做事规则的一部分，我们发展很长一段历史，从不同的立场、不同的利益分出了派别，又从血缘关系分出了宗族，这些都是为了利益最大化的一个产物。

反观博主本人，典型理工男，执着技术研究，所以这块一直是弱项，不太会讲话，但是我人缘一直比较好的。当然有利也有弊，弊端的话比较明显的，当一个人说话很厉害的时候，会给人自信，给人觉得靠谱，当一个人说话不咋样的时候，其实也有好处，就是藏锋，你不说出来个人想法大家是不知道你心里的小九九的，所以保全了你自身。（当一个人份量足的时候，说话会引发很大的影响，所以你可以发现如果一个人在公开场合大发演讲，要么是初出茅庐要么就是有靠山）

2、人生的发展需要平台

王立群老师：人生发展往往需要平台，秦国李斯这么一个故事，他发现仓鼠跟厕鼠待遇很不一样，同样是一个物种，但是一个光明正大的吃着粮食，一个过街老鼠人人喊打，所以他悟到了一个道理，人生好的发展需要借助平台的。

我们今天讲的人物：曹操，我们还是从几个学习角度去看，一个是做事的方法，另一个我们从他的事迹里面看出成事的借力的这么一回事。

曹操

出身

他祖父是一个大太监，伺候皇后还有皇上，古代有三股力量，两股都是因为比较亲近产生的，一个是外戚，另一个太监，还有一股力量是文官，这个是人数最多的。那么他祖父权利很大的，然后收了一个义子也就是曹操的父亲，然后他本身属于夏侯家族，所以他带的资源是曹家还有夏侯家非常有实力。

他并没有说直接躺平，而是想着有所作为，接下来我们再看看他的做事方面

做事手段

1、许劭风评

古代有个一个规则，靠着这些有能力、有品德的人来进行推荐人才，曹操想出来做事，他找到许劭，一开始是不肯的，因为前面讲过三股力量，文官是很鄙视太监的，后面曹操使了点手段最终让许劭给他做了风评，然后他听完大笑而去。

idea：从这件事看做什么事都是有个窍门，这个方式是别人建议曹操这么干，所以做事要恰到好处。另外里面提到曹操使了点手段，哈哈透出了一个狠，有点东西。

2、傍大腿

曹操曾经在袁绍下面干活，然后好几次都把自己的精锐干没了，袁绍作为盟主，慷慨的给予兵马才得以恢复元气。

idea：我们看曹操的出身，这么牛逼的背景，他也需要大腿的支持，更何况普普通通的我们。

3、挟天子以令诸侯

这个是非常著名的历史典故，也是因为这个跟袁绍闹掰了，当汉献帝去了洛阳的时候，他马上去迎接，然后用这个发号施令讨伐别人。

idea：曹操的眼光十分毒辣，他看出潜在的价值，不愧是曹老板。

4、善用人才

像官渡之战，像迎接汉献帝，都是底下这批谋士给的主意，曹操手下文官是人才济济的，另外这个老板是善于听从这些好的计谋，这是非常重要的。

官渡之战，袁绍没有听从谋士的重兵把守粮草，导致给了曹操抓住了机会，乌巢一把火烧光了粮草。

个人看法

a、平台是重要的，借力也是需要的

从曹操的发迹来看，他站在一个大平台上面，不像刘备四处投奔。人并不是说能力很强就能表现出来，需要有平台，有这么伯乐去发现你，然后有这么一股力量在你困难的时候拉你一把，这是重要的。

b、曹操做事狠

这里的狠，不是残暴，而是毒辣，眼光毒辣、做事方式到位，我们从善用人才，许劭风评，挟天子以令诸侯，这些做的都很到位。举个例子，比如说我们要煮开一壶水，需要火柴、木头、可能需要鼓风工具，这都是关键那些点。

这个我们前面也提到了，做事一定要有所研究，事情的关键点是什么，当然有这么一群得力助手也很重要，发现关键突破点。所以古代对英雄标准是：腹有良策，有大气概。

c、驾驭人

司马家起来是在曹操去世后几代的事情，可以说在曹操在的时候，这些有心机的人没有动作的，侧面看出曹操的厉害之处，懂人心。在资治通鉴里面也有一个例子，就是桓温，他也是古代一个权臣，后面几代就不行了压不住这批人。

学历史，学读懂人心

历史里面基本都是那个朝代的精英，他们的事迹，做事方法，当然我们看到很多东西，包括抱负、无奈、遗憾；我们学的不仅仅是做事方法，避开权谋的陷阱，还有就是学习读懂人心、人性。当我们谈到这个，大家第一印象就是坏的人性，其实它是一种自然的表现，就像饿了就要吃饭。

《百家讲坛》里面讲了这么一个故事，曹操的下邳之战生擒了吕布，原本曹操很爱惜人才的，后面刘备的一句话：吕布对以往老板不好，而曹操生性多疑，最终嘎了吕布。王立群老师：人们往往看重结果，以结果说话，而不是问你这么做的原因。

是啊，我们在故事背后，看到整件事情人心的博弈，刘备被人称为仁义之君，但是他在那会落进下石了，因为他之前跟吕布有些矛盾的，吕布把他从原来的根据地赶走了，当然他说的也是事实。所以我们除了学习历史，还需要去洞察人心，往往这些能决定事情的走向。

我从4月开始离职开始全职做独立开发，算是真正踏进入了这条河流。在过去半年多了我也观察了很多独立开发者。自己目前算是过了新手村（有正常的开发节奏，有3万用户）。看到很多刚起步的独立开发者还是有很多疑问，所以分享一下我在独立开发最初期的一些经验。因为我也不是很成功（没有走的很远），所以只能分享独立开发前100天的经验。

先说一下我认为独立开发起步阶段面临的主要困难：

第一：没有公司的孤独感。如果是一个人全职开发就更寂寞了。即使有一两个合作伙伴，但是大概率也是异地，因此也算是网友性质的社交。人说到底是群居的，所以需要找到一种社交平衡。我想可能这也是很多独立开发白天要在外面地方待着的原因，也许一个人一直在家待着有点闷。

第二：无法建立产品的健康开发节奏。以前在公司的时候自己是流程里的一环，只关心自己分工的完成情况。做了独立开发以后，所有事情都需要自己决策。太多自由的结果就是没了方向。什么都想做，好像什么都可以做，又感觉什么都不好做。

第三：没有收入。产品从开始建造到有足够健康收入中间有一段过程。这还有一个前提要是一个真正有用户价值的产品。如果你起步的时候自己没有一个优势产品方向，又没有个人社区号召力，就算你的产品是好的，也需要一段时间（可长可短）才能获得有效收入。一上线就火的概率太小了。高强度投入一件事情，如果长期没有收入，家人会有很多质疑，可能最后自己也很怀疑自己。

我把这三点结合起来，编一个故事大家可能比较有画面了：

一个人做独立开发已经半年多了，产品设计都是自己做，也没有什么人可以讨论，不知道下一步该做什么。目前每天只有零星的新增。做了这么久，总共只有两三千的收入。看来做产品还得会营销**，打算最近开始学习一下运营**。最近也打算做一下AI产品，感觉这个赛道很火。老婆说如果不行就早点回去上班好了，总不能一直这样。家人们，你们说我应该坚持吗。

家人们会说你的产品很棒，会说你做的比他们强，会说下次一定，会说你未来会成功。但是家人们不会为你掏一分钱。

也许我们不知道如何成功，但是我们可以知道什么是失败。你知道的失败方式越多，你成功的概率就越大。总的来说，产品的成功就两个要点：有用户价值，能赚钱。注意，这两点是或的关系，不是且的关系。一个产品可以能赚钱，但是没有用。一个产品也可以有用，但是不赚钱。失败就是你做的产品：既没用，又不赚钱。

基于前面提到的三个困难，我得出的前100天最重要的事是：找到一个可行的产品迭代方向。和团队经过磨合，互相能有有效、信任的协作。找到一百个种子用户。你越早解决这三个困难，你越快走上轨道。

确认产品方向

如果你真的做过产品，你就知道最终正确的产品路径不是通过脑中的某刻灵光乍现得到的。所以不是那种大脑飞速运算解题的方式。这里有两件事情需要确认：大的产品方向，产品的路径。

比如阿里巴巴，马云不是一开始就做的淘宝网。他只是觉得互联网普及以后，电子商务会有需求。最开始做的是黄页，并不是淘宝网。但是他没有在第一个项目失败以后，去做门户网站。产品路径的例子是特斯拉。特斯拉很早就确定了先出高性能的跑车，高性能轿车（model s），有了前面的技术积累以后，最后通过推出平价的轿车赢得市场（model 3）。特斯拉在 model 3 大规模量产前都是亏损的。

所以最重要的是确认产品方向。这个方向要结合自身的情况进行设定，就是我在前面帖子里提到的要是你想做的，能做的。也许想达到的产品方向有很多工作量，这个时候就要有同步的产品路径。比如小米手机的创业，他们一开始就想造手机。但是直接启动手机的制造市场、技术都有很大的困难。于是他们先通过做 MIUI 入局。

这里面首先要有个大的方向判断，对于独立开发来说，我觉得张宁在《创作者》里提到的两个维度的方向挺有意思：大众、小众；高频、低频。这里面两两结合各有什么特点我这里就不展开了，大家可以自行体会。

但是可以明确的是，独立开发者做不了又大众又高频的应用。大众又高频，就不可能小而美。大众又高频，最后赢家除了产品能力，要有运营优势，要有资源优势。独立开发者通常没有运营优势和资源优势。另外一点，如果是小众低频，就一定要高忠诚，高付费转化。可以往大众低频或者小众高频的方向多想想。

产品方向选择还有一个建议就是要有秘密。成功的业务后面一定有秘密。秘密也回答了一个问题：如果这个需求真的存在，为什么用户选择了你的产品。

最初级的秘密就是信息差，你知道别人不知道，所以你可以，更早做，可以更低的成本，更高效，有更高的获客率。

更高级的秘密就是大家都能看到，但是大家知道了，但是大家不信（脑中想到了拼多多的砍一刀）。

最高级的秘密就是所有人都知道，但是他们做不到。

总结起来，你应该找到一个你有优势的细分方向。信息优势，洞察优势也是优势。

没有一发即中的银弹，最平凡的方式想很多方向，用最低成本进行最快速的验证。在反馈中渐渐明晰产品路径。如果你三个月不管反馈闷头做，只做出了一个产品方向。你失败的概率是很大的。所以我看到很多产品1.0 的时候就做会员，做社区，做跨平台我是很不理解的。其实这些功能在早期性价比很低。

我的方式是脑海中有10个想法，挑出3个想法做初步设计，选出一个或者两个想法做产品验证。可能是原型，数据是模拟的，没有设计，如果产品真的解决了痛点的话，用户会愿意用，然后他会给你反馈他想要更好的体验，他愿意付钱得到这些改进。这里的效率优势是，你能在更短的时间验证产品方向是不是对的。总比走了3个月才发现是一条死胡同要好。

开发者很容易因为想到一个想法很兴奋，觉得这个很有用，就闷头做了一个月。有可能的问题是，这个想法虽然是个痛点，但是这个痛点频次很低，场景很少，所以虽然有用，但是没人会愿意买单。所以尽量跳出自己的思维，从用户的角度来进行验证是很必要的。

团队协作

独立开发的开发方式和传统公司不同。需要建立一个全新的工作流程。在初期大家都是空白，所以需要通过产品迭代中，形成高效的开发默契。大家松散做东西，工作习惯，工作职责都需要有共识才行。

比如我合作的设计师早期喜欢一次做一大板块的整体设计，大概一周的工作量。初期我觉得我们对产品有激情，大家都应该有自由的发挥空间。但是做了一周的设计图和产品脑海中的产品行进方向不一致怎么办。在工作时间上，我合作的设计师因为目前还是兼职，他只能在下班后设计。然而我全职只在6点前工作。这又是一个要协调的地方。

如果你是一个产品，需要协调研发和设计，三个人协调就又更复杂了。要找到一个大家都舒服，高效的协作方式。

100个种子用户

独立开发最核心的一环就是找到一个健康的商业模式。产品方向和团队协作的目标都是为了未来可以达成一个健康的商业模式。我觉得太多独立开发者上来就把目标（野心）定的太高。一口吃不成胖子。独立开发早期的商业目标只有一个：尽快达成团队最低维持标准。一鸟在手胜过二鸟在林。不要在团队只有几个人的时候用几十个人的方式管理。

初期就要估算出产品（团队）能够持续运转的最低收入。这个成本越低，团队就越容易跑起来。当收入足够覆盖团队的成本后，你的心态就会得到极大的自由，可以尝试很多奇奇怪怪有趣的想法。所以早期不要想有多高的天花板，如何建立壁垒，就关心如何达成产品的及格生命线。谁会想做一个注定失败的产品呢。

早期在没有运营优势的情况下，最重要的指标就是用户满意度了。用户满意度，就暗示了这个产品有没有解决切实的用户问题，用户愿不愿意为你宣传。其实很多人都搞错了重点，在产品没有让100个种子用户满意前，新增的流量是没有意义的。因为再多的用户都会流失。竹篮打水一场空。如果你把产品的用户目标定在100个种子用户，你也就没了运营压力，可以关注在如何打造正确的产品上。在产品基本盘没有问题后，再思考后面的才有意义。

总结

总结起来三点就是：做什么（产品方向），怎么做（团队协作），为谁做（验证用户）。以上就是我全职独立开发3个多月以来肤浅的经验分享，希望对你有帮助。

你是否曾经有过类似的疑惑？

• 我尝试过好几次健身，但都坚持不下来，我是不是一个没有耐心，没有毅力的人？
• 领导反馈说我需要提升沟通能力(开发效率、主动性)，可是我要怎么提升呢？
• 我知道该怎么做，但就是做不到呀。

在我们的个人成长中，出现这些疑惑是很正常的，它们可以归纳为以下两个原因：

• 不知道方法
• 知道方法但不知道该怎样坚持

如果你经常被这两个问题困扰，长此以往，就会陷入自我怀疑的状态。这时，MORS 法则可以帮到你。

MORS 法则，又叫做具体性原则。MORS 法则认为，我们的行为只有符合Measured（可测评）、Observable（可观察）、Reliable（可信赖）、Specific（明确化） 这 4 个要素，才是一个具体的、可执行的行为。

针对上面说到的问题，我们不要光喊口号，而需要给出具体的、可执行的方案，然后行动起来！

也就是说，当你碰到一个很复杂的目标时，要尽量拆解目标，制定一系列符合 MORS 法则的行动计划，然后开始行动，这样就能达成目标。

让我用一个栗子来解释 MORS 法则，假想一下，你今年给自己立了一个 flag：“今年要跑半马(21公里)”。要是只有这样一个目标，你能做到吗？大概率是不能的，即使你知道要每天坚持跑步，也很难坚持下来。你有可能会被临时的一些事情耽搁了几天就放弃了；你有可能在坚持了一段时间之后发现自己“根本做不到”就放弃了。

想要达成这个大目标，你可以尝试先拆解目标。假设第一次开始跑步，你可以跑 1 公里，希望 10 个月后能跑 21 公里，那就是每个月要多跑 2 公里；然后再拆到每周要多跑 0.5 公里；然后再拆解到每 2 天多跑 0.07 公里左右。这样分拆之后，就可以罗列出每天的跑步行动计划，比如：xx月xx日，跑 1.14 公里；xx月xx+1日，跑 1.21 公里... 这些行动是符合 MORS 法则的：

• Measured：这些行动是可以被测量和评估的，你可以明确知道今天计划跑多少公里，最终有没有完成这个行动也可以很清楚地衡量和评估。
• Observable：这些行动是可见的，你要跑起来，可能需要一些跑步装备和资源（比如准备水），这些都是实实在在的行动，不是 YY。
• Reliable：这些行动是可以完成的，它不会太难，每天多跑 0.07 公里远远比多跑 20 公里要简单太多了，肯定能做到吧？
• Specific：这些行动是非常明确的，就是跑步，不会有什么歧义。

当然，肯定有更好的、更加符合运动理论的跑步计划，比如是不是每天跑，还是一周休息 2 天、是应该每天突破，还是隔一天突破等等。这里只是举例，就简单一点了。不过不管是什么跑步计划，原理是不变的。

当你制定了符合 MORS 法则的行动计划之后，就能够更加容易地达成目标，也更加容易坚持下来了。因为：

• 行动计划是具体的，明确的，可行的。相比原来的假大空的目标，它更容易做到！而且，按照这个行动计划来行动，就能达成目标。
• 能够不断地感受到成果，这会帮助你更容易坚持下来。在这个栗子中，就是每天都多跑了一些，感受到自己每天都在进步，这是强大的正反馈，会给予你力量。

注意不要跟 SMART 原则搞混了哈。SMART 原则是制定目标时使用的，MORS 法则是制定行动计划的时候使用的。它们有一些相同的点，比如 Measured 和 Specific，那是因为每一个行动本身也是带有目的性的，所以 MORS 法则和 SMART 原则会有重叠的地方。

好了，MORS 法则的介绍就到这里了，它的内容非常简单，但是 MORS 法则对于我们的个人成长来说，作用是非常大的，希望你们可以多加实践啦。

除了在个人成长上面有帮助之外，MORS 法则对于管理者指导下属也非常有用，后面有机会我再介绍吧。

加油，让我们从行动开始！

1. passive event listeners

passive event listeners 是一种新兴的web标准，Chrome 51中提供的新功能为滚动性能提供了巨大的潜在提升。Chrome Release Notes.

背景：所有的现代浏览器都有一个滚动功能的线程，可以保证即使在运行耗时的js代码时滚动也能够平滑进行，但这种优化部分因需要等待任何touchstart 和 touchmove处理程序的结果而失败，因为这些交互可能会通过调用preventDefault() 事件来完全阻止滚动。

于是有了 {passive: true}

通过将touch或wheel事件监听标记为 passive，开发人员承诺处理程序不会调用 preventDefault来禁用滚动。这使浏览器可以立即响应滚动，而无需等待js的执行，从而确保为用户提供可靠流畅的滚动体验。

2. 关于系统设计

   • 关于分层

分层一般是基于模块功能来分层，有时候分层不清晰可能是有哪些模块，各模块间的功能，整个功能流程不是很清楚。

有时候两个模块间的交互复杂度增加，可以考虑构建一个中间层。 这样可以保持两个模块不会杂糅相关度不是很高的处理逻辑，功能逻辑更纯粹，保持边界清晰，降低模块本身的复杂度。

3. 关于编程思维

仔细想来，虽然从事开发工作很久了，但是编程上还是很没有章法，架构设计能力较弱，多年来都是凭借以前热血和几分小聪明存活。

今日份反思：

拿到一个需求，分析该需求需要支持那些场景，为了支持这些场景它需要具备哪些功能，思考怎样实现这些功能，根据功能做模块划分，对这些模块进行分析，做逻辑抽象（也就是分层），然后整个需求实现的大致框架就心中有数了，开始产出技术方案。 技术方案产出后，按照技术方案的设想去实施，实施过程中可能会遇到没考虑到的场景，或者发现之前的设计不能很好的cover，调整设计，增加分层或者调整已有的分层，然后修改技术方案。 不断的经历上述过程，会慢慢的沉淀出一些业务通用的设计思路，这样下次再做技术方案的时候就不会很迷茫。脑子理清楚，而后出设计，实践后总结。

4. ShadowRealm API

一个进入 statge3 的新的 JavaScript 提案,用于创建一个独立的JavaScript运行环境，里面有独立的变量作用域。

数据结构：

declare class ShadowRealm {

  constructor();

  // 同步执行字符串，类似eval()

  evaluate(sourceText: string): PrimitiveValueOrCallable;

  // 返回一个Promise对象，异步执行代码字符串

  importValue(specifier: string, bindingName: string): Promise<PrimitiveValueOrCallable>;

}

使用场景：

• 在Web IDE 或 Web绘图应用程序中运行插件等第三方代码； 这种方式比iframe的实现更简单、灵活度更高，占用内存更少、代码的安全性更高。
• 用 ShadowRealms 中创建编程环境，运行用户代码，如codepen，codesandbox；
• 服务器可以在 ShadowRealms 运行第三方代码，防止第三方代码出错打挂主环境；
• 网页抓取和网页应用测试可以在ShadowRealms中运行；

补充：Node.js的vm模块与ShadowRealm API类似，但具有更多功能，缓存Javascript 引擎，拦截import() 等等。

5. 关于状态管理

做状态管理的核心就是监听数据的变化，监听数据的变化有两种方式：

• 提供api来修改，内部做联动处理（React的setState）
• 对对象做一层代理，set的时候做联动处理，同时get时收集所有依赖。（vue，mobx的响应式数据）

6. 需求/调研

关于需求调研，我还是很急躁，急急忙忙开始技术方案评审、开发、排期的话，就会导致整个开发过程很被动。

比较好的方式，前期对于自己做的需求，以及需求的各个功能依赖有比较充分的了解（不过这在很多功能依赖方都没有文档的情况下很难做到），然后写一个符合需求的简版的demo，对可能出现的阻塞点和解决方案心里有一个预期，把图纸画好，照着图纸开发，从而更好的掌控整个开发进度。

7. 功能/需求拆解

对功能需求的有效拆解，功能模块详细具体，粒度合适，不会太过细化，也不会忽略一些关键点，才能够更好的把控整个开发进度，评估可能出现的风险点。

8. 工具方法收敛思路

收敛-内部集中分发给各个具体的util处理，保证对外暴露的接口的统一，降低该方法使用的心智负担。

9. 关于「自顶向下」和「自底向上」

自顶向下：

程序设计时，先考虑整体，后考虑细节。先考虑全局目标，后考虑局部目标。不要一开始就过多追求总多的细节，先从最上层总目标开始设计，逐步使问题具体化。

模块化设计：一个复杂的问题，肯定是有若干稍简单的问题构成。模块化是把程序要解决的总目标拆解为子目标，再进一步细化分解为具体的小目标，把每一个小目标称为一个模块。

自底向上：

自底向上的设计简单来说就是先完成细节功能，每个细节功能抽象成一个运算符，然后将这些完成的细节功能组装到整体的架构中。

自动化的设计是不是就应该采用自底向上的设计思路，把每个需要的细节功能做抽象，使得配置规则的人可以任意组装，对于不支持的功能制造新的抽象？

10. eval 和 new Function的区别

eval 和 new Function都可以解析执行一段传入的字符串。但有以下不同的地方：

• eval中的代码是当前作用域，它可以访问当前函数中的局部变量和全局变量。new Function中的代码执行的作用域是全局作用域，不论它在哪个地方被调用，可访问的都是全局变量；
• eval接收函数作为字符串时需要“（”和“）”作为前缀和后缀，new Function不需要，new Function可以接收N个参数，最后一个参数作为函数体；
• eval不容易调试，用chromeDev等调试工具无法打断点调试；
• 性能问题，eval通常比其他替代方法更慢，因为他必须调用js解释器，而其他结构则可被现代js引擎优化；
• eval存在安全问题，因为可访问局部作用域的变量，其内部逻辑不可预测性很强，可能导致XSS攻击；

11. 乐观更新与保守更新

• 乐观更新（Optimistic Update）： 乐观更新：如果有编辑等改动，先更新前端页面，再像服务端发送请求，如果请求成功则结束操作，无需额外处理，若请求失败，则页面回滚到先前状态； 这样更新方式的优点是响应及时，缺点就是低概率的请求失败回滚的体验不太好。
• 保守更新（Perssimistic Update）： 保守更新：如果有编辑等改动，向服务端发送请求，等收到回复请求后再响应用户操作，在此之前用户都需要处于等待状态。 这样做的缺点是会使页面有比较大的延时感，优点是最终呈现的结果是可信赖、稳定可靠的。

12. 正交的概念

编程上的正交，从数学上引进这个词，用于表示相互独立，相互间不可替代，并且可以组合起来实现其他功能。比如if和for语言是正交的，但for和while与句的功能是有重叠的。逻辑运算not、and也是正交的，其他复杂的逻辑运算都可以用这三种基本运算叠加起来。 编程语言经常定义一组正交语法特性，相互间不可替代，组合起来可以实现其他功能。为了更方便使用，在基础特性之上，再添加一些额外特性。这些非基本的额外特性，成为语法糖。语法糖对语言的功能没有太大影响，只是有了，代码写起来更方便些。

13. 引入外部字体，因等待字体文件的加载而产生文字不可见问题的一些解决方案

• 临时显示系统字体：添加font-display: swap;到自定义字体的style中，在自定义字体加载好之前显示系统字体；
• 预加载网页字体：用<link rel="preload" as="font" >更早的获取字体文件。

14. 总结写技术文章的几个步骤，引导自己学习并践行：

• 学习优秀的人写的东西，看看他们的理解；
• 带着自己的疑问，和目前接收到的理解去读源码；
• 读完之后，按照自己最终的理解绘制相关逻辑的流程图；
• 针对关键功能模块做拆解和源码解读；
• 总结相关功能的实现机制，以及给我带来的启发和思考；

15. 关于团队中被高频讨论的去底座；

去底座不是完全失去对底座（数据）的访问能力，而是设计一个标准化的API来支持按需访问底座（数据）的能力。

各位，两个月没写文章了，这两个月发生了很多事，也让我产生了很多不一样的感悟。从上次发完《阅阿里大裁员有感》，我的手机里就推了越来越多的“裁员”、“经济下行”、“焦虑”等信息。我这边现在这家公司，虽然不裁员，但是执行了“SABC”绩效分布考核，什么内容大家应该也都清楚，最后给我打了个 B-。呵呵，扣工资 20%，变成所谓的绩效工资，下次考核看情况发放。

很多兄弟看到这可能会替我打抱不平，狗资本家，快去发起劳动仲裁。可是他们马上又下上另一剂猛药，那就是不停的 PUA 你，告诉你现在有家庭，要多努力，要一心扑在工作上，放心，下次一定给你打回来。

我承认，他们这些话术我都看过，基本相当于明牌。可依然我还是被影响到了，情绪十分低落，也没心思去劳动局跟他们 PK。对未来的预期瞬间变得很悲观，人要是一悲观了，真的干什么也提不起兴趣。我一门心思都扑在以后能干什么上，其它的啥也不想管，疯狂的在国内外门户上刷信息，希望能找到一条“赚钱之路”。我研究了 Web3、AI 绘画、搞自媒体、网赚攻略（什么视频搬运、抄书、小说转漫画等等），基本上信息流推给我的，我都研究了一遍。这些玩意越研究越让人焦虑，因为那些标题都起的特别的有煽动性，动不动就日入几万，而我发的那些，浏览量都破不了百。于是我就想研究更多的路子去赚钱，老实说，东南亚那边的情况，我也了解过一些。

后面我对家人的态度也越来越坏，经常不耐烦，看着我小孩我经常叹气，我想这他妈可能就是中年危机提前爆发了，总之那段时间人会越来越焦虑。

后来还是我一兄弟，邀请我一家人去平潭自驾游，我们其实也没玩几天，属于特种兵式旅游，两天两晚（晚上熬夜开车去）。回来之后心情就好多了，也没那么焦虑了。其实本来也没什么，君子不立于危墙之下，这里不行那就走。找不到就先干自己的项目（我有开源项目）。我其实对干这行还是蛮有兴趣的，应该持续坚持的干下去，半途而废干别的是下策。

回想下我那时候焦虑的经历，我以前根本看都不看那种赚钱文章的，因为我知道这些大部分是在卖课，可为什么那时候我着了魔一样呢？其实很大部分与网络有关系，你着急干什么，你就愿意看点什么，你看点什么，网络就给你推什么。这种消极循环人一旦深陷其中，光凭自己是很难走出来的。其实这种时候应该主动去接收一些积极乐观的情绪，有助于自己调整心态，网络给不了你，只有身边人能给你。

更深一步的想，所谓内卷是不是也是通过网络在传播着，深刻的影响到每一个人。所谓的“智能推荐算法”，真的智能吗？大家想看的一定就是适合每个人的吗？你不停的点击去看的信息，真的能帮助到你吗？网络是我们的工具，还是我们是网络的工具？

我想我们真的应该停下来，想想我们到底在多大程度上需要抖音、需要 BiliBili、需要知乎，也许它们真的没这么重要。

人生在世，我们到底应该追逐什么？或者说，追逐什么其实不重要，重要的是我们去追逐的过程。在这个过程中，没有内卷，没有与别人的竞争，只有对自我的审视和成长。

换句话说，我有多久没有好好了解自己了，那些独属于自己的东西，永远不会背叛的资源。我们常说的：能力、人脉、技术、视野。其实除此之外还有很多很多，我刷视频看到的有趣视频点的赞，我 Chrome 里收藏的网页，我百度网盘里躺着的分享资料等等等等，还有最重要的一项，就是我的身体和组成我身体的每一个部分：大脑、心脏、肺...... 有多久没有关注和了解它们了？在这个内卷的时代，每个人都在比拼都在竞争，都怕落于人后，都想快点挣更多的钱，这些，时常让我们忽视了对我们最重要的东西。

有趣的是，每个平台都在疯狂的更新自己的算法，期望能更精准的描述一个人，给人打上各种各样的标签。但在这场竞赛中，没有平台能竞争的过你自己，在这个世界上，只有自己更了解自己。所以我真的感觉它们在做无用功，浪费资源，最好的平台，不是给打各种标签，而是引导每个人发现自己的标签是什么。

这里我想分享给各位几个我思考的点，以供探讨。

原则一：相比与到处去找信息差，更重要的是建立自己的“资源池”

我那时候不停的刷信息，不停的找信息，本质上，我是在幻想着找到一个信息差，从而获利。这也是网上铺天盖地的文章所推崇的，所谓在风口上猪都能飞。但它们总是在掩盖一个逻辑错误，那就是找到信息差和获利之间的因果关系。实际上，找到信息差只是获利的条件之一，你有多大的能力利用这个信息差，这个信息差的时效性，方方面面的因素都会互相交织和影响。

更进一步的想，信息差就像风一样，它存在于冷热空气的交换之时，它存在于各行各业、每时每刻。让我们去追逐风，这现实吗？

我们更应该静下来，好好数数自己手头的东西，整理自己的大脑。找到自己“资源池”有哪些资源，哪些可以为我们所用，哪些可以继续扩充。思路可以打开一点，任何在当前时刻属于你的东西，都是你“资源池”的一部分。

原则二：出卖自己时间和体力的不做

这个不做，不是指不去做，而是指不长期的做。一般入门一个行业或者技术，肯定要付出时间和体力的。但你要说十年如一日的付出相同的东西，那所谓“35 岁”危机就只能找到你了。这点其实各行各业都一样，只是互联网行业处在发声的前沿罢了。

包括所谓网赚、搬运都是一个道理，毫无技术含量的事做几年就好。要时常审视自己现在在干什么，手头有哪些资源，未来的目标是什么。这跟程序运行是一个道理，运行了一段时间，停下来让自己 GC 一下。不然很容易 StackOverflow。

原则三：自己抓住的资源，千万不要轻易放手

如果不经常审视自己的“资源池”，给所有资源估估价值，就很容易被人带坑里。

原先我就做过一个项目，这是个跨部门项目，我那个领导一直告诉我说这个项目没前途、没卵用，绩效也给我打的不好，问我还要不要继续做。我说那就算了吧，做的我都不想做了。

我一放弃，马上就有新人接手，连交接也不用做，代码直接拿走，吃相可见一斑。

也就是从这里我才理解到，我其实没有了解自己，没了解过我手里的项目，被人潜移默化的影响了。影响一个人的思想真的不难，不停的重复就好了。所以还是那句话，多把自己手里的“资源池”拿出来晒一晒，整理一下。

其实 996 也是一样，拿出了你最重要的资源---身体，到底换来了什么，值得好好评估一下。

原则四：做自己喜欢的赛道，更要积累自己的资源

这几个月的经历给我的最大感觉是，这世界上真的有太多太多的行业，也有很多人赚到了钱（至少网络上宣传他们赚了钱）。网络能让这些信息病毒式的传播，导致很多人错觉的以为自己照着做也能挣到钱。但他们忽视的是，网络能把世界各地的人汇聚起来，让信息流通。其实也提供了一个更大的平台，在这个平台里，只有更卷的人才能挣到钱。

有时候真的应该抛开网络。比如，你会写代码，这是你“资源池”里的一项技能，你把这个技能公开到网络售卖。只有两种情况，要么你非常的卷，打拼出一番事业；要么你根本竞争不过别人，这是普遍情况，这世界那么大，比你优秀的人有太多太多了。

但是抛开网络，回到你身边的小小社交圈子，你的技能可能就没那么普遍了。可能你会说，那我做程序员，我身边朋友认识的大部分也是做程序员啊。那么可以这么想，假如你会做菜，你身边的程序员朋友都会做菜吗？假如你会画画，你身边的程序员朋友都会画画吗？人和人总有差异点，你觉得找不到优势，那是因为你尚未建立自己的“资源库”。

先认识自己，再让身边的人认识自己，当他们会给你打标签时，他们就成了你“资源库”中的一员，这就是人脉。这才是是独属于你自己的标签，而不是抖音、B 站为你打的冷冰冷的标签。

总结

以上我感悟的四个原则，我称之为“资源池思维”，一个比较程序员化的名词。

这篇文章发完后，我后续可能就继续更新一下具体的技术文章了，继续深耕技术。

最后，推荐看到最后的各位看一部冷门电影：《神迹》，讲述的是医生维维安托马斯的故事。看完可以来一起交流交流感悟。

辞职

我辞职了

拿上水杯，挎起背包，工位被我丢在了身后，一阵清风过后，我便离开了这度过一年半载的地方

辞职的原因很简单，公司快没钱了，要么同公司共进退，要么离开，于是我选择了离开

公司的待遇不算好也不算差，工资不算满意，但至少双休不加班。平时开发阶段末尾还比较闲，大把摸鱼时间，逛逛各种论坛，掘金、知乎、github不亦乐乎，现在看来公司倒闭和我不无关系

久而久之，不免有些无聊。论坛里充斥着灌水文章，看多了属实是食之无味。于是为了打发时间，只能写一写自己的项目。一想到老板在为我打工，敲打键盘的双手便愈发轻盈了

未曾设想的道路

大半年前为了记录学习一项技能到底要花多少时间，我开了个新坑，做一款计时软件，记录某个时间段发生的事情

和以往一样，最初只是打算随便写写，写个基础功能完事。但在使用的过程中，越来越多的需求在脑海中构建。编程最有趣的便是创造感，你能感受到自己在创建一个新的世界，在创造的过程中时间飞速流逝，一转眼便度过了无聊的一天

激情是短暂的，生活是漫长的。和往常一样，功能在逐步完成，但我的兴趣在逐渐减少。没有添加柴薪，火便只能渐渐势弱

此时两个选择摆在面前，一个便是不再更新下去，毕竟要做的已经完成了，再去寻找下一个打发时间的事情就好了。另一个则是保持兴趣继续做下去

兴趣？利益？

做一个开源软件，如果能收获社区的掌声想必是件自豪的事情。但如果只有掌声，久而久之开源作者可能会陷入自己到底为了什么才做这件事的思维泥潭。有的人失去了兴趣便离开了，有的人发出了声音希望得到一些回馈

兴趣可以支撑人前行，但又有多少人能不求回报去做一件事？不可否认，曾经幻想过做出爆红的软件，然后不用打工，财富自由这样的白日梦。虽然不能一步登天，但我想借助它向前一步

审视一下目前的状况，如果要供用户使用，一个简单的计时功能加上记录，未免太过单薄。这么简单的功能实在谈不上什么竞争力，实现成本过低，而且我相信人们更愿意使用移动app，而不是在pc上去使用这个功能。我需要一个特定于pc且有实在价值的功能，很快我便找到了，它既满足前面的要求，又契合软件的主题

广告恐怕是最理想的获利方式，不会影响用户使用，也不用去考虑升级版之类的的东西。虽然不知道具体能有多少收入，但希望起码能够抵消掉域名的费用

有了继续前进的目标，这艘小船便能扬帆远航

但眼下的问题很严重，我在技术选型上摔了个大跟头

重头再来

好的开始是成功的一半，但没有人能预料到未来会发生什么

使用vue3为前端，我直接选择了webview方向的跨端框架

在以go为后端的wails和rust为后端tauri中，我选择了go。之前学习过一段时间的rust，深知学习的难度。而且在最初的预想中，我只是打算做个简单的计时软件，使用go也只是做一下数据库操作。不久后就完成了最初的一版，但在后续的尝试中，发现wails的生态还是太小了，很多基础的功能都需要自己实现。这时再看看tauri就显得很香了，各种插件和前端的绑定，再加上go并没有用得多么称手，于是只能长痛不如短痛了

ui框架的选择上我也犯了同样的问题。开始是偏向于material design这种风格，选择了vuetify，这个框架当时我看了很久，做的时候已经要到v3正式版本了。本来以为没问题，但后续使用时过于难受，此时文档基本没怎么更新，issue也被各种bug塞满了。只能快刀斩乱麻，换了习惯的ant-design-vue，风格区别很大，但改改样式也能用。quasar同样在我的考虑范围内，但更加小众，目前是不打算换了，在tauri v2移动端正式版后，再做尝试

为什么最开始没有选择做移动端？功能契合，使用起来也更方便。一方面是我的主要技能栈是js，另一方面重新学移动端过于不切实际，为一个八字没一撇的项目去学实在没有必要。flutter我之前也学过，试着写了一点，但还是不如js来得舒服

回过头来，发现走了很多弯路，但不去尝试只站在远处观望，永远也不会有结果。颠颠撞撞重头再来

编程之外

我一直把时间花在了代码之上，但想要做一款产品还远远不够，它迫使我不得不将视角转向那些我不曾关注的角落

UI可谓是产品的脸面，用户的第一印象便停留在了logo和界面上，虽然使用了风格统一的组件库，但将他们组合在一起的时候未必能将它们严丝合缝。目前只能说是勉强能看，日后再做修改

说明文档带领用户快速理解程序的运作，由于用户没有设计者的前提条件，很多理所当然也就需要一一记录

想要完善功能，bug和feature的反馈也要做指引，方便接收用户意见，确定前进路线

说明文档

参考vite的官网，使用vitepress，写markdown就可以了，还可以配上vue组件，还算方便

部署上选择了netlify，可以换自己的域名，还可以自动更新ssl证书

本来以为部署很麻烦的，结果一个小时左右就全部搞定，包括在namesilo上买域名，然后在netlify部署、配置

拥抱AI

在完成这些工作的过程中，有不少地方借助了AI，可以说很大程度加快了进程

编码上，由于我完全不懂windows编程和勉强会点rust语法，想要完成监听系统上的应用状态这项功能，根本就无从谈起。要花大量时间去学习的话，反而和我利用碎片时间进行编程相冲突了。况且在new bing的帮助下，我完成一个简单的函数就要花费数个小时的尝试。new bing根据我的需求返回了相关的api参考，但很多时候返回的代码并不能直接运行，有着这样那样的问题，需要去修正。很难想象仅凭我一人去翻找资料何时才能完成这冰山一角

在这个过程中，new bing最大的帮助就是提供了关键词。很多时候，你知道一个事物，想用自己的语言需要一长串词语去描述，但过去的搜索引擎并不能理解这些，而且就算把描述输入进去，也会因为过多的关键字导致答案被淹没在茫茫的网页之中。这就造成了一个困境，我不知道它叫什么，所以我要去搜索，但搜索的时候要知道它叫什么

在netlify配置域名，我输入了如何去配置，new bing给出了关键的name servers，省去了花时间去到处去找教程

为应用绘制一个logo，很显然我并没有这个能力，使用Bing Image Creator，一段描述就能生成

这些都是一些无关紧要，琐碎的事情，我只想获取结果，把精力留在我擅长的事情上。试想一下，我一个人去实现要花掉多少时间？最终能实现吗？部分功能交给其他人，又要用什么去换取？

计划

讲到这里如果有兴趣了解一下的话，可以移步仓库地址，但目前的功能我只能说很少，而且还可能出现问题，我提前声明一下。说明文档见此处，需要看清警告提示

为什么这个时候来写这篇文章来介绍呢，主要是辞职了也没事干，已经做了大半年就整理了一下。原本是半年后再辞职的，但计划赶不上变化，只能提前放出来看看情况

还有一项没能赶上的便是广告，使用的是google adsense，但提交申请后便石沉大海。尽管提前做了申请，但已经过去了几个星期。可能是开始建站时随意申请被驳回的缘故，久久没有反应

最后

辞职其实还有一个原因，就是累了，光是待在公司什么都不干，也能感觉到劳累。工作小憩之余，在过道眺望远方时，我一直想问自己究竟在干些什么。我想做出改变，想去尝试新的东西，体验另外一种生活

想过很多次，以后也许不会从事编程的工作，但又有什么选择呢。我希望是创作，而不是枯燥的重复劳作，但我很清楚这不是换一个职业就能改变的问题，终究是实力的问题。编程很有趣，但在公司并不是如此

现在我已经度过了一周的悠闲时光了，白天在家看看书，傍晚下楼走走，看着面向我驶过的匆忙下班的人流，感叹这也是自己前不久的模样。我背朝着喧闹，走上凉爽的林荫道，晚风吹过，天边挂着一轮淡淡的月牙

一眨眼工作已经三年了，前两年的总结 工作第一年、工作第二年 基本上把在公司做的事情都介绍了，今年站在「前端已死」、互联网大裁员的环境下，想想未来的路可能更为应景。

经常说这是最好的时代，也是最坏的时代，互联网便是如此。通过互联网将人与人之间的各种链接都成为了可能，在互联网诞生之前，人与人之间的交流就是现实生活中的圈子，而现在本来这一辈子都不会在现实中产生交集的人在互联网却会相遇。

各种写书的大佬、开源的大佬，以往可能只是从文字、代码中了解他们，但现在通过社交媒体、微信竟然就产生了互动。当然不好一面就是也会遇到和自己不相投的人，也许会影响自己的心情。

通过互联网极大的扩宽了我们的视野，看到了别人在怎么生活，也放大了自己的焦虑和欲望。我们需要认清自己的边界，知道自己想要什么，自己能做什么，不需要对本来不可能发生在自己身上的事情而焦虑。

当迷茫焦虑时，看看宇宙的纪录片，从宇宙的视角去看自己，无论从空间大小还是时间维度，其实自己什么都不是，想那么多干啥。

再想想其他动物，吃饭睡觉喵喵叫，也挺好的。

前端已死

互联网已经结束了快速扩张的时期，这是个客观事实，因此招聘的人数相对于之前减少了很多，但远没到一个已死的状态，相对于其他行业，选择互联网依旧是一个不错的选择。

前端会不会死不知道，互联网肯定会一直存在下去，现在整个社会都是基于互联网，已经变成了像电、水一样的基础设施，没有人可以离开它。因此互联网的相关的岗位一定会一直一直存在。

至于互联网中具体的职业划分，前端、后端、算法、数据库等，它们各自使用的语言、技术一定会发生变化的，当选择互联网技术行业的时候，就应该抱有持续学习的态度。

塞班操作系统被安卓、iOS 取代、.Net 岗位的减少、客户端大量岗位转前端，这些也就发生在近十几二十年。当某一个岗位减少的时候，一定又会出现新的岗位，保持开放的心态去学就可以，变化再多肯定也有不变的东西。当掌握一门技术再学习另一门技术的时候，肯定会比小白学习一门新技术快很多很多，很多经验也会迁移过去。

去年 12 月出来的 chatGPT 为代表的大模型，到现在也就半年多的时间，很多以前完全不敢想的事情就这样发生了。可以预见的是一部分岗位数量肯定也会减少，目前影响最大的应该是 UI 岗，其次一定程度上可以提高程序员的开发以及学习效率，但还没有到取代的程度，但未来会再怎么发展就不得而知了。

相对于其他行业，虽然互联网相关技术迭代确实很快，但如果是因为热爱而选择这个行业，我觉得去做一辈子是没问题的。

技术

底层技术服务于上层技术，上层技术服务于应用，真正赚钱的是应用，它可能提升了用户的效率、也可能提升了用户的生活体验，这样用户才愿意付费。上层技术的人收到了钱，进一步也愿意为底层技术的人付费。

但对于一个应用，技术并不是最重要的，更多需要的是产品和运营，一个应用在 chatGPT 和各种框架、云服务的加持下做出来变得太简单了，更多的是我们需要思考如何设计产品和如何推广运营产品，和用户产生更亲密的连接，用户才愿意付费。

极端一点，即使现在所有的应用都停止更新了，其实也并不会产生多大的影响。

在公司中亦是如此，对于技术开发，没有谁是不可取代的，公司更期望的是那些可以发现问题、分析问题、定义问题的人，至于怎么解决，问题定义清楚以后，解决方案自然可以出来，谁去解决并不重要了。

但也不用太过悲观，虽然技术不是最重要的，但一定是不可或缺的，在解决问题的过程中也会区分出能力强和能力差的：方案的设定、代码编写的好坏、线上的 bug 数、代码的扩展性等。

赚钱

赚钱很大程度又是需要运气的，比如同一个人十年前进入互联网和现在进入互联网差别就会很大，再比如开发一个应用突然爆火，例如「羊了个羊」，这些我们是很难控制的，我们只能「尽人事，听天命」。

最近几年，除了在公司工作，对于有技术的同学赚钱有下边的方式：

• 付费课程、出书

  最近几年越来越多的人在极客时间、掘金小册写课程或者直接出书。

  对于写课的人赚到了钱，对于买课的人只要跟着看完了，多多少少都会有很多收获。付费课程会比较系统， 如果没有这些课程，去学东西肯定也是可以学的，但需要花很多时间去网上搜一些零碎的资料，由于没有经验甚至可能走很多弯路。

• 付费社群

  市面上也会有一些付费训练的社群或者知识星球

  对于组织付费社群的人会花费很大的精力，需要持续运营并且照顾到每一个人，不然就等着挨骂吧。因此这类收益也会很高，一些人会辞去工作专职来搞。

• 开源

  大部分开源基本上是用爱发电，更多是收获一些朋友、流量、提升技术。

  比如 core-js 作者的经历，一个 22.6k star 的项目，几乎各个网站都在用的一个项目，作者却因为钱的问题被很多人谩骂。因此如果是个人专职开源一个项目靠 GitHub Sponsor 会很难很难。

  当然，开源也是能赚到钱的，比如 Vue 开源就赚到了很多钱，但毕竟是很少很少数了。

  依赖纯开源项目赚到钱，还是需要背靠公司。比如阿里云谦的 Umi、通过开源加入 NuxtLab 的 Anthony Fu、在 AFFiNE 的雪碧等等。

• 应用

  身为一个程序员，尤其是前端程序员，当然可以自己维护一个应用来赚钱。

  做得很成功的比如 Livid 的 V2ex 社区，Abner Lee 的 Typora（后来知道作者竟然是国内开发者）。

  也有一些没有那么出名的，比如大鹏的 mdnice，秋风的 木及简历。

  当然如果要做一个很大的项目，背靠公司也是一个很好的选择，比如之前阿里玉伯的语雀、之前极客邦池建强的极客时间。

  还有一些小的创业公司会做的，冯大辉的「抽奖助手」、吴鲁加的「知识星球」等。

  做出这些应用不需要很多时间，需要我们善于发现生活中的痛点以及强大的执行力，当然想成功的话需要再加一点运气，在成功前需要不断尝试不同的东西。

• 流量变现

  有流量就会赚钱，不管是接广告、还是带货。互联网上也会有部分人专注于怎么搞流量，知乎怎么获得更多曝光、视频号怎么获得更多流量、怎么批量注册号，各个平台规则可能是什么，怎么对抗规则，这类有技术加持也会更加顺利，很多人也在专职做。

赚钱的方式有很多，对于我来说，我会尽量选择复利的事情，这样才能产生更大的价值。比如一对一咨询，一份时间换一份收入。但如果把东西写成课程，只需要花一份的时间就能获得 N 份的收入。

另外就是需要保持分享，分享除了能帮助其他人，对自己也会有很大的帮助，写文章的过程中也会不断的有新的认知得到。虽然当下可能没有金钱方面的收入，但时间放宽到几十年，相信一定会有很大的回报。

人的欲望是无穷的，也不能陷入赚钱的极端，目标应该是关注此刻，体验生活，享受生活，而不是不停的赚钱。之前听播客，有一个恰当的比喻，钱就好比汽油，不停的赚钱相当于不停的加油，但如果汽车停着一直不动，再多的汽油也是无意义的。

健康

最近几年总是爆出程序员突然离世的新闻，前段时间耗子叔突然离世的消息听到之后真的很震惊。twitter 经常刷到耗子叔的动态，然后突然一天竟然就戛然而止了，毫无征兆。

意外是无法避免的，只能尽可能的从饮食、作息、锻炼三方面降低生病的风险。

饮食

我是工作第一年体检的时候检查出了中度脂肪肝、尿酸高，当时因为是刚毕业，体重是我的巅峰，140 多斤，脂肪都堆在了肚子上。那段时间就开始跑步加吃沙拉，少吃米饭、面条。降的也快，几个月就回到了 130 斤以下，甚至到 120 多点。

第二年体检的时候，脂肪肝基本没有了，尿酸也降了许多。

后来就保持少吃米饭，多吃蛋白质、蔬菜的饮食了。

作息

有一次得了带状疱疹，那种非常痛的类似于痘痘的东西，后来了解了一下是因为免疫力低导致病毒入侵的。猜测因为晚上坐在电脑前，气温降低了没注意，从而导致了生病。

病好之后就决心养成早睡早起的习惯。

之前作息基本上是 1 点到 2 点睡觉，9 点前后起床。现在基本上保持在 11 点前后睡觉，6 点到 7 点间起床了。

早起的好处就是早上会有大把的时间，而且这段时间是专属于自己的，并且因为大脑刚苏醒，效率也会很高。但如果是工作一天，晚上回家再做自己的事情，此时大脑已经很疲惫了，效率会比较低。

运动

最开始是跑步，但确实很难坚持下去，跑步需要换衣服、出门，还依赖于外边的天气，成本很高。后来陆续尝试过 keep、一些付费课程，都做了但没有完全养成习惯。

后来知道了 switch 的健身环大冒险，然后就一路坚持到了现在，前段时间已经通关了。

目前也一直在坚持，基本上一周会运动三到四次，一次大概花费 50 分钟左右。

投资

大学的时候开始接触到理财，知道了基金的概念，看了银行螺丝钉的「指数基金定投指南」，也看了「穷爸爸富爸爸」、「小狗钱钱」这类理财入门的书。当时赚到的一些钱，就跟着银行螺丝钉投了，主要是一些宽基和中概、医疗。

一直到工作的第一年，基金收入确实不错，甚至赚了百分之四五十。当时想着原来股市这么简单，这咋还能亏钱了。

接着疫情不断发展，还有外部经济的变化，中概、医疗都大跌，当时发了年终奖还不停的补仓中概，到现在亏损也有百分之三四十了。

但我心态是可以的，一切都是浮亏和浮盈，只要不卖一切都是浮云。

经历了大起大落后吸取了一些教训，那就是一定要严格执行计划，现金流多不一定要立刻全部投入，而是按计划定投，因为没人知道会跌多久，只有有充足的现金流，才能够把亏损逐步拉平。

现在国家规定互联网基金这些必须走「投顾」，也就是主理人帮我们买入、卖出，我们只需要交一定的投顾费即可。目前我都是在雪球上投，跟投的有孟岩的「长钱账户」、alex 的「全球精选」、螺丝钉的指数增强和主动优选。

能设置自动跟投的就自动跟投了，我相信专业的事交给专业的人肯定是没问题的。

投资肯定是财富自由不了的，但一定比把钱放余额宝强一些，只要耐心持有，尤其是目前这样的熊市投入，相信到下一个牛市会有不错的回报。

（以上仅个人看法，股市有风险，入市需谨慎）

保险

如果开始接触理财，除了投资，一个绕不过去的点就是保险。

对于保险是什么的比喻，之前听薛兆丰的课时候印象深刻。

我现在还年轻力壮，将来年纪大了可能会生病，为了防止以后生病要花一大笔医药费，今天就开始存钱，每个月拿出 10% 的收入存起来，未雨绸缪。这是一种做法。

另外一种做法，是我每个月也拿出 10% 的收入去买保险。

这两种做法有什么区别呢？

区别在于，如果我是用储蓄来未雨绸缪，那么未来可能就会发生两种不同的情形。

如果我将来年纪大了也没生病，我存的钱就还是我的钱，我不需要花出去，这时候我还是很幸运的，能够保有我原来的收入，这份储蓄没有被花掉，我赚了。

但是如果我运气不好，生病了，这份储蓄就会被用掉，甚至需要借很多钱去治病，生活会发生巨大的变化。

所以通过储蓄来未雨绸缪，它的特点是未来的结局是可变的，是变动的、是带有风险的。要么高、要么低，要么能够保有原来的这份储蓄，要么这份储蓄就被用掉了甚至借更多的钱。

而对于保险来说，如果你没病，那你的生活该怎么样还是怎么样。如果你病了，那会有保险公司给你支付一大笔钱，你也不用和别人借钱，病好后继续该干啥干啥。

因此存钱去防止生病就有赌的成分了，如果没病就白赚了很多钱，如果病了生活质量可能会发生很大的变化。

而保险就可以降低风险，未来即使生病了，由于看病不需要花钱了，病好后生活质量也尽可能的维持在原来轨道 。

我期望未来肯定是尽量稳定的，所以在不影响当前生活质量的条件下我愿意拿出一部分钱来买保险。原计划我可能会 30 岁以后开始买重疾险，之前女朋友的朋友有推荐保险的，然后就跟女朋友一起配置了重疾险。

选保险一定要慎重，一些看起来很划算的保险， 到理赔的时候可能会推三阻四，甚至理赔前公司破产了，尽量要选择大公司。

总

当然生活没有标准答案，每个人看到世界也都是不同的，我也一直在成长，一直在认识新的东西，上边的所想的也不能保证说未来不会再变。

未来能做的就是多看看书，不限制自己，看看经济学的、哲学的、心理学的、人文的，多出去走走看看，尽可能多的增加人生体验，去认识世界，认识自己，做自己想做的事，爱自己所爱的人，走下去就好了。

掘友的一个评论，让我又想跟大家唠会儿嗑了。

我之前写过一篇文章叫《该写好代码吗？我也迷茫了》。于是，这位掘友评论说，他在上家公司的时候，他们组代码质量要求高，前期设计考虑全面，所以上线后问题少。但是在领导眼里就像没事做一样。其他组经常出事故，反而很忙，像是一直在攻克难题。

我回复说：那可能是领导不够专业，没有深入到项目里。

回复完了，我仍然意犹未尽。于是，才有了这篇文章。

正常情况下，对于一个软件项目或者一次版本迭代，负责人应该是心中有数的。这个项目的难度如何？手里的人员能力如何？大约做多长时间？最终会达到什么效果？这些应该是负责人的基本功。我不自夸，反正我带项目时，我们几个负责人都是能做到的。

据此，你才能更好地把握一个项目的始终。有时，项目中间出现难题，要干预。有时，大家超额完成，要嘉奖。有时，很简单的功能，他开发出了很多bug，要扣奖金。甚至有时候，一个月的工期，老板硬要半个月完成，这时对结果不能要求太高，你不能又要做完又要做好，那是找打的节奏，最终会两败俱伤。

但是，存在一种叫“外行管理内行”的情况。这类领导呢，他不知道你干了啥，也不知道对你来说这活好不好干，甚至你干没干完他也分辨不出，全靠读你的周报和计划。但他却是你的分管领导。

我原本以为，在技术领域不会存在这类情况。后来发现，不但有，居然还很普遍。而且在国内，这还是一道别致的景观。

听过一个报道，说国内有一位教授，他从国外买来高端芯片，先把标志磨掉，再印上自己的Logo。然后，他对外宣传是自主研发的。出人意料的是，他还开发布会，还拿到了上亿的科研资金。随后几年，他甚至还推出了第二代、第三代、第四代，都是通过自己印标签的手段完成的。

整个过程，但凡有内行审一下图纸，看一下生产车间，都会很容易识破骗局。

当然，咱们普通人一般到不了研究芯片，那么高精尖的层次。但是，我觉得作为一个普通企业的小领导，参与到项目中，这总是可以的吧。

从实际情况来看，其实很少有领导能躬身入局。哪怕这个领导只管六、七个人，他也会再分成三四个组。遇到一项任务，领导会安排给员工，让它们去协商完成。而他，要去规划团队未来的发展。

我有种很明显的感觉，但现在还找不到一个合适的名词来描述它。只能从一些例子上去体会其中的差异。

我有一个任领导，开周会是他做总结。他说这一周，后端完成了什么，前端没有完成什么。前端还反驳他，说自己完成了。领导说，别糊弄我，你只是把接口地址敲上了，根本没调用过，你跑跑试试，数据结构对不上。他是最了解整个项目开发进度的人。

还有些领导与他形成鲜明的对比。他们了解事情靠开会听汇报，就算只有三个下属，也要他们说说这周干了啥。他做一下汇总，然后再上报给他的领导。功能交付后，项目出现了问题，他会说是下属欺骗他，居然谎报工期，没测说测了，没做说做了。

至于形成这种区别的原因，可能跟文化和制度有关。不能说哪种绝对好或者不好。

前面那种“严管型”领导所在的公司，企业文化中，负责人制，不讲理由。出了问题不要推脱是张三、李四没做好，他们担不起这个责任，就是你负责人的问题。所以，这才导致了领导会落实每一项流程。

后者那类“汇报型”的企业，从上到下都注重文书的格式、措辞，讲究高瞻远瞩，着眼未来，允许试错，探索创新。因此，他们便将更多的精力投入到了汇报上。

作为一名老程序员，我感觉，软件开发是一种很工程化的工作，一层层拆分好，安排到基层人员手里，告诉他们如何执行就可以了。但是新一代领导说，管理的最高境界是让团队具备自驱力，硅谷就是这样的。自驱力就是你不用安排，他们自己就能主动克服困难去完成。即便领导不在，团队也能照常运转，这才是健康的团队。

抱歉，有点儿跑题了。

本文的初衷是“外行管理内行”与“躬身入局”。

我觉得“外行管理内行”在国内是必然现象，尤其在技术领域。

在国内的中小企业，作为团队的领导，“行政类”的事情要比“专业类”多。你看看你的领导，他经常开会和写材料。这不是它自己要干的，也不是老板要求的，是受行业和环境的影响。你想要申报科技企业，申请政策扶持，参加高新评级，你就得去准备。

除此之外，团队的日常管理，年计划、月计划，人员流动、评优、优化等等，都会耗费日常的精力。而这些活，专业的程序员并不想干。

另外，就算一个内行被推上管理岗位，程序员工种复杂，知识更新也快，那他干上几年，也会慢慢被磨成“外行”。

因此，内行外行只是相对的，并不重要。我则更强调“躬身入局”。

躬身入局，就是参与到项目中。就算不写代码，起码也了解下大家遇到的问题。在这个过程中，作为管理者，可以制定一些规则和标准，来保证良性运作。好的流程制度，是可以实现员工自驱动的。

举一个身边的例子。现在夏天了，天气很热，办公室都会开一天的空调，温度调到23度。

这天下过大暴雨，空气清爽，气温很低。这时，23度的空调就很冷了。正对着空调口的瘦同事，就想去关掉空调。结果被一个静止都会喘粗气的大胖子给制止了。

胖子问：为啥关空调？

瘦子说：外面下雨，不热了！我冷。

胖子说：你冷你穿衣服。你关了我热。

瘦子说：你热，你打开小风扇。

说完，瘦子关了空调。 随后，胖子又打开了空调。

这类事情就是公说公有理，婆说婆有理。搞不好还需要领导出面调停，或者搞一个群体性的投票。如果没人理你，那就看谁的底线更低，或者说谁更狠。

但是，如果说团队制定这么一个小规则，就是室温超过26度可以开空调制冷，制冷底线是23度。那么，即便没有领导在场，大家也能很好处理此类事情。甚至，这类情况根本都不会发生。

这只是为了体现规则重要性的例子。到软件开发中，可能就是比如这类情形：一个接口如果多个端都调用，那么就由后端组织特定的数据格式。

如果你躬身入局，你就会经历类似的事情。否则的话，你可能会说，吵什么吵，大家要以大局为重（只是要求停止争吵，没有决定开不开空调）。

可能说这么多，有人朝我笑了：你以为我傻？我这么做，老板给我涨工资，多拿钱！

抱歉，抱歉！我只想着如何提高项目质量了。关于挣钱方面，我外行了！

唉，大家一定要重视环境的重要性。

大家好，我是老三，最近沉迷于听脱口秀，并且疯狂安利同事。

脱口秀演员常常说的一句话是：“脱口秀是冒犯的艺术”。最近我发现，同事们好像有点不一样了。

阳光灿烂的早上，趿拉着我的宝马拖鞋，跨上包浆的小黄车，屁股感受着阳光积累的炙热，往公司飞驰而去。

一步跨进电梯间，我擦汗的动作凝固住了，挂上了矜持的微笑：“老板，早上好。”

老板：“早，你还在呢？又来带薪划水了？”

我：“嗨，我这再努力，最后不也就让你给我们多换几个嫂子嘛。”

老板：“没有哈哈，我开玩笑。”

我：“我也是，哈哈哈。”

今天的电梯似乎比往常慢了很多。

我：“老板最近在忙什么？”

老板：“昨天参加了一个峰会，马xx知道吧？他就坐我前边。”

我：“卧槽，真能装。没有，哈哈。”

老板：“哈哈哈”。

电梯到了，我俩都步履匆匆地进了公司。

小组内每天早上都有一个晨会，汇报工作进度和计划。

开了一会，转着椅子，划着朋友圈的我停了下来——到我了。

我：“昨天主要……今天计划……”

Leader：“你这不能说没有一点产出，也可以说一点产出都没有。其实，我对你是有一些失望的，原本今年绩效考评给你一个……”

我：“影响你合周报了是吗？不是哈哈。”

Leader、小组同事：“哈哈哈“。

Leader：“好了，我们这次顺便来对齐一下双月OKR，你们OKR都写的太保守了，一看就是能完成的，往大里吹啊。开玩笑哈哈。”。

我：”我以前就耕一亩田，现在把整个河北平原都给犁了。不是，哈哈。”

同事：“我要带公司打上月球，把你踢下来，我来当话事人。唉，哈哈”

Leader、同事、我：“哈哈哈“。

晨会开完，开始工作，产品经理拉我和和前端对需求。

产品经理：“你们程序员懂Java语言、Python语言、Go语言，就是不懂汉语言，真不想跟你们对需求。开个玩笑，哈哈。”

我：“没啥，你吹牛皮像狼，催进度像狗，做需求像羊，就这需求文档，还没擦屁股纸字多，没啥好对的。不是哈哈。”

产品经理、前端、我：“哈哈哈”。

产品经理：“那我们就对到这了，你们接着聊技术实现。”

前端：“没啥好聊的，后端大哥看着写吧，反正你们那破接口，套的比裹脚布还厚，没事还老出BUG。没有哈哈。”

我：“还不是为了兼容你们，一点动脑子的逻辑都不写，天天切图当然不出错。不是哈哈。”

前端、我：“哈哈哈”。

经过一番拉扯之后，我终于开始写代码了。

看到一段代码，我皱起了眉头，同事写的，我顺手写下了这样一段注释：

/**

* 写这段代码的人，建议在脑袋开个口，把水倒掉。不是哈哈，开个玩笑。

**/

代码写完了，准备上线，找同事给我Review，同事看了一会，给出了评论。

又在背着我们偷偷写烂代码了，建议改行。没有哈哈。

同事、我：“哈哈哈”。

终于下班了，路过门口，HR小姐姐还在加班。

我：“小姐姐怎么还没下班？别装了，老板都走了。开玩笑哈哈。”

HR小姐姐：“这不是看看怎么优化你们嘛，任务比较重。不是，哈哈。”

HR小姐姐、我：“哈哈哈”。

我感觉到一种不一样的氛围在公司慢慢弥散开来，我不知道怎么形容，但我想到了一句话——

“既分高下，也决生死”。

写这篇的时候，想到两年前，有个叫码农小说家的作者横空出世，写了一些生动活泼、灵气十足的段子，我也跟风写了两篇，这就是“荒腔走板”系列的来源。

后来，他结婚了。

看（抄）不到的我只能自己想，想破头也写不不来像样的段子，这个系列就不了了之，今天又偶尔来了灵感，写下一篇，也顺带缅怀一下光哥带来的快乐。

阅读时长约10分钟，共计2268个字

如果要问自己这样一个问题：“我们工作的意义到底是什么？”会得到怎样的答案？

是为了安身立命？是为了满足别人的期待？是为了得到社会的认同？抑或是索性认为工作是无意义的？

如果我说：工作的意义在于自我实现，你会同意吗？你会觉得这样的观点很片面吗？你会觉得这很理想化吗？

其实，依我的工作经验来看，上面列举出的常见答案其实都有道理。人在不同的阶段，不同状态，工作的意义便会发生变化。

坦率地讲，我从开始工作之后，就下定决心不再啃老。简单地说，就是不再向父母伸手要钱。于是，如何保障自己的温饱就是我工作的最首要和最基本目的。也就是说，我刚开始的时候，工作就是为了挣钱。

刚起步的时候我一个月有多少工资呢？很少，2500块。即便是毕业后转正，拿到手也只有三四千块。

但是，这些钱已经可以很好地满足我的温饱需要。即使我出去租房，不在家吃饭，这些钱其实也是够的，只不过很可能剩不下分文。很感谢我的父母，在我事业刚刚开始的时候，照顾了我的起居生活。

一开始，我眼中工作的意义就是为了能养活我自己，就是为了那三两碎银。所以，为了养活自己而选择工作，挣钱，然后达到目的，我至今也不觉得有什么丢人的。

后来呢？因为我一直在家吃饭，午饭的话公司也有食堂，所以基本没什么开销。唯一生活上的花销就是衣服和鞋，可偏偏我穿衣穿鞋算是比较省的，一件衣服基本上少说穿个四五年，鞋的话就更久了，我现在还经常穿七八年前买回来的经典款。我认为穿衣方面，买经典款总是不会错，而且很难因为流行趋势而过时。

话说回来，随着我的小金库慢慢积累变多，我就不愁“安身立命”的目标了。因为我是家族后代中唯一的男性，所以心中总会有一种使命感，虽然没有人给我这方面的压力。我感受到的最大的责任感其实是想让家人生活得更美好的目标，虽然我父母在这方面依然没有表现出很大的期待。

于是凭着这个我自认为的“责任感”，一直努力工作了很多年。其实我的想法很简单，就是想让爱自己和自己爱的人过得好一点。我觉得凭本事挣更多的钱，然后达到这个目标，更是无可厚非的事情，也没什么错。

后来呢？我其实很早就有写博客的习惯，随着读者对我的文章产生认同，更重要的是有出版社编辑的认同，我就产生了要获得社会认同感的目标。虽说是“社会认同感”，其实它所包括的内容很广泛。比如读者的、家人的、老同学的、（前）同事的等等。这种“社会认同感”还会顺便带来他人的尊重甚至是敬重。至少我这次的工作和上次的工作，在面试的时候基本上技术方面是被认可的，免去了“八股文”的考验。不过老实讲，如果考验我面试“八股文”，大概率我还真得吃败仗。

再到现在，金钱对我的诱惑依然存在，但已经大幅降低了。更多的是考虑如何实现自己的价值，真正地释放自己的潜力，对这个社会，对这个世界发挥光和热。也就是我在一开始说的“工作的意义在于自我实现”。

好了，这就是我的故事。一开始为了满足温饱，我去工作，去挣钱；后来，为了得到别人的认可，获得社会认同感而努力工作，顺便把钱给挣了，引一句读者的评论：“挣钱是重要的事情中最不重要的”；再到现在，自我实现对我是最重要的。

所以，在不同阶段，不同状态，对工作意义产生不同的观点，我觉得都是正常的，也都是正确的。

但是，你知道吗？在我刚刚工作的时候，我就立下目标，要在这个世界上留下点什么，留下自己活过的印记，不想虚度此生。但当时无论如何也想不到，自己会成为作者，通过文字和图片把枯燥的编程知识教授给需要的人。

不知道你有没有听说过“马斯洛需求层次”，莫名其妙地，从一开始我就攀登这个需求金字塔，直到现在，已过去十余年。

有读者说我是“长期主义者”，以现在的认知，我愿意做一个“长期主义者”。但当初的我，哪懂什么“长期主义”。我更偏向于用“轴”、“固执”或是“不见棺材不落泪，不撞南墙不死心”这类的修饰词来形容自己。所幸的是，在我“固执”的一路上，受到了很多人的帮助与支持，还有上天的眷顾。“运气”、“机遇”占了很大的比重。

回到最初的问题：“我们工作的意义到底是什么”？如果我们对一个疲于奔命的人说：“你要实现自我”。很遗憾，“实现自我”在这个人眼中，也许就只是保障温饱，他甚至会转过头来和别人说我们是神经病。因为阶段不同，状态不同，追求的东西自然也会不同。也许这很无情，很冷血。但它很真实，也很正常。

但即便我们处在最开始的温饱阶段，着眼于生计，但目光一定要看到那个“未来”，坚定不移地坚持走“长期主义”的道路。

另一方面，在学校里，往往努力就会有结果，这是具有极大的确定性的。踏入社会之后，这种确定性消失了，我们往往努力了，却并没有得到想要的结果。很多人在鼓吹“选择大于努力”，选择固然重要。选错了，越努力，走得越偏。但这种话听多了，就要当心它是否成为了不努力的借口。努力是为了在机会到来的时候，我们有能力抓住他。这就好像不慎跌落坑里的人，有人扔绳子救他，他得努力抓住绳子，才有被救的可能。如果一味求救，却不选一种力所能及的方法去做，无论有多少次生还的机会，也会错过。

所以，任何时候也不要轻视努力与坚持的重要性。这看上去很笨很傻，但它却是每一个平凡人实现“自我价值”的可行之路。就像歌中唱的那样：“老天爱笨小孩”。在这个充满不确定性的时代，更应如此。不确定性就像基因突变，可能会变糟，也可能会变好。当有好事到来时，便是好运来临之际。和“选择大于努力”相比，我更倾向于相信“机会总是留给有准备的人”。这句话出自法国著名的微生物学家、化学家路易斯·巴斯德，告诫人们：机遇往往不易察觉，可遇不可求，容易稍纵即逝。作为普通人，若要抓住机遇，就要把功夫用在平时，甚至是有点傻的、偏执的努力。

背景

关于招聘，在最近一段时间有幸又参与到了面试工作。这次面试也包含一些相对高级一点的岗位，如何招到合适的人成为了最近一段时间一直在思考的一个点。

整体上感觉自己还是没有章法，没有清晰的思路（做不到因人而异），这种情况对自己对他人都是不负责任的。

因此，简单做一些总结思考，边面边想边改进吧。

招聘者的目标

首先，作为招聘者，都希望能找到一些厉害的人，成本不应该是他要考虑的问题。但现实总是相反。

面试官：这是我这次招聘的需求，要这个...... 那个...... 总之，能力越强越好。

公司：这次招聘成本范围已发给你了，注意查收。

面试官：......

所以，在成本有限的情况下，面试官要做的就是找到那些会发光的人。对面试官来说，招到一个即战力（不亏），招到一个高潜力（赚翻了）。

因此，招聘者的目标都是希望能够招到 能力 > 成本 的人。

梳理招聘需求

招聘的需求是需要面试官提前梳理好的，面试官作为团队的组建者，一定要提前规划好招聘需求。比如：

1. 我要找技术强的。（我不懂的他来）
2. 我要找态度好的。（我说啥都听）
3. 我要找有责任心的。（不用我说就把活干得很漂亮）
4. 我要找学习能力强的。（自我提升，啥需求都能接的住）
5. 最好还能带团队。（这样我就轻松了）
6. 最后一定要稳定。（这样我就一直轻松了）

哈哈，先开个玩笑。虽然我真的想......

现实就像上边提到的，招聘者希望的求职者模样。虽然知道不可能，但还是忍不住想要（我控制不住我几己呀！），所以在有限的面试时间内，问了很多方方面面的问题......

面试结束后：我问了那么多才答上来那么几个问题，不行，下一个......

面了几天后：人怎么这么难招呢？

所以真正的招聘需求应该是下边这样的：

1. 我要招一个领导者还是执行者：这个一定要想清楚，两者考察维度完全不一样。
2. 我要技术强的：想好哪方面技术强，不要妄图面面俱到。
3. 我要找有责任心的，学习能力强的，稳定的：想好怎么提问，如何判断。

如果能够做到上边的三点，相信招进来的人应该都是OK得。PS：先做到不亏。

领导者Or执行者

为什么把这个作为第一点，上边也提到过，两者考察维度完全不一样。一场面试，时间就那么点，所以要有针对性。

先说领导者

如果招聘领导者。试想一下领导者有哪些特点，什么样的人你愿意让他成为领导者。

1. 业务理解程度深，不仅限于产品规划的业务需求，还要有自己的理解和看法。
2. 技术能力强，通常一个技术方案便能提现出来，方案好不好，考虑全面不全面。
3. 抗压能力强，能够承担工作压力，这里不是指加班（当然加班也算），更多的是来自于技术，业务的困难和挑战。

以上三点并不代表全部，仅做参考。那么如何在面试中确认呢？

1. 业务理解程度主要通过追问细节的方式来确认。在你不了解的情况下，依然能够给你讲明白，这个业务是做什么的，关键核心点是什么，核心点有什么难度和挑战，最后是怎么解决的，解决的是否完美，不完美的原因。如果能够回答的不错那就基本合格了。最后可以再多问一下: 有没有哪些产品提出的需求，你认为不合理或者不适合当前产品现状的？这个问题只要回答的有一定高度，那就完美了。

   ps: 如果面试者认为没有什么难度和挑战，只能证明他自己没有深度参与或主导该业务。再简单的系统，也不可能一点问题都没有，如果真的没有，那么完全没有必要安排团队去专门负责。没有简单的系统，只有简单的思考。

   举个栗子，用户管理（用户CRUD）系统我们一听可能都觉得很简单，早期，用户注册要填一堆的东西，现在都是各种登录渠道，非常的方便。站在现在的角度，对于早期的用户管理来说，如何提升用户注册效率，增加用户量就是一个有难度有挑战的事情。

2. 技术能力，我简单分为有效技术能力和无效技术能力。无效技术能力代指无用且无聊的八股，当然也不是所有的八股都无用。有效技术能力我理解就是解决问题的能力，而解决问题不在于使用的技术手段与否高明，是否先进，只要贴合业务场景，我都会认为有技术能力。反而那些八股回答的头头是道，解决实际项目问题无一用到的会严重减分。

3. 抗压能力，项目经验是能反应出来一些信息的：有难度，有挑战的事情你不会交给一个不合适的人来做的，所以如果简历的项目经验中有类似的经验那么就证明别人已经帮你筛选过了。PS：别忘了鉴别一下。

再说执行者

还是试想一下，好的执行者有哪些特质：

1. 注重细节，考虑问题全面。
2. 责任心强，不会随便应付了事。
3. 技术OK，至少基础没有问题。

同样，上述三点仅做参考。

1. 注重细节，直接体现其实跟方案的完善程度有关，所以问问技术方案的异常情况是如何考虑的。另外，直接体现其实就是BUG比较少，当然这个一般人肯定不会说自己BUG多，所以可以问问，对于如何减少BUG量，有没有心得。（这个问题目前来看基本没啥用，哈哈）

2. 责任心强。责任心如何体现的我也说不太清楚，思考以后认为加班算一方面，有加薪、晋升算一方面，面试中很难直接体现，只能凭感觉。和第一条注重细节一样，我面试全凭聊完之后的直觉，这种大家都会有，而且一般来说准确率也不错。

   PS： 其实在面试沟通过程中，一问一答，很多事情靠直觉、面向也能猜个七七八八，玄学的东西这里不多说。说一点有科学依据的，人的性格简单分为外向、内向，两者都有其各自的特质，通常来说，内向者的特质更多时候适合于执行者。感兴趣的可以去了解一下两种性格特质，有益于团队管理。

3. 技术OK。这个不做多说了，一定要多问实际使用的，不用的就不要问了，可能用的适当问一下，实际使用的也可以拔高一下往深了问问。比如：mysql都在用，mysql的八股可以多问几个。JVM这种开发基本不用的，简单问一下得了（我一般是不问的）。

这一篇先到这里把，关于技术强、责任心其实也简单提了一下。关于这两点，后续结合实际情况再更新吧。

之前写过一篇《如何应对核心员工提离职》反响特别好，今天做个延展篇，在项目过程中，员工突然提离职，我们有什么办法让项目按时按质的上线。

项目做多了，总会碰到这种情况。这里给大家介绍一个解决项目问题的分析方法：从问题本身、环境、问题的主体三个方面去思考解决方案。

通常情况下，一个员工向上级提出离职，那意味着他已经下决心走了，你留得住人，留不住心。而且这段时间，最好别派太多活，他只想早点交接完早点离开。

我们试着从环境、问题本身、问题主体三个方面来思考解决方案。

环境

• 从问题发生的环境看，如果我们有一个好的氛围，好的企业文化。员工会不会突然突出离职？或者哪怕提出离职，会不会给我们更多一点时间，在离职期间仍然把事情做好？如果答案是肯定的，那么管理者可以尝试从问题发生的上游解决问题。
• 提前安排更多的资源来做项目，预防资源不足的情况发生。比如整体预留了20%的开发时间做缓冲，或者整体安排的工作量比规划的多20%。

问题本身

从问题本身思考，员工离职导致的问题是资源不够用。

• 新增资源，能不能快速找到替代离职员工的人？或者我们能不能使用外包方式完成需求？跟团队商量增加一些工作时间或提高工作效率？
• 减少需求，少做一些不是很重要的需求，把离职员工的需求分给其他人。

这2个解决方案其实都有一个前提，那就是离职人员的代码是遵循编码规范的，这样接手的人才看得懂。否则，需要增加的资源会比原来规划的多很多。这种问题不能靠员工自觉，而应该要有一套制度来规范编码。

问题的主体

我们不一定能解决问题，但可以解决让问题发生的人。这样问题就不存在了。比如，既然问题出现在张三面前，那就想办法搞定张三，让他愿意按计划把项目完成。如果公司里没人能搞定这个事，这里还有另一个思路，就是想想谁能解决这个问题，找那个能解决问题的人。

从环境、问题本身、问题的主体三个维度来分析，我们得到了好几个解决方案。我们接着分析哪种方案更靠谱。

解决方案分析

方案一，从环境角度分析，让问题不发生。这种成本是最小的。但如果问题已经发生，那这个方案就没用了。

方案二，在项目规划的时候，提前安排更多资源。这招好是好，但前提是你公司有那么多资源。大部分公司都是资源不足。

方案三，新增资源，这个招人不会那么快，就算招进来了，一时半会还发挥不出多大的价值。请外包的话，其实跟招人一样，一时半会还发挥不出多大的价值，成本还更高，也不适合。至于跟团队成员商量提高工作效率或者大家加个班赶上进度，这也是一个解决方案。不过前提是团队还有精力承担这些工作。

方案四，减少需求。这个成本最小，对大部分公司其实也适用。关键是需求管理要做好，对需求的优先级有共识。

方案五，解决让问题发生的人。这个如果不是有大的积怨，也是一个比较好的方案。对整个项目来说，成本也不会很大，项目时间和质量都有保证。

项目管理里有一个生命周期概念，越是在早期发生问题，成本越小。越到后期成本越大。所以，如果让我选，我会选择方案一。但如果已经发生，那只能在四和五里选一个。

实战经验

离职是一场危机管理

让问题不发生，那么解决之道就是不让员工离职。尤其是不让核心骨干员工提离职。离职就是一场危机管理。

这里的本质的是人才是资产，我们在市场上看到很多案例，很多企业的倒闭并不是因为经营问题，而是管理层的大批量流失，资本市场也不看好管理层流失的企业。了解这点，你就能理解为什么人才是资产了。所以对企业来说，核心员工离职不亚于一场危机。

下面分享一个危机管理矩阵，这样有助于我们对危机进行分类。

横轴是一件事情发生之后，危害性有多大，我们分为大、中、小。纵轴就是这件事发生的概率，也可以分为大、中、小。然后就形成了九种不同的类型。

我自己的理解是，有精力的话，上图红色区域是需要重点关注的。如果精力有限，就关注最右边那三种离职后，危害性特别大的员工（不管概率发生的大小）。要知道给企业造成大影响的往往是那些发生概率小的，因为概率大的，你肯定有预防动作，而那些你认为不会离职的员工，突然一天找到你提离职，你连什么准备都没，这种伤害是最大的。

理论上所有岗位都应该准备好”接班人“计划，但实际上很多公司没办法做到。在一些小公司是一个萝卜一个坑，这个岗位人员离职，还得现招。这不合理，但这就是现状。

公司如何管理危机？

好，回到公司身上，公司如何管理危机？

第一，稳住关键性员工，让员工利益和公司利益进行深入绑定。

那些创造利润最大的前10~20%的员工，就应该获得50%甚至更高的收益。当然除了金钱上的激励外，还要有精神上的激励，给他目标，让他有成就感等等。

第二，有意识地培养关键岗位的接班人或者助理。

比如通过激励鼓励他们带新人、轮岗等等

第三，人员的危机管理是动态变化的，要时不时地明确团队各成员的位置。

比如大公司每年都会做人才盘点。

第四，当危机真的出现后，要有应对方案。

也就是把危机控制在可承受的范围内。比如，项目管理中的planB方案，真遇到资源不够，时间不够的情况下，我们能不能放弃一些不重要的需求？亦或者能不能先用相对简单但可用的方案？

离职管理的核心是：降低离职发生的概率和降低离职造成危害的大小。

离职沟通

如果事情已经发生了，管理者应该先通过离职沟通，释放自己的善意。我会按照如下情况跟离职员工沟通

第一，先做离职沟通，了解对方为什么离职？还有没有留下来的可能，作为管理者有什么能帮他做的?

第二，确定走的话，确认下对方期望的离职时间，然后根据公司情况，协商一个双方都能接受的离职时间点。不要因为没有交接人，就不给明确时间。

第三，征求对方意见，是否需要公布离职。然后一起商量这段时间的工作安排。比如，你会坦诚告知会减少工作量，但哪些工作是需要他继续支持的。希望他能一如既往地高效完成工作。

第四，如果还没有交接人到岗，最好在一周内安排人员到岗，可以考虑内部换岗，内招、猎聘等手段尽快让人员到岗。

第五，如果已经到离职时间，但还没有交接人，作为公司管理者，你就是最好的交接人。在正式交接工作之前，要理清楚需要哪些相关的资料，做好文档分类。如果实在对离职员工的工作不了解，可以让离职人员写一封日常工作的总结。

如果做完这些，离职员工还是消极怠工。作为管理者能做得就比较有限，可以尝试以下几个方法

1、再进行一次沟通。表明现在公司的情况，希望他给予支持。

2、看看自己能给予对方哪些帮助，先把这些落实好。比如写推荐信。另外有些公司入职的时候会做背景调查，这也是你能够帮助到他的。

3、如果你有权利，可以跟离职员工商量是否可以以兼职的方式来完成后续工作。这种方式对大家都好，他可以早点离职，你也不用担心因为时间仓促招错人。

如果做完以上这些还不行，那么就考虑减少一些需求，用更简单的方案先用着，后期做迭代。至于说让团队加班加点赶进度，这个要根据项目实际情况来定。

总结：今天给大家分享了一个简单分析问题的方法。然后重点聊了一下项目成员突然要离职，项目负责人有哪些应对方案。如果你看完有收获，欢迎留言讨论。

最重要的-利用好工具 🔧

工欲善其事必先利其器，利用好的知识外脑来帮助自己，学会使用AI大模型 比如Chagpt等；http://www.dooocs.com/chatgpt/REA…

1. 早上不要开会 📅

每个人一天是 24 小时，时间是均等的，但是时间的价值却不是均等的，早上 1 小时的价值是晚上的 4 倍。为什么这么说？

因为早晨是大脑的黄金时间，经过一晚上的睡眠，大脑经过整理、记录、休息，此时的状态是最饱满的，适合专注度高的工作，比如编程、学习外语等，如果把时间浪费在开会、刷手机等低专注度的事情上，那么就会白白浪费早上的价值。

2. 不要使用番茄钟 🍅

有时候在专心编程的时候，会产生“心流”，心流是一种高度专注的状态，当我们专注的状态被打破的时候，需要 15 分钟的时候才能重新进入状态。

有很多人推荐番茄钟工作法，设定 25 分钟倒计时，强制休息 5 分钟，之后再进入下一个番茄钟。本人在使用实际使用这种方法的时候，经常遇到的问题就是刚刚进入“心流”的专注状态，但番茄钟却响了，打破了专注，再次进入这种专注状态需要花费 15 分钟的时间。

好的替换方法是使用秒表，它跟番茄钟一样，把时间可视化，但却是正向计时，不会打破我们的“心流”，当我们编程专注度下降的时候中去查看秒表，确定自己的休息时间。

3. 休息时间不要玩手机 📱

大脑处理视觉信息需要动用 90% 的机能，并且闪烁的屏幕也会让大脑兴奋，这就是为什么明明休息了，但是重新回到工作的时候却还是感觉很疲惫的原因。

那么对于休息时间内，我们应该阻断视觉信息的输入，推荐：

• 闭目养神 😪
• 听音乐 🎶
• 在办公室走动走动 🏃‍♂️
• 和同事聊会天 💑
• 扭扭脖子活动活动 💁‍♂️
• 冥想 or 正念 🧘

4. 不要在工位上吃午饭 🥣

大脑经过一早上的编程劳累运转之后，此时的专注度已经下降 40%~50%，这个时候我们需要去重启我们的专注度，一个好的方法是外出就餐，外出就餐的好处有：

• 促进血清素分泌：我们体内有一种叫做血清素的神经递质，它控制着我们的睡眠和清醒，外出就餐可以恢复我们的血清素，让我们整个人神经气爽：

  • 日光浴：外出的时候晒太阳可以促进血清素的分泌
  • 有节奏的运动：走路是一种有节奏的运动，同样可以促进血清素分泌

• 激发场所神经元活性：场所神经元是掌控场所、空间的神经细胞，它存在于海马体中，外出就餐时场所的变化可以激发场所神经元的活性，进而促进海马体活跃，提高我们的记忆力

• 激活乙酰胆碱：如果外出就餐去到新的餐馆、街道，尝试新的事物的话，可以激活我们体内的乙酰胆碱，它对于我们的“创作”和“灵感”起到非常大的作用。

5. 睡午觉 😴

现在科学已经研究表现，睡午觉是非常重要的一件事情，它可以：

• 恢复我们的身体状态：26 分钟的午睡，可以让下午的工作效率提升 34%，专注力提升 54%。
• 延长寿命：中午不睡午觉的人比中午睡午觉的人更容易扑街
• 预防疾病：降低老年痴呆、癌症、心血管疾病、肥胖症、糖尿病、抑郁症等

睡午觉好处多多，但也要适当，15 分钟到 30 分钟的睡眠最佳，超过的话反而有害。

6. 下午上班前运动一下 🚴

下午 2 点到 4 点是人清醒度最低的时候，10 分钟的运动可以让我们的身体重新清醒，提高专注度，程序员的工作岗位和场所如果有限，推荐：

• 1️⃣ 深蹲
• 2️⃣ 俯卧撑
• 3️⃣ 胯下击掌
• 4️⃣ 爬楼梯（不要下楼梯，下楼梯比较伤膝盖，可以向上爬到顶楼，再坐电梯下来）

7. 2 分钟解决和 30 秒决断 🖖

⚒️ 2 分钟解决是指遇到在 2 分钟内可以完成的事情，我们趁热打铁把它完成。这是一个解决拖延的小技巧，作为一个程序员，经常会遇到各种各样的突发问题，对于一些问题，我们没办法很好的决策要不要立即完成，2 分钟解决就是一个很好的辅助决策的办法。

💣 30 秒决断是指对于日常的事情，我们只需要用 30 秒去做决策就好了，这源于一个“快棋理论”，研究人员让一个著名棋手去观察一盘棋局，然后分别给他 30 秒和 1 小时去决定下一步，最后发现 30 秒和 1 小时做出的决定中，有 90% 都是一致的。

8. 不要加班，充足睡眠 💤

作为程序员，我们可能经常加班到 9 点，到了宿舍就 10 点半，洗漱上床就 12 点了，再玩会儿手机就可以到凌晨 2 、3 点。

压缩睡眠时间，大脑就得不到有效的休息，第二天的专注度就会降低，工作效率也会降低，这就是一个恶性循环。

想想我们在白天工作的时候，其实有很多时间都是被无效浪费的，如果我们给自己强制设定下班时间，创新、改变工作方式，高效率、高质量、高密度的完成工作，那是否就可以减少加班，让我们有更多的自由时间去学习新的知识技术，进而又提高我们的工作效率，形成一个正向循环。

9. 睡前 2 小时 🛌

1. 睡前两小时不能做的事情：

   • 🍲 吃东西：空腹的时候会促进生长激素，生长激素可以提高血糖，消除疲劳，但如果吃东西把血糖提高了，这时候生长激素就停止分泌了
   • 🥃 喝酒
   • ⛹️ 剧烈运动
   • 💦 洗澡水过高
   • 🎮 视觉娱乐（打游戏，看电影等）
   • 📺 闪亮的东西（看手机，看电脑，看电视）
   • 💡 在灯光过于明亮的地方

2. 适合做的事情

   • 📖 读书
   • 🎶 听音乐
   • 🎨 非视觉娱乐
   • 🧘‍♂️ 使身体放松的轻微运动

10. 周末不用刻意补觉 🚫

很多人以周为单位进行休息，周一到周五压缩睡眠，周末再补觉，周六日一觉睡到下午 12 点，但这与工作日的睡眠节奏相冲突，造成的后果就是星期一的早上起床感的特别的厌倦、焦躁。

其实周末并不需要补觉，人体有一个以天为单位的生物钟，打破当前的生物钟周期，就会影响到下一个生物钟周期，要调节回来也需要花费一定时间。

我们应该要以天为单位进行休息，早睡早起，保持每天的专注度。

参考

以上大部分来源于书籍 《为什么精英都是时间控》，作者桦泽紫苑；

伴随着颈椎疼痛的困扰，此时的我不敢轻易扭动脖子，宛如一只梗着脖子的傻猫。好在个人博客网站基本搭建完毕，尽管下一个任务紧迫，但它没有任何盈利点。现在，只需简单总结一下，就能稍微松口气了。

个人博客网站功能设计

炫酷展示：独特页面展示博客列表，包括标题和发布日期，可通过点击链接阅读完整内容。

分类与标签：文章分类和标签，助力读者按主题或关键词快速筛选和浏览感兴趣的内容。

神奇搜索：强大而快捷的模糊搜索功能，让读者迅速找到心仪文章，关键词轻松搜。

探秘联系：Github的联系方式隐藏在神秘角落，前往解锁更多关于开发者的信息。

响应式布局：兼容各设备，个人主页灵活展示在桌面、平板和手机，畅享极致用户体验。

数据剖析：揭示访问统计与分析报告，文章点击、来源追踪，读者行为一览无余。数据助力个人优化内容、领略读者趣味。

主题风格：提供浅色模式和暗黑模式，页面可一键换装或跟随系统。

为什么是Next.js和vercel？

首先是这样最简单，从基友的劳动成果中扒拉了整个技术架构。在此基础上，我又做了一些页面的功能的扩展，比如全文模糊搜索、继续阅读、文章目录等。【叉腰】

服务器渲染（SSR）可以给博客带来超棒的性能和超棒的SEO优化。它会让页面加载速度变得超快，还能让搜索引擎更好地抓取和索引博客内容。（但现在还不能搜到我的文章ε=(´ο｀*)))）

Vercel作为部署平台。它简单易用，超快速而且靠谱。最重要的是，它能跟Next.js完美结合，让我轻轻松松地将我的应用程序部署到全球分布式网络上。它还提供自动化的CI/CD流程，让我可以专注于撰写博客内容，而不用花费太多时间和精力在繁琐的部署和服务器配置上。

赞美基友！

UI设计的灵感来源

页面布局

首页的布局模仿nextjs框架的样本页，它本身拥有响应式布局。

首页的内容并不需要太多，所以保留了样本页的单屏设计，页面不需要滚动就能展示完整的内容。页面分为三个模块：顶部为面包屑按钮区，中间区域面积最大，突出博主猫奴本色，底部则包含了三个菜单，分别作为专栏文章和其他项目的链接入口。

对于专栏文章列表页的布局，首先需要考虑两个主要模块：专栏标题和描述，文章列表的标题和发布时间。在PC端，按2:3比例左右分栏，移动端按2:8比例上下分栏。顶部和首页类似有漂亮的手绘按钮点缀页面，还有一只正在认真工作的猫猫作为背景，增添趣味。

文章内容页的布局设计采用主流的设计，基本上在每个教程文档都能看见这样的布局方式。布局是类似的，但怎样才能做得好看点呢？如何用颜色+透明度、字号+行高的奇妙组合创造美的魔术？对于个人网站，这很大程度依赖于个人的审美喜好，以及最重要的、很容易被个人开发者忽略的一点：考虑读者的阅读体验。

关于颜色

浅色模式的颜色来源于我的=月白色的瓷碗，和瓷碗里的黄米汤圆。降低一点饱和度，调成目前主流的莫兰迪色系，给人一种温柔的感觉。我喜欢性格温和的人，希望自己也变得温柔一些。

深色模式中，很多网站都呈现出超棒的视觉效果，我个人最喜欢tailwind的配色。这种模式下的背景傻猫露出了其暗黑的一面，似乎正在谋划消灭人类，重建一个有吃不完的小鱼干和虾虾的新世界。

图标和图片

小图标采用阿里iconfont的手绘风格系列，给页面增添了一抹生动与活泼。

背景图由网图和两个手绘Icon图标巧妙拼合而成，似乎在讲述一个工作猫的故事。在图中，你可以看到一只憨憨的小猫专注地盯着电脑屏幕，右爪按住鼠标，而鼠标线的末端却连接着一个毛线团，给人一种不太聪明的印象。

问题和解决方案

1. 浅色和深色模式转换的解决方案，哪个最方便快捷？

项目使用的组件库mantine提供了MantineProvider组件，可用于更改主题。

import { MantineProvider } from '@mantine/core';



function Demo() {

  return (

    <MantineProvider theme={{ fontFamily: 'Open Sans' }} withGlobalStyles>

      <App />

    </MantineProvider>

  );

}

theme属性可用来传递其它任意风格属性。withGlobalStyles 这个属性可以增加几个样式，其中一个就是深色模式的颜色和浅色模式的颜色。

但我并没有使用这个方案，原因有三：

杀鸡用牛刀既视感，theme提供了很多选项默认值，但除了颜色，其它用不上。

主题色色彩不够多，如果想要更多颜色，需要修改它的css变量。而tailwind的颜色选择范围更多，添加透明度也很方便。

相比于在js中修改样式，我更喜欢在css中完成同样的功能。

比如，使用tailwind，仅需在某个className加上前缀 dark:，比如dark:bg-slate-900, 表示bg-slate-900在深色模式下生效。具体如何使用可以参考tailwind官网，这里不做赘述。

2. 老大难useEffect。

当需要使用useEffect监听事件时，有时候只想在组件 mounted 前执行某些操作，而不希望随着状态的变化而不停地更新。对于那个状态，我会创建一个ref值，就像是一块“不会变形的金属”。这样，我可以在useEffect中使用这个ref值作为判断依据，而不会受到状态的干扰。

然而，还有一种情况无法绕开。由Context上下文提供的value值 和 updateValue方法，updateValue需要在某个子组件的useEffect中监听事件而触发。

3. Tailwind SVG 样式未生效

tailwind支持处理SVG图标的样式，比如你可以这样写一个svg的颜色：

<svg class="fill-blue-500 ..."> <!-- ... --> </svg>



<svg class="stroke-blue-500 ..."> <!-- ... --> </svg>

可是，对于我下载的那些手绘图标，上述方法却不起作用，包括stroke属性也无效。我猜测可能与图标的path路径有关。脑海中浮现出一个解决方案：使用全局provider来传递主题色作为参数，并将其赋值给fill属性。但是，我实在太懒了，不想采用那么繁琐的方式，也不想依赖市面上已有的状态管理方案。

而fill属性接受的值是颜色，同样可以使用currentColor，它会继承最近祖先元素的颜色，类似于inherit的效果。当fill属性不存在或为空字符串时，默认会被填充为黑色。然而，这些手绘图标似乎并不理会tailwind针对svg的className属性，反而继承了更上一级的颜色。既然如此，那解决方案就是在引用这些图标的组件中指定颜色。

4. sticky不粘了。 通常，我们知道，英文文档的中文翻译总有一些令人困惑的小问题。但这一次，是mdn的中文文档略胜一筹。例如，在stick相关文档中：

This value always creates a new stacking context. Note that a sticky element "sticks" to its nearest ancestor that has a "scrolling mechanism" (created when overflow is hidden, scroll, auto, or overlay), even if that ancestor isn't the nearest actually scrolling ancestor.

注意，一个 sticky 元素会“固定”在离它最近的一个拥有“滚动机制”的祖先上（当该祖先的 overflow 是 hidden、scroll、auto 或 overlay 时），即便这个祖先不是最近的真实可滚动祖先。

中文文档明确多了这一句话：

这有效地抑制了任何“sticky”行为（详情见 Github issue on W3C CSSWG）。

如果不看这句话，中英文文档都会让人以为是要在overflow有这些值的时候才生效。然而事实却完全相反。在我去掉藏在 body 中的overflow-x:hidden后, sticky终于能按预期触发了。

5. 模糊查询算法和匹配文本标记

前文提到，贴心而又温柔的笔者为网站提供了搜索功能。搜索功能的界面和常见开发文档的Spotlight看起来基本上一样，不同的是细节的模糊查询功能。

一个具备模糊查询的Spotlight看起来像这样：

(好吧，截图的时候又发现自己漏了个细节，搜索文章内容节选的前后省略号。烦)

关于模糊查询算法，可以看这里探秘Fuse.js：模糊查询算法的学习笔记，这里不做赘述。

而匹配文本颜色标记，这个功能需要自己来实现，大致需求是，找出最佳匹配的文章内容节选展示在Spotlight的搜索结果列表里。解析md文档，去掉那些不想要的md文档标记符号，再循环找出最佳匹配区间作为节选内容，节选内容不超过30个字。

以上。

你有没有想过事情是否可以采取不同的方式, 但又不确定如何做？那么，不要爱上解决方案，而是爱上问题！这是一篇深入探讨设计思维如何做到这一点的文章。

在快节奏的行动和反应的世界中，高质量的结果是我们所有人的目标。但是你怎样才能做得更好呢？无论是产品、服务还是流程，我们的目标都是让事情变得更好。它让我们想知道我们将如何设计一个漫长而公平的世界以达到一定程度的卓越。

当我们谈论让“事情变得更好”时，我们不能否认看板系统在丰田实施 TQM（全面质量管理）中的作用。如果TQM为制造业做到了这一点，那么设计思维就有可能为创新带来以人为本的解决方案。

设计思维采用以人为本的方法，以便在我们跳入所有可能的解决方案之前了解如何处理问题。我们可以看到它在各个地方的使用。嗡嗡声无处不在，从社会部门到政策制定，从医疗保健到商业。那么什么是设计思维呢？

设计思维的意义 

设计思维促进以创造性的方式解决复杂问题，这种方式优先考虑人类的需求，并着重于寻找技术上可行的创造性解决方案。

虽然很难用几个词来定义“设计思维”，但我宁愿将设计思维视为一种哲学或一种思维方式，以解决难以用传统和标准方法解决的复杂问题解决问题的实践。设计思维采取的途径是提供以下解决方案：可行的、可行的和可取的。

一般来说，问题的解决方案有时会被传统的解决方法所忽视，而有些方法是高度理性和分析性的，而另一些则是情绪化的。设计思维可能只是增加人类问题的理性、情感和功能需求的第三种方式。设计思维不仅限于建筑产品；任何促进创新的新举措都可以利用解决问题的设计思维原则。

起源 

虽然没有确凿的证据表明设计思维的起源，但设计思维作为一种思维方式可以追溯到John E. Arnold，他是斯坦福大学“创意工程”研究的先驱，机械工程教授。他是最早撰写有关设计思维的少数人之一，并将设计思维的种子视为一种运动。他的讲座激发了更多的想象力和创新性。他的问题解决理论通过将问题的个人、科学和实践方面联系起来，着重于人类需求。

他强调了像艺术家一样处理问题并将人类作为想要构建的解决方案的基石的重要性。“创意问题”没有一个正确答案。

“工程师可以承担艺术家的某些方面，并通过美化或改善产品或机器的外观，或者通过对市场以及人们想要或不想要的东西的种类具有更敏锐的敏感性来尝试改善或增加产品或机器的适销性'想要。— 约翰·E·阿诺德*

设计思维过程 

在对设计思维进行情境化和应用的努力中，它通常被认为是一个过程，该过程可以指导价值观来控制如何处理问题。这个过程可能不一定是线性的或顺序的，而是一个对特定问题或用例有意义的循环。

设计思维过程

EMPATHIZE - 移情 

为人类设计可能很棘手。有时，需求或愿望未被发现，可能无法完全反映真正的问题。传统的市场研究过程是根据事实进行的，而设计思维方法是通过同理心来解决问题。同理心试图理解潜在需求并转化环境的当前现实。这有助于解决方案设计人员了解可以解释问题的人员、他们的行为和上下文，从而构建更好的解决方案。

因此，从问题中获得灵感的第一步是了解设计的对象以及他们寻求解决方案的动机。这对于企业了解可用的机会空间尤其有用。就像苹果所做的那样。虽然 MP3 播放器已经成为一种东西，但iPod 改变了人们消费音乐的方式。当索尼凭借随身听和 CD 统治消费电子市场时，苹果公司凭借 iPod彻底改变了音乐世界。Apple 对人们随身携带盒式磁带的问题深表同情，而 iPod 改变了游戏规则！

为了识别和理解问题的脉搏并结合这一步的背景，收集信息是关键。这是与问题空间中的人交谈以了解他们关心什么以及他们目前如何处理问题的地方。用户访谈和他们的反馈可以帮助了解他们的情况。

DEFINE - 定义 

这是形成问题的最重要步骤之一。

在设计思维中，构思不当的问题陈述为构建“问题”而非“问题”的解决方案铺平了道路。

例如，与某人谈论一个问题。记录下观察结果，并以合理的解决方案来解决该问题。用户对解决方案可能会解决该问题感到兴奋。但这里真正发生的是你和那个人一直在讨论他们许多其他问题中的一个问题。因此，他们是否决定采用你的解决方案取决于此人对你承诺解决的问题的重视程度。

在这里，定义问题的脉搏变得非常重要。 通常，事后看来，焦点会落在你试图解决的问题上，而不是这个人可能实际遇到的许多其他问题。

因此，定义问题对引导如何着手构建以人为本的解决方案大有帮助。

IDEATE - 构思 

在此阶段，观察结果会找到归宿，加以综合以创造改变的机会。集思广益来定义和重新定义潜在的解决方案，以创建解决问题的竞争想法。理想情况下，这一步可以帮助找到问题的核心。

如前所述，这不会是一个线性过程，可能经常会发现自己在共同努力挑战想法或问题本身时会回到之前的步骤。因此，可以挑选出好的想法来实施。

PROTOTYPE - 原型 

下一阶段是原型，可以通过创建最终解决方案的模型来验证想法。解决方案采用有形的形式来展示原型实施阶段的证据。它还展示了在构思阶段未说明的想法的限制和局限性。

Uber 是成功构建出色原型的经典公司之一。Uber 在最初发布时专注于解决“找出租车”的核心问题。该产品的第一个测试版是一个非常简约的应用程序，所有订单都是手动管理的，CEO 可以联系司机预订行程。而且它没有付费功能。目标是测试和验证叫车问题，这是该应用程序的核心优势。最终，当他们了解了目标市场和痛点后，他们开始改进其他功能。

TEST - 测试 

然后将最终原型与目标群体进行测试，并反复进行以适应学习方式。验证在这里采用最终形式，并且可能再次要求重新访问之前的一些步骤以大规模实施该计划。

行动中的设计思维 - 案例研究 

1. 社会部门的设计思维 

疟疾是非洲最令人不安的问题之一，也是5 岁以下儿童死亡的前 5 大原因之一。这是一个本质上非常复杂的社会问题，分发蚊帐的设计思维方法有助于有效地对抗这种疾病。世界卫生组织报告称，埃塞俄比亚和卢旺达等国家的死亡率下降了 50%-60% ，加纳下降了 34%。

结果发现，蚊帐的设计对加纳的一些人没有吸引力。一组研究人员确定了一个潜在的解决方案来解决让人们使用网络的问题。他们提出了一种以人为本的蚊帐设计，为长期解决这一社会问题铺平了道路。

以人为本的蚊帐设计方法。（ 大预览 ）

2. 爱彼迎 

设计思维在改造一家几近失败的公司——Airbnb 方面也发挥了巨大的作用。他们的业务正在瘫痪，当他们遇到问题时，他们发现广告中的图片效果不佳。展出的照片是用劣质手机拍摄的。当看到网站上的照片时，想租房的人觉得他们没有看到他们实际支付的是什么。创始人一意识到这一点，就租了一台相机，为客户的财产拍下好照片。创始人之一杰比亚 (Gebbia)继续解释设计学校的经历如何帮助他们重塑自我，更好地为客户服务。

3. 网飞 

另一个家喻户晓的品牌 Netflix 已经取得了长足的进步，设计思维在他们做出的决策中发挥了重要作用。Netflix 推出了直接送货上门的 DVD 租赁服务，而其他竞争对手则让人们开车穿过商店挑选电影。

后来当有线电视开始提供点播电影时，Netflix 了解了客户的痛点，开始按月提供在线流媒体服务，而无需为每张 DVD 付费。他们建立了一个订阅模式的在线目录，让客户在家中舒适地观看他们最喜欢的电影的便利性使他们感到高兴。

当选择要观看的内容比实际观看要花费更长的时间时，Netflix 想出了“预览”来帮助人们选择要观看的内容。听起来很简单，但 Netflix推荐系统背后的想法有助于减少人们花在决定观看内容上的时间。虽然变化是不可避免的，但 Netflix 不断通过设计思维方法重塑自己，以发现以最终用户为中心的创新解决方案。

从租用 DVD 到在线流媒体，Netflix 一直致力于了解最终用户，以以人为本的方式设计解决方案。

不仅如此。清单不胜枚举。

最后的想法 

设计思维一直在不断发展。人们一直在为使其在各个领域的使用情境化更有用做出贡献。根据问题的大小和复杂性，应用设计思维框架并着手创建以人为本的解决方案具有不同的形式。

考虑到它的灵活性，设计思维可以帮助熟悉并适应歧义。该方法可以在各种规模上动态地进行游戏，使其成为一项有价值的追求。

从想要解决的任何问题开始尝试，并在下面的评论中告诉我它是如何工作的。如果你愿意，我很乐意倾听并提供帮助。

相关资源 

• “为什么设计思维有效”，Jeanne Liedtka
• “设计思维不是一个过程，而是一种心态”，Amol R. Kadam
• 教育中的设计思维

这几天搜索我的聊天记录，无意中看到了一个两年前的聊天消息。那是和我讨论出海业务的独立开发网友，后来又去创业的业界精英。顺手一搜，当初他在我的一个开发者群也是高度活跃的人群之一，还经常私下给我提建议，人能力很强，做出海矩阵方向的项目做的很拿手。但是在后来忽然就没消息了，虽然人还留在群里。

我好奇点开了他的朋友圈，才知道他已经不做独立开发了，而且也（暂时）不在 IT 圈里玩了，去帮亲戚家的服装批发业务打打下手，说是下手，应该也是二当家级别了，钱不少，也相对安稳。朋友圈的画风以前是IT行业动态，出海资讯现在是销售文案和二维码。

和他私下聊了几句，他跟我说他现在过的也还好，人生路还长着呢，谈起了自己在现在这行做事情的经历，碎碎念说了不少有趣的事情，最后还和我感慨说：“转行后感觉脑子灵活了很多”，我说那你写程序的时候脑子不灵活吗，他发了个尴尬而不失礼貌的表情，“我以前技术搞多了，有时候死脑筋。”

这种话我没少听过，但是从一个认识（虽然是网友）而且大跨度转行的朋友这里说出来，就显得特别有说服力。尤其了解了他的经历后，想写篇文章唠叨下关于程序员短板的问题，还有这种短板不去补强，会怎么一步步让路越走越窄的。

现在离职（或者被离职）的程序员越来越多了，程序员群体，尤其是客户端程序员这个群体，只要能力过得去，都有全栈化和业务全面化的潜力。尤其是客户端程序员，就算是在公司上班时，业余时间写写个人项目，发到网上，每个月赚个四到五位数的副业收入也是可以的。

再加上在公司里遇到的各种各样的窝囊事，受了无数次“煞笔领导”的窝囊气，这会让一些程序员产生一种想法，我要不是业余时间不够，不然全职做个项目不就起飞了？

知道缺陷在哪儿，才能扬长避短，所以我想复盘一下，程序员创业，在主观问题上存在哪些短板。（因为说的是总体情况，也请别对号入座）

第一，认死理。

和代码，协议，文档打交道多了，不管自己情愿不情愿，人多多少少就有很强的“契约概念”，代码的世界条理清晰，因果分明，1就是1，0就是0，在这样的世界里呆多了，你要说思维方式不被改变，那是不可能的 --- 而且总的来说，这种塑造其实是好事情。要不然也不会有那么多家长想孩子从小学编程了。（当然了，家长只是想孩子学编程，不是做程序员。）

常年埋头程序的结果，很容易让技术人对于社会上很多问题的复杂性本质认识不到位，恐惧，轻视，或者视而不见，总之，喜欢用自己常年打磨的逻辑能力做一个推理，然后下一个简单的结论。用毛爷爷的话说，是犯了形而上的毛病。

例如，在处理iOS产品上架合规性一类问题时，这种毛病暴露的就特别明显。

比如说相信一个功能别的产品也是这么做的，也能通过审核，那自己照着做也能通过。但是他忽略了这种判断背后的条件是，你的账号和别的账号在苹果眼里分量也许不同的，而苹果是不会把这件事写在文档上的。

如果只是说一说不要紧，最怕的是“倔”，要不怎么说是“认死理”呢。

第二，喜欢拿技术套市场。

这个怎么理解呢，就是有追求的技术人喜欢研究一些很强的技术，但是研究出来后怎么用，也就是落实到具体的应用场景，就很缺点想象力了。

举个身边有意思的例子，有个技术朋友花了三年时间业余时间断断续续的写，用 OpenGL 写了一套动画效果很棒的 UI 引擎，可以套一个 View 进去后定制各种酷炫的动画效果。做出来后也不知道用来干嘛好，后来认识了一个创业老板，老板一看你这个效果真不错啊，你这引擎多少钱我买了，朋友也没什么概念，说那要不五万卖你。老板直接钱就打过去了。后来老板拿给手下的程序员维护，用这套东西做了好几个“小而美”定位的效率工具，简单配置下就有酷炫的按钮动画效果，配合高级的视觉设计逼格拉满，收入怎么样我没问，但是苹果在好几个国家都上过推荐。

可能有人要说，那这个程序员哥哥没有UI帮忙啊，对，是这个理，但是最根本的问题是，做小而美工具这条路线，他想都没想到，连意识都意识不到的赚钱机会，怎么可能把握呢？有没有UI帮忙那是实现层的门槛而已。

第三，不擅长合作。

为什么很多创业赚到小钱（马化腾，李彦宏这些赚大钱就不说了，对我们大部分人没有参考价值）而且稳定活下来的都是跑商务，做营销出身的老板。

他们会搞钱。

他们会搞钱，是因为他们会搞定人，投资人，合伙人，还有各种七七八八的资源渠道。

大部分人，在创业路上直接卡死在这条路线上了。

投资人需要跑，合作渠道需要拉，包括当地的税务减免优惠，创业公司激励奖金，都需要和各种人打交道才能拿下来。

那我出海总行了吧，出海就不用那么麻烦了吧。不好意思，出海的合作优势也是领先的，找海外的自媒体渠道合作，给产品提曝光。坚持给苹果写推荐信，让自家产品多上推荐。你要擅长做这些，就不说比同行强一大截，起码做出好产品后创业活下来的希望要高出不少，还有很多信息差方法论，需要进圈子才知道。

--- 

我说的这些，不是贬损也不是中伤，说白了，任何职业都有自己的短板，也就是我们说的职业病，本来也不是什么大不了的事情。只是我们在大公司拧螺丝的时候，被保护的太好了。

只是创业会让一个人的短处不断放大，那是因为你必须为自己的选择负责了，没人帮你擦屁股了背锅了。所以短板才显得那么刺眼。

最后说一下，不是说有短板就会失败，谁没点短处呢。写出来只是让自己和朋友有更好的自我认知，明白自己的长处在哪，短处在哪。

最后补一个，左耳朵耗子的事情告诉我们，程序员真的要保养身子，拼到最后其实还是拼身体，活下来才有输出。

犹记得高中班主任说：“大家努力考上大学，大学没人管，到时候随便玩”。我估计很多老师都这么说过。

我考上大学（2010年）之前也是这么过的。第一年哥哥给买了个一台华硕笔记本电脑。那个年代买华硕的应该不少，我周边就好几个。有了电脑之后，室友就拉着我一起 cs，四个人组队玩，那会觉得很嗨，上头。

后来看室友在玩魔兽世界，那会不知道是什么游戏，就感觉很好玩，再后来就入坑了。还记得刚开始玩，完全不会，玩个防骑，但是打副本排DPS，结果还被人教育，教育之后还不听（因为别的职业不会玩），就经常被 T 出组。之后，上课天天看游戏攻略和玩法，或者干脆看小说。前两年就这么过去了

1 跟风考研

大三开始，觉得这么混下去不行了。在豆瓣上找了一些书，平时不上课的时候找个自习室学习。那会家里打电话说有哪个亲戚家的孩子考研了，那是我第一次知道“考研”这个词。那会在上宏微观经济学的课，刚好在豆瓣上看到一本手《牛奶面包经济学》，就在自习室里看。刚好有个同院系的同学在里面准备考研，在找小伙伴一起战斗（毕竟，考研是一场长跑，没有同行者，会很艰难）。我一合计，就加入了他们的小团队。从此成为“中国合伙人”（刚好四个人）中的一员。

我那会也不知道毕业了之后能去哪些公司，能找哪些岗位，对于社会完全不了解，对于考研也是完全不了解。小团队中的三个人都是考金融学，我在网上查，知道了学硕和专硕的区别，也知道专硕学费贵。我家里没钱，大学时期的生活费都是自己去沃尔玛、麦当劳、发传单挣得，大学四年，我在沃尔玛工作超过了 2 年、麦当劳半年，食堂倒盘子半年，中途还去发过传单，暑假还去实习。没钱，他们考金融学专硕，那我就靠经济学学硕吧，学硕学费便宜。

从此开始了考研之路。

2 三次考研

大三的时候，报名不是那么严格，混进去报了名，那会还没开始看书，算是体验了一把考研流程；

还记得那次政治考了 48 分，基本都过了很多学校的单科线，那会就感觉政治最好考（最后发现，还是太年轻）。

大四毕业那年，把所有考研科目的参数书都过了 2 遍，最后上考场，最后成绩也就刚过国家线。

毕业了，也不知道干啥，就听小伙伴的准备再考一次，之前和小伙伴一起来了北京，租了个阳台，又开始准备考研。结果依然是刚过国家线。这一年也多亏了一起来北京的几个同学资助我，否则可能都抗不过考试就饿死街头了。

总结这几次考研经历，失败的最大原因是，我根本不知道考研是为了什么。只是不知道如果工作的话，找什么工作。刚好别人提供了这样一个逃避工作的路，我麻木的跟着走而已。这也是为什么后面两次准备的过程中，一有空就看小说的原因。

但是，现在来看，我会感谢那会没有考上，不然就错过了现在喜欢的技术工作。因为如果真的考上了经济学研究生，我毕业之后也不知道能干啥，而且金融行业的工作我也不喜欢，性格上也不合适，几个小伙伴都是考的金融，去的券商，还是比较了解的。

3 入坑 JAVA 培训

考完之后，大概估了分，知道自己大概率上不了就开始找工作了。那会在前程无忧上各种投简历。开始看到一个做外汇的小公司，因为我在本科在一个工作室做过外汇交易相关的工作，还用程序写了一段量化交易的小程序。

所以去培训了几天，跟我哥借了几千块钱，注册了一个账号，开始买卖外汇。同时在网上找其他工作。

后面看介绍去西二旗的一家公司面试，说我的技术不行，他们提供 Java 培训（以前的套路），没钱可以贷款。

我自己也清楚本科一行 Java 代码没写过，直接工作也找不到工作。就贷款培训了，那会还提供住宿，跟学校宿舍似的，上下铺。

4 三年新手&非全研究生

培训四个月之后，开始找工作。那会 Java 还没这么卷，而且自己还有个 211 学历，一般公司的面试还是不少的。但是因为培训的时候学习不够刻苦（也是没有基础）。最后进了一个小公司，面试要 8000，最后给了 7000。这也是我给自己的最底线工资，少于这个工资就离开北京了，这一年是 2015 年。

这家公司是给政府单位做内部系统的，包括中石油、气象局等。我被分配其中一个组做气象相关系统。第二年末的时候，组内的活对我来说已经没什么难度了，就偷偷在外面找工作，H3C 面试前 3 面都通过了，结果最后大领导面气场不符，没通过。最后被另外一家公司的面试官劝退了。然后公司团建的时候，大领导也极力挽留我，最后没走成。

这次经历的经验教训有 2 个，第 1 个是没有拿到 offer 之前，尽量不要被领导知道。第 2 个是，只要领导知道你要离职，就一定要离职。这次就是年终团建的时候，被领导留下来了。但是第二年以各种理由不给工资。

之前自己就一直在想出路，但是小公司，技术成长有限，看书也对工作没有太大作用，没有太大成长。之后了解到研究生改革，有高中同学考了人大非全。自己也就开始准备非全的考试。最后拿到录取通知书，就开始准备离职了。PS：考研准备

在这家公司马上满 3 年重新签合同的时候，偷偷面试了几家，拿到了 2 个还不错的 offer。第二天就跟直属领导提离职了。这次不管直属领导以及大领导如何劝说，还是果断离职了。

这个公司有两个收获。一个是，了解了一般 Java Web 项目的全流程，掌握了基本开发技能，了解了一些大数据开发技术，如Hadoop套件。另外一个是，通过准备考研的过程，也整理出了一套开发过程中应该先思而后行。只有先整理出

5 五年开发经历

第二家公司是一家央企控股上市公司，市场规模中等。主要给政府提供集成项目。到这家公司第二年就开始带小团队做项目，但是工资很低，可能跟公司性质有关。还好公司有宿舍，有食堂。能省下一些钱。

到这家公司的时候，非全刚好开始上课，还好我们 5 点半就下班，所以我天天卡点下班，大领导天天给开发经理说让我加班。但是第一学期要上课，领导对我不爽，也只能这样了。

后来公司来了一个奇葩的产品经理，但是大领导很挺他，大领导下面有 60 号人，研发、产品、测试都有。需求天天改，还不写在文档上。研发都开发完了，后面发现有问题，要改回去，产品还问，谁让这么改的。

是否按照文档开发，也是大领导说的算，最后你按照文档开发也不对，因为他们更新不及时；不按照文档开发也不对，写了你不用。

最后，研发和产品出差，只能同时去一波人，要是同时去用户现场，会打架。最后没干出成绩，产品和大领导一起被干走了。

后面我们整体调整了部门，部门领导是研发出身。干了几个月之后，领导也比较认可我的能力，让我带团队做一个中型项目，下面大概有 10 号人，包括前后端和算法。也被提升为开发经理。

最后因为工资、工作距离（老婆怀孕，离家太远）以及工作内容等原因，跳槽到了下一家互联网公司。

6 入行互联网

凭借着 5 年的工作经历，还算可以的技术广度（毕竟之前啥都干）,985 学校的非全研究生学历，以及还过得去的技术能力。找到了一家知名度还可以的互联网公司做商城开发。

这个部门是公司新成立的部门，领导是有好几家一线互联网经验的老程序员，技术过硬，管理能力强，会做人。组内成员都年轻有干劲。本打算在公司大干一场，涨涨技术深度（之前都是传统企业，技术深度不够，但是广度可以）。

结果因为政策调整，整个部门被裁，只剩下直属领导以及领导的领导。这一年是 2020 年。这个时候，我在这个公司还不到 1 年。

7 再前行

拿着上家公司的大礼包，马上开始改简历，投简历，面试，毕竟还有房贷要还（找了个好老婆，她们家出了大头，付了首付），马上还有娃要养，一天也不敢歇息。

经过一个半月的面试，虽然挂的多，通过的少。最终还是拿了 3 个不错的offer，一个滴滴（滴滴面经）、一个XXX网络（最终入职，薪资跟滴滴基本差不多，技术在市场上认可度也还不错。）以及一个建信金科的offer。

因为大厂部门也和上家公司一样，是新组建的部门，心有余悸。然后也还年轻，不想去银行躺平，也怕银行也不靠谱，毕竟现在都是银行科技公司，干几年被裁，更没有出路。最终入职XXX网络。

8 寒冬

入职XXX网络之后，开始接入公司的各种技术组件，以及看到比较成熟的需求提出、评估、开发、测试、发布规范。也看到公司各个业务中心、支撑中心的访问量，感叹还是大公司好，流程规范，流量大且有挑战性。

正要开心的进入节奏，还没转正呢（3 个月转正），组内一个刚转正的同事被裁，瞬间慌得一批。

刚半年呢，听说组内又有 4 个裁员指标，已经开始准备简历了。幸运的是，这次逃过一劫。

现在已经 1 年多了，在这样一个裁员消息满天飞的年代，还有一份不错的工作，很幸运、也很忐忑，也在慢慢寻找自己未来的路，共勉~

9 总结

整体来看，我对自己的现状还算满意，从一个高中每个月 300 块钱生活费家里都拿不出来；高考志愿填报，填学校看心情想去哪，填专业看专业名字的的村里娃，走到现在在北京有个不错的工作，组建了幸福的家庭，买了个不大不小的房子的城里娃。不管怎么样，也算给自己立足打下了基础，留在了这个有更多机会的城市；也给后代一个更高的起点。

但是，我也知道，现在的状态并不稳固，互联网工作随时可能会丢，家庭成员的一场大病可能就会导致整个家庭回到解放前。

所以，主业上，我的规划就是，尽力提升自己的技术能力和管理能力，争取能在中型公司当上管理层，延迟自己的下岗年龄；副业上，提升自己的写作能力，尝试各种不同的主题，尝试给各个自媒体投稿，增加副业收入。

希望自己永远少年，不要下岗~

前端吐槽：后端从不自测接口，等到前后端联调时，这个接口获取不到，那个接口提交不了，把前端当成自己的接口测试员，耽误前端的开发进度。

听到这个吐槽，仿佛看到曾经羞愧的自己。这个毛病以前我也有啊，有些接口，尤其是大表单提交接口，表单特别大，字段很多，有时候就偷懒了，直接编译过了，就发到测试环境了。前端同时联调的时候一调接口，异常了。

好在后来改了，毕竟让人发现自己接口写的有问题，也是一件丢脸的事儿。

但是我还真见过后端的同学，写完接口一个都不测，直接发测试环境的。

我就碰到过厉害的，编译都不过，就直接提代码。以前，有个新来的同事，分了任务就默默的干着，啥也不问，然后他做的功能测试就各种发现问题。说过之后，就改一下，但是基本上还是不测试，本想再给他机会的，所以后来他每次提代码，我都review一下。直到有一天，我发现忍不了了，他把一段全局配置给注释了，然后把代码提了，我过去问他是不是本地调试，忘了取消注释了。他的回答直接让我震惊了，他说：不是的，是因为不注释那段代码，我本地跑步起来，所以肯定是那段代码有问题，所以就注释了。

然后，当晚，他就离职了。

解决方式

对于这种大表单类似的问题，应该怎么处理呢？

好像没有别的方法，只能克服自己的懒惰，为自己写的代码负责。就想着，万一接口有问题，别人可能会怀疑你水平不行，你水平不行，就是你不行啊，程序员怎么能不行呢。

你可以找那么在线 Java Bean转 JSON的功能，直接帮你生成请求参数，或者现在更可以借助 ChatGPT ，帮你生成请求参数，而且生成的参数可能比你自己瞎填的看上去更合理。

或者，如果是小团队，不拘一格的话，可以让前端的同事把代码提了，你本地跑着自测一下，让前端同事先做别的功能，穿插进行也可以。

前端吐槽：后端修改了字段或返回结构不通知前端

这个就有点不讲武德了。

正常情况下，返回结构和字段都是事先约定好的，一般都是先写接口，做一些 Mock 数据，然后再实现真实的逻辑。

除了约定好返回字段和结构外，还包括接口地址、请求方法、头信息等等，而且一个项目都会有项目接口规范，同一类接口的返回字段可能有很多相同的部分。

后端如果改接口，必须要及时通知前端，这其实应该是正常的开发流程。后端改了接口，不告诉前端，到时候测试出问题了，一般都会先找前端，这不相当于让前端背锅了吗，确实不地道啊。

后端的同学们，谨记啊。

前端吐槽：为了获取一个信息，要先调用好几个接口，可能参数还是相同的

假设在一个详情页面，以前端的角度就是，我获取详情信息，就调用详情接口好了，为什么调用详情接口之前，要调用3、4个其他的接口，你详情里需要啥参数，我直接给你传过去不就好了吗。

在后端看来可能是这样的，我这几个接口之前就写好了，前端拿过去就能用，只不过就是多调几次罢了，没什么大不了的吧。

有些时候，可能确实是必须这么做的，比如页面内容太多，有的部分查询逻辑复杂，比较耗时，这时候需要异步加载，这样搞确实比较好。

但是更多时候其实就是后端犯懒了，不想再写个新接口。除了涉及到性能的问题，大多数逻辑都应该在后端处理，能用一个接口处理完，就不应该让前端多调用第二个接口。

有前端的朋友曾经问过我，他说，他们现在做的系统中有些接口是根据用户身份来展示数据的，但是前端调用登录接口登录系统后，在调用其他接口的时候，除了在 Header 中加入 token 外，还有传很多关于用户信息的很多参数，这样做是不是不合理的。

这肯定不合理，token 本来就是根据用户身份产生的，后端拿到 token 就能获取用户信息，这是常识问题，让前端在接口中再传一遍，既不合理也不安全。

类似的问题还有，比如后端接口返回一堆数据，然后有的部分有用、有的部分没有，有的部分还涉及到逻辑，不借助文档根本就看不明白怎么用，这其实并不合理。

接口应该尽量只包含有用的部分，并且尽可能结构清晰，配合简单的字段说明就能让人明白是怎么回事，是最好的效果。

如果前后端都感觉形势不对了，后端一个接口处理性能跟不上了，前端处理又太麻烦了。这时候就要向上看了，产品设计上可能需要改一改了。

后端的同学可以学一点前端，前端的同学也可以学一点后端，当你都懂一些的时候，就能两方面考虑了，这样做出来的东西可能会更好用一点。总之，前后端相互理解，毕竟都是为了生活嘛。

导读

程序员痛恨遇到质量低劣的代码，但在高压环境下，我们常为了最快解决当下需求而忽略代码规范，在无意识中堆积大量债务。我们还观察到许多开发者被迫加班的罪魁祸首便是写低效代码、不重视代码优化。编程路上，欲速则不达。 接下来，我将为各位列举9种我个人工作中高频遇到的不整洁代码行为，并提出针对性优化建议。继续阅读~

目录

1 代码风格和可读性

2 注释

3 错误处理和异常处理

4 代码复用和模块化

5 硬编码

6 测试和调试

7 性能优化

8 代码安全性

9 版本控制和协作

10 总结

01、代码风格和可读性

• 错误习惯

1.1 变量命名不规范

在编程中，变量命名是非常重要的，良好的变量命名能够提高代码的可读性和可维护性。不规范的命名会增加理解难度，以下是一个不规范命名的例子：

int a, b, c; // 不具有描述性的变量名

float f; // 不清楚变量表示的含义

这样的变量命名不仅会降低代码的可读性，还可能会导致变量混淆，增加代码维护的难度。正确的做法应该使用有意义的名称来命名变量。例如：

int num1, num2, result; // 具有描述性的变量名

float price; // 清晰明了的变量名

1.2 长函数和复杂逻辑

长函数和复杂逻辑是另一个常见的错误和坏习惯。长函数难以理解和维护，而复杂逻辑可能导致错误和难以调试。以下是一个长函数和复杂逻辑的案例：

def count_grade(score):

    if score >= 90:

        grade = 'A'

    elif score >= 80:

        grade = 'B'

    elif score >= 70:

        grade = 'C'

    elif score >= 60:

        grade = 'D'

    else:

        grade = 'F'

    

    if grade == 'A' or grade == 'B':

        result = 'Pass'

    else:

        result = 'Fail'

    return result

在这个例子中，函数 count_grade 包含了较长的逻辑和多个嵌套的条件语句，使得代码难以理解和维护。正确的做法是将逻辑拆分为多个小函数，每个函数只负责一个简单的任务，例如：

def count_grade(score):

    grade = get_grade(score)

    result = pass_or_fail(grade)

    return result

def get_grade(score):

    if score >= 90:

        return 'A'

    elif score >= 80:

        return 'B'

    elif score >= 70:

        return 'C'

    elif score >= 60:

        return 'D'

    else:

        return 'F'

def pass_or_fail(grade):

    if grade == 'A' or grade == 'B':

        return 'Pass'

    else:

        return 'Fail'

通过拆分函数，我们使得代码更加可读和可维护。

1.3 过长的行

代码行过长，会导致代码难以阅读和理解，增加了维护和调试的难度。例如：

def f(x):

    if x>0:return 'positive' elif x<0:return 'negative'else:return 'zero'

这段代码的问题在于，它没有正确地使用空格和换行，使得代码看起来混乱，难以阅读。正确的方法是，我们应该遵循一定的代码规范和风格，使得代码清晰、易读。下面是按照 PEP 8规范改写的代码

def check_number(x):

    if x > 0:

        return 'positive'

    elif x < 0:

        return 'negative'

    else:

        return 'zero'

这段代码使用了正确的空格和换行，使得代码清晰、易读。

02、注释

• 错误习惯

• 错误的注释

注释是非常重要的，良好的注释可以提高代码的可读性和可维护性。以下是一个不规范的例子：

int num1, num2; // 定义两个变量

上述代码中，注释并没有提供有用的信息，反而增加了代码的复杂度。

03、错误处理和异常处理

• 错误的习惯

3.1 忽略错误

我们往往会遇到各种错误和异常。如果我们忽视了错误处理，那么当错误发生时，程序可能会崩溃，或者出现不可预知的行为。例如：

def divide(x, y):

    return x / y

这段代码的问题在于，当 y 为0时，它会抛出 ZeroDivisionError 异常，但是这段代码没有处理这个异常。下面是改进的代码：

def divide(x, y):

    try:

        return x / y

    except ZeroDivisionError:

        return 'Cannot divide by zero!'

3.2 过度使用异常处理

我们可能会使用异常处理来替代条件判断，这是不合适的。异常处理应该用于处理异常情况，而不是正常的控制流程。例如：

def divide(a, b):

    try:

        result = a / b

    except ZeroDivisionError:

        result = float('inf')

    return result

在这个示例中，我们使用异常处理来处理除以零的情况。正确做法：

def divide(a, b):

    if b == 0:

        result = float('inf')

    else:

        result = a / b

    return result

在这个示例中，我们使用条件判断来处理除以零的情况，而不是使用异常处理。

3.3 捕获过于宽泛的异常

捕获过于宽泛的异常可能导致程序崩溃或隐藏潜在的问题。以下是一个案例：

try {

    // 执行一些可能抛出异常的代码

} catch (Exception e) {

    // 捕获所有异常，并忽略错误}

在这个例子中，异常被捕获后，没有进行任何处理或记录，导致程序无法正确处理异常情况。正确的做法是根据具体情况，选择合适的异常处理方式，例如：

try {

    // 执行一些可能抛出异常的代码

} catch (FileNotFoundException e) {

    // 处理文件未找到异常

    logger.error("File not found", e);

} catch (IOException e) {

    // 处理IO异常

    logger.error("IO error", e);

} catch (Exception e) {

    // 处理其他异常

    logger.error("Unexpected error", e);}

通过合理的异常处理，我们可以更好地处理异常情况，增加程序的稳定性和可靠性。

04、错误处理和异常处理

• 错误的习惯

4.1 缺乏复用性

代码重复是一种非常常见的错误。当我们需要实现某个功能时，可能会复制粘贴之前的代码来实现，这样可能会导致代码重复，增加代码维护的难度。例如：

   def calculate_area_of_rectangle(length, width):

       return length * width



   def calculate_volume_of_cuboid(length, width, height):

       return length * width * height



   def calculate_area_of_triangle(base, height):

       return 0.5 * base * height



   def calculate_volume_of_cone(radius, height):

       return (1/3) * 3.14 * radius * radius * height

上述代码中，计算逻辑存在重复，这样的代码重复会影响代码的可维护性。为了避免代码重复，我们可以将相同的代码复用，封装成一个函数或者方法。例如：

   def calculate_area_of_rectangle(length, width):

       return length * width



   def calculate_volume(length, width, height):

       return calculate_area_of_rectangle(length, width) * height



   def calculate_area_of_triangle(base, height):

       return 0.5 * base * height



   def calculate_volume_of_cone(radius, height):

       return (1/3) * 3.14 * radius * radius * height

这样，我们就可以避免代码重复，提高代码的可维护性。

4.2 缺乏模块化

缺乏模块化是一种常见的错误，这样容易造成冗余，降低代码的可维护性，例如：

   class User:

       def __init__(self, name):

           self.name = name



       def save(self):

           # 保存用户到数据库的逻辑



       def send_email(self, content):

           # 发送邮件的逻辑



   class Order:

       def __init__(self, user, product):

           self.user = user

           self.product = product



       def save(self):

           # 保存订单到数据库的逻辑



       def send_email(self, content):

           # 发送邮件的逻辑

   ```

此例中，User 和 Order 类都包含了保存和发送邮件的逻辑，导致代码重复，耦合度高。我们可以通过将发送邮件的逻辑提取为一个独立的类，例如：

   class User:

       def __init__(self, name):

           self.name = name



       def save(self):

           # 保存用户到数据库的逻辑



   class Order:

       def __init__(self, user, product):

           self.user = user

           self.product = product



       def save(self):

           # 保存订单到数据库的逻辑



   class EmailSender:

       def send_email(self, content):

           # 发送邮件的逻辑

通过把发送邮件单独提取出来，实现了模块化。现在 User 和 Order 类只负责自己的核心功能，而发送邮件的逻辑由 EmailSender 类负责。这样一来，代码更加清晰，耦合度降低，易于重构和测试。

05、硬编码

• 错误的习惯

5.1 常量

在编程中，我们经常需要使用一些常量，如数字、字符串等。然而，直接在代码中硬编码这些常量是一个不好的习惯，因为它们可能会在未来发生变化，导致维护困难。例如：

def calculate_score(score):

    if (score > 60) {

    // do something}

这里的60就是一个硬编码的常量，导致后续维护困难，正确的做法应该使用常量或者枚举来表示。例如：

PASS_SCORE = 60;

def calculate_score(score):

    if (score > PASS_SCORE) {

        // do something    }

这样，我们就可以避免硬编码，提高代码的可维护性。

5.2 全局变量

过度使用全局变量在全局范围内都可以访问和修改。因此，过度使用全局变量可能会导致程序的状态难以跟踪，增加了程序出错的可能性。例如：

counter = 0

def increment():

    global counter

    counter += 1

这段代码的问题在于，它使用了全局变量 counter，使得程序的状态难以跟踪。我们应该尽量减少全局变量的使用，而是使用函数参数和返回值来传递数据。例如：

def increment(counter):

    return counter + 1

这段代码没有使用全局变量，而是使用函数参数和返回值来传递数据，使得程序的状态更易于跟踪。

06、测试和调试

• 错误的习惯

6.1 单元测试

单元测试是验证代码中最小可测试单元的方法，下面是不添加单元测试的案例：

def add_number(a, b):

    return a + b

在这个示例中，我们没有进行单元测试来验证函数 add_number 的正确性。正确示例：

import unittest



def add_number(a, b):

    return a + b



class TestAdd(unittest.TestCase):

    def add_number(self):

        self.assertEqual(add(2, 3), 5)



if __name__ == '__main__':    unittest.main()

在这个示例中，我们使用了 unittest 模块进行单元测试，确保函数 add 的正确性。

6.2 边界测试

边界测试是针对输入的边界条件进行测试，以验证代码在边界情况下的行为下面是错误示例：

def is_even(n):

    return n % 2 == 0

在这个示例中，我们没有进行边界测试来验证函数 is_even 在边界情况下的行为。正确示例：

import unittest



def is_even(n):

    return n % 2 == 0



class TestIsEven(unittest.TestCase):

    def test_even(self):

        self.assertTrue(is_even(2))

        self.assertFalse(is_even(3))



if __name__ == '__main__':    unittest.main()

在这个示例中，我们使用了 unittest 模块进行边界测试，验证函数 is_even 在边界情况下的行为。

6.3 可测试性

代码的可测试性我们需要编写测试来验证代码的正确性。如果我们忽视了代码的可测试性，那么编写测试将会变得困难，甚至无法编写测试。例如：

def get_current_time():

    return datetime.datetime.now()

这段代码的问题在于，它依赖于当前的时间，这使得我们无法编写确定性的测试。我们应该尽量减少代码的依赖，使得代码更易于测试。例如：

def get_time(now):

    return now

这段代码不再依赖于当前的时间，而是通过参数传入时间，这使得我们可以编写确定性的测试。

07、性能优化

• 错误的习惯

7.1 过度优化

我们往往会试图优化代码，使其运行得更快。然而，过度优化可能会导致代码难以理解和维护，甚至可能会引入新的错误。例如：

def sum(numbers):

    return functools.reduce(operator.add, numbers)

这段代码的问题在于，它使用了 functools.reduce 和 operator.add 来计算列表的和，虽然这样做可以提高一点点性能，但是这使得代码难以理解。我们应该在保持代码清晰和易读的前提下，进行适度的优化。例如：

def sum(numbers):

    return sum(numbers)

这段代码使用了内置的 sum 函数来计算列表的和，虽然它可能比上面的代码慢一点，但是它更清晰、易读。

7.2 没有使用合适的数据结构

选择合适的数据结构可以提高代码的性能。使用不合适的数据结构可能导致代码执行缓慢或占用过多的内存。例如：

def find_duplicate(numbers):

    duplicates = []

    for i in range(len(numbers)):

        if numbers[i] in numbers[i+1:]:

            duplicates.append(numbers[i])

    return duplicates

在这个示例中，我们使用了列表来查找重复元素，但这种方法的时间复杂度较高。我们可以使用集合来查找元素。例如：

def find_duplicate(numbers):

    duplicates = set()

    seen = set()

    for num in numbers:

        if num in seen:

            duplicates.add(num)

        else:

            seen.add(num)

    return list(duplicates)

我们使用了集合来查找重复元素，这种方法的时间复杂度较低。

08、代码安全性

• 错误的习惯

8.1 输入验证

没有对用户输入进行充分验证和过滤可能导致恶意用户执行恶意代码或获取敏感信息。例如：

import sqlite3

def get_user(username):

    conn = sqlite3.connect('database.db')

    cursor = conn.cursor()

    query = f"SELECT * FROM users WHERE username = '{username}'"

    cursor.execute(query)

    user = cursor.fetchone()

    conn.close()

    return user

在这个示例中，我们没有对用户输入的 username 参数进行验证和过滤，可能导致 SQL 注入攻击。正确示例：

import sqlite3



def get_user(username):

    conn = sqlite3.connect('database.db')

    cursor = conn.cursor()

    query = "SELECT * FROM users WHERE username = ?"

    cursor.execute(query, (username,))

    user = cursor.fetchone()

    conn.close()

    return user

在这个示例中，我们使用参数化查询来过滤用户输入，避免了 SQL 注入攻击。

8.2 不正确的密码存储

将明文密码存储在数据库或文件中，或使用不安全的哈希算法存储密码都是不安全的做法。错误示例：

import hashlib



def store_password(password):

    hashed_password = hashlib.md5(password.encode()).hexdigest()

    # 存储 hashed_password 到数据库或文件中

在这个示例中，我们使用了不安全的哈希算法 MD5 来存储密码。正确示例：

import hashlib

import bcrypt



def store_password(password):

    hashed_password = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

    # 存储 hashed_password 到数据库或文件中

在这个示例中，我们使用了更安全的哈希算法 bcrypt 来存储密码。

8.3 不正确的权限控制

没有正确验证用户的身份和权限可能导致安全漏洞。错误示例：

def delete_user(user_id):

    if current_user.is_admin:

        # 执行删除用户的操作

    else:

        raise PermissionError("You don't have permission to delete users.")

在这个示例中，我们只检查了当前用户是否为管理员，但没有进行足够的身份验证和权限验证。正确示例：

def delete_user(user_id):

    if current_user.is_authenticated and current_user.is_admin:

        # 执行删除用户的操作

    else:

        raise PermissionError("You don't have permission to delete users.")

在这个示例中，我们不仅检查了当前用户是否为管理员，还检查了当前用户是否已经通过身份验证。

09、版本控制和协作

• 错误的习惯

9.1 版本提交信息

不合理的版本提交信息可能导致代码丢失、开发人员难以理解等问题。错误示例：

git commit -m "Fixed a bug"

在这个例子中，提交信息没有提供足够的上下文和详细信息，导致其他开发人员难以理解和追踪代码的变化。正确的做法是提供有意义的提交信息，例如：

$ git commit -m "Fixed a bug in calculate function, which caused grade calculation for scores below 60"

通过提供有意义的提交信息，我们可以更好地追踪代码的变化，帮助其他开发人员理解和维护代码。

9.2 忽略版本控制和备份

忽略使用版本控制工具进行代码管理和备份是一个常见的错误。错误示例：

$ mv important_code.py important_code_backup.py

$ rm important_code.py

在这个示例中，开发者没有使用版本控制工具，只是简单地对文件进行重命名和删除，没有进行适当的备份和记录。正确示例：

$ git clone project.git

$ cp important_code.py important_code_backup.py

$ git add .

$ git commit -m "Created backup of important code"

$ git push origin master

$ rm important_code.py

在这个示例中，开发者使用了版本控制工具进行代码管理，并在删除之前创建了备份，确保了代码的安全性和可追溯性。

10、总结

好的代码应该如同一首好文，让人爱不释手。优雅的代码，不仅是功能完善，更要做好每一个细节。

最后，引用韩磊老师在《代码整洁之道》写到的一句话送给大家：

“

细节之中自有天地，整洁成就卓越代码。

以上是本文全部内容，欢迎分享。

-End-