前天晚上彻夜难眠，翻来覆去，直到差不多凌晨四点才睡着，早上八点就起床上班了，很久都没有失眠了，失眠真的让人很痛苦。

回想起一些往事，自己做对了一些选择，但是也做错了很多选择，我想这大概就是人生，现在回想起来，不曾后悔，只有总结！

一

大四下学期我们就离开学校了，加上寒假的两个月，实际上我们的实习期有半年多，但是找工作应该是大四上学期就开始了。

那时候彪哥整天都在面试，积累了不少面试经验，也学习了不少知识，而那时候我鬼迷心窍，去做项目去了。

因为一些巧合，我加入了一个SAAS软件开发的小团队，做的是酒店方面的业务，我是远程办公，那段时间一边做毕设，一边做项目，但是做毕设的时间很少，因为论文就花了五天时间去写，更多是在做酒店项目。

现在我有一部分读者都是从我的区块链毕设过来的，我想对你们说一声，感谢你们的付费，但是也想对你们说一声对不起，如果当时我专心去做毕设，或许呈现在你们眼前的作品会更好，但是时间不能重来！

但是后来我仔细思考，我既不应该花时间去做毕设，也不应该为了点钱去做项目！

纵使我的毕设得了优秀毕设，算是我们那一届最优秀的毕设，但是并没有什么卵用，你的简历并不会因为一个优秀毕设而变得多么耀眼。

为了一点钱去做项目也不理智，因为一个人的时间是有限的，当把时间碎片化后，就很难集中去做一件事了，当时虽然说给我6k一个月，但是因为很多东西不熟悉，所以现去学，像uniapp都去学了，所以功能完成度和质量不高，一个月只给我结了3000不到！

干了两个月我们就毕业了，我收拾行李就回家了。

二

回到家里后，他们说直接给我一个单独项目做，也是一个SAAS的系统，说开发周期2个月，5万块钱，我当时心里想，一个月两万多，我直接不去实习了，安心干，干完我还可以玩几个月，这他妈多好啊。

于是我就接下来了，就开始进入coding状态，白天干，晚上干，后面在家里呆烦了，又跑回学校去。

在学校呆了半个多月，我做了50%，于是迫于经济压力，又回家了，回家最起码不愁饭吃。

那时候，我把自己定义为一个自由职业者，我也挺享受这样的生活，coding累了，就出去走走，回来后又继续coding，说实话，还挺享受！

那时候基本上大多同学都出去实习了，有些去了很不错的互联网公司，听他们说公司又是用什么牛逼的技术了，心里就突然有点羡慕。

但是想到项目做完马上能拿到钱了，就没有去羡慕了。

两个月时间很快到了，老板准时来验收了，不过一验bug足足提了几百个，还有很多变更，老板说尽快改完！

当时我有点懵，不应该先给我点钱吗？

我就说先付40%给我，但是人家说，你这玩意用起来到处是问题，无法用啊，怎么给钱？

我无话可说，拿不到钱，心里更加焦虑了，想不干了，那么就前功尽弃，如果继续干，问题越来越多，变更越来越多，思来想去，最后还是硬着头皮干了！

陆陆续续又干了半个多月，这时候二验又开始了，老板说这次稍微好了一点，但是也无法用啊，于是叫我把代码上传到他们仓库，然后给我付3000块钱，开发完后再一起结，我自然不愿意。

我想，代码给你了，你不理我了怎么办，所以我还是想等开发完以后拿到钱再交代码。

这时候我干了快三个月了，心里虽然看到一点希望，但是更多的是焦虑，因为再有几个月了就要毕业了，而我还没有去实习！

父母也开始念叨，心里的压力就更大了，我想，再干半个月，还拿不了钱，我真的就不干了。

我又继续做，为了快速做完，很多东西我都是没有考虑的，所以问题自然也多，特别还有硬件对接，还有一些复杂的操作。

说实话，这东西暂时肯定是用不了的，但是为了能拿到钱，我也带有一点骗的成分在里面，偷工减料，以为人家看不出来，实际上别人比你精多！

很多项目二验不通过，那基本就烂尾了，但是老板说，来个三验，果然还是用不了，问题很多，所以依然没拿到钱。

心里更加烦躁了，后面我直接说要么给钱，要么不做了，心里彻底崩溃了，心里后悔，为啥要去接这个项目，为啥浪费这么多时间，为啥不去实习。

后面老板说，如果你不想开发了也可以，把代码交出来，给你5000块钱，后面你和别人一起协同开发，不用全职开发。

我心里是抗拒的，干了这么久才几千块钱，心有不甘，不过过了几天，因为经济压力，所以还是选择交出代码了，谈成了6000块钱。

因为我知道他们会一直加需求，一直在变更，是一个无底洞！

三个多月，就得了6000块钱，心里别提多难受，不过好在暂时有点钱用。

于是直接就不干了，在家里呆了几天就开始投简历了，只有三个月不到就毕业了，所以自然去不了外面了，于是只能在省会城市找实习了。

还好那时候面试机会还挺多，一个星期不到就入职了，6000块钱的实习，就去干了，说实话，一个三线城市，也只能开这么多了！

不过现在这种就业环境，如果学历背景没有占优势，三线城市找6000以上的实习，还是比较难的，这两年市场真的比较低迷了！

“自由职业者“的那段时间，大概是我这么多年来最煎熬的时光，因为总是在希望和失望中来回穿梭。

后来我在书中看到一段话，“如果命运给你一次机会，哪怕是一根稻草，你也要牢牢抓住”，显然那个时候我的认知比较低，认为那就是命运的稻草，但是实际上那不是，那是荆棘！

当你的认知和能力都不够的时候，就算钱摆在你面前你都拿不了。

三

落笔到这里，心里不禁泛起一阵酸楚！

一个人总要为自己的认知买单的，因为在很黄金的时间阶段，我去做了不太正确的选择，虽然不曾后悔，但是我知道那是不理智的选择。

这段回忆虽然会成为我人生的阅历，甚至可以说是一种财富，但是他终归是一个教训，不值得提倡！

四

在大四上学期，应该快速把毕设做完，然后进入复习，投简历，即使找不到工作，也能锻炼面试能力，对自己的知识体系进行查缺补漏！

优秀毕设，论文，这些在本科阶段实际上没什么卵用，不过是教育的一个考核而已。

在校期间，那些社团活动，学生会并不能为你将来的职业发展发挥多大的作用，切勿过于沉迷！

眼前的小钱是陷阱，在未来很快就能赚回来！

在学校期间，兼职是完全没有必要的，因为赚不了几个钱，但是却花费了大量的时间，学生时期正是学习知识的时候，浪费了就没有了。

因为把只是学扎实，这点钱等毕业后一个月就能全部赚回来，但是如果浪费了，将要用很多时间去弥补，这时候你已经落后于别人很多了！

虽然我去做项目也能锻炼自己的能力，但是时机不对，如果大三去做那么没问题，但是在临近毕业之际去做，这就是不理智的。

五

学生时代，对于项目我们是没有风险把控能力的，也不清楚项目的流程，所以能赚到钱的几率不大！

我浪费了三四个月的时间去做一个项目这是不理智的，首先单干很有局限性，因为独木不成舟，你很多东西考虑不到位，所以会有很多漏洞。

还有你不能学习优秀的人的逻辑，实际上你是处于一个封闭的状态。

我觉得正确的做法是应该找一个不错的公司进去学习，融入团队，这样才能真的学到东西。

天真的是，我当时还想将其打造成一个产品，然后进行创业！

后来想想，自己如果真的投入时间去做了，那么不仅赚不到钱，可能还会饿肚子。

不用说什么不去试试怎么知道。

当你的认知跟不上的时候，你所想的，所做的，基本上都不会成功，不要想着幸运之神降临在你的身上。

六

那年，我傻逼地把自己定义为自由职业者。

实际上我连边都沾不上，因为没有赚到钱，还谈什么自由，叫“烂账职业者”还差不多。

今天，我们总是去羡慕那些自由职业者每天不用上班也能赚钱，实际上和你看到的不一样。

自由职业者赚到钱的人只有少数，但是都是经历过很多尝试，认知得到飞跃地提升后才成的。

不过可以肯定的是，未来自由职业者会越来越多，个人IP也将在未来大爆发。

布局是我们该做的事。

种一棵树最好的时间是十年前，其次是现在。

七

以上也就是对于过去的一些反思，我从来不去抱怨过去，只是去思考自己。

因为每一条路都没有对错，只能说很多时候选择大于努力。

路走岔了的时候要及时止损，不要一头黑走到底，这样对自己不好。

对于未来，还是得比较理性去看待，虽然充满各种不确定性，但是很多确定性的东西我们是能看到的。

行文至此，已经凌晨2点！

大家早上好，今天聊一下最近的一些经历和感悟还有回到三线城市的感悟，希望对大家有一定的帮助！

一、我不适合躺，也躺不了

我毕业之后就到了成都，去了一家做基础软件的上市公司，不过我们部门还是属于业务部门，差不多干了两年，因为公司属于比较传统的企业，自然没有互联网的内卷，基本上没什么加班，特别是第二年，基本上没啥事做！

这种情况下我开始意识到了问题，如果再这样呆下去，对自己的发展会很不利，如果部门的业务再推动不了，那么到时候也得面临调整，总之，留与不留对自己大多都是不好的，所以我就准备离开了！

成都在别人的映像中是一个休闲城市，吃喝玩乐，但是那是属于有钱人的，打工人只有辛苦和内卷，我就住在天府软件园对面，每晚软件园里面都是灯火通明的！

二、机缘巧合

不过对于我来说，我已经没有想法继续留在成都了，当时是想去杭州或者深圳，不过在离职完的第二天，贵阳这边的公司就叫我面试，我都不记得是啥时候投的简历！

因为两年来都没有面过试了，所以练练嘴皮子，经过几面后，给了offer，从开始面试到给offer差不多半个月，给了offer后我十来天就去入职了！

从离职后到进去新公司这段时间差不多一个月，我就在成都耍了20来天，一直在做思想斗争，说实话，去一线城市和回故乡这两个抉择是很难做选择的，为什么呢？我表达一下我的观点。

三、我认为的大城市小城市

首先，一线的机会肯定会比小城市的机会多，接触到的人也相对来说比较厉害一点，这样自己的视野也会开阔一点，不过这也要根据自己的能力来看，如果自己本身就啥也不是，那基本上也无缘接触到厉害的人！

其次，一线的人情世故不像小城市那么复杂，特别像深圳这样的城市，大家都是从外面来的，所以来了就是深圳人，包容性比较高，这样的话能够减少一些心理压力，而小城市则不然，因为好一点的单位，保安都会和你吹他家那个亲戚是省里的，不然他也谋不了这个职位，往上就更不用说，哈哈！

所以小城市的人因为地缘原因，就会产生一定的优越感，所以整体下来说，其实是不那么包容的，不那么开放的，在这样的环境下对自己或多或少有一定的影响，当然，大城市也会有，只是相对于小城市来说会轻很多！

以上只是很小的一部分，还有很多就没必要说了！

四、为什么我还要回到小城市

上面也说了因为很快拿到offer，还是在自己的故乡，而且这个企业在贵州省内来说也算比较好，属于本土企业，所以这算是一个因素，还有就是心中有一点想法想回到故土，因为很多时候确实会思念家乡的，所以二者一碰撞，自然给自己顺理成章找了一个理由回来，当然，也可以说是自己无能，这也是没错的！

五、我以为小城市相对来说比较轻松

我并不想把自己的时间都花费在工作上，因为我是一个把生活和工作分得比较清楚的人，现在是这样，以后也是这样！

这边公司是早上9:00晚上5:30，中午休息两小时，所以口头上听着倒是挺舒服，但是当任务压下来，一切美梦都是泡沫。

我来了两三个月了，除了第一个月没加班，后面基本上都加班，周末有时候也来加班，前天晚上还通宵上线了，昨天下午四点过睡醒来，就觉得应该写点什么！

不光是我们公司，我听在这边工作了很久的同事说，大家都差不多这样，所以卷不卷就不用说了。

六、不光是互联网卷，其他的更卷

前天晚上通宵上线的时候，我和几个同事聊天，我说实在干不动了，我准备考公了，他说:“你别想了，我考了那么多次都没上，更别说你连书都没去看过，你拿什么和人家卷！”。

我省内的很多朋友和同学现在都在考公，不过据我所知，基本没几个真的考上了公务员，有些已经毕业很多年，一边上班一边考，有些一毕业就全职考！

不光是考公务员，在贵阳这个地方，做啥工作都卷，用他们的话说，你去当销售，不打满五百个电话你出不来！

没错，小城市的卷是你想不到的，我们常说大城市太卷了，大城市虽然卷，但是机会多，薪酬高一点，而小城市不但机会少，而且薪酬也少，但是人多，特别对于贵阳这种城市，经济比较落后，做生做死三千几真的不是开玩笑的！

七、后悔了吗

我想说，一点也不后悔，虽然之前在成都很轻松，但是那不是我想要的，现在很忙，也累，不过也不是我想要的，那么这不是自相矛盾了吗？其实一点都不矛盾！

我始终觉得，如果你脑子里觉得你这辈子只有靠打工才能赚到钱，那么你将劳累一辈子！

现在打工对于我来说更多是积淀经验，养活自己，我不会迷失自己的，我清楚自己想要过什么生活，做什么样的人，加之我这个人的物质欲望比较低，所以我不会把自己活得很累，而是把钱和时间更多的用在提升自己和丰富自己上面！

八、建议

我想说人各有志，每个人所追求的人生不一样，每个人的欲望不一样，所以无论去一线还是小城市都没有真正的对与错！

首先对于我来说，我上面已经表达过，我对物质的欲望比较低，我是没多大的欲望，但是我很爱钱，我想做其他的事，发展其他的，所以对我来说，去任何一个地方的区别都不是很大，无非钱多点少点！

不过对于刚离开学校的朋友，如果想在职业生涯有所建树，并且家里条件不怎么好的，没啥背景资源的，尽量去一线城市，即使赚不了钱也长长见识，如果可以的话，尽量去互联网企业，别去传统行业，因为对自己的发展会比较不利！

如果一毕业就回到自己的那个小地方，那么就可能一辈子都出不来了，当然，如果有能力在自己的家乡混得风生水起，那么是真的牛逼，不过对于没啥资源背景的，基本上可能性不大！

九、最后

现在这个环境真的很严峻，各个行业都很难，真的很卷，所以无论一线还是十八线都一样，普通人想躺平基本上不可能！

对于我们来说，无论处于什么样的环境，都不要过于依赖它，不要故步自封，一定要保持思想活跃，有居安思危的意识，做好准备，这样才能保证在时代的浪潮中不被拍打得遍体鳞伤！

最后借用一句话：

人生成长最有效的方法，就是无论命运把你抛在任何一个点上，你就地展开做力所能及的事情

背景

大家好~, 我是刚入职场不久的前端小帅，每周分享我的一丢丢想法，希望能够帮助到大家~

众所周知，console在项目开发调试中是不可或缺的，在日常工作中经常会使用到它，但使用多了之后会发现，虽然它足够短小精炼，但耐不住用的多，再加上注释指示，工作量隐约还是不小的（懒惰），因此我对它进行小小的封装，让它用起来更短更方便，分享给大家，希望能够对大家开发有所帮助

优势

• 面向 Vue2


• 拒绝通用的注释打印


• 针对对象值自动序列化


• 支持一行输出 N个变量打印


• 支持输出data变量和局部变量


• 支持限制特定页面输出变量


• 更短的函数名

示例：

data() {

    return {

        joker: 'jym',

        handsomeMan: 'me',

        info: {

            job: {

                name: '专业炒粉'

            }

        }

    }

},

methods: {

    getJoker() {

        const demo = 'test'

        this.$c('joker', 'handsomeMan', 'info', 'info.job.name', { demo }) //输出语句

    }

}

输出结果：

**是的，只需要一行代码！！！ **

是的，只需要一行代码！！！

（如果是原来的console.log打印 光想就已经累了......）

封装

接下来看看是如何封装的吧~

方法名再短点！

// main.js

Vue.prototype.$c = function() {...}

因为要全局使用，因此直接挂载到 Vue 的原型对象上，这样各个组件里都能通过this.$c()进行调用

传参与打印

如何访问对应Vue实例的数据

因为我们需要访问this.xxx, 获取到this指向必不可缺，因此结合this的小知识，封装的函数必须是普通函数而不是箭头函数，这样在vue实例中调用时this.$c时this会指向Vue实例自身，我们就可以访问this下的数据啦~

传参

参数肯定需要支持多个，数组冗余了 ，直接扁平化输入

再结合Vue里是通过this.xxx获取数据，可知我们传入的需要是字符串

可得步骤

• 传入多个待打印的变量名


• 遍历每个变量名


• 通过 this 和 变量名 获取到data里的值


• 判断是否为对象，分别处理


• 打印


• over

// main.js

Vue.prototype.$c = function(...words) {

    words.forEach(word => {

        const val = this[word]

        if (Object.prototype.toString.call(val).slice(8, -1) === 'Object') {

            console.log(`${word} ======> `)

            console.log(JSON.stringify(val, null, 2))

            return

        }

        console.log(`${word} ======> `, val)

        return

    })

}

对于对象类型的变量，通常我们需要获取实时的对象，直接console.log(obj), 但这样获取的obj通常不是准确的值，想要获取实时的值则需要调用console.log(JSON.stringify(obj, null, 2))，通过json字符串化打印实时的值

什么？JSON.stringify后面两个参数是干嘛的？

我TM直接就是一个

参数一 接收 函数或数组，用来转换过滤对象

参数二 接收 数字或字符串，用于指定缩进的空格数或缩进字符串

示例：

const obj = {

    name: 'mach',

    age: 24,

    sex: 1

}

console.log(JSON.stringify(obj, ['name', 'age']))

// {"name":"mach","age":24}



console.log(JSON.stringify(obj, ['name', 'age'], 2))

// {

//   "name": "mach",

//   "age": 24

// }

OK, 这个时候我们进行打印测试一下

//xxx.vue

data() {

    return {

        name: 1,

        age: 2,

        obj: {

            name: 'mach',

            age: 24,

            sex: 1

        }

    }

},

created() {

    this.$c('name', 'age', 'obj')

}

这时候看看效果，注释有了！变量的值也有了！

局部变量

现在能够访问Vue实例的值了，那少不了局部变量。

问题来了，访问Vue实例是应用了this指向，那局部变量该怎么获取到呢？

最核心的肯定获取是局部变量的执行上下文

呃呃呃呃呃 闭包？ eval？ 试了一下貌似都不行

呃呃呃 , 有了，就是你了！

// xxx.vue

methods:{

    getList() {

        const joker = 'you'

    }

}

this.$c({ 'joker': joker })

高端的食材，往往只需要最朴素的烹饪方式~

忙碌了两小时之后，小师傅开始传入对象

直接用对象传变量名和变量值！

// 简写

this.$c({ joker })

瞧瞧 { joker } 同样很短小，非常适合开发，美吱吱~~

于是函数长这样，对局部变量和Vue data里的变量做区分：

• 判断 对象 则是局部变量


• 判断 字符串 则是vue实例数据

Vue.prototype.$c = function(...words) {

    words.forEach(word => {

        if (typeof word === 'string') {

            const val = this[word]

            if (Object.prototype.toString.call(val).slice(8, -1) === 'Object') {

                console.log(`${word} ======> `)

                console.log(JSON.stringify(val, null, 2))

                return

            }

            console.log(`${word} ======> `, val)

            return

        }

        const [name, value] = Object.entries(word)[0]

        if (Object.prototype.toString.call(value).slice(8, -1) === 'Object') {

            console.log(`${name} ======> `)

            console.log(JSON.stringify(value, null, 2))

            return

        }

        console.log(`${name} ======> `, value)

    })

}

使用

// xxx.vue

methods:{

    getList() {

        const joker = 'you'

        this.$c('name', 'age', 'obj', { joker })

    }

}

Perfect ~

指明位置及套个漂亮显眼的框

对了，因为$c的函数是定义在main.js里的，因此控制台打印会显示是出现在main.js里

解决办法就是在壳里加个 this.$options.name,指明调试语句来自哪个组件

再给打印区套个漂亮的壳，便于做区分

Vue.prototype.$c = function(...words) {

    console.log(`来自${this.$options.name}-🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉`) // 新增

    words.forEach(word => {

        if (typeof word === 'string') {

            const val = this[word]

            if (Object.prototype.toString.call(val).slice(8, -1) === 'Object') {

                console.log(`${word} ======> `)

                console.log(JSON.stringify(val, null, 2))

                return

            }

            console.log(`${word} ======> `, val)

            return

        }

        const [name, value] = Object.entries(word)[0]

        if (Object.prototype.toString.call(value).slice(8, -1) === 'Object') {

            console.log(`${name} ======> `)

            console.log(JSON.stringify(value, null, 2))

            return

        }

        console.log(`${name} ======> `, value)

    })

    console.log('🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉')

}

测试打印结果：

圆满结束啦

访问嵌套属性的值

还有嘞 ~ 有人问，刚刚只是访问变量第一层，如果只想访问变量的第n层怎么办？

很简单，核心就是嵌套调用~

const val = this[word]

改成

const val = word.split('.').reduce((pre, cur) => {

    return pre[cur]

}, this)

这个时候通过 xxx.xxxx.xx 就可以访问Vue实例下数据的值啦~

data(){

    return {

        obj: {

            name: 'joker'

            age: 24

        }

    }

}

this.$c('obj.age', 'obj.name')

这里xxx.xxxx.xx和xxx|xxxx|xx 和xxx-xxxx-xx没啥区别，就是做分割罢了，但用.好分辨点贴近开发

解决完Vue实例下数据的嵌套访问，这时候有人会问，访问局部变量的嵌套属性咋办

Emmm 好问题 , 转动我的机灵小脑袋~~~~~ 有了！！！

const obj = {

    accont: {

        xx: {

            id: 11,

            name: 'rich'

        },

        money: 10086

    }

}

const xx = obj.accont.xx   // 新增



// 调用

this.$c({xx})

高端的食材，往往只需要最朴素的烹饪方式 ~

const joker = {

    info: {

        name: 'jym',

        age: 18,

        height: 185

    }

}

const name = joker.info.name

this.$c({ joker }, { name })   

这样纸代码看起来也清晰嘛~ 嗯，针不戳

限制特定页面输出变量

假设我现在只需要path1和path2的页面输出变量，关闭其他页面的输出，咋做嘞~

简简单单，咱已经拿到指向Vue实例的this，可以直接访问当前路由地址和名做一下限制即可

在函数开头加上

Vue.prototype.$c = function(...words) {

    const whitelist = ['path1', 'path2']

    const currentPath = this.$route.path



    if (!whitelist.includes(currentPath)) return

    ......

}

现在就只有path1, path2的页面下的组件可以输出啦，是不是很方便呢？

只有 Vue2 可以这么封装吗？

虽然这个封装的代码是面向 Vue2, 但很显然封装的核心对于Vue是通用的，把this换成组件实例即可，如Vue3里是this(选项式) 或者 getCurrentInstance()(组合式)，至于React，就只能朴素一丢丢喏（你懂得）

代码 没写 我就不贴了

集帅们 也可以把代码打在评论区，供参考借鉴~~

总结

全部代码：

Vue.prototype.$c = function(...words) {

    const whitelist = ['path1', 'path2']

    const currentPath = this.$route.path

    if (!whitelist.includes(currentPath)) return

    

    console.log(`🎉🎉🎉🎉🎉🎉🎉🎉来自-${this.$options.name}-🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉`)

    words.forEach(word => {

        if (typeof word === 'string') {

            const val = word.split('.').reduce((pre, cur) => {

                return pre[cur]

            }, this)

            if (Object.prototype.toString.call(val).slice(8, -1) === 'Object') {

                console.log(`${word} ======> `)

                console.log(JSON.stringify(val, null, 2))

                return

            }

            console.log(`${word} ======> `, val)

            return

        }

        const [name, value] = Object.entries(word)[0]

        if (Object.prototype.toString.call(value).slice(8, -1) === 'Object') {

            console.log(`${name} ======> `)

            console.log(JSON.stringify(value, null, 2))

            return

        }

        console.log(`${name} ======> `, value)

    })

    console.log('🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉🎉')

    console.log('')

}

优势

• 无需通用的注释打印


• 支持限制特定页面输出变量


• 针对对象值自动序列化


• 支持一行输出 N个变量打印


• 支持打印data变量和局部变量


• 更短的函数名

总的来说，这个封装主要是我在项目console烦了，特别是加上注释和对象json序列化，于是这几天蚌埠住了，整了这个封装，总的来说我觉得效果是不错滴，一行顶之前 N 行, 不用加注释，也不需要该死的 JSON.stringify(xx, null, 2)

但是特殊打印就回归正常 console.log 哦, 没必要封装太深入

希望能够帮助到那些和我一样的console党~ （wink）， 觉得有帮助可以点赞关注一下我喔~~~

往期奇思妙想：

《这个前端Api管理方案会更好？》

《这个前端Api管理方案会更好？(二)》

成年人的世界里，要尽量改掉只要如何就能如何这种思维，因为万事没有绝对。但我认为，有些事情，依旧可以摸索出一些规律，或者说给我们一些启发。

早在入职公司之前，我就在思考，要怎样才能实现快速晋升呢？为此我也做了很多努力，比如工作上非常认真，技术成长上非常积极，但这并不代表我能以超常的速度进行晋升。当我工作一年多被现实教育之后，停下来，回头看，会发现一些观念并不正确。所以我想聊聊作为校招程序员（工作经验0-2年的程序员），这期间我观察到的关于晋升与涨薪的秘密。

绩效在分活的时候已经决定

脉脉上经常有人提到这句“你的绩效不是360之后定下来的，而是分活的时候就已经决定了”，看似暗黑，实则真实。

第一种情况是按劳分配。 对于一个开发团队来说，假设有一批校招生入职，你作为领导会怎样分活呢？以我之前的经验举例，我当时在一个大前端部门，支持近千人的大部门的前端开发需求。这种情况下，很难说谁支持的业务更好。因为大家都是随时可以被分配出去的资源，哪个业务发展的好，哪个业务发展的差，其实与你无关。

然而，虽然业务实际的发展与我们无关，但不同业务的工作量是不同的，这一点在分活的时候其实很难评估。就导致部门内可能忙的忙死，闲的闲死。尽管作为大前端部门，可以相互支援，但执行起来并没有那么简单。A业务整体的运转由小a同学负责，那小b同学去支援，就需要重新熟悉上下文，再去参与开发。如果这个需求不大不小，那叫一个新的人进来支援可能反而拖累效率。

所以在每周进度同步的时候，就有人需要加班，但有人不需要。这一点领导心中有数，在评定绩效，评估调薪的时候也会给予倾斜。

在这种情况下，只要你分到了一个忙碌的活，就能享受加班费，和不错的绩效和调薪。所以在企业里也不要羡慕事情少的同学，钱也会少。

还有一种情况就是工作量已知，但是含金量不同。 这种往往让人心里不服气，凭什么好的活领导就是不分给自己？这种我很难评价，但需要思考一下：

1. 我的能力是否已经让团队领导放心，是否建立了充足的信任？ 如果领导不信任我，自然不可能分配高价值的活过来。建立信任也是一个漫长的过程，日久见人心，需要长期的保持高质量产出，并且要让领导了解自己的辛苦付出。


2. 我是否有和领导表达过我想承接更多需求的意愿？ 如果没有，日理万机的领导也很难照顾到每一位同学，因此要主动多沟通。机会是自己争取来的，不要抹不开面子。


3. 团队内的资源是否充足，是否已经到了需要争抢的阶段？ 不可否认，不是每个部门都处于上升期，有些部门发展空间大，需要的人多，有些部门反之。但需要先梳理清楚是不是自己真的就没有问题了。

投机不如专心做事

这一点我只能谈我在字节的感受，因为我知道在腾讯不同部门的年终奖差N倍。但是在字节，给我的个人感受是更平衡。不会因为你在最赚钱的部门，就能拿到相比新业务的超额回报。

这种机制，有效的保护了公司的人才分布，不然最优秀的人才一定会被最赚钱的部门吸干。

所以对于校招程序员来说，与其思考要不要跳去一个当红炸子鸡部门，不如在当前部门好好打磨，好好思考业务价值，做到更好。

当然，也要看业务机会。你的业务是成长期还是瓶颈期，卷不卷？在成长期的业务，你会感受到朝气蓬勃，有非常多事情可以做，涨薪以及前景都很让人满意，也能遇到更多有挑战的机会。但具体处在哪个业务，作为校招生，其实没有这个眼光，完全看运气，投机成功的概率并不大。

接受排队晋升的规则

在目前的环境下，DDDD。不能用以前的眼光来衡量今天的晋升，还想着那么容易，那么迅速。

我知道有很多培训班都在卖类似《大厂P6直通车》之类的课程，给你一个学完立马能晋升大厂P6的幻想。然而，还是擦干口水，醒醒……

按照现在明面上的晋升要求，很多同学早就能达到，但未必给升。晋升名额非常有限，需要一个一个来。

按理说，职级代表的是武功，体现的是你的能力水平。绩效代表的是苦功，是你的实际产出水平。但现在职级越来越两者都要，不仅仅你要能力强，还得产出多。光有技术远远不够，要有足够的业务价值。

抛弃快速晋升的幻想，主动和领导聊，表达意愿，的同时，做好眼下的事情。相信晋升终将会在意料之外的一天发生。

高绩效的秘密

绩效最终是领导评定的，所以想要高绩效，一定要搞清楚领导最在意的点是什么？直接去和领导谈即可，毕竟自己想也未必想得正确，揣摩圣意也很累。

沟通好目标，确定好方向之后，认真去做。及时暴露风险，遇到很难解决的问题带着自己的思考及时申请援助，不要拖到暴雷了才沟通。

当然完成这些，可能依旧是中等绩效。所以在这过程中，需要挖掘出流程上，业务上可以优化的地方，适时抛出新的见解与思考。并且得到的好评等等，都可以冲击更好的绩效。

薪酬与公平

校招程序员在工作头2-3年的工资差异往往是因为进了不同的公司导致的。比如进了大公司，整体起薪就会相对高。但如果想在同一个团队内部，获得超额回报很难。在同一个团队内部的校招程序员，往往是按照同一尺度招聘进来的，人才评估标准也相同。因此就算开出了不同级别的offer差别也不会太大，这和团队预算也有关。

同部门的，工龄3年内都不会拉开过大的差距。所以在部门内如果你获得涨薪，如果职位没有提升，大概率团队内的其他人也会同步或异步一起涨，最终差距依旧不大。

所以如果爱这行，就长期奋斗，让K值更大一点点，着眼于长期获得更大的回报。

努力学习和工作与成长的关系是一个值得去深思的问题。

有趣的是，参加实习的时候，我将手上的工作做完之后去学其他的技术了，因为那时候刚好比较忙，所以领导就直接提了一个箱子过来，然我去研究一下那个硬件怎么对接。

我看了下文档，只提供了两种语言，C++和JavaScript，显然排除了C++，而是使用JavaScript，不过对于写Java的我来说，虽然也玩过两年的JS，但是明显还是不专业。

我将其快速对接完成后，过了几天，又搞了几台硬件过来叫我对接。

显然这次我不想去写好代码再发给前端了，于是直接拉前段代码来和他们一起开发了。

一个后端程序员硬生生去写了前端。

那么这时候，有些人就会说，“哎呀，能者多劳嘛，你看你多么nb，啥都能干，领导就喜欢这种人了”

屁话，这不是能力，这是陷阱。

一

之前看到一个大佬在他的文章中写道，“如果前端和后端都能干的人，那么大概率是前端能力不怎么滴，后端能力也不怎么滴”。

我们排除那种天生就学习能力特别强的人，这种人天生脑子就是好，学啥都很快，而且学得特别好，但是这样的人是很少数的，和我们大多数人是没关的。

就像有一个大佬，后端特别厉害，手写各种中间件都不在话下，起初我以为他是个全才。

知道有一天，他要出一门教程，然后自己连最基本的CSS和HTML都不会写，然后叫别人给他写。

那么，这能说明他不厉害吗？

各行各业，精英大多都是在自己的领域深耕的。

这个世界最不缺的就是各领域的高手。

在职场中，也并不是什么都会就代表领导赏识你，只能证明你这颗螺丝比较灵活，可以往左边扭，也可以往右边扭。

二

在自己擅长的领域去做，把一件事尽可能垂直。

之前和一朋友聊天，他说他干过python，干过java，干过测试，干过开发，干过实施......

反正差不多什么都干过了，但是为什么后面还是啥也没干成？

我们顶多能说他职业经历丰富，但是不能说他职业经验丰富，经历是故事，而经验才是成长。

可见垂直是很重要的，不过执着追求垂直也未必是一件好事，还要看风往那边吹，不然在时代发展的潮流中也会显得无力。

就像前10年左右，PHP可谓是一领Web开发的龙头！

那句“PHP是世界上最好的语言”可谓是一针强心剂。

可是现在看来，PHP已经谈出Web领域了，很多PHP框架早已转型，比如swoole，swoft等，只留下那句“PHP是世界上最好的语言”摇摇欲坠。

可笑的是，之前看到一个群友说，领导叫他去维护一套老系统，而老系统就是PHP写的，于是他去学了好久ThinkPHP框架，但是过了半年，这个项目直接被Java重构了。

真是造化弄人啊！

三

深度学习和浅尝辄止

在我们还没有工作的时候，在学校看着满入眼帘的技术，心中不免有一种冲动，“老子一定要把它全部学完”

于是从表面去看一遍，会一点了，然后马上在自己学习计划上打一个勾。

但是当遇到另外一个新技术的时候，完全又懵了，于是又重复之前的动作。

这看似学了很多，但是实际上啥也没学会。

个人的精力完全是跟不上时代的发展的，十年前左右，随便会一点编程知识，那找工作简直是别人来请的，但是现在不一样了，即使源码看透了，机会也不多。

而如果掌握了核心，那么无论技术再怎么变革，只需要短暂学习就能熟练了。

就像TCP/IP这么多年了，上层建筑依然是靠它。

四

看似努力，实则自我感动！

在我们读书的时候，总有个别同学看似很努力，但是考试就是考不好。

究其本质，他的努力只是一种伪装，可能去图书馆5个小时，刷抖音就用了四个小时，然后发个朋友圈，“又是对自己负责的一天”。

也有不少人天天加班，然后也会发个朋友圈，“今天的努力只是为了迎接明天更好的自己”。

事实如此吗？

看到希望，有目的性的努力才是人间清醒。

如果觉得自己学得很累，工作得很累，但是实际上啥也没学到，啥也没收获，那么这样得努力是毫无意义的。

这个世界欺骗别人很容易，但是欺骗自己很难！

日本最终还是排放了核污水

2023年8月24日，日本最后还是排放了核污水。网上的讨论很多，有说不应该排放的，也有说污染其实不严重，不需要担心的。首先说明，我是反对排放的。不是因为核污水超标，即使没有超标，我也不认为应该排放到海里。

为什么呢，因为这些辐射元素排放到海水中后，会通过食物链富集效应，最终大量的集中到人类身上。即使排放时的指标是安全的，最终，辐射污染富集到人体身上后，迟早要超标的。

关于日本排放核污水的事，我觉得和软件开发过程中的技术债很像。所以今天就蹭个热点，聊一聊项目中的技术债。

软件项目的迭代过程

我记得大学的时候，课本上学的软件迭代还是瀑布流的迭代方式。这个就比较简单，提出一个大项目，然后细化各个功能。架构师拿到十分完善的需求文档后，开始架构设计。然后开发，测试，上线，验收，完成整个项目。在这个过程中，需求是明确的，按照需求去实现就行。

可是后来出现了敏捷开发。老板们一看，这个好呀，敏捷开发，不就是快速开发吗，大大提高开发速度。尤其是互联网公司，讲究的就是一个唯快不破。然后，，，很明显就感觉到，项目中的技术债越来越多了。

原先项目需求明确后，即使开发过程中有需求变化，也都是在代码上线前修改，可以把看到的不合理代码设计给改掉，影响可控。敏捷后，项目需求是逐步迭代上线的，有时候需求间是相互影响的，再加上互联网的人员换的也勤快，需求时间也短，这前后的代码越来越不融洽。

技术债的积累

技术债是怎么积累的呢，其实是项目过程中，为了短期的收益(上线时间)而做出的技术上的妥协(怎么快怎么来)，这些妥协可能会在未来导致更多的工作，或者可能的线上问题。可以看出，技术债务并不总是坏事。有时，为了满足紧迫的市场需求或截止日期，团队可能需要做出一些妥协。关键是要意识到这些妥协，并在适当的时候偿还这些债务。如果需求上线了，就不管对应的技术债了，这个技术债可不就是越来越多吗。

就像文章最开始的日本排放核污水。从当年日本核电站地震出事，日本采用了注水冷却并储存核污水的方案，我们就能意识到，这个核污水一定要处理掉的，不然越堆越多，最后就只能排放出来的。10几年了，日本就没想过要解决核污水，现在说要排放，我觉得吧，这个估计是10几年前就确定的方案了，只是没有往外说，最后就看什么时间排放。最后，我们就这样又一次见证了历史。

重构

技术债不断积累后，会导致新需求越做越慢，bug还多。这个时候，老板就会觉得做这个需求的人不行，做的又慢，bug又多。但是只有做需求的人才知道，真的改不动呀。

所以，当你做一个需求，感觉改不动，或者明明没有改多少代码，但是bug特别多。 那么一定要想一想这个项目是不是存在了很长时间了。如果存在了很长时间了，那么大概率需要解决技术债的时候到了。怎么解决，重构！！

怎么重构，这个话题很大，一两句说不清楚。不过，一旦你成功重构了一个老项目，那么大概率你的技术水平能有一大步的提升。

就像有人说的，一个文明的衰退等于一个新的文明的诞生。

最近有同学离职，让我突然思考一个话题。

之前在腾讯，内部转岗叫做活水，是希望通过内部转岗，盘活团队。让团队保持一定的人员流动性，让个人与团队双向奔赴，满足各自的需要。因此，我们都希望，团队是活水，而不是一潭死水。

为什么团队要保持一定的人员流动性呢？

• “优”胜“劣”汰。这里不是指恶意竞争和卷。而是通过一定的人员流动性，有进有出，从而找到更加适合团队的人。找到跟团队价值观一致的，志同道合的成员。而跟团队匹配度不是很高的人，可以去寻找更加适合自己的团队和岗位，这对于双方都是有好处的。


• 激活团队。当一个团队保持稳定太久，就会有点思想固化，甚至落后了。这时候，需要通过一些新鲜血液，带来不同的思想和经验，来激活团队，这就像鲶鱼一样。

那想要形成一个“活”的团队，需要什么条件呢？

• 薪资待遇要好。首先是基本福利待遇要高于业界平均水平。其次，绩效激励是有想象空间的。如果没有这个条件，那人员流动肯定是入不敷出的，优秀的人都被挖跑了。


• 团队专业。团队在业界有一定的影响力，在某一方面的专业技术和产出保持业界领先。这个条件隐含了一个信息，就是团队所在业务是有挑战的，因为技术产出一般都是依赖于业务的，没有业务实践和验证，是做不出优秀的技术产出的。因此，待遇好、有技术成长、有职业发展空间，这三者是留住人才的主要手段。


• 梯队完整。在有了前面 2 个条件之后，就有了吸引人才的核心资源了。那接下来就需要有一个完整的梯队。因为资源是有限的，团队资源只能分配到有限人手里，根据最经典的 361，待遇和职业发展空间最多只能覆盖 3 成，技术成长再多覆盖 3 成人已经不错了。那剩下的 4 成人怎么办？所以，团队需要有一些相对稳定的人，他们能完成安排的事情，不出错，也不需要他们卷起来。

这是我当前的想法，我想我还需要更多的经验和讨论的。

那我目前的团队是“活”的吗？答案是否定的。

首先，过去一年，公司的招聘被锁了，内部转岗也基本转不动。薪资待遇就更不用说了。整个环境到处都充斥着“躺”的氛围。

其次，团队专业度一般，在金融业务，前端的发挥空间极其有限。我也只能尽自己所能，帮大家寻求一些技术成长的空间，但还是很有限。

最后，梯队还没有完整，还在建设中，不过也是步履维艰。因为前两个条件限制，别说吸引优秀人才了，能不能保住都是个问题。

最近公司开始放开招聘了，但还不是大面积的，不过还是有希望可以给有人员流失的团队补充 hc 的。但比较难受的是，这个 hc 不是过我的手的，哈哈，又有种听天由命的感觉。

这就是我最近的一个随想，那么，你的团队是“活”的吗？

五档尼卡引爆全场

前言

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

来龙去脉

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

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

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

公司现状

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

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

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

裁员情况

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

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

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

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

个人思考

看待裁员

我认为首先是放平心态吧

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

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

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

企业层面

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

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

个人层面

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

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

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

日常准备

做好记录

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

保持学习

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

关注公司

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

保护自己

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

经营关系

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

以前我还有过那种想法：

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

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

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

关于简历

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

再找工作

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

关于空窗期

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

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

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

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

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

关于社保

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

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

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

关于入职

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

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

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

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

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

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

再次强调

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

标题前言

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

须知：

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

进入正题

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




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




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




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

结束啦

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

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

千里之行，始于足下

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

山路崎岖，拥抱自然

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

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

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

山不向我，我向山去

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

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





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

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

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

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

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

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

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

总结

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

做一个自己都喜欢的团队

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

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

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

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

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

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

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

团队成长 > 个人成长

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

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

建团队，招聘 培养 汰换

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

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

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

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

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

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

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

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

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

绩效管理

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

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

不能忘本

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

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

小结

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

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

原则一：乙方来做决策

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


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


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


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

原则二：为甲方护航

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


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


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

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

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


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


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


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


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

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

下面是一些有意思的讨论

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

只说原则一：

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

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

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

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

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

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

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

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

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

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

---

我也来说三个原则

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

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

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

---

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

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

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

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

---

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

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

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

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

---

永远不要接外包

这才是正确的答案

做私活的时间

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

---

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

---

呵呵 我的意见是：

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那我们能做什么呢？

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

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

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

当自己的老板！

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

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

🪂 17 入行

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

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

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

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

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

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

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

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

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

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

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

⚜ 未来我会怎么做

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


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


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


• 跟随趋势走 拥抱变化


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


• 更平和的心态处事


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

概述

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

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

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

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

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

• 
  

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

  
  


• 
  

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

  
  


• 
  

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

  
  


• 
  

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

  
  


• 
  

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

  
  


• 
  

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

  
  

项目经历写几个合适？

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

现在的你应该做什么？

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

小结

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

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

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

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

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

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

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

• 钱没给够


• 受委屈了

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

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

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


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

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

金钱不过老六

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

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

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

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

image

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

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

快乐工作的价值

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

• 免费用餐


• 班车接送


• 股票期权


• 发放IPad


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


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

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

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

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

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

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

管理是控制还是服务

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

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


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


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


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


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


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


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


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


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


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

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

我们冷漠吗

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

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


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


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


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


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


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


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


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


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


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


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


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


• 领导善于夸奖人吗？

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

内心驱动模式

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

恐惧驱动

• 害怕最亲近的人离开？


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


• 害怕失去健康？


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


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


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


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


• 害怕家庭解体？


• 害怕死亡？

责任驱动

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


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


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


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


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


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


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


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


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


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

梦想驱动

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


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


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


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


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


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


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


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


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

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

个人感悟

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

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

时间线

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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


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


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

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

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

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

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


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


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

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

避免被“卡脖子”再发生

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

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

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


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


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


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


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

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

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

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

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

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

• 推出HMS 替代 GMS

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

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

万物互联生态蛋糕

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

小米IoT平台设备接入数据

小米IoT万物互联布局

小米智能汽车

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

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

写在最后

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

面试官提问

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

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


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

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

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

开始表演！

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

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

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

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

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

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

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


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

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

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

• 
  

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

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


• 
  

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

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

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

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


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

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

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

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

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

小结

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

不过道理是真的：

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

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

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

参考文章

• chromium开源源码在线工具


• v8引擎array源码解析


• V8引擎builtin源码解析

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

装系统

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

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

C盘红盘过程

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

@echo off



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



echo. & pause

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

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

C盘救赎

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


• 如果作为服务端

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


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


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


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

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

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

结束

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

写在前面：

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

正文：

校招篇：面试官，你好

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

工作篇：我的前端初体验

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

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

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

生活篇：程序媛的日常

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

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

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

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

最后：

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

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

主题

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

起因

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

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

经过

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

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

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

如何证明

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

回溯

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

分析

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

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

说说业务

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

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

第一点：面试冷知识

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

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

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

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

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

最后一点是软实力

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

最后做一个收尾。

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

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

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

前言

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

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

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

争取获得答辩机会

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

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

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


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


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

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

准备答辩素材

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

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

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

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

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

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

根据素材，编写答辩 PPT

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

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


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


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

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

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

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


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


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

要写答辩稿并加以练习

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

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


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


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

调整答辩心态

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

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


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


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


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

总结

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

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

前言

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

背景

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

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

• alpha


• beta


• rc


• release

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

• 1.0.0 1.0.1 1.1.0


• 1.0.0-beta 1.0.0


• 1.0.0-release 1.0.0


• 1.0.0-alpha 1.0.0-alpha.1


• 1.0.0-alpha 1.0.0-rc.1

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

常见先行版本号标识

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

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

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

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

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

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

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

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

何为语义化版本控制规范

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

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

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

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

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

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

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

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

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


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

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

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

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

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


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


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

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