Hi! I’m iroak

不知不觉，2024已经过去了1/3。本人在年初也是按照传统对今年进行了详细的规划，并留下豪言壮语。但到目前为止，似乎运转的不是很顺利（擦汗），故在此一一罗列年初计划，重新提醒自己。 希望今年可以真正地做到，言必行，行必果！ 计划总览 吉他弹唱 每日练字 读30本书 视唱练耳 风光摄影 骑行750km/徒步250km 穿搭 建立知识库，维护博客 记账，不超预算 细致解读 吉他弹唱 花了4200报课，必须赚回来，学会！！！ 每日练字 每天早上30~45min，锻炼自律能力，字能写好当然更好了XD。 读30本书 希望可以找个专题研究研究，当然，放松最重要。 视唱练耳 怎么说呢，努力吧！ 风光摄影 拿起相机，多出门逛逛。 骑行750km/徒步250km 字面意思，没啥好说，冲就完事了。 穿搭 日常进行。 建立知识库，维护博客 锻炼写作能力，多读多写多思考！博客私人看就行了，作品可以拿到社交平台上发表。 记账，不超预算 日常进行，全年预算75000。

2024 [4/23] 最后生还者-第一季

世界那么大，我想去看看

第1章 焦油坑 编程系统产品（Programming Systems Product）开发的工作量是供个人使用的、独立开发的构件程序的9倍。我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成和测试又强加了3倍的工作量，这些高成本的构件在根本上是相互独立的 编程行业"满足我们内心深处的创造渴望和愉悦所有人的共有情感"，其提供了五种乐趣： 创建事物的快乐 开发对其他人有用的东西的乐趣 将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 面对不重复的任务，不断学习的乐趣 工作在如此易于驾驭的介质上的乐趣–纯粹的思维活动–其存在、移动和运转方式完全不同于实际物体 同样，这个行业具有一些内在固有的苦恼： 将做事方式调整到追求完美是学习编程的最困难部分 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任 实际情况看起来要比这点好一些：真正的权威来自于每次任务的完成 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 人们通常期望项目在接近结束时，软件项目能收敛得快一些，然而，情况却是越接近完成，收敛得越慢 产品在完成前总面临着陈旧过时的威胁；只有实际需要时，才会用到最新的设想 第2章 人月神话 缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素的总和影响还大 良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度 所有的编程人员都是乐观主义者：“一切都将运作良好” 由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难 但是，我们的构思是有缺陷的，因此总会有bug。 围绕着成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的 在若干人员中分解任务会引发额外的沟通工作量–培训和相互沟通 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试 作为一个学科，我们缺乏数据估计 我们对自己的估计技术不确定，因此在管理和客户的压力下，我们常常缺乏坚持的勇气 Brooks法则：为进度落后的项目增加人手，只会使进度更加落后 向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通 第3章 外科手术队伍 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的生产率是较差程序员的十倍（Sackman、Erikson和Grand） Sackman、Erikson和Grand的数据显示，经验和实际表现之间没有相互联系，我怀疑这种现象是否普遍成立。 小型、精干队伍是最好的–思绪尽可能少 两个人的团队，其中一个是领导者，常常是最佳的人员使用方法（留意一下上帝对婚姻的设计） 对于真正意义上的大型系统，小型精干的队伍太慢了 实际上，绝大多数大型编程系统的经验显示，一拥而上的开发方法是高成本、速度缓慢、低效的，开发出的产品无法进行概念上的集成 一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法–既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量 第4章 贵族专制、民主政治和系统设计 “概念完整性是系统设计中最重要的考虑因素”。 “功能与理解上的复杂程度的比值才是系统设计的最终测试标准”，而不仅仅是丰富的功能。（该比值是对易用性的一种测量，由简单和复杂应用共同验证） 为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成 “对于非常大型的项目，将体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。"（同样适用于小型项目） “如果要得到系统概念上的完整性，就必须有人控制这些概念。这实际上是一种无需任何歉意的贵族专制统治。” 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性 概念上统一的系统能更快地开发和测试。 体系结构（architecture）、设计实现（implementation）、物理实现（realization）的许多工作可以并发进行。（软件和硬件设计同样可以并行） 第5章 画蛇添足 尽早交流和持续沟通能使结构师有较好的成本意识，使开发人员获得对设计的信心，并且不会混淆各自的责任分工。 结构师如何成功地影响实现： 牢记是开发人员承担创造性的实现责任；结构师只能提出建议 时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法 对上述的建议保持低调和平静 准备对所建议的改进放弃坚持 听取开发人员在体系结构上改进的建议。 第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计 OS/360是典型的画蛇添足（second-system effect）的例子。（Windows NT似乎是20世纪90年代的例子） 为功能分配一个字节和微秒的优先权值是一个很有价值的规范化方法 第6章 贯彻执行 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致 出于精确性的考虑，我们需要形式化地设计定义；同样，我们需要记叙性定义来加深理解 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施；它们都可以作为表达的标准 设计实现，包括模拟仿真，可以充当一种体系结构的定义；这种方法有一些严重的缺点 直接整合是一种强制推行软件的结构性标准的方法。（硬件上也是如此–考虑内建在ROM中的Mac WIMP接口） “如果起初至少有两种以上的实现，（体系结构）定义会更加整洁和规范。” 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。（电子邮件是现在可选的介质） “项目经理最好的朋友就是他每天要面对的对手–独立的产品测试机构/小组。” 第7章 为什么巴比伦塔会失败？ 巴比伦塔项目的失败是因为缺乏交流以及交流的结果–组织。 “因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。“由于对其他人的各种假设，团队成员之间的理解开始出现偏差 团队应该以尽可能多的方式进行相互之间的交流：非正式地进行简要技术陈述的常规项目会议，共享的正式项目工作手册（以及通过电子邮件） 项目工作手册"不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。” “项目所有的文档都必须是该（工作手册）结构的一部分。” 需要尽早和仔细地设计工作手册结构 事先制订良好结构的工作手册"可以将后来书写的文字放置在合适的章节中”，并且可以提高产品手册的质量。 “每一个团队成员应该了解所有的材料（工作手册）。"（我现在想说的是，每个团队成员应该能够看到所有材料，网页即可满足要求） 实时更新是至关重要的 工作手册的使用者应该将注意力集中在上次阅读后的变更以及关于这些变更重要性的评述上 OS/360项目工作手册开始采用的是纸介质，后来换成了微缩胶片 今天（即使在1975年），共享的电子手册是能达到所有这些目标的、更好的、更加低廉的、更加简单的机制 仍然需要用变更条和修订日期（或具备同等功能的方法）来标记文字；仍然需要后进先出（LIFO）的电子化变更小结 Parnas强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者允许看到其他部分的内部结构，只需要了解接口 Parnas的建议的确是灾难的处方。 （Parnas让我认可了该观点，是我彻底地改变了想法） 团队组织的目标是为了减少必要的交流和协作量 为了减少交流，组织结构包括了人力划分（division of labor）和限定职责范围（specialization of function 传统的树状组织结构反映了权力的结构原理–不允许双重领导 组织中的交流是网状，而不是树状结构，因此所有的特殊组织机制（往往体现成组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难 每个子项目具有两个领导角色–产品负责人，技术主管或结构师。这两个角色的职能有着很大的区别，需要不同的技能 两种角色的任意组合都可以是非常有效的： 产品负责人和技术主管是同一个人 产品负责人作为总指挥，技术主管充当其左右手 技术主管作为总指挥，产品负责人充当其左右手 着很大的区别，需要不同的技能。 第8章 胸有成竹 仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。 构建独立小型程序的数据不适用于编程系统项目。 程序开发随程序规模的大量增长而增长。 一些发表的研究报告显示指数约为1....

1. 乐音体系 音的四种性质： 高低，长短，强弱、音色。 噪音： 振动不规则，音的高低听起来不明显。 乐音体系： 音乐中所使用的基本的乐音的总和。 音级： 乐音体系中的各音（专指乐音）。 音列： 按一定的音高关系和高低次序，由低到高或由高到低排列。 半音： 乐音体系中，音高关系的最小计量单位。 全音： 半音和半音相加。 音名： C D E F G A B 也叫基本音级，一个音级到下一个的距离为“八度”，do re mi fa sol la si 这些音名多用于歌唱，故叫唱名。 变化音级： 将基本音级加以升高或降低得来的音。 升级音级： 将基本音级升高半音，如#C、#D、相反是降级音级。 重升音级： 将基本音级升高全音，如xC、xD等，反之为重降音级。 音组： 乐音体系中八十多个音用来区分音分为若干组，它的标记是用字母加数字“1”来表示。比小字一组高的各组，由低到高名为“小字二组”、“小字三组”、“小字四组”、“小字五组”。依次写上数字“2”、“3”、“4”、“5”。比小字一组低的各组，由高到低依次定名为“小字组”、“大字组”、“大字一组”、“大字二组”。小字组用小写字母，数字写在音名右上方，如c1。大字组用大写字母，数字写在音名右下方，如C1。 音域： 从低音到高音，音列的总范围。 音区： 音域中的一部分。根据音色的不同分为高音区、中音区和低音区。小字组、小字一组、小字二组被认为是中音区，小字三，小字四，五为高音区，大字组，大字一组和二组为低音区。 2. 音律 标准音： 目前国际通用的标准高度是以440Hz的小字一组的a为标准，因此a1就成了标准音。 中央C： 位于乐音体系中央的小字一组的c1。 定律法： 确定乐音体系中各音的绝对准确高度，人们在实践中创造了各种定律法。如十二平均律，五度相生律、纯律等。 十二平均律： 将一个纯八度（如c1-c2）分成十二个均等的部分。 等音： 音高相同而记法和意义不同的音。如#C、bD，xB，这三个音在钢琴上音高是完全相同的，但记法和意义不同。可以看出，除了#G和bA只有一个等音外，其他各音都有两个等音。 基音： 由全弦振动产生的音，听的最清楚的最响的音。 泛音： 由发音体各部分振动而产生，不易被听出的音。 3.调式 调式： 若干音（3-7个）按照一定的关系（高低、稳定，不稳定）联结在一起，构成一个体系，并以某一个音为中心的体系。 大调式： 简称大调，是一种由七个音构成的一种调式，其稳定音合在一起构成一个大三和弦，不稳定音以二度音程关系倾向于稳定音，构成旋律进行的基本音调。根本特征表现为主音上方的大三度。分为三种：自然大调、和声大调和旋律大调。 自然大调 和声大调 旋律大调 音阶： 调式中的音，从主音开始到主音结束，按高低次序排列起来。 等音调： 根据十二平均律所有半音相等的理论，不仅产生了等音、等音程、等和弦，还产生了等音调。就是两个调之间的所有音都是等音关系。 黑键开始的等音调： 常用的15个大调 首调： 任何一个大调的首音的唱名都为do，其他音依次类推 固定调： 音名C D E F G A B固定对应唱名do re mi fa sol la si 原调、移调、转调、离调： 4....