|
|
|
|
|
# 用户故事 | 站在更高的视角看架构
|
|
|
|
|
|
|
|
|
|
|
|
> 你好，许式伟老师的架构课已经更新了一段时间，不少同学反馈这段时间的学习很有收获，于是我们邀请了Aaron同学来和我们做一次分享，看看他这阶段都是怎样学习课程的，又有哪些收获。今天这节课为加餐，形式和正式的课程内容不同，需要你阅读文稿来学习，好，我们开始吧。
|
|
|
|
|
|
|
|
|
|
|
|
我是 Aaron，一名 Python 软件工程师， 目前主要从事运维开发DevOps工作。
|
|
|
|
|
|
|
|
|
|
|
|
一般开发的系统是内部使用的运维系统，最近主要的工作就是将产品需要的一些功能嵌入到类似CMDB系统当中，比如SaltStack、ELK（EFK)、Zabbix 等。
|
|
|
|
|
|
|
|
|
|
|
|
目前，运维自动化的困境是运维研发资源能力的不足，底层自动化的能力可以通过IaaS公有云来解决，但是在OS之上的运维自动化都是通过一些开源工具来解决的。开源工具的引入，加大了维护的难度和复杂度，而且，很多平台的可扩展能力非常薄弱。
|
|
|
|
|
|
|
|
|
|
|
|
理解这些开源工具的内部实现原理、优缺点，了解可以改善的地方，实现项目的深层次进化，是自己的额外追求。因为这个追求，学习架构设计就很有必要，从架构的思维来看这些迭代了五六年的开源项目，可以看到开源软件开发者的迭代开发流程和思考。发上等愿，结中等缘，享下等福，运维开发在公司偏辅助业务，我希望努力学习基础架构来实现自身价值。
|
|
|
|
|
|
|
|
|
|
|
|
## 我为什么要学习架构课？
|
|
|
|
|
|
|
|
|
|
|
|
极客时间推出《许式伟的架构课》的时候 ，我正在工作时间之外学习操作系统、计算机网络等课程。看了这门课的介绍觉得挺好的，知道作者是七牛云的许式伟老师，因为自己工作方向的原因，经常会接触到关于Go语言布道师（许式伟老师）的一些介绍，对于许老师非常崇拜 ，特别是许老师多年前就预测到 Go 语言会称霸云计算这一点，我特别佩服。
|
|
|
|
|
|
|
|
|
|
|
|
另外，**我也一直希望能借助许老师的视角和高度，来看看架构这件事。**
|
|
|
|
|
|
|
|
|
|
|
|
如何将用户的需求，一步步分解为程序员要实现的功能点，并展现给用户，这是架构师的职责。设计高可用、高性能、高并发的可靠系统需要匠心，悟心，保持谦和求取的心态。架构思维并不难 ，但是成为优秀的架构师却不易。我很想知道在许老师这样的高度上，他对架构的理解是什么样的。
|
|
|
|
|
|
|
|
|
|
|
|
我也希望可以通过对专栏的学习，能在工作实践中有所成长，成为优秀的架构师。所以我购买了《许式伟的架构课》，并开始学习。
|
|
|
|
|
|
|
|
|
|
|
|
## 我是怎样学习专栏的？
|
|
|
|
|
|
|
|
|
|
|
|
我学习这个专栏没有什么特别之处，无非做到了三点：**反复学习、动手实践、留言打卡坚持。**
|
|
|
|
|
|
|
|
|
|
|
|
许老师的课程是每周二、五更新，一般情况下我都会在当天先通读一下老师的文章 ，特别好的文章会通读好几遍 ，周末的时候会再拿出来细看 。 平时上下班路上的细碎时间，也会抽空看一次 、听一次来巩固学习。
|
|
|
|
|
|
|
|
|
|
|
|
具体算下来，整个学习的过程，基本上也和别的同学分享的类似，基本可以读懂的文章，学习两到三次；不是很精通的，云里雾里的，会至少看到五六次；听一遍不够，再看一遍也不行，那就再多读几遍，查看留言，看看其他同学的留言内容，来检验自己是否理解了，问题是否完全解决了。
|
|
|
|
|
|
|
|
|
|
|
|
许老师专栏中提到的实战项目， 像JS和Golang 的项目 ，**我都要自己仔细敲一遍 ，落实到代码上**。因为如果只是浮光掠影的话 ，不会理解到精髓的。知识还是要下苦工夫才能消化。
|
|
|
|
|
|
|
|
|
|
|
|
另外，**我基本一直坚持学**。可能很多同学可以看到我在老师课程下坚持留言，因为极客时间的课程我购买了不少，有些跟了一段时间就暂时搁置了，所以我在跟许老师的架构课程之初，就定下了Flag：一定要在老师正式的课程下多留言打卡，虽然留言质量未必很高，但是至少有一种方式可以让我尽量坚持下去。
|
|
|
|
|
|
|
|
|
|
|
|
## 专栏中最有收获的文章是哪几篇？
|
|
|
|
|
|
|
|
|
|
|
|
介绍几篇我个人觉得很有收获的文章：
|
|
|
|
|
|
|
|
|
|
|
|
* 《[01 | 架构设计的宏观视角](https://time.geekbang.org/column/article/90170)》
|
|
|
|
|
|
|
|
|
|
|
|
很多开发人员对众多系统背后是如何工作的，原理一知半解 ，知其然不知其所以然，成为架构师就是成长为造房子的建筑工程师，需要宏观的全局掌握能力。
|
|
|
|
|
|
|
|
|
|
|
|
* 《[17 | 需求分析（上）](https://time.geekbang.org/column/article/100140)》和《[18 | 需求分析（下）](https://time.geekbang.org/column/article/100930)》
|
|
|
|
|
|
|
|
|
|
|
|
为什么要做需求分析呢？一是为了满足用户需求，二是满足边界的需要 ，三是架构设计的需要，防止过度设计， 把简单的事情复杂化。
|
|
|
|
|
|
|
|
|
|
|
|
如果只是被动接受产品需求，以按图索骥的方式做架构师，是不足以成为顶级架构师的，用户需求的深层理解是很难传递的。
|
|
|
|
|
|
|
|
|
|
|
|
产品设计过程需要架构师的深度参与，而不是单向的信息传递。产品是桥，一端连接用户需求 ，一端连接了先进的技术。
|
|
|
|
|
|
|
|
|
|
|
|
产品经理和架构师其实是一体两面，都需要关心用户需求和产品定义。架构师需要三分之一的精力（我目前感觉可能会更多一些）在需求分析上。
|
|
|
|
|
|
|
|
|
|
|
|
许老师介绍的这些点，都很有价值：
|
|
|
|
|
|
|
|
|
|
|
|
“心态第一，装着用户，刨根究底，找到根源需求，理清需求，对需求进行归纳整理。需求分析，用户的需求反馈到架构师那里，需要对功能进行拆解，对于部分超前的需求，分期进行实现。”
|
|
|
|
|
|
|
|
|
|
|
|
* 《[22 | 桌面程序的架构建议](https://time.geekbang.org/column/article/105356)》
|
|
|
|
|
|
|
|
|
|
|
|
老师对 MVC 的讲解，当时看完了之后感觉到醍醐灌顶，看到下面留言说 ，这一篇文章就值回“票价”，我也是同样的感受。
|
|
|
|
|
|
|
|
|
|
|
|
后面的我就不一一举例了。
|
|
|
|
|
|
|
|
|
|
|
|
## 有哪些好的学习方法？
|
|
|
|
|
|
|
|
|
|
|
|
学习的方法无非就是坚持，坚持，坚持 ！夯实基础，夯实基础，夯实基础！
|
|
|
|
|
|
|
|
|
|
|
|
去年的时候看到一位深度学习的大佬 Lan Goodfellow 的访谈， 说他人工智能本科阶段和博士早期阶段曾经多次咨询吴恩达老师寻求建议。 吴恩达建议他彻底精通这些基础知识和技能 （编程、调试、线性代数、概率论等等）， 特别是基础数学。
|
|
|
|
|
|
|
|
|
|
|
|
以前的他特别不理解这个建议，觉得这些实在是很无聊 ，他以为吴恩达能建议他去学习超实数或者类似的东西 ，实践几年后，他发现老师当时给的建议实在是太正确了。
|
|
|
|
|
|
|
|
|
|
|
|
学习没什么捷径，不存在什么一蹴而就的高超技术，要真的能稳得住啃那些基础，能沉下心坚持再坚持。
|
|
|
|
|
|
|
|
|
|
|
|
**夯实基础，坚持下去**，就几个字，做到不易，愿你我共勉。每个开发者都希望能够有银弹，架构设计的其中一种是基础架构，涉及操作系统、分布式系统、嵌入式系统、数据库、计算机网络等，这些都需要扎实的基础作为后盾。研发底层基础设施，这个是自己近期的目标。
|
|
|
|
|
|
|
|
|
|
|
|
有很多人说 ，第一份工作带给你的能力，眼界，和圈子是非常重要的，一个人的能力决定他的上限，圈子决定了他的下限。
|
|
|
|
|
|
|
|
|
|
|
|
我对毕业之后的第一份工作没有足够的重视 ，发展不佳，但是非常庆幸参加了许老师的课程， “受益终生”四个字不足以完全表达我的谢意。 希望老师的公司发展蒸蒸日上， 也祝一起在极客时间学习的我们在努力坚持之后会心想事成 ！
|
|
|
|
|
|
|
|
|
|
|
|
平时对外输出文字的机会不多 ，些许胡言，希望能够给大家抛砖引玉，谢谢大家。
|
|
|
|
|
|
|
