-
开发前要进行好准备工作，这能减少后面写代码的时候折返跑的概率。（架构设计、需求完整、考虑每个需求点的商业价值...）
-
架构设计：（为了降低风险）
※ 对实现80%功能的20%的类所说明
※ 数据库设计（为啥用单个/多个数据库、表设计、view设计、为啥要用数据库而非文件）
※ 对资源的使用率例如线程带宽以及极端情况处理
※ 安全性、性能以及风险
※ 可伸缩性（用户增长应对）
※ 国际化
※ 错误以及容错
※ 指明对哪些类必须健壮，而其他类可以勉强健壮，防止过度工程 -
主要的构建：代码规范 & 测试用例单元测试 & merge前的统一工序
-
子系统之前的通信要避免过多，这样容易牵一发而动全身，避免形成环：
乱七八糟的系统
简化后的系统
-
隐藏业务规则（例如税率）& 用户界面 & 数据库访问 & 系统相关的接口（例如Windows）的实现，尽量通过接口访问，这样可以很快的对他们做修改替换
-
信息隐藏：如果有个变量是int的，你可以通过
int id = newID()生成它，但是如果它变成string了呢，你要到程序里面所有地方把类型改掉。如果你typedef了一个idType，然后程序里都用idType就可以很轻松的改id的实际type了~ 所以要多思考我要隐藏些什么？ -
封装变化：把容易变化的搞成一个类，然后让内部的变化对外不可见。例如sdk的操作啥的，这样如果以后要换一个sdk就很方便。（例如业务规则、对硬件or系统的依赖、输入输出的文件格式、非标准的语言特性、困难设计区域、状态变量、常量定义）
如何找变化
-
为测试而设计
设计check list
-
不要太多注释说明的事儿，可以直接assert解决，如果错误使用就crash了
-
保持接口抽象一致性、内聚性。不要暴露过多接口，注意封装，封装如果做不好接口抽象也一般很难做好，随之而来的可能就是耦合严重
-
如果你调用某个函数必须知道它的内部实现逻辑，那么就是有问题的，这不是面向接口编程而是面向实现了
-
有7-9个成员变量是一个类的合理大小，如果有更多的话最好拆成单独的类
-
继承的适用场景是，如果有个基类A和子类BCD，你在使用BCD的时候是无差别的，不用考虑它具体是哪个类才是对的。如果C的某个方法和BD不一致，使用实例的时候还得先判断是不是C，如果是就do something，继承就是不好的。
-
只有一个派生类的基类是没啥用的可以不用提早过度设计做继承；而有很多只覆盖了几个方法还不干活的派生类的基类也是有问题的。
派生误区1
派生误区2
-
减少继承层数，最多2-3层以内
-
多重继承
屏幕快照 2020-05-30 上午8.09.26.png
-
减少实例化对象的种类、减少在实例化对象上调用不同子程序的数量、减少调用由子程序返回对象的子程序例如
new A().createB().getC().doSth() -
避免只有数据或者只有行为的类。
（这里其实有点迷，model不是有一些就只有数据么，以及util一般都只有行为吖） -
继承会增加复杂度，所以用组合好于继承，因为我们编程的目的是降低复杂度。
-
创建子程序（函数）的原因：
降低复杂度让调用者可以不必思考细节直接用、
引入中间易懂的抽象让代码更可读、
避免代码重复、
支持子类化、
隐藏顺序如先A后B可以把AB都分为两个子程序、
隐藏指针操作、
提高可移植性隔离有语言特性的代码、
简化复杂的bool判断、
改善性能集中调用可以集中发现修改问题、
限制变化带来的影响、 -
子程序应该提高内聚性做好一个事儿例如求cos，避免干两个事儿例如cos以及tan。高内聚性的bug会更少。
-
子程序命名：
（1）有的时候会起解决的问题&副作用的名字例如calculateReportTotalsAndOpenOutputFile。这样就太长了，可以只保留解决的问题即可
（2）避免无意义的动词看不明白干了啥，例如handleOutput可以改成formatAndPrintOutput，但有时候不好起名是这个子程序没有很好地内聚，需要修改代码
（3）避免仅数字形成不同名字，例如outputUser1/outputUser2
（4）要对返回值有所描述，例如currentColor()
（5）面向对象语言里面如果都document.print()了就可以不用命名为printDocument
（6）对仗，open/close、create/destory
（7）为常见操作统一命名。例如项目里面好几个类都有获取id的方法，那么就尽量不要一个类叫getId()，另一个类叫id()，还要一个类叫id().get() -
参数顺序，可以先是input不修改值的、最后是output会改变值的。（类似swift）
-
用assert对参数说明，例如数值范围、枚举、数量的参数的单位
-
参数限制在7个以内；
-
如果一个有10个参数外露的对象，子程序之需要3个，那么是传入对象还是3个参数呢？看子程序需要的抽象究竟是什么，避免装包拆包也就是避免创建一个新的对象给子程序，然后子程序再拿自己要的三个属性，如果是这样就直接给三个属性即可。如果经常需要修改子程序参数，每次都是加这个对象的其他参数，那么就可以传入对象。
-
显式声明参数名，防止错位
-
返回值应该是函数名所指定的，如果函数名没有指定，则不应该有返回值。不要为了方便随意加返回值给外面暗示成功or失败哦。
-
define宏注意用括号 & 花括号包起来避免执行错误：例如
Cube(a) ((a) * (a) * (a))，这样就避免了传入的是 x + 1 这种。所以尽量不要用宏，可以用inline、template、typedef来替代 -
断言是保证代码正确性的，只有debug环境监测，避免绝不应出现的问题；错误处理是处理可能出现的问题，让程序不崩溃；异常是严重问题，外面拿到异常如果不catch就crash了
-
不要抛出低层级exception暴露内部实现：
错误的异常
正确的异常
-
可以先写伪代码，从高到低，直到你觉得已经没有意义了，然后作为注释，填充代码。（注意去除冗余的注释，虽然其实现在的互联网没有给写伪代码的时间..）
-
变量存活时间是从最后一次使用到第一次声明的行数；平均跨度是相邻使用之间的行数距离的平均值。我们追求的应该是短存活时间 + 短跨度，可以让读者更好的理解代码，并且减少中间使用的可能性来减少错误。其实也就是让你思考和控制的范围变小，就更不容易出错。（所以应该避免全局变量）
变量名命名
-
把计算的量放在名字最后的这条规则也有例外，那就是Num限定词的位置已经是约定俗成的。Num放在变量的开始位置代表一个总数：numCustomers表示的是员工的总数。Num放在变量名的结束位置代表一个下标：customerNum表示的是当前员工的序号。通过numCustomers最后代表复数的s也能够看出这两种应用之间的区别。
然而，由于这样使用Num常常会带来麻烦，因此可能最好的办法是避开这些问题，用Count或者Total来代表员工的总数，用Index来指代某个特定的员工。这样，customerCount就代表员工的总数，customerIndex代表某个特定的员工。 -
循环中可以用i,j,k命名，但是如果是循环嵌套，其实这样容易出问题，或者这个变量不仅仅在循环内用，这些情况最好起一个有意义的名字类似
score[teamIndex][eventIndex] -
BOOL的命名可以用
found、success等，自己就包含了真假的含义。如果有的人习惯在前面加一个is例如isFound也可以，可以避免非bool含义的变量被如此命名例如isStatus就很奇怪。但是if(found)就比if(isFound)好很多。如果是反义的可以取名notFound，如果经常判断的是if(!notFound)就应该替换为if(found)啦 -
在同一段中不要出现含义类似的两个变量，很难理解。也不要那种拼写类似的哦，容易看混。
-
在精度要求很高的环境下，如果你不确定自己要用double还是float，其实可以typedef一个新的类型，然后计算时候都用自己定义的type，如果需要改精度，只要改这个type的定义就可以改掉所有地方比较方便~ 例如
typedef Coordinate double，而且这样可以对使用者隐藏细节。 -
内存中的一个位置就是一个地址，常用16进制形式表示。在32bit的处理器上面，地址用32bit表示，指针本身只包含地址。
-
如何解释内存中某个位置的内容，是由指针的base type决定的，如果某个指针指向整数，那么意味着编译器会把指向的内存位置的数据解释为整数。所以内存并没有绑定一个指定的type，是你用的指针才指定了解析内存的方式。你可以让一个整数、字符串、浮点数都指向同一块内存，同样的内存可以解释为不同的内容，只是取决于指针的base type，例如：
指针type
-
如果子程序传入参数是个指针，需要
*parameter = some_value才是改了指针指向的内容哦。
但是注意int *p; *p = 1不能用，因为int *p;定义了一个指针p，然而p并没有指向任何地址，所以当使用*p时是没有任何地址空间对应的，所以*p=1就会导致，不知道把这个1赋值给哪个地址空间了。
int *p; p = 1;能用是因为int *p;定义了一个指针p，p = 1;意思是将一个内存地址为1的地址赋值给p，所以这个是可行的。但是这个操作是不安全的。 -
即使全局变量，也不要让程序里各个地方直接使用和修改，需要创建setter和getter控制访问。这样比较方便之后拓展和调试。
全局变量访问
- 虽然应该避免全局变量，但如果真的需要那么就光明正大的用，命名尽量和别的区分开，不要搞一个大的杂乱无章的对象来回传递反而不好。（类应该具有抽象一致性，而非单纯为了减少参数传递个数之类的，除非本身就是一致的）
- 如何标识一系列需要顺序执行的子程序：
通常我们对写程序对数据操作都是取数，对数据进行计算，再打印。一段java演示代码如下：
data = ReadData();
results = CalculateResultsFromData( data );
PrintResults( results );
这三个步骤思路非常清晰，说明了这几个函数之间的耦合程度，和相互依赖性。除非什么特殊情况发生，否则都会按照这个顺序来执行。尤其在ABAP中，似乎都是这样的顺序。
再看一个例子：
revenue.ComputeMonthly();
revenue.ComputeQuarterly();
revenue.ComputeAnnual();
在以上代码中先计算的是月份，接着是季度，最后是年份。这是一个常识，但是光从代码中我们无法得出他们是否有耦合，是否应该按照这个特定顺序执行。
再看一个VB例子：
ComputeMarketingExpense
ComputeSalesExpense
ComputeTravelExpense
ComputePersonnelExpense
DisplayExpenseSummary
从以上例子中也看不处这段代码的执行顺序有什么特殊之处，也不知道如果改变语句的执行顺序会怎样。没有任何的注释，程序也没有参数，可能都是直接对全局变量进行操作。所以这段代码写的并不好。
=> Solution 1: 组织代码让依赖关系更明显
在上面的VB代码中，应该有一个初始化函数，如InitializeExpenseData()。写这个函数的目的是程序的结构更清晰，让读代码的人知道了一个隐含的信息，在调用其它函数之前，必须调用初始化函数。
=> Solution 2: 使子程序名凸显依赖关系
如果ComputeMarketingExpense必须最先执行，它做的不仅仅是现在名字里面的事情，还InitializeMemberData它应该命名为ComputeMarketingExpenseAnd InitializeMemberData
=> Solution 3: 利用子程序参数明确显示依赖关系
如果子程序没有传参，你就看不出来哪些子程序依赖了一样的数据，通过显式写参数可以暗示使用者顺序是很重要的。
ComputeMarketingExpense( marketingData )
ComputeSalesExpense( salesData )
ComputeTravelExpense( travelData )
ComputePersonnelExpense( personnelData )
DisplayExpenseSummary( marketingData, salesData, travelData, personnelData )
有一种更明确依赖关系的方式就是加入输入和输出
expenseData = InitializeExpenseData( expenseData )
expenseData = ComputeMarketingExpense( expenseData )
expenseData = ComputeSalesExpense( expenseData )
expenseData = ComputeTravelExpense( expenseData )
expenseData = ComputePersonnelExpense( expenseData )
DisplayExpenseSummary( expenseData )
这样你是不是就可以明确的感受到，后面的结果依赖于前面的步骤了
=> Solution 4: 注释
=> Solution 5: 断言
如果这段非常重要，可以在前置步骤里面加一个bool isXXXExceuted，然后再后面的步骤判断之前的isXXXExceuted都是true才执行后面的，否则就assert。但这样增加了变量哦，所以要权衡利弊啦是不是足够重要。
-
顺序无关的语句也要遵循就近原则，相关的放在一起，降低读代码的时候的复杂度。
-
if-else、switch-case的时候，先写正常的再写异常情况。这个也类似likely可以提高执行效率。
-
如果condition过于复杂，可以抽出函数来得到BOOL值，不要把
if(xxx)写的过长很难理解。 -
简化case里面要做的事儿，如果很长就提成函数。尽量避免case里面不break越到下个case，如果真的要这么做就注释一下，但也尽量不要这么做。
-
递归要注意有可能内存溢出，可以加入安全计数器限制执行次数。（不要用递归计算阶乘 & 斐波那契，明明循环更可读并性能好）
-
各种方式找代码问题的有效率：
缺陷检测率
所以没有任一种是可以直接把问题都找出来的，需要混合各种方法来提高检测率。代码复查的找到错误的效率要高于测试的，所以要多review吖还可以顺便改bug
-
测试先行。先写测试用例，能明确需求也能提高开发效率。
-
一个不能经验论的例子：性能优化的时候我们可能为了性能而写了晦涩的高级代码，例如二维数组求和，为了避免用循环以及下标计算，可以用指针递减的方式做。但是当你真的测试性能就会发现没有区别两者，因为编译器早就做了优化，循环的实现就是指针递减。所以真的有性能问题的时候要找到影响性能的20%代码然后优化，不要再细枝末节上面纠结太多。
-
C#中switch-case的效率要高于if-else，然而java中相反。不用语言是不一样的哈~ 只能通过测试确定这个事情。
-
用表查询替代逻辑判断：
image1.png
image2.png
-
当性能和可读性矛盾的时候需要看场合，不是一定为了性能牺牲可读性。例如循环展开求和比for快，但很难理解。但我们应该尽量简化for循环里面做的事情
-
把最忙的循环放在内层：
把最忙的循环放在内层
-
削弱运算强度来提高性能：
运算强度
-
用低级语言重写代码：
image
-
性能改善：
代码调整方法
提高代码执行速度
-
项目越大，写代码的时间占比会越小，架构、需求、测试的b比例会更大。并且项目的大小成倍增加，总的时间可能不止一倍增加，因为相应其他的部分是非线性增长的。
-
编译器与链接器：
编译器与链接器
根据C++标准，一个编译单元（Translation Unit）是指一个.cpp文件以及这所include的所有.h文件，.h文件里面的代码将会被扩展到包含它的.cpp文件里，然后编译器编译该.cpp文件为一个.obj文件，后者拥有PE（Portable Executable，即Windows可执行文件）文件格式，并且本身包含的就是二进制代码，但是不一定能执行，因为并不能保证其中一定有main函数。当编译器将一个工程里的所有.cpp文件以分离的方式编译完毕后，再由链接器进行链接成为一个.exe或.dll文件。
举个例子，编译器负责把每一页或节或章翻译成等价的中文，链接器负责把翻译好的章节整理成完整说明书。
Finally，这本书真的好长。。涉及的很广还会有一些管理心理学之类的，虽然年代久远但也值得一看吧。
网友评论