第四天了，我还是久久不能忘怀，fuck code。
前面的几天，我学习了SOLID原则、KISS原则、YAGNI原则、DRY原则、迪米特法则。 这些法则的共同思想是提高代码的可扩展性，稳定性，整洁性。
- S ：单一职责原则的核心就是解耦和增强内聚性(方法、接口、类)
- O ：对扩展开放，修改关闭（参数封装、方法抽象、面向接口编程）
- L ：里氏替换原则（确保派生类（子类）可以替换基类（父类）并且程序仍然能够保持正确性）
- I ：接口隔离原则（强调一个类不应该强制实现它用不到的接口。具体来说，一个类应该对它的客户端提供尽可能小的接口，而不强迫客户端依赖于它们不使用的方法。ISP主要关注接口设计，强调接口的精简和高内聚性；SRP主要关注
接口的设计，强调类的单一职责。） - D ：依赖反转原则（1. 高层模块不应该依赖于低层模块。两者都应该依赖于抽象。 抽象不应该依赖于细节。细节应该依赖于抽象。）
- KISS/YAGNI ：适当封装，抽象、不至于看一遍都不知道你要干嘛，或者写的太详细，看半天都看不完一个函数。
- DRY ：不要写重复的代码（重复代码是编程实现，代码重复性是设计特性，实际工作中应该提高代码重复性）
- DIMETER ：“高内聚”用来指导
类本身的设计，“低耦合”用来指导类与类之间依赖关系的设计（接口与抽象）
想要在互联网公司长久的工作下去，不能仅仅的停留在简单的需求执行者，需要对整个需求的周期都有了解，前期的需求沟通分析，中期的代码设计实现，后期的维护都对个人有很高的要求。
下面通过一个例子，来体会在实际需求中都需要哪些思维和能力？ 积分是一种常见的营销手段，很多产品都会通过它来促进消费、比如淘宝积分、信用卡积分、商场消费积分等等。假设你是一家类似淘宝这样的电商平台的工程师，平台暂时还没有积分系统。Leader 希望由你来负责开发这样一个系统，你会如何来做呢？
我一直以为一个功能的完成，只要产品经理给我产品设计文档（PRD）、线框图，我照着实现就可以了。哈哈哈哈，这真的是我的真实想法.技术人员应该更多地参与到产品设计中。在 Google工作的时候，我很明显能感受到，Google 工程师跟其他公司工程师有一个很大区别，那就是大部分人都具备产品思维，并不是完全的“技术控”。所以，Google 很多产品的初期设计都是工程师来完成的，在产品发展壮大到一定程度的时候，才会引入产品经理的角色。
那你可能要问了，作为技术人，我该怎么做产品设计呢？首先，一定不要自己一个人闷头想。一方面，这样做很难想全面。另一方面，从零开始设计也比较浪费时间。所以，我们要学会“借鉴”。
我们可以找几个类似的产品，比如淘宝，看看它们是如何设计积分系统的，然后借鉴到我们的产品中。你可以自己亲自用用淘宝，看看积分是怎么使用的，也可以直接百度一下“淘宝积分规则”。基于这两个输入，我们基本上就大致能摸清楚积分系统该如何设计了。除此之外，我们还要充分了解自己公司的产品，将借鉴来的东西糅合在我们自己的产品中，并做适当的微创新。
对于非业务通用框架的开发，我们在做需求分析的时候，除了功能性需求分析之外，还需要考虑框架的非功能性需求。比如，框架的易用性、性能、扩展性、容错性、通用性等。
对于复杂框架的设计的几个小技巧：画产品线框图、聚焦简单应用场景、设计实现最小原型、画系统设计图等。这些方法的目的都是为了让问题简化、具体、明确，提供一个迭代设计开发的基础，逐步推进。
今天我也收到了一个需求。在手机屏幕上显示一个横向滚动条，将几个固定图标显示出现，并且点击要跳转到对应应用。并且该滚动条只在第一屏显示，后续要消失。
首先将功能划分了一下
