diff --git a/docs/_coverpage.md b/docs/_coverpage.md index 37be1e7..0640351 100644 --- a/docs/_coverpage.md +++ b/docs/_coverpage.md @@ -9,7 +9,7 @@ * [🌳 技术开发](web/README.md) * 🦠 团队管理 * 🍄 产品体系 -* [🌻 思维认知](read/lean-ux.md) +* [🌻 思维认知]() [GitHub](https://github.com/lingxyz/learning/) [Get Started](web/README.md) \ No newline at end of file diff --git a/docs/_navbar.md b/docs/_navbar.md index 365aff2..bc94004 100644 --- a/docs/_navbar.md +++ b/docs/_navbar.md @@ -19,7 +19,6 @@ * [互联网+]() * [技术工具]() * 🌻 思维认知 - * [阅读](read/lean-ux.md) * [商业]() * [管理]() * [世界格局]() diff --git a/docs/read/_sidebar.md b/docs/read/_sidebar.md deleted file mode 100644 index 2641760..0000000 --- a/docs/read/_sidebar.md +++ /dev/null @@ -1,6 +0,0 @@ - - -* 业务架构 - * [📒《精益设计》](read/lean-ux) -* 技术架构 - * [📗《架构整洁之道》](read/clean-architecture) \ No newline at end of file diff --git a/docs/read/clean-architecture.md b/docs/read/clean-architecture.md deleted file mode 100644 index de89644..0000000 --- a/docs/read/clean-architecture.md +++ /dev/null @@ -1,191 +0,0 @@ -# 📒 精读《架构整洁之道》 -> [豆瓣](https://book.douban.com/subject/6114900/) | [微信读书](https://weread.qq.com/web/reader/480322f072021a3248038c8) - -## 推荐序一 - -``` -程序员的三个层次： - - 普通程序员：能让程序跑起来，正确处理业务流程和对数据进行计算，会写代码 - - 工程师：有“洁癖”、有工匠精神、有修养的程序员。 - - 怎么做：用工程的方法来编写代码，以便让编程开发更为高效和快速。 - - 工程的方法：把编程当成一种设计，把代码模块化，让这些模块可以更容易地交互拼装和组织，让代码排列整齐 - - 解决了什么问题：使用各种各样的手段和技术不断提高代码的易读性、可扩展性、可维护性和重用性。 - - 架构师：高智商、经验足、不怕难，挑战复杂系统的问题，引领着整个行业前行。 - - 解决了什么问题：问题繁殖和进化，解决1个问题引发多个问题；问题的多少和系统的复杂度成指数型正比。 - -观点（左耳朵耗子）： -无论微观代码、宏观架构、三种编程范式、微服务架构，都在解决同一个问题：分离控制和逻辑。 - - 控制：是对程序流转的与业务逻辑无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩等） - - 逻辑：是实实在在的业务逻辑，是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度，有效地分离控制和逻辑会让你的系统得到最大的简化。 -``` - -## 推荐序二 - -``` -举例：蓝绿部署： - - 内容：用代理分离请求，A组为核心功能（程序基本不更新）、B组为外围请求（程序随业务更新） - - 核心：动静分离 - - 结合工作：冷热分离、动静分离、读写分离... - -所谓架构就是“用最小的人力成本来满足构建和维护系统需求”的设计行为。 - - 无论以前的面向对象系统和现在的分布式系统，在这一点上完全一致。 - - 架构设计思想可以穿越时空，无论在过去还是现在同样适用。 - - 从这种古老的视角看问题，往往更能摆脱细节的困扰，把握问题的核心。正如老子“治大国如烹小鲜。” - - 作者举了面向对象编程、函数式编程、分布式系统、微服务架构来论证此观点 - -如果又要保证操作原子性又要能精确还原各时刻的状态？ - - 只提供CR操作，而不提供完整的CRUD操作（就像MySQL的binlog那样）。 - - 平时只要追加操作记录即可，各时刻的状态永远通过重放之前的操作记录得出，这样就彻底避免了状态的错乱。 -``` - -## 序言 -``` -软件架构（architecture）究竟是什么？ -软件架构学关注的的一个重点是组织结构（structure） -软件项目是具有递归（recursive）和分形（fractal）特点的，最终都要由一行行的代码组成。 - - 大型软件项目往往是由小的软件组件构成的，这些软件组件又是由更小的软件组件构成的，层层堆叠，无穷无尽。 -软件开发比修建物理建筑需要更长、更专注的设计过程，软件架构师应该比建筑架构师更懂架构！ -走快的唯一方法是先走好。 -``` - -## 前言 -``` -历经多应用、多系统的构建过程，作者的领悟：软件架构的规则是相同的！ -为什么？作者的结论：软件架构规则和其他变量完全无关。软件架构规则是永恒不变的。 - - 今天的软件与过去的软件本质上仍然是一样的，仍然是顺序结构、分支结构、循环结构的组合。 - - 计算机代码没有变化，软件架构的规则也就一直保持了一致。 - - 软件架构的规则其实就是排列组合代码块的规则。由于这些代码块本质上没有变化，因此排列组合它们的规则也就不会变化。 -``` - -## 第1部分 概述 - -``` -采用好的软件架构可以大大节省软件项目构建与维护的人力成本。 -让每次变更都短小简单，易于实施，并且避免缺陷，用最小的成本，最大程度地满足功能性和灵活性的要求。 -``` - -### 第1章 设计与架构究竟是什么 - -``` -架构与设计的区别：二者没有任何区别。一丁点区别都没有！ -底层设计细节和高层架构信息是不可分割的。它们组合在一起，共同定义了整个软件系统，缺一不可。 - -软件架构的终极目标是，用最小的人力成本来满足构建和维护该系统的需求。 - -举例揭示软件开发核心特点：要想跑得快，先要跑得稳。 -扭转开发者观念，逃离过度自信。过度自信只会使得重构设计陷入和原项目一样的困局中。 - -本书主题： -要想提高自己软件架构的质量，就需要先知道什么是优秀的软件架构。 -而为了在系统构建过程中采用好的设计和架构以便减少构建成本，提高生产力，又需要先了解系统架构的各种属性与成本和生产力的关系。 -``` - -### 第2章 两个价值维度 - -``` -对于每个软件系统，我们都可以通过行为和架构两个维度来体现它的实际价值。 - -行为价值：即软件系统的行为。是最直观的价值维度。 - - 程序员的工作就是让机器按照某种指定方式运转，给系统的使用者创造或者提高利润。 -架构价值：软件系统必须保持灵活。体现在"software"的"soft"上，软件系统必须足够软，容易被修改。 - - 好的系统架构设计应该尽可能做到与“形状”无关。（形状指的是需求拼图块） - -软件研发人员应该确保自己的系统在这两个维度上的实际价值都能长时间维持在很高的状态。 -只关注其中一个维度，还是错误的维度，会导致系统的价值最终趋降为零。 - -哪个维度更重要： -系统行为，是紧急的，但是并不总是特别重要。 -系统架构，是重要的，但是并不总是特别紧急。 - -软件研发人员的坚持： -有成效的软件研发团队会迎难而上，毫不掩饰地与所有其他的系统相关方进行平等的争吵。 -平衡系统架构的重要性与功能的紧急程度这件事，是软件研发人员自己的职责，而非业务团队。 - -请记住： -如果忽视软件架构的价值，系统将会变得越来越难以维护，终会有一天，系统将会变得再也无法修改。 -如果系统变成了这个样子，说明软件开发团队没有和需求方做足够的抗争，没有完成自己应尽的职责。 -``` - -## 第2部分 从基础构件开始：编程范式 - -### 第3章 编程范式总览 - -```markdown -三大编程范式一句话总结： -- 结构化编程对`程序控制权的直接转移`进行了限制和规范。 -- 面向对象编程对`程序控制权的间接转移`进行了限制和规范。 -- 函数式编程对`程序中的赋值`进行了限制和规范。 - -编程范式的目的： -- 每个编程范式的目的都是`设置限制`。 -- 这三个编程范式分别限制了goto语句、函数指针和赋值语句的使用。 - -软件架构的三大关注重点：`功能`性、`组件`独立性以及`数据`管理。 -``` - -### 第4章 结构化编程 - -```markdown -Dijkstra在研究中发现的问题： -goto语句的某些用法会导致某个模块无法被递归拆分成更小的、可证明的单元，这会导致无法采用分解法来将大型问题进一步拆分成更小的、可证明的部分。 -- goto语句：不受限制的直接控制转移语句。 -如何避免： -goto语句的实际效果其实和更简单的分支结构if-then-else以及循环结构do-while是一致的。 -如果代码中只采用了这两类控制结构，则一定可以将程序分解成更小的、可证明的单元。 - -Bohm和Jocopini在2年前发现：人们可以用`顺序结构、分支结构、循环结构`这三种结构构造出任何程序。 -证明了：我们构建可推导模块所需要的控制结构集与构建所有程序所需的控制结构集的最小集是等同的。 -Dijkstra的证明： -- 顺序结构的正确性、分支结构的可推导性可以通过枚举法证明； -- 循环结构中，循环1次的正确性用枚举法证明，循环N次的正确性采用数学归纳法证明。 - -结构化编程的好处：功能性降解拆分。 -结构化编程范式可将模块递归降解拆分为可推导的单元。 -如将大型问题拆分为高级函数，高级函数拆分为低级函数，低级函数用结构化编程范式书写。 -通过采用这些技巧，程序员可以将大型系统设计拆分成模块和组件，而这些模块和组件最终可以拆分为更小的、可证明的函数。 - -科学证明法： -科学理论和科学定律的特点：它们可以被`证伪`，但是没有办法被证明。 - -测试： -一段程序可以由一个测试来证明其错误性，但是却不能被证明是正确的。 - -结构化编程范式促使我们先将一段程序递归降解为一系列可证明的小函数，然后再编写相关的测试来试图证明这些函数是错误的。 -如果这些测试无法证伪这些函数，那么我们就可以认为这些函数是足够正确的，进而推导整个程序是正确的。 - -结构化编程范式中最有价值的地方： -它赋予了我们创造可证伪程序单元的能力。这就是为什么现代编程语言一般不支持无限制的goto语句。 -更重要的是，这也是为什么在架构设计领域，功能性降解拆分仍然是最佳实践之一。 - -软件开发过程是由证伪驱动的，与科学研究非常相似。无论在哪个层面，从小函数到大组件，模块和服务。 -为了达到这个目的，他们需要将类似结构化编程的限制方法（后续章节）应用在更高的层面上。 -``` - -### 第5章 面向对象编程 - -### 第6章 函数式编程 - -## 第3部分 设计原则 - -``` -SOLID原则： - SRP单一职责原则：每个软件模块都有且只有一个需要被改变的理由。 - OCP开闭原则：如果软件系统想要更容易被改变，那么其设计就必须允许*新增代码*来修改系统行为，而非只能靠修改原来的代码。 - LSP里式替换原则：如果想用可替换的组件来构建软件系统，那么这些组件就必须遵守同一个约定，以便让这些组件可以相互替换。 - ISP接口隔离原则：软件设计师应该在设计中避免不必要的依赖。 - DIP依赖反转原则：实现底层细节的代码应该依赖高层策略性的代码。 -SOLID原则目的：告诉我们如何将数据和函数组织成为类，以及如何将这些类链接起来成为程序。 - T - 构建软件中层结构的主要目标：使软件可容忍被改动。使软件更容易被理解。构建可在多个软件系统中复用的组件。 - T - 中层架构：SOLID原则应该直接紧贴于具体的代码逻辑之上，这些原则是用来帮助我们定义软件架构中的组件和模块的。这些设计原则主要适用于那些进行模块级编程的程序员。 - T - 高级软件架构：组件设计原则（下一章） -``` - -### 第7章 SRP：单一职责原则 - -### 第8章 OCP：开闭原则 - -### 第9章 LSP：里氏替换原则 - -### 第10章 ISP：接口隔离原则 - -### 第11章 DIP：依赖反转原则 diff --git a/docs/read/lean-ux.md b/docs/read/lean-ux.md deleted file mode 100644 index 82a5d2c..0000000 --- a/docs/read/lean-ux.md +++ /dev/null @@ -1,119 +0,0 @@ -# 📒 精读《LeanUX》 -> [豆瓣](https://book.douban.com/subject/24896848/) | [PDF电子版](精益设计.pdf ':ignore') - -本书核心：精益思想和敏捷理念。 - -最大的感悟：参加很多敏捷培训和书籍，对于敏捷自以为很懂，其实没有真正明白。这本书却让我弄懂什么是真正的敏捷。可能就是`想法+开发+敏捷迭代=好的产品`。按需求，小团队作战；聚焦成果，杜绝浪费；持续交付。 - -## 莱斯序 -> 传统管理方法 -- 公司按照不同职能划分，各个部门有条不紊各司其职。 -- 每个部门是按照效率最大化设计：需要找到高度迭代、以客户为中心的方法。 - - 制造部门：采用传统精益思维的方式； - - IT部门：采用敏捷开发方法； - - 市场部门：客户开发法； - - 运营部门：DevOps理念； - - 设计部门：最新设计思维、交互设计和用户研究法。 - -> 事实结果 -- 各部门都运转敏捷，但整个公司却僵化迟缓。 -- 作者举例说明：上游将交付物定型后交给下游，下游发现问题或市场有所`变化`，不能及时反馈给上游做更改。 - -> 原因分析 -- `部门间缺少联系`。 -- 【补充】按职能大团队管理，不能充分激发个人潜力，团队战斗力反而很弱。往往负责人压力最大最忙，成员需要直接承担的责任和压力很少。 - -> 举例：出现问题时，如公司未能找到新的增长点时，每个部门都觉得自己高效且前瞻，拖公司后退的是其它部门。 - -原因分析： -- 错误不在设计师、工程师、管理者身上，真正的问题在于公司体制。 -- 线性组织结构，无法满足`世界不断改变`的需求； -- 各个职能上门打造成一座座封闭的筒仓，无法满足`全面合作`的需求； -- 在分析和文档上投入过量资源，争论不休，为完成交付任务不辞劳苦，无法满足持续试验才能`不断创新`的需求。 - -> 精益思想每传播到一个新领域，依靠高瞻远瞩的行业领袖，将其核心精髓用创新的方式应用于该领域。 - -> 精益创业法优势 -- 兼收并蓄，博采众长。从精益生产到设计思维，它汲取了多个领域的精华； -- 各部门形成了一系列共同的语言和概念，进而促进公司的发展； -- 不再为问题的责任归属而争执不休，也不再纠结于全公司要对哪个部门唯首是瞻； -- “从交付中走出来”。打破筒仓、协力合作。聚焦、关注、投入全公司最要紧的任务——`让客户满意`。 - -## 前言 - -> 软件行业中的“第二阶段问题” -- 软件行业中，最大的谎言就是“第二阶段”。 （*很大的概率不会进入“第二阶段”*） -- 埃里克·莱斯解决方案：如何确保最有价值的想法获得最多的资源？以`实验`为基础，对想法进行`快速迭代`并对`流程进行改良`。如此一来，“第二阶段”的概念就不复存在了。 - -> 什么是Lean UX？ -- 把精益创业法与用户体验(UX)设计结合起来，共同成长，互惠共存。 - -> Lean UX从精益创业法中吸收的三个基本原则 -- Lean UX流程中，只做必要的设计来推进团队认知。简化UX设计流程，无需进行繁重的文件交接，只进行必要的会话； -- LeanUX让大家可以透明地、跨职能进行协作，让非设计师参与到设计流程中来； -- 最重要的一点，LeanUX基于实验的模式，不再依赖明星设计师。迅速进行实验和评估，看设计是否能实现目标。设计师转变为引导者，同时承担新的职责。 - -> LeanUX 的另外两个基础 -- `设计思维`：脱离界面和设计稿，`着眼全局`，把协作、迭代、实现、移情作为`解决问题`的核心。 -- `敏捷开发理念`：软件开发聚焦短周期、定期传递价值以及持续获取认知。表现为向客户 `快速交付可用的软件 → 获取反馈 → 根据新的认知持续修改`。 - -> LeanUX 作用 -- 在敏捷环境下践行UX设计（打破产研所需设计与敏捷所需速度的僵局）； -- 设计师与真实业务和实际实现紧密贴合（把业务和技术人员拉到了白板前一起讨论）。 - -> 案例：大型制药公司聘请Jeff公司重新设计电子商务平台 -- 过程：首席设计师Jeff带领团队花了数月时间，在办公室`封闭`研究系统、用户等，规划战略模型。 -- 产出：设计了新的信息结构、全新的付款体验的`PPT`。 -- 结果：6个月后，客户的网站没有任何改变。 -- 说明：做设计是为了创造有价值的产品和服务，而不是为了撰写说明文档。市场环境变化莫测，没有时间做详细规划和事无巨细的设计。 -- 个人感悟：与敏捷中的拒绝浪费一致。 - -> 想要毕其功于一役是不可能的，必须协同合作，不断迭代。 -- 不要自以为拿出的东西“未完成”或“很丑”，就在初始设计浪费大量时间。初次尝试之后，修改在所难免。 -- `越快把想法展现出来，我们就能越快找到修改的方向`。 -- 只有高速运转、协同合作的团队才能接受迭代乃是设计的本质。 -- 决定数字系统成败的因素有很多。没有任何一环能独立解决所有问题，这是数字媒介的本性使然。`协同合作`能将工作做得更好，`不断迭代`能够创造出更好的产品。 -- 个人感悟： - - `从0到1，要迅速把产品展现出来，获取反馈，找到修改的方向，不要怕丑`； - - `从1到100，协同合作，不断迭代，不断从客户反馈获取新的认知，持续修改`。 - -## 第一部分 简介及基本原则 - -### 第1章 Lean UX:从未如此重要 - -> 产品设计与开发的简史 -- 20世纪八九十年代，设计师最初进入软件行业。使用在工业、平面、时装等实物产出的领域中的方法进行设计：由于高昂的生产成本，必须在投产之前就明确到底要做什么。 -- 遵循的设计流程没有明显变化，因为始终要面对生产环节。犯错的代价居高不下。 - -> 这一流程为何已到了该演进之时 -- 软件交付数字产品和服务给客户，并非实物。 -- 软件生产是一个持续的过程。 -- 竞争对手采取缩短生产周期的工作方式：敏捷开发、持续集成、持续部署...。且这些是免费的。目前几乎每个领域的进入壁垒都比以往任何时候要低。现有的公司暴露在未知的威胁之下。 - -> 短周期竞争优势本质：在交付产品的同时也在进行探索。 -- 能够迅速且持续地了解产品满足客户需求的程度。 -- 提升客户对产品质量的期望及其对公司响应问题和反馈速度的 -预期。 - -Lean UX在于深度地跨职能协作。 -及时获取客户反馈，并根据客户反馈调整设计方案。 - -> Lean UX有三层含义 -- 它是设计师和产品团队工作流程的变革。 -- 它也是一种让我们以谦卑的方式对待工作的文化变革。 -- 它还是一种对软件设计及开发团队进行组织和管 -理的方式。 - -### 第2章 基本原则-to be done - -Lean UX的关键原则 - -5. 原则：不要明星、权威、独行侠 -- 结合实际：设置组长的弊端。为组员摸鱼提供了舒适的温床。 -- 思考：如何在没有明星的兜底情况下，消灭问题？ - -2.2.4 指导流程的原则 - -6. 原则：实干胜于分析 -7. 原则：从交付中走出来 -- 感悟：现今行业中大多数中高级产品设计师的主要工作是为开发者提供文档和原型设计。按照Lean UX思想，产品设计的重要性降低，`想法+开发+敏捷迭代=好的产品`。产品经理得以从文档中解脱，可以将精力放在客户、商业、产品价值和信息整合上。 diff --git "a/docs/read/\347\262\276\347\233\212\350\256\276\350\256\241.pdf" "b/docs/read/\347\262\276\347\233\212\350\256\276\350\256\241.pdf" deleted file mode 100644 index aacd9a8..0000000 Binary files "a/docs/read/\347\262\276\347\233\212\350\256\276\350\256\241.pdf" and /dev/null differ