关于后端:鹅厂程序员的9个生存法则

腾小云导读

本文作者在腾讯多年，次要从事的是腾讯云 CDN、EdgeOne 产品的后盾研发工作。作者在云计算畛域遇到了不少代码设计和程序设计的问题，他对于如何把我的项目中的代码标准化、进步开发保护的效率，做了总结梳理。本篇为各位分享作者总结的代码设计、架构设计准则和工作思维。欢送浏览～

目录

1 万物皆可形象

1.1 遵循 DRY 准则

1.2 SOLID 准则

1.3 利用设计模式

2 高可用设计

2.1 设计高可用的零碎架构

2.2 日志和监控，蕴含服务级和业务级

2.3 做好容灾设计 2.4 零碎稳固是一名后盾开发的生命线

3 想尽一切办法“偷懒”

3.1 优化反复流程、所有自动化

3.2 应用模板和标准化流程

3.3 利用项目管理工具和流程

4 从价值登程，专一于最重要的事

5 沟通与合作也是身为开发的必备技能

6 凡事有交代，件件有着落，事事有回音

7 放弃凋谢和学习的心态

8 职业倒退

9 横向发展

01、万物皆可形象

1.1 遵循 DRY 准则

DRY 准则（Don’t Repeat Yourself），中文直译为：不要反复本人。将它利用在编程中，能够了解为：不要写反复的代码。

或者有些开发者会想当然地认为，只有代码有反复就是违反 DRY 准则了。真的是这样吗？答案是否定的。实际上，反复的代码不肯定违反 DRY 准则，而有些看似不反复的代码也有可能违反 DRY 准则。

DRY 准则的典型代码反复状况有三种： 实现逻辑反复、性能语义反复和代码执行反复 。上面咱们简略分享。

1.1.1 实现逻辑反复

以下是一个实现逻辑反复的例子：

class Calculator:
    def add(self, a, b):
        return a + b

    def subtract(self, a, b):
        return a - b

    def multiply(self, a, b):
        return a * b

    def divide(self, a, b):
        if b == 0:
            # ...throw DivideByZeroException...
        pass
        return a / b

class AdvancedCalculator(Calculator):
    def power(self, a, b):
        result = 1
        for i in range(b):
            result *= a
        return result

    def square_root(self, a):
        if a < 0:
            # ...throw InvalidInputException...
            pass
        return math.sqrt(a)

在这个例子中，AdvancedCalculator 继承了 Calculator，然而在 AdvancedCalculator 中实现了 power 和 square\_root 办法，这两个办法的实现与 Calculator 中的 multiply 和 divide 办法有很多反复的逻辑。例如，power 办法中的循环能够应用 multiply 办法来实现，square\_root 办法中的判断能够应用 divide 办法来实现。这种反复的逻辑会导致代码简短、难以保护，并且容易呈现谬误。

1.1.2 性能语义反复

性能语义反复是指代码中存在雷同的性能语义，然而代码的实现不同。例如，以下代码中的两个函数都实现了计算一个数的平方，然而它们的实现形式不同：

def square1(x):
    return x ** 2

def square2(x):
    return pow(x, 2)

能够看到，这段代码中存在雷同的性能语义，即计算一个数的平方，然而代码的实现不同。如果咱们遵循 DRY 准则，能够将计算一个数的平方形象成一个函数，而后在须要计算平方的中央调用该函数，防止了性能语义的反复。

def square(x):
    return x ** 2

1.1.3 性能语义反复

UserService 中 login() 用来校验用户是否登陆胜利，如果失败就返回异样，否则返回用户信息。

class UserRepo:
    def __init__(self, db):
        self.db = db

    def check_if_user_existed(self, email, password):
        if not EmailValidation.validate(email):
            # ...throw InvalidEmailException...
            pass
        if not PasswordValidation.validate(password):
            # ...throw InvalidPasswordException...
            pass
        # ...query db to check if email&password exists...
        
    def get_user_by_email(self, email):
        if not EmailValidation.validate(email):
            # ...throw InvalidEmailException...
            pass
        # ...query db to get user by email...

class UserService:
    def __init__(self, user_repo):
        self.user_repo = user_repo

    def login(self, email, password):
        existed = self.user_repo.check_if_user_existed(email, password)
        if not existed:
            # ...throw AuthenticationFailureException...
            pass
        user = self.user_repo.get_user_by_email(email)
        return user

从下面代码能够发现，login() 调用 UserRepo 的 check\_if\_user\_existed() 和 get\_user\_by\_email()，这两个函数都校验了一次 email。咱们能够将校验代码放到 login() 即可。

另外还有一个暗藏的执行反复问题，login() 并不需要调用 check\_if\_user\_existed()，只须要调用一次 get\_user\_by\_email()，从数据库中获取用户的 email、password 等信息跟用户输出的 email、password 信息做比照，顺次判断是否登陆胜利。

实际上，这样的优化是很有必要的，因为两个函数都查问了数据库，数据库 I/O 操作是比拟耗时的，在写代码的时候该当缩小这类 I/O 操作。

依照刚刚的思路把代码重构一下：

class UserService:
    def __init__(self, user_repo):
        self.user_repo = user_repo

    def login(self, email, password):
        if not EmailValidation.validate(email):
            # ...throw InvalidEmailException...
            pass
        if not PasswordValidation.validate(password):
            # ...throw InvalidPasswordException...
            pass
        user = self.user_repo.get_user_by_email(email)
        if user is None or password != user.password:
            # ...throw AuthenticationFailureException...
            pass
        return user
class UserRepo:
    def __init__(self, db):
        self.db = db

    def check_if_user_existed(self, email, password):
        # ...query db to check if email&password exists...

    def get_user_by_email(self, email):
        # ...query db to get user by email...

这样做当前，整个代码构造变得更清晰了，类的职责也更加对立。

身为一名合格的程序员，要时刻谨记不干“反复”的事件，能形象的都做形象，对后续零碎的保护有很大的帮忙。

1.2 SOLID 准则

在程序设计畛域，SOLID（繁多性能、开闭准则、里氏替换、接口隔离以及依赖反转）是由罗伯特·C·马丁在 21 世纪晚期引入，指代了面向对象编程和面向对象设计的五个根本准则。当这些准则被一起利用时，它们使得一个程序员开发一个容易进行软件维护和扩大的零碎变得更加可能。

1.2.1 繁多职责准则（Single Responsibility Principle，SRP）

一个类应该只有一个职责。通过将职责形象成不同的类或办法，咱们能够更好地组织和治理代码。

所谓职责是指类变动的起因。如果一个类有多于一个的动机被扭转，那么这个类就具备多于一个的职责。而繁多职责准则就是指一个类或者模块应该有且只有一个扭转的起因。

很多人认为这个准则是针对一个类进行形容，在我看来这里应用模块这个更加形象的名词更为适合。在设计中，小到一个办法，大到一个模块咱们都应该尽量去遵循繁多职责准则。

置信在咱们日常开发中，每个人都遇到过改了一个问题常常会引起另一个问题。其起因大多都是因为在设计上违反了繁多职责准则。

如果一个类承当的职责过多，就等于把这些职责耦合在一起了。一个职责的变动可能会减弱或者克制这个类实现其余职责的能力。这种耦合会导致软弱的设计，当发生变化时，设计会蒙受到意想不到的毁坏。而如果想要防止这种景象的产生，就要尽可能地恪守繁多职责准则。

此准则的外围就是解耦合加强内聚性，是为了实现代码高内聚、低耦合，进步代码的复用性、可读性、可维护性。

还是下面的例子：

class UserManager:
    def __init__(self, user_repo):
        self.user_repo = user_repo

    def create_user(self, name, email, password):
        if not EmailValidation.validate(email):
            # ...throw InvalidEmailException...
            pass
        if not PasswordValidation.validate(password):
            # ...throw InvalidPasswordException...
            pass
        user = User(name, email, password)
        self.user_repo.save_user(user)

    def get_user_by_email(self, email):
        if not EmailValidation.validate(email):
            # ...throw InvalidEmailException...
            pass
        user = self.user_repo.get_user_by_email(email)
        return user

class UserRepo:
    def __init__(self, db):
        self.db = db

    def save_user(self, user):
        # ...save user to db...

    def get_user_by_email(self, email):
        # ...query db to get user by email...

还是相似的例子，UserManager 类负责用户的创立和获取，而 UserRepo 类负责用户的存储和查问。这两个类各自承当了不同的职责，合乎繁多职责准则。如果将这两个职责合并到一个类中，就会导致这个类的职责过于简单，难以保护。

1.2.2 开闭准则（Open-Closed Principle，OCP）

当咱们在软件开发中增加新性能或批改现有性能时，咱们心愿这些更改不会毁坏现有的代码。这就是开闭准则（Open-Closed Principle，OCP）的核心思想：软件实体（类、模块、函数等）应该对扩大凋谢，对批改敞开。

换句话说，咱们应该通过增加新的代码来扩大软件的性能，而不是批改现有的代码。这样做的益处是，咱们能够保障现有的代码依然可能失常工作，同时也能够防止引入新的谬误。

以下是一个合乎开闭准则的例子：

class Shape:
    def area(self):
        pass

class Rectangle(Shape):
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def area(self):
        return self.width * self.height

class Circle(Shape):
    def __init__(self, radius):
        self.radius = radius

    def area(self):
        return math.pi * self.radius ** 2

在这个例子中，Shape 类定义了一个形象办法 area，示意计算形态的面积。Rectangle 和 Circle 类继承了 Shape 类，并实现了 area 办法来计算矩形和圆形的面积。如果咱们须要增加一个新的形态，例如三角形，咱们只须要创立一个新的类并实现 area 办法即可，而不须要批改现有的代码。

这个例子中的代码合乎开闭准则，因为它对扩大凋谢（咱们能够增加新的形态），对批改敞开（咱们不须要批改现有的代码）。

遵循开闭准则的益处是，咱们能够编写具备可扩展性和可维护性的代码，从而进步软件开发的效率和品质。如果咱们的代码不具备这些个性，那么在软件开发过程中就会遇到很多问题，例如：

遵循开闭准则是十分重要的，它能够帮忙咱们编写具备可扩展性和可维护性的代码，从而进步软件开发的效率和品质。

1.2.3 里氏替换准则（Liskov Substitution Principle，LSP）

里氏替换准则（Liskov Substitution Principle，LSP）是 SOLID 准则中的第三个准则，它强调了子类应该可能替换其父类并且不会影响程序的正确性。

里氏替换准则强调的是设计和实现要依赖于形象而非具体；子类只能去扩大基类，而不是暗藏或者笼罩基类，它蕴含以下 4 层含意

子类能够实现父类的形象办法，但不能笼罩父类的非形象办法，父类中但凡曾经实现好的办法（绝对于形象办法而言），实际上是在设定一系列的标准和契约，尽管它不强制要求所有的子类必须听从这些契约，然而如果子类对这些非形象办法任意批改，就会对整个继承体系造成毁坏。

以下是一个合乎里氏替换准则的例子：

class Rectangle:
    def __init__(self, width, height):
        self.width = width
        self.height = height

    def get_width(self):
        return self.width

    def set_width(self, width):
        self.width = width

    def get_height(self):
        return self.height

    def set_height(self, height):
        self.height = height

    def area(self):
        return self.width * self.height

class Square(Rectangle):
    def __init__(self, size):
        self.width = size
        self.height = size

    def set_width(self, width):
        self.width = width

    def set_height(self, height):
        self.width = height

在这个例子中，Rectangle 类示意一个矩形，它有一个 width 和一个 height 属性，以及一个计算面积的办法 area。Square 类继承了 Rectangle 类，并重写了 set\_width 和 set\_height 办法，以确保正方形的宽和高始终相等。

这个例子中的代码合乎里氏替换准则，因为咱们能够用 Square 类的实例替换 Rectangle 类的实例，并且程序的行为不会受到影响。这是因为 Square 类继承了 Rectangle 类的行为，并且没有扭转它。

1.2.4 接口隔离准则（Interface Segregation Principle，ISP）

接口隔离准则也叫 Interface Segregation Principle、ISP，要求程序员尽量将臃肿宏大的接口拆分成更小的和更具体的接口，让接口中只蕴含客户感兴趣的办法。2002 年罗伯特·C·马丁给“接口隔离准则”的定义是：客户端不应该被迫依赖于它不应用的办法（Clients should not be forced to depend on methods they do not use）。

该准则还有另外一个定义：一个类对另一个类的依赖应该建设在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。

以上两个定义的含意是：要为各个类建设它们须要的专用接口，而不要试图去建设一个很宏大的接口供所有依赖它的类去调用。

感觉可能与繁多职责准则很像，接口隔离准则和繁多职责都是为了进步类的内聚性、升高它们之间的耦合性，体现了封装的思维，但两者是不同的：

简略来说接口隔离准则与繁多职责的定义的规定是不雷同的，繁多职责要求的是类和接口职责繁多，重视的是职责，没有要求接口的办法缩小，例如一个职责可能蕴含 10 个办法，这 10 个办法都放在一个接口中，并且提供给多个模块拜访，各个模块依照规定的权限来拜访，在零碎外通过文档束缚不应用的办法不要拜访，依照繁多职责准则是容许的，依照接口隔离准则是不容许的。

1.2.5 依赖倒置准则（Dependency Inversion Principle，DIP）

依赖倒置准则（Dependency Inversion Principle，简称 DIP）是面向对象设计准则之一，它强调高层模块不应该依赖于低层模块，而是应该依赖于形象。换句话说，依赖关系应该建设在抽象层次上，而不是具体实现档次上。这样能够升高模块间的耦合度，进步零碎的可扩展性和可维护性。

依赖倒置准则次要蕴含以下两个方面：

为了更好地了解依赖倒置准则，咱们能够通过以下几个步骤来利用它：

辨认模块间的依赖关系：在设计零碎时，咱们须要辨认出各个模块之间的依赖关系，以便确定哪些模块须要遵循依赖倒置准则。

依赖倒置准则是一种无效的设计准则，能够帮忙咱们构建更加灵便、可扩大和可保护的零碎。通过将依赖关系建设在抽象层次上，咱们能够升高模块间的耦合度，从而进步零碎的整体品质。

1.2.6 小结

1.3 利用设计模式

设计模式是一种常见的代码设计思维，它能够帮忙咱们解决常见的代码设计问题。通过应用抽象思维，咱们能够更好地了解和利用设计模式，以便更好地组织和治理代码。

抽象思维在代码设计中十分重要。通过应用不同的代码设计思维和准则，咱们能够将具体的事物形象成一般性的概念或模型，以便更好地组织和治理代码。一堆形象度很低的代码，很容易就会成为咱们我的项目当中人人鄙弃的对象（简称代码“屎山”）。

这里总结了 23 种常见的设计模式，在做零碎设计时，能够依据需要，应用对应的设计模式：

02、高可用设计

2.1 设计高可用的零碎架构

高可用的零碎架构是实现零碎高可用性的根底。因而，咱们应该设计高可用的零碎架构，包含负载平衡、集群、分布式、异地多活等特点。例如，咱们能够应用腾讯云 CLB 来实现负载平衡，应用 Kubernetes 来实现容器集群，应用分布式数据库来实现数据的高可用性，应用异地多活来实现零碎的容灾和备份。

在零碎设计之初，肯定要避免出现服务单点问题！

2.2 日志和监控，蕴含服务级和业务级

监控是保证系统高可用性的重要伎俩。咱们应该做好各路的监控，包含零碎的性能监控、服务的衰弱监控、网络的流量监控、日志的收集和剖析等。通过监控，咱们能够及时发现零碎的异样和故障，疾速定位和解决问题，保证系统的稳定性和可用性。

在做日志和监控设计时，应该思考以下因素：

2.3 做好容灾设计

容灾设计对于一个零碎的稳定性来说至关重要。从零碎和架构设计的角度，做好服务容灾须要综合思考多个方面，包含分布式架构、多数据中心冗余、数据备份与复原、容灾预案、监控告警、容量布局等。通过这些措施，能够进步零碎的可用性和容错能力，确保在产生劫难时可能疾速复原服务。

对于局部零碎，在产生故障时，选择性地进行服务降级，也是一种无效的伎俩：就义掉不重要的服务，保障外围服务的失常运行。

上面有一些容灾设计的准则，供大家参考：

2.4 零碎稳固是一名后盾开发的生命线

稳固是后盾开发的生命线。咱们应该重视零碎的稳定性和可靠性，从设计、开发、测试、部署、运维等各个环节，都要重视稳定性和可靠性验证。咱们应该遵循“稳固优先”的准则，保证系统的稳定性和可用性，为用户提供更好的服务和体验。

此外，腾讯云开发者公众号也分享过不少对于高可用零碎的建设思路和教训如工作十年，在腾讯积淀的高可用零碎架构设计教训、腾讯专家 10 年积淀：后海量时代的架构设计。

03、想尽一切办法“偷懒”

这里说的“偷懒”并不是让大家真的去偷懒，而是一种思考问题的形式。

打个比方，产品经理常常会要求咱们导出近期一段时间内，用户的沉闷数据、用户的付费志愿、域名的带宽增长状况、某个新上性能的应用状况等，每次的要求都有所不同，十分消耗和占用研发的工夫。前面咱们想了个方法，咱们将这些经营根底数据（用户纬度、域名纬度、性能纬度），统统上报到公司的 BI 零碎（相似于一个经营报表生成平台），让产品自行决策须要哪些数据、怎么应用这些数据，这样研发既不须要再给产品经理导出数据，又能够让产品经理本人随便“折腾”，单方的效率都失去了很大的晋升。

上面这些方法论能够供应大家参考。

3.1 优化反复流程、所有自动化

在工作中，咱们常常须要解决反复的流程，例如手动导出数据、手动解决数据等等。这些反复的流程不仅浪费时间和精力，还容易引入谬误和破绽。倡议定期复盘近期始终在反复做的事件，被动优化掉这些反复的工作内容。

3.2 应用模板和标准化流程

模板和标准化流程是另一种防止反复流程的办法。例如，咱们能够应用标准化流程来解决数据，应用模板来生成反复的文档或报告等等。举个例子，咱们须要每周向客户发送一份报告，将每周的经营数据和相干状况同步给客户。其实咱们齐全能够创立了一个标准化的报告模板，并应用自动化脚本来生成报告，这样大大减少了手动编写报告的工作量，进步了工作效率。

3.3 利用项目管理工具和流程

项目管理工具和流程是一种常见的治理办法，它们能够帮忙咱们优化反复流程，进步工作效率。例如，咱们能够应用项目管理工具来跟踪工作和进度，应用流程图来优化流程等等。

04、从价值登程，专一于最重要的事

咱们应该始终保持从用户价值和需要价值登程，关注用户的需要和痛点，为用户提供有价值的产品和服务。同时，咱们也应该多问一些为什么，思考这件事是否是当下最重要的事件，这个事件不做或怎么样，以后我最重要的是做什么。只有选对了办法和方向，能力做出有意义的事件，为用户和整个产品发明价值。

在我过来的教训外面，很多时候后方接触客户的同学常常会叫着说“XX 客户要求实现一个怎么怎么样的需要，咱们连忙搞起来”，但往往这个时候，我会反诘一句：“这个事件不做会怎么样？做了又能带来什么收益？咱们是不是应该从整个零碎设计的角度，提前就满足好这类客户的需要，而不是长期抱佛脚？”。其实咱们会发现，往往就因为这么多问一句，会发现其实这个需要并没有那么重要，更重要的是咱们须要提炼出更多通用化系统化的能力，提前满足到这类用户 / 客户的场景，对于咱们整个零碎和产品的久远倒退来说显得尤为重要。

如果咱们总是在干一些疾速和短期的事件，就须要思考咱们是否真的在朝着咱们的指标在进发了。

05、沟通与合作也是身为开发的必备技能

在软件开发中，沟通能力是十分重要的技能。很多开发同学会间接把本人简略纯正地定义为“一个只负责写代码的人”，这其实是一个思维上的误区。在开发过程中，程序员其实须要与团队成员如产品经理，甚至用户或客户进行大量的沟通，以便更好地了解需要、协同工作、解决问题等。

• 更好地了解需要

程序员须要与产品经理，甚至用户进行沟通，以便更好地了解需要。只有了解了用户和客户的需要，能力开发出合乎需要的软件产品。如果程序员没有良好的沟通能力，就很难了解用户和客户的需要，从而导致开发出的软件产品与用户和客户的需要不符。

• 协同工作

略微大点的我的项目开发，往往是一场“团战”。程序员须要与其余共事进行沟通，以便更好地协同。只有通过良好的沟通，团队成员能力了解彼此的需要和想法，协同实现我的项目的开发和交付。如果程序员没有良好的沟通能力，就很难与团队成员进行无效的沟通和合作，从而导致我的项目的延误和品质问题。

• 解决问题

在软件开发中，问题是难以避免的。程序员须要与团队成员、用户、客户等进行沟通，以便更好地解决问题。只有通过良好的沟通，能力及时发现和解决问题，保障我的项目的顺利进行。如果程序员没有良好的沟通能力，就很难与团队成员、用户、客户等进行无效的沟通和问题解决，从而导致问题的滋生和扩充。

• 推动和解决

在大公司外面，推动沟通能力也是一种掌控资源的能力，咱们往往会发现，沟通不好的人推动事件总是很慢，总是取得不到他想要的资源，导致事件始终难以获得落地。

打个比方，TEAM A 的小 X 是一名程序员，尽管技术能力很强但不善言辞，他在我的项目上有一个获取 IP 地理位置的需要，刚好另一个团队 TEAM B 有这块的一些积攒，小 X 心愿能调用他们的接口，获取到 IP 的一些地理位置信息。但奈何 TEAM B 的同学对这个事件提不起趣味，感觉这不是他们的任务，也没什么收益，所以不论小 X 怎么致力，TEAM B 的人就是不予理睬，不配合。这时候小 X 的一位共事小 Y 发现了这个问题，并帮助他一块解决，小 Y 是怎么做的呢，首先小 Y 拉上了 TEAM A 和 TEAM B 团队的领导，并阐明了这个事件的重要性、对公司的意义、对单方团队的收益，很快，TEAM B 的领导马上就安顿了一名团队外围骨干同学参加反对，并解决了问题，小 X 对小 Y 拜服得嗤之以鼻。

所以，沟通能力对于程序员来说也十分重要，千万别小看沟通这项技能，毕竟身为程序员，除了写代码以外，还有很长的工夫都在和人在打交道。

06、凡事有交代，件件有着落，事事有回音

“凡事有交代，件件有着落，事事有回音”，其实翻译过去就是“做事靠谱”，负责的事件肯定会认真负责到底，及时反馈和响应。

成为一位靠谱共事，你的行为准则就是你集体的铭牌，共事会非常违心与你单干。职场实质上也是一个互相支持的过程，你对他人工作的反对，在你有求时他人也会积极支持你。

成为一位靠谱的员工，下属会十分喜爱这类员工，工作认真负责，交办的事可控。你的行事格调，会让下属看在眼里，记在心里，在下属打考核的时候也会思考到这一点。

遵循“凡事有交代，件件有着落，事事有回音”准则，可能更好地实现本人的工作工作，提大家整体的合作效率，在我看来也是十分重要的一项行为准则。

07、放弃凋谢和学习的心态

在以后技术更新迭代速度十分快的时代，程序员须要时常放弃有一颗学习的心态。

• 技术更新迭代速度十分快

以后的技术更新迭代速度十分快，新技术和新工具层出不穷。如果程序员不放弃凋谢和学习的心态，就很容易被淘汰，无奈适应新的技术，从而影响长期的职业倒退。

• 学习是程序员的必备技能

作为程序员，学习是必备的技能。只有一直学习新的技术和工具，能力放弃本人的竞争力和创新能力。比方最近火爆全网的 chatgpt，如果不及时跟进学习相似的 AI 工具，置信很快就会有不少的人被淘汰掉。

• 学习能够进步工作效率和品质

学习新的技术和工具能够进步程序员的工作效率和品质。新的技术和工具通常都有更高效的解决方案和更好的性能，能够帮忙程序员更快地实现工作工作，进步工作效率和品质。比方 GO 语言在 1.18 版本新推出的泛型反对，能够很好地解决 GO 中不足泛型，导致一个雷同性能的函数，须要为不同的变量类型反复写很多遍函数的问题。

总体来说，程序员我认为是一个须要放弃一生学习的职业，常识永远都在往前更新迭代，咱们须要做的，就是放弃一颗凋谢和学习的心态，对技术放弃敏感和热度。

08、职业倒退

职场中不免遇到不好的团队、不好的我的项目，这种时候该怎么办？从三个角度登程：

· 是否工作得开心。

· 在这里工作是否能继续失去自我晋升和自我满足。

· 金钱方面是否可能满足。

如果三个外面有两个都是“NO”，那么你可能须要考虑一下换份工作了，换一个更广大的平台，找到一条适合本人的路线。每个人都是一个自在而独立的个体，咱们大可不必吊死在一棵树上。

09、横向发展

作为一名开发，往往会将本人的视线仅仅聚焦在手头在做的事件下面，疏忽了本人身份是一个职业人的事实。因而，多做“横向发展”十分重要：

• 加强职业竞争力

除了技术能力之外，软性技能也十分重要。例如沟通能力、团队单干能力、领导力等，都能够帮忙咱们更好地实现工作工作，进步工作效率和品质。如果程序员只关注技术能力，而疏忽了软性技能，就会在职业竞争中处于劣势，毕竟咱们的工作内容可不只有敲代码这件事。

• 拓宽职业倒退路线

多元化倒退能够拓宽职业倒退路线。程序员能够通过学习其余畛域的常识和技能，拓宽本人的职业倒退路线。例如，学习产品设计、市场营销等常识，能够帮忙咱们更好地了解客户需要和市场趋势，从而更好地实现工作工作，实现职业倒退。

• 将来的抉择更多样化

多做一些其余畛域的常识储备，能够在咱们将来无奈持续胜任开发工作的时候，有更多的职业抉择。领有技术背景的咱们，转到其余岗位上也会有锦上添花的感觉。

以上就是本篇文章的全部内容啦，如果感觉内容有用，欢送转发珍藏 \~

聊一聊令你受害的职场思维（点这里进入开发者社区，左边扫码即可进入公众号）。咱们将选取 1 则最有创意的分享，送出腾讯云开发者 - 马克杯 1 个（见下图）。5 月 31 日中午 12 点开奖。