2015-04-07 Summary Report

2015-04-07 Summary Reports

截止4月3日，我来到新公司的第一个项目在一片混乱和加班声中落下了帷幕。这可能是我参加工作至今参加的最最混乱的一个项目。所以有必要整理下思路，将项目中的有缺点(主要是缺点:）)总结纪录下，为自己也为他人提供一个参考。

我将问题分为几类，按照软件工程来分吧，反正每个阶段都有一些问题。

一、需求方面主要遇到的问的：

• 需求不明确: 项目已经开始一周，需求还没敲定。

• 需求变更频繁: 常常是到测试阶段了，需求还会变化。大boss竟然也会提需求，而且还是必须得实现。

• 需求在QQ中讨论: 在qq群里讨论需求，导致得后果就是开发不知道需求，或者是很快就忘了。

• 没有及时更新到文档上: 没有专门的需求文档和设计文档，有也是非常旧的版本，没有及时更新。

二、UI设计

• UI设计原型图修改后不会及时更新。

• 效果图不准确，也没有及时更新。

• 标注图同上。

• UI没有统一的标准，光颜色值就各自定义各自的。

三、代码管理

• 代码没有标准。看工程中的代码，各式各样。

• 没有code review。经常会导致代码覆盖或者是很简单的错误出现。

• 没有CI，全靠手工打包。效率极低。

• 模块划分不明确。

• 业务逻辑和UI逻辑混在一起，无法维护和测试。

• 无用代码或者无用的文件都混在一起，导致工程很混乱。相同定义出现多次。

• 后台和前端周期安排不合理，经常前端做完后，后台接口还未完成。非常耽误进度。

四、测试

• 没有Test cases.

• Bug系统不支持Mac OS.

• 测试没有规范及周期，完全依赖研发，测试过程比较混乱，版本追踪困难。

五、其他：

• 项目周期制定拍脑门，不是根据具体需求细化后，根据每个feature的时间预估周期，而是指定死时间，在过程中不论需求如何变化，人员如何变化，周期永远不变化。也就是说一点风险控制的意识都没有。

• 项目管理没有风险控制和变更控制。

• 开发完全无法参与时间制定。

总之，问题很多，不局限我上面所列出的问题。有问题不可怕，可怕的是认识不到问题。从我来到项目结束，除了我及另外一个新来的同事提出过这样做不行，其他人都麻木了。每次我提出问题，总是会说习惯就好，
忍忍就过去了。这不是做事都态度！也不是我做事的准则。我来就是为了锻炼自己能力的，解决这些问题也是我的工作，所以我必须要改变这种状况才行。

很多问题肯定无法一下子解决，所以我将问题分两部分：1，是可以开发内部解决的问题。2，是需要其他部门一起改进的。

对于内部:
1. 我首先使用Jenkins搭建了自动build系统，增加版本号自动增加，将build和版本号对应起来。解决测试问题无法追踪版本及开发手动打包效率低问题。
2. 使用MVVM模式替换原来的MVC模式，分离business logic和UI logic。
3. 统一使用宏定义替换magic number。
4. 建议需求和UI统一管理一份（svn），避免需求和理解的混乱。

对于合作：
1. 积极提出改进建议：如UI规范统一。
2. 接口文档及时更新。
3. 测试统一依据效果图。
4. 对需求变化进行把控。（好像没有效果）

虽然当前项目没有太大的改进，但是在开发方面还是有很大的进步的。坚持好的习惯或者好的规范，也要有好的方法去推进。最近又将《软件作坊》这本书重新翻开，理论联系实践，理解的更加深刻。不论是对自己还是对公司都是又一些贡献。相当于双赢的局面。