我一直在想该不该写这样一篇文章,想标题都想了很久,激进一点的起法是:麦座系统10宗罪。感觉这个标题太大了,如果写不出来点什么,就成了麦黑了,其实我的本意是想一篇关于麦座系统的总结,但最近工作太忙抽不出时间写这篇文章,最多的是在繁忙之中更多的吐槽系统的各种问题,代码的各种不合格的规范以及前辈们留下的各种坑。
之前我基于maizuo的thrift架构写了很多小的程序,例如maizuo和zookeeper集成,maizuo和ehchche集成等,最近我又想将maizuo和amazeui继承,因为amazeui是一套手机优先的前端框架,比较不错,我一直不喜欢目前麦座的ui,感觉太low了,没有产品感。我想使用一套好看的ui来做一个精简版的麦座,目前已经实现了登录,和一个简单的项目列表查询,也使用angular的mvc架构,但问题也存在就是对angular的依赖比较大,还是需要写指令,我本人的指令基本功差一些,对于这些ui的指令封装太难了,就封装了一个项目列表的就暂时搁浅了。
我对工作的定义是,只要我在工作中可以得到认可,我工作的舒服没有拘束感我就愿意继续留下来工作。但有一些不舒服的地方怎么做都可能无法避免,比如代码的各种坑,我一致在幻想一种理想中的系统,可以有很多种定义,同时我觉得可能实际又不存在,因为如果这种理想的系统存在了,就不再需要这么多的程序员了,程序员的存在不就是为了完善和修改系统的缺陷吗。尽管如此,我一直对麦座给予厚望,我是希望麦座可以做到我理想中的那样,不管是从产品还是开发上,但这种幻想总感觉距离越来越远,系统的坑越来越大也越来越难以维护,这种不舒服感越来越大。。。我觉得我需要总结,总结麦座系统的不足点,麦座系统本身也需要反思,不要一味的为满足需求而开发,要懂得反思,从程序的角度入手,真正的做到程序上的最优而不光光是外表。
所以今天提笔写这样一篇文章:如果给我一次重构麦座的机会,或者说给你一次机会让你重新做麦座,你会怎么做?未来1个月估计还是很忙,我会在不忙的时候总结和反思麦座的问题以及优化的设想,慢慢补充这篇文章。
2016年4月23日 星期六 天气晴
今天我想了想系统应该从哪些方便进行重构或者重写,也许我应该站在更高的角度去思考,而不是仅仅局限与代码,包括从核心人员的选取,技术架构的分析以及具体代码的执行上我都需要去考虑,就像我要作为一个项目经理去带领一个团队做开发一样,我需要准备哪些工作,我会从以下这些方面去做麦座这个产品。
1、团队合作
(1)团队人员选择,例如:强调进取心
(1)团队合作原则,例如:强调责任感
(2)团队合作规定,例如:强调执行力
2、开发规范
(1)技术规范检查官
(2)技术规范制定
(3)技术规范文档输出
3、技术业务架构
(1)技术选型原则
(2)技术架构设计
(3)技术架构搭建
(4)业务架构分析
(5)业务耦合度分析
(6)代码版本升级
4、核心代码
(1)核心人员组成
(2)核心代码开发原则
(3)前端与后台核心管理
5、强调设计
(1)开发前必须有设计
(2)设计后必须有审核
6、代码审核
(1)代码审核官职位责任
(2)代码审核周期性检查