A
算法题我就回顾上周的吧，但是改了个写法，还是很差，这还是看了题解视频一开始的什么水平扫描法
不过怎么对比上周的，好像发现了一个bug，22ms击败了5.03%，381ms反倒击败了5.06%更慢的反而还击败得比例面还更大一些
这怎么解释？也许是最近有好多牛B的人提交了他们得题解呗？
肯定还是哪里出了问题呗，我得承认，我也并不知道我得了什么病，我好困
所以仔细看了一下题解视频，还没看完，只又听了一遍水平扫描法和看了一下视频中得代码片段（看这样子估计是python得），确实差的太多了跟自己写的，感觉是集中在两个地方：
- 如果是确定两个字符串公共前缀是空字符串，那就不用继续了，但从提交结果上来看，这个对cpu和内存影响都不大，我估计是它得test得case得范围导致的？
- 这个最关键，就是两个字符串来比较和确定前缀的时候，直接用字符逐个比较就行了，同时只在最后返回结果得时候再截取字符串，内存消耗和cpu消耗就都降下来了，内存不是特别的明显，但是比例上从所谓超越5%提升到30%，而cpu，直接进入超过80%得行列
这两个修改之后得提交结果：
这周这样其实也有点算作弊，就看从什么角度来看待这问题了，也算往前走了点吧
R
Principles behind the Agile Manifesto
We follow these principles:
_
敏捷宣言背后的原则
我们遵循以下原则
没啥可太多解释的，官网中文版behind也翻译成遵循了，觉得还不地直译…
第一条
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
我们最高的优先级是满足客户，通过提早和持续的交付有价值的软件
两点：
- satisfy/to satisfy，中文方面，可能要选一下满足，满意，也许没那么刻意吧，但是吹毛求疵一下，牛津双解上也确实分两个解释，老实说没看懂，没这个中文的写的明白，摘抄一下吧：
- to make sb pleased by doing or giving them what they want
- to provide what is wanted, needed or asked for
- early，尽早？or 提早？我想还是要慎重，所以选了提早
应该还好，反正是要早一点吧，唉，但其实这句话的着眼点更应该放在continuous上吧
第二条
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage
欢迎改变需求，即便是在开发的晚期。敏捷过程为了客户的竞争优势而利用变化
- harness ，利用，这个有道牛津双解里都没这个意思竟然，不可思议，新牛津和柯林斯里有
- 新牛津：control and make use of（natural resources），espacially to produce energy
- 柯林斯：if you harness something such as an emotion or natural source of enegy , you bring it under your control and use it
- competitive，有竞争力的
强行评论一下吧，这个其实才是敏捷方法的真谛吧，最终其实还是为客户带来价值，交付给客户价值，这才是目标，这才是结果，结合这个，就更好理解后面那个working software … is measure 这种看起来好像是把结果变手段的描述了
第三条
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
频繁的交付可以工作的软件，从几周到几个月，倾向于较短的时间尺度
字面意义挺明显的了
但我觉得，这事儿得有个限度，计划中的一个迭代，不应该低过三周，否则完成不了什么有意义的事情，还会产生很多债务；也不应该超过五周，除非对团队产能的估算已经非常非常非常准确了，而且真的有能力排除掉外界的各种乱七八糟的干扰
第四条
Business people and developers must work together daily throughout the project.
业务人员和开发者必须于项目始终每天在一起工作
那个年代没有互联网，可以理解可以理解，互联网时代…至少和产品/运营的同学打成一片吧，但是怎么能不干扰呢？我觉得还是远程办公，留出每天视频沟通的时间窗口吧
这个反正，那个原则是好的，实操还是注意点吧
第五条
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
这条是我最喜欢的
围绕被激励起来的个体来构建工程。给他们他们需要的环境和支持，并且相信他们可以把工作做好
所以为什么敏捷宣言排比句的第一个词是individual呢？估计巧了也是
第六条
The most efficient and effective method of conveying information to and within a development
team is face-to-face conversation.
最有效率的团队沟通还是面对面的交流
这个其实有点不太够，或者离开当时的那个年月这么表述就不够了，可能one-on-one，或者深度的沟通才是有效率的，而不是一群人坐在一起扯东扯西的，或者一群人坐在一起扯，必须得有一个懂得控场的主持人才行
第七条
Working software is the primary measure of progress.
这一条也是我特别喜欢的，醍醐灌顶
可以工作的软件是进度的主要度量衡
第八条
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely
敏捷的过程推进可持续的发展，赞助商、开发者还有用户都要一直保持一个稳定的节奏
第九条
Continuous attention to technical excellence
and good design enhances agility.
持续重视卓越的技术，好的设计促进灵活性
这个没啥好说的，所以说那17位同学，确实都是精于设计的工程师
第十条
Simplicity—the art of maximizing the amount
of work not done—is essential.
简洁是必要的 …
没看懂其他部分，困了
第十一条
The best architectures, requirements, and designs
emerge from self-organizing teams.
最好的架构、需求、设计是从自组织的团队中涌现出来的
第十二条
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly
定期的回顾，团队要反思如何变得更有效率，接着调整相应的行为
这个也没毛病，直面自己的问题，承认自己的不足，而不是盲目乐观，吐个槽爽一下没问题，但是上帝的归上帝，凯撒的也得归凯撒么不是…
T
收集一个钉钉小技巧
早上发现这么个玩意
主要是那把小锁，不能下载不能转发，是在群文件里面设置的
S
这周要说可以share得viewpoint不少，但是跟技术直接强相关的不算多，勉强来两个吧
技术细节需要随时的整理，归纳
- 又得重新招人，运维主管得副手，这次反正不管出于什么目的，列了一个问题清单，或者叫Q&A清单吧
- 首先最大的问题是，提问题就很难
- 一个知识点，选提问的角度也很难
- 即便是自问自答，写出一个令自己满意的答案，也不容易
- 真的能发现自己多么的无知
计划安排想落地，还是要有清晰的目标和要求
- 没完成的，都是任务本身就虚
- 完成了的，都是非常具体的目标和成果物
- 代办事项三要素没跑，但是如何让人真心认同，我还没找到套路，也许对付不同的宣贯对象，需要找不同的抓手
- 时间和人很容易拍
- 还是对成果物的描述是最难的，就好像写测试一样，断言的预期值选择其实非常重要
这周没想到这个这么水，R一节应该也算一个吧，夹叙夹议么
若有收获，就点个赞吧
0 人点赞
