技术领导力¶

Preface¶

技术，技术，技术¶

• 一旦技术人成长为技术领导之后，有个问题就会像“我是谁”一样一直困扰着我们：我还需要在技术领域孜孜以求吗？答案当然是要。你是技术领导啊，又不是产品经理。技术这东西是很实在的，泾渭分明，会就是会，懂就是懂，很难不懂装懂。在现在这个时代，技术是需要我们终其一生学习的东西。
• 对于聪明人来说，有实践机会，管理可以在短时间内达到一个不错的水准，但技术永远需要长时间积累。钻研技术，并不是让你增加自己的代码量，事实上一个领导者每天深夜像打字机一样咔咔地提交代码，对组内成员是极大的压力。一个技术领导，更多是通过对技术领域的探求打磨自己的技术敏感度和技术决策力。
• 什么阶段引入什么技术，什么时候重构，什么时候重写，如何利用技术驱动产品，如何构建技术平台……这些都是技术领导需要思考并确定的问题，这些都将依托你强大的技术背景。

技术管理工作¶

技术管理¶

• 定义

  • 技术管理就是这么一种组织团队共同进行研发的工作，它是一门细分工种，随着社会的进步、人类思维的开放、经济水平的提升，被管理者（工程师们）逐渐从单纯为了解决物质矛盾转化为追求工作的归属感、参与感、技术尊重感，他们逐渐对跟着谁一起工作、采用哪种工作方式、解决了什么样的技术问题、做出了什么样的产品感兴趣，而不是仅仅满足于金钱的多少。
  • 同时，被管理者之间还存在紧密的社交关系，能够随时保持沟通，分享对在该公司或组织工作的切身感受，分享对于管理者个人能力、品德的认识。
  • 每位技术团队管理者，也正在像书一样被摆放在被管理者面前，如果别人懒得翻你，就证明你不能给予他们指导，他们没有归属感，最终都会匆匆离职。

• 必备技能

  • 深入理解一门或多门编程语言
  • 深入理解多种流行的框架
  • 系统架构能力强，拥有复杂系统的设计经验
  • 积极跟随开源社区
  • 积极了解业界技术发展
  • 沟通能力强、情商高
  • 有产品意识，不是技术迷
  • 会带人，服从领导，责任心强
  • 会写专利
  • 再会点别的更好
  • 随叫随到、工资不高
  • （总之，上得“厅堂”、下得“厨房”、忍气吞声、专业背锅）

• 工作

  • 管事

    • 项目管理
    • 时间管理
    • 技术管理

  • 管人

    • 人才招募
    • 团队建设
    • 人才培养

  • 定方法

    • 流程改进
    • 目标管理

  • 拿结果

    • 制度管理
    • 绩效管理

技术团队领导者¶

• 工作职责定位

  • 一位管理者最重要的是给团队指明方向，包括技术方向和业务方向，还有个人成长方向。
  • 与下属相比，领导者的优势不只在于他的专业能力，还在于他的眼光和胸怀。既然选择做技术管理，你就要有成就他人的心胸，同时还要有超出一般人的眼界，能够给予团队正确的方向
  • 。同时，要保持对技术的兴趣，多关注新技术的发展，否则你很难在重大的技术决策上做出正确的决定。

• 工作品质定位

  • 成熟

    • “走向成熟就是独立得更彻底而又联系得更紧密。”——霍夫曼·斯塔尔
    • 成熟的人具备一些典型特征，他们重视诺言、不夸夸其谈、有学识而含蓄内敛、心胸宽广、不以自我为中心、勇于承认错误、意志坚定。凭自身的品格、实力与信誉在人群中从容地来去，这样的人流溢着非凡的魅力。成熟的人刚强豁达，待人宽容、知足乐观，他们知道为人处世的原则，懂得如何处理好与朋友、同事的关系。
    • 我认为衡量一个团队的凝聚力是否强大，看看这类员工的占比就知道了，缺少这类员工的团队一定不会有什么了不起的成绩。

  • 勇敢

    • “勇往直前地去做，直到成功为止。”——罗斯福

  • 热爱技术

    • “科学所以叫作科学，正是因为它不承认偶像。”——斯大林
    • 我们必须让别人知道我们是专家，我们团队很牛。
    • 但有一点需要注意，只有做好当前的事情，你才有资格谈技术理想。

  • 勤奋

    • 一万小时定律：要成为某个领域的专家，需要一万个小时的训练。按比例计算就是：如果每天工作八个小时，一周工作五天，那么成为一个领域的专家至少需要五年。

  • 逻辑能力

    • “没有一门科学比逻辑科学更强烈地感到需要从问题实质本身开始，而无须先行的反思。”——黑格尔
    • 设计（Design）、建模（Model）、编码（Code）、调试（DeBug）、重构（Refactor）、沟通（Communicate）、学习（Learn）和思考（Think），所有这些工作对一个人的逻辑能力要求都很高。

  • 一线作战精神

    • 无论你是CTO、CEO，还是CFO，既然承担了团队负责人的实际工作，那么就应该每天召开例会，不断地抽时间和大家一起讨论架构、业务流程、技术难点、技术方向，这是你的职责，不要来谈你有多忙；
    • 而不是让团队处于流浪状态。

  • 决策能力

    • 1）开放的提炼能力。

      • 开放的提炼能力是指管理人才以开放的态度，准确和迅速地提炼出解决问题的各种方案的能力。
      • 包括两个基本要素：第一、要以开放和包容的思想及态度尽可能广泛地获取决策方案，特别是不要局限于传统的解决办法之中，要善于“借外脑”来帮助判定决策方案；
      • 第二、需要对各种决策方案进行提炼，以把握各种方案的本质和核心，正确地评估每个方案的条件及效果，分析各个方案实施的可能性。

    • 2）准确的预测能力。

      • 决策与预测是密不可分的，要具备卓越的决策能力，首先应具备准确的预测能力。
      • 预测是决策的基础，决策是预测的延续；
      • 预测的目的是为企业的决策提供准确的资料、信息和数据，在正确预测的基础上，选择符合企业发展的满意方案。

    • 3）准确的决断能力。

      • 即能从众多的决策方案中选取满意方案的能力，以及危机时刻或紧要关头有当机立断的决断能力。
      • 这种能力是进行科学决策的关键能力，误选、漏选会使企业造成重大损失或与成功失之交臂。
      • 对此，必须把握以下几个主要标准。
      • 一是所选方案 实施的条件 要具备。若条件不具备，则要弄清获得该条件的代价是什么。
      • 二是所选方案要与 企业的宗旨和决策目标 相符，若不符则不可取。
      • 三是所选方案要能被决策方案的受益人及 相关利益人 所接受。
      • 四是所选方案要能被决策方案的 执行者 所接受。好的决策方案只有执行和实施后才能达到最终的目的，因此要注意决策方案的可接受性。
      • 五是能正确评估决策方案的 风险。有些人在选取决策方案时只看到“乐观”的一面，而没有考虑环境的可能变化，这种“乐观”情绪往往会给企业造成重大损失

  • 开放姿态

    • 我可能会不赞成你的看法，但是我尊重并捍卫你说话的权利。——伏尔泰
    • 曾经在微信上看到某位投资者的文章，他曾经对一家技术公司进行评估，各项指标都比较满意，但最终放弃的原因是：该公司CTO的管理方式非常野蛮，他不允许别人对他提出的技术方案提意见，提出意见就会被他冷嘲热讽，最终团队中全是老实巴交、毫无追求的程序员。基于CTO（首席技术官）这样的管理方式，这个公司的技术能力和积累，无论当下还是未来，发展都会受到限制。
    • 我们需要倡导“开放、共享、追求极致”的团队文化。
    • 人才是我们最大的财富，所以要建设以人为本的团队文化，创造出沟通顺畅、敢于挑战、喜欢创新的团队氛围。在团队文化建设方面，主要倡导的是互联网文化、极客精神。有的工程师，为了开发一个高效的算法，通宵熬夜，结果虽然只提升了短短的10毫秒，但这就是追求极致的精神。试想在一个亿万级调用量的场景下，提升10毫秒，效果将是质的变化。据说国外某家投资银行为了提升1秒的系统研发投入几千万美元，可见其价值。
    • 作为一个管理者，你的重点应该首先在于创建出有良好化学反应的、能把事情做好的团队，然后再考虑分配什么任务给他们。好的团队，不仅可以很好地协同工作，还能彼此互相学习。

  • 宽容

    • “庆祝你的成功，在失败中寻找幽默。别太把自己当回事儿，你放松，你周围的人才能放松。享受乐趣，并始终保持激情。”——山姆·沃尔顿，沃尔玛创始人

  • 仔细

    • 仔细的人一般做事都比较负责，愿意承担责任，也懂得抓细节。
    • 所谓的管理浮于表面，一般都是说管理者不关注细节，例如不参与设计、不参与代码审核，而只是高喊要注意开发设计、注意开发质量，这样的领导对于技术团队来说，尤其是一线技术团队经理来说，是不合格的，也是不能服众的。

  • 终身学习

    • 一个事实：一个人一生如果想要获得过人的成就，就注定与读书和终生学习形影不离。
    • 终生阅读和学习的巴菲特，即使在84岁的高龄，还掌管着全世界最大的投资公司，保持着敏锐的大脑和思维，以及对工作和生活的热爱。
    • 爱因斯坦曾经说过，复利（Compounded Interest）是这个世界上的第八大奇迹，那些理解并学会使用它的人将最终获得巨大的财富。那些不理解它的人会付出巨大代价。复利的效果不仅可以应用在财富的积累，也能应用在知识的积累上。
    • 你的知识将会在复利的作用下持续地累积和增长，最终的收获和回报会远远超出你的想象，而实现终生学习的最佳途径，就是阅读大量优秀的书籍。
    • 我们每个人都可以通过读书和终生学习，为自己塑造一个优秀的人格，实现个人的价值提升和阶级突破。

  • 时间管理

    • “从不浪费时间的人，没有工夫抱怨时间不够。”——杰斐逊
    • 一个认知误区：多花时间=态度好=产出高。然而即便是在泰勒管理理论的时代，这都是被否定的结论。
    • GTD（Getting Things Done）是一种高效的管理时间的方式。个人感受就是要划分任务，重要的事情优先完成，用一定的时间专注处理一些事情，然后再休息，再专注，周而复始，
    • 这和番茄工作法比较类似。通常，最好的方式是在每一天早晨花上一定的时间来规划一天的安排。

  • 以人为本

    • 克莱斯勒CEO Lee Iacocca 的管理哲学的：“人、产品、利润。人是第一位的。”
    • 如果你有卓越的人才，并给予相应的尊重和鼓舞，让他们能够积极参与工作，那么你会做出卓越的产品。如果你有卓越的人才和卓越的产品，利润就会随之而来。

带领技术团队心得¶

• 技术人员心态成长四个阶段

  • 皮亚杰（瑞士）将儿童和青少年的认知发展划分为四个阶段：感知运动阶段、前运算阶段、具体运算阶段和形式运算阶段。
  • 感知阶段

  • 深入阶段

    • 就事论事，就架构论架构，就代码论代码。

  • 突破阶段

    • 遇到一定的发展瓶颈，渴望突破瓶颈。如果你不能很好地解答他们当前的问题，他们很有可能会流失。

  • 创新阶段

• 找到属于自己的圈子

  • 工作内

    • 尝试多参加各类技术论坛，了解新的技术点。
    • 除了论坛之外，你可以多上上国外的知名技术问答网站，对你绝对有帮助。
    • InfoQ和IBM开发者论坛开设专栏，给自己不断输出技术成果的目标和压力，进而不断提升自己的技术能力。

  • 工作外

    • 除了工作以外，你可以提前几年为自己未来的发展方向布局，比如你的目标是成为CTO，那你要明白，当前你的朋友圈可能没有这样职位的人，或者没有可以让你走上这个位置上的人，那么你需要找机会去结交这样的人，或者是那些大企业的领导，也许，将来哪一天目标就实现了呢？目标总是要有的。
    • 你可以选择加入一些高管俱乐部，或者知识分子组织，比如九三学社。

• 何时成为技术管理者

  • 技术积累是一辈子的事情，只有到了一定程度，即你可以花较少的时间学会一项新技术或者架构的时候，你才能去做技术管理的工作，因为技术管理工作会占用你很大一部分工作时间。
  • 那么当一个人的技术基础很好时，他就会很容易理解你所讲的技术，能够在最短时间内掌握，这就是一个人的学习能力，有点类似于慕容复[插图]的“以彼之道还施彼身”，只有功力深厚的人才能做到。

个人职业发展¶

• 对于职业的选择

  • 什么时候可以转为技术管理？如果在军队里面，一个士兵说我杀敌本领不行，是不是可以升为将军？同样的道理，最好是技术能力比较强之后再转管理，水到渠成，技术不行的人即使转了管理，也难使人信服。
  • 什么时候可以转为技术管理？如果在军队里面，一个士兵说我杀敌本领不行，是不是可以升为将军？同样的道理，最好是技术能力比较强之后再转管理，水到渠成，技术不行的人即使转了管理，也难使人信服。情商是什么？个人理解，情商就是如何站在别人的角度看问题

• 工程师的等级

  • 前苏联著名物理学家Lev Davidovich Landau提出过一个衡量物理学家水平的郎道等级。他把世界上的物理学家分为了五级，即第一等物理学家的贡献是第二等的十倍，第二等是第三等的十倍，依此类推。
  • 从成本上看，一流工程师的收入可能是二流工程师的两三倍，但是，前者的贡献可能大十倍，从经济的角度来讲，采用最优秀的人才是最合算的

• 不要计较当下职位

  • 企业里面成功，依仗两个方面：要么你聪明，会交际，懂政治，被人认可；要么你做出成绩，贡献巨大，被认可。
  • 技术人员还是选后面一条比较合适，持续地积累自己的技术，最终你的成长会由量变达到质变。

• 坚持做正确的技术管理

  • 最好的领导，思路敏捷而清晰，做事务实而高效，永远没有废话，永远雷厉风行。
  • 事实的真相是：评判一个管理者的好坏，从来不是看测验的民意，而是看输出的成绩。
  • 世上最讨厌的词是“烂好人”。善良发展到极致，就变成无原则的妥协。

• 抛弃通道思维，建立雷达视角

  • 对于工程师来说，考核方式分为专业通道和管理通道。
  • 技术与管理结合的方法论掌握不好，整个团队的绩效输出都会差，你别指望纯技术通道的人能够输出业务部门能够理解的产物。
  • 不再沿着一个狭窄的方向前进，而是以自身为圆心，等距离向外的探索，好像雷达扫描一样。当你发现一个机会落入你的雷达区时，意味着你的技能与之是匹配的，那你就可以努力抓住它。
  • 在这样的世界观里，我们不再追求人人都去做团队管理者，而是追求做一个靠天赋、靠能力吃饭的人。转变的过程是痛苦的，跳出原有模式是需要极大勇气的，但最后的收益很诱人，即自由，更强的安全感，还有乐趣。
  • 我们需要坚持学习，不然随着年龄的增加，你的优势会逐渐消失。抛弃通道思维，建立起自己学习新知识的雷达视角

CTO角色解释¶

• CTO是公司第一号技术大师，他对于技术非常敏感，需要具备对于技术发展的深远见解，保持公司在技术上的竞争力。
• 技术VP的职责是交付软件解决方案，确保业务健康，只有业务健康，工程师们的努力才有价值，团队才有可能继续发展。

• 技术VP职能

  • 1）人员管理
  • 2）项目管理和执行
  • 3）财务管理
  • 4）技术领导
  • 5）战略发展

• CTO规划技术愿景，工程VP更多负责业务愿景

团队建设、人员管理¶

管理基础¶

• 开发团队管理者

  • 团队的构成要素总结为目标、人、定位、权限、计划。
  • 开发团队管理者一般都是优秀程序员出身，积累了较强的技术和架构能力，对业务知识也较熟悉，且拥有较强的人际关系处理能力，智商、经验、情商的三者综合水平都较高。这个岗位也是本书的重点目标人群。

• 永不气馁

  • 我在职业生涯中投篮失败9000余次，输掉了300场比赛，有26场比赛，我被委以投出致胜球的重任，却没能命中。我不断地遭遇失败，而这恰恰是我取得成功的原因。——迈克尔·乔丹

• 承认错误

  • 认知失调

    • 现象：错误难以消化，这时候，我们对事物的认知会产生偏差，导致我们需要寻求证据来证明自己所坚持的信念。
    • 定义：当我们持有两种相互冲突的想法、信念、观点或态度时所感受到的压力。
    • 原因：《错不在我》的作者Carol Tavris认为：“认知失调是我们在自我认知（我是聪明、善良的，我坚信这是真的）受到事实挑战时所产生的感受。"

  • 如果哪一个领导因为你主动承认错误，而把责任全部推给你，那你也应该离开他了。

• 1

组建团队¶

• “一流人才招聘一流人才，二流人才招聘三流人才。”——史蒂夫·乔布斯

• 招聘策略

  • 明确我们当前是需要开发经验？（老手）

    • 一个可以领导整个团队开展各种实际工作的程序员？
    • 一个可以找出产品里隐蔽难寻的设计缺陷的程序员？
    • 一个具备大局意识、能预想到需求可以如何分解为模块和组件的设计师？
    • 一个能主动行动、能很好地配合管理层的工程师

  • 还是需要对技术有钻研热情的人？（新手）

    • 在短时间内可以编写数千行代码？
    • 能够快速开发出对客户非常重要的原型系统？
    • 能快速领会业务流程，围绕根本需求设计产品。

  • STAR面试法

    • 背景（SITUATION）
    • 任务（TASK）
    • 行动（ACTION）
    • 结果（RESULT）

  • 招聘文化

    • 你必须明白，你在招聘过程中的表现在一定程度上体现了你的团队价值观，所以请无限高度重视招聘。
    • 面试过程体现了一家公司的技术能力、思维和管理能力，绝不可以轻率应付，你代表着公司，而不仅仅是你个人，如果你不够资格，或者根本不想做好，那请你让开位子，请合格的人来坐。

• 性格分析

  • DISC个性特征理论

    • 支配型(Dominance):在敌对的环境中保持主动的态度和反应；
    • 影响力(Influence)：在友好的环境中保持主动的态度和反应；
    • 稳定性(Steadiness):在友好的环境中采取保守的态度和反应；
    • 遵从性(Compliance)：在敌对的环境中采取保守的态度和反应；

  • 九型人格

    • 按照人们的思维、情绪和行为，将人分为九种：完美主义者、给予者、实干者、悲情浪漫者、观察者、怀疑者、享乐主义者、保护者、调停者。

• 人员分类

  • “独狼”和“农民”

    • “独狼”更喜欢一个人完成工作，他们常常跳过规划阶段，最终得到的是一次性解决方案。只能当“独狼”的程序员不会在任何一家企业待太久。
    • 从团队角度来看，我们更加希望软件开发像种地一样。农民会有条不紊地先去了解地形、研究土地的化学成分，然后种植、浇水、除草，最终收获粮食。可靠、可扩展、可维护的软件也都是这样有条不紊地开发出来的

  • 内向的人

    • 《安静：内向性格的竞争力》苏珊·凯恩列举了许多性格内向的成功人士，他们安静、稳重、深思熟虑，默默地带给这个世界许多改变。如果他们不幸被强制改变成外向的人，这个世界会少许多天才，多出来许多“病人”。
    • 内向的人表现为非常沉默、内敛，几乎让人感觉不到他们的存在。他们可以把工作完成得很出色，但是对团队执行力或者在会议上几乎不会有什么贡献。他们在一对一的时候能正常进行交流，一旦退回到人群里就跟消失了一样。

  • 离奇之人与离奇之事

    • 对于技术团队来说，我们需要的是刻苦的工程师，需要的是能够解决问题的工程师，而不是搞办公室政治的高手，或者腹黑的工程师。不管是一心想当“老大”，不择手段压制同事的人，早点让他们走，无论他们的水平有多高，

管理团队¶

• 如果你想要建造一艘大船，不要立马号召大家开始收集木材，也不要立马分配任务和工作，而是应该先教会他们去憧憬广阔无垠的大海。——Antoine de Saint-Exupéry
• 管理的最终目标是：“不要让你的下属陷入困境，不要让你的同事陷入困境，尤其是在任何情况下，都不要让你的上级陷入困境”。

• 向下管理

  • 得到技术尊重

    • 理解计算机程序设计的艺术
    • 拥有良好的过往履历
    • 做出过技术贡献
    • 追逐技术潮流
    • 成为一个技术或者职业组织的活跃成员
    • 展现出强大的个人价值

  • 强化现有的团队

    • 杰出的程序员能够以一种优雅、简洁、易懂的设计来架构大型的复杂系统，这些优秀的系统往往能让所有其他程序员的工作都更加轻松。因此，单个人就能带来巨大的杠杆效应。
    • 需要让系统程序员/架构师参与到开发工作中，不要让他们只设计、不编码，应该把他们引导成为杰出程序员。

  • 进度管理

    • 我有一块小白板，放在自己的面前。
    • 每天上午半天时间我会和每一个项目（产品开发、预研、调研等）的团队成员过一遍当前进展。大家坐下来，好好谈谈已经实现的设计或代码，对疑惑、问题进行讨论。
    • 因为这种方式可以确保自己不仅仅依赖于状态报告、项目时间表，这种方式也可以让你能够接触到说真话的员工，他们会告诉你哪些地方做得不够好，并且会主动请求团队管理者帮助，而不需要团队管理者来催促他们。
    • 从长远看，一些不紧急但是很重要的事情，如果迫于压力被放下，到后面往往需要花费好几倍的代价才能弥补回来，技术管理者需要时刻保持警惕，慎重地做出决策，做正确的事情，要能够为公司的长远利益负责。

  • 效率管理

    • 团队的效率并不是简单的加法关系，而是乘法关系。
    • 影响组织效率的关键因素是人，如果每一个人效率提高10%，组织的效率就会提升很多倍。
    • 如果每件事情都有唯一的责任主体，出了问题能够快速找到问题根源，组织就会更加高效。

    • 那么如何提高效率？

      • （1）提高效率，最重要的是先确保做正确的事，再把正确的事做对。因此，先明确目标和结果，以及结果对最终客户的价值大小，这是提升效率最重要的事。在这个基础上，我们会发现很多事情根本就不应该做，而不做就是最大的效率提升。减少一件事情，或者在事情中减少一个步骤，就是最大的效率提升。
      • （2）所谓效率其实就是性能。性能往往受限于系统的资源瓶颈。我们应该看清楚整个系统中的资源瓶颈是什么，是机器厂房、人力、资金预算，还是周转率，围绕它来组建流程，提升效率。
      • （3）高效与工具化、自动化程度强相关，因为自动化具有规范、一致、高速、闭环反馈等特性，而且不会因为疲劳而下降。因此高效率的组织，一定会大力发展这些能力。
      • （4）高效的组织，每个人都会主动优化流程，并且持续改进。

  • 引导工作

    • 对于一个团队管理者来说，要想最大化地利用自己的时间和技能，就要引导程序员自己做出正确的决定，而不应该自己就把决定做了。
    • 这样做可以帮助下属员工培养技术、积累经验、建立自信，还能获得具体执行决定的员工的认同。
    • 如果你发现自己经常需要讨论非常具体的命令以及如何执行，说明你没能很好地利用你的管理技能，或者没能赋予下属员工足够的权利。
    • 记住，优秀的主管要有足够的自制力，不在下属工作时瞎指挥。

  • 保护成员

    • 很多团队管理者的大部分工作内容是处理这些问题，如果让你的下属去处理这些问题，他们最终可能会被淹没在这些繁杂事情的洪流之中，进而极大地降低他们的程序设计效率。
    • 通过保护你的员工，可以让他们避免把宝贵的时间浪费在临时事务上，而且也能让他们工作得更愉快，因为某些问题可能会演变成完整的流言，让人担心项目变更，担心收购、重组或裁员，这些流言会大大降低士气。

  • 任务责任制

    • 每项任务都必须有且仅有一位负责人，如果有两个负责人，那就没有人负责了。
    • 定期检查以下三个问题：“是否清楚整体的目标？是否清楚你的任务对实现整体目标有怎样的贡献？对于你所负责的部分，有哪些东西妨碍你达成目标？”

  • 主动沟通

    • 千万不要轻视沟通能力，这一能力对你的晋升起决定性作用。
    • 技术管理者要想搞清楚项目执行的进度、团队成员存在哪些诉求和不满，想要打造一个有战斗力的团队，沟通无疑是最重要的。

  • 会议记录

    • 记住，没有记录的会议，相当于没有开过。
    • 每一个重要会议，都需要有完整的会议记录，包括参加人员、讨论议题（逐一写下来）、讨论过程大体描述、每一个议题的最终结论（包含流程图）、遗留问题、下一次会议时间及议题等。

  • 下放权力

    • 程序员在工作中经常犯的错误是只见树木，不见森林。
    • 管理者需要为成果而工作，以结果为导向。一位卓越的管理者不应该在工作一开始就身先士卒地从事具体的工作，更不应该把精力放在研究技术实现的细节上，而是首先问问自己：“客户期望我做出什么样的成果？”然后再对整个项目进行规划。

  • 激励员工

    • 亚伯拉罕·马斯洛在20世纪中叶提出了需求层次模型：生理、安全、社交、尊重、自我需求

• 向上管理

  • 实际上成功地管理好你的老板可能比管理好你的团队还重要。
  • 成功并不只在于你做了什么，更需考虑别人如何看待你所做的成果。现实中，外在认知往往比实际行动更重要。

  • 了解老板

    • 你老板的级别越高，你的报告就越要精简，越要注重大局，细节更少、局面更大、文字更少、项目符号更多。

  • 准备讨论内容

    • 你还要避免只把问题带给领导的情况，最好是拿着几套潜在的解决方案和问题一起交给他。
    • 让领导觉得你已经做好了自己的功课，过来找他是为了寻求他的建议和忠告，而不是直接把问题抛给他。

  • 主动承担

    • 你可以非常好地管理团队并完成项目，但如果没有你老板为你护航，你的职业前途必然坎坷。也许看起来不那么明显，但你的薪水、奖金、期权、津贴和机会的多寡，都是由一系列的管理层闭门会议或者你老板自己决定的。
    • 所以一定要主动，做好向上管理，可能会得到更多的职业回报。你损失的只是时间和精力，但能得到的却太多了。
    • 向上管理本身也有直接的回报：当你为更多的交流做出努力时，会潜在加固和上层领导的关系。

• 对外管理

  • 在跨部门活动中，尽可能成为一个领导者，而不是追随者。你的主动参与将提高你在整个组织中的形象，帮助你在很多看不见的方面取得成功。

• 自我管理

  • 个人管理系统就是一个由世界观和方法论组成的整体，构建这个整体的目的是为了实现自我提升，这个整体里包含个人价值观、个人思考模式、做事的流程体系、做判断和决策的方法和一系列的健康生活习惯等。
  • 作为一名软件团队管理者，我们需要避免过度管理，做好沟通管理、面对面管理和形象管理。

  • 1．过度管理

    • 切记，造成延迟和混乱的最主要的原因之一就是允许一个上级直接管理过多的下属。
    • 我们自己也要注意这一点，不要过度深入管理每一件事情，或者直接管理每一个团队成员。
    • 一般来说，你能够覆盖完整的团队成员，最好不要超过10人，多于10人以上，可以采用分小组形式间接管理。

  • 2．沟通管理

  • 3．面对面交流

    • 智慧是您一生从聆听而非说话中所得的奖赏。——亚里士多德
    • 关注对方，放下你的手机，停止处理电子邮件或写代码，坐下来，看着说话的人。

  • 4．形象管理

    • “人靠衣装”其实需要好好思考，如果你看起来邋里邋遢，那么你需要采取行动了，要去克服你的老板和其他高级管理层与你交流时因着装而产生的负面看法。

影响团队因素¶

• 不懂技术的技术领导

  • 不懂技术的人如果做了研发团队的领导，很容易出现严重的问题。
  • 对于整个研发过程的管理，不懂技术的人很容易完全从产品角度考虑，忽略研发团队面临的困难和风险，忽略技术人员对于技术的憧憬，造成团队超负荷工作、技术团队缺少技术愿景等情况发生。
  • 举个例子，业务方收到了客户的压力，本来可以通过向客户解释来减少研发的压力和风险，但是选择直接施压研发）。这时候，你的这位不懂技术的团队老大可能会说，没关系，我们一开始并不需要一个完美的系统，你先上了再说，我们后面有时间再重构和完善（当然有的技术人员也会用“架构和设计是逐步演化出来的”这句话来证明“故障驱动”开发是值得的），这样的想法本质上是错误的。
  • 一些人喜欢将缺少需求分析、技术设计环节解释为“这是敏捷开发，和你们的瀑布式不一样”，这是对敏捷开发的误解，敏捷开发是很好的一套开发流程。敏捷开发的实质是为了解决需求快速变化的情况，需要快速响应需求提出方，快速搭建产品原型用于验证实际效果，而不是说有了敏捷就可以忘记软件工程理论，不管三七二十一，先随便写一堆代码再说，这是不合理的。任何软件工程模型，都不会允许在需求完全不明确、描述不清楚的情况下，开始进行技术方案设计，也不会鼓励在方案设计缺失的情况下开始编码，因为这个时候没有人知道究竟如何编码。

  • 团队领导可以不是对口的专业出身，但是他必须对技术有热情，必须有开发经历，需要对技术有敬畏之心。总结为两点：

    • ❑ 基础知识和理论知识非常重要，多多使用已有的且成熟的方案是关键。
    • ❑ 对技术要有一颗严谨和敬畏的心，想清楚了再干，坚持高标准，很多事情都急不来。

• 薪资管理

  • 千万不要以为“公司内部不能谈论工资”这一条很有用，这条规定对于有大量同学在一起的大公司来说，几乎不起作用。
  • 我们要做的是，在公司开始慢慢有稳定的收入后，逐步调整薪资并向优秀的员工倾斜，让他们的付出得到合理的回报，并在薪资、奖金和期权分配上为他们争取更多的回报，这是对优秀人才最好的奖励。

• 上升通道

  • 大家觉得，光做开发没有职业前途，永远都处在金字塔的底层。而在硅谷的公司，说话比较有分量、收入相对较高的人，他们有很多是在各层级中的技术佼佼者，他们备受尊重，干得也开心，不少人根本不愿意转做管理者。
  • 我们作为技术团队管理者，应该多与每一位下属沟通，抽出时间来了解他们对于未来的期望，帮助他们逐渐设计符合他们想法的上升通道。

• 一言堂

  • 技术团队如果出现喜欢搞一言堂的领导，逐渐会形成他的个人特权，刚开始不会让人感觉恶心，但是逐渐地他会越来越肆无忌惮，直到团队中有个性的、有能力的人全部离开，只剩下一些实在走不掉的、很能忍的，那么这个团队的整体战斗力就变得很弱。

• 各种无端限制

  • 技术能力上的锁。
  • 负责模块上的锁。
  • 时间锁、进度锁。
  • 沟通锁、利益锁。

• 缺乏愿景

  • 最有效的领导方法，包括两个能力：一是愿景（Vision），二是沟通能力。
  • 什么是愿景？愿景就是作为一名软件工程师，未来你的发展前途、你做的产品对未来世界有什么影响
  • 团队里的个人可以有这样的愿景：三年之内成为Web前端方面的技术专家。团队可以有这样的愿景：打造国内技术领先的前端团队。

其他相关知识¶

• 程序员思维

  • 1．抽象思维（Abstract Thought）

    • 抽象就是去掉纷繁芜杂的与计算无关的部分，用规约（Reduction）的方法还原到问题的本质。
    • 问题的实体对象 => 数据结构

  • 2．逻辑推理 (Reasoning)

    • Deductive（演绎推理）
    • Inductive（归纳推理）
    • Analogical（类比推理）

  • 3．分析 (Analysis)

    • 猜测加验证（guess-and-verify）的过程

  • 4．分解 (Decomposing)

    • 分而治之（Divide-and-Conquer）

  • 5．递归 (Recursion)

• 杰出的程序员

  • 杰出的程序员是大师级的人物，做事有条不紊、遵守纪律，能够凭借直觉把代码和程序组织好，能够约束自己总是在编写代码之前进行设计，能够在最少的时间内编写出清晰、简洁、实用、高质量的代码并获得预期的结果。
  • 换言之，杰出的程序员是大师级的工匠。

• 扁平化管理

  • 雷军曾经在一次采访中谈到小米的情况：“小米团队是小米成功的核心原因。和一群聪明人一起共事，为了挖到聪明人可以不惜一切代价。如果一个同事不够优秀，很可能不但不能有效帮助整个团队，反而有可能影响到整个团队的工作效率。真正到小米来的人，都是真正干活的人，他想做成一件事情，所以非常有热情。来到小米工作的人聪明、技术一流、有战斗力，这样的员工做出来的产品注定是一流的。”
  • 扁平化的好处，它更容易让能干的人冒出来。理论上来说，通过减少管理层次、压缩职能部门和机构、裁减人员，使企业的决策层和操作层之间的中间管理层级尽可能减少，以便使企业快速地将决策权延至企业生产、营销的最前线，从而为提高企业效率建立富有弹性的新型管理模式。
  • 知识型员工
  • 为什么过去没有这么强烈的诉求？因为中国的IT起步较晚，人才的出现、累计需要很多年，现在已经出现了大规模的知识型员工。知识型员工的一个鲜明特点就是，对专业的忠诚大于对所服务的企业的忠诚，选择企业的目的是致力于寻求能够实现自身专业成就最大化的成长平台。200多年的工业社会发展使专业分工模式越来越成熟，也进一步催生了庞大的知识型员工群体。知识型员工群体的兴起和“去中心化”的信息传播方式，这两者结合，对企业管理提出新的要求，同时，这部分群体对企业的绩效发挥着越来越大的影响，而知识型员工又是社群自组织和传统组织混合协作的主要群体。

• 金州勇士奇迹

  • 硅谷地区有两种人最不缺，即风险投资人和工程师，勇士队的奇迹从很大程度上讲是靠他们创造的。前者善于看到其他人还没有发现的投资潜力，然后把它经营成值钱的实业；后者善于利用技术创造奇迹。

• KPI之祸

  • 开始带技术团队后，在绩效考核这方面同样遇到了类似的疑惑，例如:

    • （1）程序员的工作怎么量化？Bug数？代码行？版本数？
    • （2）即使程序员的工作可以量化，每次绩效都是这几个指标，定绩效目标还有意义么？
    • （3）团队Leader如何制定团队的KPI？
    • （4）前瞻性的工作谁愿意做，有风险的工作谁愿意做？

  • OKR全称是Objectives and Key Results，而KPI的全称是Key Performance Indicators, OKR和KPI具体的差别表现在：OKR的关键词是Objectives, KPI的关键词是Indicators！

  • 不要小看了这两个词的力量，正是这两个词决定了OKR和KPI的本质差异：OKR关注的是目标，KPI关注的是指标。当我们关注“目标”的时候，我们会思考接下来我要做的事情是什么；而我们关注“指标”的时候，我们会思考自己的工作如何评价。
  • 如果方向对了，就不怕路途遥远！如果方向不对，指标再漂亮都没有意义，甚至指标越漂亮就错得越离谱。
  • 使用OKR的时候，我们的第一反应是：“我们的目标是什么？”而使用KPI的时候，我们的第一反应是：“我们的职责是什么？”如果我们将思维固化在当前的职责，那就不会去审视整个环境当前的状态以及后续可能发生的变化，也就不会及时地根据实际情况进行调整。
  • 彼得·德鲁克在《管理的实践》中说：“并不是有了工作才有目标，而是相反，有了目标才能确定每个人的工作。所以企业的使命和任务，必须转化为目标。”
  • OKR和KPI的区别，形象地提炼一下：OKR让我们做正确的事情，KPI让我们正确地做事情！

产品开发过程管理¶

前言¶

• 理论好比是教人如何在地图上规划一条路，而实践则好比是要在现实中一步一个脚印地走完这条路。
• 工程延期、Bug丛生、沟通冗长、人心浮动，这些现象可能是因为开发经理个人管理能力或经验不足，也可能是整个细分行业不够成熟，没有形成方法论，造成各种混乱。
• 软件工程是一门综合学科：数学、物理、电子电路、建筑学。
• 软件工程师还要对该业务所在行业的专业知识进行一定的积累，并要跨越听得懂和能执行两个阶段，然后才能够用计算机语言表达出来。

开发经理及研发体系¶

• 什么是软件

  • 软件发展历史

    • 从冯·诺依曼结构开始，程序逻辑开始脱离硬件，采用二进制编码。软硬件两者结合，一个可编程的大脑就出现了，这也是为什么我们把计算机叫作电脑的原因。
    • 摩尔定律：当价格不变时，集成电路上可容纳的元器件数目，约每隔18～24个月增加一倍，性能提升一倍。
    • 在计算机出现前，人们用机器来代替人进行生产，也就是所谓的机械化生产。
    • 吉尔伽美什计划
    • 人们对于时间的恐惧，导致人们不断地去为延长自身生命而努力，提升自己的生产力是其中的一种途径。软件可以让人们节省大量的工作时间，从而有更充分的时间去关注并推进自身的核心生命周期。
    • 软件模拟出了一个虚拟的世界，人们在自己创造的虚拟世界中互相联系，形成了一个虚拟的社会，从而给人类带来了极大的便利。
    • 换句话说，软件是人类实际需求的虚拟化实现，通过软件让机器完成本应由人类完成的工作，这样人类可以做更多有创造性的事情，可以更多地休息、享乐。

  • 软件的作用

    • 软件的主要目的就是把人类生活的非核心生命周期软件化、虚拟化，以提供更低的成本和更高效率的新生活，让核心生命周期的运行能够更加容易，让非核心生命周期的处理更少地占用人类的时间，变相地延长人类生命。

  • 软件生命周期

    • 软件的生命周期可以拆分为软件开发生命周期和软件运行生命周期。
    • 人们对世界的访问生命周期发生了切分，形成了软件的访问生命周期，从而打破了物理时空的限制。

• 什么是开发经理

  • 开发经理更像是个专业岗位，需要依靠领导力来解决和激励团队，靠沟通和协调推进项目，甚至需要一定的政治和文化意识才能获得支持。

  • 开发经理的职责

    • 一个合格的开发经理必须同时做到“按预期交付成果”“让客户满意”“让员工满意”。
    • 1）对产品开发全过程进行组织和管理
    • 2）管理产品开发团队
    • 3）管理对外关系

  • 开发经理 VS 项目经理

    • 开发经理是项目的推动者、技术的输出者，也是关系的协调者。总的来说，开发经理往往是决定一个项目成败的关键人物，要求其职业素养高、技术能力强、综合能力强、职责范围广。
    • 也正是因为要求太高，所以很多公司将开发经理、项目经理区分开，即项目经理可以不用管技术，专心做协调、进度把控工作。

• 开发经理素质

  • 1）领导力

    • 领导力是指通过领导他人来完成工作的能力。开发经理虽然是项目领导核心，但需要依赖团队完成任务。
    • 开发经理和大家是平等的，很多时候还要走在别人的前面。
    • 开发经理的口号应该是“跟我冲”，而不是“给我上”。

  • 2）责任心

    • 项目执行过程中会遇到很多困难，经常会超出预期。这个时候，能够帮助开发经理挺下去的可能只有“责任心”了。
    • 具备强烈责任心的人，出于对承诺的负责
    • 具有强烈责任心的人，也会非常注重细节

  • 3）积极主动

    • 积极主动的人最大的特点是不会经常抱怨，因为抱怨本身是没有用的。开发经理是项目组的“主心骨”，如果这个人很容易慌乱，那这个项目也会混乱。

  • 4）抗压能力

    • 项目中会出现各种突发事件，有时候需要忍受极大的压力。有抗压能力的人在困难来临的时候仍能镇定自若，仍能冷静思考，即使在无能为力的时候，也能保持“风度”和“幽默感”，从而稳定军心、解决问题。

• 软件开发模式

  • 瀑布式开发模型

    • 阶段：需求分析、设计、编码、测试、维护。
    • 瀑布式开发模式本身是没有问题的。比如在建筑行业，其实就是瀑布式开发模式，在需求做完后进行设计，在设计完成之后，再开工建设。区别在于，建筑行业是对空间切分，而空间是现成的，只需要顺从地球的自然地理环境以及地球的重力等因素，大部分都是可预测、稳定的。
    • 建筑设计师本身也是建筑的使用者，对用户的需求感同身受，容易理解。但软件行业存在不同，软件是用来代替业务人员的，首先需要理解业务人员的工作，才能做出设计。
    • 沟通的偏差会导致软件的起点会有问题
    • 如果没有一位强有力的技术管理者牵头，很容易出现设计阶段普通程序员闲置的情况，因此软件行业采用瀑布式模型时，会存在大量的浪费

  • 敏捷开发模型

    • 所谓的“敏捷”，核心就在于快速迭代并迅速反馈。
    • 要想快速发现和纠正错误，就要做好迭代，而做好迭代就必须确保迭代的生命周期足够短。
    • 软件开发方法，包括极限编程、Scrum、特征驱动开发、测试驱动开发等。

• 研发管理体系介绍

  • CMMI（能力成熟度模型集成）

    • 一种过程改进的方法，可用于指导一个项目、一个单位，或一个企业的过程改进。

  • RDMS（Research and Development Management System，研发管理体系）

    • 适用于公司产品开发全生命周期的管理
    • 包括概念、定义、设计、实现、验证、移交、维护等多个步骤

产品开发过程管理¶

• 完成阶段工作的标志称为里程碑。里程碑包括4个要素：时间点、标志性事件、交付物、关闭条件。
• 项目启动会

• 用户需求

  • 软件开始开发前需要确定投入与产出的比值，也就是ROI（Return On Investment，投资回报率
  • 用户需求由用户提出，对技术一般不描述，只描述产品目标。产品需求是根据用户需求转化而来的技术实现需求。
  • 开任何会议，一定不要上来就讲解方案，应该先讲解场景。

• 产品需求

  • 产品需求矩阵

    • 一般按照子系统、功能集、执行单元的结构列出所有的功能需求，每列则对应每项功能的工作步骤以及每个步骤的工作量。

  • 产品需求规格说明书

    • 1）简介
    • 2）产品描述
    • 3）技术约束和局限
    • 4）需求详细描述
    • 5）接口需求
    • 6）质量需求
    • 7）用户文档需求

  • 需求评审

    • WHY：为什么做这个需求？
    • WHAT：需求的价值是什么？
    • WHEN：需求期望什么时候上线？截止日期？
    • HOW：需求是否完整？正常场景是什么？异常场景是什么？技术上分别怎么应对？

• 总体设计

  • 设计阶段包括了系统架构的输出，一个好的系统架构设计可以帮助人们梳理业务逻辑并抓住核心需求，设计稳定可扩展的业务系统，评估业务开发周期和开发成本，有效地规避风险。例如盖房子的时候得有建筑图纸，有了图纸，才能核算施工周期。

  • 总体设计说明书格式

    • 1）产品描述
    • 2）涉及约束

    • 3）总体设计

      • 软件架构及模块划分
      • 模块描述

    • 4）接口设计

    • 5）备选方案及方案对比
    • 6）集成要点

• 概要设计

  • 设计软件的结构，包括组成模块，模块的层次结构，模块的调用关系，每个模块的功能等。
  • 结构化设计方法：首先按照问题域，将软件逐级细化，分解为不必再分解的模块，每个模块完成一定的功能，为一个或多个父模块服务（即接受调用），也接受一个或多个子模块的服务（即调用子模块）。
  • 概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等

• 详细设计

  • 详细设计阶段就是依据概要设计阶段的分解，设计每个模块内的算法、流程，为每个模块完成的功能进行具体的描述，把功能描述转变为精确的、结构化的过程描述。
  • 详细设计阶段常用的描述方式有：流程图、N-S图、PAD图、伪代码等。

• 代码审核

  • 代码审核重要性

    • 代码审核及其重要，一般来说每周都要做一次代码审核。
    • 真实地看到其他人的工作进展如何，并且能更早发现他们是否误入歧途

  • 代码审核内容

    • 1）前置条件：否可以正常运行、有没有严重警告灯。
    • 2）代码规范性：注释、排版、命名规则等
    • 3）代码逻辑：函数、内存管理、类/结构体、设计模式等

  • 代码审核关注点

    • 1）设计

      • 如何让新代码与全局的架构保持一致？
      • 代码是否遵循SOLID原则，是否遵循团队使用的设计规范，如领域驱动开发等？
      • 新代码使用了什么设计模式？这样使用是否合适？
      • 基础代码是否使用了一些标准或设计样式，新的代码是否遵循当前的规范？代码是否正确迁移，或参照了因不规范而淘汰的旧代码？
      • 代码的位置是否正确？比如涉及订单的新代码是否在订单服务相关的位置？
      • 新代码是否重用了现存的代码？新代码是否可以被现有代码重用？新代码是否有重复代码？如果是的话，是否应该重构成一个可被重用的模式，还是当前还可以接受？
      • 新代码是否被过度设计了？是否引入现在还不需要的重用设计？团队如何平衡可重用和YAGNI（You Ain't Gonna Need It）这两种观点

    • 2）可读性和可维护性

      • 字段、变量、参数、方法、类的命名是否真实反映它们所代表的事物
      • 是否可以通过读代码理解它做了什么？
      • 是否理解测试用例测了什么？
      • 错误信息是否可被理解？
      • 不清晰的代码是否被文档、注释或容易理解的测试用例所覆盖？

    • 3）功能

      • 代码是否真的达到了预期的目标？
      • 是否有自动化测试来确保代码的正确性，测试的代码是否真的可以验证代码达到了协定的需求？

    • 4）其他

      • 是否需要满足相关监管需求？
      • 是否需要创建公共文档或修改现存的帮助文档？
      • 否有会在生产环境中导致应用停止运行的明显错误？
      • 对性能的需求是什么，是否考虑了安全问题？

• 单元测试

  • 什么是单元测试？

    • 所谓“单元”指的是代码调用的最小单位，实际上指的是一个功能块（Function）或者方法（Method）。所以单元测试指的就是对这些代码调用单元的测试。
    • 单元测试是一种白盒测试，就是必须要对单元的代码细节很清楚才能做的测试。由软件工程师来做。
    • 除了单元测试，还有集成测试（功能测试、回归测试等）。集成测试基本都是黑盒测试，主要是由测试人员根据软件的功能手册来进行测试。

  • 如何做单元测试

    • 有一个方法可以判断是否为可测试的代码，就是看这个方法能否用一个main函数直接运行，如果可以的话就是可单元测试的代码。
    • 如果代码里有逻辑，但是不可单元测试的话，就需要改造代码。改造的方法，就是要确保逻辑代码和外部环境相关代码隔离，这个逻辑代码就是可单元测试的。而隔离的办法就是把代码的执行顺序，也就是单元的执行生命周期，做架构的拆分。

  • 测试用例编写

    • 单元测试用例主体包括每个模块的详细测试用例、修改记录这两项。

  • 单元测试优点

    • 刚开始编写单元测试代码确实存在一定的代码量，会觉得有点占用时间。但是随着代码的深入，测试工作量会越来越小，因为单元测试做到位了，代码可以直接运行。
    • 反观手工测试，刚开始确实很快（需要测试的内容少），随着代码增多，手工测试工作量加大，反而花得时间更多，因为以前测试过的内容还需要重新再测，无法把自己的重复工作自动化。
    • 一旦养成单元测试的习惯你就离不开单元测试了，因为一旦上瘾，会觉得没写单元测试代码就很不安。
    • 只要业务没有太大的变化，单元测试就不需要维护，即一次投入会持续受益。

• 集成测试

  • 什么是集成测试

    • 集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求组装成为子系统或系统，进行集成测试。
    • 目的是检查软件单位之间的接口是否正确。

  • 集成测试重点

    • 集成测试重点是模块之间的连接。

  • 集成测试优点

    • 单元测试具有不彻底性，不能保证模块间接口信息内容的正确性，以及各模块间相互调用关系是否符合设计，只能依靠集成测试来保障。
    • 同系统测试相比，由于集成测试用例是从程序结构出发，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也较高。
    • 从纯理论的角度来讲，集成测试能够模拟所有实际情况。

• 系统测试

  • 测试方案和用例编写

    • 测试方案和用例是对业务逻辑的一次梳理，从测试角度完整理解一次需求，看看是否有测试场景遗漏，验证业务场景的完整性。

  • 功能性测试

    • 功能性测试一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合《产品需求规格说明书》

  • 性能测试

    • 性能测试是一个十分复杂的系统工程，对测试人员的能力水平提出了更高的要求，需要性能测试人员具备非常全面的知识与技能，能够定位应用的性能瓶颈，并提出适当的优化方案。

  • 稳定性测试

    • 稳定性测试（亦可称可靠性测试）通过给系统加载一定的业务压力，让系统持续运行一段时间（一般为7×24小时），检测系统是否能够稳定运行

• 产品发布

  • 产品发布前需要通过产品发布说明会的形式，对整个产品开发过程从立项开始回溯过程，总结整个过程中的经验教训。
  • 产品经理、主要开发人员、测试人员、上级领导等
  • 这一环节不可缺少，即便在互联网公司

• 开发过程复盘

  • 复盘会不要太严肃，它不是“批斗会”，而是为了总结经验，不断优化

产品开发过程杂谈¶

• 开发进度管理

  • “向进度落后的项目中增加人手，只会使进度更加落后”。—— 摘自《人月神话[插图]》
  • 伊格尔森定律（Eagleson's Law）:“自己写的代码如果有半年时间没有看过，就跟别人写的代码没什么区别了。”

  • 每天“晨会”

    • 晨会规定在15分钟以内，每个小组的成员站在白板前面完成；以检查和确认为目的，不展开讨论。

    • 第一步，检查状态。

      • 成员逐个说明昨天任务的完成情况，今天计划的工作任务，以及遇到的问题。

    • 第二步，调整计划。

      • 确定当天每个人的工作任务

    • 第三步，解决问题。

      • 不对问题展开讨论，只记录到白板的问题栏

  • 每周五周例会

    • 周例会检查和调整项目计划，关注的问题是：任务完成了吗？没完成的原因是什么？怎么调整？
    • 计划进行调整和更新是常态，因为“计划本身没有用，不断地进行计划才有用”。

• 评审的重要性

  • 对设计进行评审是为了尽早发现软件的欠缺，尽可能把这些缺陷在进入下一阶段工作之前予以纠正，从而避免后期付出更多的代价。
  • 角色4种：责任人、主审人、评审专家、记录员

• 软件版本管理

• 优先级安排

  • 原则顺序：重要/紧急工作>重要/不紧急>不重要/紧急>不重要/不紧急。

• 项目管理重要性

• 产品质量的重要性

  • 质量是一种管理，是一种控制，是一种预防。只有成熟的组织，成熟的团队，才能做出高水平的产品来。
  • 质量就是你的最高水平，以及你对用户理解的最高水平。

• 测试过程的区别

• 测试驱动开发

  • 它要求在编写某个功能的代码之前先编写测试代码，然后只编写测试能通过的功能代码，从而推动整个开发的进行。

  • TDD模型

    • V测试模型：
    • 需求分析 -> 概要设计 -> 详细设计 -> 编码
    • 验收测试 <- 系统测试 <- 集成测试 <- 单元测试

  • TDD优势

    • 1）因为关注用户反馈，可以及时响应需求变更，同时因为是从使用者角度出发的简单设计，也可以更快地适应变化。
    • 2）出于易测试和测试独立性的要求，这将促使我们实现松耦合的设计，并更多地依赖于接口而非具体的类，最终提高系统的可扩展性和抗变性。
    • 3）将测试工作提到编码之前，并频繁地运行所有测试，这样可以尽量地避免和尽早发现错误，极大地降低后续测试及修复的成本，也提高了代码的质量。
    • 4）TDD提供了持续的回归测试，使我们拥有重构的勇气，因为若代码的改动导致系统其他部分产生任何异常，测试都会立刻通知我们。
    • 5）TDD所产生的单元测试代码就是最完美的开发者文档，它们展示了所有的API该如何使用以及是如何运作的，而且它们与工作代码保持同步，永远是最新的。
    • 6）TDD可以减轻压力、降低忧虑，提高我们对代码的信心，使我们拥有重构的勇气，这些都是快乐工作的重要前提。
    • 7）提高了开发效率。

  • TDD的重要性

    • 1）反映真实需求

      • 后补的测试：开发人员很容易在后补的测试中只试图测试已有的实现，而不是需求本身，很容易遗漏掉一些边界检查之类，在测试时，已有的实现细节会在脑子里面先入为主，即使实现存在问题或漏洞，也很难在后补的测试中测出来。
      • 先写测试：每先写一个测试都是在试图用自己对问题和需求的理解来定义实现代码的框架；先写测试可以让开发者把重点放在理解需求和实现需求上，而不是一开始就陷入实现的细节中。

    • 2）设计在其中

      • 先写测试会先定义新的类，以及定义类与类之间的关系，就是定义类与类之间如何交互，每个类如何暴露自己的接口，类和类之间的引用关系。
      • 开发者会认真考虑如何分解类与类之间的耦合关系，这样产生的实现代码利用了IoC和DIP的模式，会更容易实现面向接口编程。

    • 3）增强信心

      • 很多经验表明，在开发者按照需求添加一些新的代码进入系统，或者试图修复已有缺陷时，很容易导致既有功能出错，也就是新引入的代码打破了既有代码的逻辑，从而导致回归问题的出现。
      • 作为TDD的副产品之一——可以快速频繁自动运行的测试代码，可以在开发者新引入代码之际，给予开发者足够的信心，每次添加一点新代码，一个方法，一个类，都需频繁运行已有相关的测试代码，来确保新引入代码不会打破已有的功能。

    • 4）粒度和进度

      • 先写测试，可以让开发者在同一时间只关注功能需求的一小部分，把功能需求细分到一定小的粒度
      • 在保证小粒度实现的同时，保证进度即使被打断时，已经做完的内容是完整可以运行的

  • 总结 TDD 好处

    • 减少开发周期中的反馈；
    • 提高代码质量；
    • 保证设计质量；
    • 集中精力开发一个功能。

  • TDD能改善和验证设计

    • 以客户端的视角编写测试代码；
    • 为客户端提供示例代码；
    • 更注重接口的设计；
    • 为了便于测试，需要实现松耦合；
    • 更少的调试时间。

• 自动化部署

  • 敏捷开发 和 DevOps

    • 自动化部署的目标就是要取消手工操作，将全部步骤流程化、标准化、规范化，从而提高质量和效率。

  • 自动化运维工具 Ansible

• 编写高质量代码的难度

  • 任何程序员都能写出机器可以阅读的代码，但只有好的程序员才能写出人可以阅读的代码。

  • 命名上的困难

    • 除了因为我们英语词汇量太小以外，另外一个原因是我们对于业务领域的不了解。在接到需求后，我们往往就急着开始所谓的设计和开发。
    • 如果我们把程序仅仅看成一些数据和算法组合，那么我们的命名必然也只是局限于这些数据结构、算法的概念上

  • “封装”

    • 我们把类似的、重复的代码封装成子函数；用继承的方法来构建相似的数据对象。
    • 代码重用的首要条件是代码可理解，而封装正是对复杂的实现过程进行屏蔽，让人可以快速理解。

• 业务代码对技术的作用

  • 只有能够解决问题的人，才配谈技术理想。
  • 并不是说学习算法和基础没有用，这是为业务提供理论基础

• 迭代的意义

  • 软件无法一次性把所有的业务都模拟出来，必须要分步骤将一个一个阶段做出来，通过用户的反馈，一点点地升级。
  • 这就是所谓的迭代，每一个小的迭代都是瀑布式的推进。
  • 迭代的前提是必须要先确定优先级。

技术调研/预研¶

概述¶

• 技术调研 vs 技术预研

  • 技术调研是针对粗粒度需求实现方案进行的研究，很有可能对所需技术根本不清楚，需要通过调研项目来完成技术了解、技术选型、技术可行性分析、技术方案设计等工作。
  • 技术预研是针对细粒度需求的实现方案进行的预先尝试，主要针对的是通过技术调研所选择的技术，同时结合我们产品化时的实际需求，对实现时存在的不确定性因素、细节等进行预先研究、尝试，从而减小产品化过程中的技术实现风险。

• 参与调研和预研的重要性

  • 设计一个最优的技术方案前提：了解系统存在的问题、产品未来的走向和技术团队的现状。
  • 为什么技术负责人要亲自设计呢？因为技术负责人亲自主导或参与了设计，就能有针对性地去解决问题，即便将来系统遇到瓶颈，也能更好地优化或者重新设计。

技术调研¶

• 调研报告

  • 1）调研过程介绍：对需求进行整理，明确调研的方向，初步筛选，选择技术调研过程；
  • 2）调研技术简介：逐一说明调研技术的实现原理、规则；
  • 3）测试环境：对测试环境进行说明；
  • 4）调研技术测试方案：包括通用测试方案和业务测试方案；
  • 5）调研技术测试用例：包括通用测试用例和业务测试用例；
  • 6）调研技术测试数据对比/分析：包括对通用测试场景和业务测试场景的测试结果数据进行对比并分析原因；
  • 7）调研总结：对业务方案进行总结，从性能、技术评测、需求方、产品化、综合等多个不同的角度评判调研结果，选择可以用于技术预研的技术；
  • 8）列举现有不足和下一步工作计划。

• 调研过程

  • 调研过程需要：“需求整理→明确技术方向→搜索技术调研方向→调研方向初步筛选→选择技术调研方向→确定调研测试方案及用例→调研执行→调研数据对比→调研结论”
  • 1．需求整理

  • 2．技术选型

    • 1）搭建原型，测试、研究，再决定

    • 2）找到对的人

      • 有良好技术背景的人——那些人了解不同的范式，理解编程的理论（算法和并发），受过良好工程文化熏陶，这样的人很少会去凑热闹。
      • 有经验的人——年轻的开发人员更喜欢凑热闹。如果有多年的开发经验，见过许多技术，踩过许多坑，在技术决策时就更容易做出客观的判断。

    • 4）技术采用生命周期 Technology Adoption LifeCycle

      • 一个用来衡量用户对某项新技术接受程度的模型。
      • 钟形曲线。分五个阶段：创新者阶段（2.5%）、早期采用者阶段（13.5%）、早期大众阶段（34%）、晚期大众阶段（34%）与落后者阶段（16%）。

  • 3．明确方案

    • 1）实现方案：设计、编码
    • 2）测试方案：通用测试场景和业务测试场景
    • 3）测试用例

  • 4．执行方案

  • 5．讨论结论

    • 覆盖性能角度、技术评测角度、需求方角度、产品化角度

技术预研¶

• 技术预研思路

  • 难度较大的关键技术的预研，在项目立项之前开展；
  • 项目正式立项后，难度较大的关键技术已经攻克。

• 预研过程

  • 1．技术介绍
  • 2．明确方案
  • 3．执行方案

  • 4．讨论结论

    • 预研工作的输出为技术可行性分析报告（技术介绍文档、技术环境搭建文档、功能验证文档、性能测试），有优越性和风险性评估。

关于技术开源¶

• 各种开源协议介绍

  • BSD开源协议：使用者可以“为所欲为”，可以自由地使用、修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。
  • Apache Licence 2.0：和BSD类似，同样鼓励代码共享和尊重原作者的著作权，同样允许代码修改、再发布（作为开源或商业软件）
  • GPL：GPL的出发点是代码的开源/免费使用和引用/修改/衍生代码的开源/免费使用，但不允许修改后和衍生的代码作为闭源的商业软件发布和销售。
  • LGPL：允许商业软件通过类库引用（link）方式使用LGPL类库而不需要开源商业软件的代码。

• 开源的好处

  • 开源不仅意味着公司技术有了影响力，而且开源后技术需求的输入会变多，外部会给内部提供许多技术需求，从而通过从外部推进内部加快技术产出与技术创新。
  • 创新后再回归到开源，进而构成技术闭环。

系统架构¶

系统架构工作¶

• 软件架构概念

  • 组织架构

    • 架构拆分的原则，首先来源于业务自身的组织架构，软件架构要保持和业务组织架构的匹配关系。
    • 如果软件开发团队的组织架构和业务的组织架构能一直保持高度一致，内部损耗就会达到最小，软件架构设计才能真正落地。

  • 进化 vs 生长

    • 业务相当于基因，而架构呈树状延展则相当于细胞的分裂。就好比每一个人，都是从一个细胞逐渐分裂出来的。一个细胞最终分裂成什么，起决定作用的不是分裂本身，而是它的基因。基因决定了细胞最终会分裂生长成什么样的一个生命。
    • 比如一棵树从种子长成小树苗，再长成参天大树，这不叫进化，这叫 生长。长成什么树是由树的基因决定的，不是架构。因为不管怎么拆分，业务的目标，也就是基因没有任何变化。
    • 如果一个企业的业务由制造商变成电商，这个时候业务就发生进化了。因为基因变了，业务已经完全不一样了，整棵架构树的含义就变了。该企业的软件架构就需要重新设计，而不能在原有的架构上修改，也就不存在架构的进化。
    • 严格来说，只有业务才会进化，架构是支撑业务长大的。业务的核心生命周期相当于架构树的主干，主干没有变化，则说明没有变成一棵不同品种的树，因此只有架构的拆分不能叫作进化

• 软件架构师岗位

  • 职责

    • 更进一步，架构师要解决的问题基本都是别人的问题。别人的问题解决了，架构师自己的问题才能解决。
    • 架构师都要有觉悟，理解并发现问题永远比解决问题更加重要，遇到问题首先进行分析，不要急于解决问题。

  • 谁是架构师？

    • 很多公司设了软件架构师的职位，主要职责是做出架构设计，他们具备一定的影响力，但并不具备调动组织架构的权利。这样的职位往往不能发挥架构师的作用，有时候还会起反作用。
    • 软件架构师必须是一个组织的领导人，有权利调整这个组织的架构，才能够更好地发挥架构师的作用，才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。
    • 一名优秀的技术管理者，技术在前，管理在后，并不是说两者有太大的轻重差异，而是你需要花费70%的时间在技术上，只能花30%的时间在管理上，但是你需要用这30%的时间做完100%的管理工作。技术、管理，一样都不能差，架构能力也是一样。
    • 因此，一个好的领导就是一个很好的架构师。我相信，在架构师的领导下，这个组织一定是健康向上的。

• 软件架构师的责任

  • 企业软件架构的设计不仅要注重某一个系统功能，更需要给企业一个可进化的、可持续发展的、不断创新的平台。
  • 团队达到一定规模之后，技术管理者（也可能有独立架构师存在）的大部公时间就需要花费在思考上面了，当然也可以继续编程，但是编程的目的是验证架构是否合理，所以不要受是否需要编程这一思维的束缚。
  • 如果设计得不好，那么团队就会走很多弯路，如果想要设计得很好，你必须自己或者带领团队做很多的测试、预研工作。作为架构师，你需要多多思考，很多时候因为很忙、事情很多，导致真正思考时间太少了。

  • 应对增长

    • 如果以很少的资源达到了很大的业务增长，那肯定是一位好的架构师，公司所节省下来的资源应该回馈给架构师，从而形成正向反馈。从这一点来看，架构师要对总体增长的效果负责。

• 软件架构落地

  • 针对不同的生命周期，要选择不同的技术来进行支撑，再把不同的生命周期分工交给不同类型的软件工程师去实现。这就是架构师和技术人员的分工配合，架构师负责拆分生命周期，技术人员负责实现生命周期。
  • 组织架构是树状的，上层节点要求下层执行，所以执行才是架构的核心。同时权力也要下放，只有权力下放了，下层节点才能够更好地执行。只有架构师拥有组织架构的权利，才能确保架构拆分的落地。

系统架构能力培养¶

• 学习能力

  • 如果你想进步、想要有所成绩，就需要持续学习、终身学习。
  • 看论文可以被认为是架构修炼的一种方式，因为很多论文写得比较严谨，也比较系统化，了解一个系统实现的细节对于架构方面的成长很有好处。
  • 也许很多人对架构的理解还停留在设计模式、重构、SOA等软件层面，然而这仅是非常基本的东西，架构师的脑子里不光需要知道让软件如何高效地运行，还需要知道如何去结合网络、存储，甚至一些文件系统的特性，比如GFS、NFS、ⅩFS、NTFS等。而且架构师还需要知道一些编程语言的特性，如C、C++、Java、PHP、Python、Lisp、JS等。现在是一个混合编程的时代，只了解一种语言，即使再精通也会使你在架构系统的时候受到很大的局限。架构师需要对数据库技术有深刻的认识，因为现今是一个信息时代，大量的信息都是需要存储并检索的，数据库设计得不好，将会严重影响系统的性能，而这一点往往会被我们的设计人员忽略，他们只知道遵守那些范式而不会去结合数据的特性来设计数据库。
  • 从一个程序员到架构师是一个很大的变化，架构师需要从大的方面考虑，而不只是考虑这个模块该用哪种设计模式去开发。总的来说，想要成为架构师，需要有耐心，不断学习，拓宽自己的视野，不要局限于自己眼前的项目，多关注开源技术，多关注热门技术社区的新动向。

• 创新思维

  • 试想如果现有代码的可维护性很差，任何人都很难在有限的时间内写出高质量代码，最终很可能“随波逐流”。
  • 创新无疑需要批判性思维，但前提是我们能将“批判”与“批判性思维”区别开，批判的目的只是为了达到对某个事物的否定，而批判性思维则是通过否定来寻找更好的做事方法。单纯批判是消极的，而批判性思维是积极的。
  • 没有精神层面的支持，创新是无从谈起的，因为创新实在是一项艰巨的工作，概念的建立不是一蹴而就的，需要反复地推敲、对比、自我否定。问题的定义更是自我意识游走在理想与现实之间，尝试各种问题边界的可能，不断地进行权衡。
  • 人生贵在坚持批判性思维，而不是简单的批评与抱怨。所有这些行动都是很困难的，因为它们会产生巨大的认知摩擦。

  • 创新模型核心要素

    • 创新需要挑战现状，即批判性思维。
    • 批判性思维需要准确的问题定义。
    • 问题的定义有赖于概念系统的建立。
    • 概念模型的正确与否是次要的，更为重要的是要有一个概念模型，然后这个概念模型可以随着认识的深入而不断演化。谁在幕后推动认识的发展？答案还是批判性思维。

  • 一个简单的应用会随着时间推移逐渐变大，几年后，这个小而简单的应用会变成了一个巨大的“怪物”。一旦你的应用变成一个庞大而又复杂的“怪物”，那开发团队肯定很痛苦。

  • 敏捷开发和部署举步维艰，其中最主要的问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正Bug和正确地添加新功能将变得非常困难，并且很耗时。
  • 一个应用越大，启动时间就会越长，大部分时间就要在等待中度过，生产效率会受到极大影响。

常见问题分析¶

• 无从入手

  • 市面上也确实有很多例如“分布式系统架构”“微服务架构”等跟随潮流的书籍，但是看完后只停留在会采用一些开源框架进行整体框架搭建（注意，我说的是搭建，而不是设计）。
  • 确实是搭建，你所拥有的能力就好像小孩子搭积木，只会采用固定套路，或者学得差点的连固定套路都不会，这样对你的个人发展其实没有多大好处，
  • 这也是为什么很多程序员在完成了程序员到架构师的转型后，没过多久就转为纯管理，或者彻底离开了技术界。因为他们从来没有大彻大悟地理解系统架构。
  • 如果你发现一个人画出来的总体架构图有点奇怪，没有区分服务端、客户端，这时候你可以猜测他并没有真正理解什么是系统架构，他更多的是以模块方式进行切割，而不是从架构设计角度思考。
  • 出现无从下手或者随意下手的情况，真正的原因都是不理解，建议大家从软件系统架构基础类的书学起，不要一开始就看基于潮流框架的架构书。

• 轻视设计

  • 职场新兵在设计业务系统时三类问题
  • ❑ 需求沟通完，马上就开始设计数据表结构，就想着有哪几张表、要建哪些索引、有哪些唯一键、如何保证事务、如何设计触发器等。出现这类问题很正常，毕竟在学校学的都是理论，授课的老师很多没有太多的工程经验，也指导不了你的设计。
  • ❑ 要他设计一个系统，完全摸不着头脑，一提笔就是写代码，想到哪里写到哪里，没有一丝设计。出现这类问题的同学，一般都是在学校没好好学习的同学，或者是非计算机专业的同学。
  • ❑ 而有一些工作经验的人，做出来的设计也是一团糟，不是考虑不周全，就是画的图别人看不懂。这类人一般是平时不喜欢看书学习，或者是之前刚工作的时候没有有经验的人指导。

• 技术优先

  • 随着人们问题的不断变化，会有不同的技术周期出现，技术有自己的生命周期。没有永远最好的技术，也没有永远最差的技术，问题总是在不断发生变化的。
  • 我其实不太喜欢面试培训班出来的技术人员，他们可以滔滔不绝地和你描述各种框架的使用，细微到某一个参数，每遇到这种场景，我真想用英语说“I don't care。”
  • 并不是有偏见，而是我真的不在乎你懂不懂参数的配置，我要问的是计算机科学基础知识，可以聊算法、聊数据结构、聊设计模式、聊你参与过的系统架构设计、聊内存管理机制和垃圾回收机制、聊你对于技术的情怀。
  • 框架的选择，实质上是对技术可行性的选择，这又需要符合当前的业务形态，所以，没有哪一个技术或者框架是最好的，只有最适合你的产品需求的，才是最好的。
  • 技术人员如果要成为架构师，就必须跳出技术的视角，换一个角度去看技术。要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，而不只是追求新潮的或自己喜欢的技术。

• 业务困境

  • 业务和架构都是处理人的问题，而技术人员最讨厌处理的就是人的问题，内心厌恶，却又无法逃避。因为这个排斥的心理，工作中始终想避开和人有关系的地方。

  • 为什么软件工程师会有时间恐惧和压力呢？

    • 原因是他们把按时完成自己的工作当成了自己的最大利益。人对时间的压力是与生俱来的，对业务的不了解也会导致他们没有太大的把握。
    • 深入到业务中去；随着对业务的熟悉，对时间的恐惧才会慢慢消失。对业务领域理解得越深入，就越知道如何去发现问题，慢慢就成为业务专家了。

  • 还有另一种很普遍的现象，做技术的软件工程师往往看不上业务，觉得技术更高端，而业务太平凡、太低端，并且业务人员总是给技术挖坑。而业务人员则觉得做技术的眼光高，但总是理解有偏差。技术人员往往对业务一知半解，业务问题总是解决得不圆满，但业务人员对此又无可奈何，因为自己不懂技术。

  • 做架构的人必须亲身体验业务，感受业务，才可能真正认识业务的个性，真正认识业务所面临的问题。
  • 在理解业务个性的基础上，才能够谈共性。否则这个抽象就像是无根之木，一旦局限于个人的主观认识，很难长大。
  • 在软件开发的整个过程中，参与其中的所有角色，都应该以软件工程师为核心，帮助软件工程师理解业务，让软件工程师成为业务专家。
  • 只有软件工程师成为业务专家，写出来的软件才是靠谱的。

• 专职架构师

  • 要想成为架构师，必须超越对时间的恐惧，看清楚需要解决问题的主体是业务人员，而不是自己。
  • 即需要解决的问题是另一个行业的问题，自己是在帮助业务人员解决问题。

• 一步到位思想

• 系统过度设计问题

  • 比如觉得MySQL性能不好，要加一层Memcached缓存，最后设计并上线使用后发现，缓存命中率非常低，白白浪费了大量服务器，损耗了性能，并增加了系统的复杂性。

其他¶

• 架构和树的关系

  • 树状结构

    • 架构和树的关系我们每次谈到架构，都需要谈论树状结构，那么树状结构有什么好处呢？ 树状结构特别适合增长。
    • 树状的增长，成本方面最低、沟通的路径也没有显著的增长，带来的效果最好。
    • 树的结构也保证了分支的能量汇集到树干，保障了整棵树的生长。而架构恰恰是为了应对增长的，自然而然架构都是树状的。

  • 分层

    • 分层实际上是架构树状拆分的结果，所以当我们采用分层的时候，内心先要有树的概念。
    • 如果我们直接采用分层的方式设计，最后就会违背树的原则，导致很多复杂的问题发生，从而影响到系统的长大，例如跨层访问形成了图，这就违反了树的原则

  • 拆分始终是围绕着业务的核心生命周期进行的，结果只有一个：无论如何拆分，它依然是树。

• 为什么会有架构

  • 当软件对应的业务组织架构越来越复杂，或者当访问的流量越来越大时，就会产生时间的压力，需要不同技巧的人同时工作，并对代码进行切分，形成代码的架构。
  • 从分层的角度进行思考的时候，千万注意不要破坏树的架构。有树才会有分层，有分层却不一定有树。

• 业务、技术、架构三者关系

  • 业务、架构和技术之间是共生的关系，而不是互斥的关系。
  • 由于业务和技术属于两个不同的树，也就是说有两个不同的根节点，因此只有沟通才能解决问题。
  • 技术总是在人类对业务目标要求不断提高的情况下产生，其目的是为了获取更大的利益。所以，技术是为了解决业务问题而产生的，没有了业务，技术也就没有了存在的前提；有了更好的技术后，效率较差的技术，就会慢慢被淘汰，进而消失，一切都遵从人类的利益诉求。
  • 先有 业务 问题，才会有 技术 来解决业务问题。
  • 而业务的长大要求，提高了对技术的要求，导致了对业务生命周期的拆分，以并行的方式提升效率，形成了 架构，也形成了新的技术。
  • 三者的关系里：业务是核心，技术是解决业务问题的工作，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，技术需要架构来合理组织，以提升效率。软件和业务最终是要合体的。

• 架构拆分要点

  • 切分与建模

    • 架构切分的过程就是建模的过程。切分出来的不同子生命周期就形成了不同的概念。所以每个概念背后都是一个生命周期，每个生命周期都是一个模型。

  • 切分与组织

    • 架构切分的结果最终都会体现在组织架构上，因为架构的切分是对人利益的重新分配。另一方面，架构切分需要组织架构来保障实施。要为负担重的相关利益人减轻职责和权力，要为负担轻的需增加职责和权力，这里反复强调职责和权力，它们本质上应该是需要对等的。如果所有人负担都很重，就要增加人，从而形成新的架构切分；或者引进新的技术，提升大家的生产力，以形成新的架构切分。所以进行架构切分的时候，往往也是组织长大的时候。

  • 切分与森林

    • 一个好的架构拆分会形成一棵树，慢慢会长大成一片森林。每棵树在这个森林里都能够获得所需要的养分，有自己的空间。每棵树的内在是平和的、舒展的，遵循自己的生命周期规律，顺其自然地长大，一派欣欣向荣的景象。这就是架构的魅力所在。

• 给架构师的建议

  • 不论是架构师、产品线负责人或某个系统的产品负责人，都要有架构设计的理念和知识，尤其是后端产品经理，必须充分理解企业应用架构的基本概念。
  • 1）系统定位和边界要清晰，对应的业务定位和边界要清晰。一套应用系统的存在，是为了解决某一类业务问题，对应某一个业务板块。如果业务板块或业务单元定义模糊，也会导致对应的应用系统定位混乱。
  • 2）系统要实现松耦合、高内聚[插图]。对外界系统要透明、简单、易理解，与外部系统的接口要简明、扼要、灵活。内部模块高度聚合，粒度越细越不可拆解。
  • 3）易变的、尝试中的新业务要避免影响现有业务的稳定性。对新业务的支持，可以考虑新建独立微小型应用系统，以便避免改造成熟核心系统，影响其稳定性和健壮性。
  • 4）系统之间数据要实现单向流转。系统之间尽量保证单向数据流转，确保数据流可回溯性、一致性和可追溯性。混乱的数据流转管理会造成应用架构管理的灾难。
  • 5）架构设计核心目标是支持业务，有时候不合理的存在是合理的。应用架构存在的首要目标是支持业务，很多成长型企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度而导致企业错过发展时机。这种情况在互联网型企业更为常见。业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。
  • 对于CTO或公司架构师而言，要保证整体企业应用架构的合理性，只要大框架合理，局部的偏差可以忽略，修正的成本也比较小。如果大框架有偏差，修正的代价会非常高。对于产品线负责人而言，要保证局部框架的合理性，避免出现由于设计不合理造成的返工和补救工作。很多时候架构师或产品线负责人要做出判断，是做一套新系统还是修改老系统，若是前者则新系统如何定位，若是后者则老系统如何调整定位。另外还考虑：数据如何流转，系统之间如何关联，底层数据如何打通；是否要复用其他系统模块，是否要将某些模块抽象化、服务化、平台化。对于产品经理，要在系统级别的粒度做出类似问题的判断，能够识别出可能存在的系统演变风险，及时升级控制不了的问题，进而避免做出错误决策。