分而治之思想，
面对一个体系很庞大（相对我而言）的程序的开发，首先应将程序合理的划分一些层次和模块，
不要至上而下的开发，不然可能呆坐半天而下不了手，应该先把下层的小模块做好，再组装起来，即使组装的时候发现了很多需要修改的地方，也不是很要紧，利用resharper和vs的强大的重构和提示功能，完成修改并不算困难。
写这段话的时候,还是我实习中刚开始参加开发工作的时候(2012年的8-9月份),那时我水的一比,给我一个很小的功能模块,我都下不了手.
我还记得这段话的背景是:我要开发一个小功能,读取文本文件,里面有一些坐标和卫星图像的参数信息,我需要读取出来,然后通过一个复杂的计算公式,求出某个投影坐标,我需要将它封装成接口,让其他人调用,输入参数是文本文件地址,输出参数是保存坐标信息的二维数组.我当时对接口其实都理解的很浅,对整个功能模块的开发,完全没有思路.
其实现在想来蛮可笑的,但我想也许大部分的初涉开发人员,其实都会有这个问题.
这其实不是编码能力的问题,而是做事方法,不知道应该怎么去做一件事,没有自己的一套方法学的指引,感觉很茫然.
在枯坐半天之后,我只好去请教带我的前辈,他只是问了我几个问题(原话不是这样,我提炼一下意思):读取文件你会吗?会!字符串解析会吗?会!公式计算呢?虽然算法比较复杂,但是有现成的公式套用,我也可以写出来. 那不就得了,你先把文件里面的内容读出来再考虑下一步.
ok,现在目标变简单了,我终于开始写代码了,在一番尝试之后,我做到了第一步,然后接下来越写越顺,虽然在数据中间流转环节遇到了很多问题,但我都有思路了,慢慢调式,重构,最终也搞定了这个功能.
在这里不得不感谢我实习的这家公司,现在回想起来,我们那批实习生,其实根本不能创造多少价值,反倒是公司定期组织人手给我们培训,而且我们还能拿点工资.我自己都知道,公司在我身上的投入远远大于我对公司的贡献,而且因为种种原因我们能留下来的,其实是少数,公司也知道这点.因为这种行为已经持续7年了,按照每年的经验总结,大概最终只会留下20-30%,我那年也没例外.但公司仍然不介意.
这其中有这家公司和我们学校有合作的原因,但其心胸也足以令人钦佩.
这公司老总是武大教授,研究生以上学历占一半以上,大部分员工都是武大和地大出身,里面的氛围很轻松,和我在学校时都没什么差别.而且师兄师姐比较多,我那个楼层的boss和带我的boss都是我的直系师兄,所以我自己也不拘谨,只是最终因为我不想呆在北京,公司由于项目原因,技术比较老旧(.net 2.0 winform)还是选择离开了这家公司.
功能的分层和原子化
不要在一个函数里面做太多的事情，这句话以前一直听到，但真正有体会，还是要等到自己实际遇到，我有一个函数，解析DAL对象传递的字段，控制任务对象的开启、关闭线程，修改数据库。但是当我应理解出错或是需求更新，需要添加和修改功能的时候，就麻烦了。这个函数被改来改去，同时还要修改任务对象的接口，DAL解析的内容，函数本身的参数。如果我当时能把这些功能合理的分割下，修改的时候就只需要修改相应地方就可以了。所谓“原子化”意为不可分割，表示这个功能一执行就全部执行，不执行就全部不执行，如果一个函数的功能是这样子的，那么这个函数被修改的可能性就很小了。但是分层也需要注意合理性，不然层次太多，各种跳转，也是无谓的加大了代码的复杂度。
命名规范很重要，
大家都遵循一套好的命名规范，首先第一个好处是代码阅读起来很方便，比如_taskState
一看就知道是个全局私有变量，taskState则可能是个局部变量，要注意有效范围了。类名的存放位置同样如此，依据DAL-Model（Definition）-Class的层次存放类文件，我们引用或查看的时候，对类的结构首先就有了一个大致的了解。
不过我老是不记得这点，写着写着就忽略了，不过后来发现RESharper的命名提示功能不错，尤其是它还可以自定义不同内容的命名规范，利用这个小工具，一定程度上可以保证名名规范。