培训归来随笔
今天终于结束了公司为期七天的软件培训，虽然培训的是N年没用的C，但是经过短暂的不适应，还是能很快找到感觉。总结下本次培训的几个关键内容：
1，低级错误案例分析。
2，性能优化
3，需求和代码设计
4，测试
5，工具
6，实战
一，低级错误案例分析：
通过对公司Top10的低级案例分析的讨论和讲解，笔者对编码规范有了更深一步的认识。原来自己写代码，怎么写都无所谓，以为只要实现功能就OK，现在看来是太幼稚了。总结下一般需要注意的低级错误：
1，传入参数合法性验证，不光如此，使用到的全局变量也要进行相应的判断。
2，各分支要考虑齐全，各个需要进行的有效判断，都要想到位。
3，注意循环条件，不要造成死循环。
4，记着要初始化。
二，性能优化
其实在性能优化上，之前就有过一点点了解，特别是目前笔者正在使用的C#，如果用不好，很容易造成性能的低下。养成良好的编码规范，是解决这一块，一劳永逸的办法。能够提升性能的主要途径如下：
1，优化算法
2，通过对编程语言的理解，用正确的方式编码
3，重构
不管哪种办法，只要能降低时间和空间复杂度的，都是对性能的优化。这里再总结下平时编码时一些需要注意的地方：
1，循环体内工作量最小化。与循环无关的操作可提出来。外部循环次数应该比内部循环次数少。
2，对于重复使用的运算方法，如果其结果是定值，应该用一个变量保存起来。
3，避免不必要的内存拷贝。
4，传参尽量使用引用类型传递。
5，把最可能命中的if判断放前面。
6，在需要时才初始化对象或资源
7，日志必须按合适的级别分级打印
几种常用的提升性能的方法：
1，以空间换时间
老师举的例子很形象，说是N年前，最早的设计游戏，很卡很卡，然后一家公司，很聪明的将所有使用到的计算，制成一张表，然后用直接表内调用结果，去代替实时计算，大大的提升了游戏性能。
2，减少函数切换次数
函数不断切换，在汇编层面是函数地址间的切换，很浪费时间，最好内联。
3，模块之间耦合度过高，重复代码和函数体过大的情况，应使用GOF的23种设计模式，来进行重构。
4，函数参数不应多于4个
这个好像和寄存器有关系，欢迎补充。
5，避免使用复杂的表达式
代码应该简洁明了，不应该使用晦涩的编码，如i+++++++
6，过多的函数调用层级（过度深度递归）
这个好像和栈有关系，具体情况没遇到过，欢迎补充。
7，避免长switch
如果是很长的switch，为什么不用哈希表呢
这些建议，很多不光与性能优化有关，还和编码规范，可维护性，可扩展性，健壮性有关。
三，需求和代码设计
其实在入职前，在学校是使用过软件工程的内容，进行项目的需求分析，设计的。但是这次明显感到，学校里做的东西，实在是太水了，我们自己做的需求和设计，和真正SE做的一比，差的不是一点点。职业SE对需求要点抓的很准，流程和结构理得都很是清晰，特别是其对功能模块的切分，粒度大小，范围恰到好处。给出的设计文档，规范易懂，流程梳理的很是清晰，各个分支以，异常处理，输入和输出都进行了详细的标注。开发人员一看，就知道如何动工，按图索骥。
在这一块，我最大的收获是：
1.需求分析，应该从客户的角度去看，而不是根据自己的经验想当然的去添加或删除东西。
2，最好理出个整体流程出来，再按各个角色的角度去划分各自的流程。
3，简化流程，梳理出大概的流程图。开始圈分出功能模块，分清其开发的优先级。
4，对各个功能模块开始细化设计，理清其输入，输出，各个可能的分支。最好边分析，边画出其详细的流程图。
四，测试
其实在入职前的实习阶段，我负责的部分就是和测试息息相关的自动化测试环境。所以对白盒和黑盒，ST,UT等都有所了解。虽然如此，但是私下编码时。。。一个都没用到过。这次被强行要求编写UT，慢慢的开始感到，“磨刀不误砍柴工”的真理。虽然在之前弄ACM时，听闻各个大神都是直接Printf，从不断点Debug，更别谈UT，那开发速度，如神一般。但我们毕竟是凡人，所以还是按更为稳妥的方式来编码，特别是在听过各种“一个错误代码，导致N 千万损失”的案例后。。。
简而言之，随手写UT，减少以后的工作量！
五，工具
因为笔者使用的是C#，所以对课里将的C/C++使用的Insert Source不是很感冒，但是其中的PC Init和MaxCC计算工具，还是上了下心的。因为公司对这几个工具的指标，下了死命令。。。
六，实战
感觉很好的一点就是，培训不是老师在上面讲，下面一堆人各干各的，有了这个最后的实战考试，大家对学习内容还是很上心的。实战即是编写一个“停车场收费系统”，结构很简单，最大的数据结构不过是一个链表（C只会用数组的表示还是有点蛋疼），代码框架定义好了API，只要实现其功能，提交上去，平台就会根据设定自动评分。
实战的收获在于，自己动手过一遍，才算是真正的掌握知识要点。
