Algorithm
343. 整数拆分
给定一个正整数 n,将其拆分为至少两个正整数的和,并使这些整数的乘积最大化。 返回你可以获得的最大乘积。
示例 1:
输入: 2 输出: 1 解释: 2 = 1 + 1, 1 × 1 = 1。
示例 2:
输入: 10 输出: 36 解释: 10 = 3 + 3 + 4, 3 × 3 × 4 = 36。
说明: 你可以假设 n 不小于 2 且不大于 58。
解决方案如下:
import static java.lang.Math.pow;
public class IntegerBreak {
    public int integerBreak(int n) {
        if (n == 2 || n == 3) {
            return n - 1;
        }
        if (n == 4) {
            return 4;
        }
        if (n % 3 == 2){
            return (int)pow(3, (n / 3)) * 2;
        }
        return (int)pow(3, (n / 3) - 1) * (3 + (n % 3));
    }
}
Review
《Software Development Waste》 一文对软件开发中的浪费进行了调研和归类,大致分为九大类:
- 构建错误的功能或产品(building the wrong feature or product)
 - 任务列表管理不善(mismanaging the backlog)
 - 返工(rework)
 - 不必要的复杂解决方案(unnecessarily complex solutions)
 - 无关的认知负担(extraneous cognitive load)
 - 心理困扰(psychological distress)
 - 等待/多任务处理(waiting/multitasking)
 - 知识丢失(knowledge loss)
 - 无效沟通(ineffective communication)
 
软件开发是一项复杂的社会技术活动,涉及不同的学科和技能之间的协调。 在整个软件开发过程中,为浪费提供了充足的机会,浪费就像发生在开发过程中的摩擦。消除浪费的难度在于如何去识别浪费。
丰田生产浪费的定义:
| 浪费类型 | 描述 | 
|---|---|
| 库存 | 在需要之前存储材料的成本。材料可能永远不会被使用 | 
| 额外处理 | 生产过程中下游步骤不需要的处理成本 (有时候因为没有看到整个过程而效率低下) | 
| 生产过剩 | 生产比现在需要更多的部件成本。 | 
| 运输(货物) | 不必要地将物料从一个地方移动到另一个地方的成本 | 
| 等待 | 等待上一个上游步骤完成的成本 | 
| 动作(人) | 不必要地拾起和放下东西的成本。 | 
| 缺陷 | 质量缺陷造成的返工成本。 | 
| 价值 | 生产不符合客户需求的商品和服务的成本。 | 
| 未利用的人才 | 未利用的员工的创造力和天赋的成本。 | 
生产浪费和软件研发浪费对比:
| 丰田生产中的浪费 | 精益软件开发中的浪费 | 
|---|---|
| 库存 | 部分完成工作 | 
| 额外处理 | 重新学习 | 
| 生产过剩 | 额外的特性 | 
| 运输(货物) | 移交 | 
| 等待 | 延迟 | 
| 动作(人) | 工作切换 | 
| 缺陷 | 缺陷 | 
| 价值 | N/A | 
| 未利用的人才 | N/A | 
构建错误的功能或产品
描述
构建无法满足用户或业务需求的功能或产品的成本。
观察到的原因
- 用户需求(不进行用户研究,验证或测试;忽视用户反馈;处理低用户价值特性)
 - 业务需求(不涉及业务利益相关者;利益相关者反馈缓慢;产品优先级不明确)
 
任务列表管理不善
描述
重复工作的成本,加快低价值用户功能或延迟必要的错误修复。
观察到的原因
- 任务列表倒置
 - 同时处理太多功能
 - 重复的工作
 - 没有足够的待开发故事
 - 特性工作和bug修复不平衡
 - 延迟测试或关键bug修复
 - 反复无常的插入(thrashing)
 
返工
描述
改正错误的交付工作回归正确的成本。
观察到的原因
- 技术债务
 - 被拒绝的故事(例如产品经理拒绝故事实施)
 - 没有明确的完成定义(模棱两可的故事;设计的二次揣测)
 - 缺陷(测试策略不佳;缺少错误根因分析)
 
不必要的复杂解决方案
描述
创建比其本质更为复杂的解决方案的成本,错过了简化功能,用户界面或代码的机会。
观察到的原因
- 从用户的角度来看,不必要的功能复杂性
 - 不必要的技术复杂性(重复代码,缺乏交互设计重用,前期创建的过于复杂的技术设计)
 
无关的认知负担
描述
不必要的脑力消耗的成本。
观察到的原因
- 遭受技术债务
 - 复杂或大型故事
 - 无效的工具和有问题的API,库和框架
 - 不必要的上下文切换
 - 无效的开发流程
 - 代码组织不良
 
心理困扰
描述
给团队带来无助压力的代价。
观察到的原因
- 团队士气低落
 - 混乱模式
 - 人际关系或团队冲突
 
等待/多任务处理
描述
空闲时间的成本,通常由多任务隐藏。
观察到的原因
- 缓慢的测试或不可靠的测试
 - 不可靠的验收环境
 - 缺少信息,人员或设备
 - 源自反馈延迟的上下文切换
 
知识丢失
描述
重新获取团队曾经知道的信息的成本。
观察到的原因
- 团队流失
 - 知识孤岛
 
无效沟通
描述
不完整,不正确,误导,无效或缺失沟通的成本。
观察到的原因
- 团队规模太大
 - 异步通信(分布式团队;分布式利益相关者;依赖于另一个团队;团队之外不透明流程)
 - 不平衡(把持谈话;没有倾听)
 - 无效的会议(缺乏关注;跳过回顾;每天都未讨论阻碍者;会议匆匆结束(例如长时间站立))
 
Tip
放几个实用的小技巧(长时间不用的话可能会忘记):
- 在 macOS Sierra,可以使用快捷键⌘⇧.(Command + Shift + .) 来快速(在 Finder 中)显示和隐藏隐藏文件了。
 - 在Chrome中安装Vimium插件,可以实用vi命令来控制Chrome,其中最重要的命名就是“?”,通过该命令可以学习各种其他命令。类似于vs code中的命令面板(cmd + shift + P)。
 
Share
最近同事要做一个领导力的系列培训,从而引发了大家一系列的探讨,话题从领导力到共创教练。下面是领导力的一些内容:
领导力是一种影响力,既不能太强,也不能太弱。人们对领导力有太多的误解。当他们听到某人有令人印象深刻的职衔或者被指派到某一领导岗位时,就认为此人是一个领导者。有时确实如此,但职衔对于领导工作本身并没有太大的价值。真正的领导力不是授予、任命或者指派的。它仅仅来自于影响力,不能强求,必须通过努力才能获得。
关于领导力的三个阶段:
- leading yourself
 - leading others
 - leading everthing
 
对于这些课程要心存敬畏,就算是改变自己也是一件影响深远的事情。可能会对你的生活产生各种影响,而这些影响可能是“好”的也可能是“坏”的。比如:寻找自己可能会让你产生改变现状的迫切冲动,这可能与你目前的现状格格不入,最终导致激烈的冲突(人际关系、婚姻、职业等)。所以说你只是想了解,还是说已经准备好迎接它们了?
- 版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 3.0 许可协议。转载请注明出处!