前言：《不止代码》是阿里首部技术经验精选集，涵盖了许多技术大牛对职业发展的看法，文笔简洁大方，通俗易懂，刚看前两章我就被深深吸引住了，是本值得推荐的书籍，适合碎片化时间阅读。书籍只有一百来页，却不建议一口气读完，最好读完每一章能有自己的思考感悟，再往下读。
- Do more ：做的更多，做的比你主管安排给你的任务更多，试图在团队中脱颖而出。
- Do better：知道这个世界上没有完美的东西，你负责的系统和业务，总有不合理和可以改进的地方，这些"不合理"和"可改进"的地方，尝试向领导提出自己的方案，并付出实践。
tips：以上两点在工作中要怎么做到呢？1. 对公司/项目产生归属感！当成是自己的伟大事业。2. 寄托于自己良好的职业精神。
- I hear and I forget. I see and I remember. I do and I understand. 实践出真知。
- 学习的方法论：learning（原理、底层知识阅读书籍，框架、组件阅读文档） ，trying（根据书上的知识写 Demo 练习，实践出真知） ，teaching（把知识归纳总结成文档）
- 假如碰到一个问题，身边的同事解决了，而我解决不了。那么我就去想这个问题他是怎么解决的，他看到这个问题后的逻辑和思考是怎么样的？有哪些知识指导了他这么逻辑推理，这些知识哪些是我也知道但是我没有想到这么去运用推理的；这些知识中又有哪些是我不知道的。
- 知识 + 逻辑就基本等于你的能力。知识让你知道那个东西；逻辑让你把东西和问题联系起来，这里的问题可以理解成方案、架构、设计等。
- 软件系统的价值是以解决业务问题的能力、支撑业务增长的能力为衡量标准，不是软件系统用了多么牛逼的技术。所以，架构的目标是为了支撑业务增长，提升软件系统的服务能力，必须认清系统背后的业务价值，而不是一味的追求技术的理想化。
- 不要因为自己是开发人员就不去关注软件运维，不要因为只是测试就不关注软件开发，因为你关注的越多你越能看清全局的价值目标。如果只关注一亩三分地，那么注定这辈子只能困守在这一亩三分地里，成为一名流水线上焦虑至死的码农。试着转变思维，从架构师的角度思考价值问题，看看能否将技术贯穿到业务、到用户、到最终的价值去。
- 有趣的是互联网将我们连接至广袤的世界，却也把我们封闭在独属于自己的小世界里。
tips：曾经的毕业的我们是多么朝气勃发，富有想法，不要因为迷信技术，从而困死在自己的世界里。
-
团队在招人上有一个对比的标杆，就是你招的人是不是比团队中同一等级中50%的同学优秀，如果你觉得没有他们优秀，那不用纠结，这个候选人不要了，团队必须不停加入更好的同学，才能变得更加优秀。
-
不要在面试中试图证明别人不如自己。
-
架构是不断演进的，等到真的需要这么高可用的时候我们再来重构系统，记住：不要过早优化，过早优化是万恶之源 —— 《UNIX编程哲学》
-
分工是工业革命以来社会高效协作的主要推动力，以后很长一段时间应该也会维持这种形态。
-
软件领域和硬件领域最大的不同就是软件领域没有绝对的工业标准，大家都很尽兴，想怎么玩怎么玩。
-
You are the owner of your career.你是你职业发展的责任人。
-
我们要做的事，就是永远不重复劳动，当你觉得现在的工作，越来越舒适，越来越缺少风险的时候，就应该引起警惕了。
-
从无到有的是架构；从表到里的是抽象；从粗到细的是设计。
-
微软对架构师有一个分类：
- 企业架构师 EA(Enterprise Architect)
- 基础结构架构师 IA(Infrastructure Architect)
- 特定技术架构 TSA(Technology-Specific Architect)
- 解决方案架构师 SA (Solution Architect)
-
“兼职架构师”：在小团队或者项目中承担非明确的架构师职责；做项目或者产品的关键设计和实施；负责产品基础设施；引入新的理念、框架；解决团队中的复杂问题。但是只有小部分时间承担了架构师的角色，绝大部分时间在做开发、PM的工作。并且做的绝大部分事情是自己可控的，自己做架构，自己做实施，或者在小团队中推行。（偏向于 SA 类型的架构师）
-
“专职架构师”：不负责具体的业务系统，而又对所有的系统负责， 很少直接负责项目，却必须对项目有提前把控，面对的是更大的团队，更大的问题域。（偏向于 IA、TSA 类型的架构师）
- 做好全局的技术规划
- 统一的方法、规范、机制
- 完备的基础组件构建
- 架构落地实施
-
架构师面对的客户是团队的每一个成员，必须始终保持客户第一的心态。架构师存在的目的是成就研发团队每一个同学，我们提供必要的平台、服务和空间，然后彼此成就。