动动发财的小手，点个赞吧！

数据工程构成了数据科学过程的很大一部分。在 CRISP-DM 中，这个过程阶段称为“数据准备”。它包括数据摄取、数据转换和数据质量保证等任务。在本文章中，我们使用 ChatGPT 和 Python 解决了典型的数据工程任务。通过这样做，我们探索了数据工程与提示工程新学科之间的联系。

简介

2022 年 5 月，斯蒂芬·沃尔夫勒姆 (Stephen Wolfram) 和莱克斯·弗里德曼 (Lex Fridman) 发表了题为“编程已死吗？”的深刻见解。他们讨论了未来开发者是否还会使用高级语言。根据 Wolfram 的说法，许多编程任务可以通过大型语言模型 (LLM) 实现自动化。在撰写本文时，此类模型最突出的例子是 ChatGPT。自 2022 年底推出以来，它产生了惊人的效果。指定要由 LLM 执行的操作称为“提示工程”。如果 Wolfram 是对的，至少软件开发的一部分将从编写代码转向编写提示。

在数据科学方面，数据准备可能是一项耗时且乏味的任务。那么，为什么不尝试使用 LLM 使其自动化呢？在以下部分中，我们将使用 ChatGPT 和 Python 解决不同的数据工程问题。我们没有自己编写 Python 代码，而是使用提示工程来生成它。我们的实验是在 2023 年 5 月 19 日基于当时最新的免费 ChatGPT 版本 (GPT-3.5) 进行的。

创建数据框

让我们从一个简单的问题开始，并从样本数据集创建一个 Pandas 数据框。表 1 包含例如世界银行提供的国家指标。

为了从上面的示例中创建数据框，我们开始了与 ChatGPT 的新对话并发布了以下提示：

Create a Pandas table with the following data:

Continent, Country, Year, Category, Variable, Value

Asia, China, 2022, Economy, GDP, 18.1

Asia, China, 2022, Demographics, Population, 1412

North America, USA, 2022, Economy, GDP, 25.5

North America, USA, 2022, Demographics, Population, 333

Europe, Germany, 2022, Economy, GDP, 3.9

Europe, Germany, 2022, Demographics, Population, 84

作为响应，该模型生成了以下 Python 代码：

import pandas as pd



data = {

    'Continent': ['Asia', 'Asia', 'North America', 'North America', 'Europe', 'Europe'],

    'Country': ['China', 'China', 'USA', 'USA', 'Germany', 'Germany'],

    'Year': [2022, 2022, 2022, 2022, 2022, 2022],

    'Category': ['Economy', 'Demographics', 'Economy', 'Demographics', 'Economy', 'Demographics'],

    'Variable': ['GDP', 'Population', 'GDP', 'Population', 'GDP', 'Population'],

    'Value': [18.1, 1412, 25.5, 333, 3.9, 84]

}



df = pd.DataFrame(data)

print(df)

运行脚本时，我们看到输出符合我们的规范：

尽管我们在实验中使用了示例，但下一节中生成的代码原则上也可以处理更大的数据集。

旋转数据框

对于数据科学，我们在第一个提示中创建的表结构并不是最优的。相反，所谓的“平板”会更方便。在表 1 中，指标“GDP”和“人口”分别用名为“Variable”和“Value”的两列表示。相比之下，平面表格将为每个指标包含单独的列，如表 2 所示。

将表 1 的格式转换为表 2 的格式称为“透视”。让我们尝试使用 ChatGPT 来解决这个任务。为此，我们在对话中发布了第二个提示：

Transform the table into the following format:

Continent, Country, Year, GDP, Population

Asia, China, 2022, 18.1, 1412

North America, USA, 2022, 25.5, 333

Europe, Germany, 2022, 3.9, 84

上述消息基于所需数据格式的示例。或者，我们也可以纯口头表达我们的要求。与经典编程一样，在提示工程中有实现目标的替代解决方案。在不久的将来，寻找最佳方式将是一项激动人心的任务。根据我们的提示，ChatGPT对Python代码进行了如下调整：

import pandas as pd



data = {

    'Continent': ['Asia', 'Asia', 'North America', 'North America', 'Europe', 'Europe'],

    'Country': ['China', 'China', 'USA', 'USA', 'Germany', 'Germany'],

    'Year': [2022, 2022, 2022, 2022, 2022, 2022],

    'Category': ['Economy', 'Demographics', 'Economy', 'Demographics', 'Economy', 'Demographics'],

    'Variable': ['GDP', 'Population', 'GDP', 'Population', 'GDP', 'Population'],

    'Value': [18.1, 1412, 25.5, 333, 3.9, 84]

}



df = pd.DataFrame(data)



# Pivot the table

pivot_df = df.pivot_table(index=['Continent', 'Country', 'Year'], columns='Category', values='Value').reset_index()



# Rename the columns

pivot_df.columns.name = 

pivot_df.columns = [column if column != 'Variable' else  for column in pivot_df.columns]



print(pivot_df)

然而，运行脚本的第二个版本显示输出不是我们所要求的：

该表包含名为“人口统计”和“经济”的两列，而不是预期的“GDP”和“人口”列。为了解决这个问题，我们发布了下一个提示：

The columns are not correct, you should have used 

the variables GDP and population

作为响应，模型纠正了错误并生成了另一个版本的 Python 代码：

import pandas as pd



data = {

    'Continent': ['Asia', 'Asia', 'North America', 'North America', 'Europe', 'Europe'],

    'Country': ['China', 'China', 'USA', 'USA', 'Germany', 'Germany'],

    'Year': [2022, 2022, 2022, 2022, 2022, 2022],

    'Category': ['Economy', 'Demographics', 'Economy', 'Demographics', 'Economy', 'Demographics'],

    'Variable': ['GDP', 'Population', 'GDP', 'Population', 'GDP', 'Population'],

    'Value': [18.1, 1412, 25.5, 333, 3.9, 84]

}



df = pd.DataFrame(data)



# Pivot the table

pivot_df = df.pivot_table(index=['Continent', 'Country', 'Year'], columns='Variable', values='Value').reset_index()



# Rename the columns

pivot_df.columns.name = 

pivot_df.columns = ['Continent', 'Country', 'Year', 'GDP', 'Population']



print(pivot_df)

运行脚本表明这次旋转已正确实现：

富集数据框

另一个典型的数据工程任务是用附加信息丰富数据集。为此，我们要求 ChatGPT 通过发布以下提示将 ISO 国家代码添加到我们的数据中：

For each country, in the table above, add its ISO code

结果，模型调整了响应并返回了以下代码片段：

import pandas as pd



data = {

    'Continent': ['Asia', 'Asia', 'North America', 'North America', 'Europe', 'Europe'],

    'Country': ['China', 'China', 'USA', 'USA', 'Germany', 'Germany'],

    'Year': [2022, 2022, 2022, 2022, 2022, 2022],

    'Category': ['Economy', 'Demographics', 'Economy', 'Demographics', 'Economy', 'Demographics'],

    'Variable': ['GDP', 'Population', 'GDP', 'Population', 'GDP', 'Population'],

    'Value': [18.1, 1412, 25.5, 333, 3.9, 84]

}



iso_codes = {

    'China': 'CN',

    'USA': 'US',

    'Germany': 'DE'

}



df = pd.DataFrame(data)



# Add ISO code column

df['ISO Code'] = df['Country'].map(iso_codes)



# Pivot the table

pivot_df = df.pivot_table(index=['Continent', 'Country', 'ISO Code', 'Year'], columns='Variable', values='Value').reset_index()



# Rename the columns

pivot_df.columns.name = 

pivot_df.columns = ['Continent', 'Country', 'ISO Code', 'Year', 'GDP', 'Population']



print(pivot_df)

运行脚本显示一个带有 ISO 代码的新列已添加到数据框中。

派生列

接下来让我们通过将一个国家的 GDP 除以其人口规模来得出一个新的列“人均 GDP”。为此，我们发送了以下提示：

Derive a new column "GDP per capita" by dividing the GDP 

of a country by its population size

对此，模型修改了代码如下：

import pandas as pd



data = {

    'Continent': ['Asia', 'Asia', 'North America', 'North America', 'Europe', 'Europe'],

    'Country': ['China', 'China', 'USA', 'USA', 'Germany', 'Germany'],

    'Year': [2022, 2022, 2022, 2022, 2022, 2022],

    'Category': ['Economy', 'Demographics', 'Economy', 'Demographics', 'Economy', 'Demographics'],

    'Variable': ['GDP', 'Population', 'GDP', 'Population', 'GDP', 'Population'],

    'Value': [18.1, 1412, 25.5, 333, 3.9, 84]

}



iso_codes = {

    'China': 'CN',

    'USA': 'US',

    'Germany': 'DE'

}



df = pd.DataFrame(data)



# Add ISO code column

df['ISO Code'] = df['Country'].map(iso_codes)



# Pivot the table

pivot_df = df.pivot_table(index=['Continent', 'Country', 'ISO Code', 'Year'], columns='Variable', values='Value').reset_index()



# Calculate GDP per capita

pivot_df['GDP per capita'] = pivot_df['GDP'] / pivot_df['Population']



# Rename the columns

pivot_df.columns.name = 

pivot_df.columns = ['Continent', 'Country', 'ISO Code', 'Year', 'GDP', 'Population', 'GDP per capita']



print(pivot_df)

输出表明脚本产生了预期的结果：

分析数据

一旦数据转换完成，实际的分析就可以开始了。最后让我们计算一下各国GDP与人口的相关系数。为此，我们贴出最后一个提示：

Use the table above to calculate the correlation coefficient between 

the GDP and the population of the countries

结果，模型返回了以下代码片段：

import pandas as pd



data = {

    'Continent': ['Asia', 'Asia', 'North America', 'North America', 'Europe', 'Europe'],

    'Country': ['China', 'China', 'USA', 'USA', 'Germany', 'Germany'],

    'Year': [2022, 2022, 2022, 2022, 2022, 2022],

    'Category': ['Economy', 'Demographics', 'Economy', 'Demographics', 'Economy', 'Demographics'],

    'Variable': ['GDP', 'Population', 'GDP', 'Population', 'GDP', 'Population'],

    'Value': [18.1, 1412, 25.5, 333, 3.9, 84]

}



df = pd.DataFrame(data)



# Pivot the table

pivot_df = df.pivot_table(index=['Continent', 'Country', 'Year'], columns='Variable', values='Value').reset_index()



# Calculate correlation coefficient

correlation_coefficient = pivot_df['GDP'].corr(pivot_df['Population'])



print("Correlation Coefficient: {:.3f}".format(correlation_coefficient))

运行脚本时，我们发现两个变量之间存在很强的正相关性，这并不奇怪：

总结

不可否认，我们的实验是基于一个简单的数据集。然而，结果是显著的。我们执行了几项数据工程任务，而没有编写一行代码。 ChatGPT 不仅能够在大多数情况下正确执行我们的提示。但即使模型犯了错误，它也能够反映和修复错误。与软件开发一样，生成的代码必须经过测试。此外，它可能需要重构和优化。在 AI 时代使用 pylint 仍然是一个好主意。然而，总而言之，我们必须同意 Wolfram 的观点：在未来，数据工程的重要部分将从编码转向提示工程。这种新方法不会取代数据工程师，但会提高他们的效率。

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

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

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

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

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

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

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

第一，认死理。

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

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

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

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

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

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

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

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

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

第三，不擅长合作。

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

他们会搞钱。

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

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

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

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

​

--- 

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

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

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

最后补一个，左耳朵耗子的事情告诉我们，程序员真的要保养身子，拼到最后其实还是拼身

提到实事求是，大家第一时间会想到什么？我想大部分是客观，事实，脚踏实地？这么一想，大家都会觉得，自己挺实事求是的呀，没毛病。但是，我会经常在工作中感受到不是那么实事求是的行为，比如张嘴就来，不带思考，做事全靠猜的行为，真太多了。

随着我这两年的学习和总结，我越发觉得实事求是非常重要，并把它视为我做事情和成长的基石。对于实事求是，我主要有以下 3 层理解。

首先，尊重客观事实，探寻真理。我们要承认事实，即使这个事实有多么的难以置信，但存在即是合理，我们首先要尊重它，承认它。然后我们还要积极主动地面对它，探寻事实背后的真理，获得真知，这样才能真正的成长，并有可能寻得机会。当某个事情的进展超出自己预期的时候，我们正确的态度应该是思考为什么会这样，而不是去想对错得失。

其次，数据说话，数据驱动。事实如何去量化？答案是数据。使用数据去表达事实，是我们程序员应该有的技能。工作的本质就是解决问题，之前的文章有讲解，问题就是理想状态和现实状态之间的差别，因此，我们在工作当中做的每一项决策的依据、制定的每一个目标，都应该用数据说话。我们应该使用数据表达现状，并使用数据衡量目标，驱动自己去工作。一些沟通的细节就能够体现出他是不是在实事求是地工作，比如“这个页面加载太慢了，需要优化”。那这个页面加载到底有多慢？业界标准或者竞品的加载耗时是多少？优化的目标值是多少？

最后，从客观事实中获取反馈，不断迭代。工作中想要获得成功和成长，最核心的一个环节是反馈。很多人没有意识到这点。更多的人没有意识到的是，获取反馈其实很简单，随处都是。敏捷开发、精益创业、增长黑客，这些理论的底层核心都是基于事实和数据的反馈，不断迭代改进自己的产品，从而获得成功。对于个人成长来说也是一样的，我们要从客观事实中获取反馈，思考总结，不断迭代自己的能力。

总结一下，实事求是地工作有 3 个层次，首先，要正视事实，并主动探究真理；然后我们慢慢地开始用数据驱动自己的工作；最后让数据驱动变成循环，不断迭代，并把这种循环融入到各个方面，包括工作和个人成长，让它成为自己下意识的动作。

我在努力学习和践行实事求是地工作，我也希望我的团队可以用实事求是的态度来工作，以此文共勉！

人在国企，身不由己！公司福利和薪资还可以，但有个难顶的组长就不可以，说走就走!如果把这个组长换了的话就另说了！

1.为什么突然想不干了？

1.奇葩的新组长

我的前组长辞职了，然后被安排到这个自研项目组，而这个新组长我之前得罪过，老天爷真爱开玩笑！

今年过年前，我主开发的平台要嵌入到他负责的项目里面，一切对接都很顺利，然而某天，有bug，我修复了，在群里面发消息让他合并分支更新一下。他可能没看到，然后我下班后一个小时半，我还在公司，在群里问有没有问题，没回应！

然后我就坐车回家，半路，产品经理组长、大组长和前组长一个个轮流call我，让我处理一下bug,我就很无语！然后我就荣获在家远程办公，发现根本没问题！然后发现是对方没更新的问题！后面我修复完直接私聊他merge分支更新，以免又这样大晚上烦人！
而类似的事情接连发生，第三次之后，我忍不住了，直接微信怼了他，他还委屈自己晚上辛苦加班，我就无语大晚有几个人用，晚上更新与第二天早上更新有什么区别？然后就这样彻底闹掰了！

我就觉得这人很奇葩，有什么问题不能直接跟我沟通，一定要找我的上级一个个间接联系我呢？而且，这更新流程就很有问题，我之前在别的组支援修bug，是大早上发布更新，一整天测试，保证不是晚上的时候出现要紧急处理的问题！

然后，我跟这人有矛盾后，我就没继续对接这个项目了，前组长安排了别人代替我！

结果兜兜转转，竟然调到他这里来！作孽啊！

2.项目组乱糟糟

新项目组可以看出新组长管理水平很糟糕！

新组长给自己的定位是什么都管！产品、前后端、测试、业务等，什么都往自己身上揽！他自己觉得很努力，但他不是那部分的专业人员，并不擅长，偏偏还没那个金刚钻揽一堆瓷器活！老爱提建议！

项目组就两个产品，其中一个是UI设计刚转，还没成长为专业的产品经理，而那个主要负责的产品经理根本忙不过来！

然后，他一个人搞不定，就开始了PUA大法，周会的时候就会说：“希望大家要把这个项目当成自己的事业来奋斗，一起想，更好地做这个产品！”

“这个项目集成了那么多的模块功能，如果大家能够做好，对自己有很大的历练和成长！”

“我们项目是团队的重点项目，好多领导都看好，开发不要仅限于开发，要锻炼产品思维……”

……

简而言之就是，除了本职工作也要搞点产品的工作！

然后建模师开始写市场调研文档，前后端开发除了要敲代码，还得疯狂想新功能。

整个组开始陷入搞新东西的奇怪旋涡！

某次需求评审的时候，因为涉及到大量的文件存储，我提出建议，使用minio,fastdfs，这样就不用每次部署的时候，整体文件还要迁移，结果对方一口拒绝，坚决使用本地存储，说什么不要用XX平台的思想来污染他这个项目，他这个项目就要不需要任何中间件都能部署。

就很无语！那个部署包又大又冗余，微服务都不用，必须要整包部署整套系统，只想要某几个功能模块都不行，还坚持说这样可以快速整包部署比较好！

一直搞新功能的问题就是版本更新频繁！一堆新功能都没测清楚就发布，导致产品质量出现严重问题，用户体验极差！终于用户积攒怨气爆发了，在使用群里面@了我们领导，产品质量问题终于被彻底揭开了遮羞布！

领导开始重视这个产品质量的问题，要求立即整改！

然后这个新组长开始新一轮搞事！

“大家保证新功能进度的同时，顺便测试旧功能，尽量不要出bug！”

意思就是你开发进度也要赶，测试也要搞！

就不能来点人间发言吗？

3.工作压力剧增

前组长是前端的，他带我入门3D可视化的，相处还算融洽！然而他辞职了，去当自由职业者了！

新组长是后端的，后端组长问题就是习惯以后端思维评估前端工作，给任务时间很紧。时间紧就算了，还要求多！

因为我之前主开发的项目是可视化平台，对方不太懂，但不妨碍他喜欢异想天开，加个这个，加个那个，他说一句话，就让你自行想象，研究竞品和评估开发时间！没人没资源，空手套白狼，我当时就很想爆他脑袋了！

我花一个星期集成了可视化平台的SDK，连接入文档都写好了，然后他验收的时候提出一堆动态配置的要求，那么大的可视化平台，他根本没考虑项目功能模块关联性和同步异步操作的问题，他只会提出问题，让你想解决方案！

然后上个月让我弄个web版的Excel表格，我看了好多开源项目，也尝试二开，增加几个功能，但效率真的好低！于是我就决定自己开发一个！

我开发了两个星期，他就问我搞定没？我说基本功能可以，复杂功能还在做！

更搞笑的是，我都开发两个星期了，对方突然中午吃饭的时候微信我，怕进度赶不上，建议我还是用开源的进行二开，因为开源有别人帮忙一起搞。

我就很无语，人家搞的功能又不是一定符合你的需求，开源不等于别人给你干活，大家都是各干各的，自己还得花精力查看别人代码，等价于没事找事，给自己增加工作量！别人开发的有隐藏问题，出现bug排查也很难搞，而自己开发的，代码熟悉，即便有问题也能及时处理！

我就说他要是觉得进度赶不上就派个人来帮忙，结果他说要我写方案文档，得到领导许可才能给人。

又要开发赶进度，又要写文档，哪有那么多时间！最终结果就是没资源，没人手，进度依旧要赶！

因为我主开发的那个可视化平台在公司里有点小名气，好多平台想要嵌入，然后，有别的平台找到他要加上这个可视化平台，但问题是我很忙，又要维护又要开发，哪搞得了那么多？还说这个很赶！赶你个头！明知道时间没有，就别答应啊！工作排期啊！

新组长不帮组员解决问题，反而把问题抛给组员，压榨组员就很让人反感！

2.思考逃离

基于以上种种！我觉得这里不是一个长久之地，于是想要逃离这里！

我联系了认识的其他团队的人，别人表示只要领导愿意放人，他们愿意接收我，然后我去咨询一些转团队的流程，那些转团队成功的同事告诉我，转团队最难的是领导放人这关，而且因为今年公司限制招聘，人手短缺，之前有人提出申请，被拒绝了！并且转团队的交接的一两个月内难免要承受一些脸色！有点麻烦！

我思虑再三，我放弃了转团队这条路，因为前组长走了之后，整个团队只剩下我一个搞3D开发的，估计走不掉！

3.提出辞职

忍了两个月，还是没忍住，工作最重要的是开开心心！赚钱是一回事，要是憋出个心理疾病就是大事了！于是我为了自己的身心健康，决定走人！拜拜了喂！老娘不奉陪了！

周一一大早，我就提交了辞职信，大组长表示很震惊，然后下午的时候，领导和大组长一起来跟我谈话，聊聊我为什么离职？问我有没有意愿当个组长之类的，我拒绝了，我只想好好搞技术！当然我不会那么笨去说别人的坏话得罪人！

我拿前组长当挡箭牌，说自己特别不习惯这个新组长的管理方式！前组长帮我扛着沟通之类的问题，我只要专心搞开发就好了！

最终，我意志坚定地挡住了领导和大组长的劝留谈话，并且开始刷面试题，投简历准备寻找新东家！

裸辞后真的很爽，很多同事得知消息都来关心我什么情况，我心里挺感动的！有人说我太冲动了，可以找好下家再走！但我其实想得很清楚，我没可能要求一个组长委屈自己来适应我，他有他的管理方式，我有我的骄傲！我不喜欢麻烦的事，更不喜欢委屈自己，一个月后走人是最快解决的方案！

4. 转机

其实我的离开带来了一点影响，然后加上新组长那个产品质量问题警醒了领导，然后新组长被调去负责别的项目了，换个人来负责现在的项目组，而这个人就是我之前支援过的项目组组长，挺熟悉的！

新新组长管理项目很有条理也很靠谱，之前支援的项目已经处于稳定运行的状态了，于是让他来接手这个项目！他特意找我谈话，劝我留下来，并且承诺以后我专心搞技术，他负责拖住领导催进度等问题！

我本来主要就是因为新组长的问题才走人的，现在换了个不错的组长！可以啊！还能苟苟！

5.反思

1. 其实整件事情中，我也有错，因为跟对方闹掰了，就拒绝沟通，所以导致很多问题的发生，如果我主动沟通去说明开发难度的问题，并且争取时间，就不至于让自己处于一个精神内耗的不快乐状态。


2. 发现问题后，我没有尝试去跟大组长反馈，让大组长去治治对方，或者让大组长帮忙处理这个矛盾，我真的太蠢了！


3. 我性格其实挺暴躁的，看不顺眼就直接怼，讨厌的人就懒得搭理，这样的为人处世挺不讨喜的，得改改这坏
   
   作者：敲敲敲敲暴你脑袋
   来源：juejin.cn/post/7241884241616076858
   脾气！

我们在平常工作中经常会听到有人说系统性风险，但系统性风险到底是个啥？

1 系统性风险是什么

1.1 定义

「系统性风险」是一个经济术语，主要指的是一种可能导致整个金融系统或市场瘫痪的风险或概率。它是从系统性风险的整体性出发，而不是单一机构或者单一行业的危机。这通常是由于金融体系中一个重要组成部分的失败，例如一个大银行或一系列银行的破产，这可能引发一种连锁反应，影响整个系统。

当突发性事件导致金融机构或市场失灵时，资金无法在市场中有效输送和配置，从而引起整个市场的崩溃。系统性风险不仅仅是经济价值损失，还会对实体经济造成严重影响，并导致大部分金融体系的信心丧失。

如 2008 年的全球金融危机。在这个危机中，许多大型金融机构由于负债过重和资产质量下降而陷入困境，这引发了对全球金融系统稳定性的广泛担忧。

系统性风险是监管机构、政策制定者和经济学家关注的主要问题，因为如果这种风险实现，可能会导致重大的经济损失和社会动荡。因此，他们会尝试制定和执行各种政策和法规，以减少系统性风险的可能性。

1.2 系统性风险和非系统性风险的差别

系统性风险作为一种具有更大影响面的风险，和非系统性风险有以下几个方面的区别：

1. 影响范围：系统性风险具有广泛的影响范围，不仅仅局限于特定个体或组织，而是可能波及整个系统、市场或行业。非系统性风险则相对较局部化，通常只对特定个体、组织或项目产生影响。

2. 相互关联性：系统性风险与系统中各个组成部分相互关联，其中一个部分的风险可能会传播、扩大或影响其他部分。非系统性风险通常是单个因素或事件的结果，并不涉及系统的相互依赖关系。

3. 复杂性和不确定性：系统性风险往往更加复杂和不确定，因为它们涉及到多个变量、因素和相互作用。非系统性风险可能更加可控和可预测，因为它们通常涉及特定事件或条件。

4. 长期影响：系统性风险可能具有长期影响，并可能导致持续的连锁反应和不良后果。非系统性风险通常具有较短期的影响，并且其影响通常更容易限定和控制。

5. 解决方法：由于系统性风险的复杂性和广泛影响，解决它们通常需要跨部门、跨组织或跨行业的合作和综合性措施。非系统性风险通常可以通过特定个体或组织的行动来解决。

系统性风险与非系统性风险在影响范围、相互关联性、复杂性和不确定性、长期影响以及解决方法等方面存在明显的区别。

2 技术上的系统性风险

类比经济上的系统性风险，对于一家企业的技术负责人来说，技术上的系统性风险也是一个需要重点关注的点。

2.1 定义

在技术上，系统性风险指的是一个技术系统或者一个技术生态系统中，某个关键组件或者某些关键组件出现故障、漏洞、安全问题等，导致整个系统或者生态系统无法正常运行，进而引发连锁反应和影响。

例如，在云计算生态系统中，某个云服务提供商的故障可能会影响到众多企业和用户的业务运营；在物联网领域，某个智能设备的漏洞可能会导致整个物联网网络遭受攻击和瘫痪。因此，在技术领域中，识别和防范系统性风险也是非常重要的。

2.2 系统性风险和非系统性风险的不同

和经济上的系统性风险一样，技术上的系统性风险和非系统性风险也有 5 个不同点：

1. 影响范围和规模：系统性风险通常具有广泛的影响范围和规模，涉及整个技术系统或架构。它可能涉及多个组件、子系统或关键基础设施，甚至可能跨越多个应用程序或服务。非系统性风险更倾向于局部范围，通常仅影响特定的组件、功能或子系统。

2. 相互关联和依赖：系统性风险涉及到技术系统中各个组件和环节之间的相互关联和依赖关系。它们可能因为一个组件或环节的故障或问题而影响其他组件或环节的正常运行。非系统性风险更倾向于独立存在，其影响相对较为局限，不会对其他组件或环节造成波及效应。

3. 复杂性和不确定性：系统性风险通常更加复杂和不确定，因为它们涉及到多个技术组件、系统交互、数据流和相关的外部因素。这使得系统性风险的评估、预测和解决变得更加困难。非系统性风险通常更容易辨识、评估和控制，因为其范围和影响相对较小。

4. 长期影响和连锁反应：系统性风险可能导致长期的影响和连锁反应，其中一个问题可能触发多个级联故障或影响多个关键业务流程。非系统性风险的影响通常更为短期和局限，不会引起大规模的系统级问题。

5. 解决方法和复杂度：由于系统性风险的复杂性和广泛影响，解决它们通常需要跨部门、跨团队的协作，涉及多个技术专长和领域的知识。这可能需要综合性的技术改进、架构调整或系统重构。非系统性风险通常可以通过单个组件或功能的修复或改进来解决，其处理相对较为简单和局部化。

3 系统性风险的传播

在技术系统中，系统性风险通过多种方式传播，包括以下几种：

• 
  

  级联传播：级联传播是指一个组件的故障导致其他相关组件的故障，从而在整个系统中形成一种连锁反应。这种传播方式可能导致整个系统的瘫痪，影响业务的正常运行。例如，在一个分布式计算环境中，如果某个关键任务执行节点发生故障，可能导致其他依赖于该节点的任务无法正常执行，从而引发其他节点的过载或故障。这种风险传播会在整个分布式系统内形成级联效应，可能导致整个系统瘫痪。

  
  


• 
  

  传染传播：传染传播是指一个系统的风险通过某种途径传播给其他系统，从而导致多个系统受到相同类型风险的影响。例如，WannaCry 勒索病毒，它通过网络传播，利用 Windows 系统的一个漏洞进行攻击。当某个系统被感染后，病毒会自动搜索其他具有相同漏洞的系统，并尝试感染它们。这种风险传播方式导致了全球范围内大量系统受到勒索病毒的影响。

  
  


• 
  

  共同暴露：共同暴露是指多个系统由于共享相同的风险因素，而同时受到该风险因素的影响。例如，多个在线服务都依赖于一个第三方身份验证服务。如果这个第三方身份验证服务出现故障或者安全漏洞，那么所有依赖它的在线服务都将面临安全风险或者无法正常运行，因为它们共同暴露在同一个风险因素下。

  
  


• 
  

  放大效应：放大效应是指一个较小的初始风险经过多次传播和叠加，最终导致整个系统面临较大的风险。例如，在社交网络中，一个虚假信息可能经过多次转发和传播，形成恶性舆论，对整个社会产生较大的负面影响。

  
  

在技术系统中，了解这些传播方式和机制对于有效管理技术风险至关重要。

4 系统性风险的来源

系统性风险的由来可以追溯到技术系统的复杂性和相互依赖性。当一个技术系统由多个组件、流程和环节组成时，它们之间存在着相互依赖和相互作用。这种相互依赖性使得一个组件或环节的故障或问题可能会影响整个系统的运行和稳定性。

以下是一些常见的系统性风险的来源：

• 
  

  复杂性和交互作用：技术系统的复杂性和各组件之间的交互作用可能导致系统性风险的出现。当系统变得越来越复杂，组件之间的相互依赖性增加，可能出现不可预见的问题和故障。例如，一个庞大的分布式系统可能由多个模块和子系统组成，彼此之间的相互作用可能导致系统范围的故障，如性能下降或数据不一致。

  
  


• 
  

  外部环境因素：外部环境因素也是技术系统性风险的重要来源。例如，技术系统可能受到恶劣天气、自然灾害（如山洪地震等导致光纤断了）、供应链中断或恶意攻击等外部因素的影响。这些因素可能导致系统中断、数据丢失、安全漏洞暴露等问题。例如，一家电子商务平台可能受到网络攻击，导致用户信息泄露或交易中断。

  
  


• 
  

  人为错误和疏忽：技术系统性风险也可能源自人为错误和疏忽。人员的操作失误、编码错误、配置错误或安全意识薄弱等问题都可能导致系统故障或数据泄露。例如，一个开发人员可能在代码中引入漏洞，导致系统容易受到攻击。

  
  


• 
  

  技术演进和更新：技术的演进和系统的更新也可能引入系统性风险。当引入新的技术、框架或库时，可能存在兼容性问题或未知的缺陷。例如，将系统从一个版本升级到另一个版本时，可能出现功能不兼容、新增的安全漏洞或数据不一致的问题等。

  
  


• 
  

  依赖供应商和第三方：技术系统通常会依赖外部供应商或第三方服务。这种依赖性可能带来风险。例如，如果一个关键供应商无法按时提供所需的硬件设备，可能导致项目延期或无法正常运作。另外，如果一个 CDN 第三方服务提供商的服务出现故障，可能会影响到技术系统的正常运行。

  
  

以上是一些常见的技术系统性风险的来源示例。在技术管理中，了解和识别这些来源是非常重要的，以便采取相应的措施来减轻和管理系统性风险的影响。

5 管理好系统性风险的意义

聊了这么多术语类的东西，看一下对于一个技术管理者来说，管理好系统性风险到底有什么用，有什么收益。这里我们从技术管理和技术团队，以及业务的角度来看。

5.1 技术管理上的意义

从技术管理和技术团队的角度来看，管理好技术上的系统性风险具有以下意义：

1. 保障系统的稳定性和可靠性：系统性风险管理可以帮助确保技术系统的稳定性和可靠性，减少系统故障和服务中断的可能性。这有助于降低业务中断的风险，提高技术系统的可用性和持续性，保障业务的正常运行。

2. 提高技术投资的回报率：有效管理系统性风险可以降低技术投资的风险并提高回报率。通过规避潜在的系统性风险，可以减少因系统故障或不稳定性而造成的额外成本和资源浪费，提高技术投资的效益和投资回报。

3. 增强技术管理者决策能力：系统性风险管理使技术管理者能够更全面地了解和评估技术系统的风险情况。这有助于他们做出明智的决策，选择合适的措施来降低风险，并确定优先级，以使资源和精力能够最大程度地应对最重要的风险。

4. 提高团队效率：通过管理系统性风险，技术管理者可以减少系统故障和问题的发生，从而减少紧急修复和事后处理的工作量。这使团队能够更加专注于战略性的工作，提高工作效率和生产力。

5. 增加业务可信度：有效管理系统性风险可以提高技术系统的可靠性和稳定性，增加业务的可信度。这有助于提高内部和外部利益相关者对技术部门的信任，加强与其他部门的合作和协调，为企业的可持续发展和成长奠定基础。

6. 促进技术创新和发展：管理好系统性风险有助于为技术管理者提供稳定的技术基础，支持技术创新和发展。他们可以更好地专注于推动新技术的应用、优化现有技术架构和流程，为业务增长提供技术支持和竞争优势。

5.2 业务价值上的意义

从业务价值的角度来看，管理好技术上的系统性风险具有以下意义：

1. 提高效率和生产力：通过管理系统性风险，技术系统可以更加稳定和可靠地运行，减少系统故障和问题的发生，从而减少因为系统问题导致的客诉、修复、沟通等成本。这有助于提高业务的效率和生产力，节省时间和资源，并降低运营成本。

2. 支持业务增长和扩展：有效的系统性风险管理可以为业务提供可靠的技术基础，支持业务的增长和扩展。通过降低系统故障和数据泄露的风险，技术管理者可以为业务提供稳定的平台，支持业务的创新、市场拓展和新产品的推出。

3. 支持业务创新和竞争优势：系统性风险管理为技术团队提供稳定的技术基础，支持业务的创新和发展。通过降低系统性风险，技术团队能够更好地专注于业务创新、新产品开发和市场敏捷性，从而获得竞争优势。

4. 提升用户体验和满意度：系统性风险管理有助于提供稳定、安全和高性能的技术系统，提升用户体验和满意度。用户倾向于选择那些能够提供稳定服务、快速响应和数据安全的产品或服务，有效的系统性风险管理可以增强用户对技术产品或服务的信任和满意度。

5. 降低损失和风险：有效的系统性风险管理有助于降低业务面临的潜在损失和风险。通过识别和管理系统中的风险，可以减少数据泄露、安全漏洞和技术故障所带来的损失，并降低法律诉讼和声誉损害的风险。

6. 提升客户信任和忠诚度：通过管理系统性风险，技术管理者可以建立客户信任和忠诚度。稳定、安全和可靠的技术系统能够增强客户对企业的信心，提高客户满意度和保持客户的长期合作关系。

可以看到如果能管理好系统性的风险，对于技术组织，对于技术管理者，对于业务和业务价值来说，都是一件非常好的事情。从生产效率的提升，到业务稳定性，到对成本的减少以及客户成功都是极好的。

那么如何管理系统性风险呢？

6 如何管理系统性风险

6.1 风险模型

风险模型是风险管理的第一步：理解系统中已有的风险，识别、标记并对已知的风险排列优先级，最终形成一张包含了系统所有已知风险的当前状态的表格。这就是我们所说的风险模型。

建立风险模型的过程是识别风险的过程，在这个过程中我们需要识别出系统中已有的风险，并对其进行分析，标记出优先级、梳理当前状态和历史情况。

风险模型构建过程中需要考虑模型的作用范围，是公司级的，团队级的，项目组的，还是服务级的。

对于一个小公司，可以是公司级的，对于大型一些的公司，可以考虑团队或项目级的。

风险模型至少包括以下一些方面：

• 严重性/可能性：高中低，先评估严重性，再评估可能性


• 风险缓和计划：可以使用的或者正在使用的用来降低该风险严重性或者可能性的风险缓和措施。


• 监控：对该风险的发生是否进行了监控，如果监控了说明监控的指标，如果没有监控，说明原因，以及达成监控目标的原因，最终所有的风险应该是要监控起来的。


• 状态：活跃 / 已缓和 / 正在修复 / 已解决


• 历史风险情况：该风险在历史上有没有发生过，什么时候，发生频率等


• 风险缓和计划：当我们制定风险缓和计划的时候，需要从严重性最高的项开始，缓和风险不是为了消除，而是为了降低风险的严重性和可能性。并不是每一个风险都要制订风险缓和计划。


• 风险预案：当风险发生的时候，我们可以采取的措施

除此之外，还包括一些常规的添加时间，ID，负责人之类的

6.2 识别和评估系统性风险

识别系统性风险是一个关键的步骤，它需要深入分析和理解组织或项目所面临的技术环境和相关因素。以下是一些常见的技术上的系统性风险示例：

• 
  

  依赖单点故障：系统中存在关键组件、设备或服务的单点故障，一旦出现故障，将导致整个系统或业务的中断。例如，网络设备的故障、云服务提供商的服务中断等。

  
  


• 
  

  服务间的强弱依赖：如果系统中的服务之间存在强依赖关系，一旦其中一个服务发生故障或不可用，可能会导致整个系统的故障或性能下降。

  
  


• 
  

  内部和外部/离线和在线业务的相互影响：系统中的离线和在线业务之间存在相互依赖关系，如果其中一个业务出现问题，可能会影响其他业务的正常运行。

  
  


• 
  

  安全漏洞和数据泄露：系统存在安全漏洞或不当的安全措施，可能导致黑客攻击、数据泄露或信息安全问题。这可能对组织的声誉、客户信任和合规性产生严重影响。

  
  


• 
  

  技术过时和不可维护：系统采用的技术或架构已过时，不再受支持或难以维护。这可能导致系统难以升级、演进和修复漏洞，增加系统故障和风险的概率。

  
  


• 
  

  第三方供应商问题：系统依赖于第三方供应商提供的技术、服务或组件，但供应商出现问题，无法提供所需的支持、维护或升级。这可能导致系统中断、服务质量下降或业务受阻。

  
  


• 
  

  文档或流程的问题，如没有文档，没有沉淀，只在某些人的脑袋里面：如果系统或流程存在缺乏文档、知识沉淀或依赖于个别人员的情况，可能会造成知识孤立和团队合作的问题，影响系统的可维护性和可扩展性。

  
  


• 
  

  数据完整性和一致性问题：数据在系统内部或与其他系统之间的传输和处理过程中，可能遭受损坏、丢失或篡改，导致数据完整性和一致性问题。这可能对决策和业务流程产生负面影响。

  
  


• 
  

  大规模系统故障：系统由多个组件、服务或子系统组成，如果其中一个组件出现故障，可能导致整个系统的大规模故障。例如，云服务提供商的故障、硬件故障等。

  
  


• 
  

  法规和合规风险：系统必须符合特定的法规要求和合规标准，如果系统无法满足这些要求，将面临法律风险、罚款或业务停摆的风险。

  
  


• 
  

  服务容量的不足：系统中的某些服务容量可能不足以应对高负载或峰值流量，这可能导致性能下降、响应时间延迟或系统崩溃。

  
  


• 
  

  基建发布或扩容等发布操作会影响业务的情况：系统基础设施的发布操作，如服务器扩容、网络配置变更等，可能会对业务产生影响，例如服务中断或性能下降。

  
  


• 
  

  线上配置/环境/网络等的变更：对线上系统的配置、环境或网络进行变更时，可能会引入风险，如配置错误、网络中断等，导致系统故障或不稳定。

  
  


• 
  

  安全问题：系统面临的安全漏洞、攻击风险或数据泄露等问题可能对业务运行和用户数据安全产生重大影响。

  
  

要识别系统性风险，可以采取以下方法：

• 审查历史数据和经验教训，了解以前的系统故障和问题。


• 进行风险评估和风险工作坊，与团队一起识别潜在的系统性风险。


• 与各个部门和团队合作，收集反馈和洞察，了解系统的弱点和关键风险点。


• 借鉴行业标准和最佳实践，了解常见的系统性风险和应对方法。


• 定期进行系统评估和安全审查，以发现潜在的系统性风险。


• 通过识别系统性风险，组织可以有针对性地采取措施来降低风险，并确保系统的稳定性、安全性和可靠性。

6.3 风险治理

风险治理不是一个一蹴而就的事情，需要持续的来做，需要从组织，流程机制，系统工具和文化层面进行治理。

• 组织层面：一个事情或方案想要比较好的落地，一定是有一个完整的组织来承接，至少需要有 PACE 的逻辑来支撑，明确分工。


• 流程层面：流程层面至少要建立明确的沟通机制，如周报、例会等，同时还需要建议风险控制流程，明确制定风险识别、评估、控制和监测的标准流程，确保风险管理工作的有序进行。


• 系统工具：理想中是希望有建立统一的风险管理信息系统，用于收集、整理和分析风险相关信息。甚至可以利用数据分析和人工智能，对潜在风险进行预测和预警，提高风险应对的时效性。简化版可以通过群、Jira 系统等项目管理工具来达到前期的系统工具落地的程度。


• 文化层面：通过宣导、洞察、关注、固化、奖励等方式引导大家对于风险的关注，将风险意识融入日常工作中，提高大家对风险的认知，强化风险意识。

以上的组织、流程、系统工具和文化层面的治理都是为了更好的管理风险而存在。在这个过程中，风险模型是抓手，通过不停的识别风险，消除风险，缓和风险，不断提高系统变好的可能，以最终达到治理系统性风险的目标。

风险评估和应对规划是一个反复重复的过程，不停的迭代风险模型，识别出新的风险。

当风险模型构建完成后，我们需要定期逐个风险拉出来 review 一次，我们可以问我们自己如下的一些问题：

• 与上次回顾相比，风险有更严重吗？可能性有更高吗？


• 接下来会排专人来解决某些风险吗？是否应该安排？


• 上次回顾安排的事项落实了，对应的风险情况如何，是否有更新到风险模型中？

问完问题，我们可能需要有一些实际的行动：

• 评估是否有新的风险；


• 删除旧的风险：如果风险已经解决了，可以归档；


• 评估原有风险模型中的每一项风险，评估其严重性和可能性，如果有变动，对其进行更新；


• 对于不同的优先级的风险区别对待。

以上的回顾操作我们在上面建设的某个管理系统来承载，并且这个管理系统是带有通知等功能，以更好的将风险相关的信息周知出去，如 Jira 系统。

7 小结

系统性风险是一个动态的概念，持续反复的监测和评估至关重要。定期审查系统的运行情况、漏洞和潜在风险，确保及时发现和解决问题

你是否也经过这样的灵魂拷问：「开发的功能不都是经过上线测试的吗？为什么上线后还会那么多 Bug ？」。

大家明明都很努力，为什么「输出」的结果没有更进一步？今天我们就水一水这个「狗血」话题，究竟是谁个锅？

本篇只是毫无意义的「故事」，内容纯属「虚构」，如有雷同，自己「反思」。

对于这个话题，我想用一个「虚构」的故事来介绍下，这个故事里我有一个「朋友」，他在某电商项目组，当时恰逢经历了公司内部的「双十一需求立项」：

立项时

老板：“这次的需求很简单，主要就是参考去年 TB 的预热活动来走，核心就是提高客单量和活跃，具体细节你们和产品沟通就行”

产品：“TB 去年的活动预热大家应该都了解吧，我们这次主要就是复刻一个类似的活动，时间一个月，具体有***，总的来说，双十一活动一定要准时上线，这次运营那边投入很多经费，需求方面我会把控好，核心围绕老板的思路，细节大家可以看文档，基本就是这些内容，一个月应该够的，大家没问题吧？”

开发：“没问题，保证完成任务”

3 天后：

老板：“我刚看了 JD 好像推出了一个不错的小游戏，我觉得这个可以导入到这边活动里，这样可以提高用户的活跃，用户活跃了，消费自然就起来了”

开会

产品：“鉴于老板的意见，我觉得 JD 的这个游戏活动效果可以提升我们的复购，所以我计划在原本需求基础上增加一个支线活动。

产品：“大家不要紧张，支线会和当前主线同步开发，支线活动比较灵活，不对账号级别做限制，另外「设计」那边看下入口放哪里比较合适。”

开发：“上线时间还是没变吗？”

产品：“双十一日期会变吗？老板说了大家抓紧点，功能不多，时间还是够的”

10 天后：

老板：“我刚和x总沟通了下，他觉得我们的活动少了互动，不利于留存，你看下怎么处理”

开会

产品：“经过这几天和老板的探讨，我们发现这次活动少了一些互动性，必须增加一些交互游戏，这样才能提升日活和用户体验。

产品：“这样吧，这部分功能也是比较迫切，我知道任务比较重，但是为了这次能取到较好成果，大家加把劲，接下来周末幸苦下大家，先不休假，后面调休补回来，具体需求大家可以看文档，有一些调整，不多，时间还是够的”

开发：“。。。。”

14 天后：

老板：“我看大家工作的热情还是可以的，刚运营提了可以增加一些视频支持，我觉得这是一个很好的意见”

开会

产品：“目前看起来我们的开发进度还比较乐观，运营的同学说了他们录制了一些活动视频，我看了还不错，就在主会场增加一些视频播放的功能吧，细节你们直接和设计讨论下”

产品：“这个应该不难吧，把分享和下载加上，视频播放这么基础的东西，应该不耽误事，我看网上开源服务就挺多的。”

开发：“。。。。”

20 天后：

老板：“我刚去开发那里看了下效果，感觉分会场的效果挺好的，做支线太可惜了，给他加回主流程里”

开会

产品：“老板那边觉得分会场的效果更好，让我们把分会场的效果做到主会场里的核心交互里，分会场部分的逻辑就不要了，入口也取消。

产品：“大家不要激动，都是现成的东西，改一改很快的，不过项目进度目前看来确实起有点拉垮，接下来大家晚上多幸苦点，我们晚上11点后再下班，我申请给大家报销打车的费用”

开发：“。。。。”

23 天后：

老板：“整体效果我觉得可以，就是好像有一些糙，你们再过一过，另外大家开个会统一下目标，看看能不能有新的补充”

产品：“可以的，过去我们也一直在开会对齐，基本每两天都会对齐一次”

开会

产品：“我和设计对了下，发现有一些细节可以优化，比如一些模块的颜色可以细调一下，还有这些按键的动画效果也加上，我知道工期紧张，所以我从「隔壁」项目组借了几个开发资源，未来一周他们可以帮助大家缓解下压力”

开发：“。。。。”

28 天后：

开会

产品：“好了，项目可以提测了，相信之前测试也陆续介入跟进了需求，应该问题不大，目前看起来「燃尽图」还可以，测试完了尽快上线，老板那边也在催了”

测试：“不行啊，今天走了用例，一堆问题，而且提测版本怎么和用例还有需求文档不一致，这个提测的版本开发是不是自己没做过测试啊，一大堆问题，根本测不下去，这样我们很难做”

产品：“这个我来沟通，开发接下来这几天大家就不要回家了，马上活动上线，一起攻克难关”

产品：“我也理解大家很努力了，但是这次提测的质量确实不行，你们还是要自己多把把关，不能什么问题都等到 QA 阶段才暴露，这样不利于项目进度，需求一直都很明确，大家把 Bug 尽可能修一修，有什么问题我们及时沟通，尽快解决，敏捷开发”

开发：“。。。。”

上线前一天晚上 10 点：

开会

测试：“不行，还有 20 几个问题没有确认，这种情况我不能签字，上线了有问题谁负责。”

产品：“一些问题其实并不影响正常使用，目前主流程应该没问题，让开发把 P0 的两个问题修了之后先上线，剩下的在运营过程中逐步更新就好了，有问题让运营先收集和安抚”

开发：“上线了脏数据不好弄，会有一些账号同步的问题，而且用户等级可能还有坑”

产品：“没什么不好弄的，到时候有问题的用户让运营做个标志，接下来小步快跑修复就好了，时间不等人，明天就是上线时间， 活动上不去对老板和运营都没办法交代”

项目上线：

老板：“运营和我反馈了好多问题，你们版本上线是怎么测试的，要反思一下xxxx”

开会

产品：“我说过用户要集齐碎片和好友砍价之后才能给优惠券，等级不够的不让他们砍价成功，为什么只完成砍价的新人拿到大额优惠券？”

产品：“什么？因为账号数据绑定有 Bug ，不同渠道用户合并账号就可以满足？为什么会有这个 Bug ，测试那边没覆盖到吗？”

测试：“我不知道啊，需求文档没有说还能账号合并，而且这个功能之前没说过要限制用户等级吧？”

产品：“我出的需求肯定有，文档里肯定有，另外开发你既然知道问题，为什么不提前沟通，现在用户都消费了，这个事故你和测试 55 责，后面复盘的时候要避免这样的问题再次发生”

开发：“。。。。。”

最后

所以大家觉得是谁应该背锅？是开发的能力不够，还是测试用例的覆盖缺失？说起来，其实在此之前，我在掘金也遇到了一个 “Bug” ，比如：

文章 Markdown 里图片链接的 content-type 字段如果不符合 image/*** 规格，那么发布出来的时候链接就不会被掘金转码，所以不会有图片水印，同时直接指向了我自己的图床地址。

那么你觉得这个是 Bug 吗？明明是用户不遵循规范。但是这样不就留下漏洞了吗？

如果在文章审核通过之后，我修改图床上的图片内容，这样不就可以绕过审核在掘金展示一些「违规」内容了吗？

所以有时候一些功能的初衷是好的，但是引发的问题却又很隐蔽，那么这能怪「测试用例覆盖不到位吗」？

那么，你觉得「经过测试，为什么上线后还会那么多 Bug 」

前言

自从毕业开始工作之后，我坚持写了 2 年多的日记，基本节奏是每半年会写一篇，目的是为了记录自己成长的痕迹。

未来某个时间自己再回首的时候，能回味到此时此刻自己在做什么。当时的选择是否正确，是否在此时此刻，看到了未来发展的趋势，跟上了正确的车。

现在是 23 年 6 月，我第一次羊了，上一轮虽然逃过去了，但是这一次没能幸免，现在还在发着低烧。

距离上次写日记又过去了半年多，自己也步入 25 岁，这半年发生了很多事情，体会到时间变得更快了。

工作第一年：误打误撞加入创业公司

在来到字节之前，经历了校招被毁约，来到了创业公司，在创业公司工作了一年，作息是大小周，早 9 晚 9 ，对我来说这是一段比较记忆深刻的经历，教会了我很多互联网行业的东西。

校招被毁约

19 年的时候签约了一家金融公司，也是临近 20 年毕业前几十天，才被公司以疫情经济情况不好的理由，告知单方面毁约。

那个时候的我还是很害怕的，一点是临近毕业，大多校招已停止，第二点是自己有一段时间没有复习，很多知识已经遗忘。

一个朋友得知了我的情况，内推我到一家创业公司，也是内推第二天一大早就去公司面试，还好我还有一些基础在脑子里，现场面了两轮，当场就通过了，成为了前端的实习生一枚，公司也是答应毕业之后就转正。

面试通过之后，第二天就去公司上班了。第一天入职就拿到了 Macbook，也是第一次用 Mac 办公，想象那时的自己，就跟刚进城的人一样。

公司的结构

一个公司，总共就 50 来个人，做着 DAU 百万的产品。由于公司不大，所以做各种不同事情的人（销售、CEO、内容运营、新媒体运营、算法、产品），都坐在一起。敲代码的时候还能听到销售打电话的声音，因为是教育产品，所以销售的合作方大多是猿辅导、好未来、作业帮、学霸君等教育头部公司。

虽然公司小，但是产品各个环节非常全面：

• ABTest


• 算法


• Hive

公司小的好处是，决策层级少，一个想法想要落地是很快的。在公司 1 年期间，快速上线了 3 款小程序，也快速从 0 到 1 上线了金融产品。PC、H5、小程序开发都有涉及。

整个团队的氛围是非常 Open 的，可以试验各种新技术，不像大厂内部会封装一些框架，有内部标准，不好去实践一些开源的框架。

与普通公司不同的地方

个人扮演的角色

我觉得最大不同的地方是角色，我是一名前端，但不仅扮演着前端的角色。要对产品体验负责，也要自己设计页面 UI。

公司没有测试，所以在日常开发中，每个研发和产品都是 QA，要对 C 端百万 DAU 产品对应的用户体验负责。

每个人都对需求负责，一个需求上线之后，可以自己写 SQL 去 Hive 里捞埋点数据，验证 AB 的可行性。

可以深入感受互联网不同角色发挥的作用

在创业公司，因为每周都有公司周会，大家会聚在一起聊每周各部门的进展，在会上，也可以全流程的了解到一个产品的完整生命周期。

• 
  

  内容运营视角：

  
  
  
  
  • 做公众号，发文章，在存在粉丝基础的情况下，头版收入是很可观的，可以达到 6 位数+。
  
  
  
  


• 
  

  产品运营视角：

  
  
  
  
  • 做竞品分析，看出对方哪方面做的好，我们要抄袭哪快的功能。
  
  
  • 做电话回访，了解用户的痛点，尤其针对停留时间较长的重度 C 端用户。
  
  
  
  


• 
  

  销售视角：

  
  
  
  
  • 通过和大型教育机构合作，由于家长是很愿意为孩子进行教育付费的，所以通过弹窗收集信息配合电销，可以达到很可观的收入。
  
  
  
  


• 
  

  算法视角：

  
  
  
  
  • 通过 AB 试验调整算法策略，可以优化广告收入，另外也可以提前计算预测插入广告可能带来的收益。
  
  
  • 调整算法策略，也可以优化用户停留时长，增强用户粘性。
  
  
  
  


• 
  

  数据分析：

  
  
  
  
  • 通过 Hive 离线数据计算，可以生成一些报表数据，给提供用户信息聚合查看功能。
  
  
  
  


• 
  

  产品视角：

  
  
  
  
  • 在产品基本功能打磨完毕后，要尽可能往付费方向引导。
  
  
  
  


• 
  

  运维视角：

  
  
  
  
  • 将服务迁移到 K8S 集群，可以降低维护成本。
  
  
  
  


• 
  

  后端视角：

  
  
  
  
  • 和算法、数分团队配合，另外还需要负责机器运维相关。
  
  
  
  


• 
  

  老板视角：

  
  
  
  
  • 关注一些重要事项的进展，以及查看上线后的数据，是否符合产品预期。
  
  
  • 最终产品需要自负盈亏，功能不能一步设计到位，也需要把一些功能做成付费使用的。
  
  
  • 关注公司每个方向资金支出情况，控制公司收支，避免快速花光融资资金。保持自己的股份不被过度稀释。
  
  
  
  

我的直观感受是，自己虽然初入茅庐，但通过这一年的感知，深入理解了 C 端产品的全流程。这对我来说也是一笔很大的财富。

营收方面

App 内广告占大头，开屏广告>插屏广告>贴片广告，其次公众号文章等也是赚钱的利器，销售带来的收益远不如以上两个。总共这些一个月7位数还是有的。实际上最大的开销除了人力成本，还是服务器的成本，这个成本逼近7位数。

创业公司的生命周期

1. 公司在快速发展期，有很多功能需要开发，这时是需要人的时候，会无限招人。


2. 在产品 2-3 年之后，如没有新的大方向，进入一段停滞期，指的是 DAU 的不增长或下降。


3. 产品稳定期，不再需要人，核心骨干退出团队，HC 缩减，产品转向以盈利为目标。


4. 自负盈亏，break even。不再为公司资金发愁，不再需要融资。


5. 保持公司运作，通过手段维持 DAU 和用户付费意愿，通过一些预消费手段留住用户，扩大收益。

快速验证

快速验证是 CEO 经常提的一个点，不过在王兴和张一鸣成功的经验来看，这也是正确的。

快速验证是说快速从 0 到 1 上线一个产品，冷启动或硬广，在短期查看一个产品的数据，如果产品数据不够理想，便放弃产品。试验下一个风口上的题材。

像美团，或者字节现在也在使用这种策略，快速上线 App 并试错，留下那些抓住用户的产品。

公司的瓦解

一个产品的瓶颈

当一个产品被打磨到 3 年之后，一般来说主流程就比较完善了，换句话说是用户需要的功能，产品都有了。这个时候也就过了 PM 发力 RD 开发的时期，在这之后即便这个公司只有运营，也可以保持产品正常运行。

创业公司的问题

CEO 的话语权会很大

一个人带来的决策不一定合理，当产品的发展不再合理时。大家会出现不满情绪，久而久之大家也不再团结协作，在快速上线几个小程序无果之后，3 个月内 50% 的研发团队成员纷纷离职了，不过大伙也很厉害，离职之后大多都去了大厂。

转变方向为营收优先

通过缩减一系列支出，想方设法让公司达到赚钱的状态。

手段有：砍 HC，团建，下线产品不需要的费钱的功能。

另外我也是一步步看着，公司从半层多楼的工区面积，变成 5分之二，4分之一的大小，最后工区被卖掉，撤离北京。

我的离开

我的离开也是必然，在后期被拉到老板的新产品线帮忙做产品从 0 到 1 建设。对当时工作还不到 1 年的我来说，还是很有压力，独自 own 一个私人银行项目。

在长时间宣传下，仍是没有用户使用，我能明显的感受到，新产品前景是渺茫的，只是老板的一厢情愿。另外新产品线的研发非常少，只是一番的催活，其实过程也决定了结果，产品是做不成的。在这种情况下，我提出了离职。

不过我也很感谢这段经历，能让我对从 0 到 1 创业有新的理解，另外也锻炼了我的抗压能力，增强了技术积累。

最近的工作

工作上

工作上在建设插件市场，提供了一种能快速开发页面组件的方式，能直接嵌入组件到前端中，类似动态执行模块联邦注入的组件。是一块很有意思的功能，类似于 Chrome 应用商城，其实开发工具建设一直是我比较喜欢也擅长的方向，未来也会继续在这方面努力，学习其它语言，做更快更高效的工具，为开发提效。

详细可以看这篇我今年写的文章 带你从 0 到 1 实现前端「插件市场架构」

能力提升方面

编程技能

学习并实战了以下技能：

• VSCode 插件开发
  
  
  
  • 实践开发插件 VSCode 插件开发
  
  
  
  


• Rush.js
  
  
  
  • 大型项目构建管理。
  
  
  
  


• Golang (MySQL / Redis / Kafka)
  
  
  
  • 主要还是 API 层面的熟悉，目的还是为了能用非 NodeJS 语言写一写后端，以及了解更多的后端知识。
  
  
  
  


• Rust
  稍微了解了一下语法，之前也写了一篇文章：以 JS 的视角带你入门 Rust 语言，快速上手

开源库

轻量的模块联邦

非编程相关

最近这 2 年，锻炼了画图、写 PRD、拉通对齐的能力，大厂更加专精一个方面，这让我能静下心来，不再像创业公司一样，受老板的影响，不再做快速迭代的事情，而是把产品打磨好，更加以用户角度出发思考用户需要什么，补齐什么功能。

愿望

毕业之后，由于疫情一直都是在国内旅游。还没出过国，希望疫情后每年自己都能出去走走，行万里路。把最好的景色都记录下来，拓宽眼界，放松心情。我很喜欢大海，尤其是四环环海的小岛，看着大海能让自己的心平静下来。接下来还有几个非常想去的地方、意大利、冰岛、新西兰、瑞士，夏威夷，希望能在 3

作为一名程序员，我们经常会面临工作压力和时间紧迫的情况，因此有一个好的自控力对于我们的工作和生活都是至关重要的。以下是一些可以帮助程序员增强自控力的方法：

1. 设定明确的目标和计划

制定明确的目标和计划可以帮助我们更好地管理时间和精力。我们可以使用日程表、任务清单、时间追踪工具等，来帮助我们控制时间并更有效地完成任务。

2. 掌控情绪

作为程序员，我们需要面对很多挑战和压力，容易受到情绪的影响。因此，掌握情绪是一个非常重要的技能。可以通过冥想、呼吸练习、运动等方法，来帮助我们保持冷静、积极和乐观的心态。

3. 管理焦虑和压力

焦虑和压力是我们常常遇到的问题之一，所以我们需要学会如何管理它们。我们可以使用放松技巧、适度锻炼、交流沟通等方法，来减轻我们的焦虑和压力。

4. 培养自律习惯

自律是一个非常重要的品质。我们可以通过设定目标、建立规律和强化自我控制等方式，来培养自律习惯。

5. 自我反思和反馈

经常进行自我反思和反馈可以帮助我们更好地了解自己的优缺点和行为模式。我们可以使用反馈工具或与他人交流，来帮助我们成长和改进。

6. 持续学习和自我发展

程序员需要不断学习和自我发展，以保持竞争力和提升自己的技能。通过阅读书籍、参加培训、探究新技术等方式，可以帮助我们持续成长，增强自我控制力。

结论

自控力是我们工作和生活中重要的的品质之一，可以帮助我们更好地应对各种挑战和压力。通过设定目标、掌控情绪、管理焦虑和压力、培养自律习惯、自我反思和反馈、持续学习和自我发展等方法，我们可以帮助自己增强自我控制

前言

距离上一次的年中总结已经过去了一年，来深圳的日子也即将一年过半，看了看去年的年终总结，基本上已经全部完成，除了依然没吃胖点，反而有了两三次低血糖之外(T＿T)。

工作

去年2月26上完最后一天班晚上到的深圳，3月8号来现在的公司入职（印象比较深是因为入职当天有500的女神节红包，哈哈哈）。

今年年初的时候，公司换了办公地方，再也不用过地铁转公交的日子了(^▽^)，现在可以从坪洲坐8站直接到深大，通勤时间少了一点；

年后陆陆续续做了三四个公司内部用的系统，用到了一个腾讯的UI框架，使用感还不错，顺便学习了TDesign 提供了一个脚手架 tdesign-starter-cli，通过它来初始化项目，有兴趣的可以看看（新手不会搭建脚手架的可以做个参考）。

上个月调薪（10%），虽然没有预期的涨薪幅度高，不过涨了总比不涨好（O(∩_∩)O哈哈哈~），经过一次涨薪，也明白了这个涨薪幅度跟什么有直接的关系，如果明年年初不跳槽的话，到年中的时候能涨个15%吧，虽然不多，但是福利好，工作不多，不加班，如果明年离职，掘友们有兴趣的话，可以来找我内推(^▽^)。

学习

今年在一边工作之余，也一直有在坚持学习，当然有时候还是会摸鱼偷懒（捂嘴笑（^▽^））。

1. 
   

   收货

   
   
   
   
   • 输出30余篇文章（不过写的水平很一般，基本上都是记录自己的学习，没有给广大掘友带来什么收货）
   
   
   • 学习了vue3
   
   
   • 学习了react（不精通）
   
   
   • 学习了react native（为了接项目挣钱）
   
   
   • 接了个小程序的项目，顺道回顾了小程序的写法（长时间不写，真的会忘记）
   
   
   
   


2. 
   

   不足

   
   
   
   
   • 学习的vue3一直拖延重构，没有实际用到项目中去
   
   
   • react前面学着，后面忘着（记性真的差）
   
   
   
   

生活

早上一口气写完了这半年的工作和学习，到了生活这里，好像卡壳了——

1. 
   

   吐槽

   
   

   好像没什么说的，又好像想说的很多，今年这半年，是对这慢无休止的疫情最烦闷最讨厌的半年，马上快八月了，核酸做的已经变得麻木，想必辛苦做核酸的护士们也麻木了吧，这么热的天气做的一次比一次敏捷（敷衍），从年后回到深圳，基本上一天一做，最少的时候三天要做一次。

   
   

   后来上海疫情爆发，封城，看着曾经的朋友们封城后的生活，心情五味杂陈，难以言说（此处省略500字）。

   
   

   吐槽结束，把刚刚的丧收起来。

   
   


2. 
   

   平淡

   
   

   其实除了疫情，无休止的核酸，就是工作，出租屋两点一线的平淡了；趁着清明，和朋友们一起自驾游了一次，我是纯游，因为有俩司机开车，哈哈哈哈。在五一也去了一直没去的珠海玩了一趟，虽然上了外伶仃岛，被困在岛上了，但在海边，心情真的有被治愈。

   
   

   图片放到文章最后啦！

   
   

总结

曾经看到的一句话：

生活可以忙忙碌碌随大流，思想必须偷偷摸摸求上进

其实以前挺不喜欢这种生活方式的，后来发现自己也是这样的活着，还是和去年文章中一句话说的那样：

行到水穷处，坐看云起时是选择，卧薪尝胆，三千越甲可吞吴也是选择，怎么选，都有理，怎么选，都对

因为我们都在为自己想要的生活，或努力或躺平着。

接下来，还是该工作工作，该学习学习，该玩玩，该吃吃，该喝喝。

晒图

1. 清明——潮州-南澳岛
   

2. 五一——珠海-外伶仃岛

3. 吃吃喝喝

提到实事求是，大家第一时间会想到什么？我想大部分是客观，事实，脚踏实地？这么一想，大家都会觉得，自己挺实事求是的呀，没毛病。但是，我会经常在工作中感受到不是那么实事求是的行为，比如张嘴就来，不带思考，做事全靠猜的行为，真太多了。

随着我这两年的学习和总结，我越发觉得实事求是非常重要，并把它视为我做事情和成长的基石。对于实事求是，我主要有以下 3 层理解。

首先，尊重客观事实，探寻真理。我们要承认事实，即使这个事实有多么的难以置信，但存在即是合理，我们首先要尊重它，承认它。然后我们还要积极主动地面对它，探寻事实背后的真理，获得真知，这样才能真正的成长，并有可能寻得机会。当某个事情的进展超出自己预期的时候，我们正确的态度应该是思考为什么会这样，而不是去想对错得失。

其次，数据说话，数据驱动。事实如何去量化？答案是数据。使用数据去表达事实，是我们程序员应该有的技能。工作的本质就是解决问题，之前的文章有讲解，问题就是理想状态和现实状态之间的差别，因此，我们在工作当中做的每一项决策的依据、制定的每一个目标，都应该用数据说话。我们应该使用数据表达现状，并使用数据衡量目标，驱动自己去工作。一些沟通的细节就能够体现出他是不是在实事求是地工作，比如“这个页面加载太慢了，需要优化”。那这个页面加载到底有多慢？业界标准或者竞品的加载耗时是多少？优化的目标值是多少？

最后，从客观事实中获取反馈，不断迭代。工作中想要获得成功和成长，最核心的一个环节是反馈。很多人没有意识到这点。更多的人没有意识到的是，获取反馈其实很简单，随处都是。敏捷开发、精益创业、增长黑客，这些理论的底层核心都是基于事实和数据的反馈，不断迭代改进自己的产品，从而获得成功。对于个人成长来说也是一样的，我们要从客观事实中获取反馈，思考总结，不断迭代自己的能力。

总结一下，实事求是地工作有 3 个层次，首先，要正视事实，并主动探究真理；然后我们慢慢地开始用数据驱动自己的工作；最后让数据驱动变成循环，不断迭代，并把这种循环融入到各个方面，包括工作和个人成长，让它成为自己下意识的动作。

我在努力学习和践行实事求是地工作，我也希望我的团队可以用实事求是的态度来工作，以此文共勉！

前言

现在好多人说程序员的红利时代已经过去

• 裁员的企业比比皆是


• 简历投出去基本没人理，2,3个月能找到工作就不错了，而且还是降薪


• 有重点学校毕业的也只能找到外包的工作


• 千万别学计算机相关专业，无异于50年加入国军


• 车贷，房贷都要还，降薪我也接受

等等上面现象都是我或听说或看到的，或亲身经历的。

现在行业不景气，也不知道是否有恢复生机的一天，或者也许一直会走下坡路，也触动着你我的神经。

真实经历

去年年底的时候我为我们公司面试员工，通过率变得很低，所以面试难度要相对加大，有一次面试一个女生，她技术我觉得一般，感觉没怎么准备，八股文也没有背熟，所以我给了她一些建议，然后我问了一下她从上一个公司的离职原因，她说是被裁掉了，然后说现在找工作很困难，已经找了很长时间了，上家公司工资16，现在要12,13好多公司都还在压价，她说主要现在有车贷，房贷，还有小孩，所以迫不得已得赶紧找到下一家，所以薪资她一降再降，只希望能快点找到工作，等等，说了很多。

非常同情她的遭遇，但是遇到现在行业不景气，而且技术也一般，所以这就很难受，感觉她的焦虑要比平常人大很多，因为还有车贷，房贷，小孩的原因在里面。说到这里屏幕前的你是否有些焦虑呢？

焦虑由来

如果我们踏入程序员这一行业，那么就意味着终生学习。如果平时喜欢躺平，喜欢摸鱼，那么随着年龄的增大，或者行业不景气，焦虑就会不断找上你。用大多数的人来说，'这个行业就是吃青春饭的'，可能在行情好的时候，有些人感觉不出来，觉得自己没有问题的，能干到40岁，但是行情下滑，失业率加大的时候，可能这个问题又会被放大。但是焦虑一定就是坏事么？

什么是焦虑？

引用百度百科里的解释：

焦虑是人对现实或未来事物的价值特性出现严重恶化趋势所产生的情感反映 。与之相反的情感形式是企盼，即企盼是人对现实或未来事物的价值特性出现明显利好趋势所产生的情感反映。

焦虑是指个人对即将来临的、可能会造成的危险或威胁所产生的紧张、不安、忧虑、烦恼等不愉快的复杂情绪状态。

所以我的意思还是希望大家能够主动拥抱变化，主动改变自己，行动起来，那么问题又来了，我们努力的方向在哪里？努力是有方法的，努力要选择好努力的方向，否则辛苦付出了，收获并不会很大。所以说到这里你是否又开始迷茫了？

你是否有这种迷茫？

在技术的学习中大家应该有过下面这种现象，有的同学感觉付出了很多努力，但是收获很少。尤其进阶阶段，研究源码阶段，精通阶段等等，付出了大量时间，但是收效甚微，有时候我们就会产生这样的想法，我选择的这条道路对么？为什么感觉自己还是很菜？我花这么多时间研究源码干什么？

于是这个时候你开始变得焦虑，迷茫？想想工作1，2年的程序员2周就能学会vue并上手了，而你花了相同的时间看了《javascript高级程序设计》这本书还不到20页, oh my god, 这样下去会不会下一个被裁的就是我

这个时候在我脑子里浮现了一个问题'你说工作7,8年的程序员相对于工作两三年的程序员优势在哪里呢？'

如何选择好以后的道路

针对程序员该如何选择自己的道路，我采访过一些工作比较久的程序员。

我的问题是这样的

'你说工作7,8年的程序员相对于工作2,3年的程序员优势在哪里呢？'

下面是一些回答

有的人觉得优势是经验，包括成本预估、架构策略、性能评估、风险评估等, 但是除了这些也不得不承认其他基本都是劣势

有的人觉得工作5年的程序员应该达到技术的至高点，根据统计学规律，程序员以后主要往两条路发展，一种是系统架构师，一种是业务负责人，要早做规划

还有的人说找准目标，缺啥补啥，当然目前是根据环境动态调整的，先把自己能把控好的事做好，大环境不好就降低目标，也能把更多精力放到其他上面

还有的人给出了更加详细的解答

    1、更多关注全局架构的精力超过专注细节的精力

    工作早期，接到的任务大多是单点的功能模块和系统，更多关注编码、技术实现问题。

    工作7、8年会，会逐渐承担整块的业务，进而会从业务的整体角度来思考系统的架构，目标从“实现某个功能”转变到“支撑某个业务”，把业务当作整体来看，视角逐渐从“语言、框架、数据库”转换到“通信、架构、安全合规、网络、数据”。



    2、意识到对技术的表达能力很重要

    这不是指为人处事的沟通表达能力，而是对技术的表达能力；

    例如更加关注流程图、架构图，不再排斥ppt、文档，会更多思考怎么更加准确、简洁的描述出你的系统架构、业务流程，能够让合作方、上下游更加准确的理解你的思路和设计，更加高效的合作，避免出现理解偏差。

    例如编码，早起很喜欢炫技，喜欢各种高大上的编码风格，例如各种函数式语法，工作久了就不再喜欢追求这些，更加看重你的代码是否能够很容易理解，是否足够健壮，能够被测试到，特殊逻辑能否充分注释；



    3、不再纠结于单点的性能提升

    新人很容易陷入性能崇拜，过分关注有限的性能优化，为了有限的性能提升，直接在db层面写复杂的sql直接处理，导致代码可读性变差。

    后来会更加关注有限在符合基础性能的前提下，优先满足业务的诉求，再根据业务的特性、预判一段时间内的发展，适当的在性能和可读性、可复用性上做一定的取舍。



    4、更加追求简单的架构、代码

    好的代码、架构一定是简洁的，如果一段代码、设计很多人不容易理解，那么这样的设计迟早会出问题。

    给你的上下游以简洁、清晰的接口、文档和功能，避免给到用户各种条件选择，避免过度原子化拆分，在可拓展性、易用性方面需要做取舍，

在这里非常感谢以上各位的回答，相信上面的回答能帮助大家或多或少的解决努力方向的问题

just do it

首先说明一点，没有人不迷茫的，大家都第一次做人，怎么会知道接下来每一步该怎么走呢？

有一个人十分崇拜杨绛。高中快毕业的时候，他给杨绛写了一封长信，表达了自己对他的仰慕之情以及自己的一些人生困惑。

杨绛回信了，淡黄色的竖排红格信纸，毛笔字。除了寒暄和一些鼓励晚辈的句子外，杨绛的信里其实只写了一句话，诚恳而不客气：

“你的问题主要在于读书不多而想得太多”。

参考

• 冴羽答读者问：怎么才能不焦虑？<
  
  作者：为了摸鱼而战
  来源：juejin.cn/post/7239633419784405047
  /a>

这是一个全新的平台。熟悉的框架和工具。请准备好为 Apple vision Pro 设计和构建全新的应用程序和游戏世界。

沉浸的光谱。

Apple vision Pro 提供无限的空间画布供您探索、试验和玩耍，让您自由地完全重新思考您的 3D 体验。人们可以在与周围环境保持联系的同时与您的应用互动，或者完全沉浸在您创造的世界中。您的体验可以是流畅的：从一个窗口开始，引入 3D 内容，过渡到完全身临其境的场景，然后马上回来。

选择权在您手中，这一切都始于 visionOS 上的空间计算构建块。

窗口（Windows）

您可以在 visionOS 应用程序中创建一个或多个窗口。它们使用 SwiftUI 构建，包含传统视图和控件，您可以通过添加 3D 内容来增加体验的深度。

体积（Volumes）

使用 3D 体积为您的应用添加深度。 Volumes 是一种 SwiftUI 场景，可以使用 RealityKit 或 Unity 展示 3D 内容，从而创建可从共享空间或应用程序的完整空间中的任何角度观看的体验。

空间（Space）

默认情况下，应用程序启动到共享空间，在那里它们并排存在——很像 Mac 桌面上的多个应用程序。应用程序可以使用窗口和音量来显示内容，用户可以将这些元素重新放置在他们喜欢的任何位置。为了获得更身临其境的体验，应用程序可以打开一个专用的完整空间，其中只会显示该应用程序的内容。在完整空间内，应用程序可以使用窗口和体积、创建无限的 3D 内容、​​打开通往不同世界的门户，甚至可以让某人完全沉浸在某个环境中。

Apple 框架 - 扩展空间计算

SwiftUI

无论您是要创建窗口、体积还是空间体验，SwiftUI 都是构建新的 visionOS 应用程序或将现有 iPadOS 或 iOS 应用程序引入该平台的最佳方式。凭借全新的 3D 功能以及对深度、手势、效果和沉浸式场景类型的支持，SwiftUI 可以帮助您为 Vision Pro 构建精美且引人入胜的应用程序。 RealityKit 还与 SwiftUI 深度集成，以帮助您构建清晰、响应迅速且立体的界面。 SwiftUI 还可以与 UIKit 无缝协作，帮助您构建适用于 visionOS 的应用程序。

RealityKit

使用 Apple 的 3D 渲染引擎 RealityKit 在您的应用程序中呈现 3D 内容、​​动画和视觉效果。 RealityKit 可以自动调整物理光照条件并投射阴影、打开通往不同世界的门户、构建令人惊叹的视觉效果等等。为了创作您的材料，RealityKit 采用了 MaterialX，这是一种用于指定表面和几何着色器的开放标准，由领先的电影、视觉效果、娱乐和游戏公司使用。

ARKit

在 vision Pro 上，ARKit 可以完全了解一个人的周围环境，为您的应用提供与周围空间交互的新方式。默认情况下，ARKit 支持内核系统功能，您的应用程序在共享空间中时会自动受益于这些功能——但是当您的应用程序移动到完整空间并请求许可时，您可以利用强大的 ARKit API，例如平面估计、场景重建、图像锚点、世界轨道和骨骼手部轨道。所以在墙上泼水。从地板上弹起一个球。通过将现实世界与您的内容融合在一起，打造令人惊叹的体验。

Accessibility

visionOS 的设计考虑了可访问性，适用于希望完全通过眼睛、声音或两者的组合与设备交互的人。对于喜欢以不同方式导航内容的人，Pointer Control 允许他们选择食指、手腕或头部作为替代指针。您可以使用已在其他 Apple 平台上使用的相同技术和工具为 visionOS 创建易于访问的应用程序，并帮助使 vision Pro 成为每个人的绝佳体验。

您需要的所有工具。

Xcode

visionOS 的开发从 Xcode 开始，其中包括 visionOS SDK。将 visionOS 目标添加到您现有的项目或构建一个全新的应用程序。在 Xcode 预览中迭代您的应用程序。在全新的 visionOS Simulator 中与您的应用程序交互，探索各种房间布局和照明条件。创建测试和可视化以探索空间内容的碰撞、遮挡和场景理解。

reality composer Pro

探索全新的 reality composer Pro，旨在让您轻松预览和准备 visionOS 应用程序的 3D 内容。随 Xcode 一起提供的 reality composer Pro 可以帮助您导入和组织资产，例如 3D 模型、材料和声音。最重要的是，它与 Xcode 构建过程紧密集成以预览和优化您的 visionOS 资产。

Unity

现在，您可以使用 Unity 强大、熟悉的创作工具来创建新的应用程序和游戏，或者为 visionOS 重新构想现有的 Unity 创建的项目。除了熟悉的 Unity 功能（如 AR foundation）之外，您的应用程序还可以获得 visionOS 的所有优势，例如直通和动态注视点渲染。通过将 Unity 的创作和模拟功能与 RealityKit 管理的应用程序渲染相结合，使用 Unity 创建的内容在 visionOS 上看起来和感觉起来就像在家里一样。

您的 visionOS 之旅从这里开始。

visionOS SDK 本月晚些时候与 Xcode、visionOS 模拟器、reality composer Pro、文档、示例代码、设计指南等一起发布。

为 visionOS 做准备

无论您已经在 App Store 上拥有应用程序，还是这是您第一次为 Apple 平台开发应用程序，您现在都可以做很多事情来为 visionOS SDK 的到来做好准备。了解如何更新您的应用程序并探索现有框架，让您更轻松地开始使用 visionOS。

Prepare for visionOS

了解 visionOS

visionOS 拥有一流的框架和工具，是帮助您创造令人难以置信的空间体验的完美平台。无论您是在构想游戏、构建媒体体验、设计与 SharePlay 的连接和协作时刻、创建业务应用程序，还是更新您的网站以支持 visionOS，我们都有会议和信息来帮助您制定计划。为第 46 场 WWDC23 会议准备好 visionOS SDK，以帮助您了解平台开发、空间体验设计以及测试和工具。

Learn about visionOS

与苹果合作

在为 visionOS 开发应用程序和游戏时，获得 Apple 的直接支持。了解即将举行的活动、测试机会和其他计划，以支持您为此平台创造令人难以置信的体验。

Learn about working with Apple

#visionOS #苹果MR #苹果VR #苹果AR

不知不觉回到哈尔滨工作三年了，经历了两家公司，最近又燃起了换工作的心思。都说人挪活、树挪死，所以，我还想要活着，甚至获得更好一点，只能选择挪一挪，说句不好听的，这就有种矮子里拔大个的感觉。

概述

稍微熟悉哈尔滨的人都应该知道，哈尔滨是座没有互联网的城市。回溯过去的十几甚至二十年，哈尔滨整体的软件行业基本处于停滞的状态。每年的各种互联网公司排行，独角兽公司排行甚至从没有出现过哈尔滨这三个字眼。被人们所熟知的BJTA等互联网巨头，他们甚至没有在哈尔滨这座城市扎根的丝毫想法。当然，我指的是研发团队，毕竟研发才是整个互联网公司的核心，他们支撑着公司各条业务线的运转。

你可能会说，没有大厂的城市多了去了。确实如此，但是哈尔滨作为最北方的省会城市，有着美丽的称号东方小巴黎，作为二线城市中排名靠前的城市，软件行业的发展确实是没有进步。最近几年，同为二线城市的成都、武汉、西安等城市的发展可谓是突飞猛进，一跃成为新一线城市，工作机会与工资水平大大提升。然而作为共和国长子中的省会城市，却在原地踏步，夸张点说，甚至是在退步！

城市表现

随着2022年全国城市商业魅力排名的发布，我们清晰的看到，全国共有4个一线城市，15个新一线城市，而哈尔滨不出意外的出现在二线城市当中，且排名二线城市的第9位。更夸张的是，东北竟然无一城市入选新一线，去年杀入榜单的沈阳今年也铩羽而归了。

2020年时，全国千万级人口城市有18个，其中就有哈尔滨，到了2021年，哈尔滨居然跌出了这份榜单，全是常驻人口为988.5万，且全是人口增长率为-2%。那么你不禁要问，人口去哪了？为何会越来越少？

我愿意用恶劣这两个字来形容如今哈尔滨年轻人的工作环境。2022年哈尔滨工资全国排名第38位，7160元，乍一看，这个水平不低了，确实，但是你真正了解就会发现，工资区间在3k~5k的人大有人在，他们同样是大学毕业，活力满满的年轻人，但是却没有机会获得一份高薪水的工作，甚至五险一金都是奢望。高收入人群虽然是少数，但是他们的工资却达到普通人的几倍，甚至十几倍。你会说，低收入的人还是没有能力，然而真的如此吗？

对比其他新一线城市，哈尔滨还是差了太多，我指的工作的机会。人确实有优秀的人，也有相对差一些的人，但是他们的层次也不至于相差十几倍这么夸张。但是在哈尔滨恰恰就是这样一种体现，年轻人甚至没有机会去展示自己的能力。

绝大多数的企业，高层都是在公司深耕多年的老人，他们的存在注定年轻人没有取代他们的机会，这并不是一个完全靠能力就能上位的城市。公司内部没有明确的晋升机制，没有规范的涨薪条例，更没有给你预留以后的位置。

软件行业的工资水平，远远低于行业的平均值。3~5年的程序员工资水平大约在7k-9k，5-10年的大约水平在11-15k左右。这种水平在一线甚至其他新一线城市已经是低薪了。毫不夸张的说，这还是不错的那些程序员能够拿到的薪水。

技术水平

既然咱们是程序员，那就来聊聊哈尔滨的程序员水平如何。

2019年我刚回到哈尔滨，面试过几家公司，对于技术层面的面试基本都是皮毛，仅限于是否使用过哪些工具？用过哪些方法？如何写一个sql？

是否觉得现在面试还有如此不卷的公司？有，而且在哈尔滨90%都是这样的。虽说整体面试难度看起来不大，也很好通过，但是你觉得仅凭如此，能获得不菲的薪水？当然，基于这种环境，你就不可能获得高薪水。因为你的面试官根本也不懂更深层面的内容。如果一个饱受面试摧残的程序员来到哈尔滨面试，我相信你会发现一个新大陆。当你面试入职后，你甚至会不屑于与他们讨论技术原理性问题，因为他们根本不懂。

我作为一个后端开发，竟然遇到这样一个面试题：会用div画三角形吗？你能相信这是一个哈工大博士生，且工作10余年的java程序员能问出来的问题？

在目前的微服务发展形势下，当然也有不少公司开始使用这些技术，然而他们不是基于业务去拆分，而是基于功能，你能想象到的是，原本没有多少功能的系统，生生拆出十几甚至二十个服务，上线后每天的用户量，用一个手指就可以数的过来。当然，有部分程序员还是有理智的，不会认同你们leader的这种恶劣行为，但是你的反对不会有效果。

有一句话，我听得时候很不屑，现在想想，这就是现实！你学这些干啥？学了你也用不上。确实，很多东西学了你也用不上。说个简单的方面，哈尔滨企业的容器化，或者云化的程度微乎其微。且大部分功能在领导看来能用就可以。

长期在哈尔滨的程序员，经过这种环境熏陶，相当于浪费生命，真的好比坐井观天，他们如果出去其他新一线城市，相信必然会感叹程序员居然是这样的？

新的机遇

那么，哈尔滨软件行业到底有没有新的机遇？前一段时间相信哈尔滨人都知道的一个新闻，六大巨头宣布与哈尔滨达成深度合作，其中包含华为,百度,京东,腾旭,中兴,中科。初一听，这好像确实是对哈尔滨的好消息，这几个公司基本都是行业的领头羊，如果他们到来必定能够带来不少的就业岗位，提升一定的经济增长。

但是细细观察你会发现，最高兴的人无异于房地产行业，似乎踩到他们的尾巴一般，各种营销号，短视频不断的四处宣扬。但也不得不说，疫情导致哈尔滨的商业难以开展，所有的行业都停滞了，他们也像找到了救命稻草。

但是我却并不很看好这次机会，从本质来说，这六个企业能来，还是黑龙江政府给到了足够的吸引力，提供了强大的政策支持，不然我不认为会有企业发善心一样的去带动你你们的经济发展。

另外，本次六个企业的到来，至少我不认为是软件从业人员的机遇，研发团队无论从质量，还是数量，相比于其他城市，哈尔滨还是有很大的不足的。即使有，我觉得也只是外包团队，而不会是核心研发团队。

在从目前公布的几个公司的业务方先来看：华为在算力中心、人工智能、人才培养，百度在“一基地、三中心、七平台”，京东在“一店、一基地、一底座、一战略、三平台”，腾讯在数字转型、生物医药、创意设计，中兴在5G产业链，中科在咨询智库、数智制造业等方面提出落地诉求。在我看来特别像是老板在给我们画大饼。

如何找工作

不管以后如何发展，现在还是要找一分稳定的工作。作为程序员，我还是总结一下几个重要的方面：

1、技术方面，即使处于哈尔滨这种躺平的环境，还是要不断的学习的。深度与广度同样重要，可以让你在工作当中得心应手，有更多的解决方案，也就意味着有更多被领导关注的机会。平时的沟通中，能更多的体现你的技术能力，将会使你在领导的印象里增加重量。同时在面试时，你技术能力的体现，还是有助于获得相对高一些的薪水。

2、工作环境。目前很多企业克扣员工较为严重，名义上双休，实际单休；加班、出差严重，且没有加班费，调休等机制；五险一金按照最低工资标准缴纳，设置有些工资没有一金；领导PUA严重，公司氛围沉闷，逢场作戏，拍领导马屁层出不穷。选择的时候慎重考虑。

3、工作距离。目前哈尔滨的地铁建设、覆盖程度不高，虽然公交线路较多，但是堵车较严重。大部分公司聚集在香坊开发区，松北等较远地带，没有地铁，但是部分公司带有通勤车，考虑目前的油价和你的薪水，建议慎重考虑出行方式。

4、薪水提升。在哈尔滨，想要薪水double，基本没有可能，涨个三五千就算不错的，如果有这种机会，且考虑我前面分析的三个方向，基本符合你的设想，别犹豫。虽然有可能是坑，但也是能拿到更多钱的坑。

总结

工作之余，闲聊而已。希望给在哈尔滨的同仁们，和即将回来的同仁们一点参考。虽然咱们哈尔滨环境不好，但是在吃这方面还是顶呱呱的。如果您有幸进入国企，或者拿到公务员的铁饭碗，作为养老城市还是不错的选择。也希望咱们哈尔滨能够越来越好吧，不要让年轻人无奈的离开。

作为一名程序员，我们经常会面临工作压力和时间紧迫的情况，因此有一个好的自控力对于我们的工作和生活都是至关重要的。以下是一些可以帮助程序员增强自控力的方法：

1. 设定明确的目标和计划

制定明确的目标和计划可以帮助我们更好地管理时间和精力。我们可以使用日程表、任务清单、时间追踪工具等，来帮助我们控制时间并更有效地完成任务。

2. 掌控情绪

作为程序员，我们需要面对很多挑战和压力，容易受到情绪的影响。因此，掌握情绪是一个非常重要的技能。可以通过冥想、呼吸练习、运动等方法，来帮助我们保持冷静、积极和乐观的心态。

3. 管理焦虑和压力

焦虑和压力是我们常常遇到的问题之一，所以我们需要学会如何管理它们。我们可以使用放松技巧、适度锻炼、交流沟通等方法，来减轻我们的焦虑和压力。

4. 培养自律习惯

自律是一个非常重要的品质。我们可以通过设定目标、建立规律和强化自我控制等方式，来培养自律习惯。

5. 自我反思和反馈

经常进行自我反思和反馈可以帮助我们更好地了解自己的优缺点和行为模式。我们可以使用反馈工具或与他人交流，来帮助我们成长和改进。

6. 持续学习和自我发展

程序员需要不断学习和自我发展，以保持竞争力和提升自己的技能。通过阅读书籍、参加培训、探究新技术等方式，可以帮助我们持续成长，增强自我控制力。

结论

自控力是我们工作和生活中重要的的品质之一，可以帮助我们更好地应对各种挑战和压力。通过设定目标、掌控情绪、管理焦虑和压力、培养自律习惯、自我反思和反馈、持续学习和自我发展等方法，我们可以帮助自己增强自我控制

“啊！” 我今天居然被通知裁员了！！！

虽然之前一直盛传我们这边要裁员，但是我想着，应该一时半会轮不到我这边，我感觉我们项目还是相对挣点钱的。但是呢，心里也是挺忐忑的。

今天，我正在那全心全意的敲代码，敲的正起劲呢。我突然看到我们项目经理被叫走了。啊？我一想啥情况？要开会的话怎么只叫我们项目经理，怎么不叫我呀。

难道是要裁员？！难道真的是要裁员？！然后我就看着我们项目经理和我们的上级领导他们一起坐在小屋里聊了半天，啊，我的小心脏呀，我心里就祈祷呀：“千万不要裁员啊！千万不要裁员呀！千万不要裁员呀！！！”

等我们项目经理出来之后，他走到了我这边，然后 “啪” 拍了一下我的肩膀，然后 “哎” 叹了口气。他说：“我们这个项目要被裁掉了。”

我说心里特别失落，但还故作镇定的说：“为啥？我们的项目不是还挣钱呢吗？”

项目经理说：“哎，挣钱也不行。我们现在不需要这么多人了。我们现在的项目，没有一个大的发展了啊！你先等一会吧，等一会他们还得找你谈。”。他走的时候，又拍了拍我肩膀。

哎，当时我就感觉我心里呀那种失落感呀，没法说的那种感觉。果然，没一会，我们经理就来了。他过来之后跟我说：“走，请你到小屋里喝点水。”

我苦笑着跟他说：“经理，我能不去吗？我现在不渴。”

然后我们经理说：“哎，不行呀，我都已经给你倒好了，走吧走吧，歇会去。”

然后我就默默的跟他去了。进去之后呢，我们俩都坐下了。经理跟我笑着说：“恭喜你呀，脱离苦海了。”

哎，我当时心情比较低落，我说：“是呀，脱离苦海了，但又上了刀山了呀。哈哈哈。。。”

然后他说：“哎，确实是，没办法，现在，哎，公司也不容易。现在有一些项目确实得收缩。”

我说：“哎，这也没啥，这都很正常。咱公司还算不错的，最起码还让过了个节。很多公司什么都不管，就这样让走了呀。哎！”

后面我们就谈了一些所谓的那种离职补偿啊，等等一些列的东西**。**

反正当时感觉着吧，就是，嗯，聊完之后呢就准备出去嘛。然后走路的时候呀，就感觉这个腿上啊就跟绑了铅块一样。

当时我感觉，哎，裁员这玩意怎么说呢，都没法回去和亲人说呀，弄的一下午这个心里慌慌的。怎么跟家人交代呢？人至中年居然混成这样，哎！！！

郑重声明，本文不是为了制造焦虑，发文的原因有两个：

1. 我今年 33 了，一方面给大家展现下一个普通程序员 35 岁后能咋样？是送外卖还是跑滴滴？难道真的就找不到工作了吗？


2. 感觉我并没有走好自己的人生路，把自己的经历写出来发到网上，让年轻人以我为鉴，能更好的走好自己的人
   
   作者：程序员黑黑
   来源：juejin.cn/post/7110887208953282590
   生路。

前端开发，刚开始学的时候，我感觉自己就像个孩子，一脸懵懂。当时，我非常迷茫，不知道该从何开始学习。但是，我并没有放弃，因为我对前端开发充满了热情和兴趣。

刚开始学习时，我觉得 HTML、CSS 和 JavaScript 这些基础知识就已经够难了，但是当我开始接触一些流行的框架和库时，我才发现自己真正的水平有多菜。当时，我就像一只踩在滑板上的小猪，不断地摔倒，但是我并没有放弃，我一直在努力地学习和实践。

在学习的过程中，我遇到了许多困难和挑战，但是也有很多有趣的体验和经历。有一次，我在编写一个简单的网页时，花了一整天的时间，结果发现自己的代码有一个很小的错误，导致整个网页无法正常显示。当时我感觉自己就像一个猴子在敲打键盘，非常无助和懊恼。但是，通过不断地调试和修改，我最终找到了错误，并且成功地将网页显示出来。当时，我感觉自己就像一只成功攀爬上树的小猴子，非常自豪和兴奋。

除了遇到困难和挑战，我在学习前端开发过程中也经历了许多有趣的体验。有一次，我在编写一个小型的应用程序时，发现我的代码出现了一个非常有趣的小 bug。当用户在页面上进行操作时，页面上的一些元素会突然出现在屏幕的右侧，然后又突然消失不见。当时我还担心这个 bug 会影响用户的正常使用，但是后来发现这个 bug 其实很有趣，而且还能给用户带来一些意外的乐趣。于是我就把这个 bug 留了下来，并且在用户操作时添加了一些特效，让这个小 bug 变成了一个有趣的亮点。

总结一波：
第一点，学习前端开发需要有耐心。前端开发不是一个短时间内可以学会的技能，它需要大量的时间和精力。尤其是在学习的早期，你可能会觉得有些技术和概念非常难以理解。但是，只要你有耐心，坚持不懈地学习，最终你一定会掌握这些技能。

第二点，建立一个良好的学习计划非常重要。前端开发有很多不同的技术和概念，你需要有一个清晰的学习计划来帮助你系统地学习和掌握这些知识。首先，你需要了解 HTML、CSS 和 JavaScript 这三大基本技术。其次，你可以学习一些流行的框架和库，如 React、Vue、jQuery 等，这些技术可以帮助你更快捷地构建网站和应用程序。

第三点，实践是学习前端开发的关键。你可以通过练习编写代码来更好地理解前端开发的技术和概念。在学习的过程中，你可以尝试编写一些小项目，比如一个简单的网页或者一个小型的应用程序。通过实践，你可以更深入地了解前端开发的各个方面，并且提高你的编程技能。

第四点，不要害怕向他人寻求帮助。前端开发是一个非常开放和社交的领域，你可以通过参加社区活动、参与在线讨论、向他人寻求帮助等方式来更好地学习和成长。有时候，你可能会遇到一些困难，或者对某些概念不是很理解，这时候向他人寻求帮助是非常重要的。你可以参加一些线上或线下的前端开发社区，与其他开发者交流经验和技巧，也可以在 GitHub 等平台上查看其他人的代码，从中学习和借鉴。

第五点，不断更新自己的知识和技能。前端开发是一个不断发展和变化的领域，新技术和新概念层出不穷。因此，你需要不断地更新自己的知识和技能，跟上前端开发的最新动态。你可以通过阅读博客、参加培训课程、观看技术视频等方式来学习新的技术和概念。

总之，学习前端开发需要有耐心、建立一个良好的学习计划、实践、寻求帮助和不断更新自己的知识和技能。这些都是非常重要的，也是我在学习前端开发过程中得到的宝贵经验。通过不断地学习和实践，相信你我可以成为一名优

人到中年中年总是觉得很累,每天忙不完的事,操不完的心,曾今那些无忧无虑的日子似乎消失的无影无踪, 工作三年一点存款没有

落户

关于落户这个事, 就是一个很突然的想法,很突然, 得知天津有个"海河英才计划",只要是本科生, 就比较容易落户,所以就想着试一试, 心想起码这个是一个阶级的跨越(农村-->城市), 然后就在网上各种搜索,问一些了解的朋友,看看怎么操作, 最后发现好多人说有北京社保,在天津落户会被查出来, 然后就被拉入黑名单了. 最后为了稳妥还是找了一个中介帮忙操作了一下,花了1w, 等我办完,不久就有我的朋友自己办的三无人员落户, 一分钱没花. 唉😌!!!!!

看房

一开始在安居客上看, 因为穷, 基本也没啥可选择性, 一筛选也就那么几个, 然后就联系了一个销售去看房, 不得不说这个销售真的可以, 不知道他们能赚多少钱哈, 但是服务是真的不错, 一到了高铁站他们就去接你,还请你吃饭, 带着你看,看完之后还把你送到高铁站. 想着一开始就看西青和北辰的,但是西青的都好贵, 北辰好像会好点, 然后就去北辰看, 销售说他觉得武清也不错, 就带着去武清也看了, 看完之后, 心里比较了一下, 感觉被武清的哪个样板间和户型深深吸引了,并且价格也比较合适些, 然后我回到北京一周左右吧, 就跟那个销售说,打算买武清哪个, 然后然后我父母给我拿了20w, 剩下的就是我自己的,还借了朋友一些, 首付了40多, 然后就打印征信, 一顿签字就买了. 感觉很随意, 感觉买房就跟买菜似的, 不过还是有一点区别的, 买菜之后不会让我身无分文, 买房会😭. 现在就是每个月5000多贷款"真爽".

学习

1. 缺失了刚毕业那会的激情,刚毕业那会,每天下班还会去学习, 刷视频, 看文章, 现在下班回家已经不想再打开电脑了. 刷视频(此视频非彼视频)


2. 今年也学习了一些新的东西摸鱼之间,刷了一些课程,<破解JavaScript高级玩法，成为精通JS的原生专家> <Vue3全家桶>


3. React技术栈是我工作一直使用的,也会持续性的学习一些,每天刷刷Medium和掘金


4. 深度学习Nginx,进行了一半了,以前对nginx只停留在使用的层面


5. 上半年在公司分享了一下架手架的原理以及实践


6. 英语的学习说实话真的有点三天打鱼两天晒网了, 好在现在有一半了

工作

21年年底, 老东家北京这边合作的项目,终止了,然后面临了裁员, 不过当初也确实有了想跳槽的想法了,本来想,等到年终奖发了,就提离职. 没想到提前到来了, 给了正常的赔偿(n+1) 拿了三个月的赔偿, 正好月底, 算上本月的薪资,还有一些调休啥的 加起来一共是4个月, 感觉还挺爽的, 因为大概还有个20天左右吧, 就快过年了, 然后在回家和找工作抉择了一下, 决定先找找工作,然后就开始学习在掘金上查看面经, 感觉都是各种源码, 给我搞的有点懵, 毕竟缺钱嘛. 先后面试了一些公司: 金山, 58, 携程, 欢聚, 等等; 说实话,这段时间招人的还挺多的. 所以我很快就入职了, hr问我年前能入职吗? 其实那段时间疫情严重了, 老家那边也不让北京的回去, 所以在过年的前一周我入职了, (没钱的人不配拥有假期😭) . 唉, 第一次自己在外地过年.

关于兼职:

• 今年和朋友一块干了一个公司的官网,本来也没打算要钱的,最后老板一人给了一张京东e卡


• 还干了一个审核ppt的工作,一个ppt给150,不用改, 就说哪里写的不合适, 不过这个活有点恶心, 每个人理解不一样, 每次我这边审核后, 拿去交付,还是很多问题

生活

1. 上半年感觉一直有疫情断断续续,大家都比较封闭,也没出去玩过, 偶尔和朋友去爬个山. 5, 6月还居家办公了好久, 记不太清了,应该得有一个月


2. 从去年十月一到现在一直没有回过家, 有些想回去看看, 但是最近每个周末都有事😞


3. 和女朋友去看过两次脱口秀, 感觉现场的感觉还是很棒的, 比电视看好太多


4. 因为对象住他们单位的宿舍, 所以我自己平常下班也懒得收拾屋子, 只有礼拜天,才会大扫除一下, 或者对象来的时候😁


5. 前段时间迷上了王者,以前从来不怎么玩游戏的, 熬夜打游戏, 导致生活节奏有点乱, 每天的精神状态也不如以前,正在积极调整. 但是吧,我告诉你们我的云中君玩的贼6的 不服来战哦


6. 养了一只鹦鹉, 刚来还不是很好看, 现在尾巴长长的了

下半年flag

• 完成Nginx的深度学习


• 希望能出去转一圈, 看看外面的世界


• 继续背单词学习


• 看看车车, 目前感觉Crv和宋大妈还不错


• 能再进行一次有价值的分享

晋升是一个极好的自我review的机会，不，应该是最好，而且没有之一。

晋升是最好的自我review的一次机会，不管有没有晋升成功，只要参加了晋升，认真准备过PPT，就已经包赚不赔了。

总的来说，晋升的准备工作充分体现出了——功夫在平时。平时要是没有两把刷子，光靠答辩准备的一两个月，是绝无可能把自己“包装”成一个合格的候选人的。

下面整体剖析一下自己在整个准备过程中的观察、思考、判断、以及做的事情和拿到的结果。

准备工作

我做的第一件事情并不是动手写PPT，而是搜集信息，花了几天在家把网上能找到的所有关于晋升答辩的文章和资料全撸了一遍，做了梳理和总结。

明确了以下几点：

• 晋升是在做什么


• 评委在看什么


• 候选人要准备什么


• 评判的标准是什么


• 常见的坑有哪些

首先要建立起来的，是自己对整个晋升的理解，形成自己的判断。后面才好开展正式的工作。

写PPT

然后开始进入漫长而又煎熬的PPT准备期，PPT的准备又分为四个子过程，并且会不断迭代进行。写成伪代码就是下面这个样子。

do {

    确认思路框架;

    填充内容细节;

    模拟答辩;

    获取意见并判断是否还需要修改;

} while(你觉得还没定稿);

我的PPT迭代了n版，来来回回折腾了很多次，思路骨架改了4次，其中后面三次均是在准备的后半段完成的，而最后一次结构大改是在最后一周完成的。这让我深深的觉得前面准备的1个月很多都是无用功。

迭代，迭代，还是迭代

在筹备的过程中，有一个理念是我坚持和期望达到的，这个原则就是OODA loop ( Boyd cycle) 。

OODA循环是美军在空战中发展出来的对敌理论，以美军空军上校 John Boyd 为首的飞行员在空战中驾驶速度慢火力差的F-86军刀，以1:10的击落比完胜性能火力俱佳的苏联米格-15。而Boyd上校总结的结论就是，不是要绝对速度快，而是要比对手更快的完成OODA循环。

而所谓的OODA循环，就是指 observe(观察)–orient(定位)–decide(决策)–act(执行) 的循环，是不是很熟悉，这不就是互联网的快速迭代的思想雏形嘛。

相关阅读 what is OODA loop

wiki.mbalib.com/wiki/包以德循环 (from 智库百科)

en.wikipedia.org/wiki/OODA_l… (from Wikipedia)

看看下图，PPT应该像第二排那样迭代，先把框架确定下来，然后找老板或其他有经验的人对焦，框架确定了以后再填充细节。如果一开始填充细节（像第一排那样），那么很有可能越改越乱，最后一刻还在改PPT。

btw，这套理论对日常工作生活中的大部分事情都适用。

一个信息论的最新研究成果

我发现，程序员（也有可能是大部分人）有一个倾向，就是show肌肉。明明很简单明了的事情，非要搞得搞深莫测，明明清晰简洁的架构，非要画成“豆腐宴”。

晋升述职核心就在做一件事，把我牛逼的经历告诉评委，并让他们相信我牛逼。

所以，我应该把各种牛逼的东西都堆到PPT里，甚至把那些其实一般的东西包装的很牛逼，没错吧？

错。

这里面起到关键作用的是 “让他们相信我牛逼” ，而不是“把我牛逼的故事告诉评委”。简单的增大的输出功率是不够的，我要确保评委能听进去并且听懂我说的东西，先保证听众能有效接收，再在此基础上，让听众听的爽。

How?

公式：喜欢 = 熟悉 + 意外

从信息论的角度来看，上面的公式说的就是旧信息和新信息之间要搭配起来。那么这个搭配的配比应该是多少呢？

这个配比是15.87% ——《科学美国人》

也就是说，你的内容要有85%是别人熟悉的，另外15%是能让别人意外的，这样就能达到最佳的学习/理解效果。这同样适用于心流、游戏设计、神经网络训练。所以，拿捏好这个度，别把你的PPT弄的太高端（不知所云），也别搞的太土味（不过尔尔）。

能够否定自己，是一种能力

我审视自己的时候发现，很多时候，我还保留一张PPT或是还持续的花心思做一件事情，仅仅是因为——舍不得。你有没有发现，我们的大脑很容易陷入“逻辑自洽”中，然后越想越对，越想越兴奋。

千万记得，沉没成本不是成本，经济学里成本的定义是放弃了的最大价值，它是一个面向未来的概念，不面向过去。

能够否定和推翻自己，不留恋于过去的“成就” ，可以帮助你做出更明智的决策。

我一开始对好几页PPT依依不舍，觉得自己做的特牛逼。但是后来，这些PPT全被我删了，因为它们只顾着自己牛逼，但是对整体的价值却不大，甚至拖沓。

Punchline

Punchline很重要，这点我觉得做的好的人都自觉或不自觉的做到了。想想，当你吧啦吧啦讲的时候，评委很容易掉线的，如果你没有一些点睛之笔来高亮你的成果和亮点的话，别人可能就糊里糊涂的听完了。然后呢，他只能通过不断的问问题来挖掘你的亮点了。

练习演讲

经过几番迭代以后，PPT可以基本定稿，这个时候就进入下一个步骤，试讲。

可以说，演讲几乎是所有一线程序员的短板，很多码农兄弟们陪电脑睡的多了，连“人话”有时候都讲不利索了。我想这都要怪Linus Torvalds的那句

Talk is cheap. Show me the code.

我个人的经验看来，虽然成为演讲大师长路漫漫不可及，但初级的演讲技巧其实是一个可以快速习得的技能，找到几个关键点，花几天时间好好练几遍就可以了，演讲要注意的点主要就是三方面：

• 形象（肢体语言、着装等）


• 声音（语速、语调、音量等）


• 文字（逻辑、关键点等）

演讲这块，我其实也不算擅长，我把仅有的库存拿出来分享。

牢记表达的初衷

我们演讲表达，本质上是一个一对多的通信过程，核心的目标是让评委或听众能尽可能多的接受到我们传达的信息。

很多程序员同学不善于表达，最明显的表现就是，我们只管吧啦吧啦的把自己想说的话说完，而完全不关心听众是否听进去了。

讲内容太多

述职汇报是一个提炼的过程，你可能做了很多事情，但是最终只会挑选一两件最有代表性的事情来展现你的能力。有些同学，生怕不能体现自己的又快又猛又持久，在PPT里塞了太多东西，然后又讲不完，所以只能提高语速，或者囫囵吞枣、草草了事。

如果能牢记表达的初衷，就不应该讲太多东西，因为听众接收信息的带宽是有限的，超出接收能力的部分，只会转化成噪声，反而为你的表达减分。

过度粉饰或浮夸

为了彰显自己的过人之处，有时候会自觉或不自觉的把不是你的工作也表达出来，并没有表明哪些是自己做的，哪些是别人做的。一旦被评委识破（他本身了解，或问问题给问出来了），那将会让你陈述的可信度大打折扣。

此外，也表达的时候也不要过分的浮夸或张扬，一定的抑扬顿挫是加分的，但过度浮夸会让人反感。

注意衔接

作为一个演讲者，演讲的逻辑一定要非常非常清晰，让别人能很清晰明了的get到你的核心思路。所以在演讲的时候要注意上下文之间的衔接，给听众建设心理预期：我大概会讲什么，围绕着什么展开，分为几个部分等等。为什么我要强调这个点呢，因为我们在演讲的时候，很容易忽略听众的感受，我自己心里有清楚的逻辑，但是表达的时候却很混乱，让人一脸懵逼。

热情

在讲述功能或亮点的时候，需要拿出自己的热情和兴奋，只有激动人心的演讲，才能抓住听众。还记得上面那个分布图吗？形象和声音的占比达到93%，也就是说，你自信满满、热情洋溢的说“吃葡萄不吐葡萄皮”，也能打动听众。

第一印象

这个大家都知道，就是人在最初形成的印象会对以后的评价产生影响 。

这是人脑在百万年进化后的机制，可以帮助大脑快速判断风险和节省能耗——《思考，快与慢》

评委会刻意避免，但是人是拗不过基因的，前五分钟至关重要，有经验的评委听5分钟就能判断候选人的水平，一定要想办法show出你的与众不同。可以靠你精心排版的PPT，也可以靠你清晰的演讲，甚至可以靠一些小 trick（切勿生搬硬套）。

准备问题

当PPT准备完，演讲也练好了以后，不出意外的话，应该没几天了。这个时候要进入最核心关键的环节，准备问题。

关于Q&A环节，我的判断是，PPT和演讲大家都会精心准备，发挥正常的话都不会太差。这就好像高考里的语文，拉不开差距，顶多也就十几分吧。而Q&A环节，则是理综，优秀的和糟糕的能拉开50分的差距，直接决定总分。千万千万不可掉以轻心。

问题准备我包含了这几个模块：

• 业务：业务方向，业务规划，核心业务的理解，你做的事情和业务的关系，B类C类的差异等


• 技术：技术难点，技术亮点，技术选型，技术方案的细节，技术规划，代码等


• 数据：核心的业务数据，核心的技术指标，数据反映了什么等等


• 团队：项目管理经验，团队管理经验


• 个人：个人特色，个人规划，自己的反思等等