本篇我将从7个方面来谈一谈我对于项目优化的理解，并且将在后续的文章里通过不断践行记录整个项目优化的过程。
WHAT：项目优化是什么？需要达到的目标是什么？
- 项目优化是什么？
按照百度百科的解释：优化就是通过新的方式、方法或者新的技术、算法得到更优的解决方案。
那么在项目优化中我的理解是：“更优”意味着对于优化这件事应该从来是没有终点的，不必想着一步到位，阶段性的优化目标更为合理；“解决方案”意味着不仅仅是从技术层面的优化，也应该是从用户需求、产品设计、技术方案、技术实现、产品落地推广、运营跟踪反馈等等多维度的系统性的进行。
- 需要达到的目标是什么？
对于项目优化显性出来的目标无外乎就是让产品体现出更好用，更好用是一个模糊非量化的词，正所谓“不可量化，便无法优化”，在量化更好用时也许可以得到以下大方向上的目标：
对于内：优化的目标是减少后期的维护成本，提高开发效率
对于外：最基本的应该是稳定，而后才是降低用户的学习使用成本；降低操作门槛直达用户意图；统一交互体验；增强信息及视觉感官效果…
WHY：为什么做或者说要达到目标的动机是什么？
对于组织来说所有想要达成的目标也许源于较为深层次的动机：降本增效，获取更高的价值交换。
WHO：优化这件事应该由谁来做？谁定义完成？
- 谁来做？
一个项目那就必定涉及的不仅仅是单方面，从单方面带来的优化效果应该是有限的，也只能够体现单方面的微薄的效果，要体现一个复利效果那么就应该涉及产品、设计、研发、测试、运营推广等多方面的进行
- 谁定义完成？
谁都可定义完成，但又谁都不可定义完成，完成的定义最简单直接的方法就应该是从目标当中去找寻答案：检验是否有成效地达到目标即可定义是否完成。
WHEN：何时开始做？何时完成？
- 何时开始？
优化需要满足一个最根本的特征：那就是有可优化的东西，并且这个东西与我们预期在某种程度上存在不可容忍的差异，这个阶段就是优化开始的时候。
- 何时完成？
在WHAT已经提到过，优化是找寻更优的解决方案，更优意味着没有终点，那么是否这件事情就需持续下去了呢？这里个人觉得有个衡量标准，那就是优化所带来的效果价值≈所付出的成本价值，此时定义为阶段性优化完成。
WHERE：从哪里开始入手？
业务逻辑层面、产品设计层面、技术层面、其他（较为特殊，将在后文细说）
HOW MUCH：花费多少成本？
成本在不同的公司，不同的部门，不同的项目是不一样的，无法去统一界定应该花费多少，有一条比较好的衡量原则：在这个非常达尔文的时代，我们所做的几乎所有事情都是基于价值的交换，价值交换落于一个项目上来说那就是投入产出比ROI，如果投入产出比达到预期或高于预期，那么所投入的时间成本、人力成本、资源成本，甚于说机会成本都是值得的。
HOW：怎样去做？
上述WHERE提到的四个层面来说：业务逻辑、产品设计、技术层面、其他，总的来说由于经验、认知偏差所限，以及对于特定产品所实现的需求的信息质量不高、数量较少，在业务逻辑、产品设计仅仅粗略谈论。
以下言论仅出自一个程序员视角
业务逻辑层面
关于业务逻辑优化，需要产品设计人员给予足够的设计背景及设计思想，帮助或共同重新理解某个业务功能为何是这样设计的，这种看似对于技术来说非重要的东西，可以为技术方案设计提供广度思考。
以一个这样的场景为例：
一个在首页上标识为学习、学院亦或者学术的模块，采用的是信息流的模式并且加有激励机制，学习模块仅为各种方面的信息流+推荐，奖励机制是对于所有信息流的内容统一一致的奖励规则。
如若给到更多信息，技术就可以从以下方面思考：
学习-信息流
学习应该是意味着某种程度上的主动，而产品设计的是以类信息流的方式，这种类信息流本身就存在两个原罪：一是沉浸；二是被动；沉浸的大概意思就好似我在浏览整个信息流过程中好似学到了东西，因为每当我滑动时得到的都是新的数据，但当浏览完成结果是什么都没有留下，这是类信息流的原罪。那么这里叫做学习是否合理？亦或者说是否可以添加更多的标签，亦或者增强某种主动搜索+某种归并、分类的主动学习入口。标签、搜索足迹、归并、分类的信息等可以为推荐算法提供更多更精确的信息。更加精准的推荐用户想看到信息，让用户更加依赖使用才是目的。
激励机制
学习的激励机制，是否应该去考虑不同内容的信息，给予奖励的时间，奖励的数量是不同的，技术在做这个功能的时候如果产品设计人员将后续可能存在的某种需求，那技术设计就可以一步到位，当此项需求开启的时候稍加修改即可
产品设计层面
一致的操作体验与规范
逻辑跳转，UI界面表现，颜色、icon设计等
合理的引导
引导的特征应该是用户未知的, 具有重大场景改变，异于当下操作习惯需要被教育的功能，作为主线功能需要特别提醒的，满足这些特征的做引导方可合理。
……
对于这一层面理解还不深，暂不展开谈论
技术层面
优化对于技术来说有个核心前提：稳定，在稳定的前提之下总结了四个方面的大要以及部分细节，大要分别为四个阶段：开发阶段、调试测试阶段、发布阶段、上线阶段。
开发阶段
— 代码规范：google swift规范，SwiftLint使用
— 框架分层设计：基础框架层、业务基础框架层、应用层
— 交互：启动速度、页面响应速度、操作流畅度调试测试阶段
— 编译优化：如何加快编译速度
— 代码静态分析
— 内存：占用、泄漏检测等发布阶段
— 包大小优化
— 发布流程优化上线阶段
— CPU、内存监控
— 页面卡顿监控
— 电量消耗
— 崩溃日志
做技术的人往往有所谓的技术信仰，但是切记业务稳定才是真，稳定就意味着首先采用的还是原有技术的，期望的技术可以慢慢加入，那些让人兴奋，觉得写了有尿性的技术可以延后再用，最好在整个优化过程中让测试尽快介入，每一次阶段性的优化也可遵循MVP（最小可执行）原则，快速检验，快速纠差。
其他
个人认为重要，但又被常常忽略的：团队沟通。沟通的目的是告知、说服、达成共识，这是高效完成一项任务的前提。
PM 与 研发、测试
就像上文提到的“设计背景及设计思想”的交流，可以提升了某项业务功能的在技术心中存在的意义与价值，通过后期的正面反馈获得某种“参与感”，也通过负面反馈去加深一些反思。
研发与研发
沟通交流实现方式，通过他人的实现流程，方案来优化自以为最优的方案。这一点很重要，毕竟载自己熟悉的思维下做优化是有限的。
研发与测试
某些研发实现过程中发现的逻辑问题，测试很难通过自动测试或者人工测试复现出来，这样的沟通交流可以辅助测试发现更深的问题。
产品、技术与运营
产品、技术可以从运营处得到反馈，通过反馈数据加以逻辑佐证，纠正我们的认知偏差，从而回归客观需求事实。
总之：
沟通帮助我们互相了解共识
只有相互了解了，才能相互理解；相互理解了，才有可能共同高效达成目标。沟通还可帮我弱化那种根深蒂固的“越熟悉，越重视”思维，找出真正需要做的优先级
沟通可以共同作出计划
计划有三个显性的特征：阶段性目标、时间限定、大致可执行的方案，及一个隐性特征：一定是与某项事务具有相关性，计划的这些特性就是后期优化遵从的原则（也许可以采用SMART原则来订立我们的目标）
沟通就一定存在“冲突”
但这种冲突在某种程度上是积极的，是值得的。由于冲突的两个必要因素：一是被对方感知；二是存在意见或不一致，并带有某种相互作用。能让对方感知，就促成了深入交流的基础。冲突可以从不同视角、层次去思考从而产生新的想法和观念，产生创新idea（想法、观念、创新并不是凭空而来的，而是基于已有的见解和经验）。
最后贴图一张：
