UML

从程序员到架构师的成长之路

作者: likaiguo

从程序员到架构师的成长之路

课程大纲

  • 程序员的技术发展道路和职业规划
  • 提升代码质量和开发效率的方法
  • 什么是适合业务发展的好架构?
  • 架构师日常工作,享受什么样的苦与乐?

讲师简介

李开国

  • 对系统架构设计有深入理解
  • 专注机器学习和自然语言处理
  • 某互联网创业公司技术总监
  • 前腾讯QQ离线数据挖掘工程师
  • OneAPM公开课:《推荐系统架构演进》讲师
  • 趋势科技Big Data创意程序大赛中国区亚军,国际季军
  • 中科大硕士研究生

weixin: likaiguo
weibo : http://weibo.com/likaiguo

课程大纲

  • 程序员的技术发展道路和职业规划
  • 提升代码质量和开发效率的方法
  • 什么是适合业务发展的好架构?
  • 架构师日常工作,享受什么样的苦与乐?

一.程序员的技术发展道路和职业规划

明确入行的目的

  • 冲着“收入高”这一点

  • 对技术充满热爱

  • 有改变世界的冲动

技术发展规划

  • 软件业人才结构

程序员是技术相关的职业生涯一个不错的开始，不论你以后是要做CTO还是总监等等，
只要你还做着技术大家庭中的一员，那现在的技术沉淀，都将是你未来的基石。

主要技术类岗位

2016-9-21-截图

选择合适的工具

语言只不过是一个工具，“与其分散进攻，不如全力一击”
万变不离其宗

  • 面向过程
  • 面向对象
  • 函数式编程

明确发展方向

做啥???

职业规划

最关键的一点: 你的梦想(理想)是什么? O(∩_∩)O哈哈~

  • 角色发展路线
  • 不仅仅是coder
    抽取《软技能：代码之外的生存之道》

程序员来源

专业:

  • 科班计算机/软件工程类专业;
  • 自动化,通信,信息科学类计算机相关专业;
  • 生物相关理科专业;
  • 文科类专业;

大致分为以下几类:

专业科班
相关专业人员
半路出家
基于兴趣

职位跳转图谱:软件工程师

职位跳转图谱:软件工程师

职位跳转图谱:架构师

职位跳转图谱:架构师

职业通道的路线一览

可能与有些公司的职位不符，毕竟公司不一样，规模和起名的习惯可能不一样，但是大体上是这么个路子。不要太拘泥于职位名称。

程序员职业发展路径

程序员工作两三年后，基本上都会考虑自己的未来发展方向。发展的路径主要有以下三种：

  • 程序员–系统分析员–架构师–技术经理(Team Leader)–>(技术总监)–CTO；
  • 程序员–>高级工程师–>资深工程师–>技术专家–>CTO;
  • 程序员–项目组长–项目经理–项目总监–CTO；
  • 程序员–>产品经理–>产品总监–>CTO;
  • 现在还多了另一条路，创业（创业合伙人）。现在技术创业的越来越多，大有流行趋势。

（虽然都是CTO，主要的关注点和方向上有些不一样）

不管是项目经理还是技术经理与产品经理，都要求要熟悉业务，业务是需求的来源，没有不谈业务的技术，所以不管你从哪个方向发展，都要求对业务熟悉。

产品经理要求对业务最熟悉，项目经理次之，技术经理排最后。对于程序员来说，刚开始工作的前几年可以埋头扎到技术里面，一般这个时间在2-3年的时间，然后就应该多关注业务了。

分享8年开发经验，浅谈程序员职业规划
程序员的职业发展道路

  1. 从技术向业务过渡
  2. 从程序员向技术管理发展
  3. 单方面向技术发展

浅谈程序猿的职业规划，看你如何决定自己的未来吧

程序员职业发展路径

开发工程师：这个大家是最熟悉的，这个角色主要负责系统中某个模块或某个功能的设计与编码，有时候还会有数据库设计的工作等等。

研发经理：主要负责项目的技术选型，技术难题的攻克，技术人员的招聘，团队成员的技术培训与熏陶等一系列与技术相关的工作。

项目经理：主要负责项目进度的规划、跟进、落实、交付以及与客户的沟通等任务，是一个项目的监督者与管理者。

小组讨论:

IT行业是吃青春饭???

程序员工作只能做到35岁吗？之后的路是怎么走的呢?

软件工程师年龄分布

软件工程师年龄分布

高级软件工程师年龄分布

高级软件工程师年龄分布

系统架构师年龄分布

系统架构师年龄分布

IT行业是吃青春饭???

关于年龄的传说:

你看的是五年前的文章吧，现在的主流说法是40岁。五年前是35岁，我大学那会儿是30岁。
时代是不断发展的。

我二十二的时候，他们说程序员只能干到25 。
我二十五的时候，他们说程序员只能干到27 。
我三十的时候，他们说程序员只能干到 35 。
我现在三十七了。我觉得再干三十年毫无压力。

编程不是青春饭，技术才是硬通货。

写程序可以说像盖房子，又不能说就是盖房子。
第一，盖房子要绝对的体力，人年纪越大，越吃力。写程序不一样，体力只是一部分，最重要的是智慧，同样的一个模块，你去看senior和刚毕业的小豆包们，绝对不一样。
第二，程序员，与其说软件工程师，是要求有完整的思维的，同样是计算机毕业的软件系的同学，北大青鸟和MIT的肯定不一样，所以知识和思维才是软件工程的核心~
第三，任何行业都会是优胜劣汰的~时间只是催化剂

成功无所谓年纪

如果你仍有斗志，上天就只能让你失踪于海难，让你出车祸，让你死于滑翔伞事故，让你得阿兹海默氏症，或者诸如此类的方式，才能无耻的战胜你。

年纪大了、有家庭了、有小孩了，放不开手脚了。这个「现实」可不仅是程序员需要面对的，是所有人都需要面对的。

心态 真的太重要。

成功无所谓年纪:

  • 你周围的人
  • 国内外牛人
    各大公司的技术专家?
    计算机语言的设计者?

二.提升代码质量和开发效率的方法

第一原则: DRY

Don’t repeat youself!!!

1.代码质量

保证代码质量最简单的方法: 这个代码会给其他人review!

  • 团队代码规范
  • 代码review
  • 单元测试与集成测试
  • 功能测试与性能测试
  • 规范的需求和设计文档

拥抱开源

  • 阅读github上star或fork数高的代码
  • 向开源社区提交代码
  • 遵循开源社区的代码规范

celery对贡献者要求

Community Code of Conduct(社区行为准则)

  • Be considerate(为别人着想) -> 首先为人写程序,其次为机器
  • Be respectful(尊重)
  • Be collaborative(合作)
  • When you disagree, consult others(异见时询问他人)
  • When you’re unsure, ask for help(不确定时,寻求帮助)
  • Step down considerately(稳定的交接任务)

找到合适的导师(尤达)

向周围的人求教

  • 没有天才 <极客与团队>

最直接的方式找认识的人,特别是团队中.

找到合适导师: 书籍

《代码整洁之道》
《代码大全》
《重构 改善既有代码的设计》

计划一年要读书的数量

StackOverflow讨论帖:哪本最具影响力的书，是每个程序员都应该读的 59本 [^books]

找到合适导师: 公开课/MOOC

MOOC（Massive Open Online Courses）

推荐: 在Coursera，随时都是学习的好时候–微软亚洲研究院副院长 张峥

文档

  • 产品设计文档
  • 软件设计文档
  • 测试用例文档
  • 项目部署文档

为什么需要有正式的文档?

重构: 改善既有代码的设计

重构：在不改变软件可观察行为的前提下改善其内部设计

为何重构：

  • 重构改进软件设计,提高软件质量
  • 重构软件更容易理解,提升可读性
  • 重构帮助找到bug,减少错误
  • 重构提高编程速度,阻止系统腐烂变质

书: 《重构 改善既有代码的设计》

重构: 代码的坏味道

  • 重复代码
  • 过长函数
  • 过大的类
  • 过长参数列
  • 发散式变化：类经常因为不同的原因在不同的方向上发生变化
  • 霰弹式修改：每遇到某种变化，你都必须在许多不同的类内做出许多小修改
  • 依恋情结：一个类的动作过分依赖其他类
  • 数据泥团：不同地方的相同数据字段
  • 基本类型偏执
  • Switch 惊悚现身：考虑用多态代替 switch

重构: 代码的坏味道

  • 平行继承体系：为某个类增加一个子类的时候，也必须为另一个类相应增加一个子类
    冗赘类
  • 夸夸其谈未来性：某个抽象类其实没啥太大作用
  • 令人迷惑的暂时字段
  • 过度耦合的消息链
  • 中间人：某个类接口有一半的函数都委托给其他类
  • 狎昵关系：两个类过于亲密
  • 异曲同工的类：两个函数做同一件事，却有着不同的签名
  • 不完美的库类
  • 纯稚的数据类：单纯的数据容器
  • 被拒绝的遗赠：子类复用超类的行为，却又不愿意支持超类的接口
  • 过多的注释：当你感觉需要撰写注释时，请先尝试重构，试着让所有注释都变得多余

构筑测试体系

测试

  • 确保所有测试都完全自动化，让它们检查自己的测试结果
  • 一套测试就是一个强大的 bug 侦测器，能够大大缩减查找 bug 所需要的时间
  • 频繁地运行测试。每次编译请把测试也考虑进去——每天至少执行每个测试一次
  • 每当你收到 bug 报告，请先写一个单元测试来暴露 bug
  • 编写未臻完善的测试并实际运行，好过对完美测试的无尽等待
  • 考虑可能出错的边界条件，把测试火力集中在那儿
  • 当事情被认为应该会出错时，别忘了检查是否抛出了预期的异常
  • 不要因为测试无法捕捉所有 bug 就不写测试，因为测试的确可以捕捉到大多数 bug

浅谈代码覆盖率
有赞分层自动化测试实践
敏捷开发中高质量 Java 代码开发实践
写出高质量代码的10个Tips

2.开发效率

效率 就是工作量除以时间。提高效率需要从这两方面着手，一是增大工作量，二是缩短工作时间。

【如何提升工作效率】
1、列出具体行动和细分目标，把待办清单画成流程图；
2、给每项清单任务附上优先度；
3、定时轮换任务调动积极性，花1小时在重要任务上，然后换着做一项容易而优先度较低的任务；
4、保持对重要任务的关注度，正在做一件事，却不时想着另外一个事，请把那件事记下来，忙完后再去做。

问:程序员上班有什么提高效率技巧？

断网!O(∩_∩)O哈哈~(Just a joke!)

其他回答

打开音乐播放器，戴上耳机，少刷sns；
有条件拔掉网线，无条件关掉浏览器\QQ，
手机静音，
暂时无视所有产品经理和设计师。

一切源于专注

  • 专注并且避免重复.
  • DRY(Don’t repeat youself!!!)原则.
  • 首先你得设置一个小目标. O(∩_∩)O!

如何专注?

  • 方法: 番茄工作法
  • 设置有优先级的任务列表(Todo List)
  • 工具: 番茄土豆

关掉微信,QQ,邮件提醒;统一的时间,集中回复;

设置可量化的目标

  • 代码行数
  • 文档数量
  • commit,bugfix数量
  • 代码覆盖率 nose,CI

设置Deadline

美国的”自然科学基金委”(NSF)发现最近申请各种资金的科学项目提案太多了，审都审不过来，怎么办呢？
结果他们发现最好的解决办法就是。。。不设置申请的截止日期 (deadline)，总的提案数量自然减半； O(∩_∩)O!!!

  • 保持对deadline的敬畏
  • 一鼓作气,再而衰,三而竭

我们要多线程么?

为什么多任务并行一般都很糟?

  • 不停的上下文切换带来过多消耗
  • 什么任务适合 进行多线程/多进程 并行
    • 例如: 跑步时候听听音乐;写程序时候听舒展的音乐
    • 写作时候看电视???

例子:

  • 开车时候换挡/巡航模式
  • 函数堆栈

好记性不如烂笔头

书写

  • 记云笔记，特别是费好大劲整理出来的资料。轻而易举就能拿到的资料没必要花时间记，利用搜索引擎即可。
  • 桌上放一本白色草稿纸和笔，你随时需要利用图表捋顺思路。
  • 思维导图: 捋顺思路后不妨花点时间整理成思维导图，下次看5秒的效果相当于花5分钟重整思路。

markdown让书写更美好

  • 语法简洁
  • 专注于内容
  • 不去担心样式
  • 纯文本便于版本管理

markdown使用举例:

  • 文档书写: 强大的插件支持
  • 书写博客: hexo等
  • PPT: landslide
  • 论文: pandoc+latex

责任心

  • 对自己负责: 对自己的承诺负责

  • 自驱力: 自我驱动

  • 外部问责

找到你的Time Killer

找到最大的时间杀手

  • 找到最花费时间的地方;
  • 找到自己的节奏: 什么时间段工作效率最高;
  • 分配好工作内和工作外;
  • 跟踪你的时间;

是不是在:

  • SNS
  • 查看碎片信息: weibo,weixin,qq
  • 看电视
    上花费高昂?

形成习惯

行为 惯例 习惯

成就我们的恰恰是那些不断重复做的事情.因此,优秀不是一种行为,而是一种习惯. – 亚里士多德

要培养工作习惯，并且要让其他人理解尊重你的工作习惯，你知道总被人打断的碎片化编程时间会杀了你

了解习惯

  • 习惯: 暗示,惯例,奖励

找出坏习惯

  • 打开电脑后,查看email,各种QQ,微信,刷网页

形成新习惯

  • 集中处理碎片任务
  • 不加班，晚上早点睡觉，保持作息规律
  • 工作时间设立小的计划

快速解决coding中遇到的问题

  • 官方文档
  • Google(如果是技术问题避开百度吧!)
  • Github
  • Stackoverflow
  • 源码

对新技术充满热情

  • 愿意使用新东西(慎重用于生产)
  • 爱折腾

不要重复造轮子

  • 社会化编程的趋势越来越明显
  • 研究和学习成熟的库
  • 拥抱开源社区

敢于造新轮子并分享/开源它

我们并不总是满意其他人的封装和开源的工具包.慎重思考发现并不那么美好的时候,要敢于动手造一个新的了;

  • 找不到的轮子
  • 不合适的轮子
  • 不完美的轮子

例如:

小组讨论:

阿里员工用脚本抢中秋节月饼,你怎么看???

自动化一切

Automate everything!!!

非常具有工程师思维. 只是没有做好边界条件测试;

  • 自动化一切

    各种自动化工具: fabrickk,ansible,docker等
    自动化测试

  • 工程师天生是追求效率的
    有人说认为程序员花大量的时间做自动化的工具，还不如人肉的效率高，比如，写自动化的脚本花5个小时，而重复做这件事200次只花3个小时。有这样的理解的人根本不懂工程。
    一方面，这个工具可以共享重用，更多的人可以从中受益，这次我花5个小时开发这个工具，下次只用1小时改一下就可以用在别的地方，这是着眼于未来而不是眼下的成本。更重要的是，这是一种文化，一种提高效率的文化，他会鼓励和激发出更多的这样的事情发生。
  • 人类之所以比别的动物聪明就是会使用和发明工具.
    而古语也有云：“工欲善其事，必先利其器”，看看美军的装备你就知道战争工具的好坏有多重要了，一个公司的强大之处在执行力，而执行力的强大之处在于你有什么样的支持工具。这些，已经不是工程师文化，而是人类发展的文化。

月饼事件-新篇章,leon lee最后回应

快捷键

熟练使用快捷键，不单能提高操作之间的切换速度。更重要的是它能时刻提醒你，你的软件还有这样那样的功能（尤其是IDE上的功能）。

  • 不要让手指离开键盘
    编辑器之神: vim
    我用到的vim模式演示
    vim
    所有编辑器: haroopad,Sublime,eclipse,pycharm
    浏览器: vimium
    命令行: oh-my-zsh vi插件

其他各种快捷键
F2,F5-8,F12,C,V…

工欲善其事必先利其器

效率提升工具集推荐
硬件层面

  • 跑的更快的设备(Mac经验谈,SSD)
  • 宽度合适的屏幕,多配一块屏幕辅助，省得来回切换窗口。
  • 键盘
    代码书写
  • 合适的IDE
  • vim/emacs/sublime 编辑器
  • 纯文本的威力
  • 文档书写:markdown
    协作工具
  • 团队协作工具tower
  • 代码版本管理git
  • 持续集成Jenkins
    vim模式无处不在,各种插件
  • 浏览量网页: chrome的vimium插件
  • 代码编辑器: 启用vim模式(eclipse,sublime)
  • 书写文档: vim模式
  • 命令行: oh-my-zsh,vim跳转

减少无效沟通

  • 减少无效会议
  • 用有效的非即时团队沟通软件如Tower、 Trello等,建立任务清单
  • 无法快速用即时通讯软件完成的采用当面沟通或电话

没有银弹

No sliver bullet!!!

不存在一个神奇的方法或技术“银弹”，实现数量级以上的程序员的工作效率的提升。

《人月神话》

三.什么是适合业务发展的好架构?

架构设计是由需求驱动，而非模型驱动。

软件需求

  • 功能需求
  • 质量属性（非功能需求）
  • 设计约束

不管是高层次的架构设计也好，还是最简单的功能实现也罢，对需求的把握都是至关重要的。
需求才是我们付出所有努力想要达到的目的，脱离了需求，就是“答非所问”。同样，大多的反复和变更都是因为对需求的把握不够精准，因此我们要给予需求足够的重视。

一线架构师阅读体会-需求之于架构

唯一不变的就是变化本身,把握好需求

  • 架构是不断演进的
    架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的。
  • 架构需要验证
    在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。

什么是软件架构

  • 什么是架构
  • 架构的种类
    • 功能架构
    • 技术架构
    • 服务器架构
    • 企业架构
    • 网络架构
    • 数据库架构
    • ….
  • 软件架构定义

架构重要么?

软件架构好处

  • 让团队跟随清晰的愿景和路线图
  • 技术领导力和更好的协调
  • 与人交流的刺激因素: 以便于回答与重要决策,非功能需求、限制和其他横切关注点相关的问题
  • 识别和减轻风险的框架
  • 方法和标准的一致性,随之而来的结构良好的代码库
  • 正在构建的产品的坚实基础
  • 与不同的听众,以不同层次的抽象来交流解决方案的结构

基本概念篇

  • 解析软件架构概念
    • 软件架构是应用程序与系统架构的结合
    • 即从代码结构到将代码部署到生产环境,与一个软件系统重要元素相关的所有东西都是软件架构
  • 应用程序架构
    • 应用程序架构讨论的是软件设计低级别切面,通常只考虑单一的技术栈(如:java,.net,python)
    • 结构单元以软件为基础
  • 系统架构
    • 更大规模的应用程序架构
    • 端到端软件系统在较高层次的整体结构.组件和服务更高层次的抽象.
    • 结构单元是各种软硬件,从编程语言框架到服务器和基础设施

架构设计基础

设计的基本原则

  • Don’t Repeat Yourself (DRY)
  • Keep It Simple, Stupid (KISS)
  • Program to an interface, not an implementation
    设计模式中最根本的哲学，注重接口，而不是实现，依赖接口，而不是实现。接口是抽象是稳定的，实现则是多种多样的。
  • Command-Query Separation (CQS) – 命令-查询分离原则
  • You Ain’t Gonna Need It (YAGNI)- 只考虑和设计必须的功能，避免过度设计。
  • Law of Demeter – 迪米特法则 - “最少知识原则”
  • 面向对象的S.O.L.I.D 原则
    • Single Responsibility Principle (SRP) – 职责单一原则
    • Open/Closed Principle (OCP) – 开闭原则
    • Liskov substitution principle (LSP) – 里氏代换原则
    • Interface Segregation Principle (ISP) – 接口隔离原则
    • Dependency Inversion Principle (DIP) – 依赖倒置原则

设计的基本原则

  • Common Closure Principle（CCP）– 共同封闭原则
    一个包中所有的类应该对同一种类型的变化关闭。一个变化影响一个包，便影响了包中所有的类。一个更简短的说法是：一起修改的类，应该组合在一起（同一个包里）。如果必须修改应用程序里的代码，我们希望所有的修改都发生在一个包里（修改关闭），而不是遍布在很多包里。
  • Common Reuse Principle (CRP) – 共同重用原则
    CRP原则帮助我们决定哪些类应该被放到同一个包里。
  • Hollywood Principle – 好莱坞原则
    “don’t call us, we’ll call you.”意思是，好莱坞的经纪人们不希望你去联系他们，而是他们会在需要的时候来联系你。也就是说，所有的组件都是被动的，所有的组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。
    好莱坞原则就是IoC（Inversion of Control）或DI（Dependency Injection ）的基础原则。这个原则很像依赖倒置原则，依赖接口，而不是实例，

设计的基本原则

  • High Cohesion & Low/Loose coupling & – 高内聚， 低耦合
    UNIX操作系统设计的经典原则，把模块间的耦合降到最低，而努力让一个模块做到精益求精。
    内聚：一个模块内各个元素彼此结合的紧密程度
    耦合：一个软件结构内不同模块之间互连程度的度量
  • Convention over Configuration（CoC）– 惯例优于配置原则
  • Separation of Concerns (SoC) – 关注点分离
  • Design by Contract (DbC) – 契约式设计
  • Acyclic Dependencies Principle (ADP) – 无环依赖原则

一些软件设计的原则

最小可用产品(MVP)理念

做出最小可用产品(Minimum Viable Product， MVP)，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。

过度工程（Over Engineering）的问题

讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。

架构模式

  • 分层架构(n层架构)
    • SOLID原则的通用架构
  • 事件驱动架构:一种流行的分布式异步架构模式
    • 用于小规模或者大规模的应用程序
    • 可以与 调停者拓扑（Mediator Topology） 或者 代理者拓扑（Broker Topology） 一起使用
  • 微内核架构(插件架构)
    • 核心系统和插件模块
  • 微服务架构
    • 核心概念是具备高可伸缩性、易于部署和交付的独立部署单元（Separately Deployable Units）
    • 最重要的概念是包含业务逻辑和处理流程的服务组件（Service Component）

架构原则和模式

如何呈现设计的架构?

可视化软件

  • 画有效的草图
  • 模式设计工具(UML,工具:staruml)

UML的5视图方法:4+1视图始终是架构师界最通用的东西，寻找一种向世界妥协的方式。

  • 职责划分（逻辑视图）
  • 程序单元组织（开发视图）
  • 控制流组织（运行视图）
  • 物理节点安排（物理视图）
  • 持久化设计（数据视图）

一线架构师实践指南（二）
软件架构师书籍

架构可视化:一图胜千文,图文并茂

建模工具对比

建模工具 利 弊
UML 善于表达静态与动态结构 不善于表达概念、约束与行为
文字 不善于表达概念、约束与行为 善于表达静态与动态结构
(伪)代码 好的代码有很强表达能力 太细、难以反映意图、不便于非程度员阅读(非通用语言)

以文字为主体，配合以图形（可以用UML）；图形不要太大、太细；不但要表达是什么，而且要表达为什么。

不画图的专家不是好的架构师
【UML 建模】UML建模语言入门-视图,事物,关系,通用机制

恰如其分的预先设计

  • 方法学
    • 瀑布模型: 大型预先设计,推崇写代码前每件事情都经过讨论和评审
    • 敏捷开发: 充分自由度,快速行动,拥抱变化,反馈和交付价值. 演化架构和浮现式设计
  • 恰如其分很难具体量化
    • 过少设计
    • 过分设计
    • 为设计设置语境

最关键是明确自己的需求

为软件生成轻量的文档

  • 代码不会讲完整的故事
  • 软件文档即指南
    • 语境
    • 功能性概览
    • 质量属性
    • 约束
    • 原则
  • 软件架构
  • 外部接口
  • 代码: 呈现底层细节,解释工作原理
    • 文档化的代码
    • 支持自动化生产部分文档
  • 数据文档
    • 数据字典
    • 数据模型
  • 物理架构
    • 服务器架构
    • 网络架构
  • 部署文档

架构实例剖析

包括聘宝平台的Web端系统架构、推荐系统架构、分布式存储/计算系统、底层服务器架构

  • 聘宝系统架构演进路线
  • 其中一些的问题

人员架构: 应对需求与团队规模

  • 两个人
  • 5个人
  • 20个人

服务器架构:

  • 2台服务器: 1+1
  • 10台服务器: 5+5
  • 30台: 10+20
  • 60台+: 15+35

架构演进

  • web端系统:
    • MVC模式–>前端分离
  • web端架构
    • 微内核架构: 核心系统 和 插件模块
  • web端系统与推荐系统解耦
    • RPC架构: 消息队列

华为内部如何实施微服务架构？

服务化架构的演进历史
华为内部如何实施微服务架构？

架构之道-规划、简化和演化

规划还是演化

  • 好的架构是设计出来的
  • 好的性能,好的质量主要源于好的设计,而不是依赖测试
  • 架构设计的质量直接影响演化的难以程度

联想高级架构师分享：架构之道-规划、简化和演化

缺少规划难以演化

单靠演化，即使能使架构越来越优化，也可能需要很长的周期，而对于产品或者项目，时间这个约束条件往往是苛刻的。
迭代是有条件的。建议：在有规划的基础上进行演化。我们无法得到普适的架构，但可以得到确定领域的通用架构，可以在特定领域通过演化使应用架构逐步优化，逐步与业务架构想适应，提高匹配度。

缺少规划难以演化

四.架构师日常工作,享受什么样的苦与乐?

##软件架构师的职责

  • 架构师的基本分类
    • 根据职能: 前端架构师,后端架构师,算法架构师,分布式架构师,运维架构师
  • 其承担的责任
    • 确保概念的完整性，合理的切分工作，制定接口

架构师是最重要的，以确保概念的完整性，合理的切分工作，制定接口。行政领导应当尊重架构师的权威。

软件架构师的职责
架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。

小组讨论:

架构师需要写代码么???

尽可能要写,找到合理的平衡

架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）

软件工程师角色和职责区别

简单地将写程序的工程师分成三类:

  • 第一，写程序的人 （Coder、Employee、Worker）
    这种类型的人单纯的只是为了工作、功课、任务而写程序，虽然职务名称叫做工程师，但是写程序对他们来说只是获取成绩、金钱的工具，写程序对他们来说枯燥无味，但为了生活，他们继续产出他们的程序码。
  • 第二，有目标而写程序的人 （Hacker、Doer、Entrepreneur）
    这种类型的人并不是因为热爱「程序」本身而开始写程序，他们写程序是为了要达成某些目的。
  • 第三，热爱程序本身的人 （Architect、Theorists、Change Maker、Geek）
    这类工程师喜欢程序本身，他们欣赏程序设计的架构、可扩充性、可被测试性。他们喜欢最新的科技，并且会主动的去接触、试用它们。他们喜欢写有架构、能够被别人重复使用的套件 （Library）。

在我们的环境中，有太多的 Coder、也有许多从 Coder 变成的 Hacker（他们的差别只在有没有目标，还有去实作的毅力），但比较少真正愿意奉献、热爱程序的 Architect。

三种软件工程师——编码员、程序师和架构师

coder vs hacker



架构师的必备技能

2016-9-22-截图 - blob_1474503395836.png

架构师的必备技能

  • 项目技能
  • 技术技能
  • 想象力技能

1.一个好的架构师首先是一个合格的工程师；
2.具有抽象的思维能力，能把业务抽象在抽象；
3.了解技术前沿知识，并深知其优劣；
4.沟通；
5.权衡取舍，能够在设计系统时综合考虑；
6.业务精良，同时具有多领域知识，因为有时候业务是相通的;

进度评估

人月 换算

<人月神话>

“测试的时间至少需要整个开发流程时间的一半”。

团队协作

外科手术队伍: 专业

  • 用好tower进行任务分配和进度管理
  • 用好版本管理工具(git)
  • 用好github,进行代码review

一个人每天200行有效代码 vs 20个人 * 150行/每天

团队文化建设

你不是一个人在战斗. 谦逊、尊重、信任-HRT(Honest,Respect,Trust)原则.

  • 团队技术分享
  • 拥抱开源社区
  • 极客与团队

<极客与团队-软件工程师的团队生存秘笈>

与人打交道

  • 架构师与研发团队
  • 关系技能: 架构师和各个业务需求方
  • 商务技能

必要的会议

  • 项目产品需求评审
  • 每日研发内部站立晨会
  • 研发内部关键模块技术评审
  • 除此之外还有一些非研发团队沟通会议

架构师必知

软件架构师应该知道的97件事（极致总结）

工具集

讲义中提到的各个工具集

用途 推荐工具 你喜欢的
版本管理 git
番茄工作法 番茄工作法
…. …

架构师的每日工作流程案例

敏捷开发总的流程如下：

  1. 需求规划和分期
  2. 需求评审
  3. 需求讲解
  4. 方案评审
  5. 每日晨会
  6. 性能测试
  7. CodeReview
  8. Demo
  9. 测试阶段
    10.线上Bug修改流程

程序员简易成长指南:学习

  • 如何更高效地学习？
    • 做一个全流程的demo,即使不理解也要做完
    • 体系化的学习。抱着厚书硬啃了一遍，突然有种豁然开朗的感觉.
    • 做笔记,画思维导图
    • 再去看一些文章
  • 带着问题学习更有效率
  • 架构师应不应该写代码？
    • 应该
    • 在代码和和其他工作之间平衡

程序员简易成长指南:职责

从菜鸟码农到架构师

  • 架构师职责
    • 在代码中第一时间发现可能存在的问题，向其他人提出警告，
    • 或是给予其他人改进的意见，
    • 必要的时候或是给其他人演示一下正确的姿势。
    • 保持大局观需要适度参与“核心模块”开发
      总的来说，架构师和程序员在某些方面上有点像产品经理和用户的关系，大部分程序员并不会主动告诉你他们想要什么、哪里需要优化，甚至自己也不知道这些。想要做出好的产品，捷径之一就是跟用户做同样的事情。

程序员简易成长指南:沟通

  • 实践：开会是个技术活吗？
    • 是
    • 大多数的会议都是在毫无意义的交流中浪费时间
    • 这并不是会议才有的问题
    • 大多数时候，沟通的核心不是你说了什么，而是你想要让对方了解什么、让他做什么。
    • 良好的沟通能在工作中显著提升效率，但很多人忽略了这个事情。

程序员简易成长指南:沟通

  • 恰到好处的进行沟通的原则
    • 确保各方对背景的理解一致，
      比如开会之前先简单通过邮件交流一下，对新加入会议的人花个30秒钟做个前情提要，或者在讨论过程中让对方说一下他的理解。
    • 去掉对方不能/不需要理解的内容，
      比如跟产品说“这个队列在高并发下因为锁的实现有问题导致CPU性能瓶颈”不如改成“我们发现了性能问题，持续10分钟了，10万用户收不到运营发的无节操广告，大概5分钟后扩容解决”。
    • 确保在对方失去注意力前尽快说出重点，
    • 不要说没有意义的内容浪费其他人的时间，
      比如”这需求做不了“或者”这里不可能出bug“，没有人想听到这些废话。

程序员简易成长指南:沟通

  • 还有更好的办法吗？
    成为技术专家/架构师之后的工作可以说是痛并快乐着，会有很多人找你咨询问题，另一方面，会有太多人找你咨询问题。
    甚至有一段时间每天的工作就是解答问题，小到工具使用中到疑难bug，大到架构设计，从早上到晚上基本都是在给各种各样的小伙伴提供咨询服务。
  • 简化到三个问题:
    • “他们要你解决什么问题？”
    • “你解决的是什么问题？“
    • ”还有更好的办法吗？“

现在第三句已经很少问到了。

程序员简易成长指南:门槛

  • 成为架构师最困难的门槛是？

    • 知易行难。架构师虽然听起来很高大上，但本质上 仍然是工程师，不是科学家，也不是忽悠人的江湖骗子。学习再多，也需要 实践落地。设计架构方案更多的是在做一些抽象和权衡：把复杂的需求抽象成简单的模型，从功能、性能、可用性、研发成本等等方面规划如何构建一个系统，这些内容需要更多的实践练习。
    • 没有实战平台。没有工作在类似平台天天需要接触架构设计的地方，而很多公司没有架构方面的工作可供练级，于是就想办法从理论上下功夫，这类人的特征非常明显：在信息不足，甚至不了解实际场景的情况下就开始做架构设计，这种所谓的架构往往理解比较肤浅，经不住推敲。
    • 需要经验和磨砺。每次招人之后我们都会做一些针对新人的架构方面的培训，课程材料基本上包括了系统架构相关的主要方面，但是学完这些材料之后就能成为独当一面的架构师了吗？并没有。相反，这仅仅是开始，新人真正做了实际生产的系统之后才算是正式入门：面对压力时才会懂得权衡，走过弯路之后才会寻找捷径。

程序员简易成长指南

从菜鸟码农到架构师

1）大部分烂代码并不是架构师的设计问题；
2）想要做出好的产品，捷径之一就是跟用户做同样的事情；
3）大多数的会议都是在毫无意义的交流中浪费时间；
4）程序员之间的差距或许比人和猴子之间的差距还大

参考书籍

人月神话
程序员的职业素养
作为公司的架构师，一直致力于如何更好的设计架构，如何优化项目架构，如何提高开发效率和质量，却很少让团队成员理解和明白，为何要这样做。下一个小目标，让团队每个人都理解设计。
程序员修炼之道：从小工到专家
代码整洁之道
代码大全
软件架构师的12项修炼
软件架构设计：程序员向架构师转型必备
程序员必读之软件架构:告诉你怎么像架构师一样思考
极客与团队
重构 改善既有代码的设计
深入理解计算机系统（原书第2版） [Computer Systems]
编程珠玑（续 修订版）

参考文章

StackOverflow讨论帖:哪本最具影响力的书，是每个程序员都应该读的 59本
物理量纲失效了-论《人月神话》
程序员简易成长指南：从菜鸟码农到架构师
秦迪，微博平台及大数据技术专家. 爱折腾，喜欢研究从内核到前端的所有方向，近几年重点关注大规模系统的架构设计和性能优化，重度代码洁癖：以code review己任，重度工具控：有现成工具的问题就用工具解决，没有工具能解决的问题就写个工具解决。业余时间喜欢偶尔换个语言写代码放松一下。
程序员如何才能晋升为优秀的高薪架构师？
<重构 改善既有代码的设计>读书笔记
软件架构师不等同于资深程序员
高质量的工程代码为什么难写
不是实现了业务需求就结束了呢，其实远没有，这其实只是写代码的开始，除了正向的逻辑实现外，任何一个点的异常的分支逻辑怎么处理才是工程化的代码中更难处理的部分，这个问题在单机式的系统中会相对还好处理，在分布式的环境会变得非常的复杂
异常分支逻辑处理好后，通常还需要增加必要的日志信息，以便在出问题时方便排查
吃掉重要的异常信息不抛出这种行为在写代码中是非常可耻的
对于高质量的工程代码而言，其实实现业务逻辑只是其中占比很小的一部分，甚至花的时间是相对最少的一部分;
好的工程代码，说难也难，说不难也不难，均体现在“工程”二字之上。除了代码之外，想想其他被冠以“工程”二字的，如：大厦、桥梁、船舶、水电站等等等等，高质量“工程”都有共性：安全、易用、可维护、美观… 综合多个维度，缺一不可。

系统设计案例

支付宝系统架构（内部架构图）

微信联系我

2016/9/22/截图 - blob_1474494141371.png

THANK YOU