在日常工作中，尤其是程序员时时刻刻都会与英文打交道，虽然我们尽可能的在互联网和中文书籍中寻找我们需要的信息，但是，有时候总是不尽人意。对待翻译过来的文档或者书本可能有些定义依然无法明确理解，回到它原有的场景中才能明白究竟是什么意思？阅读英文文档应该是我们的基本技能。

本文笔者将会从以下几个方面来分享一个月的时间，笨方法跨越英文障碍的落地方法：

• 遇到的 Bug 百度没有结果怎么办


• 中文翻译文献模棱两可怎么办


• 寻找外文文献的发现过程是什么样的


• 如何解决英文文档中的复杂句子


• 如何结合文档学习语法


• 结合实例带你操作“笨”方法找到适合自己的路

在本文内，笔者想在这儿分享的一点工作体会。在标题中重点引号标注的一个字——“笨”。既然是“笨”方法，就说明我们都很容易理解，很容易上手，很容易操作，很容易见效。

之所以没有说，两天速成，七天见效，因为这些似乎是赤脚医生行走江湖的招数。工作或者学习，还是务实一点比较能走长远。

那么笔者的方法究竟“笨”在哪儿呢？展示几张图就很快明白了。

1. 如果在出差的路上，或者咖啡馆，或者自习室，可以拿出英文资料，或者是需要查看的技术文档，或者需要学习的产品手册。将不能够准确理解的段落、句子、单词摘抄到随身携带的抄写本上，这样便于针对细节深入处理。

（图片来自手机拍摄，不太美观）

上图是笔者曾经在了解 JWT 的涉及到的实现机制的过程中，对于 Auth0 提供的 JWT 指南的阅读过程中留下的笔记。

当再次看到笔记的时候对 JWT-handbook 第 16 页的部分内容就能够了然于心。

那么我们在来看它对应的原始的手册中的内容如下：

（图片来自：jwt-handbook）

通过这种方式，相信一定程度上就能感受到对于英文手册，技术指南的文档也能够看上一看，并获取到一些有意义的信息。

2. 接着上面，如下的内容是笔者对于原文流程图下方的注解的学习过程。

通过剖析一张图和图对应的注解，就能够发现能够很轻松的干掉一篇 122 页技术手册中的其中一页，前前后后可能也不到几分钟的时间，如果基础比较好的情况下，也许几秒钟就解决了无法在各式各样的解读后的博客中看到的原始概念和流程。进而对关键的技术点有更加清晰的认识。

3. 如果在家的情况下，有时候会觉得使用电脑打字的速度要比用手抄本写笔记的速度要快，你就可以像下图这样，在电脑主屏幕上用文本编辑器来记下笔记，用扩展显示器显示 pdf，这样不用切来切去，影响阅读速度。

4. 要说上面是笔者使用的“笨”方法， 那下面就可以说明，它“笨”的程度。笔者大概记下了这么多页的笔记，看完一遍 JWT handbook 和 The OAuth 2.0 Authorization Framework。这个过程大概花了一个月的空闲时间。所以如果你的英语基础更好的话，那就更不用担心了，连一个月的时间都用不了。

曾经多次看到全英文的技术指南，都只能看几句话就放弃，在阅读两篇英文技术文档之后，对于其他的文档来说，都会尝试拿来读一读，而且随着阅读量的增加速度和理解能力都会逐渐增强。

上面分享完了笔者曾经的经历，便能直观的认识到，对于技术人员或者产品经理，应对工作中的英语非要先背诵大量的词汇，并不像想象的那样：买两本厚厚的语法书，啃上半年一年才能够掌握它。

知识点来源于生活和工作，同样它又应用于生活和工作。就像我们的母语汉语一样，从咿呀学语到长篇大论，也并不是长篇大论之前一直在背诵汉字，学习句法。这需要一个过程，但是在这个过程中，随着知识的积累，在积累的过程中一定不耽误成长和认识新的事物。

所以，我们不必恐惧我们遇到的其他语种的文献，它像我们学习汉语一样，只是有一个过程。相对于曾经考试过程中遇到的令人头疼的“完形填空”，“阅读理解”这些，兴许比我们看到的技术文档要更难，因为技术文档对于技术人来说，它所涉及的内容与我们工作的范畴是高度结合的。

如果要学习 Spring Security，那么我们自然不会去看关于发表的“新冠肺炎”的最新文献。随着技术词汇的总结，我们便能够对于相关的技术文档更容易理解，更快速的阅读掌握。因为它首先在行业上就存在一定的专一性，这样就为我们学习圈定了范围。

接下来，从以下几个方面来分享。

遇到的 Bug 百度没有结果怎么办

我们在工作中如果遇到的问题，经常会去百度一些问题，尤其是具体的 IDE 中的一些异常。例如，在 Eclipse 中有如下的错误提示：

MongoDB shell version v3.4.5 connecting to: mongodb://127.0.0.1:27017 2020-0

如果第一次遇见这个问题，无从下手的时候，可能首先会去百度，查找结果，如下：

如果得到的答案，没有我想要的，或者是解决不了我的问题的情况下怎么办呢？

Google

不同的搜索引擎，由于它的搜索机制不一样，自然呈现给我们的检索结果就不一样，所以当无路可走的时候，常常会使用这几种方法综合起来，来搜寻符合需要的方案。

必应

有时候，我们无法访问谷歌的情况下，可以尝试使用必应的国际版。

（图片来自：cn.bing.com）

输入我们之前的问题，得到如下结果：

上面几种检索结果的区别对于我们来说有时候未必不是一件好事，因为它能够展现出更多的推荐方案供我们选择。

Stack Overflow

仔细的从谷歌和必应国际版的检索结果中会发现它得到的结果都有 Stack Overflow 提供的方案。那么 Stack Overflow 是何方神圣呢？可以把它看成是中国的 CSDN、博客园这一类的技术问答网站。

如果无法登陆 Google，而且不习惯于 biying 的搜索引擎的情况下，那么可以直接去 Stack Overflow 查找或者询问你自己的问题。

（图片来自：stackoverflow.com/）

MSDN

如果是微软技术栈的工程师或者是产品经理，可以考虑使用 MSDN。

（图片来自：docs.microsoft.com）

（图片来自：docs.microsoft.com）

在使用 MSDN 的时候有一个优点，就是它支持中文，也支持英文。这样可能能够为我们阅读英文文档提供一个参照。如果英文的版本的确无法看下去的情况下，便可以参考中文的说明。

其他

当然不乏一些其他优秀的网站、论坛，比如日本的 Fresheye、俄罗斯的 Yandex、韩国的 NAVER，如下图：

（图片来自：search.fresheye.com）

（图片来自：yandex.com）

（图片来自：search.naver.com/）

从这也能看出来，尽管我们是学习技术的，或者是产品部门的一个产品专员，但我们一样能够通过我们的努力打开世界上每一扇我们感兴趣的大门。

接下来，说一说文章起始位置的第二个问题。

中文翻译文献模棱两可怎么办

对于这一点，我们引用 DAN OLSEN 的一本书的封面的内容来说明。如图：

（图片来自：THE LEAN PRODUCT PLAYBOOK）

封面上能够得到的信息是：

DAN OLSEN

THE LEAN PRODUCT PLAYBOOK

HOW TO INNOVATE WITH MINIMUM VIABLE PRODUCTS AND RAPID CUSTOMER FEEDBACK

WILEY

其中 DAN OLSEN 是作者、WILEY 是指这本书是由 WILEY 出版的。从领英上的介绍来看，这本书是 DAN OLSEN 是他很得意的一本畅销书。

（图片来自：http://www.linkedin.com）

这也是笔者接触到的第一本专业的关于产品的书。通过它来印证我们遇到模棱两可的解释的时候，该如何处理。

THE LEAN PRODUCT PLAYBOOK

HOW TO INNOVATE WITH MINIMUM VIABLE PRODUCTS AND RAPID CUSTOMER FEEDBACK

WILEY

假设你不知道它的意思的情况下，分别在 Google 翻译和百度翻译上翻译的结果如下：

（图片来自：translate.google.cn）

（图片来自：fanyi.baidu.com）

通过对比就能够知道它的含义就是精益产品手册，对于 PLAYBOOK 的翻译结果稍有不同，如果深究的情况下， 我们可以去看一下 PLAYBOOK 的英文解释。

（图片来自：dictionary.cambridge.org）

（图片来自：http://www.merriam-webster.com）

（图片来自：http://www.oxfordlearnersdictionaries.com）

相信对于你的感到模糊的词汇或者句子，在谷歌、百度、韦氏、剑桥、牛津五家线上词典的围攻下将你的疑问降低到零。

这就是笔者在日常工作和学习中遇到的模棱两可的问题的解决方案。

当时引起笔者注意的是如下这一段话：（引自：THE LEAN PRODUCT PLAYBOOK）

The Lean Product Process will guide you through the critical thinking steps required to achieve product-market fit. In the next chapter, I begin describing the details of the process, but before I do, I want to share an important hight-level concept: seperating problem space from solution space. I have been discussing this concept in my talks for years and am glad to see those terms used more frequently these days.

Any product that you actually build exists in solution space,as do any product designs that you create-such as mockups,wireframes,or prototypes. Solution space includes any product or representation of a product that is used by or intended for use by a customer It is the opposite of a blank slate.When you build a product,you have chosen a specific implementation.Whether you've done so explicitly or not, you've determined how the product looks,what it does,and how it works.

In contrast,there is no product or design that exists in problem space. Instead, problem space is where all the customer needs that you'd like your product to deliver live. You shouldn't interpret the word "needs" too narrowly: Whether it's a customer pain point, a desire, a job to be done, or a user story, it lives in problem space.

如果我是一名产品经理或者产品专员，我想在这里我便应该仔细的去推敲 DAN OLSEN 说的这一句话中包含了些什么信息？

什么是 problem space，什么是 solution space，这两个概念是它的范畴中包含了哪些元素，它们之间有什么关系，它们又是如何促进产品创新的。可以带着这些问题去别的章节中去寻找答案。

另外，这里想要提醒的一点是，在国内我们是可以使用谷歌翻译的，它对应的域名是 translate.google.cn，而不是 translate.google.com，笔者曾经由于一直输入 .com 所以导致困惑了好多天。

寻找外文文献的发现过程是什么样的

白岩松老师在一个《对白》中曾经说过一句这样的话，笔者很赞同。“人找书是很难的，但是书找书是容易的，越读书，越知道该读什么书”。

在工作过程中，我们如果需要找到一个问题的解决方案，可能需要在搜索过程中不断调整检索词，希望能够通过检索词来搜索出自己需要的有价值的内容。

1. 
   

   在工作中，常常为了对项目结构有清晰的认知，需要我们能够画出“软件架构图” ，如果你搜索，“软件架构图”，检索后可以看到几乎第一屏展现出来的有一多半的都是实现软件架构的工具的广告。这往往是一件令人很头疼的事情。

   
   


2. 
   

   调整检索词，改为“software architecture”，在百度中的结果会得到一些相对有用的信息。

   
   

这时候标注出来的 PDF、读书、图文的字样便出现了。

3. 
   

   再次细化检索词，使用“Software Architecture Patterns”。

   
   


4. 
   

   通过查看能够进一步得到某一本书的信息：

   
   

（图片来自：http://www.oreilly.com/library）

这种情况下，就能够对这本书中的部分内容，查看是否是存在自己想要调研的相关内容，而后便能进一步去学习。

5. 如果你需要查看这本书，继续在搜索引擎中搜索，比如“software architecture patterns pdf”，能够看到很多好心人分享出来的书，这种方法往往都比较有效，只要耐心的搜索检索词。

6. 找到后打开对应的文件，浏览目录，这时候看到了它对架构师经常要打交道的”层图“的介绍，这就为我们平时的工作中的画图能够提供参考和建议。

（图片来自：Software Architecture Patterns）

这一部分，基本就介绍了，在我们对于英文文献的寻找过程是怎样的，输入中文检索词，如果中文检索词无法满足要求情况下，可以考虑将中文检索词转换为英文检索词，用转换的英文检索词，一步步优化，结合不同搜索引擎的检索结果去找到符合自己目标的内容。

另外上面的例子中提到的 Software Architecture Patterns 篇幅比较小，也比较适合查看。同时架构图在软件设计过程中又比较重要，我们可以尝试通过这种方式的查找和学习、阅读，逐渐地对于架构图不会敬而远之，不会感觉遥不可及。

有些情况下在某些书中，会对于一些概念在脚注或者引用文献都会进行说明，这样便可以在阅读过程中对于相关的概念，去其他的书中寻找，这就形成了一个书找书的过程，它是实现起来还是比较便捷有价值的。但是在阅读过程中想要提醒的一点是，我们不要过度发散，导致忘记了最初需要解决的问题，导致花费大量的时间，需要解决的问题没有解决。

如何解决英文文档中的复杂句子

在阅读过程中，我们可能会发现长句理解起来相对麻烦一点，这里我们拿上文中提到的 Software Architecture Patterns 的一个段落来解剖：

Each layer in the architecture forms an abstraction around the work that needs to be done to satisfy a particular business request. For example, the presentation layer doesn’t need to know or worry about how to get customer data; it only needs to display that information on a screen in particular format. Similarly, the business layer doesn’t need to be concerned about how to format customer data for display on a screen or even where the customer data is coming from; it only needs to get the data from the persistence layer, perform business logic against the data (e.g., calculate values or aggregate data), and pass that information up to the presentation layer.

文章无非就是通过这种类似的长短句形成的段落堆砌出来的，所以解决了词，解决了句子，自然没什么可怕的。看到这种段落的时候，可以试试去拆分：

将一个段落拆分，按照标点符号拆分成四个部分。再对每一个部分进行分解，再把其中一句单独分离出来。

比如第一句：

只要能够找到句子中的主语、谓语、宾语，基本上就能确定大概的意思。这类比于汉语中实际上，也比较容易理解，“谁”“干了”“什么”。其余的内容只是对这几个元素的修饰和补充说明。

架构中的每一层，形成一个围绕工作的抽象，什么工作？需要被实现用来满足业务需求的工作。

那么上一句就能够基本理解它的意思，架构中的每一层实际上是对于满足特定业务需要的抽象，再简化就是架构图中的层，是对于特定业务的抽象。

回到原文中结合上下文，便能够对第一句进一步理解。

而这时候，如果你不加分析，直接去 Google 翻译或者百度翻译上看它的翻译结果，可能会让你更加迷糊。

从这个结果来看，我们在阅读过程中，所有的工具只能是参考，需要我们结合自己实际情况，不断补充，不断调查，不断积累和完善。

如何结合文档学习语法

从上文中的复杂句子的分解过程中，实际上就能看到语法的影子，如果只是在文档的学习中遇到的问题解决的情况下，如果无法正确理解的时候，从词性、时态、句型、从句等方面去针对性的查找。这儿就不再深入扩展了。

可以查找关于高中、托福、雅思一类的专业英语语法书籍，比如在世界上颇有影响力的 Practical English Usage，它的中译本是《牛津英语用法指南》。

笔者从书中摘抄一段内容，兴许这一小段就会纠正原本的错误认识：

动词形式（”时态“）和时间

动词形式和时间没有直接关系。例如，像 went 这样的动词过去式不但可以表示过去的事情（如 We went to Morocco last January 我们去年 1 月份去了摩洛哥），而且可以表示发生在现在或将来的不真实的或不确定的事情（如 It would be better if we went home how 我们现在回家更好）。动词现在式可以表示将来（如 I'm seeing Peter tomorrow 我明天要见彼得）。另外，进行式和完成式不单单表示时间有关的概念，还可表示动作的持续、完成或目前的重要性。

（摘自：《牛津英语用法指南》）

这就熟悉又陌生的语法，可能从高中毕业后再也没有系统的学习过过于英语语法的内容，但是没关系，只要用到就有机会学习。

结合实例带你操作“笨”方法找到适合自己的路

前面的内容，笔者分享了关于在工作中遇到的问题，查找、分解的方法。总的来说大概几个方面，包括了:

• 搜索


• 翻译


• 找文献


• 分解复杂句子


• 查找语法知识

希望这些能够对你的工作中遇到的头疼的英语问题有所帮助。

下面推荐了相关的文档，你可以使用它，也可以按照前面介绍的方法结合自己遇到的实际问题去寻找对应的文献。

研发的同学可以尝试去读一下，Windows 上 ZIP 版本 Redis 的三个文档：

（图片来自：github.com/）

• Redis on Windows Release Notes


• Redis on Windows


• Windows Service Documentation

产品的同学，笔者目前只发现了上文提到的 DAN OLSEN 的 THE LEAN PRODUCT PLAYBOOK，有好资源的同学可以分享，共同学习。

另外，闲暇时有兴趣的同学可以去浏览、了解日常的消息（国内可访问）

• apnews.com/

（图片来自：apnews.com/）

• http://www.afp.com/afpcom/en/

（图片来自： http://www.afp.com）

• globalnews.ca/

（图片来自：globalnews.ca/）

这次的分享到这儿基本结束了，希望你可以用更快的，更简单的方法，去克服工作中遇到的问题。欢迎共同学习，携手共进。

一家公司的好坏，除去客观情况，更多是个人的主观感受，甲之蜜糖，乙之砒霜，别人口中的“好公司”，未必适合你。

那我们应该怎么挑选一个适合自己的公司呢？还是有一些可以考量的指标的。

• 企业文化和价值观


• 行业势头


• 工资待遇


• 公司规模


• 人才水平

企业文化和价值观

无法适应企业文化和价值观的员工，注定会被边缘化，获取不到资源，直到被淘汰。而适应企业文化和价值观的员工，在公司做事情则更能够得心应手。

如何选择适合自己的企业文化和价值观

如果你打算在一个公司长期发展，可以试着找找里面的熟人，聊聊公司内部的做事风格，比如晋升、奖金、淘汰、组内合作、跨部门合作以及如何处理各种意外情况等，这样就能实际感受到企业的文化和价值观了，然后再根据自己的标准，判断是否适合自己。

行业势头

行业一般会有风口期、黄金发展期和下降期三个阶段。

• 处于下降趋势的行业要慎重考虑。


• 处于风口期的行业发展趋势还不是很明显，如果你之前从事的行业和新的风口相关，那么不妨试试；如果你对这些风口背后的行业不是很熟悉，那不妨等风口的势头明朗了，再做打算。


• 处于黄金发展期的行业发展已经稳定，有成熟的盈利模式，在这样的行业中积累经验，会在行业的发展上升期变得越来越值钱。如果你对这些行业感兴趣，不妨考虑相关的公司。

工资待遇

工资待遇不仅仅包括固定工资，还有一次性收入、奖金、股票以及各种福利等。

很多新入职的员工会有一些的奖金，例如签字费、安家费等，这些是一次性的，有时还会附加”规定时间内不能离职”等约束条件。这部分钱的性价比比较低，但一般金额还不错。

奖金主要看公司，操作空间很大，它和公司的经营状况关联紧密，谈Offer时约定的数额到后面不一定能够兑现，尤其是这两年整个互联网行业都不景气，很多公司的奖金都“打骨折”甚至直接取消了。

其他福利一般包括商业医疗保险、年假、体检、补贴等，它和公司所在行业有关联，具有公司特色。

股票也是待遇中很重要的一部分，很多公司在签Offer时会约定一定数量的股票，但是会分四年左右结清，这需要考虑你能坚持四年吗？四年之后没有股票要怎么办？

公司规模

如果待遇和岗位差不多，建议优先选择头部大公司，这样你可以学到更多的经验，接触更有挑战的业务场景，让自己成长的更快。

如果你看好一个行业，那么需要努力进入这个行业的头部公司。

人才水平

一个公司的人才水平，决定了公司对人才的态度和公司内部合作与管理的风格。

举个例子，如果一个公司里程序员的水平都很一般，那么这个公司就更倾向于不相信员工的技术能力，并制定非常细致和严格的管理规范和流程，避免员工犯错。如果你的水平高，就会被各种管理规范和流程束缚住。同时，如果你发现与你合作的人的水平都很“感人”，你也需要调整自己的风格，让自己的工作成果能够适应公司普遍的水平。

此文章为极客时间3月份Day26学习笔记，内容来自《职场生存

懂点心理学，生活工作两不误～

什么是踢猫效应

某公司董事长为了重整公司事务，许诺自己将早到晚归。有一次，他在家看报太入迷以至于忘记了时间，为了不迟到，他在公路上超速驾驶，结果被警察开了罚单，最后还耽误了时间。这位老董愤怒之极，回到办公室，为了转移他人的注意，他将销售经理叫到办公室训斥了一顿。

销售经理挨训之后，气急败坏地走出办公室，将秘书叫到自己的办公室并对他挑剔一顿。

秘书无言无故被人挑剔，自然是一肚子气，故意找接线员的茬儿。

接线员无可奈何垂头丧气地回到家，对着自己的儿子大发雷霆。

儿子莫名其妙地被父亲痛斥之后，也很恼火，便将自己家里的猫狠狠地踢了一脚。

可怜的猫🥺。

提猫效应指的是坏情绪的传达，并且承受最多最痛的人，是弱小的群体。

其他案例

笔者在工作中也会遇到这样的人：

**主管，因为任务的延期完成或者任务出现问题，并没能完成上面的 OKR。受到经理的警告，然后 TA 会找茬自己手下的人，对其一顿 PUA。有时候，TA 还直接跟经理火拼，美其名曰为公司着想，吵着吵着就哭起来，然后任性连休几天假...

这是一种病态的社会表现。也是个人情绪无法抑制的无良的宣泄渠道。更是一种伤害集体利益和他人利益的一种行为。

当然，现实生活中还有很多这种鲜活的案例，比如：

所谓的专家，建议老百姓城市买房去库存，买车带动经济，再开车回农村耕田。升斗小民们可真是惨啊～

如何应对

1. 认清自己的角色：自己的角色是相对，有时候你是弱者，有时候你是施暴者。我们要正确认识到自己当前所处的角色，尊重善待无辜的人和动物。


2. 情绪管理：人不是神，会有喜怒哀乐愁，适当给自己放松一下，拥抱下大自然，请别压抑情绪，更不能为了释放情绪而转嫁情绪给他人。「亲人最容易受伤」


3. 规范和法律：当自己的权益受到了侵害，需要我们拿起法律的武器。比如，公司无缘无故裁了你，但是又没有给赔偿你，甚至在推荐信上恶意差评你。

参考

• wikipedia 踢猫效应


• 踢猫效应|谁是谁的出气筒<
  
  作者：Jimmy
  来源：juejin.cn/post/7264756009887989812
  /a>

写在前面

好像很久没有更文了，感觉有很多想写的，但却又不知道该写些什么了。。。

近阶段，整个人的状态都好，本计划这月想给自己充电，做一些自己想做的事，结果真的就是事与愿违吧。

好像每个人都一样，都是为了生活而疲于奔命，依然忙碌于各种事情之间。

整个过程

没经过深思熟虑的计划制定

两周前，组内同事想让我帮忙做冒烟测试脚本，原因是因为每次发版测试的时间耗时特别长，所以在结束批量测试工具的开发工作后，我便主动和领导请缨做冒烟测试脚本的开发工作。

和领导说，脚本开发需要5天，整个冒烟测试每次需要大约5分钟！

领导听完很吃惊，我自己说应该差不多吧。

迷之自信？

可能很多同学也会和我的领导一样吃惊，为什么？

系统发版后的回归测试，就测试场景和流程来看，工作量肯定不小，姑且不说技术问题，就业务流程的梳理就很费时间了。

而我却说整个过程只需要五天，可见我是多想证明自己了

其实不然，我自己还是有一些考量的，才说出五天，原因有两个：

• 因为信任，所以备受期待，同事信任我，真的感觉自己被需要，并且想为团队贡献出一份自己的力量；


• 因为之前做过测试环境的性能测试脚本，以为很多接口可以直接拿来就用（我天真了，因为改了不少，需要重做）。

理性永远在给感性收拾烂摊子

整个系统总共6个测试流程，也就是说我每天要完成1.2个流程的脚本开发。

我特别喜欢现在团队的氛围，第一天到下班点时，差一个模块就完成了一个流程。

所以在责任心的驱使下，心想加个班吧，今天能赶出来这个模块，明天其他的流程就能复用了。

一切看似很好，也正是这个模块把我彻底卡住了，我遇到了一个让我很抓狂的问题：

打个类比，比如发起申请接口，申请成功了，到领导审批，点击同意的时候报错，而发起申请这个接口却不报错，你在页面同样的操作，领导同意却是正常好用的。

被问题卡住，心态开始崩盘

这个问题，我反复查了近两天......

这期间我积极的找开发同事帮忙排查问题，并确认是否是我的入参不对导致节点数据不正确。

由于开发同事比较忙，能帮我排查问题的时间有限，所以只有在开发稍微有点时间，才能帮忙排查联调。

也正因为开发同事的尽心尽力帮忙，几次下来，让我感觉离问题根源好像又进了一步。

也知道为什么不能审批了，因为虽然请求成功了，但是没走业务逻辑，导致部分数据还是默认值，所以审批报错。

关于入参的排查，暂时告一段落了，因为数据状态不对，无法进行审批，意味着还是没有解决问题。

到这已经是第三天了，一个流程都没整完，感觉整个人都不好了，心态有点崩了......

于是向领导说明原因，领导了解后，并说先把耗时最长的做完，虽然没那么大压力，但是心里还是有些深深地自责。

我还是没忍住，终于哭了出来......

距离周五晚上发版测试还有两天，这个问题不解决，怎么也说不过去，心里一直憋着这个劲特别难受。

当时的想法，真的是谁能帮帮我，帮帮我行么？

但是我也不知道该找谁帮忙，谁又能帮助我？

为什么？说是业务问题吧？还不算？技术问题吧，入参还查不出来啥问题？真的就是进退两难！

因为开发太忙，实在没时间，暂时也没想到什么好的解决办法，我就先下班回了家。

把车停好后，习惯性地给女友打了电话，那天还是我的生日，再加上那阶段烦心事特别多，说着说着我哭了出来，突然感觉好无助而且很没用，最后彻底哭了出来，为什么就那么难？

我以为我很颓废，今天我才知道，原来我早废了。

因为烦心事特别多，导致整个人都不好了，哭出来后，感觉真的很舒服，而且整个人平和了许多。

没人能教你，只有自己能拯救自己

回到家后，搭建好环境，改用工具进行测试，使用jmeter+fiddler抓包开始，重新调接口来模拟测试，结果居然成功了，真的很意外，难道是我代码写的有问题？

第二天上班，我把自己代码接口调用及入参与昨天做好的jmeter脚本一一对照，发现入参一模一样，这让我产生了怀疑，是我封装的工具类有问题？

我代码走的HTTP协议，而jmeter脚本是HTTPS协议才成功的。

这让我想到，可能我的httpclient需要走HTTPS协议请求会让接口调用后，数据应该会正常显示吧。

有了思路，就开始找httpclient如何进行HTTPS请求的相关文章。

经过一番搜索，找到的重点都是围绕使用ssl和根证书的使用的代码片段，我又对httpclient底层封装进行改造，改造完再次使用封装工具类调用接口，结果还是数据状态不对，我真的彻底绝望了。

于是，我又去找到了强哥（我北京的同事），强哥说你干嘛自己封装，用hutool呀。

我照着强哥的思路，又去照着hutool中的工具类，开始写demo，逐一调用接口，结果竟然成功了，这让我欣喜若狂，真的好用。

于是，我对写好的demo，再次进行封装，也就是hutool中的工具类封装，封装好后，再次使用封装好的工具类调用，结果数据状态又不对了。

我真的服了，这是玩我吗？分开就好使，封装就不行。

有的同学说了，应该是你封装的有问题，那为什么其他模块都好用，就这个模块不行？

后来，我灵机一动，那就都对分开可用这部分代码进行简单封装，保证流程跑通就行，算是退而求其次的解决方法，虽然，它很low，但是能用。

也正因为这个临时解决方案，助力我在周五发版前成功的让同事用上了，一个流程的冒烟测试，跑完这一个流程仅需113秒，比手动回归快了近10倍的时间。

写在最后

整个过程让我记忆深刻，在此特别记录一下，真的是头一次被问题卡的这么难受，那种既生气，又干不掉难题的感觉，太难受了!

你有被难题阻塞，一直无法继续下去的情况吗？

最近老板的老婆在参加一项什么“指尖博物馆”的评选，因此老板每天在群里给我们发链接让我们投票。我们兢兢业业每天一投，甚至还相互提醒，完全把这个当成事业在努力。结果，对面直接不按常理出牌，一夜就刷了300票，我们一早来，发现这个数据，面面相觑：这绝对是刷票了吧！

这就是现在网络投票的现状，可能一开始开启网络刷票的人并没有想到会变成这样。本以为这将是民意的体现，具有公平、公正、透明的特质。而且它不需要场地、设备、人力，更不需要大量资金，极大地节省了人力成本。最重要的是，它能通过网络迅速传播活动信息、扩大影响规模，最后的数据一导出，妥妥一大亮点。

事与愿违，网络投票中的刷票行为，让这原本可以最大体现民意的设置，成了黑灰产牟利的“利器”。“某某评选开始啦，请动动你的手指为我们投上宝贵的一票”“本次评选活动对我们很重要，我们需要您的支持，鞠躬感谢”……每次朋友圈看到这样的话，我都心有戚戚：发了也没用呀，对面可能直接机器刷票了！

网络刷票的两种形式

网络刷票背后有一群分工明确的黑灰产业。所谓黑灰产是指利用计算机、网络等手段，基于各类漏洞，通过恶意程序、木马病毒、网络、电信等形式，以非法盈利为目的规模化、组织化、分工明确的群体组织。

网络刷票形式，主要有人工刷票与机器刷票两种。

人工刷票：就是一些空闲时间多的人士，以帮助参赛选手投票来获得“佣金”为主要工作。这些人多数为兼职投票手，外界称之为投票水军。

**技术刷票：**通过抓包工具分析提交投票时所产生的数据，然后使用脚本程序批量提交数据的刷票方式。

通过分析可以发现，网络刷票黑灰产揽客主要分为三步：第一步，在网上搜索这类评选活动，通过冒充主办方或媒体等方式，拨打参选对象单位公开的办公电话，索要参选者私人联系方式。第二步，抛诱饵强卖。会以“专业低价、保证安全”、“先刷后付”等话术来诱骗参选人交钱刷票，不管参选人是否同意，团伙都会假意进行少量刷票，为下一步诈骗进行铺垫。第三步，威胁+诈骗。即便参选者交了一部分的预付金，诈骗团伙也不会再帮你刷票了。而是以此为要挟不断加价，等到活动快结束时，再以冲击排名为由诈骗一笔。

此外，为了吸引参与者自发的去拉票刷票，商家往往会将投票配合奖励去吸引投票用户。由此经引起“羊毛党”注意，出现组队集团化刷票薅礼品的现象。

如何防止网络刷票

毫无疑问，网络刷票对于发起者（商家）、参与者、投票用户这三方来说，都是会造成损失的。我们需要采取一定的措施来防止黑灰产进行刷票。

比较简单的方式有以下集中：

1. 验证码： 在投票页面中加入验证码功能，通过输入验证码来确认投票者是真实的人类用户，而不是机器人或其他自动程序。这里可以使用顶象的免费验证码，因此就不展开叙述了。

2. IP地址限制： 通过限制相同IP地址的投票次数，可以防止同一IP地址的用户对同一选项进行多次投票。P地址限制可以通过服务器端脚本语言（如PHP、Python等）或者Web服务器（如Apache、Nginx等）来实现。

<?php

// 获取投票者的IP地址

$ip = $_SERVER['REMOTE_ADDR'];



// 设置IP地址的投票次数上限为10次

$vote_limit = 10;



// 判断IP地址的投票次数是否已经超过上限

if(get_votes_count($ip) >= $vote_limit){

    // 如果超过了上限，提示投票失败

    echo "投票失败，您已经超过投票次数限制！";

}else{

    // 如果没有超过上限，进行投票操作

    do_vote();

    // 记录投票记录

    record_vote($ip);

    // 提示投票成功

    echo "投票成功，谢谢您的支持！";

}



// 获取指定IP地址的投票次数

function get_votes_count($ip){

    // 连接数据库

    $conn = mysqli_connect('localhost', 'username', 'password', 'database');

    // 查询指定IP地址的投票次数

    $result = mysqli_query($conn, "SELECT COUNT(*) AS count FROM votes WHERE ip='$ip'");

    // 获取投票次数

    $row = mysqli_fetch_assoc($result);

    $count = $row['count'];

    // 关闭数据库连接

    mysqli_close($conn);

    return $count;

}



// 记录投票记录

function record_vote($ip){

    // 连接数据库

    $conn = mysqli_connect('localhost', 'username', 'password', 'database');

    // 插入投票记录

    mysqli_query($conn, "INSERT INTO votes (ip) VALUES ('$ip')");

    // 关闭数据库连接

    mysqli_close($conn);

}



// 进行投票操作

function do_vote(){

    // TODO：进行投票操作

}

?>

3. Cookie限制： 通过在用户浏览器中设置Cookie，可以限制同一浏览器的用户对同一选项进行多次投票。

<?php

// 获取投票者的Cookie

$cookie_name = "voted";

$voted = isset($_COOKIE[$cookie_name]) ? $_COOKIE[$cookie_name] : 0;



// 设置Cookie的过期时间为1天

$expire_time = time() + 86400;



// 判断投票者是否已经投过票

if($voted){

    // 如果已经投过票，提示投票失败

    echo "投票失败，您已经投过票！";

}else{

    // 如果还没有投票，进行投票操作

    do_vote();

    // 设置投票者的Cookie

    setcookie($cookie_name, 1, $expire_time);

    // 提示投票成功

    echo "投票成功，谢谢您的支持！";

}



// 进行投票操作

function do_vote(){

    // TODO：进行投票操作

}

?>

另外，在用户打开页面时，Cookie已经配置在用户浏览器中了，因为示例代码中的setcookie()函数会在服务器响应中设置Cookie并发送给客户端浏览器，当用户打开页面时，浏览器会检查本地是否存在该网站的Cookie，并将其附加在该请求中一同发送给服务器，以便服务器识别该用户的身份，或者保存一些用户相关的数据。因此，在示例代码中，当用户访问该网站时，Cookie已经生效并配置在用户浏览器中了。

4. 人工审核： 对投票结果进行人工审核，通过人工审核来确认投票者的身份和投票行为的真实性。但是，该方法需要投入较大的人力和时间成本，不适合大规模的投票活动。

结语

在2021年1月8日，国家互联网信息办公室公布《互联网信息服务管理办法（修订草案征求意见稿）》。对互联网信息发布、保存及个人信息安全保护等方面作出规定，并对日益泛滥的刷票、刷量、刷评论及制作虚假账号给出了处罚细则。其中特别第二十五条特提到，任何组织和个人不得以营利为目的或为获取其他非法利益，实施下列行为，扰乱网络秩序：
（一）明知是虚假信息而发布或者有偿提供信息发布服务的；
（二）为他人有偿提供删除、屏蔽、替换、下沉信息服务的；
（三）大量倒卖、注册并提供互联网信息服务账号，被用于违法犯罪的；
（四）从事虚假点击、投票、评价、交易等活动，破坏互联网诚信体系的。

希望在此基础上，网络刷票情况能够得到一定的缓解。<

以上。

努力干活就能赚多点钱

职场中最大的谎言可能是“工作越忙就能赚到更多的钱”。虽然在某些情况下这是真实的，但很多时候这只是一种误解。长时间超负荷工作可能会导致身体和心理健康问题，甚至影响到家庭生活和人际关系。此外，很多公司并不愿意在工作强度过高的员工身上支付额外的报酬，而是更倾向于平衡员工的工作与生活，提高员工的幸福感和满意度。因此，新进职场人士应该认识到，在职场中坚持适度的工作量、良好的工作习惯和优秀的职业素养才是取得成功的重要因素。

我都是为你好

“我都是为你好”可能是一种常见的谎言，在不同情境下被使用。在某些情况下，这可能真诚地表达出对他人的关心和照顾，但在其他情况下，这也可能成为掩盖自己私人动机或者行为错误的借口。因此，在职场和日常生活中，我们需要学会审视这句话所蕴含的背后意图，并判断其是否真实可信。同时，我们也应该秉持着开放、坦诚、尊重和理解的态度，与他人进行良好的沟通和相处，以建立健康、和谐的人际关系。

他做得比你好，向他好好学习

“他做得比你好，向他好好学习”是一句非常有益的建议，可以让人们从成功的经验中汲取营养，不断提高自己的能力和水平。在职场中，人们面对不同的工作任务和挑战，而且每个人的工作方式、思维模式和经验都不同，因此，我们应该善于借鉴他人的优点和长处，吸取别人的经验和教训，不断完善自己的职业素养和技能。然而，这并不意味着要完全依赖和模仿别人，而是应该在合适的时机，根据自身实际情况和需要，加以改进和创新，开拓自己的专业视野和发展空间。

在职场中，有些人可能会通过拍马屁、拉关系等不正当手段来获取自己的利益或者提高自己的地位。然而，这种做法可能会导致负面后果和损失，例如破坏工作团队的合作氛围、损害自己的职业形象和信誉等。因此，我们应该始终保持清醒和冷静的头脑，不受拍马屁等诱惑，专注于自己的工作和职责，努力提高自己的专业水平和职业素养。同时，我们也应该与他人建立良好的人际关系，以合理、公正、透明的方式展示自己的才华和成果，赢得别人的尊重和信任，并在适当的时刻借助他人的力量来实现共同的目标。

公司不怎么赚钱，理解一下，行情好了加工资

如果公司在过去设定了一些目标和承诺，但无法兑现或者没有达到预期的结果，那么这就是一种失信行为。画饼充当推销手段，可能会对员工、客户和利益相关方造成误导和不良影响，并破坏公司的商誉和形象。因此，公司应该根据市场实际情况和自身能力水平，制定合理、可行的计划和策略，避免过于浮夸和虚幻的承诺，注重落实和执行，加强与员工、客户和社会各方的沟通和互动，建立坦诚、透明的企业文化和价值观念。同时，员工也应该保持客观、谨慎、理性的态度，不盲目追求高回报或者虚假宣传，始终以个人职业道德和职责为先，为公司和自

说起来加班，别管什么80后，90后，00后，内心肯定都是非常抵制的，朝九晚六，平衡工作生活，想必是大多数人的梦想。

为什么突然想写一篇这样的文章，这两天确实有几件事情触动了我。

1.同事猝死

曾任职的一家公司，一名同事于4月1日猝死。以前总是看网上那些猝死的案例，感慨加班猝死，不曾想这件事生生的发生在自己身边，这名同事是一名销售，具体猝死缘由（前）公司并没有多谈，但我想一定是和熬夜加班息息相关。

这家公司的加班文化，我深有体会，去年11月初，各个项目组长在工作群先后通知强制要求加班，并不给你机会以及理由请假，反正加班给出的理由就是冲刺冲刺。

当时有同事用dingding和其他同事讨论加班的各种不情愿，聊天记录居然被公司扒出来并认为其散播负面言论，邮件全体对其进行警告，我大为震惊，当然这名同事后来也进入了裁员名单。

警告信发出之后越来越多的同事周末有一天不能来公司办公，其实他们在家根本也没闲着，这时候大老板急了，又发了这样的一封邮件。

（我看到这封邮件的时候，心里的想法就是作为公司的领头人，这格局不是一般的小,仅代表个人意见）

显然这封邮件是给那些不坚持10 10 7的人看的，对于那些不加班的人等待着的自然是优化。就这样还是有些同事继续坚持着10 10 7，在元旦之前大家终于把所有项目全部成功交付，本以为等待着大家的是老板分享喜悦的成果，结果等来的却是3/2的裁员，后来大家想明白了，就是催促着大家感觉把项目做完，裁掉你们。其中有位同事，前一天通宵加完班，第二天就被裁了，那时候整个办公室一片哗然。

2.持续加班住进icu

朋友的同事，据说刚刚升为一名奶爸，每天十点前不曾下班，大家问他为何这么拼，给出的理由是我刚刚生了娃，买了房子，工作一点不敢懈怠，怕惹得领导不高兴随时让我滚蛋。

是啊,谁想加班，谁愿意加班天天守着个破电脑，可是生活让我们不得不加班，不得不向一些不合理的规定屈服。

3.中国电科龙哥

这两天龙哥火遍了各个社交网络，龙哥痛批强制加班员工事情为什么能火，为什么传播速度这么快，我猜测是龙哥一人之言说出了很多打工人的心声，引起网友一片共鸣。

不过央视网的这文字怕是惹得大家一顿p喽。

职场人偶尔加下班，没有任何问题，毕竟工作中肯定会遇到一些紧急事件需要及时处理，作为公司员工，加班赶下进度也是应该的，可是长期被自愿加班就不合时宜了，毕竟身体是革命的本钱，一旦因为长期加班，出现问题就得不偿失了，所以加班文化不可取，尤其是超

如果你接触过公司的面试工作，一定见过很多来自大公司的渣渣。这些人的薪资和职位，比你高出很多，但能力却非常一般。

如果能力属实，我们大可直接把这些大公司的员工打包接收，也免了乱七八糟的面试工作。但可惜的是，水货的概率通常都比较大，新的公司也并不相信他们的能力。尤其是这两年互联网炸了锅，猪飞的日子不再，这种情况就更加多了起来。

反过来说也一样成立，就像是xjjdog在青岛混了这么多年，一旦再杀回北上广，也一样是落的下乘的评价。

除了自身的努力之外，你在上家公司混的差，还与你在组织架构中所处于的位置和组织架构本身有关。

一般公司会有两种组织架构方式：垂直化划分和层级化划分。

1. 垂直划分

垂直划分，多以业务线为模型进行划分。各条业务线共用公司行政资源，相互之间关联不大。

各业务线之间，内部拥有自治权。

如上图所示，公司共有四个业务线。

• 
  

  业务线A，有前端和后端开发。因为成员能力比较强，所以没有测试运维等职位；

  
  


• 
  

  业务线B倡导全栈技能，开发后台前端一体化；

  
  


• 
  

  业务线C的管理能力比较强，仅靠少量自有研发，加上大量的外包，能够完成一次性工作。

  
  


• 
  

  业务线D是传统的互联网方式，专人专岗，缺什么招什么，不提倡内部转岗

  
  

运行模式

1. 
   

   业务线A缺人，缺项目，与业务线BCD无任何关系，不允许借调

   
   


2. 
   

   业务线发展良好，会扩大规模；其他业务线同学想要加入需要经过复杂的流程，相当于重新找工作

   
   


3. 
   

   业务线发展萎靡，会缩减人员，甚至会整体砍掉。优秀者会被打散吸收进其他业务线

   
   

好处

1. 
   

   业务线之间存在竞争关系，团队成员有明确的奋斗目标和危机意识

   
   


2. 
   

   一条业务线管理和产品上的失败，不会影响公司整体运营

   
   


3. 
   

   可以比较容易的形成单向汇报的结构，避免成本巨大且有偏差的多重管理

   
   


4. 
   

   便于复制成功的业务线，或者找准公司的发展重点

   
   

坏处

1. 
   

   对业务线主要分管领导的要求非常高

   
   


2. 
   

   多项技术和产品重复建设，容易造成人员膨胀，成本浪费

   
   


3. 
   

   部门之间隔阂加大，共建、合作困难，与产品化相逆

   
   


4. 
   

   业务线容易过度自治，脱离掌控

   
   


5. 
   

   太激进，大量过渡事宜需要处理

   
   

修订

为了解决上面存在的问题，通常会有一个协调和监管部门，每个业务线，还需要有响应的协调人进行对接。以以往的观察来看，效果并不会太好。因为这样的协调，多陷于人情沟通，不好设计流程规范约束这些参与人的行为。

在公司未摸清发展方向之前，并不推荐此方式的改革。它的本意是通过竞争增加部门的进取心，通过充分授权和自治发挥骨干领导者的作用。但在未有成功案例之前，它的结果变成了：寄希望于拆分成多个小业务线，来解决原大业务线存在的问题。所以依然是处于不太确定的尝试行为。

2. 水平划分

水平划分方式，适合公司有确定的产品，并能够形成持续迭代的团队。

它的主要思想，是要打破“不会做饭的项目经理不是好程序员”的思维，形成专人专业专岗的制度。

这种方式经历了非常多的互联网公司实践，可以说是最节约研发成本，能动性最高的组织方式。主要是因为：

• 
  

  研发各司其职，做好自己的本职工作可以避免任务切换、沟通成本，达到整体最优

  
  


• 
  

  个人单向汇报，组织层级化，小组扁平化。“替领导负责，就是替公司负责”

  
  


• 
  

  任何职位有明确的JD，可替换性高，包括小组领导

  
  

这种方式最大的问题就是，对团队成员的要求都很高。主动性与专业技能都有要求，需要经过严格的面试筛选。

坏处

• 
  

  是否适合项目类公司，存疑

  
  


• 
  

  存在较多技术保障部门，公共需求 下沉容易造成任务积压

  
  


• 
  

  需要对其他部门进行整合，才能发挥更大的价值

  
  

分析

如上图，大体会分为三层。

• 
  

  技术保障，保障公司的底层技术支撑，问题处理和疑难问题解决。小组多但人少，职责分明

  
  


• 
  

  基础业务，公司的旗舰业务团队，需求变更小但任何改动都非常困难。团队人数适中

  
  


• 
  

  项目演化，纯项目，可以是一锤子买卖，也可以是服务升级，属于朝令夕改类需求的聚居地。人数最多

  
  

可以看到项目演化层，多是脏活，有些甚至是尝试性的项目-----这是合理的。

1. 
   

   技术保障和基础业务的技术能力要求高，业务稳定，适合长期在公司发展，发展属性偏技术的人群，流动性小，招聘困难

   
   


2. 
   

   项目演化层，业务多变，项目奖金或者其他回报波动大，人员流动性高，招聘容易

   
   

成功的孵化项目，会蜕变成产品，或者基础业务，并入基础业务分组。

从这种划分可以看出，一个人在公司的命运和发展，在招聘入职的时候就已经确定了。应聘人员可以根据公司的需求进行判断，提前预知自己的倾向。

互联网公司大多数将项目演化层的人员当作炮灰，因为他们招聘容易，团队组件迅速，但也有很多可能获得高额回报，这也是很多人看中的。

3.组合

组合一下垂直划分和层级划分，可以是下面这种效果。

采用层级+垂直方式进行架构。即：首选层级模式，然后在项目演化层采用垂直模式，也叫做业务线，拥有有限的自治权。

为每一个业务线配备一个与下层产品化或者技术保障对接的人员。

绩效方面，上层的需求为下层的实现打分。基础业务和技术保障，为绿色的协调人员打分。他们的利益是一致的。

End

大公司出来的并不一定是精英，小公司出来的也并不一定是渣渣。这取决于他在公司的位置和所从事的内容。核心部门会得到更多的利益，而边缘的尝试性部门只能吃一些残羹剩饭。退去公司的光环，加上平庸的项目经历，竞争力自然就打上一个折扣。

以上，仅限IT行业哦。赵家人不在此列。

前段时间招聘的一位开发，待了两三周，拿到了京东的offer，离职了。在离职的后一天，接到了他新公司的背调电话，几乎每项都给他打了8分。这个分数打的有点虚，单纯只是为了不影响他下家的入职。

离职之前，收到他在飞书上查看电话号码的消息，大概也猜到是在填写背调人信息，但自始至终，他也没打一声招呼，让给个好评。

离职最后一天，办完手续，没跟任何人打一个招呼，不知什么时候就消失了。

当初他刚入职一周时，其实大家都已经看出他在沟通上有很大问题，还想着如何对他有针对性的安排工作和调整，发挥他的长处，避免他的短处。但没想到这么快就离职了。在他提离职时，虽没过多挽留，但给了一些过来人的建议，很明显也听不进去。

站在旁观者的角度来看，他的职业生涯或即将面临到的事几乎能看得清清楚楚，但他有自己的坚持，别人是没办法的。

就着这事，聊聊最近对职场上关于沟通的一些思考：

第一，忌固执己见

职场中最怕遇到的一种人就是固执己见的人。大多数聪明人，在遇到固执己见的人时，基本上都会在三言两语之后停止与其争辩。因为，人一旦在自己的思维层次形成思维闭环，是很难被说服的。

而对于固执己见的人，失去的是新的思维、新的思想、纠错学习的机会，甚至是贵人的相助。试想一下，本来别人好像给你提建议，指出一条更好的路，结果换来的是争辩，是抬杠，聪明人都会敬而远之，然后默默地在旁边看着你掉坑里。

真正牛的人，基本上都是兼听则明，在获得各类信息、建议之后，综合分析，为己所用。

第二，不必说服，尊重就好

站在另外一个方面，如果一件事与己无关，别人有不同的意见，或者这事本身就是别人负责，那么尊重就好，不必强行说服对方，不必表现自己。

曾看到两个都很有想法的人，为一件事争论好几天，谁也无法说服谁。一方想用权力压另一方，另一方也不care，把简单的事情激化，急赤白脸的。

其实争论的核心只是展现形式不同而已，最终只是在争情绪、争控制感、争存在感而已，大可不必。

对于成年人，想说服谁都非常难的。而工作中的事，本身就没有对错，只有优劣，大多数时候试一下就知道了。

有句话说的非常好，“成年人的世界只做筛选，不做教育”。如果说还能做点什么，那就是潜移默化的影响别人而已。

第三，不懂的领域多听少说

如果自己对一个领域不懂，最好少发表意见，多虚心学习、请教即可。任正非辞退写《万言书》的员工的底层逻辑就是这个，不懂，不了解情况，还草率提建议，只是哗众取宠、浪费别人时间。

如果你不懂一个领域，没有丰富的背景知识和基础理论支撑，在与别人沟通的过程中，强行提建议，不仅露怯，还会惹人烦。即便是懂，也需要先听听别人的看法和视角解读。

站在另一个角度，如果一个不懂的人来挑战你的权威，质疑你的决定，笑一笑就好，不必与其争辩。

郭德纲的一段相声说的好：如果你跟火箭专家说，发射火箭得先抱一捆柴，然后用打火机把柴点着，发射火箭。如果火箭专家看你一眼，就算他输。

第四，没事多夸夸别人

在新公司，学到的最牛的一招就是夸人。之前大略知道夸人的效果，但没有太多的去实践。而在新公司，团队中的几个大佬，身体力行的在夸人。

当你完成一件事时，夸“XXX，真牛逼！”，当你解决一个问题时，夸“还得是XXX，不亏是这块的专家”。总之，每当别人有好的表现时，总是伴随着夸赞和正面响应。于是整个团队的氛围就非常好。

这事本身也不需要花费什么成本，就是随口一句话的事，而效果却非常棒。与懂得“人捧人，互相成就彼此，和气生财”的人相处，是一种非常愉悦的体验。

前两天看到一条视频，一位六七岁的小姑娘指派正在玩游戏的父亲去做饭，父亲答应了。她妈妈问：你是怎么做到的？她说：夸他呀。

看看，这么小的小孩儿都深谙的人性，我们很多成人却不懂，或不愿。曾经以为开玩笑很好，现在发现“夸”才是利器，同时一定不要开贬低性的玩笑。

其实，职场中还有很多基本的沟通规则，比如：分清无效沟通并且及时终止谈话、适当示弱、认真倾听，积极反馈、少用反问等等。

当你留意和思考这些成型的规则时，你会发现它们都是基于社会学和心理学的外在呈现。

周末带娃出去玩，回来的时候路过一家新开的水果店买东西，因为是新店，所以店里在搞促销活动。进去后发现一个很糟糕的问题。店员对收银系统不熟悉，排队的人要好几分钟才能结算一个，很多人等着不耐烦就走了。现在客户买东西，在哪里买都是买，体验不好，留不住客户的。

这让我想到前年六月份，公司开第一家实体店的时候，也出现过类似情况。当初做的是让客户通过小程序线下扫码购买，优惠设计得很复杂，服务员虽然做过培训，但很多细节不清楚。当客户支付出现异常情况时，又来回沟通处理。这就让用户很不耐烦。最后虽然看起来店里人多热闹，但实际营收并不高。

这并不是特例，有经验的老板，在正式开店前会有一段时间的试营业，非常低调地开门。等员工都熟悉工作了，才会正式开业。

我们都知道招聘的时候，企业更喜欢招聘有经验的人。为啥？因为经验指的是你不仅知道一个东西，还做到过。你能解决某个问题，解决问题的方法才是经验。

如果你只是第一次做，就算培训过，那也不是经验，只能说你知道某件事。从知道到做到，中间还隔很远，越是复杂系统，越需要花更多时间在这个做到的过程上。就像我们做菜，你按照菜谱做，第一次也大概率做得也不会很好吃。

另外一个原因是，人往往容易高估自己的能力。我们在评估一个项目工作量时就很容易犯这个错误，你要是没经验，很容易把一个复杂需求看得很简单。导致工作量评估不足，这也是导致项目延期很重要的一个原因之一。

说到这里，相信你也知道招聘的背后是找一个能解决他们现有问题的人，这个解决问题的经验才是他们需要的。那如果我们想换工作，我想你应该也知道招聘的关键是”经验“，跟岗位相关的经验都是加分项。在进一步思考，人的时间都是一样的，把时间用哪里，把解决什么问题变成经验，这是我们可以思考的方向之一。比如，你想做一名项目经理。那项目管理经验就是你的加分项。十人的管理、百人的管理，管理的深度不一样，获得经验也是不一样的。

总结一下，今天主要想跟大家表达两个观点：

1、珍惜你的时间，用有限的时间去拥有更多跟工作相关的经验。

2、没有经验就不要太乐观地去做一件事情。反之，在做一件没有做过的事情前，应该找一个无利益关系且有经验的前辈咨询下。

推荐相关阅读： 初学者思维 - 找到解决

夜半惊醒

看了下时间，凌晨4:37，辗转反侧。3.7号大领导告诉我这次10升11没通过，这是我知道晋级失败的第4个夜晚，从震惊到否认，到愤怒，到麻木，再到冷静。我的技术能力、思考深度、攻坚能力明明是小组里突出的一个，但在此次技术职级的晋升上，却名落孙山，落在同组小伙伴之后。技术人员，终究困于技术的窠臼。

工作经历

浑浑噩噩的四年

我毕业就进入鹅厂工作，15年，正是鹅厂大杀四方的一年，至今犹记得当时拿到鹅厂 offer 时的兴奋和同学眼中的艳羡。来了公司后，跟着项目组开始创新项目，一眼望到头的挣不来钱，浑浑噩噩的干了3年，和一起进公司的小伙伴们收入差距越来越大。

好在我的驱力不错，既然挣不到钱，那就好好积累技术能力，提升自己。那段时间，周围没有伙伴，没有对比，没有好的机会，只剩下我一个人慢慢悠悠的学习积累，我以为自己足够努力，没有荒废时间；后来才发现自己其实是井底之蛙，一起入职的小伙伴付出了百倍的努力和数不清的不眠之夜，1年多就已经能 cover 当时的业务了，没过2年就已经提干了。

2018年底，我满怀信心去答辩后台 3.1，没过。我当时还觉得评委装逼，挑刺，后来回头看写的都是s，一点含量都没有。

时来运转

2019年3月，答辩刚结束。部门业务调整，我们被整组划到了一个相对挣钱的业务上，leader 也调整成后台 leader。

新业务还是挣钱，凭着第一个项目积累的技术和项目经验，我得到了新领导的认可，第一年干的轻轻松松就挣到了远远超出之前的收入，和之前累死累活拿温饱线形成鲜明对比，可见大厂里跟对项目是多么的重要。

只是没想到第一年就是巅峰，后面随着贸易战、反垄断，鹅厂形势越来越差，我们业务收入也受到极大影响，人员也越来越冗余。挣的钱少了，分蛋糕的人还多了，可想而知，收入越来越差。

在这里，我成功从8级升到了10级工程师。说起来我们这一届实名惨，第一批毕业要等1年才能晋级，最后一批8升9需要公司范围内通道评审，第一批9升10走BG内评审，第一批10升11走部门内评审，全程试验品，一样没落下。

10升11

去年年底公司晋升改革，10升11评审下放部门，职级和待遇不再挂钩，不仅看重”武功“，还看中”战功“，同时传闻这次晋升名额极少。大领导找我谈话，要不就别去了？我想了想这两年的技术和项目积累，不甘心。

整个中心，就我和同组的小伙伴两个人一起去，我挑的是个一直在做的有技术挑战、持续优化的项目，小伙伴挑的是挣钱的项目。我准备了几个周末，小伙伴临时抱佛脚，结果小伙伴过了，我没过。评委说，我过度设计(优化过头)、没有实战演练容灾。

我和大领导说这个和我预期差太多了，我和小伙伴一起预答辩过，都知道讲的啥，咱是技术评审，我的项目技术含量、架构和挑战明明更好，为啥是我没过？大领导说你是认知偏差，人家讲的确实好。不忿，遂找评委 battle，咱要真按这个说法，能不能对参加评审的项目一致对待，不要双标？且不说我是不是过度设计，凭啥对我的项目就要求容灾演练，对别人的项目就视而不见？评委不语，你的项目对部门价值没产生什么收益和价值。

部门400+人，4个晋升11级名额，大概率是一个中心一个。一个技术评审，糅合了许多超过技术方面的考量，业务挣不挣钱和技术有啥关系？技术好的业务就能挣钱？业务挣钱多的是技术好的原因？

我以前也晋级失败过，但是我认输，因为相对而言，整个BG一起评审，你没过就是你技术差，其他因素影响没有这么大。这次明明是我更有技术深度、更投心思在优化上，却事与愿违。

反思与感悟

反思一下。千头万绪，毛主席说，那是没有抓住主要矛盾。

大的方面上讲：这两年大环境差，公司收入减少，需要降本增效。我要是管理层，也会对内部薪资成本、晋升等要求控制增速；政策制定上，也会将资源更倾斜于现金流业务，控制亏损业务的支出。在这个大的背景下，公司不愿意养“能力强，战功少”的技术骨干了；更愿意养“能力强，战功多”的人员。希望员工把精力都聚焦在业务挣钱上。

部门层面上讲：和公司政策一脉相承。晋升名额少，那紧着挣钱的中心、挣钱的小组、挣钱的个人给。这个意义上讲，职级体系已经不是衡量技术能力的标尺了。你技术能力强，没用。你得是核心，得是领导认可的人。

中心层面上讲：要争取名额，否则怎么团结手底下人干活。而且名额要给业务干活干的最出色的那个人，其他人就往后稍稍。我要是我领导，年前也会劝退我的。毕竟我技术能力虽然强，更多的是问题专家的角色，而不是业务核心。

且预测一下，中心之间肯定进行了各种资源置换。评审估计流于形式。慢说我被挑出来了问题，就是挑不出来问题也得给你薅下来。我就是和小伙伴互换项目去讲，估计还是小伙伴过，到时候评委就该说我“你做这东西有啥难度，我叫个毕业生都能来做”了。此处我想起了一副对联，不太合适，就是很搞笑。“说你行你就行不行也行，说你不行你就不行行也不行”，横批是“不服不行”。

从个人角度讲，付出和收获不成正比，难受吗？那肯定的。但谁让方向一开始就错了呢？这世界不公平的事情多了，不差这一个。

重新出发

综上来说，短期内，不改变发力方向到业务上，后面可以说晋升无望。以前老是觉得自己技术能力强，心高气傲，心思没在业务上，勤于术而懒于道，实在是太过幼稚。做了几年都对很多东西不甚了了。

今后，需要趁着还能拼的时候拼一下，潜心业务。编码和开发只是很小一部分，更要从：

1. 业务大局出发，实时数据驱动，监控、统计一定要完善，要有看板，否则无法衡量。


2. 主动探索业务，给产品经理出主意，一起合力把产品做上去做大，提升对业务的贡献，探索推荐、探索推广渠道等等。产品做不上去，个人也没机会发展。


3. 多做向上管理，和领导、大领导多沟通。做好安排的每一件小事，同时主动汇报，争取重获信任。


4. 主动承担，做一个领导眼里靠谱放心的人。


5. 多思考总结，多拔高提升，不要做表面的勤奋工作，看似没有浪费时间，实则每分每秒都在浪费时间。


6. 多社交，多沟通，多交流，打破技术人员的牢笼。

凡事都有两面性，福兮祸所依，祸兮福所倚。多受挫折、早受挫折不是坏事。

2023，就立个

Hello 我是光影少年。

最近有一些刚毕业的小朋友私信我，说工作贼难找，能不能先去一个软件外包公司先苟着，之后的事情等行情好些了再说。

去外包公司当然没什么不可以，成年人能基于实际做出判断和选择，并承受相应的结果就行。

只是我想补充一些细节，让可能有这个想法的小朋友们对这种公司和岗位有一些大概的了解。

在这里先给部分不太清楚的观众扫个盲，软件开发行业有两种基本的用工方式:

• 作为所服务公司的正式员工，和该公司主体签订劳动合同。


• 作为所服务公司的劳务派遣员工，和所服务公司委托的第三方公司签订劳动合同。简单来说，你和所服务的公司实际上没有什么关系，是那家签合同的第三方公司的员工，只是替这家公司干活而已。这也是俗称的「外包员工」或者「顾问」

劳务派遣这种用工方式已经广泛地存在于许多的行业。事实上，有些公司中，围绕着派遣员工和正式员工之间的差异，存在着一整套完整的「潜规则」。

围绕着这两种不同类型的员工，在日常工作中往往会衍生出的所谓「戴蓝色工牌」和「戴绿色工牌」的区别对待的概念。

「戴绿色工牌」的他们的工资通常较低，没有其他福利待遇，在某些公司甚至被告知他们不能使用专门的员工通道，也不能参与公司组织的一些诸如团建，抽奖等活动。

「戴蓝色工牌」的是正式员工，有权享受所有的福利待遇。同时要想戴上蓝色工牌是很困难的。

在劳务派遣公司招募「戴绿色工牌」的员工时，往往会拿「表现良好者可以戴上蓝色工牌」这种承诺来作为吸引人的筹码，但是绝少有人能够如愿以偿。

表面上看上去，似乎完全不用选，正式员工就是比派遣员工要好。在大多数情况下这没错。不过我还是想介绍一下派遣员工的现状，和你在考虑是否接受这个岗位时可能会忽略的一些实际情况。

在这里，我只介绍狭义上「劳务派遣」所指的群体，

这种类型的岗位员工和一家代理机构（比如最常见的某软，某辉）签订劳动合同，然后这家机构会把他们派遣到客户公司的现场，和客户公司的雇员一起工作。

相对于客户公司，他们就是「劳务派遣」员工。代理机构会定期向客户收钱，然后从中抽成之后，再把「工资」发给员工。比如客户公司为一个岗位支付的成本是2w/月，很可能发到员工手里只有1w/月（随便举例，不代表实际情况）。

作为这种类型的员工，通常会要求定期填写一份工时记录表，来证明为客户工作的时间，然后根据这张表从所在的机构获得报酬。

代理机构的最根本的盈利模式就是赚差价，所以通常客户向机构支付的费用要比机构实际支付给员工的工资高出 50%~100%的情况也并不算少见。

可能有些小伙伴看到这里已经开始生气了。「存在即合理」，在国内，代理机构起码还得负责员工的五险一金等一些其他的基本保障。往往通过代理机构给大型客户工作，比直接去一家朝不保夕的初创公司还是稳定轻松许多，甚至收入也会高上不少——哪怕已经被拿走了一大部分。

当然，如果咱们已经选择接受一个派遣的岗位，你可以通过一些方式了解到客户给你付出的成本，之后不论是和机构谈判，还是更新对自己的定位都有好处。

同工不同酬

首先就要聊最重要的：

关于薪资。

在大多数情况下，在同等工作岗位上，作为一个派遣员工，只看固定薪资的话，单价是更高的。

在我之前的工作岗位上，我的固定时薪是比不上和我同样职级的顾问同学的。

但是，但是，通常能大量使用派遣员工的大型企业，他们的薪资构成不光是固定薪资。往往是：

薪资总包 = 薪资+绩效+其他（各种福利、股票期权等等）

派遣员工往往只有固定薪资，或者一些超时工作的加班补偿。

稳定性

为什么公司宁可支付更高的单价，也要大量使用派遣员工呢？其中一个很重要的因素就是控制固定成本支出。

雇佣一个正式员工，除了薪资总包以外，还需要支付和固定工资匹配的五险一金，其他的各种福利，雇佣一个人付出的成本大概是纸面薪资的1.5倍甚至更高。而且如果公司遇到业务收缩，需要裁撤员工，正式员工也需要支付大量的赔偿金。

如果是派遣员工，那么大可以在项目建设期需要大量人力投入时短期购入大量的人手，在项目上线稳定进入维护期后终止合作，而遣散派遣员工所付出的成本低的可以忽略不计。

所以，如果你对于频繁地更换工作场所有所抵触的话，派遣员工可能对你来说是个很大的挑战。尤其是在有些时段没有什么客户需要，很可能要在代理机构坐冷板凳，甚至被裁撤掉。

工作环境

就像本文开头提到的，有人的地方就有江湖。在有些公司，派遣员工和正式员工之间存在巨大的鸿沟；有些公司中又不是那么明显，但就像一道空气墙，不知道在什么时间就会拦住你的去路。

为了控制成本，在扩张员工规模时的大型企业是十分谨慎的，对待正式员工的招募流程会比派遣员工的进场流程严格的多。高标准，严要求下，如果正式员工的数量还比派遣员工的数量少，那么难免的一些「精英思维」就会开始弥漫。

这是难以避免的，这也是许多在派遣员工岗位的小伙伴反复和我提及的：

一定要端正心态。

在很多你不经意的时候，甚至会有「被抛弃」的感觉。并不是每个客户公司的氛围都那么让人舒服，但这就是正常的，不要太过于纠结这个。

而且派遣员工有一个小小的优势，正式员工通常会因为卷而主动加班，而这种加班在不少地方是无偿的，派遣员工由于是代理机构提供的劳动力，所以通常加班都是有补偿的——毕竟你们的工作就是机构的收益，机构也会争取他们的利益。

长期发展

作为派遣员工，短期收益甚至可以说还不错。进入大型公司的劳务派遣基本不会比去初创企业工作难多少。而且也没有传统大企业对于正式员工所提出的高要求，压死人的KPI之类的影响。

但如果你想从工作中获得的不仅仅只有报酬，更想有一些为日后的履历增光添彩的项目经历的话，派遣员工可能就不是很合适。通常情况下，客户公司总倾向于让派遣员工去做一些相对简单的外围部分工作，核心的部分很难接触到，这没得说。

除非你愿意非常频繁地跳槽来换工作，否则涨薪在派遣员工中也是很困难的，而作为规模公司的正式员工，往往有很成熟的薪资上升机制，也有晋升的机会。

而且业内有一些传言，把进代理机构的经历称之为「弄花简历」，这段经历有可能会对后期想要进入大厂时的筛选过程有一定的影响。

至于说HR招人时所提到的「有转为正式员工的机会」，就像真爱，听过的人多，见过的人少，

国内要闻

香港高校陆续拥抱 ChatGPT，暑期忙于筹备新学期变革

香港众多高校拥抱了 OpenAI 的聊天机器人 ChatGPT。香港科技大学率先引入ChatGPT。6 月 1 日它正式为学生与教职人员提供港科大版 ChatGPT，是香港首所为学生与教职工提供 ChatGPT 的大学。香港中文大学、香港理工大学、香港浸会大学等高校也陆续推出使用 AI 工具的指引，共同希望师生批判性探索和谨慎使用 AI。除了在高等教育掀起热潮，AI 也将进入香港的初中课堂。香港教育局指出，ChatGPT 可以成为有价值的教育工具，但要留意抄袭的伦理问题，并期望所有公立中学尽快规划，于 2023/24 学年在“资讯和通讯科技课程”中安排 10 至 14 小时的 AI 课程教授。（奇客Solidot）

小鹏智驾灵魂人物吴新宙确认离职

小鹏汽车董事长何小鹏发文称，因家庭和多方面的原因，小鹏汽车自动驾驶中心副总裁吴新宙在 2022 年下半年表示要回到美国。在此后 10 个月时间里，小鹏汽车确立全新的工作模式，并在架构和组织上进行了提前优化和迭代。负责 XNGP 项目的李力耘博士将接手自动驾驶团队。

据业内人士透露，吴新宙或将担任英伟达“全球副总裁”这一级别的职位，直接向黄仁勋汇报，“是黄仁勋本人亲自出马，将吴新宙招至麾下。”届时，吴新宙将成为全球知名公司的最高等级华人高管，并继续在芯片等多个方面和小鹏汽车深度合作。（雷锋网）

微信要做“小绿书”？知情人士：小范围内测，优化视频号图文发布及呈现

据网传消息，微信正在灰度测试“小绿书”。从知情人士处了解到，这是一次非常小范围的内测，不是新功能，初衷就是为了更方便视频号创作者发布图文短内容，以及提高用户获得信息的效率。（36氪）

OPPO IoT 事业群负责人李开新离职，电视业务几近裁撤

OPPO IoT 事业群负责人李开新离职，可能导致其电视业务几近裁撤。OPPO IoT 部门最近两年变动不断，一直在探索新的产品线。虽然 OPPO 在 IoT 方面也尝试过其他小品类，但较为稳定的业务还是耳机和可穿戴设备。近期有报道称 OPPO 将裁撤电视业务，但 OPPO 方面表示电视业务目前运营正常。

百度千帆接入 LLaMA2 等 33 个大模型

8 月 2 日，百度智能云宣布千帆大模型平台完成新一轮升级，全面接入LLaMA2全系列、ChatGLM2、RWKV、MPT 等 33 个大模型，成为国内拥有大模型最多的平台，接入的模型经过千帆平台二次性能增强，模型推理成本可降低50%。同时，上线 103 个预置 Prompt 模板，覆盖对话、游戏、编程、写作十余个场景，并发布多款全新插件。

国际要闻

iPhone 14 被用户吐槽电池老化

据报道，不少 iPhone 14 系列机主在社交媒体吐槽，该系列出现了严重的电池老化问题。iPhone 14 系列于 2022 年 9 月上市发售，首批用户持有时间还不到一年。社交网站上不少用户留言反馈称手机电池健康已经低于 90%，最多的跌到 87%。苹果官方对“电池健康”的描述为：包含最大电池容量和峰值性能容量。一般在手机电池正常使用的情况下，完整充电次数达到 500 次，电池健康的最大容量低于 80% 则会影响手机峰值性能，保修期内的 iPhone 可以得到官方保修甚至更换。（IT之家）

消息称 OpenAI 正测试第三代图片生成模型

OpenAI 在去年 4 月推出了第二代 DALL-E“文生图”模型，该模型凭借过硬的实力吸引了业界广泛注意，据外媒表示，OpenAI 日前正在准备下一代 DALL-E AI 模型（DALL-E 3），目前该公司正在进行一系列 Alpha 测试，而部分用户已经提早接触到了该 AI 模型。（财联社）

韩国室温超导团队称论文存在缺陷

韩国一研究团队近日发布论文称实现了室温超导，在引起全球广泛关注的同时，也遭到了质疑。而该研究团队的成员表示，论文存在缺陷，系团队中的一名成员擅自发布，目前团队已要求下架论文。分析师郭明錤认为，常温常压超导体商业化的时程并没有任何能见度，但未来若能够顺利商业化，将对计算器与消费电子领域的产品设计有颠覆性的影响。即便是小如iPhone的行动装置，都能拥有与量子计算机匹敌的运算能力。（财联社）

消息称苹果 Vision Pro 开发者实验室冷清，开发者兴趣不大

苹果公司在 7 月份开始邀请开发者去 Vision Pro 的开发者实验室，这些实验室分布在库比蒂诺、伦敦、慕尼黑、上海、新加坡和东京等城市，但是目前看来，开发者对这些实验室并没有表现出很大的兴趣。据彭博社的 Mark Gurman 报道，这些开发者实验室“参与人数不多，只有少量的开发者”。

AI 打败 AI：谷歌研究团队利用 GPT-4 击败 AI-Guardian 审核系统

8 月 2 日消息，谷歌研究团队正在进行一项实验，他们使用 OpenAI 的 GPT-4 来攻破其他 AI 模型的安全防护措施，该团队目前已经攻破 AI-Guardian 审核系统，并分享了相关技术细节。谷歌 Deep Mind 的研究人员 Nicholas Carlini 在一篇题为“AI-Guardian 的 LLM 辅助开发”的论文中，探讨了使用 GPT-4“设计攻击方法、撰写攻击原理”的方案。据悉，GPT-4 会发出一系列错误的脚本和解释来欺骗 AI-Guardian ，论文中提到，GPT-4 可以让 AI-Guardian 认为“某人拿着枪的照片”是“某人拿着无害苹果的照片”，从而让 AI-Guardian 直接放行相关图片输入源。谷歌研究团队表示，通过 GPT-4 的帮助，他们成功地“破解”了 AI-Guardian 的防御，使该模型的精确值从 98% 的降低到仅 8%。（IT之家）

程序员专区

KubeSphere 3.4.0 发布

致力于打造以 Kubernetes 为内核的云原生分布式操作系统 KubeSphere 3.4.0 发布，该版本带来了值得大家关注的新功能以及增强：扩大对 Kubernetes 的支持范围，最新稳定性支持 1.26；重构告警策略架构，解耦为告警规则与规则组；提升集群别名展示权重，减少原集群名称不可修改导致的管理问题；升级 KubeEdge 组件到 v1.13 等。同时，还进行了多项修复、优化和增强，更进一步完善交互设计，并全面提升了用户体验。

Firefox 116 发布

浏览器 Firefox 116 正式发布，该版本新增加了编辑现有文本注释的可能性、用户可以从操作系统复制任何文件并将其粘贴到 Firefox 中，开发方面，Firefox 现在支持 CSP3 external hashes，添加了对 dirname 属性的支持。具体可查看发布说明：http://www.mozilla.org/en-US/

2017年毕业后，我来到了北京，成为了北漂一族。五年后，我决定回家了。也许是上下班一个多小时的通勤，拥挤的地铁压得我喘不过气；也许是北漂五年依然不能适应干燥得让人难受的气候。北京很大，大得和朋友机会要提前两个小时出门；北京很小，我每天的活动范围就只有公司、出租屋两点一线。今年我觉得是时候该回家乡了。

（在北京大兴机场，天微微亮）

有些工作你一面试就知道是坑

决定回家乡后，我开始更新自己的简历。我想过肯定会被降薪，但是没想到降薪幅度会这么大，成都前端岗位大多都是1w左右，想要双休那就更少了。最开始面试的一些岗位是单休或者大小周，后面考虑了一下最后都放弃了。那时候考虑得很简单，一是我没开始认真找工作，只是海投了几个公司，二是我觉得我找工作这儿时间还比较短，暂时找不到满意的很正常。

辞职后，我的工作还没有着落，于是决定先不找了，出去玩一个月再说。工作了这么久，休息一下不为过吧，于是在短暂休息了一个月后，我又开始认真找工作。

但是，但是没想到成都的就业环境还蛮差的，找工作的第二个月还是没有合适的，当时甚至有点怀疑人生了，难道我做的这个决定是错误的？记得我面试过一家公司，那家公司应该是刚刚成立的，boss上写的员工数是15个，当时我想着，刚成立的公司嘛，工资最开始低点也行，等公司后续发展起来了，升职加薪岂不美滋滋。

面试时，我等了老板快半小时，当时我对这家公司的观感就不太好了。但想着来都来了，总不能浪费走的这一趟。结果，在面试的时候老板开始疯狂diss我的技术不行，会的技能太少，企图用这种话来让我降薪。我是怎么知道他想通过这种方式让我降薪呢，因为最后那老板说“虽然你技术不行，但是我很看好你的学习能力，给你开xxx工资你愿意来吗？”

也是因为这次面试，我在招聘软件上看到那种小公司都不轻易去面试了，简直浪费我时间。

（回家路上骑自行车等红绿灯，我的地铁卡被我甩出去了，好险，但是这张地铁卡最后还是掉了，还是在我刚充值完100后，微笑）

终于，找了大概3个月，终于找到一家还算不错的公司，在一家教育行业的公司做前端。双休，工资虽然有打折，但是在我能接受的范围内。

有些人你一见面就知道是正确的

其实我打算回家乡还有一个重要原因是通过大厂相亲角网恋了一个女孩子，她和我是一个家乡的。我们刚认识的时候几乎每天都在煲电话粥，基本上就是陪伴入眠，哈哈哈哈哈。语言的时候她还会唱歌给我听，偏爱、有可能的夜晚......都好好听，声音软绵绵的。认识一个月后，我们回了一趟成都和她面基。一路上很紧张，面基的时候也很害怕自己有哪里做得不好的地方，害怕给她留下不好的印象。我们面基之后一个月左右就在一起啦。有些人真的是你一见面就知道她是正确的那个人，一见面心里有一个声音告诉你“嗯，就是她了！”。万幸，我遇到了。

说一些我们在一起后的甜蜜瞬间吧

打语言电话的时候，听着对方的呼吸声入睡；

走在路上的时候，我牵她的手，她会很顺其自然地与我十指相扣；

在一起吃饭的时候，她会把自己最好吃的一半分享给我；

总结

回到正题，北漂五年。我回家了，后悔吗？不后悔。离开北京快一年了，有时候还是会想念自己还呆在北京的不足10平米的小出租屋里的生活，又恍惚“噢，我已经回四川了啊”。北漂五年，我还是很感激那段时间，让刚毕业的我迅速成长成可以在工作上独当一面的合格的程序员，让我能有拿着不菲的收入，有一定的积蓄，有底气重新选择；感谢大厂相亲角，让我遇见我的女朋友，让我不再是单身狗。

五档尼卡引爆全场

前言

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

来龙去脉

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

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

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

公司现状

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

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

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

裁员情况

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

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

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

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

个人思考

看待裁员

我认为首先是放平心态吧

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

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

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

企业层面

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

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

个人层面

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

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

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

日常准备

做好记录

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

保持学习

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

关注公司

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

保护自己

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

经营关系

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

以前我还有过那种想法：

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

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

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

关于简历

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

再找工作

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

关于空窗期

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

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

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

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

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

关于社保

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

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

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

关于入职

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

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

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

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

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

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

再次强调

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

全文4300字，整体目录如下

作者简介:持续探索副业的大厂奶爸程序员 2020年,华科硕士毕业，非科班转行成程序员 2022年,进入某互联网大厂，打工搬砖 2023年,开始探索副业，目前主攻IP+工具开发

正文开始

一位朋友转载我的故事到公众号后，突然就让意识到

现在29岁的我

往回看6年，我刚进入华科读硕士

往后看6年，我将面临网上所说的35岁中年危机

因此，借此机会，聊下我对未来的思考和回顾下简单过去的6年

未来6年-战略上乐观，战术上悲观

看待未来，我需要保持乐观，只有这样，才能不为未来的不确定而过分焦虑

还是学生时代的时候，因为对这程序员这行业不清楚，当时就很害怕网上常说的35岁的失业危机，为此还在网上查了各种各样的信息，整天忐忑不已。

可真正进入了这个行业以后，才发现危机远没有想象中的恐怖，原来，恐惧真的源于对未知的不确定。

身边也有好些35以上的朋友，他们有的还在程序员这行，有的已经转行了。虽然整体来看，薪酬水平或者薪酬增长速度不如之前，但远没有到达山穷水尽的地步。

即使是现在ai时代的到来，我依然相信，只要程序员去积极的拥抱ai,使用ai去做更多创造性的工作，也不会突然就失业。

但同时，如果35岁的我，还是会被失业危机所困的话，那么一定就是平常的日子太过懈怠，处于温水煮青蛙的状态。

22年刚入大厂的半年里，基本就处于这个状态，除了工作外，剩下的时间基本都用来娱乐了，成长很是有限。

因此，我需要在战术上保持悲观，要不断成长，要确保自己将主要精力放下以下三方面的事情

1、做好主业，保持市场竞争力，被裁/失业时，能快速找到工作

2、开展第二曲线，降低未来失业可能带来的现金流锻炼的风险

3、爱护好自己的身体，照顾好家人，帮助朋友。

先来聊下第二点和第三点吧，第一点在文末聊。

未来6年-做好第二曲线

为什么开展

2022年过年期间，开始意识到现在的看似高薪工作并不稳定，需要在工作外，建立第二曲线（也就是副业），降低未来的风险。

原因有二，内心的渴望+外在的环境

内在的渴望就是，其实自己一直是一个很爱好学习的人，也希望做出点成绩获得外界认可的人。

在3月之前，也一直在保持学习，科学习的那点热情基本全用在了阅读各种书籍以及得到上，看了几十本书，学了好几本课程，可是成长却极为有限。

幸而在3月的时候遇见了生财有术，看见了更多的可能性，也提升了很多认知，因而，内在的渴望进一步扩大。

外在的环境，一方面是工作的不确定性，另一方面，是身上责任的加重。

自动20年当程序员以来，身边的朋友一茬接一茬的换，有的突然就被迫失业了，有的就跳槽了，有些朋友，甚至都没来得及告别，就已经后会无期了。

再加上网上的铺天盖地的悲观主义和程序员危机。想开展副业，抵抗未来的不确定的决心越来越强。 目前还没房贷车贷，这里的加重倒不是说现金流上的压力加重

只是觉得，作为一个父亲，应该为孩子去铺一条更好的道路，不希望等到我孩子需要我支持帮助的时候，我却面临中年危机。

同时，我也希望孩子从我这里获得更多的认知和经验，而仅仅只继续专注于程序员的话，这个希望是有点难以实现的。（因为我个人觉得，程序员这行，距离真实的商业事件挺远的）

这几个月的效果

到目前为止，从2023年3月算起，差不多开展5个月了，在金钱上的收获很少，累计也没超过500吧。

先后做过

1、小程序（做了2款小程序，但都是学习阶段的程序，未盈利）

2、小红书无货源店铺（赚了200多吧，其实还是朋友的支持）

3、公众号流量主（赚了没超过50吧）

说下后2个没赚大钱的最大原因吧：我有个很大的毛病，就是爱学习，但不注重学习的结果，在实际执行过程中，碰到点问题就会泄气。

同时，过分在意做事的时间成本，导致执行力不够。（后2个项目，其实只要投入时间认真去做，都不只赚我这点钱。）

不过虽然金钱上的收获不多，在技能、认知和人脉上还是提升了很多

人脉上，认识了好些其他行业的朋友，各行各业的都有。 认知上，知道了要多输出表达、要有流量意识、要懂得链接他人 技能上，也是突破了后端能力，会了一点vue app，小程序搭建能力。

当然，最重要的是，这个过程极大的提高了我对未来的信心

因为我知道，只要认真专注的执行某一个赚钱的领域，我就能一定能赚到一点钱。

不再是之前那种担心如果失业了，就前途一片阴暗的感觉了。

对接下来的思考

接下来的6年，为了发展好第二曲线。我需要做以下的事情:

1、需要克服执行力差、技术傲慢、纸上谈兵等一系列的问题，去扎实的投入实战中。

2、在过程中，尽早找到适合自己的长期事业，并专注的投入（我希望在30岁以前能够找到。）

3、相信积累的力量，不断坚持。

6年以后的我，一定能够发展好自己的第二曲线。

未来6年-爱护自己,照顾家人,帮助朋友

从6年后的视角看，其实最重要的是这三件事，爱护好自己，照顾好家人，帮助好朋友

爱护自己

健康是一切的起点，没有健康的话，其他所有的都是白搭。

现在的身体状况应该是挺糟糕的，肥胖而且不运动，6年后最容易出现的问题，应该就是肥胖带来的问题了。

也因此

1、需要有意识的去控制自己的体重，定期体检，适当运动。

2、平常养好身体，工作上不要太用力，压力不要太大。

照顾家人

6年后，孩子就到了上小学的年纪了。父母也都65左右了，这么看的话，主要是父母的健康问题需要考虑。

也因此

1、已经给父母买了医疗险，但还没给岳父母买，需要2023年落实

2、每年带父母/岳父母 体检。

帮助朋友

志同道合的朋友，于我来说，是不可或缺的，也是能极大的提升幸福感的。

也因此

1、积极拓展志同道合的朋友

2、维护好现有的朋友，真诚利他。

（最近建了个程序员副业群，欢迎私聊加入）

好，接下里回顾下过去的6年

过去6年-转行当程序员

为什么转行

我来自湖南农村，家里挺穷，是那种穷到连上大学学费都要借的那种。

2012-2016年在华科读本科，在校就是天天混日子，大四想考华科电气没考上，毕业时连份工作都没有，于是决定二战考研。考完研后，在湖南省长沙市新东方做了八年的小学奥数老师，保底薪资5k，钱少事多的一份工作。

2017年秋，以笔试和面试都是专业第一的成绩，顺利成为一位硕士。

在2017年开始读硕士时，实验室的师兄就丢给我一本《21天精通Java》，说：“你先学习这个哈，后面做实验会用到”。也因此，开始接触Java。（事实，我到现在都没有精通Java ）

2018年，实验室接了头部水电企业的一个项目，需要给他们做一个系统，我就参与进来了，然后，还去这个头部企业公司内部实习了半年。

在那里工作，我看到那些公司的员工有的40 50岁了，每天都是在办公室上来了又走，每天的工作都规律的不行，中午午休2个半小时，下午5点半准时下班。有事没事去打个乒乓球，跑个步什么的。

那时候还年轻啊，也没有足够的经验认知，就觉得，这样安逸的生活，一眼看到头的生活，完全不是我想要的。我还年轻，还有大好年华，我要去闯荡，去见识更多的可能性，去看更多的世界。（事实证明，随便在哪工作，你都可以去看大千事件）

于是，从2018年开始就开始坚定的要转行。

转行成功的因素

现在看，非科班转行成功主要有3个因素：

一是学历给了我很大的加成。我是985本硕，在2020年的就业市场上，还是有很大竞争优势的。

二是实验室恰好有一两个项目和IT搭边。现在好多转行的人，做的项目基本都是往上那种通用的项目，这种项目，要是深耕下去的话，确实也能收获很多。但一般转行的人，但研究的比较浅，也因此，在项目上没有多少竞争优势。

三是我自己也还算刻苦。记得当时，经常一两点在那看《深入理解Java虚拟机》、《Java并发编程》等。花了3个月一页页的看完了《算法.第4版》。甚至还花了2个月恶补了计算机基础。同时，也在CSDN上输出自己的学习记录

最后，也是2020年的顺利的校招毕业，拿到当时挺高年薪的offer，进入了北京某头部地产当Java工程师

这是我当时的面试经历 app.yinxiang.com/fx/fc7e01fa…

过去6年- 跳槽到大厂的经历

想跳槽的原因

2020年7月进入公司，从2021年下半年开始，很明显的感觉整个部门的业务动荡。

再加上身边的人一个个的被裁了，虽然说我是校招+管培生，裁员短期内不会落到我头上，但我知道，这一天迟早会到来。

（后来也表明，22年开始，公司开始裁我们这些校招生了。）

当然，还有另外一个很重要的因素，当初和夫人异地恋，我们相约在深圳见面。

关于我在这家公司的情况，请见这个链接：北京，再见。下一站，深圳

跳槽的过程

我这个人脑子比较笨，技术底子也差。但肯下苦功夫 。

从2022年9月开始，以极客时间为主要学习渠道，开始疯狂的学习。主要学习的就是和八股文相关的课程。（记得那时候，身边的朋友都说，你是真的能学的进去阿，也有好几个朋友，被我卷的也开始看书学习了）。

从2021年12月开始，知道要为2022年的3月的黄金跳槽期做准备了。于是给自己列了个学习计划，并差不多严格执行了。

从21年12月开始，知道要为22年的3月的黄金跳槽期做准备了。于是给自己列了个学习计划，并差不多严格执行了。

与此同时，我发现思维导图很适合做这种八股文的笔记和辅助记忆，于是就在ProcessOn上持续记录学习笔记。（后来还将笔记分享给你100+朋友）

刘卡卡 | ProcessOn

一个人学习的道路总是艰辛的，经常感觉坚持不下去，感觉很孤独，没人交流。幸好在1月进入了知识星球代码随想录，里面都是为了找到好工作而奋斗的人，大家一起交流探讨，互相打卡监督，整个人的学习劲头也开始上来了。

也是在2022年3月底，面了差不多10家公司后，如愿以偿的拿到了现在的深圳大厂的工作。

过去6年- 大厂一年多以来的感想

2022年4月，成功进入大厂 。

前面3-4个月的时候，真的很累，一来是不并不适应大厂的自己干自己活的氛围，二来也是技术上也还待欠缺，三是业务复杂度很高，四是每天要应对Oncall处理。

但干了半年左右后，也就开始适应了。（人果然是一种适应性的动物。）

现在的我，在大厂内，就是当一名勤勤恳恳的螺丝钉，

同时在心态上，也有了很大的转变。

1、接受自己不爱竞争的性格，只要自己心里不卷的话，其他人也就卷不到我。

2、将工作看的很清晰，工作就是为了挣钱，因此，如果工作上有什么不如意的地方，切莫影响到自己的生活，不值当。

当然，工作中也不能躺平，要在日常的工作中去多做积累经验，沉淀知识，保持市场竞争力。

好了，洋洋洒洒写了4000多字了，就先到这吧，希望6年后的我，看到这篇文章的时候，能说一句：

你真的做到了，谢谢你这6年的努力

简述

近年来，机缘巧合之下接触了不少toG类项目。项目上颇多事情，令人疑惑频频。然而屡次沟通，却都不了了之，长此以往，心力愈发交瘁，终究心灰意冷，再无劝谏之心。

令人困惑的项目经理

孟子说天时不如地利，地利不如人和。而项目上遇到的很多事情，天时、地利终为少数，多数在人和。

立项开工，项目经理自然是项目上的第一把手。既为第一把手，自要有调兵遣将，排兵布阵的能耐。

当然用我们业内的话来说，可分为下面几类：

第一等的自然是懂业务又懂技术，这样的项目经理可运筹帷幄之中，决胜千里之外，当然这般的项目经理可遇而不可求。

这第二等的懂业务不懂技术，或者懂技术不懂业务，这样的项目经理，辅以数名参将，只要不瞎指挥，也可稳扎稳打，有功无过。

第三等的项目经理，业务与技术皆是不懂，如这般的项目经理，若尽职尽责，配先锋、军师、参将、辎重，最好再辅之以亲信，也可功成身退。若其是领导亲信，那更可说是有惊无险了。

而这第四等的，业务与技术不懂也就罢了，既无调兵遣将之才，又无同甘共苦之心，更是贻误战机，上下推诿。若其独断专横，那便是孔明在世也捧不起来。

有这般一个项目，公司未设需求经理，常以项目经理沟通需求。工期八月，立项后，多次催促，却不与甲方沟通，以至硬生生拖了两月之后才去。然而不通业务，不明技术。甲方被生耗两个月才沟通需求，这样的情况下，如何能顺利进行，以至于项目返工现象，比比皆是。多次提及需求管理，亦是左耳进右耳出。类类数落问题，甲方、研发、产品都有问题，独独他自身若皎皎之明月，灿灿之莲花。然而纵是项目成员承星履草，夜以继日，交付一版之后。举目皆是项目经理之间的恭维之词。

我有很多朋友是优秀的项目经理。言必行，行必果。沟通起来非常愉悦。偶尔遇到一个这样的人，确实让我大开眼界。

其实我也想过，这并非是项目经理职位的问题，实在是个别人自身的问题，这样的人，在任何岗位都是令人恼火的。

技术人员的无力感

我们互联网从业者经常听到一个词，技术债。技术债是令人难受的，尤其是在做项目的时候。做产品，我们可以制定完善的迭代周期，而项目，当需求都无法把控的时候，那么就意味着一切都是可变的。

糟糕的事情是，我遇到了这样的项目。前期无法明确的需求，项目期间，子虚乌有的需求管理，项目中不断的需求变更，deadline的不断临近，最终造就了代码的无法维护。

我从未想过，在同一个紧迫的时间阶段，让研发进行需求研发、bug修复、代码解耦，仿佛每一件事情都很重要。当然，我更建议提桶跑路，这样的项目管理，完全是忽视客观现实的主观意识。

前端规范难落地

公司是有前端规范的，然而前端规范的落地却很糟糕。如果使用TS，那么对于诸多时间紧，任务重，且只有一名前端开发人员的项目来说，显得太过冗余了。所以依旧使用js，那么代码中单个性化不会少见。使用esLint怎么样呢？这当然很棒，直到你发现大部分成员直接将esLint的检查注释了。或许还可以依靠团队内不断的宣讲与code Review，这是个好主意，然而你会发现，公司的code Review也是那么形式化的过程。

或许对一些企业来说，代码的规范性不重要，所谓的技术类的东西都显得没那么重要。只有政府将钱塞到它的口袋里这件事，很重要。

崩盘的时间管理

那么，因为各方面的原因，项目不可避免的走向了失控。时间管理的崩溃，项目自然开始了不断的延期。在私下里，一些擅长酒桌文化的甲方与项目经理，开始了酒桌上的攀谈，推杯换盏之间，开始了走形式的探讨。灯红酒绿之间，公司又开始了例行的恭维。

当然，我依旧无法理解，即使管理的如此糟糕，只要在酒桌上称兄道弟，那便什么问题都没有了？若是如此，项目经理面试的第一道题，一定是酒量如何了。

引言

最近有几天没写技术文章了，因为最近我也遇到了前端职业的迷茫，于是我静下来，回想了下这几年来在工作上处理问题的方式，整理了下思路 ，写了这一片文章。

关于对前端职业的迷茫，如何摆脱或者说衰减，我觉得最重要的是得找到一个自己愿意持续学习、有领域知识积累的细分方向。工作了3-5年的同学应该需要回答这样一个问题，自己的技术领域是什么？前端工程化、nodejs、数据可视化、互动、搭建、多媒体？如果确定了自己的技术领域，前端的迷茫感和方向感应该会衰弱很多。关于技术领域的学习可以参照 前端开发如何给自己定位？初级？中级？高级！这篇，来确定自己的技术领域。

前端职业是最容易接触到业务，对于业务的要求，都有很大的业务压力，但公司对我们的要求是除了业务还要体现技术价值，这就需要我们做事情之前有充分的思考。在评估一个项目的时候，要想清楚3个问题：业务的目标是什么、技术团队的策略是什么，我们作为前端在里面的价值是什么。如果3个问题都想明白了，前后的衔接也对了，这事情才靠谱。

我们将从业务目标、技术团队策略和前端在其中的价值等方面进行分析。和大家一起逐渐走出迷茫区。

业务目标

前端开发的最终目标是为用户提供良好的使用体验，并支持实现业务目标。然而，在不同的项目和公司中，业务目标可能存在差异。有些项目注重界面的美观和交互性，有些项目追求高性能和响应速度。因此，作为前端开发者，我们需要了解业务的具体需求，并确保我们的工作能够满足这些目标。

举例来说，假设我们正在开发一个电商网站，该网站的业务目标是提高用户购买商品的转化率。作为前端开发者，我们可以通过改善页面加载速度、优化用户界面和提高网站的易用性来实现这一目标。

1. 改善页面加载速度： 使用懒加载（lazy loading）来延迟加载图片和其他页面元素，而不是一次性加载所有内容。

htmlCopy Code

<img src="placeholder.jpg" data-src="image.jpg" class="lazyload">

javascriptCopy Code

document.addEventListener("DOMContentLoaded", function() {

  var lazyloadImages = document.querySelectorAll(".lazyload");

  

  function lazyLoad() {

    lazyloadImages.forEach(function(img) {

      if (img.getBoundingClientRect().top <= window.innerHeight && img.getBoundingClientRect().bottom >= 0 && getComputedStyle(img).display !== "none") {

        img.src = img.dataset.src;

        img.classList.remove("lazyload");

      }

    });

  }



  lazyLoad();



  window.addEventListener("scroll", lazyLoad);

  window.addEventListener("resize", lazyLoad);

});

2. 优化用户界面： 使用响应式设计确保网站在不同设备上都有良好的显示效果。

htmlCopy Code

<meta name="viewport" content="width=device-width, initial-scale=1.0">

cssCopy Code

@media (max-width: 768px) {

  /* 适应小屏幕设备的样式 */

}



@media (min-width: 769px) and (max-width: 1200px) {

  /* 适应中等屏幕设备的样式 */

}



@media (min-width: 1201px) {

  /* 适应大屏幕设备的样式 */

}

3. 提高网站易用性： 添加搜索功能和筛选功能，使用户能够快速找到他们想要购买的商品。

htmlCopy Code

<form>

  <input type="text" name="search" placeholder="搜索商品">

  <button type="submit">搜索</button>

</form>



<select name="filter">

  <option value="">全部</option>

  <option value="category1">分类1</option>

  <option value="category2">分类2</option>

  <option value="category3">分类3</option>

</select>

javascriptCopy Code

document.querySelector("form").addEventListener("submit", function(e) {

  e.preventDefault();

  var searchQuery = document.querySelector("input[name='search']").value;

  // 处理搜索逻辑

});



document.querySelector("select[name='filter']").addEventListener("change", function() {

  var filterValue = this.value;

  // 根据筛选条件进行处理

});

协助技术团队制定策略

为了应对前端开发中的挑战，协助技术团队需要制定相应的策略。这些策略可以包括技术选型、代码规范、测试流程等方面。通过制定清晰的策略，团队成员可以更好地协作，并在面对困难时有一个明确的方向。

举例来说，我们的团队决定采用React作为主要的前端框架，因为它提供了组件化开发和虚拟DOM的优势，能够提高页面性能和开发效率。同时，我们制定了一套严格的代码规范，包括命名规范、文件组织方式等，以确保代码的可读性和可维护性。

1. 组件化开发： 创建可重用的组件来构建用户界面，使代码更模块化、可复用和易于维护。

jsxCopy Code

// ProductItem.js

import React from "react";



function ProductItem({ name, price, imageUrl }) {

  return (

    <div className="product-item">

      <img src={imageUrl} alt={name} />

      <div className="product-details">

        <h3>{name}</h3>

        <p>{price}</p>

      </div>

    </div>

  );

}



export default ProductItem;

2. 虚拟DOM优势： 通过使用React的虚拟DOM机制，只进行必要的DOM更新，提高页面性能。

jsxCopy Code

// ProductList.js

import React, { useState } from "react";

import ProductItem from "./ProductItem";



function ProductList({ products }) {

  const [selectedProductId, setSelectedProductId] = useState(null);



  function handleItemClick(productId) {

    setSelectedProductId(productId);

  }



  return (

    <div className="product-list">

      {products.map((product) => (

        <ProductItem

          key={product.id}

          name={product.name}

          price={product.price}

          imageUrl={product.imageUrl}

          onClick={() => handleItemClick(product.id)}

          isSelected={selectedProductId === product.id}

        />

      ))}

    </div>

  );

}



export default ProductList;

3. 代码规范示例： 制定一套严格的代码规范，包括命名规范、文件组织方式等。

命名规范示例：

• 使用驼峰式命名法：例如，productItem而不是product_item。


• 组件命名使用大写开头：例如，ProductList而不是productList。


• 常量全大写，使用下划线分隔单词：例如，API_URL。

文件组织方式示例：

Copy Code

src/

  components/

    ProductList.js

    ProductItem.js

  utils/

    api.js

  styles/

    product.css

  App.js

  index.js

前端的价值

作为前端开发者，在业务中发挥着重要的作用，并能为团队和产品创造价值。前端的价值主要体现在以下几个方面：

1. 用户体验

前端开发直接影响用户体验，良好的界面设计和交互能够提高用户满意度并增加用户的黏性。通过技术的提升，我们可以实现更流畅的页面过渡效果、更友好的交互反馈等，从而提高用户对产品的喜爱度。

例如，在电商网站的商品详情页面中，我们可以通过使用React和动画库来实现图片的缩放效果和购物车图标的动态变化，以吸引用户的注意并提升用户体验。

jsxCopy Code

import React from 'react';

import { Motion, spring } from 'react-motion';



class ProductDetail extends React.Component {

  constructor(props) {

    super(props);

    this.state = {

      isImageZoomed: false,

      isAddedToCart: false,

    };

  }



  handleImageClick = () => {

    this.setState({ isImageZoomed: !this.state.isImageZoomed });

  };



  handleAddToCart = () => {

    this.setState({ isAddedToCart: true });

    // 添加到购物车的逻辑

  };



  render() {

    const { isImageZoomed, isAddedToCart } = this.state;



    return (

      <div>

        <img

          src={product.image}

          alt={product.name}

          onClick={this.handleImageClick}

          style={{

            transform: `scale(${isImageZoomed ? 2 : 1})`,

            transition: 'transform 0.3s',

          }}

        />

        <button

          onClick={this.handleAddToCart}

          disabled={isAddedToCart}

          className={isAddedToCart ? 'disabled' : ''}

        >

          {isAddedToCart ? '已添加到购物车' : '添加到购物车'}

        </button>

      </div>

    );

  }

}



export default ProductDetail;

2. 跨平台兼容性

在不同的浏览器和设备上，页面的呈现效果可能会有所差异。作为前端开发者，我们需要解决不同平台和浏览器的兼容性问题，确保页面在所有环境下都能正常运行。

通过了解各种前端技术和标准，我们可以使用一些兼容性较好的解决方案，如使用flexbox布局代替传统的浮动布局，使用媒体查询来适配不同的屏幕尺寸等。

1. 使用Flexbox布局代替传统的浮动布局： Flexbox是一种弹性布局模型，能够更轻松地实现自适应布局和等高列布局。

cssCopy Code

.container {

  display: flex;

  flex-direction: row;

  justify-content: space-between;

}



.item {

  flex: 1;

}

2. 使用媒体查询适配不同的屏幕尺寸： 媒体查询允许根据不同的屏幕尺寸应用不同的CSS样式。

cssCopy Code

@media (max-width: 767px) {

  /* 小屏幕设备 */

}



@media (min-width: 768px) and (max-width: 1023px) {

  /* 中等屏幕设备 */

}



@media (min-width: 1024px) {

  /* 大屏幕设备 */

}

3. 使用Viewport单位设置响应式元素： Viewport单位允许根据设备的视口尺寸设置元素的宽度和高度。

cssCopy Code

.container {

  width: 100vw; /* 100% 视口宽度 */

  height: 100vh; /* 100% 视口高度 */

}



.element {

  width: 50vw; /* 50% 视口宽度 */

}

4. 使用Polyfill填补兼容性差异： 对于一些不兼容的浏览器，可以使用Polyfill来实现缺失的功能，以确保页面在各种环境下都能正常工作。

htmlCopy Code

<script src="polyfill.js"></script>

3. 性能优化

用户对网页加载速度的要求越来越高，前端开发者需要关注页面性能并进行优化。这包括减少HTTP请求、压缩和合并资源、使用缓存机制等。

举例来说，我们可以通过使用Webpack等构建工具来将多个JavaScript文件打包成一个文件，并进行代码压缩，从而减少页面的加载时间。

结论

作为前端开发者，我们经常面临各种挑战，如业务目标的实现、技术团队策略的制定等。通过不断学习和提升，我们可以解决前端开发中的各种困难，并为业务目标做出贡献。同时，我们的工作还能够直接影响用户体

前言

1、人情世故

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

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

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

2、人生的发展需要平台

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

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

曹操

出身

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

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

做事手段

1、许劭风评

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

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

2、傍大腿

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

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

3、挟天子以令诸侯

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

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

4、善用人才

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

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

个人看法

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

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

b、曹操做事狠

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

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

c、驾驭人

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

学历史，学读懂人心

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

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

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

在前几期文章的评论中，我发现不少人有类似“古茗前端到底搞什么飞机”的疑问：

其实在入职古茗前我也有这种观点，不就是做做下单小程序，做做简单的内部管理系统吗，甚至在面试过程中我也问了面试官这个问题，在听完面试官的解答之后，我也同样地忍不住发出了“居然要做这么牛逼的事情，这还是一个奶茶公司吗”的感慨！

于是我毫不犹豫地选择加入了古茗（有免费奶茶喝！畅饮的那种！）。

到现在已经入职快一年了，是时候跟大家讲讲“古茗前端到底搞什么飞机”了。

做一杯奶茶，总共分几步？

其实古茗的业务真的很多，很多，很多！具体有哪些我不方便透露，只能说光是我们前端团队就服务了4个业务域，18条业务线。那我们是怎么服务这些业务域和业务线的呢？我就拿我所在的“机料”举例吧。

那什么是机料呢？在这里我先卖个关子，相信看完下面的介绍，你就会知道是什么意思了，以后去古茗点奶茶就可以跟别人吹牛了（狗头）

首先问大家一个问题：做一杯奶茶，总共分几步？

就和把大象塞进冰箱一样，第一步：倒上茶，第二步：加上料，第三步：吨吨吨！

是不是很简单？步骤看着是简单，但是衍生出来的问题还是很多的

第一步涉及到的问题：

1. 泡茶汤时，不同的茶，分别用多少度的水泡？泡多长时间？泡多少量？


2. 怎么保证全国门店的店员按要求执行了泡茶方法？


3. 怎么灵活控制不同地区的茶保持相同/不同口感？


4. ...

再来看看第二步涉及到的问题：

1. 有些物料是冷冻运输的，什么时候拆封解冻？解冻多久？保质期多久？


2. 有些物料是原材料，什么时候要制备成半成本？保质期多久？


3. 怎么保证加料时物料是在最佳赏味期内的？


4. 怎么保证全国门店的店员遵守食品安全规范？


5. 怎么提前告知门店高峰期的预估物料种类以及用量？


6. ...

最后第三步里的问题：

1. 怎么保证门店能尽可能还原研发室里研发出来的口味？


2. 怎么保证更快地出杯？


3. ...

虽然看着很麻烦很多，但是我们稍微捋一下还是能捋明白的：

• 对于“怎么保证”这类问题，其实是一种功能性问题，我们需要让我们的功能代码在门店运行


• 对于“多少”、“多久”、“什么时候”这些问题，可以归类为配置性问题，可以通过后台配置并进行下发

那基于这两大类问题，“机料”业务就浮出水面了。

机-机器设备

机，就是机器设备（下文统一叫设备），奶茶店里有各种各样的设备，这些机器都是用来辅助店员去标准化地制作奶茶的，设备更多地在解决一些“功能性”的问题，有了这些功能，我们就可以更好地保证一系列流程的规范性。

解决了什么问题

比如上面提到的问题：泡茶汤时，不同的茶，分别用多少度的水泡？泡多长时间？泡多少量？这些问题都是直接影响茶汤的口感的，茶汤是一杯奶茶的基底，要是口感不佳，那么整杯奶茶就毁了。

虽然古茗有很严格的培训体系，每一个店员都需要来总部进行培训学习和考试，但是哪怕是老虎也有打盹的时候，我们不能完全寄希望于店员时时刻刻严格遵守不同类别的茶的制作流程，人不是机器，对不同茶汤的温度、水量、时长等等因素进行人为控制，这些都是难度极大的。

既然人不是机器，那就直接造！于是乎我们的设备部做了泡茶机、制冷设备等等设备。

有泡茶机前，我们的店员需要记下每一款茶的调制过程，然后人工去泡，这就导致同一个人，同一家店，不同时间，泡出来的茶口感会不一样。

有了泡茶机以后，店员只需要把茶包包装上的茶包码往泡茶机上扫一下，泡茶机就可以检索对应的茶汤配方自动按照标准流程、按照标准参数进行泡茶，这样就解决了人为带来的茶汤口感不稳定的问题。

并且无形中还解决了另一个问题，就是“灵活控制不同地区的茶保持相同/不同口感”，因为刚才有提到，泡茶机会根据对应的茶汤配方进行泡茶流程，那么我们就可以根据不同地区下发不同的配方，来保证泡出预期口感的茶汤。

怎么实现

那这一套我们是怎么做的呢？前端在其中扮演了什么角色呢？考虑到保密的原因，我这里就简单画几个图，详细的技术细节就不透露了。

设备侧的产品经理需求评审之后：

1. 嵌入式开发：与“网关”开发（一般是前端开发）共同制定数据通信协议，并按这份协议进行嵌入式开发，通过这份协议可以实现硬件设备与“网关”上USB或者蓝牙的数据传输方式


2. 后端开发：与前端制定接口格式，通过接口可以将设备的数据上传至后端，用做设备信息展示、设备异常告警等用处


3. 前端开发：根据数据通信协议进行“网关”功能的开发，通过协议解析设备的数据，并按照接口格式上传至后端，在后台大盘上显示数据，或者在“网关”上显示相关设备的异常告警

可以看到前端不光要开发后台的功能，还需要开发“网关”的功能，这对传统前端开发来说是一种新的挑战，因为不光要写前端代码，还要掌握硬件的通信协议，了解客户端的相关开发技能，目前的“网关”其实是运行在搭载了Android系统平板的APP中，协议的实现都需要在这个APP中完成。

用这种“伪网关”的方式存在一个很明显的弊端，就是我们的门店存在多个种类的设备，光是制冷设备就分为平冷、冷冻、冷藏三种类型，每种类型分别会有1-2台设备下店，加上一些研发中的设备，这样一来网关平板的蓝牙连接数量很容易达到上限，就会造成有部分设备无法连接蓝牙的问题，为了解决这个问题，我们出了一个临时方案，一个长久方案。

临时方案就是保证核心设备是保持连接的，但是给一些相对来说不是那么重要的设备做定时断开、轮流连接的处理，这样能一定程度上解决这个问题。

长久方案就是开发一个真正意义上的“边缘网关”，边缘网关能接入更多的设备，且能更聚焦于设备的通信、信息的处理分析等功能。

边缘网关是一种用于连接边缘设备和云平台之间的网络设备。 其主要作用是在边缘设备和云平台之间构建一个灵活、高效和安全的网络，将数据从边缘设备收集并处理后，再传输到云平台上进行存储和分析。 在这个过程中，边缘网关需要具备多种功能，包括数据的采集、处理、分析、存储和传输等。

小结

我经常感叹，我们组不是单纯的前端开发工程师了，因为组里的成员一直在和设备、各种协议打交道，桌上也放着各种各样的电路板，年前甚至把一台要下店的净水器直接放在工位边联调，也写过“220V，勿碰”的牌子放在工位上。

之前和TL聊物料网的应用场景，我们都认为这就是物联网一个很好的落地场景，并且我们的目标远不止于此，业务上还有很多的问题要依赖于设备去解决，很多降本增效的事情也要依赖于设备去实现，我相信在不久的将来，古茗的设备一定会给门店带来更多的收益，古茗的IoT方案会成为茶饮界IoT方案中值得参考的那个。

料-物料

说完“机”，再来看看“料”，就是制作一杯奶茶所需要用到的物料。

餐饮行业最重视的一个问题就是食品安全问题，这首先关系到每个消费者的身体健康，其次涉及门店的经营情况，最后会影响品牌在公众心里的印象，所以食安是每一个餐饮企业的底线。

古茗为了保证食安，搞了自己的种植基地，搭建了自己的供应链系统、智能报货系统，研发室的研发员们针对每一款物料制定了“有效期”...

除了种植基地，其他业务都和我们组有关系，这里我就介绍一下物料“有效期”这件事。

解决了什么问题

在开头的经典三步的第二步，都是物料相关的内容，首先我先科普一下物料有效期相关的几个概念：解冻时间、备料时间、最佳赏味期。

解冻时间：冷冻品需要解冻的时长，比如家里的冻肉，做菜时得先拿出来解冻一下；

备料时间：解冻完成后就需要对原料进行备料加工了，还是拿冻肉举例，冻肉解冻完了就得切成肉片开始炒了；

最佳赏味期：顾名思义，就是在这个期间内食用是最好的，好比你妈妈把肉炒完了，喊你吃饭，结果你一直在玩游戏就错过了最佳赏味期了。

为什么是定这三个时间，而不是其他的四个时间，五个时间呢？

其实也是根据奶茶的制作方式来定的，因为门店要做一杯奶茶是需要用到半成品物料的，半成品物料又需要由原料制备得到，而那些冷冻原料又需要解冻（解冻其实也是制备的一个环节，只不过解冻需要的时间会很长，且不是每个物料都需要解冻，比如茶就不需要解冻），所以结合实际情况，就定了这三个时间。

按我个人理解的话，其实就是为了保证任何一家门店、任何一个店员做出来的奶茶，都是符合食安的、最新鲜的、口感最好的。

怎么实现

那这三个时间需要怎么在门店里直观地展现给店员呢？

聪明的你可能想到了，对，就是利用设备！这台设备的名字就叫“效期机”，我再画个图给大家看看效期机是怎么在门店发挥作用的。

假设店员发现XX冷冻原浆快不够用了，那他就会从冷冻柜中取出XX冷冻原浆，然后去效期机的物料列表上去找XX冷冻原浆这个物料，找到后在使用效期机的打印功能进行打印，这时打印机就会打印XX冷冻原浆的效期贴（记载了物料相关信息的一个小贴纸），店员撕下小贴纸后贴到XX冷冻原浆的容器上，最后放到解冻区进行解冻。

店员做完上面这些步骤之后就可以做自己的事了，等到了解冻时间、备料时间、超过最佳赏味期前2分钟这些节点，效期机就会进行语音播报，提醒店员XX冷冻原浆需要进行XX操作了。

那效期机是怎么知道物料的这三个时间并在对应时间给出语音提醒的呢？

其实这个链路的流程蛮简单的，效期机种记录了每个物料的三种时间，在店员打印效期贴的那一刻，这个物料的生命周期就开始了，物料的生命周期每个阶段的时长是按照物料配置平台配置的时间决定的，同时效期机内部维护了三个有序队列，分别是解冻提醒队列，备料提醒队列，最佳赏味期超期提醒队列，物料的生命周期就在这三个队列之间流转，驱动生命周期的是一个10s一次的轮询，每次轮询都会去判断三个队列的头数据是否达到触发条件，即是否到了提醒时间。

比如XX冷冻原浆的配置是解冻时间30分钟，备料时间10分钟，最佳赏味期60分钟，店员打印效期贴的时间是12:00，那么这个物料的生命周期就是这么流转的：

这里有个小细节：我们会在最佳赏味期前2分钟就进行提醒，这个的目的就是为了更进一步保证食安以及最后奶茶的口感。

小结

其实对于物料的管理，上文提到的内容只是冰山一角，我们已经做的、正在做的、未来计划要做的事还多的很。

在食安问题上，针对私自篡改效期时间的门店，会进行高额的罚款，每天也会定期进行后厨的打扫，在培训时也会针对食安部分进行严格的培训和考试；

在物料提醒的优化上，我们发现目前的提醒交互还是会存在店员理解不到位的情况，这里也在不断地进行优化和迭代；

在保证更快的出杯速度上，我们现在正在做的一件事是基于门店的实际出杯情况去生成预测物料用量，并通过效期机下发给到门店，辅助门店更好准确地进行物料的提前制备，以及提升出杯速度。

感悟

最后聊聊入职古茗后的感悟吧，在这不到一年的时间感觉成长了很多。

首先是技术吧，前面也提到了，我所在的组要和设备打交道，加上我本来是个安卓开发，现在加入古茗前端部门后，也在针对性学习前端的内容、跨端的技术，其实学习一门语言并不是难题，难的是要培养前端的编程思维，这和客户端思维还是有差别的。

其次是业务，古茗应该是我离业务最近的公司了，我给门店打过上百通电话，线下跑过十来家门店，跟产品经理去实地调研......这些经历让我更了解了店员需要什么，我们需要提供什么样的功能给他们。

然后是工程师能力，这是在古茗前端部门经常被提起的一个概念，我们给工程师的定位是能解决一类复杂问题的人，在此基础上我们就应该具备更完善的能力，不仅仅局限于写某一种或几种代码，为了搭建运维平台，我特地去学习了产品知识，按照一个完整的流程进行了原型图的评审，需求文档的评审，并参与到平台的开发中。不仅是我，古茗的前端都在朝着“工程师”而在努力着。

最后的最后，就是人长胖了，古茗真的是无限畅饮，我可真喝不动了......

最后

关注公众号「Goodme前端团队」，获取更多干货