以前公司产品使用LAMP的架构去扩展产品，php这端的关于Linux硬件管理这块cgi有人用perl来写，其他模块基本上是c++来写的。架构在演进的过程中为将c++人员释放出来更专注于后端模块，管理端就使用了python来替代。于是粗略的话划分就变成了 Linux+php+nginx+tornado(python)+模块服务（c++）。
人手不够的时候基本上需要从前端js到后端c++管理再到具体模块都需要一个人来处理，于是我也变成了一个偏后端开发的伪全栈开发。由于接到一个新模块的开发，但是python端人手不够，于是除去前端开发自己又要从python到c++写个遍，不同的是我需要在已经成熟的python代码架构里面添加我的功能模块。还好之前抽空学过python语言，从c++转python相对轻松很多，但相对于c++这样的静态语言的严谨，python的自由让我有点无法适从。
还好模块编写比较顺利，但是在修复一个BUG的时候碰到了一个动态语言的坑。看看下面两个函数的定义：
def get_common_job_info_source(media_ip, job, execType, server):
def get_common_job_info(media_ip, job, execType):
能看出两个接口有啥区别嘛？第一个参数多了一个server？哈哈，好眼力。但实际上问题出在了job上，几乎所有模块的job都是利用orm库定义的数据库操作对象，于是在修复BUG时在处理job是我两个接口都想当然的都当成了对象去取值。但是出问题了，第一个函数里面的job是一个dict(字典)，关键是编译出包的时候不会出错，发现不了问题，只有在环境中真正运行时抛出异常，发现问题出来了。
但最最关键的是这个job居然依赖web端传递过来的参数。。。web传json对象，那么job就是对象，web传字典，那么job就是字典。我的个天啊，在没有任何接口文档的情况下去修复这个问题是要人命的。这就是我碰到的一个动态语言的坑，我不想去否定什么，但是我确实碰到了。怎么去解决这个问题了，多瞎比比几句：
-
代码设计上多留意，但这玩意很难讲，开发人员的水平参差不齐，水平的提高不是一蹴而就的。只能说尽量做个上进，不断学习、进步的高要求程序员吧。学校里面追求程序能跑就行，但是工作中要想精进的话还是要花点时间的。不过感觉公司出于成本的考虑不怎么留得住优秀coder，算是给其他公司培养优秀人才吧。
-
AT/UT，当然，如果开发人员或者公司要求严格一点，把AT和UT覆盖全面，也能让问题早发现，避免在生产环境出现问题而影响用户对产品的映像。
-
把每个接口文档完善，方便接手人员更好的能够维护代码。但是前期项目紧张、人手不够的情况也可能成为借口而不去处理这个事情
网友评论