android - 架构思考 （一） 写代码前的思考

1.什么是 OOA、OOD、OOP

• 1.OOA : Object-Oriented Analysis(面向对象分析方法)
  强调用 「抽象」 站在整体的角度进行分析问题而「不过多考虑具体实现」，也就是注重整体。

• 2.OOD : Object-Oriented Design (面向对象设计)
  是对 OOA 的过渡环节及规范整理，处理各种的依赖关系，强调应该「依赖抽象」而不是具体实现。

• 3.OOP : Object Oriented Programmin(面向对象编程)
  利用封装、继承、多态使得程序达到「重用性、灵活性、扩展性」

2.怎么利用 OOA、OOD、OOP

• 1. OOA Analysis 分析什么？
     面向对象分析、分析的是对象，对象从哪里来？从需求中来
• 2. OOD Design 怎么设计？
     面向对象设计、需要将这些对象关联起来，封装成一个独立类、模块、系统
• 3. OOP Programming 抽象编程
     面向对象编程、封装、继承、多态，易维护、易扩展

简单画个图再来温习下：

OOA、OOD、OOP

• 做好需求分析，系统设计，抛弃复制粘贴，主导开发流程.
• 合理设计⾼层抽象与低层实现，减少依赖耦合
• 剥离⾼内聚可复⽤代码，从而避免需求变动⽽导致整体重构、重写。

具体干什么

3.写代码前该做些什么

想清楚是什么 => 与产品讨论反复确认 => 拆分技术点 => 优先处理业务，其次在是UI => 具体实现

• 1. 先想清楚产品到底要一个什么样的功能，这个功能对产品来说是否真的那么重要，有没有什么更能放大这个效应的做法。
• 2. 与产品讨论，理解他们通过APP想表达的需求，将它们转化成真正的需求，并画出流程图与产品反复确认。
• 3. 需求理解好了，可以先拆分调研相关技术点。先不要急着去表达这个功能实现不了，这个效果要花时间。不妨客观的分析下（反正都要实现，为什么不把它做的好点呢）
• 4. 有个大抵的了解之后，团队在一起讨论下，采用什么具体实现，谁来实现。 (务必让每个人都对代码有整体上的认识，不要各自维护自己的小模块，不利于成长，也不利于团队)
• 5. UI一般都要比业务逻辑改动的频繁，所以最好不要急着画UI，只要有个大致的UI框架就可以了。先把业务逻辑完善（网络交互， cache，点击事件，跳转）如果有盈余，可以写unit test来测试C层或者P层逻辑的正确性。没问题了再写UI实现。
• 6. 剩下的具体实现呢，如果没有现成的代码可以用，可以再拆分成几个task。先自己将tasks通过workflow串在一起，不管是流程图，还是TODO伪代码都行。再针对每个task来搜对应的解决方案。
• 7. 所有技术问题不可能是无解，只要耐心，肯定能找到解决方案。别怕麻烦，别图省事，碰到的每个问题都是你进步的阶梯。如果真不能解决，那就换个折中的解决方案嘛，沟通灰常重要的！

4.什么会增加额外的工作量和风险？

• 1.复制粘贴（不经过思考）
  复制的代码往往一些实现不理解，代码中可能隐藏着配置未能注意到，导致出了 bug 需要找很久

• 2.代码规范不好（可维护性差）
  命名规范，未写注释，写过后不知道这段代码做什么的，难以维护。

• 3.重实现，轻设计（不考虑复用和解耦）
  所有的代码都写在一个类中，忽视设计原则，不能合理的提取，导致一个类比较臃肿，后期难以理解和维护。