程序员进阶攻略笔记01-10

有人有天赋，有人凭兴趣，有人看前景。
在人生的不同阶段里，我都喜欢做“复盘”，一方面审视过去的自己，另外一方面思索未来的方向。
选择开发语言：对一门语言掌握到通透之后，再学习其他语言才可能触类旁通。
开发平台，它包括一种编程语言、附带的平台生态及相关的技术。
   与语言平台关联的还有其技术生态以及各种技术框架的繁荣程度。
算法【动态】
数据结构【静态】
   数组 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。
       见猎心喜，手上拿个锤子看到哪里都是钉子。
       炫技是因为你想表达得不一样，就像平常说话，你要故意说得引经据典去彰显自己有文化，但其实效果不一定佳，因为我们更需要的是平实、易懂的表达。炫技是因为你想表达得不一样，就像平常说话，你要故意说得引经据典去彰显自己有文化，但其实效果不一定佳，因为我们更需要的是平实、易懂的表达。
   克制：克制俗称低调有内涵。为了程序的稳定，以及可读性，人为的降低代码的复杂度和理解难度（损己利人）
       对于新技术，即使从我知道、我了解到我熟悉、我深谙，这时也还需要克制，要等待合适的时机。
       新技术的应用，也需要等待一个合适的出击时刻，也许是应用在新的服务上，也许是下一次架构升级。
       不克制的一种形态是容易做出臆想的、通用化的假设，而且我们还会给这种假设安一个非常正当的理由：扩展性。
           扩展性很重要，但扩展性也应当来自真实的需求，而非假设将来的某天可能需要扩展，因为扩展性的反面就是带来设计抽象的复杂性以及代码量的增加。

       克制的编程方式：
           克制的编码，是每次写完代码，需要去反思和提炼它，代码应当是直观的，可读的，高效的。
           克制的代码，是即使站在远远的地方去看屏幕上的代码，甚至看不清代码的具体内容时，也能感受到它的结构是干净整齐的，而非 “意大利面条” 似的混乱无序。
           克制的重构，是每次看到 “坏” 代码不是立刻就动手去改，而是先标记圈定它，然后通读代码，掌握全局，重新设计，最后再等待一个合适的时机，来一气呵成地完成重构。

   不炫技、不追新，且恰到好处地满足需要，是一种平实、清晰、易懂的表达。
   面对新技术，基本态度希望是积极拥抱，但在实际工作中要有克制【业务要稳定，技术可以渐变，不要突变】。

程序员进阶攻略笔记01-10相关推荐

程序员进阶攻略-笔记-051~061(完)
技术债务,有意或无意的选择代码既是资产也是债务技术债务:在程序设计与开发过程中,有意或无意做出的错误或不理想的技术决策,由此带来的后果,逐步累积,就像债务一样. ...
程序员进阶攻略-笔记-021~030
信息:过载与有效 "忙碌.充实而疲倦"的虚幻假象在这个信息过载的洪流中,需要的就是在这股洪流中筛选信息并建立自己中流砥柱般的 "知识磐石". ...
程序员进阶攻略-笔记-041~050
沟通之痛:如何改变沟通,越发成为一件重要的事,至少和写代码同等重要:沟通清楚了,能让我们避免一些无谓的需求,少写不少无效的代码. 需求没沟通清楚,写出来的代码,即使没 Bug 将来 ...
《程序员进阶攻略》学习笔记
整个专栏分七讲,下面总结作者感触颇深的内容. 一.征途:启程之初 1.有时选择对了合适的路,比光顾着赶路要重要得多. 2.技术的选择,都是赚取长期回报,短期的波动放在长期来看终将被抵消掉,成为时代的一 ...
程序员进阶攻略11-20笔记
三阶段进化:调试,编写与运行代码阶段一:调试代码 Debugging 逐渐降低使用Debug 功能的频率阶段二:编写代码 Coding & ...
程序员练级攻略(2018)-陈皓-笔记整理
程序员练级攻略(2018) 开篇词入门篇零基础启蒙正式入门修养篇程序员修养专业基础篇编程语 ...
《Java程序员全攻略：从小工到专家》连载八：加入什么样的公司
加入什么样的公司 "怎么样,蔡佳娃?听了这么多介绍,心里有点谱了吧?" "嗯,听师兄你这么一说,我想了想,还是优先要追求一下欧美的IT公司.追不到也没关系,至少知道自己不 ...
程序员练级攻略（2018) --左耳朵耗子
2011年,我在 CoolShell 上发表了 <程序员技术练级攻略>一文目前,我在我极客时间的专栏上更新<程序员练级攻略(2018版)>这篇文章有[入门篇].[修养篇].[ ...
高效学习程序员练级攻略
感谢内容提供者:金牛区吴迪软件开发工作室文章目录一.高效学习 1.端正学习态度 2.面对枯燥和量大的知识 3.深度,归纳和坚持实践 4.学习和阅读源码 5.源头.原理和知识地图二.程序员练级攻略 ...

程序员进阶攻略笔记01-10

程序员进阶攻略笔记01-10相关推荐

最新文章

热门文章