有没有一个瞬间或者一个画面在脑海中不断重复，令我无法自拔？
有的！
2019-08-17 04:05 可能太过于耀眼让我闭不上眼。
可是可触及的都不美丽，美丽的不可触及。
我的窗户上满是灰尘，太阳光透过窗户斜照入我的房间，照到我正在睡觉的椅子上。终于在下午快到饭点时，我被热醒了。
楼上的空调掉下来几滴水，真希望它们能飘到我的窗户上，把那些灰尘冲洗掉。
仅仅不到5分钟，太阳就 被对面的几栋高楼挡住了，温度冷却了下来。
推翻天平
G1（garbage first）：侧重点在于处理垃圾最多的区间（垃圾优先）。
并行和并发：二者均可表示多个人物一起执行，但偏重点有些不同。并发偏重于多个任务交替执行，而多个任务之间有可能还是串行的。并行是真正意义上的“同时执行”
我的脑子呀，经常会联想出一些乱七八糟但却有那么一滴点关联的的事情。
已经在新租的房子里住了两个晚上了。写到这里会想起来帆场英一换过的27个住处，无一例外的都是破破烂烂的旧房子。这个销毁了所有个人痕迹的人，却唯独留下这个看似无用的搬家记录。而追随这些记录所看到的场景，就如同浏览记录城市变迁的纪录片一样，看到城市高速发展的同时，也看到了那些陌生但却亲切的事物在眼前销毁。
理想乡，梦想乡，乐园。这三个词看似接近，但且有感觉相差甚远。我想找一个词来描述一种场景，明明第一次来，但眼前景象却如此熟悉但地方。人是否能选择保留何种记忆，是否可以选择删除何种记忆，是否可以拼凑何种记忆。这个“熟悉的陌生地（或人）”，可能就是记忆中的一些碎片拼凑出来的结果吧（而这些碎片，就是记忆中美好的，很难忘却的点点滴滴）。这个记忆中的由个人潜意识不自觉制造出的“熟悉的陌生地”，似乎可以被称为“幻想乡”，最近特别喜欢“乐园”这个词，但这里还是用“幻想乡”来称呼他吧。
此次抉择，孤注一掷！
冲刺：Scrum在最长一个月的迭代或者周期中安排工作，这些迭代或者周期称为“冲刺”。
关键特性：
冲刺是在时间盒内完成的。 持续时间 短并且长度一致。 冲刺开始后就不能再改变目标。 必须达到团队的完成定义中要求的最终状态。 概述 时间限定（优点） 时间盒：每个冲刺都发生在一定的时间期限之内，有明确的开始日期和结束日期，称为一个时间盒。
设定WIP数量限制
WIP：表示已经开始但尚未结束的工作清单。
强制排列优先级顺序
可以将注意力集中在快速完成有价值的事情。
展示进度
在冲刺结束之前，通过完成验证重要的工作，时间盒可以帮助展示相关进度。
避免不必要的完美主义
强制结束可能无休止的工作。避免花费时间把事情做得“不必要的完美”。
促进结束
确定的时间节点可以激发团队成员全力以赴按时完成工作。
增强可预测性
预测在下一个短冲刺中能够完成的工作是完全可以做到的。
持续期短（的冲刺的好处） 容易规划
持续期短的冲刺更容易规划。
反馈快
投入产出比高
错误有限
有助于“满血复活”
检查点多
一致的持续期 有节奏感
简化规划活动
锁定冲刺目标 冲刺目标
共同承诺
是变更，还是澄清？
变更引起的后果
注重失效
异常终止
完成的定义 什么是完成的定义？
下班回酒店的路上想到了“海浦新生地”。
特车二课，一边钓鱼养鸡种番茄，一边要修理被打成破烂的98，想起真人版电影里升为班长的阿繁带领一帮维修班如丧尸版加班加点维修的场景。
“真是悠闲，番茄园、鸡笼，整备班全部都去钓鱼了，这里的人真的是警察么？” “与其说是警察，不如说是正义的使者。” --《机动警察 - 东京毁灭战》 这群看似毫无希望的年轻人，看似混混沌沌的年轻人，却是在城市最危险时仍在坚持的人。
“只要有台风做挡箭牌的话，我想那就没有所谓的责任问题了。 毕竟都是台风造成的嘛。” “当然了！只要是天灾，那就没有办法了。” --《机动警察 - 东京毁灭战》 当后藤用“台风”来质问部长，部长承认“想用台风推卸掉全部责任”后，唯一还愿意坚持拯救城市的，只有这群无所事事的年轻人，这群被称为“社会蛀虫”的年轻人。
2019年7月1日，我离职了，各种原因，个人原因，家里的原因，公司的原因。是什么原因根本无所谓，重要的是事实，我离职了，早上提交了辞呈，心情放松了好多。这一年来，越来越压抑的心情终于放轻松了下来。
对于什么外在的成绩，老板喜欢看什么根本无所谓，更在意自己做得东西实实在在是什么。因此今天早上心情真是舒畅。
实实在在的东西只有时间会证明。
前几天买了一本《Scrum精髓-敏捷转型指南》，今天看了第三章“敏捷原则”，虽然还没看完，目前看到的内容部分，不止一次感觉这些原则好几处围绕着“承认不足，并寻找应对措施”的想法在阐述。还没有看完这章节，也不知道这种理解是不是偏离书中想要表达的意思，但我是非常认同“承认不足，并寻找应对措施”这一点的。不要老觉得什么都简单，再简单的事情，当真正发生时，总会有它的难点。至少抱着这样的想法去对待问题的态度是必要的，因为我是一名软件开发人员。
以前有人问我“怎么懂那么多，想要做到那么多”，我的回答是“人的精力是有限的”。人的精力是有限的，挑几件事做好就已经非常了不起了。但决定了做一件事，还是要尽力做好。现在我想加一句，放弃一件事时，也要足够坚持“去放弃”！
可变形和不确定性 积极参用有帮助的可变性
采用迭代和增量开发
迭代开发：承认我们在把事情做对之前有可能做错，把事情做好之前有可能做坏。本身是一个有计划的修改策略。
增量开发：先构建部分，再构建整体。
Scrum 并不是每次做一个阶段的工作，而是每次做一个特性的工作。
通过检视、调整和透明来利用可变形
Scrum的核心原则是检视、调整和透明性。
维度 计划驱动 Scrum 过程定义的程度 一套明确定义的顺序 复杂过程无事时先制定的完整规则 产出物的随即程度 产出物可变形很小或者不存在 预计有变化，因为我们不是重复构建相同的东西 利用的反馈的数量 很少、很晚 频繁、尽早 Scrum依赖于透明性：参与创建产品的每一个人都有必要能够得到与WIP相关的所有重要信息。
信息透明 –> 检视 –> 调整
减少各种各样的不确定因素
结果不确定性（不确定做什么）：围绕最终产品特性的不确定性。 方法不确定性（不确定怎么做）：围绕产品的开发过程和技术的不确定性。 此外还包含客户的不确定性（不确定用户是谁）。
预测和适应 不到最后时刻，不轻易做决定
“最后责任时刻”原则（Last Responsible Moment，LRM）：不该单单因为通用过程要求此事作出决定，就做出不成熟的决定。而是“不轻易做决定”。推迟做出承诺，直到最后责任时刻再作出重要的、不可逆转的决定。
大多数人都倾向于等有更多信息之后再做出更明智的决定。
Scrum：一个用于组织和管理工作的框架。
Scrum框架 {产品负责人}---->[产品列表] | -------------------------------------------- 冲刺 [产品列表的一项]-->冲刺规划-->[冲刺列表] {产品负责人} 每日例会 {ScrumMaster} 冲刺评审 {开发团队} 冲刺回顾 --------------------------------------------- | [潜在可交付产品增量] 3个角色 产品负责人
敲定要开发什么，以什么顺序开发。
是产品列表（Product Backlog）的唯一负责人。
PBI：产品列表名目（Product Backlog Item）
敏捷教练（ScrumMaster）
在通用的Scrum框架上建立并遵循自己的过程。
开发团队
确定如何交付 产品负责人要求 的 产品，负责产品的*设计*、*构建*、测试
3个工件 产品列表（pruduct backlog）
产品待办列表，可能包含*新特性*、对*现有特性的变更*、*需要修复的缺陷*及*技术改进点*。按优先级排列的列表。
梳理：建立和优化产品列表，估算并确定他们的优先顺序的活动。
冲刺列表（sprint backlog）
将需求完成的特性分解为一组任务，这组任务及相关对PBI（产品列表名目）组成第二个列表，称为“冲刺列表”； Sprint待办列表，指Sprint任务清单。
可持续的节奏：开发团队能够轻松、长时间保持的工作节奏。
潜在的可交付产品增量
5个事件 Sprint（Sprint本身为一个事件，包含其他4个事件）
工作在不超过一个月的迭代或循环中进行，这个迭代或者循环称为冲刺（Sprint） 。
冲刺规划、Sprint计划会议（Sprint Planning Meeting）
根据产品列表 制定出 冲刺列表（Sprint Backlog） 。
每日会议（Daily Scrum Meeting）
博客github地址
作者gtihub地址
2019年6月30日
偶然发现静态网站生成器Hugo，尝试之后发现非常好用。 之前用过hexo，但由于不习惯，博客也没有再进行过更新。
目前已经把替换为Hugo，整理的笔记将逐步整理迁移到该博客中。
系统功能相关 1.平台系统功能封闭
所有直接与外部系统交互的操作，不得在平台系统中出现，均通过接口服务进行交互。并且这平台系统仅允许系统通用功能和性能进行开发升级，不允许出现对定制需求的开发升级。所有定制需求均只能出现在接口服务中实现。 2.暴力搜索禁止
避免暴力搜索操作，在保证数据最终统计结果准确的前提下，允许用实时统计数量的准确性换取性能的提升。 3.“重跑”功能
尽量单独设计重跑流程，避免异常数据在初次使用时异常触发重跑后，在重跑时继续异常。 4.异常流程及失败流程处理
缩小try catch的范围，尽可能方便定位问题。 出现“非正常”（包括判断分支的“非正常”以及抛出的异常）问题时，需要详细打印异常数据信息。 配置文件相关 1.读取配置文件配置项的功能
“选项类”配置需要设计默认配置值，必要时需要在系统启动日志中打印是否使用了系统默认配置值。 代码规范相关 1.自定义常量
代码中所有需要使用常量的地方，均需要设计编写对应的常量类（可以使用接口类），或者枚举类型，不允许直接使用整形或者字符串值。直接使用整形或者字符串值，严重影响代码的可维护性。 2.常量命名
以简介明确为原则，禁止使用flag这类看似为类型名称，但却没有任何实际含义的名词命名。 3.POJO类设计
需要重写toString()方法，避免打印POJO类对象信息时打印出对象内存地址（实际上是该对象内存地址经哈希算法得出的int类型的值在转换成十六进制），造成日志中出现无效信息。 数据库操作相关 缓存数据 1.禁止自定义Redis KEY值
所有Redis操作，key的取值均必须调用设计专用的"KEY管理类"，提供Key的查询方法或常量，不要出现直接在代码中出现直接使用自定义字符串的形式作为key来操作Redis。 2.Redis数据失效处理
如果数据库表数据在Redis中存在相应数据，则需要设计相应的更新生效机制（或者数据失效机制）。在增删（改）接口中设置删除Redis中的对应的数据，或者设置更新标识，避免接口中对Redis进行数据更新。应将“数据自动加载”操作设计在使用该数据的服务中执行，尽量减少服务之间的耦合，降低接口服务的维护难度 持久化数据 1.强制数据库接口操作
所有数据库表设计时，均需要设计完整的增删（改）查接口功能，应避免运维过程中直接修改数据库数据。 2.数据库操作时间记录
对于频繁更新数据的表，字段中必须包含创建时间、更新时间两个字段