首页 > 代码库 > 框架,公共模块,unified思想
框架,公共模块,unified思想
最近两周一直在加班加点refactor代码,贡献了2014年最后一个周末和2015年元旦三天假期,终于赶在了sprint结束之前完成。
可见,这个sprint做的并不理想!
项目逻辑本身并不复杂,从数据库取数据,进行相关分析计算,然后在前端以图表的形式呈现结果。用的是Django框架,前端图形采用jqplot实现。
项目有三个平行的模块,各模块都要实现数据呈现,报表导出,图片下载功能,但各模块之间互不相关,额外的要求是三个模块都要有很强的可扩展性,以便以后增加新的查询选项,能快速实现。
三个人分别负责一个模块,而且在plan meeting的时候,确保了每个人都了解自己模块的功能需求。
大家都开始了自己模块的设计与实现,第一个星期:基础架构和核心代码实现,第二个星期:前端数据呈现和下载图表实现,第三个星期:互相测试和code review,第三个星期三开始:推倒,重构。。。
就是这么的无奈,在功能都实现了的前提下,又几乎重新编写了后端代码和重新修改前端template。
问题出在了unified思想上:
三个人分别在三个层次实现了unified:template数据呈现一致性,View层数据处理一致性,modle层参数化查询数据库一致性。
每一个模块都为了自己的unified实现做了相应的代码架构,别的模块想复用其代码很麻烦,甚至到了后期,因为命名不一致,连js代码都没法重用,只能眼睁睁的看着非常好的实现无法移植到自己模块中,从而,没法能够做到整个项目的unified。甚至,以后维护代码反而增加了复杂度,如果三个模块添加同样的查询条件,反而要分别进行三套不同的实现,而且因为不同的template元素id,同样的逻辑要写好几个功能相同的js方法。
为什么出现如此结果:
团队成员分布在不同的城市,没有及时沟通机制,交流不畅肯定是造成问题的一个原因。
在项目plan的时候对如何实现并不是很清楚,也没有人发表意见和建议,进行深入的讨论,导致摸着石头过河,每个人都按照自己的想法摸索,以完成功能为主,并未重复考虑,特别是整体考虑项目的架构和可扩展性。
三个人当中有一个比较熟悉项目逻辑,可是没有能够站出来主动负责承担公共代码实现,比如统一呈现数据的前端实现,相应的js验证代码,从而导致前端实现五花八门,甚至没有统一的命名规范。
总之,问题很多,没有及时有效的交流,没有做到充分的思考,没有搭好框架,没有公共处理模块的统一控制。。。
不是敏捷团队,但是按照敏捷的模式去推进,可是没有sm,没有daily stand up meeting等机制保障,只是靠着user story,靠着task去跟进项目,只会导致代码实现杂乱无章,大家只focus在自己的user story上,缺乏体眼光,只快速完成task,没有考虑集成。最终导致了代码的大量重构和返工,同时也增加了软件的熵。
框架,公共模块,unified思想