鹅厂程序员的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 小结
| 原则 | 含义 |
|---|---|
| 单一职责原则 （Single Responsibility Principle，SRP） | 一个类应该只要一个职责。经过将职责笼统成不同的类或方法，咱们能够更好地安排和办理代码。 |
| 开闭原则 （Open-Closed Principle，OCP） | 一个类应该对扩展敞开，对修正关闭。经过运用笼统类或接口来界说通用的方法或特色，咱们能够更好地完结代码的扩展性。 |
| 里氏替换原则 （Liskov Substitution Principle，LSP） | 子类应该能够替换父类。经过运用笼统类或接口来界说通用的方法或特色，咱们能够更好地完结代码的可扩展性和可保护性。 |
| 接口阻隔原则 （Interface Segregation Principle，ISP） | 一个类不应该依靠于它不需求的接口。经过将接口笼统成不同的类或方法，咱们能够更好地安排和办理代码。 |
| 依靠倒置原则 （Dependency Inversion Principle，DIP） | 高层模块不应该依靠于低层模块，它们应该依靠于笼统。经过运用笼统类或接口来界说通用的方法或特色，咱们能够更好地完结代码的可扩展性和可保护性。 |
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点开奖。
