程序员的职业素养

职业素养

如果说个人能力是职业道路上的"外功"决定你走的多快，那么职业素养就是"内功"决定你走多远。

我将从一下几个方面来谈谈我对职业素养的认识

• 专业主义 （个人角度）
• 沟通协作 （团队角度）
• 理论实战

专业主义

1. 了解你的领域

1.1 编程规范

• 命名

  • 精简且有意义
    • 例如：返回遍历统一命名为 res // return res;
  • 统一的技术语言
    • 达成共识:DO、DTO、VO、Query/Req

• 方法封装

  • 一个方法最⻓不应超过80行

  • 一个方法的入参最多不应超过5个

• 防止破窗

  • 不做第一个“破窗”的人

    • 遵守规范
    • 不断学习，提升能力

  • 及时修复发现的“破窗”

    • 每次改进一点点
    • 绝不难上加难

1.2 基础建模

统一建模语言（UML），一图胜前言。

• 类图
• 时序图
• 活动图
• ...

1.3 设计原则

SOLID 是基础原则我们需要尽量遵守，但为了稳定性和快速迭代破坏其中的原则也无可厚非。

DRY是我们需要进行重构的重要信号。当你发现一个逻辑到处拷贝时，就需要考虑抽象整合了。

KISS是我们方案设计的首要原则，好的程序一定是迭代中诞生的，而不是一蹴而就。

• SOLID

  • Single Responsibility Principle（SRP）：单一职责原则
  • Open Close Principle（OCP）：开闭原则
  • Liskov Substitution Principle（LSP）：里氏替换原则
  • Interface Segregation Principle（ISP）：接口隔离原则
  • Dependency Inversion Principle（DIP）：依赖倒置原则

• DRY [Don’t Repeat Yourself]

• KISS [Keep It Simple and Stupid]

• Rule of Three

  • 第一次做某件事时只管去做
  • 第二次做类似的事会 产生反感，但无论如何还是可以去做
  • 第三次再做类似的事，你就应该重构

• Apache的架构师们遵循的30条设计原则

1.4 设计模式

设计模式主要为了解决程序复用问题，即DRY原则。单纯的炫技而设计，不仅不专业还会让专业的人贻笑大方。

• 定位

• • 可复用面向对象软件的基础

• 如何使用

• • 找出可复用的逻辑，进行抽象解耦

• 什么时候用

  • 参考设计原则

    • DRY
    • KISS
    • …

• 常用的设计模式

  • 简单工厂
  • 策略模式
  • 模板方法模式
  • 责任链模式

1.5 方法实践

集以上专业技能之大成者，盖 领域驱动 与 重构 也。

1.5.1 领域驱动

总览

自顶向下设计，核心包括以下两块

• 战略设计（如: 攻打平安城县城，李云龙布置战略设计，所有营都是主攻攻打县城，区小队配合阻击增援）
• 战术设计（如: 最后攻打城门，属于整个战役的具体一环，采用了二营长意大利炮轰）

核心思想

人们熟悉的是现实世界的规则，如出去玩，乘坐地铁需要先买票、安检进站、选择合适的班次上车、到站下车等。

DDD的思想是，将现实规则照搬进软件工程。对应接口或方法 buy 、 check 、 selectSubway 、 arrvied 等。

最后将需要实现的技术屏蔽到这些接口抽象之下。

就说同样的购票（buy），你无论是通过mq实现、亦或是直接mysql事务编程都不影响上游对该接口的依赖。

这也是依赖倒置思想的体现。

将屏蔽技术细节，反应世界原有的规则，这样使得项目更加容易上手和维护。

设计流程

• 需求分析
• 领域分析
• 领域建模
• 核心业务逻辑
• 技术细节(存储、消息…)

项目架构设计

• 接口层： controller
• APP层： controller的实现service层
• domain层： 领域层
• infrastructure层： 技术细节层

DDD学习推荐

• 文章

  • DDD在严选供应链复杂业务系统的落地实践
  • COLA 4.0：应用架构的最佳实践

• 书籍

  • 领域驱动设计
  • 代码精进之路 从码农到工匠
  • 中台架构与实现

• Demo

  • COLA 开源地址：https://github.com/alibaba/COLA

1.5.2 重构

重构的前提

不改变软件可观察的行为，即重前后程序的处理结果保持一致。

• 单测保证
• 集成测试-流量对比平台 保证

重构的时机

Rule of Three原则

• 第一次做某件事时只管去做
• 第二次做类似的事会 产生反感，但无论如何还是可以去做
• 第三次再做类似的事，你就应该重构

重构的核心思想

将原本臃肿复杂的逻辑拆分成一个个更短小精悍的实现。

越细的方法，越利于组合复用。

重构的实现

利用DDD拆分主流程，利用设计模式去遵守DRY原则

2. 了解你的业务领域

了解业务领域可以让你更好的设计出可拓展的、与业务保持一致的架构。

2.1 基本面

• 业务背景
• 业务主逻辑
• 业务上下游依赖
• 业务趋势
• ….

2.2 快速上手

• 查看项目相关文档
• 体验产品
• 构建项目 run起来
• 抓包并Debug跟踪一个场景
• 参与一个小迭代

沟通协作

1. 说“不”

• 说“不”的前提
  • 我们应尽可能的去实现我们可以实现的功能
  • 在通过专业主义的权衡后谨慎的说“不”
• 敢于说“不”，避免模棱两可的回答更有益于整个团队
• 拒绝思维定式，乐于接受与思考新的可能性
• 敢于承担说“不”的结果
  • 闭环分析，改进提升自己的专业性

2. 说“是”

• 说“是”的前提
  • 承担责任
  • 兑现承诺
• 坚守专业主义原则，否则说的也未必能兑现
• 另一种方法说“是”
  • 给出说是的前提
  • 给出一定能完成的最大期限，并说明可能提前完成

3. 压力

• 避免压力
  • 谨慎承诺
  • 坚持原则
  • 保持整洁
• 应对压力
  • 不必惊慌失措
  • 沟通
  • 坚持原则
  • 寻求帮助

理论实战

1. 方法论

• 设计的两部分
  • 战略设计 顶层分析规划
  • 战术设计 细节确认与实现
• 设计的主要流程
  • 需求分析
  • 领域分析
  • 领域建模
  • 核心业务逻辑
  • 技术细节(存储、消息…)

2. 实战

参考

• 《代码整洁之道 - 程序员的职业素养》
• 《重构 2》
• 《领域驱动设计》
• 《代码精进之路从码农到工匠》- 作者: 张建飞（CSND）
• 《设计模式：可复用面向对象软件的基础》

本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名,转载请标明出处
最后编辑时间为: 2022-03-16