有人有天赋，有人凭兴趣，有人看前景。
在人生的不同阶段里，我都喜欢做“复盘”，一方面审视过去的自己，另外一方面思索未来的方向。
选择开发语言：对一门语言掌握到通透之后，再学习其他语言才可能触类旁通。
开发平台，它包括一种编程语言、附带的平台生态及相关的技术。
    与语言平台关联的还有其技术生态以及各种技术框架的繁荣程度。
算法【动态】
数据结构【静态】
    数组 Array
    链表 Linked List
    队列 Queues
    堆栈 Stacks
    散列 Hashes
    集合 Sets
    树 Trees
    图 Graphs
    
数据存储系统有下面三类：
    SQL 关系型数据库（如：MySQL、Oracle）
    NoSQL 非关系型数据库（如：HBase、MongoDB）
    Cache 缓存（如：Redis、Memcached）
    
用好各类数据存储，那么按了解的深度需要依次知道如下几点：
    如何用？在什么场景下，用什么数据存储的什么特性？
    它们是如何工作的？
    如何优化你的使用方式？
    它们的量化指标，并能够进行量化分析？
测试思维：
    测试驱动开发（TDD）
工程规范
    代码结构
    代码风格
    
    目标：更清晰、易读的代码，一致性的风格
开发流程
    了解敏捷开发方法论
    了解团队演进形成的开发流程规范【先了解，再优化】
    
源码管理
    CVS -> SVN -> Git[至少要了解 Git，并用好它]
    
    对源码进行管理的最基本诉求有以下三点：
        并行：以支持多特性，多人的并行开发
        协作：以协调多人对同一份代码的编写
        版本：以支持不同历史的代码版本切换

做优秀的程序员，首先要有优秀的笔记本【利剑】
    职场的第一个台阶就是形成独立性：独立承担职责的能力。
    你问出什么样的问题，就可以看出你对这个问题做出了怎样的探索与思考，以及让你困惑的矛盾点在哪里。有些人就喜欢不假思索地问些 Google 都能够轻易回答的问题，形成路径依赖，虽然最终搞定了问题，但换得的评价却不会高，特别要省之戒之。
    遇到问题：先想一想，找到问题方向->查资料->写出来（一方面是梳理，一方面是让帮你解决问题的人，了解你的思路。）->询问(要点在于，态度谦卑，要节约对方时间)->总结问题和自己的思考（方便复盘和共享问题库） 

架构与实现：
    把一种想法、一个需求变成代码，这叫 “实现”
        中间有一个过程称为设计，设计中有个特别的阶段叫 “架构”：软件系统的结构与行为设计。
        实现就是围绕这种已定义的宏观结构去开发程序的过程。
        
    架构是一种结构设计，但它同时可能存在于不同的维度和层次上：
        高维度：指系统、子系统或服务之间的切分与交互结构。
        中维度：指系统、服务内部模块的切分与交互结构。
        低维度：指模块组成的代码结构、数据结构、库表结构等。
    架构师的共同点包括下面4个方面：
        确定边界：划定问题域、系统域的边界。
        切分协作：切分系统和服务，目的是建立分工与协作，并行以获得效率。
        连接交互：在切分的各部分之间建立连接交互的原则和机制。
        组装整合：把切分的各部分按预期定义的规则和方法组装整合为一体，完成系统目标。

    架构师的交付成果是一整套决策流，文档仅仅是交付载体
        选型评估；程序设计；执行效率；稳定健壮；维护运维；集成部署。
            选择一些合适的库或框架，再从中找到需要的API。
            确定了合适的选型后，需要从逻辑、控制与数据这三个方面进一步考虑程序设计：
                逻辑，即功能的业务逻辑，反映了真实业务场景流程与分支，包含大量业务领域知识。
                控制，即考虑业务逻辑的执行策略，哪些可以并行执行，哪些可以异步执行，哪些地方又必须同步等待结果并串行执行？
                数据，包括数据结构、数据状态变化和存取方式。
            开始编码实现时，你进一步要考虑代码的执行效率，需要运行多长时间？要求的最大等待响应时间能否满足？并发吞吐能力如何？运行的稳定性和各种边界条件、异常处理是否考虑到了？上线后，出现 Bug，相关的监控、日志能否帮助快速定位？是否有动态线上配置和变更能力，可以快速修复一些问题？新上线版本时，你的程序是否考虑了兼容老版本的问题等？

            最后你开发的代码是以什么形态交付？如果是提供一个程序库，则需要考虑相关的依赖复杂度和使用便利性，以及未来的升级管理。如果是提供服务，就需要考虑服务调用的管理、服务使用的统计监控，以及相关的 SLA 服务保障承诺
        熵：系统的混乱程度====架构的核心关注点“熵”，实现的核心关注点“简”
            一开始清晰整洁的架构与实现随着需求的变化而不断变得浑浊、混乱。也即系统的“熵”在不断增高。
            软件系统的“熵”有个临界值，当达到并超过临界值后，软件系统必须重写或对系统做架构升级。
        断裂带：    
            架构与实现之间存在的一条鸿沟，这是它们之间的断裂带。
            架构师如何准确地传递架构决策？而开发实施的效果又如何能与架构决策保持一致？
                定期对系统的状态做快照【定期去检视系统的状态】，而非去把握每一次大大小小的变化
                在做快照的过程中我会发现很多的细节，也许和我当初想的完全不一样
                在我发现和掌握的所有细节中，我需要做一个判断，哪些细节上的问题会是战略性的，而我有限的时间和注意力，必须放在这样的战略性细节上。
                其他大量的实现细节也许和我想的不同，但只要没有越出顶层宏观结构定义的边界即可。
                
                关注与把控边界，并确认领地中的战略要地：架构与实现的鸿沟上选择合适的地方建设桥梁，建设桥梁的地方必是战略要地。
    总结：架构是关注系统结构与行为的决策流，而实现是围绕架构的程序开发过程；架构核心关注系统的“熵”，而实现则顺应“简”；架构注重把控系统的边界与 “要塞”，而实现则去建立 “领地”；所有架构的可实现性都是等效的，但实现的成本、效率绝不会相同。
模式与框架
    框架和模式的共同点在于，它们都提供了一种问题的重用解决方案。其中，框架是代码复用，模式是设计复用。
    
    设计模式【联系武功的内功】
        每个模式都描述了一个在我们的环境中不断出现的问题，然后描述了该问题的解决方案的核心，通过这种方式，我们可以无数次地重用那些已有的成功的解决方案，无须再重复相同的工作。
    框架：
        框架就像是给程序员定制的开发脚手架。一个框架是一个可复用的设计组件，它统一定义了高层设计和接口，使得从框架构建应用程序变得非常容易。因此，框架可以算是打开“快速开发”与“代码复用”这两扇门的钥匙。
        框架会用只是第一步，原理一定要明白，不懂就要去看文档和代码，框架搞透了，设计模式的应用自然就明了了。框架的实现中大量应用了设计模式
多维与视图==机械设计的三视图引申
    UML（Unified Modeling Language）： 统一建模语言，一种涵盖软件设计开发所有阶段的模型化与可视化支持的建模语言。
    1、组成视图===理清系统功能。
        组成视图，表达了系统由哪些子系统、服务、组件部分构成。
            按功能划分，用于了解系统结构与分工
            功能单一化：每个模块负责且只负责一个功能
            功能正交化：每个功能由且仅有一个模块提供
    2、交互视图==用以分析服务间依赖，看看是否拆分错。
        交互视图，表达了系统或服务与外部系统或服务的协作关系，也即：依赖与被依赖。
            如果我们把目光聚焦在一个服务上，以其为中心的表达方式，就体现了该服务的依赖协作关系。
    3、部署视图===用以关注服务，中间件，使用端之间的网络传输，确定IO瓶颈
        部署视图，表达系统的部署结构与环境。
        
    4、流程视图
        流程视图，表达系统内部实现的功能和控制逻辑流程【UML 的序列图】。
        重点在于要把逻辑表达清楚。
        逻辑流程一般分两种：业务与控制。
            有些系统业务逻辑很复杂，而有些系统业务逻辑不复杂但请求并发很高，导致对性能、安全与稳定的要求高，所以控制逻辑就复杂了
    5、状态视图
        状态视图，表达系统内部管理了哪些状态以及状态的变迁转移路径。
代码与分类
    按代码的作用，大概都可以分为如下三类：
        功能
        控制
        运维
    1、功能
        功能代码，是实现需求的业务逻辑代码，反映真实业务场景，包含大量领域知识。
            把功能代码写好，最难的不是编码本身，而是搞清楚功能背后的需求并得到正确的理解(用户的心理诉求有可能表达错了，也有可能被理解错)。
            程序员需要对被要求开发的功能进行更深入的思考，努力去理解业务及其背后用户的真实需求，才是写好功能代码的基本能力。
            当功能实现了并非已经完成了开发，这仅仅是第一步。
    2、控制：功能代码满足了服务的功能需求，而控制代码则保障了服务的稳定可靠。
        控制代码，是控制业务功能逻辑代码执行的代码，即业务逻辑的执行策略。
        通用控制型代码由各种开源框架来提供，比如微服务架构模式下关注的控制领域，包括：通信、负载、限流、隔离、熔断、异步、并行、重试、降级。
        “服务网格（Service Mesh）” 架构模式：将控制和功能分离做到了极致，控制和功能代码甚至运行在了不同的进程中。
        
    3、运维
        运维代码，就是方便程序检测、诊断和运行时处理的代码。它们的存在，才让系统具备了真正工业级的可运维性。
        检测诊断代码的终极目标：让程序系统完成运行时的自检诊断。这是完美的理想状态，却很难在现实中完全做到。
            退而求其次，至少在系统异常时可以具备主动运行状态汇报能力，由开发和运维人员来完成诊断分析，这也是我们常见的各类系统或终端软件提供的机制。
        最常见的检测诊断性代码：日志
        运维类代码的另一种类，是方便在运行时，对系统行为进行改变的代码。通常这一类代码提供方便运维操作的 API 服务，甚至还会有专门针对运维提供的服务和应用，例如：备份与恢复数据、实时流量调度等。
        
    功能代码易变化，控制代码固复杂，运维代码偏繁琐
    优雅就是边界与距离
    
    
粗放与精益：编程的两种思路与方式 
    写得粗放，写得多
    写得精益，写得好
    
    不要盲目追求理想上的 “好与精益” ，而要通过“多与粗放”完成，通过做得多，不断尝试，快速迭代 ，最后取得到更好的结果【反馈与迭代改进在发挥关键作用】。
        核心在“迭代”，迭代的好处就是试错和反馈。
            试错，是快速找到自己根本没有意识到的错误，看一遍和做一遍差距太大
            反馈，你会在做不停做中得到反馈，并迭代 
    编程，其实一开始哪有什么完美，只有不断变得更好。
    好不是完美，好是一个过程，一个不断精益化的过程。
炫技与克制
    要真正提高代码水平，需要多读代码。就像写作，写得再多，不多读书，思维和认知水平其实是很难提高的。
        我读源码的方式是，发现这个框架实现了某个能力，我自己想不出怎么做，就会去看看别人怎么实现的。带着问题去读，可能有针对性一些
    好代码中有一种味道和品质：克制。
    炫技：炫技是指，为了展示自己的水平，人为的推高自己代码的复杂度和理解难度。（损人不利己） 
        技术人就容易倾向性地关注项目或工程中的技术含量与难点，项目中的炫技，未必能加分，还有可能导致减分，比如其维护与理解成本变高了。
        除了增加不必要的复杂性外，炫技的代码，也可能更容易出 Bug。
        见猎心喜，手上拿个锤子看到哪里都是钉子。
        炫技是因为你想表达得不一样，就像平常说话，你要故意说得引经据典去彰显自己有文化，但其实效果不一定佳，因为我们更需要的是平实、易懂的表达。炫技是因为你想表达得不一样，就像平常说话，你要故意说得引经据典去彰显自己有文化，但其实效果不一定佳，因为我们更需要的是平实、易懂的表达。
    克制：克制俗称低调有内涵。为了程序的稳定，以及可读性，人为的降低代码的复杂度和理解难度（损己利人） 
        对于新技术，即使从我知道、我了解到我熟悉、我深谙，这时也还需要克制，要等待合适的时机。
        新技术的应用，也需要等待一个合适的出击时刻，也许是应用在新的服务上，也许是下一次架构升级。
        不克制的一种形态是容易做出臆想的、通用化的假设，而且我们还会给这种假设安一个非常正当的理由：扩展性。
            扩展性很重要，但扩展性也应当来自真实的需求，而非假设将来的某天可能需要扩展，因为扩展性的反面就是带来设计抽象的复杂性以及代码量的增加。
            
        克制的编程方式：
            克制的编码，是每次写完代码，需要去反思和提炼它，代码应当是直观的，可读的，高效的。
            克制的代码，是即使站在远远的地方去看屏幕上的代码，甚至看不清代码的具体内容时，也能感受到它的结构是干净整齐的，而非 “意大利面条” 似的混乱无序。
            克制的重构，是每次看到 “坏” 代码不是立刻就动手去改，而是先标记圈定它，然后通读代码，掌握全局，重新设计，最后再等待一个合适的时机，来一气呵成地完成重构。
            
    不炫技、不追新，且恰到好处地满足需要，是一种平实、清晰、易懂的表达。
    面对新技术，基本态度希望是积极拥抱，但在实际工作中要有克制【业务要稳定，技术可以渐变，不要突变】。