上道有点艰难
18年过完年回来，上一个项目已经交付等待下一步进展了。真正要开始接触当前公司已有项目
-
有了一开始项目的一些经历，看起已有项目还是很吃力 ——以往写代码都是一个人完成需求开发，中间没有别人参与，而实际上对于自己代码的风格完全没有规范，不知道什么是易读易维护的代码。
-
当时自己在项目中总会写一堆全局变量，各种外部声明头文件里写了一堆； 数据结构也是单一的数组变量在存储，不知道打包；即使有命名要准确的意识，还是起了些相关但不确切的名字，弄得后面维护时还是挺头大的，需要不断借助注释
-
现在要开始读别人写的工程文件了，发现各种不舒适，不理解为何这里要这样写，那里又换一个风格写，而这些不舒适都成就了后来我能拿起就读别人的代码并快速理解意图，好的写法还能自己从容借来放到自己未来的编写中。
好的代码风格重要性不言而喻，这里想记录下：1. 不忽视代码风格的多样性和一致性（这里听起来有点矛盾：多样性————通过不同的写法来满足不同地方 比如对易读易辨识的要求；一致性————让自己习惯的写法在不同工程中出现，但相同目的都使用相同的写法） 2. 注释很重要，但尽量通过代码来表达自己的意图是最好的（比如一个函数要发送无线数据，函数名写成Wireless_SendData就很直观了） -
老代码中总会有些BUG，真是太年轻，说是调试代码其实连“调试”都不会啊，只会写一写led灯提示，看一看结果再改一改，效率也是出奇的慢，两周还没读完一个通信功能模块的代码（实际上连从哪里开始看都不明确）┭┮﹏┭┮ ，后来才知道原来编译器自带的调试工具简直不要太好用，基本满足所有调试需求… …
-
在与前同事交接时也因为没有经验做得相当糟糕，没有流程图，没有文档说明，甚至是已经离职了难得来几次公司指导问题，没有在他来之前充分准备需要请教的问题等等… 说起来都是泪啊，也是后来我真正接手开发是又一两个月后的主要原因
维护老代码一些心得：1. 熟悉使用的编译器，有什么工具可以用，怎么用都在未来对自己的帮助是巨大的 2. 谁写的代码谁一定是最最清楚结构流程的，在看代码前向他们要整体框架图或者流程图、文档一些的辅助都是必要的，就算没有这些都要他们亲自给你讲解下每个功能模块的分布，之间的联系，接口调用注意事项等等等等... 3. 即使有了上面这些辅助你理解，最最重要是根据这些内容，自己死磕代码；就我而言是先看工程的组成文件有哪些，有没有用到库，用的什么库就可以知道基本框架是基于什么的，如果不了解就赶紧去学，哪里不懂学哪里。 4. 需要知道用户文件区有什么内容，知道工程里面大致做什么事情的代码会在哪里 5. 深入文件中，从main开始看系统是怎么开始运行的，有用到什么硬件资源就有什么的初始化；往下就是进入系统工作的调用是怎样的，建立一个大致认识，看这个人的代码风格是如何的一般从头文件可以看出来，大部分人的数据结构封装都会在头文件中体现出一二 6. 看文件开头都有哪些全局变量，这些变量通常会伴随着外部声明，意味着你会在不同文件看到他们，记住他们做什么用的 7. 可以用全工程查找（包括头文件），对一些自己想知道都在哪调用过的函数或变量会非常非常方便 8. 使用对比工具，这是个神器啊！ 对比文件夹，对比文本，合并等等，在项目打大了之后工程文件上午改了下午不知道改了哪，打开备份（前提你要有）的工程对比看下一目了然... -
就这样磨磨唧唧的进度一俩月过了试用期，还被幸运地留了下来，真是很感激被老板包容这么久，渐渐熟悉了老代码的结构后就开始被提出要做些新东西了，自己成长的也很快，慢慢掌握了一些方法吧，这些对后面的工作帮助极大
后续还有… …
