#ABOUT INNOVATION#
创新并不是人人都喜欢的，无论是出于对已有模式的适应，还是利益的考量，创新并没有像我们想象的那样“热门”，从很多例子上看，当如今我们所见到的很多发明和创新，在其被推广时都遇到了层层阻碍。这本书提到了一些当我们有创新的想法的时候该考虑的事情。首先是对利益相关人讲清楚“你能从中得到什么”，也就是所谓的“What's In It For Me?”,第二是创新的想法和目前流行的做法相比，有什么相对优势，能让别人清楚地看到这个区别。再者是创新和目前大众习惯，已有系统的兼容问题，最后要避免过度描述复杂的技术。
创新并不一定是“全新”的，事实上，大部分成功的创新者都不是先行者，先行者和后来的领导者往往不同。
有趣地是，百分之70的创新者说，他们最成功的创新，是在他们的拿手领域之外发现的，并且，有时候，技术可能不是创新的关键，我们在考虑创新一个东西，要考虑其受众，不仅是技术的创新，还有商业模式的创新、用户体验的创新、生态系统的创新（苹果做的比较好）。科研并不等于创新。杰弗里·尼科尔森认为“科研是将金钱转换为知识的过程”，而“创新则是将知识转换为金钱的过程”。“功能的增加”也不等于“技术的创新”，我们需要考虑功能的整合，也要考虑用户体验。
那么创新者及其团队有什么特点呢？
- 不是喜欢冒险，而是能够从多次失败中恢复并继续努力。
- 有强烈的好奇心，不满足于“就是这样”，而是探究背后的道理“为什么会这样，换一个方式会怎么样
- “蛇的三条原则””——自学、动手、立即解决问题、不断寻找新的机会、擅于发现新的问题。
- 不在乎面子，而在乎自己是否在进步。
- 价值观坚定——要有把事情做好的决心和信念
分析机会可以用SWOT表格，而机会是多种多样的，不一定是技术突破带来的，也有暂时的，小的，例如为时下的热点服务，也可以和当前政策有关的，而这些都是创新都可以考虑的方面。
判断一种技术到达维持性阶段的重要特征就是效能过剩，我想也就是功能已经相对完善，相当地满足了用户的需求。
影响产品竞争的各种因素有：
产品行业的因素（最重要）、公司和市场因素（受众和质量）、团队执行因素、产品的价值因素。
对于团队执行因素，有几个值得一提的地方。首先不能陷入过度地分析和评价，力争要弄清楚所有情况再动手（和理科思维有所不同），这叫做“分析麻痹”。执行力发一个有效衡量标准是一个决定需要多少次会议才能达成。
一个团队发多个产品可以通过四象限划分，对于级别不同的产品，采取不同的对待方式，优秀的产品要力图让其脱颖而出。
开发产品和推出产品的方法概括如下：
- 了解团队能力、产品方向和大环境趋势（技术产品发展周期、SWOT、四个象限法）
- 选择合适的细分市场
- 针对市场投放产品，要考虑用户使用软件的周期、吸引更多的用户，跟踪用户的使用率和留存率、在用户中招募粉丝，让粉丝有参与感并整合到市场推广中。
——————分割线————————————————————————————————————————————————————————————
#代码大全 （续）#
这是关于类内部发设计和实现的部分。
包含。
包含是一个相对于继承来说比较简单的概念，继承需要很多的技巧，也容易出错，但包含是面向对象编程中的主力技术。生动地说，包含用来实现“has a ”的关系。当万不得已时，可以通过private继承来实现“有一个”的关系。要警惕超过约7个数据成员的类。研究表明，人们在做其他事情时能记住的离散项目的分数是7+-2个，当超过时，就要考虑是否要把它分解几个更小的类。
继承。
继承是说一个类是另一个类发一种特化，继承的目的在于，通过“定义能为两个或更多派生类提供共有元素的基类”的方式写出更精简的代码。共有元素可以使子程序接口、内部实现、数据成员或数据类型等。继承有助于避免在多处出现重复的代码和数据。
当决定使用继承时，要做一些决策。分别是：
- 对于每一个成员函数而言，它应该对派生类可见吗？它应该有默认的实现吗？这一默认的实现能被覆盖吗？
- 对于每一个数据成员而言（包括变量、具名常量、枚举等等），它应该对派生类可见吗。
在C++进行面向对象编程的一个最重要的法则就是，public继承代表的是“是一个”的关系。这是一个很重要的法则。
Liskov替换原则（LSV）被总结为：派生类必须能通过基类的接口而被使用，且使用者无需了解两者之间的差异。换一句话说，对于基类中定义的所有子程序，用在它的任何一个派生类中时的含义都应该是相同的。如果程序遵循LSV，继承就能成为降低复杂度的一个强大工具，因为它能让程序员关注与对象的一般特性而不必担心细节。如果程序员必须要不断地思考不同派生类上语义的差异继承只会增加复杂度。不要覆盖一个不可覆盖的成员函数。把共有的接口、数据及操作放到继承树中尽可能高的位置。
