以前公司产品使用 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 覆盖全面, 也能让问题早发现, 避免在生产环境出现问题而影响用户对产品的映像.
把每个接口文档完善, 方便接手人员更好的能够维护代码. 但是前期项目紧张, 人手不够的情况也可能成为借口而不去处理这个事情
来源: http://www.jianshu.com/p/d7a4727a9945