标签（空格分隔）： 个人总结

最近学了很多知识点，也通过几个作业、项目将这些知识点串联在一起，相互协作完成一个程序丰富的功能。
在写项目的时候，最大的困难是没有一个很好的编写流程。虽然对于项目的每一个功能都可以单独的分析并提出解决方法和思路，也可以写出对应的知识点来完成此功能。但是多个功能之间的交互、函数划分、接口调用方法等等，涉及模块之间或者说涉及全局规划时，就会无从下手。

自己分析过，可能有几个原因：

1、看的其他人写的代码太少，其他人写的架构、思路是可以借鉴的
2、自己写的代码太少，（不过在没有架构思维的情况下一味的练习只会转牛角尖出不来）
3、需要一个全流程的指导，并分析各个环节的作用，环节之间的相互作用

经过1个多月的学习，从自己的代码、别人写的代码、一些书籍的阅读之后，大致对于全局编码，有如下几点经验：

设计角度：
1、函数大小：不应该超过1页
2、高聚合：一个函数里的代码应该有一个共同完成的目标，如果有两个，应该拆分
3、耦合性：
    a、使用参数和return来提高耦合，尽量甚至不使用全局变量
    b、避免修改传入的对象内容，如果有必要，可以考虑copy
    c、避免import *，一是可读性差，二是污染当前模块命名空间
    d、函数接口设计要功能分离，同时，将系统函数（或常用函数）与自定义函数分开，方便后期测试

类角度：
1、类的接口，哪些需要对外提供，哪些是内部接口（使用 _ 或者 __ 来隐藏接口）
2、类中方法的抽象层次，一般来说，相似的功能应该有相同的抽象层次，抽象层次的设计就是函数结构的设计
3、函数的通用性，函数应该尽量设计成可以通用的，这样可以提高抽象程度

编码角度：
1、每次应该只写一小部分代码，聚焦一个小功能的实现，不要这里写一点，那里修改一点，聚焦视角
2、每完成一小部分代码的编写，立马测试
3、小步走，多测试
4、要有框架思维、全局思路，但是实际编码的时候应该一步步写，日渐丰富程序功能。一开始就写好框架再填写代码并不合适（至少目前对我而言），非常容易发生：写到某一部分时发现需要重构框架，导致整体推翻。
5、内部接口和外部接口一样要整洁漂亮，内部接口代码（对内使用）不应该随意编写。

几点教训：
1、不应该过于抽象化，因为抽象化意味着高耦合，一旦需要重构，需要修改每一处被抽象的地方。
2、不应该过长时间思考和编码，如果连续编码8个小时，基本上已经没有思路和创新，应该休息和放松。
3、精力很重要，所以要经常锻炼身体，我发现身体的锻炼可以提升脑力容量。
4、编码的速度越快、一次性想要做的事情越多，就会做的越差，慢即是快，真的是一个矛盾但是有效的事实。