再简单的事情也要全力以赴的去做
有些事情我以为比较简单,几下能做完,其实真正开始做时,才发现遇到了各种各样的问题,狮子搏兔,当用全力,就是这个道理。
职业发展就是个眼界不断提高的过程,不管什么行业都是如此。
如何开阔自己的眼界呢?
读万卷书,行万里路,多见不同的人,多经历不同的事。
多阅读好代码
分辨出来哪些是好代码,哪些是不好的代码?
能够识别出代码的坏味道
简洁 优雅 高效
可读性
高内聚低耦合,代码复用性才好
可扩展性
现在github上好代码这么多,值得自己学习。
像刚哥说的,多去了解下和自己工作相关的事情.
做前端的,多去了解下后端是如何响应请求的
做后端的,多去了解下前端是如何展示数据的
了解下数据库是如何应对我的场景请求的,是如何设计的?
自己写的程序,在测试人员手中是如何测试的?
在运维手中,是如何部署的?线上生产环境是如何动态升级的?
配置文件是如何配置的?
精深
掌握技术细节
语言细节
类库细节
算法细节
运行环境细节
精明(非技术层次)
准确的理解需求
评估工作量
判断任务优先级
向更优秀的人学习,code review
学习更优秀的代码
当业务越来越复杂时,将会超过个人的能力,个人能够实现的软件复杂度是有上限,所以需要将业务分为多个模块,团队中的每个成员负责各自的模块开发和维护,大家分工合作。
架构师的眼界
scalability
人的scalability
量的scalability
考虑程序对性能稳定性的影响
Be A Architect
理解业务需求
解决宏观问题
提炼通用组件
设计协作方式
一、取舍
需求和资源
时延和吞吐量
什么是当前业务最需要的?在线系统优先保证延迟稳定性,离线系统有限保证吞吐量
二、前瞻性
架构的调整周期较长,不合适的代码做重构,如何来做。
未来访问量增长,如并发连接数增长,qps增长
新业务
四、抽象
1.避免过早陷入细节
2.分层,将各个组件的角色定义下来,然后分块来思考。
3.复用
五、容错
架构师碰到的问题比程序员负责的问题要复杂的多
设计错误处理解决方案
数据丢失,备份方案
如果出现故障,如何去恢复,尽量不修只换。
要不要用容器来做云平台?业务上有前瞻性的判断
多想优秀的架构师学习,总结出来新思路。
多看书,扩宽自己的思路
架构师是个好的程序员
架构师要解决的问题:
更大的软件规模
更不可靠的底层环境
更不确定的需求变化
CTO
用什么技术来实现业务->用什么技术来发展业务
google的分布式论文,亚马逊发布了aws云计算
16年发布了人工智能,人工智能和大数据会对人的生活产生什么样的影响。
自然语言处理
机器学习
大数据
云平台
个性化推荐
知识图谱
等等
CTO要写代码,保持创造力,奋斗在一线,理解兄弟们的辛苦
优化,持续不断的去优化。
优化产出,加人,做培训?
平时学习积累的知识都是独立的,静态的。如何把静态的知识转化为动态的架构设计能力呢?多看其他公司的成功案例,自己多思考。
每个技术人员都有第一曲线,当第一曲线发展到极致后,要创造性破坏的开启第二曲线,何时开启第二曲线呢?对程序员来说,就是在熟悉的领域,能够完成整个模块的编写,以及单元测试。第二曲线可能是架构师,可能是项目经理等,因个人而异。
架构师的本质是降门提效,否则就是耍流氓。
对于不熟悉的领域,多去参加大会能有效吸取成熟大公司的经验,结合公司具体场景进行实践。