本文写于2024年3月31号，大的背景是行业寒冬，工作岗位的数量和质量都远远不如之前，造成了打工人卷的飞起的现象，但是从企业端去看，却是面临高端人才不足，低端人才过剩以及招的人数很多但是却满足不了业务需求的问题。

本文所描述现象有作者自己的真实经历，也有道听途说但是真实存在的现象~

一、词汇高大上，过后却一地鸡毛

造词现象普遍发生在大厂牛逼人物向上汇报或者是全员会的ppt中，这些牛逼的人物已经不屑于用已存的词汇来表达自己的想法，他们会把现有的词汇融会贯通，进而创造出新的牛x词，给人一种创新的感觉，让人一下子觉得这才是核心科技。

二、无效卷

• 白天不怎么干活或者磨洋工，但是到了晚上才认真干起活来，故意加班到很晚，其实p事都没干。


• 故意很晚的时间群里@下同事

三、产品经理只管要要要，研发只管干干干

其实这点很可怕，一般来说对于产品经理，产品就像自己的娃一样，自己再熟悉不过。但是现实是很多产品经理可能连这个娃有没有xjj都不知道😂。研发不管需求是不是解决问题，也不会考虑实际问题，只管完成crud的任务。

四、无脑跟进新技术

比如最近几年兴起的大模型，那好，我们怎么可以落后于行业呢，我们自己也来搞个，虽然不知道对于我们有什么用，但贵在自研啊。

五、文档一坨狗屎

很多大厂对外的文档，比如云厂商的，用户照着文档一步一步做都会失败。

六、PUA

下面这段也是老经典语录了

其实，我对你是有一些失望的。当初给你定级px，是高于你面试时的水平的。我是希望进来后，你能够拼一把，快速成长起来的。px这个层级，不是把事情做好就可以的。
你需要有体系化思考的能力。你做的事情，他的价值点在哪里？你是否做出了壁垒，形成了核心竞争力?你做的事情,和公司内其他团队的差异化在哪里?你的事情，是否沉淀了一套可复用的物理资料和方法论?为什么是你来做，其他人不能做吗？你需要有自己的判断力，而不是我说什么你就做什么。后续,把你的思考沉淀到日报周报月报里，我希望看到你的思考，而不仅仅是进度。
提醒一下，你的产出，和同层级比，是有些单薄的，马上要到年底了，加把劲儿。你看咱们团队的那个谁，人家去年晋升之前，可以一整年都在项目室打地铺的。成长，一定是伴随着痛苦的，当你最痛苦的时候其实才是你成长最快的时候。

导读

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

目录

1 代码风格和可读性

2 注释

3 错误处理和异常处理

4 代码复用和模块化

5 硬编码

6 测试和调试

7 性能优化

8 代码安全性

9 版本控制和协作

10 总结

01、代码风格和可读性

• 错误习惯

1.1 变量命名不规范

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

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

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

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

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

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

1.2 长函数和复杂逻辑

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

def count_grade(score):

    if score >= 90:

        grade = 'A'

    elif score >= 80:

        grade = 'B'

    elif score >= 70:

        grade = 'C'

    elif score >= 60:

        grade = 'D'

    else:

        grade = 'F'

    

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

        result = 'Pass'

    else:

        result = 'Fail'

    return result

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

def count_grade(score):

    grade = get_grade(score)

    result = pass_or_fail(grade)

    return result

def get_grade(score):

    if score >= 90:

        return 'A'

    elif score >= 80:

        return 'B'

    elif score >= 70:

        return 'C'

    elif score >= 60:

        return 'D'

    else:

        return 'F'

def pass_or_fail(grade):

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

        return 'Pass'

    else:

        return 'Fail'

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

1.3 过长的行

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

def f(x):

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

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

def check_number(x):

    if x > 0:

        return 'positive'

    elif x < 0:

        return 'negative'

    else:

        return 'zero'

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

02、注释

• 错误习惯

• 错误的注释

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

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

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

03、错误处理和异常处理

• 错误的习惯

3.1 忽略错误

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

def divide(x, y):

    return x / y

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

def divide(x, y):

    try:

        return x / y

    except ZeroDivisionError:

        return 'Cannot divide by zero!'

3.2 过度使用异常处理

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

def divide(a, b):

    try:

        result = a / b

    except ZeroDivisionError:

        result = float('inf')

    return result

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

def divide(a, b):

    if b == 0:

        result = float('inf')

    else:

        result = a / b

    return result

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

3.3 捕获过于宽泛的异常

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

try {

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

} catch (Exception e) {

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

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

try {

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

} catch (FileNotFoundException e) {

    // 处理文件未找到异常

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

} catch (IOException e) {

    // 处理IO异常

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

} catch (Exception e) {

    // 处理其他异常

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

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

04、错误处理和异常处理

• 错误的习惯

4.1 缺乏复用性

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

   def calculate_area_of_rectangle(length, width):

       return length * width



   def calculate_volume_of_cuboid(length, width, height):

       return length * width * height



   def calculate_area_of_triangle(base, height):

       return 0.5 * base * height



   def calculate_volume_of_cone(radius, height):

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

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

   def calculate_area_of_rectangle(length, width):

       return length * width



   def calculate_volume(length, width, height):

       return calculate_area_of_rectangle(length, width) * height



   def calculate_area_of_triangle(base, height):

       return 0.5 * base * height



   def calculate_volume_of_cone(radius, height):

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

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

4.2 缺乏模块化

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

   class User:

       def __init__(self, name):

           self.name = name



       def save(self):

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



       def send_email(self, content):

           # 发送邮件的逻辑



   class Order:

       def __init__(self, user, product):

           self.user = user

           self.product = product



       def save(self):

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



       def send_email(self, content):

           # 发送邮件的逻辑

   ```

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

   class User:

       def __init__(self, name):

           self.name = name



       def save(self):

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



   class Order:

       def __init__(self, user, product):

           self.user = user

           self.product = product



       def save(self):

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



   class EmailSender:

       def send_email(self, content):

           # 发送邮件的逻辑

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

05、硬编码

• 错误的习惯

5.1 常量

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

def calculate_score(score):

    if (score > 60) {

    // do something}

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

PASS_SCORE = 60;

def calculate_score(score):

    if (score > PASS_SCORE) {

        // do something    }

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

5.2 全局变量

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

counter = 0

def increment():

    global counter

    counter += 1

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

def increment(counter):

    return counter + 1

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

06、测试和调试

• 错误的习惯

6.1 单元测试

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

def add_number(a, b):

    return a + b

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

import unittest



def add_number(a, b):

    return a + b



class TestAdd(unittest.TestCase):

    def add_number(self):

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



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

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

6.2 边界测试

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

def is_even(n):

    return n % 2 == 0

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

import unittest



def is_even(n):

    return n % 2 == 0



class TestIsEven(unittest.TestCase):

    def test_even(self):

        self.assertTrue(is_even(2))

        self.assertFalse(is_even(3))



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

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

6.3 可测试性

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

def get_current_time():

    return datetime.datetime.now()

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

def get_time(now):

    return now

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

07、性能优化

• 错误的习惯

7.1 过度优化

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

def sum(numbers):

    return functools.reduce(operator.add, numbers)

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

def sum(numbers):

    return sum(numbers)

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

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

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

def find_duplicate(numbers):

    duplicates = []

    for i in range(len(numbers)):

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

            duplicates.append(numbers[i])

    return duplicates

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

def find_duplicate(numbers):

    duplicates = set()

    seen = set()

    for num in numbers:

        if num in seen:

            duplicates.add(num)

        else:

            seen.add(num)

    return list(duplicates)

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

08、代码安全性

• 错误的习惯

8.1 输入验证

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

import sqlite3

def get_user(username):

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

    cursor = conn.cursor()

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

    cursor.execute(query)

    user = cursor.fetchone()

    conn.close()

    return user

在这个示例中，我们没有对用户输入的 username 参数进行验证和过滤，可能导致 SQL 注入攻击。正确示例：

import sqlite3



def get_user(username):

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

    cursor = conn.cursor()

    query = "SELECT * FROM users WHERE username = ?"

    cursor.execute(query, (username,))

    user = cursor.fetchone()

    conn.close()

    return user

在这个示例中，我们使用参数化查询来过滤用户输入，避免了 SQL 注入攻击。

8.2 不正确的密码存储

将明文密码存储在数据库或文件中，或使用不安全的哈希算法存储密码都是不安全的做法。错误示例：

import hashlib



def store_password(password):

    hashed_password = hashlib.md5(password.encode()).hexdigest()

    # 存储 hashed_password 到数据库或文件中

在这个示例中，我们使用了不安全的哈希算法 MD5 来存储密码。正确示例：

import hashlib

import bcrypt



def store_password(password):

    hashed_password = bcrypt.hashpw(password.encode(), bcrypt.gensalt())

    # 存储 hashed_password 到数据库或文件中

在这个示例中，我们使用了更安全的哈希算法 bcrypt 来存储密码。

8.3 不正确的权限控制

没有正确验证用户的身份和权限可能导致安全漏洞。错误示例：

def delete_user(user_id):

    if current_user.is_admin:

        # 执行删除用户的操作

    else:

        raise PermissionError("You don't have permission to delete users.")

在这个示例中，我们只检查了当前用户是否为管理员，但没有进行足够的身份验证和权限验证。正确示例：

def delete_user(user_id):

    if current_user.is_authenticated and current_user.is_admin:

        # 执行删除用户的操作

    else:

        raise PermissionError("You don't have permission to delete users.")

在这个示例中，我们不仅检查了当前用户是否为管理员，还检查了当前用户是否已经通过身份验证。

09、版本控制和协作

• 错误的习惯

9.1 版本提交信息

不合理的版本提交信息可能导致代码丢失、开发人员难以理解等问题。错误示例：

git commit -m "Fixed a bug"

在这个例子中，提交信息没有提供足够的上下文和详细信息，导致其他开发人员难以理解和追踪代码的变化。正确的做法是提供有意义的提交信息，例如：

$ git commit -m "Fixed a bug in calculate function, which caused grade calculation for scores below 60"

通过提供有意义的提交信息，我们可以更好地追踪代码的变化，帮助其他开发人员理解和维护代码。

9.2 忽略版本控制和备份

忽略使用版本控制工具进行代码管理和备份是一个常见的错误。错误示例：

$ mv important_code.py important_code_backup.py

$ rm important_code.py

在这个示例中，开发者没有使用版本控制工具，只是简单地对文件进行重命名和删除，没有进行适当的备份和记录。正确示例：

$ git clone project.git

$ cp important_code.py important_code_backup.py

$ git add .

$ git commit -m "Created backup of important code"

$ git push origin master

$ rm important_code.py

在这个示例中，开发者使用了版本控制工具进行代码管理，并在删除之前创建了备份，确保了代码的安全性和可追溯性。

10、总结

好的代码应该如同一首好文，让人爱不释手。优雅的代码，不仅是功能完善，更要做好每一个细节。

最后，引用韩磊老师在《代码整洁之道》写到的一句话送给大家：

“

细节之中自有天地，整洁成就卓越代码。

以上是本文全部内容，欢迎分享。

原创作者｜孔垂航

故事发生在10年前，因为自己的不成熟，没想好就跟老板提了离职，不得不真的开始找工作（详情见之前的文章，末尾有链接）。很快，就拿到了下家的 offer，约定3月31日入职。

猎头又推荐了「小而美」的豌豆荚，我不想去，因为他们周六也上班。猎头说周六基本是打酱油，而且工作氛围号称 Google 范，文艺风，不妨聊聊。吼啊，那就聊聊。

为了叙事方便，先放个当年的日历：

3月15日，周六，下午，连续面了3轮后， CEO 王俊煜(下称 junyu)不在，HR 让我回去等消息，路途遥远，到家已经天黑了。

周一，猎头告诉我挂了，不知道原因，建议我找 HR 争取下，看能否跟 junyu 聊聊，也许会有转机。我拒绝了，强扭的瓜不甜，而且我也不喜欢周六上班。

周四，收到一位面试官的邮件，他觉得我还不错，想约我再聊聊，全文如下：

我那时工作刚满20个月，其中2个月，因为部门快要黄了，整天无所事事的。最后6个月，搞 iOS 去了。所以，真正做 Android 的时间也就1年，他说的没错，我确实掌握的不够深入。虽然邮件里直接指出了我的不足，但我觉得更多的还是肯定吧。

说句不要脸的，我喜欢这种被人欣赏的感觉。类似的事，在我身上发生过挺多次了，只可惜因为自己的原因，没能接住那些泼天的富贵，先挖个坑，未来有时间再填。

最后约的是3月21日，周五，又去面了两轮，junyu 还是不在，继续回去等消息。周六，发邮件给之前的面试官咨询结果，得知面试通过了，需要等 HR 约 junyu 的时间再聊聊。

距离我入职下家公司只剩一周了，豌豆荚 HR 迟迟没有动静。我多次发短信催促她，得到的答复都是还在约。印象中最后约的是29号，周六，我从狼厂离职的第2天。

当天下午，我到的时候，junyu 还在面试中，等了半个多小时，他才完事。简短的自我介绍和项目介绍后，我说自己开发了一款计算器 APP，获得了不错的用户反馈。他一脸鄙夷的眼神问我：

什么？计算器？

对，我正准备展示它的功能和获得的奖项，他打断了我，改问其他问题了。具体问题不记得了，只记得他对我回答的反馈基本都是「嗯」，外加十分不屑的表情，而且大多数时间是在看电脑。5分钟后，他说今天就到这，有消息会通知我。

很快，HR 给我发了个拒信：

经过综合评估，还是觉得不合适

收到，我谢谢你。

工作快12年了，我面过很多公司，成功了多次，也失败了多次。但没有哪次像这次令人生气，如此不尊重候选人，这是唯一的一次。我不知道他的居高临下是为何，我的出现浪费了他的宝贵时间？哪怕是面对一问三不知的面试者，也不应该如此一副高傲的态度。

也许是因为年纪轻轻，创业有所成，于是飘飘然，开始藐视众生了？又或者因为狼厂以19亿美元收购「91手机助手」，觉得自己也行？

当初在狼厂时，周围的同事就没有一个人觉得「91无线」能值这么多钱，妥妥的冤大头。实话说，狼厂还不如把那个「91」收购了，给「狼友」们谋福利，还能赋能、反哺后来的视频业务，懂的都懂。。。

除了那场面试，HR 的表现也是让人无语，在我反复提醒她我就要入职下家了，她依然无动于衷，迟迟未能约好时间，而且每次都是我主动联系她的。哪怕是对待备胎，女神也会偶尔主动一下吧？难道是因为我太主动，把我当舔狗了？

几个月后，豌豆荚竟然断缴了很多员工的社保，据说是因为缴费的卡上余额不足，导致扣款失败，庆幸当初他们没看上我，这种奇葩的事也能出现。

对于给我发邮件的那位工程师，我还是很感激的，感谢他又给了我一次机会，也感谢他让我知道了物种的多样性。巧合的是，多年以后，我在面试另一家大厂时，又碰到了他，他已经是一名中层管理人员了，手下估计有几百号人。不过，因为跟 HR 待遇没谈拢，我最后没去。

本文纯属吐槽，以上内容，绝对真实，如有雷同，深表同情。

在我告诉猎头挂了后，他告诉我还有一家跟豌豆荚风格类似的「小而美」的公司，建议我去聊聊看。我说马上要入职新公司了，不想再面了，况且我都没听过这个公司。彼时，那个小公司名叫「今日头条」。

昨天，昨天和滨江的一个朋友聊了聊，他是那边的一个公司产品负责人，也算是核心合伙人的角色之一，他们的公司是做直播业务的，大概有七八十人的团队，开发人员大概是30人左右，占比35%左右，其中里面还有一个CTO角色，或者说技术总监的角色，其他的全部都是干活的小兵和小组长之类的。

我们主要聊到了两个不同规模的公司的工作模式的问题，因为我所在的是阿里巴巴应该是非常典型的超大型互联网公司，而他们公司这个人数刚好是属于小型的互联网公司。

他的公司主要是做直播业务的，大家都很熟悉诸如抖音快手这样的直播平台，这么小的公司怎么能做好一个直播平台呢？那他们的业务模式也非常的经典，那就是做一些非常小众的网红和用户产品。

一、直播市场的长尾用户

他描述了一下他自己的一些对于直播和用户的一些观点和理解，比如说现在众所周知的类似于抖音这样极大的平台，有超级大的网红IP，也有无数的粉丝。但是国内互联网用户基数非常之大，存在非常多的长尾用户，比如一些粉丝想在平台上获得一些娱乐感和交互感，这个是抖音这种大平台所满足不了的。另外一方面有大量的尾部网红在抖音这种大平台上面往往也拿不到任何的流量，所以他们也需要一种更小的平台，有充足的流量扶持。

在这个背景下就有了针对这些长尾用户的一些小的直播平台，那在小的直播平台上，哪怕你再小的网红，你都会有一些流量上面的倾斜，对于用户来说，在抖音上给大V打赏几万可能主播都不会理你，但是你在小平台上直接给主播进行打赏交互，就会变得更加的简单和高效。毕竟我们可以想象一下，很多花不起大价钱的“屌丝”用户，可能在这种小平台上面砸个几百几千，可能就能够约网红出来吃个饭，聊个天什么的。一些尾部网红也是一样，长期在抖音中大平台上面基本上没有流量，也没人关注和在意，但是到小平台上面可能就有比较多的几十个，甚至几百个粉丝过来和你交互和聊天打赏，很容易形成一个正反馈。

所以对于刚刚起步的网红来说，在这种小平台上面去发展，获得自己的正反馈和积累初步的影响力是非常的必要的。那对于一些没有太多钱、时间又空闲的粉丝们来说，对于小平台上面也能够有一个快速的通道去接触到这些主播或者兴趣相同的朋友。

于此同时，各行各业，蚊子肉都是大平台吃不到也不想吃的，这类长尾用户是大的平台是往往无法覆盖的，也是看不上的，所以给了这些小型的平台很多的发展空间，这个就是非常典型的一种长尾生态形式。也非常符合之前我所推荐的那本书叫做《长尾理论》，这种小平台因为它的边际成本是非常的低的，所以它可以在各个地方花钱去投放广告，吸引长尾客流，主打各种形式的娱乐化的直播并从中抽佣。

我们也可以看到这种平台本身也不大可能做的非常大，一方面它可能在形式和内容上面都可能走一些擦边或者灰色的方式，另外一方面对他们自己来说，他们也不想做的做大，做大以后以后就会面临着更加复杂的问题，比如监管问题。所以很多这种小型的平台活的非常的滋润，从来没想着做大做强，而是在自己的一亩三分细分领域里深耕，现金流反而还比大平台的还更加的充足。

他们公司在前两年就寻求上市，因为经济的原因中止，但这也就说明他这种模式实际上非常赚钱，现金流是非常的稳定的。

二、快进快出的用人理念

除了这种非常好的商业模式之外，另外一个讨论点就是我们工作模式上面的最大的区别。他提到了他们公司的员工的离职率是非常高的，基本上几个月、半年可能就大量的技术人员离职汰换。这个也很简单，她说对于新招聘的员工来说，如果半个月上不了手的情况下的话，就会在试用期里面就会解聘掉，主打就是追求实用主义，员工拿来即用没有培养一说。对于一个小的技术公司来说，它的成本控制的非常的严格，如果员工短时间内不能上手的情况下的话，对他们来说是没有任何价值的，所以对于员工都采用快进快出这样的方式，完全不像我们大平台大企业，可能给到一个员工的成长时间，短则三个月，大长则半年，一年。而小公司完全吃不消这种巨大的人力培养成本。

另外就是对于他们一些比较资深的工程师来说，工龄时间也不会太长，因为他们给不了员工的一个向上的晋升通道。当个员工工作了两年到三年，技术能力各方面能力都提高了，以后也没办法往上升或者持续加薪，因为毕竟上面只有一个技术合伙人，总不能把这个技术合伙人给顶下去吧，所以他们大部分的员工工作了两年到三年之后，技术能力上面都有非常大的成长之后，往往就会跳出这个小厂去寻求其他的大厂机会。

然后他们公司本身对于技术的追求也不深，大部分完全采用的是“拿来即用”的原则，他说在早期的时候做平台还会去找一些开源源码自己来部署，到了现在大部分能力都有非常成熟的第三方厂家来支持，他们公司技术人员只要做集成和包装就可以了。现在据我所知，类似于阿里云这样的云平台，已经把整个云计算API、网络直播的API，甚至很多底层技术全部做的非常好，都打包成SDK或者封装成API，所以上层业务方只要购买服务后把API包装一下，封装就可以直接使用了，五分钟生成一个直播平台APP已经没有任何问题了。

以我的理解，一个正常的工作了半年到一年的同学，我觉得在这种SDK或者API的加成下，就应该在一个星期内能创建出来一个直播平台APP了。所以很明显在这种基础能力非常强大的情况下，他们公司就会可以把成本压的更小，他们可以随时的去调整自己的业务方向和迭代，基本上几周就会有一个小版本迭代或者出全新的APP。

我问了一下，他们有没有一个知名的应用市场APP，给我的答案是他们开发成了很多非常小的一些APP，然后在应用市场上面去打广告引流，用户量和粉丝量都不算大，明显就能看到这种模式主打一个灵活、主打分布式。

三、反脆弱的商业形式

所以相对于小厂和中厂来说，不管从业务模式上还是从技术架构上，还是从经营理念上完全不可同日而语。但不得不说，我觉得正如我们的自然界生态系统一样，有些时候很微小的生物往往能够在漫长的生态环境中存活下来，比如蟑螂老鼠，而有一些庞然大物，诸如恐龙猛犸象这样的大体积的生物，反而还容忍不了生态气候的变化而灭绝。

而对于他这样小的一些经济体，几十个人，有自己的一些核心的产品模式，并且能够快速的迭代，对成本控制严格，对经济变化敏感，反而还能够存活到各个不同的周期里面，所以这我觉得也是一种值得我们羡慕的地方。这也是知名作家塔勒布在他的《反脆弱》一书里提到的一种形式，这种公司反而具备更强的反脆弱性，当经济越差，他们不仅不受影响，反而反弹变得更强壮、盈利性更强。

最后一步来说，对于程序员来说，根据自己的兴趣、爱好、能力水平，在当前的经济周期找到一个比较合适自己的平台，能够锻炼到自己的能力，不管是从技术还是从业务经营，产品各个方面都有所成长，那对自己来说就是好事。对于创业者来说也未必要盯着非常大的市场，动不动就来个规模效应，有时候去做这种非常小微公司和长尾市场，往往活得会更加的滋润和惬意。

最近，我周围有挺多互联网大厂leader级别的同事或朋友，被“降本增效”了。

其中最有意思的是，我的前同事老Z今年刚刚晋升了一级，在这个级别上还没待热乎了，然后就下来了。

有句话是这么说的：“世界上最残忍的事，莫过于让其拥有一切，然后再剥夺其所有。”

有次我跟老Z吃饭，他苦笑着跟我说：“妈的，如果不晋升，没准还能待下去呢，晋升之后反而目标变大了。”

我问他：“那你最近看新机会的结果怎么样，有没有拿到比较满意的offer呢？”

他说：“面试机会倒是不少，大厂已经面了五六个，但最后都无疾而终了。”

接下来，他又把话题聊了回来，说：“你说，如果公司对我不满意，为什么还给我晋升呢，但如果公司对我满意，又为什么还要裁我呢？”

我给他举了一个这样的例子：“就算大款给小三买奢侈品，让她住豪宅，但并不代表不会甩了她啊，对吧。”

他听了哈哈大笑，似乎释怀了。

接下来，我盘点一下，具备什么特征的管理层最容易被“降本增效”，以及在未来的日子里，我们应该如何应对这种不确定性。

“降本增效”画像

跟大家聊下，哪类用户画像的领导层最容易被“降本增效”，请大家对号入座，别心存侥幸。

（1）非嫡系

不管到哪天，大厂也都是个江湖，是江湖就有人情世故。

如果你不是老板的嫡系，那公司裁员指标下来了，你不背锅谁背锅，你不下地狱谁下地狱。

你可能会说：“我的能力比老板的嫡系强啊，公司这种操作，不成了劣币驱逐良币了吗？”

其实，这个时候对于公司来说，无论是劣币还是良币，都不如人民币来得实在。

人员冗余对于公司来讲就是负担，这个时候谁还跟你讲任人唯亲还是任人唯贤啊。

（2）老员工

可能有人会这么认为，老员工不但忠诚，而且N+1赔的钱也多，为什么会优先裁掉老员工呢。

我认为，一个员工年复一年、日复一日地待在熟悉的工作环境，就犹如温水煮青蛙一样，很容易停留在舒适区，有的甚至混成了老油子。

而老板最希望看到的是，人才要像水一样流动起来，企业要像大自然一样吐故纳新，这样才会一直保持朝气和活力。

总之，老板并不认为员工和公司一起慢慢变老，是一件最浪漫的事。

（3）高职级

对于公司来讲，职级越高的员工，薪资成本也就越高，如果能够创造价值，那自不必多说，否则的话，呵呵呵。。。

现在越来越多的公司，在制定裁员目标的时候，已经不是要裁掉百分之多少的人了，而是裁员后把人均薪资降到多少。

嗯，这就是传说中的“降均薪”，目标用户是谁，不多说也知道了吧？

（4）高龄

35+，40+，嗯，你懂的。

老夫少妻难和谐，大龄下属跟小领导不和谐的几率也很大，一个觉得年轻人不要抬气盛，另外一个觉得不气盛就不是年轻人。

不确定性——在职

恭喜你，幸存者，老天确实待你不薄，在应对不确定性这件事情上，给了你一段时间来缓冲。

如果你已经35+了，那接下来你需要把在职的每一天，都当成是最后一天来度过，然后疯狂地给自己找后路，找副业。

一定要给你自己压力，给自己紧迫感。

因为说不定哪天，曾经对你笑圃如花的HR，会忽然把你叫到一个偏僻的会议室里，面无表情地递给你一式两份的离职协议书，让你签字。

在你心乱如麻地拿起签字笔之际，她没准还得最后PUA你几句：“这次公司不是裁员，而是优化。你要反思自己过去的贡献，认识到自己的不足，这样才能持续发展。

当然，你有大厂员工的光环加持，到市场上还是非常抢手的，你要以人才输出的高度来看这次优化，为社会做贡献。”

至于找后路和副业的方式，现在网上有很多类似的星球，付费和免费的都有，加一个进去，先好好看看，主要是先把思路和视野打开。

当然，如果你周围要是有一个副业做得比较好的同事，并且他愿意言传身教你，那就更好了。

然后，找一个自己适合的方向和领域，动手去做，一定动手去做，先迈出第一步，可以给自己定一个小目标，在未来几个月内，从副业中赚到第一次钱。

从0到1最难，再接下来，应该就顺了。

不确定性——不在职

如果35+的你刚刚下来，而且手头还算殷实的话，我先劝你第一件事：放弃重返职场。

原因很简单，如果一个方向，随着你经验的积累和年龄的增长，不仅不会带来复利，而是路会越走越窄，那你坚持的意义是什么？难道仅仅是凑合活着吗？

第二件事，慢下来，别立马急急忙忙地找出路，更不要一下子拿出很多本金砸在一个项目上。据说，有的项目是专门盯着大厂员工的遣散费来割韭菜的。

有人会说，在职的人你劝要有紧迫感，离职的人你又劝慢下来，这不是“劝风尘从良，逼良家为娼”吗？

其实不是的，只是无论是在职还是离职，我们都需要在某件事情的推进上，保持一个适合且持久的节奏，不要止步不前，也不要急于求成，用力过猛。

第三件事，就是舍得把面子喂狗，不要觉得做这个不体面，做那个有辱斯文，只要在合理合法的情况下，能赚到钱才是最光荣的。

接下来，盘点周围可用资源，调研有哪些领域和方向适合你，并愿意投入下半生的精力all in去做。

这个过程可能会很痛苦，尤其对于一些悲观者来说，一上来会有一种“世界那么大，竟然再也找不到一个我能谋生的手段”的感觉，咬牙挺过去就好了。

这里说一句，人只要自己不主动崩，还是远比想象中耐操很多的。

结语

好像也没什么好说的，大家各自安好，且行且珍惜吧。

近期在开发AI对话产品的时候为了提升用户体验增强了对话输入框的相关能力，产品初期阶段对话框只是一个单行输入框，导致在文本内容很多的时候体验很不好，所以进行体验升级，类似还原了微信输入框的功能（只是其中的一点点哈🤏）。

初期认为这应该改动不大，就是把input换成textarea吧。但是实际开发过程发现并没有这么简单，本文仅作为开发过程的记录，因为是基于uniapp开发，相关实现代码都是基于uniapp。

简单分析我们大概需要实现以下几个功能点：

• 默认单行输入


• 可多行输入，但有最大行数限制


• 超过限制行术后内容在内部滚动


• 支持回车发送内容


• 支持常见组合键在输入框内换行输入


• 多行输入时高度自适应 & 页面整体自适应

单行输入

默认单行输入比较简单直接使用input输入框即可，使用textarea的时候目前的实现方式是通过设置行内样式的高度控制，如我们的行内高度是36px，那么就设置其高度为36px。为什么要通过这种方式设置呢？因为要考虑后续多行输入超出最大行数的限制，需要通过高度来控制textarea的最大高度。

<textarea style="{ height: 36px }" />

多行输入

多行输入核心要注意的就是控制元素的高度，因为不能随着用户的输入一直增加高度，我们需要设置一个最大的行数限制，超出限制后就不再增加高度，内容可以继续输入，可以在输入框内上下滚动查看内容。

这里需要借助于uniapp内置在textarea的@linechange事件，输入框行数变化时调用并回传高度和行数。如果不使用uniapp则需要对输入文字的长度及当前行高计算出对应的行数，这种情况还需要考虑单行文本没有满一行且换行的情况。

代码如下，在linechange事件中获取到最新的高度设置为textarea的高度，当超出最大的行数限制后则不处理。

linechange(event) {

    const { height, lineCount } = event.detail

    if (lineCount < maxLine) {

        this.textareaHeight = height

    }

}

这是正常的输入，还有一种情况是用户直接粘贴内容输入的场景，这种时候不会触发@linechange事件，需要手动处理，根据粘贴文本后的textarea的滚动高度进行计算出对应的行数，如超出限制行数则设置为最大高度，否则就设置为实际的行数所对应的高度。代码如下：

const paddingTop = parseInt(getComputedStyle(textarea).paddingTop);

const paddingBottom = parseInt(getComputedStyle(textarea).paddingBottom);

const textHeight = textarea.scrollHeight - paddingTop - paddingBottom;

const numberOfLines = Math.floor(textHeight / lineHeight);



if (numberOfLines > 1 && this.lineCount === 1) {

    const lineCount = numberOfLines < maxLine ? numberOfLines : maxLine

    this.textareaHeight = lineCount * lineHeight

}

键盘发送内容

正常我们使用电脑聊天时发送内容都是使用回车键发送内容，使用ctrl，shift，alt等和回车键的组合键将输入框的文本进行换行处理。所以接下来要实现的就是对键盘事件的监听，基于事件进行发送内容和内容换行输入处理。

首先是事件的监听，uniapp不支持keydown的事件监听，所以这里使用了原生JS做监听处理，为了避免重复监听，对每次开始监听前先进行移除事件的监听，代码如下：

this.$refs.textarea.$el.removeEventListener('keydown', this.textareaKeydownHandle)

this.$refs.textarea.$el.addEventListener('keydown', this.textareaKeydownHandle)

然后是对textareaKeydownHandle方法的实现，这里需要注意的是组合键对内容换行的处理，需要获取到当前光标的位置，使用textarea.selectionStart可获取，基于光标位置增加一个换行\n的输入即可实现换行，核心代码如下：

const cursorPosition = textarea.selectionStart;

if(

    (e.keyCode == 13 && e.ctrlKey) ||

    (e.keyCode == 13 && e.metaKey) ||

    (e.keyCode == 13 && e.shiftKey) ||

    (e.keyCode == 13 && e.altKey)

){

    // 换行

    this.content = `${this.content.substring(0, cursorPosition)}\n${this.content.substring(cursorPosition)}`

}else if(e.keyCode == 13){

    // 发送

    this.onSend(); 

    e.preventDefault();

}

高度自适应

当多行输入内容时输入框所占据的高度增加，导致页面实际内容区域的高度减小，如果不进行动态处理会导致实际内容会被遮挡。如下图所示，红色区域就是需要动态处理的高度。

主要需要处理的场景就是输入内容行数变化的时候和用户粘贴文本的时候，这两种情况都会基于当前的可视行数计算输入框的高度，那么内容区域的高度就好计算了，使用整个窗口的高度减去输入框的高度和其他固定的高度如导航高度和底部安全距离高度即是真实内容的高度。

this.contentHeight = this.windowHeight - this.navBarHeight - this.fixedBottomHeight - this.textareaHeight;

最后

到此整个输入框的体验优化核心实现过程就结束了，增加了多行输入，组合键换行输入内容，键盘发送内容，整体内容高度自适应等。整体实现过程的细节功能点还是比较多，有实现过类似需求的同学欢迎留言交流～

看完本文如果觉得有用，记得点个赞支持，收藏起来说不定哪天就用上啦～

本文分享一下凌览近期看的一本书《微信背后的产品观》，它源自2012年7月微信产品经理张小龙一次长达8小时的腾讯内部分享。

了解人性

产品经理是站在上帝身边的人，上帝根据他的期望，创造了人，并赋予人一些习性，让人类的群体在这些习性下发展演化。而产品经理实际是在理解了人的习性后，像上帝一样，建造系统并建立规则，让群体在系统中演化。

书中提及两本书《失控》、《乌合之众》，两本书结合的逻辑：群体在特定规则下的无序演化产生很多意想不到的结果。微信的很多产品功能的设计思想都和这两本书的理论很契合，比如漂流瓶、摇一摇，拍一拍等。

优秀的产品经理需要具备的能力：

• 了解人的习性，需求从人性中产生


• 了解群体的心理

"人"的特性：

• 人是懒惰的，懒惰是创新的动力，案例：语音查找联系人，解决走路或双手不方便时要给一个人发微信，输入半天还找不出的情况


• 人是跟风的，"因为别人都在用"，时尚是驱动力，在互联网产品中，"时尚"是重要的驱动力


• 人是没有耐心的，用户没有耐心看产品说明书，不要尝试去引导用户，去教育用户，没有人愿意去接受你的引导和教育。一定是他拿过来就会用才是最直接的（产品使用操作简单）


• 人是不爱学习的，"马桶阅读"理论：不要给用户超过马桶上看不完的内容


• 群体是"乌合之众"，理论出自《乌合之众》一书，群体智商低于个体，互联网产品的用户是群体，不是个体

如何确定一个需求

• 对于新点子，99%的情况下否定是对的，不要随便臆想需求


• 不要用户说什么就做什么，用户的反馈是帮助你了解他们的想法，用户的需求是零散的，应该进行归纳抽象


• 不从同类产品里找需求，另的产品决定做这个需求，是有他们自己的理解，并深入分析思考过。如果别人说好，我们就直接照搬，其实没有深刻理解需求


• 不听从产品经理的需求，他们不是用户却自认为代表用户，他们分析过于理性，他们会要求要显示在线、要已读、要分组、要滤镜、要涂鸦、要多端同步、要群名片、要赞头像.....如果产品经理都把这些当作用户朴素的需求做进去，这将是可怕的事情


• 需求来自你对用户的了解
  
  
  
  • 需求不来自调研
  
  
  • 需求不来自分析
  
  
  • 需求不来自讨论
  
  
  • 需求不来自竞争对手
  
  
  
  


• "爽"用过功能,爽是体验。爽比功能更易传播


• 只抓主场景，不做全功能，做大而全很容易，做小很难，如果没有化繁为简的功力，就控制自己的欲望，每天砍掉几个需求的爽，远大于提出几个需求，案例：朋友圈只能发图片，发140字的难度远胜一张图片

如何设计一个产品

• 好的产品价值观和认知是成为优秀产品的前提


• 先做产品结构，之后才是功能细节。微信功能细算特别多，但看起来还是很简单，做一个新版本都不知道它有什么新功能，先把微信的骨骼梳理清楚，枝叶的东西藏得很深也没关系，这样整个产品才会乱掉


• 功能模块之间是有机联系的关系，独立的功能堆砌很危险


• 设计是分类


• 抽象才能化繁为简，如果有100个需求，而我们能把这100个需求汇总成10个需求，这就是"抽象"


• 越简单的分类越容易被接受，微信会升级，但结构和界面依然保持简单，过多变化易引来用户不适应


• 挖掘需求背后的本质需求


• 宁愿损失功能也不损失体验

最后

张小龙强调我所说的，都是错的，每个人都会有自己的解决问题的办法，没有永远的正确教条。

书未有问答环节，这里精简摘录下我认为有启发的回答：

Q：为什么人人都是产品经理？怎么做到跟其他也是产品经理的人不一样？

A：因为人人都可以提问题，人人都可以指手画脚，用户也会，但最难的是找到本质的东西，这才是产品经理要一定具备的

Q：从普通工程师到现在做成一个伟大的产品，你是怎么一步一步走过来的？

A：经历上千个实战的锻练，越多越好，一个人要成为一个领域的专家，要付出一万个小时的努力和专业训练

回答提及一本书《另类成功学》，有兴趣可以看看。

如果我的文章对你有帮助，您的👍就是对我的最大支持^_^。

二零零几年，大环境还没像现在这么拉垮的时候，有个面向学生的网站叫校内网，里面曾有人发起了一次大范围投票。

问广大学子毕业后最想从事什么工作。

当时超过一半的人都选择了大型外企，排名第二的是大型国企民企，然后是自主创业。

只有很少一部分选择了事业单位和公务员，这部分同学还有相当比例来自对考公自古有执念的山东。

而在其他省份，多数同学都认为自己能拥有光明的未来，当然不会喜欢公务员这种工资稳定得低，日复一日枯坐案前，早早就能一眼望到头的工作。

在当时年轻人眼里，公务员属于“实在不行就只能回家考公“的备胎，地位约等于“实在不行就找个老实人嫁了“的级别。

但后来的故事我们都知道了，经济大船这几年驶入了深水区，风浪越来越大，鱼也越来越贵。

于是四平八稳旱涝保收的体制内，这几年摇身一变，一跃成为了那个最靓的仔。不得不说，人确实是时代的产物，环境的变化可以完全改变一个人的决策。

大环境好的时候，人们会不自觉地高估自身的努力，那时候人们是相信努力一定会有收获的。有时候过于相信了，但这在经济高速增长的年代并不会有太大问题，你还是会得到属于自己的那块蛋糕的。

但当经济增速换档时，付出与回报的比例开始失衡，努力就能收获的简单逻辑不攻自破。变成了努力也不一定有收获，进而发展成努力大概率不会有收获，最后演变成一命二运三风水，努力奋斗算个鬼。

这种心态的转变也解释了为啥从去年以来，越来越多的年轻人开始扎堆去寺庙求签祈福，排的长队连起来能绕地球三圈，看得旁观的老大爷直摇头说，“真搞不懂这些小年轻是怎么想的，偶像粉丝见面会咋还跑到庙里来开了？！”

人在逆境迷茫时，是容易被玄学吸引。逆境意味着前路遇阻，意味着你迫切需要一些指引，而玄学恰好满足了这方面需求。

命运这个东西，有时候真蛮捉摸不透的。

我认识一小姐姐，为一场决定人生的重要考试做足了准备，结果在赶往考场的路上，书包就这么巧被扒手偷了，里面开卷考试所有的资料全部丢失，直接导致她逃汰出局，泪洒当场。

还有一大哥，在升职加薪岗位竞争的关键阶段，突然一场急病，好巧不巧失声了，一句话也说不出来，参加不了竞聘答辩，眼睁睁看着大好机会就此溜走。

等这事过去了，他一下子又能正常说话，跟被老天上了沉默debuff一样，你说他找谁说理去呢。

人活得时间越长，就越信“命“这个东西，越能意识到自己真正能把控的其实少得可怜，随便一点意外都能直接改变整个人生走向。

这种感悟放在以前，一般都是上了些年纪的人才会有的，但随着这两年经济增速换挡，年轻人频繁碰壁，被命运按在地上摩擦的次数多了，自然也就信了“命”，求签问道的也就跟着多起来了。

说句不好听的话，我觉得这样挺好的。不是说求签问道这个行为好，而是这种行为背后暗含着一个巨大的心理转变，我认为很好。

那就是放过自己。亚洲人尤其是我们特别不愿意放过自己，从出生开始就活在比较中，长辈们连夸个人都要这么夸，说哎呀，你学习真用功，比学习委员还用功；哎呀，你工资挺高，比隔壁小王还要高。

骂你的时候也一定要捎带上别人，说你看谁谁谁多厉害，你再看看你，一定是你还不够努力。

就是这种搞法很容易让人把责任全揽自己身上，对自我要求过高，最后的结果就是崩掉，就累嘛！

但现在不一样了，现代人在网络上看了太多含着金汤匙出生在罗马的人，和那些老天爷追着赏饭吃的人。

他们跟我们之间的差距大到几辈子都弥补不上，那努力万能论也就不攻自破了嘛。

于是越来越多的小伙伴开始承认自我的局限，承认努力也不一定有收获，承认人生不如意十之八九，慢慢也就承认了“命运”这个东西，开始顺其自然，没那么多执念了。

不过有些人过于放飞自我，摆烂走了另一个极端，那也是要出问题的。

即便是玄学，它也没有彻底否定个人奋斗，大富靠命没错，但小富靠勤，靠双手取得一些小成就，让日子过得舒服些还是没啥问题的。

其实我觉得一个比较合适的世界观应该是这个样子：首先咱得承认不可抗力，承认“命”与“运”这个东西是真实存在的，如果你不喜欢这两个玄乎的字，可以用“概率”代替，我们永远得做好小概率事件砸到头上的准备。

有时候拼尽一切就是没有好的结果，这咱得承认，但同时这也并不意味着从此放弃一切行动，落入虚无主义的陷阱。

人还是要去做一些什么的。比如精进某项专业技能，逐步提升自身能力，为的不是那点工资，而是一件更重要的事，抓住运气。

运气有多重要，大家都明白，它比努力重要得多。

运气这东西打比方的话，就像一个宝箱，会随机在你面前掉落，但这些宝箱自带隐形属性，你等级太低的话就看不见它，自然也就抓不住这些运气。

用现实举例，“运气”就像你在工作中遇到了某个本来还可以拉你一把的贵人，结果你的等级太低，工作能力稀碎，贵人一看，这货不值得我帮，转身走了。他这个宝箱对你而言就隐形了，消失了。

而且最讽刺的是你从头到尾都被蒙在鼓里，根本不知道自己错失了一次宝贵的机会，所以为了避免运气来了你抓不住，又溜走的这种尴尬情况出现，我们还是要去精进和磨练一下社会技能，尽量达到能在某些场合被人夸奖的程度。

把等级刷高一些，之后该吃吃该喝喝，耐心等待宝箱的出现。这可能也是以前人们常说的，“尽人事听天命”的另一种解释吧。

也希望今天聊的关于命和运的这些内容，能启发到一些小伙伴，大家一起认认真真，平平淡淡的生活。

前言

不是标题党，不是标题党，不是标题党，重要的话说三遍！大家常见的【只读模式】，下面简称 readonly，可能最常用的是在 表单场景中，除了正常的表单场景，你还会想象到它可以应用在我们中后台场景的 编辑表格、描述列表、查询表格 吗？先看看效果吧 ~

表单场景

表单列表场景

描述列表场景

查询表格场景

编辑表格场景

上面看到的所有效果，背后都有 readonly 的存在

下面就以 实现思路 + 伪代码 的方式和大家分享 readonly 的玩法

以 Date 组件为例

我们这里说的 Date 就是单纯的日期组件，不包含 picker 为 month(月份)、quarter(季度) 等，我们先思考一下，如何让 日期组件 可以在多处公用（查询表格、表单、编辑表格、描述列表）

多处公用

我们可以将 Date 组件进行封装，变成 ProDate，我们在 ProDate 中扩展一个属性为 readonly，在扩展一个插槽 readonly，方便用户自定义，以下为伪代码

<script lang="tsx">

import { DatePicker, TypographyText } from 'ant-design-vue'



export default defineComponent({

  name: 'ProDate',

  inheritAttrs: false,

  props: {

      readonly:{

        type: Boolean,

        default:false

      }

  },

  slots: {

      readonly: { rawValue: any }

  },

  setup(props, { slots, expose }) {

    const getReadonlyText = computed(() => {

      const value = toValue(dateValue)

      return getDateText(value, {

        format: toValue(valueFormat),

        defaultValue: toValue(emptyText),

      })

    })



    return {

      readonly,

      getReadonlyText,

    }

  },

  render() {

    const {

      readonly,

      getReadonlyText,

    } = this



    if (readonly)

      return $slots.readonly?.({ rawValue: xxx }) ?? getReadonlyText



    return <DatePicker {...xxx} v-slots={...xxx} />

  },

})

</script>

上面的伪代码中，我们扩展了 readonly 属性和 readonly 插槽，我们 readonly 模式下会调用 getDateText 方法返回值，下面代码是 getDateText 的实现

interface GetDateTextOptions {

  format: string | ((date: number | string | Dayjs) => any)

  defaultValue: any

}



// 工具函数

export function getDateText(date: Dayjs | number | string | undefined | null, options: GetDateTextOptions) {

  const {

    format,

    defaultValue,

  } = options



  if (isNull(date) || isUndefined(date))

    return defaultValue



  if (isNumber(date) || isString(date)) {

    // 可能为时间戳或者字符串

    return isFunction(format)

      ? format(date)

      : dayjs(date).format(format)

  }



  if (isDayjs(date)) {

    return isFunction(format)

      ? format(date)

      : date.format(format)

  }



  return defaultValue

}

好了，伪代码我们实现完了，现在我们就假设我们的 ProDate 就是加强版的 DatePicker，这样我们就能很方便的集成到各个组件中了

集成到 表单中

因为我们是加强版的 DatePicker，还应该支持原来的 DatePicker 用法，我们上面伪代码没有写出来的，但是如果使用的话，还是如下使用

<template>

    <AForm>

        <AFormItem>

            <ProDate v-model:value="xxxx" />

        </AFormItem>

    </AForm>

</template>

这样的话，我们如果是只读模式，可以在 ProDate 中增加 readonly 属性或插槽即可，当然，为了方便，我们实际上应该给 Form 组件也扩展一个 readonly 属性，然后 ProDate 的 readonly 属性的默认值应该是从 Form 中去取，这里实现我就不写出来了，思路的话可以通过在 Form 中 provide 注入默认值，然后 ProDate 中通过 inject 读

好了，我们集成到 表单中 就说这么多，实际上还是有很多的细节的，如果大家想看的话，后面再写吧

集成到 描述列表中

描述列表用的是 Descriptions 组件，因为大部分用来做详情页，比较简单，所以这里我将它封装成了 json 方式，用 schemas 属性来描述每一项的内容，大概是以下用法

<ProDescriptions

  title="详情页"

  :data-source="{time:'2023-01-30'}"

  :schemas="[

      {

          label:'日期',

          name:'time',

          component:'ProDate'

      }

  ]"

/>

解释一下：

上面的 schemas 中的项可以简单看成如下代码

<DescriptionsItem>

    <ProDate 

        readonly 

        :value="get(dataSource,'time')" 

        />

</DescriptionsItem>

我们在描述组件中应该始终传递 readonly: true，这样渲染出来虽然也是一个文本，但是经过了 ProDate 组件的日期处理，这样就可以很方便的直接展示了，而不用去写一个 render 函数自己去处理

集成到 查询表格中

实际上是和 集成到描述列表中 一样的思路，无非是将 ProDescriptions 组件换成 ProTable 组件，schemas 我们用同一套就可以，伪代码如下

<ProTable

  title="详情页"

  :data-source="{time:'2023-01-30'}"

  :schemas="[

      {

          label:'日期',

          name:'time',

          component:'ProDate'

      }

  ]"

/>

当然我们在 ProTable 内部对 schemas 的处理就要在 customRender 函数中去渲染了，内部实现的伪代码如下

<Table 

:columns="[

    {

       title:'日期',

       dataIndex:'time',

       customRender:({record}) =>{

            return <ProDate

                readonly

                value={get(record,'time')} 

            />

        }

    }

]"

/>

ProTable 和 ProDescriptions 的处理方式是类似的

集成到 编辑表格中

没啥好说的，实际上是和 集成到表单中 一样的思路，伪代码用法如下

<ProForm>

    <ProEditTable

      :data-source="{time:'2023-01-30'}"

      :schemas="[

          {

              label:'日期',

              name:'time',

              component:'ProDate'

          }

      ]"

    />

</ProForm>

我们还是复用同一套的 schemas，只不过组件换成了 ProEditTable，不同的是，我们在内部就不能写死 readonly 了，因为可能会 全局切换成编辑或者只读、某一行切换成编辑或者只读、某个单元格切换成编辑或者只读，所以我们这里应该对每一个单元格都需要定义一个 readonly 的响应式属性，方便切换，具体的实现就不细说了，因为偏题了

结语

好了，我们分享了 只读模式 下不同组件下的表现，而不是简单的在 表单中 为了好看而实现的，下期再见 ~

扯皮

这段时间闲着没事就去翻翻红宝书，已经看到 Promise 篇了，今天又让我翻到两个陌生的知识点。

因为 Promise 业务场景太多了自我感觉掌握的也比较透彻，之前也跟着 Promise A+ 的规范手写过完整的 Promise，所以这部分内容基本上就大致过一遍，直到看见关于 Promise 的取消以及监听进度...🤔

只能说以后要是我当上面试官一定让候选人来谈谈这两个点，然后顺势安利我这篇文章🤣

不过好像目前为止也没见哪个面试官出过...

2024-04-03 更新：这段时间在刷牛客，无意间看到了 25 届佬： 收心檬 的个人主页 - 文章 - 掘金 (juejin.cn) 美团暑期实习的面经，绷不住了🤣

原面经链接：美团暑期一面_牛客网 (nowcoder.com)

不知道这位面试官是不是看了我的文章出的题，例子举的都大差不差🤣

我确实标题党了想整个活，没想到大厂面试官真出啊，还是实习生，刁难人有一手的🙃...

正文

取消功能

我们都知道 Promise 的状态是不可逆的，也就是说只能从 pending -> fulfilled 或 pending -> rejected，这一点是毋庸置疑的。

但现在可能会有这样的需求，在状态转换过程当中我们可能不再想让它进行下去了，也就是说让它永远停留至 pending 状态。

奇怪了，想要一直停留在 pending，那我不调用 resolve 和 reject 不就行了🤔

 const p = new Promise((resolve, reject) => {

    setTimeout(() => {

      // handler data, no resolve and reject

    }, 1000);

 });

 console.log(p); // Promise {<pending>} 💡

但注意我们的需求条件，是在状态转换过程中，也就是说必须有调用 resolve 和 reject，只不过中间可能由于某种条件，阻止了这两个调用。

其实这个场景和超时中断有点类似但还是不太一样，我们先利用 Promise.race 来看看：模拟一个发送请求，如果超时则提示超时错误：

const getData = () =>

  new Promise((resolve) => {

    setTimeout(() => {

      console.log("发送网络请求获取数据"); // ❗

      resolve("success get Data");

    }, 2500);

  });



const timer = () =>

  new Promise((_, reject) => {

    setTimeout(() => {

      reject("timeout");

    }, 2000);

  });



const p = Promise.race([getData(), timer()])

  .then((res) => {

    console.log("获取数据:", res);

  })

  .catch((err) => {

    console.log("超时: ", err);

  });

问题是现在确实能够确认超时了，但 race 的本质是内部会遍历传入的 promise 数组对它们的结果进行判断，那好像并没有实现网络请求的中断哎🤔，即使超时网络请求还会发出：

而我们想要实现的取消功能是希望不借助 race 等其他方法并且不发送请求。

比如让用户进行控制，一个按钮用来表示发送请求，一个按钮表示取消，来中断 promise 的流程：

当然这里我们不讨论关于请求的取消操作，重点在 Promise 上

其实按照我们的理解只用 Promise 是不可能实现这样的效果的，因为从一开始接触 Promise 就知道一旦调用了 resolve/reject 就代表着要进行状态转换。不过 取消 这两个字相信一定不会陌生，clearTimeout、clearInterval 嘛。

OK，如果你想到了这一点这个功能就出来了，我们直接先来看红宝书上给出的答案：

<!DOCTYPE html>

<html lang="en">

  <head>

    <meta charset="UTF-8" />

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

    <title>Document</title>

  </head>

  <body>

    <button id="send">Send</button>

    <button id="cancel">Cancel</button>

    

    <script>

      class CancelToken {

        constructor(cancelFn) {

          this.promise = new Promise((resolve, reject) => {

            cancelFn(() => {

              console.log("delay cancelled");

              resolve();

            });

          });

        }

      }

      const sendButton = document.querySelector("#send");

      const cancelButton = document.querySelector("#cancel");



      function cancellableDelayedResolve(delay) {

        console.log("prepare send request");

        return new Promise((resolve, reject) => {

          const id = setTimeout(() => {

            console.log("ajax get data");

            resolve();

          }, delay);



          const cancelToken = new CancelToken((cancelCallback) =>

            cancelButton.addEventListener("click", cancelCallback)

          );

          cancelToken.promise.then(() => clearTimeout(id));

        });

      }

      sendButton.addEventListener("click", () => cancellableDelayedResolve(1000));

    </script>

  </body>

</html>

这段代码说实话是有一点绕的，而且个人觉得是有多余的地方，我们一点一点来看：

首先针对于 sendButton 的事件处理函数，这里传入了一个 delay，可以把它理解为取消功能期限，超过期限就要真的发送请求了。我们看该处理函数内部返回了一个 Promise，而 Promise 的 executor 中首先开启了定时器，并且实例化了一个 CancelToken，而在 CancelToken 中才给 cancelButton 添加点击事件。

这里的 CancelToken 就是我觉得最奇怪的地方，可能没有体会到这个封装的技巧，路过的大佬如果有理解的希望能帮忙解释一下。它的内部创建了一个 Promise，绕了一圈后相当于 cancelButton 的点击处理函数是调用这个 Promise 的 resolve，最终是在其 pending -> fuilfilled，即 then 方法里才去取消定时器，那为什么不直接在事件处理函数中取消呢？难道是为了不影响主执行栈的执行所以才将其推到微任务处理🤔？

介于自己没理解，我就按照自己的思路封装个不一样的🤣：

const sendButton = document.querySelector("#send");

const cancelButton = document.querySelector("#cancel");



class CancelPromise {



 // delay: 取消功能期限  request：获取数据请求(必须返回 promise)

  constructor(delay, request) {

    this.req = request;

    this.delay = delay;

    this.timer = null;

  }



  delayResolve() {

    return new Promise((resolve, reject) => {

      console.log("prepare request");

      this.timer = setTimeout(() => {

        console.log("send request");

        this.timer = null;

        this.req().then(

          (res) => resolve(res),

          (err) => reject(err)

        );

      }, this.delay);

    });

  }



  cancelResolve() {

    console.log("cancel promise");

    this.timer && clearTimeout(this.timer);

  }

}



// 模拟网络请求

function getData() {

  return new Promise((resolve) => {

    setTimeout(() => {

      resolve("this is data");

    }, 2000);

  });

}



const cp = new CancelPromise(1000, getData);



sendButton.addEventListener("click", () =>

  cp.delayResolve().then((res) => {

    console.log("拿到数据：", res);

  })

);

cancelButton.addEventListener("click", () => cp.cancelResolve());

正常发送请求获取数据：

中断 promise：

没啥大毛病捏~

进度通知功能

进度通知？那不就是类似发布订阅嘛？还真是，我们来看红宝书针对这块的描述：

执行中的 Promise 可能会有不少离散的“阶段”，在最终解决之前必须依次经过。某些情况下，监控 Promise 的执行进度会很有用

这个需求就比较明确了，我们直接来看红宝书的实现吧，核心思想就是扩展之前的 Promise，为其添加 notify 方法作为监听，并且在 executor 中增加额外的参数来让用户进行通知操作：

class TrackablePromise extends Promise {

  constructor(executor) {

    const notifyHandlers = [];

    super((resolve, reject) => {

      return executor(resolve, reject, (status) => {

        notifyHandlers.map((handler) => handler(status));

      });

    });

    this.notifyHandlers = notifyHandlers;

  }

  notify(notifyHandler) {

    this.notifyHandlers.push(notifyHandler);

    return this;

  }

}

let p = new TrackablePromise((resolve, reject, notify) => {

  function countdown(x) {

    if (x > 0) {

      notify(`${20 * x}% remaining`);

      setTimeout(() => countdown(x - 1), 1000);

    } else {

      resolve();

    }

  }

  countdown(5);

});



p.notify((x) => setTimeout(console.log, 0, "progress:", x));

p.then(() => setTimeout(console.log, 0, "completed"));

emm 就是这个例子总感觉不太好，为了演示这种效果还用了递归，大伙们觉得呢？

不好就自己再写一个🤣！不过这次的实现就没有多大问题了，基本功能都具备也没有什么阅读障碍，我们再添加一个稍微带点实际场景的例子吧：

// 模拟数据请求

function getData(timer, value) {

    return new Promise((resolve) => {

      setTimeout(() => {

        resolve(value);

      }, timer);

    });

}



let p = new TrackablePromise(async (resolve, reject, notify) => {

  try {

    const res1 = await getData1();

    notify("已获取到一阶段数据");

    const res2 = await getData2();

    notify("已获取到二阶段数据");

    const res3 = await getData3();

    notify("已获取到三阶段数据");

    resolve([res1, res2, res3]);

  } catch (error) {

    notify("出错！");

    reject(error);

  }

});



p.notify((x) => console.log(x));

p.then((res) => console.log("Get All Data:", res));

对味儿了~😀

End

关于取消功能在红宝书上 TC39 委员会也曾准备增加这个特性，但相关提案最终被撤回了。结果 ES6 Promise 被认为是“激进的”：只要 Promise 的逻辑开始执行，就没有办法阻止它执行到完成。

实际上我们学了这么久的 Promise 也默认了这一点，因此这个取消功能反而就不太符合常理，而且十分鸡肋。比如说我们有使用 then 回调接收数据，但因为你点击了取消按钮造成 then 回调不执行，我们知道 Promise 支持链式调用，那如果还有后续操作都将会被中断，这种中断行为 debug 时也十分痛苦，更何况最麻烦的一点是你还需要传入一个 delay 来表示取消的期限，而这个期限到底要设置多少才合适呢...

至于说进度通知功能，仁者见仁智者见智吧...

但不管怎么样两个功能实现的思路都是比较有趣的，而且不太常见，不考虑实用性确实能够成为一道考题，只能说很符合面试官的口味😏