随笔分类 - 2023年阅读笔记
摘要：软件架构 架构师的定位 工作实质：规划如何将系统切分为组件，并安排好组件之间的排列关系，以及组件之间互相通信的方式。 目的：更好地对组件开发、部署、运行、维护。 如果想设计一个更方便推进各项工作的系统，策略就是在设计中尽可能长时间地保留尽可能多的可选项。 开发的角度 难以开发的系统也不会健康长久。
阅读全文
摘要：组件构建原则 设计原则指导我们如何用砖块砌成房间，组件构建原则指导我们如何将房间组合成房子。 组件 组件是软件的部署单元，是完成部署的最小实体。 我本来以为这一章讲的是划分软件设计层面的抽象组件，结果真的是编译器层面的部署单元。 组件是一组二进制文件的集合，多个组件可以链接成一个独立可执行文件。可以
阅读全文
摘要：设计原则 SRP 单一职责原则 一般会被大家简单理解为：一个函数只完成一个功能。 实际上，单一职责原则是：任何一个软件模块都应该只对某一类行为者负责。 我比较喜欢记住这个解释：任何一个软件模块都应该有且只有一个被修改的原因。当一组人对一些数据有共同的责任时，那这些数据的处理适合放在同一个地方管理，如
阅读全文
摘要：随着软件周期的推移，软件修改要付出的代价会越来越大。软件架构的目标是希望以最少的人力满足构建和维护该系统的需求，延缓软件腐化的趋势。 关于对架构的误解澄清：高层的架构并不能脱离细节实现的设计。高层架构和低层设计不分你我。 从两个价值维度描述软件价值： 系统的行为。体现为程序员赶功能交付。 架构灵活性
阅读全文
摘要：提炼函数时机：当我们觉得一段大函数内某一部分代码在做的事情是同一件事，并且自成体系，不与其他掺杂时当代码展示的意图和真正想做的事情不是同一件时候，如作者提到的例子。想要高亮，代码意思为反色，这样就不容易让人误解，印证了作者前面说的：当你需要写一行注释时候，就适合重构了做法：一个以他要做什么事情来命名
阅读全文
摘要：代码的坏味道本书之中的核心之一：简单来说就是碰到什么样子的代码，你就需要警惕起来，需要进行重构了！ 本文章中主要分成三部分进行描述，第一部分为名字就是它的术语，第二部分为详解：它的描述及一些实际场景，第三部分重构：就是他的参考重构手法，但这些手法仅作为参考，有时我们可能会需要更多的手法 神秘命名详解
阅读全文
摘要：重构的挑战 延缓新功能开发 实际上，这只是一部分不理解重构真正原因的人的想法，重构是为了从长效上见到收益，一段优秀的代码能让我们开发起来更顺手，要权衡好重构与新功能的时机，比如一段很少使用的代码。就没必要对他重构 代码所有权 有时候我们经常会遇到，接口发布者与调用者不是同一个人，并且甚至可能是用户与
阅读全文
摘要：重构的定义所谓重构（refactoring）是这样一个过程：在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构。重构是一种经千锤百炼形成的有条不紊的程序整理方法，可以最大限度地减小整理过程中引入错误的概率。本质上说，重构就是在代码写好之后改进它的设计。应该重构的原因需求变化需求的变化
阅读全文
摘要：七.错误信息错误处理很重要，但如果它搞乱了代码逻辑，就是错误的做法 使用异常而非返回码 1.遇到错误时，最好抛出一个异常。调用代码很整洁，其逻辑不会被错误处理搞乱 先写Try-Catch-Finally语句 1.异常的妙处之一是，它们在程序中定义了一个范围。执行try-catch-finally语句
阅读全文
摘要：四.注释1.若编程语言足够有表达力，就不需要注释 2.注释的恰当用法是弥补我们在用代码表达意图时遭遇的失败。注释总是一种失败 3.程序员应当负责将注释保持在可维护、有关联、精确的高度，更应该把力气用在写清楚代码上，直接保证无须编写注释 4.不准确的注释要比没注释坏得多 注释不能美化糟糕的代码 用代码
阅读全文
摘要：三.函数短小，只做一件事 每个函数一个抽象层级 1.要确保函数只做一件事，函数中的语句都要在同一抽象层级上 2.自顶向下读代码：向下规则，让代码拥有自顶向下的阅读顺序，让每个函数后面都跟着下一抽象层级的函数，这样一来，在看函数列表时，就能循抽象层级向下阅读了，我把这叫做向下规则 switch语句 1
阅读全文
摘要：一.整洁代码整洁代码的一些特征 代码逻辑应该直接了当，叫缺陷难以隐藏； 尽量减少依赖关系，使之便于维护； 依据某种分层战略完善错误处理代码； 性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来； 整洁的代码只做好一件事； 有单元测试和验收测试； 有意义的命名； 尽量“少”； 两条重要原则： 尽
阅读全文
摘要：本学期精读以下三本书 《代码整洁之道》 《重构》（第二版） 《架构整洁之道》
阅读全文
