一路走来

一、到处寻找免费的“午餐”

1、SCM是一个免费的私有svn仓库——unfuddle， 需求和Bug在每周例会统计， 通过邮件跟踪
2、SCM切换为免费的私有Git仓库——GitEnterprise
因为， 伟大的GFW居然连一个版本控制的站点也封！！ 无奈找了另一个免费的私有仓库。 现在看， 使用git还是比svn方便了一些。
3、Bug跟踪系统
通过邮件和Excel跟踪Bug实在时一件让人崩溃的事情。所以，开始想找一个免费的空间，搭建自己的Bug跟踪系统， 没有找到免费的空间； 然后想找一个提供Bug跟踪服务的网站， 但是没有免费的。 在几乎绝望的时候，想到了开源项目托管网站都有Bug管理功能， 对比了github, google code和sourceforge, 无耻的使用了google code 的bug跟踪系统， 但是代码还是托管在私有的GitEnterprise上。

二、与免费的“午餐”失之交臂

想要快速发布版本， 必须保证不同特性之间不能相互影响。 GitEnterprise不支持拉分支， 所有的功能都不停的往主线上提交， 导致发布一个新版本很困难， 要等待多个特性同时ok才能发布， 不能快速迭代， 快速发布版本。必须寻找新的工具替换已有的工具。

要找一个支持分支的合并的似有仓库实在不好找， 绝大多数是收费的，但是还是被找到了——gitlab.com。 研究了使用法， 测试ok，编写完使用文档后。 我被气疯了， GFW又把Gitlab.com给封了，好不容易找到了一个，又研究好怎么用， 正要给兄弟发邮件切换到gitlab.com的时候， 被GFW给疯了， 我真的忍不住大骂了好几天。

三、搭建自己的工具

由于gitlab.com测试好用后， 又被墙的经历。 再也不想过这种打一枪换一个地方的日志， 决定将命运掌握在自己手里。

租了第2个服务器， 用于搭建项目管理的服务。 这也是我们的第3笔花费， 第一笔是域名， 第二笔是用于58bancai.com的主站。

首先要选择的是项目管理工具， 主要集中在选择使用gitlab还是gerrit。 不知道当时我为什么选择了gitlab, 或许是因为想用gitlab.com没有成功， 所以选择gitlab, 以示我们不屈的意志。 但是我总感觉应该没有那么意气用事， 具体原因已经记不起来， 但是想在回过头来看，选择gitlab确实是一个失误， 后面再涉及到集中管理的项目，绝对义无反顾的选择gerrit。

然后选择的时文档管理工具， 主要集中在xwiki还是dokuwiki。 其实按照我们的需求， xwiki当之无愧， 但是xwiki真是个资源大户， xwiki和gitlab一起跑的时候， 内存就被吃光了。迫于无奈，选择了dokuwiki。

四、不断被重新设计的前端

1. 直接使用原型的代码作为前端的代码， 实在是一件糟糕的事情，现在还有生成的糟糕的代码在影响前端代码的整洁和可读性——我们也得到教训：“原型代码一定要彻底放弃， 实际代码里一行都不能使用” 。当然我们也确实用这个代码发布了v1.0版本。 这个版本里面应该引入了jquery。
2. 使用google的前端编码规范，作为前端的编码规范——确实是在开始工作后才引入的编码规范。关于目录划分还有很大的争议， 由于没有讨论确定个， 暂时搁置了。
3. 首页重新设计， 改写了大部分原型打代码， 重新设计页面视觉效果， 发布了v1.1版本。
4. 引入bootstrap， 使用ajax和pjax提高用户体验, 个人中心进行改写完成后，v1.2版本亟待发布。

五、几乎不用改变的后台

1. struts2 + hibernate。
2. 修改了腾讯的java编码规范， 结合IBM的编码规范，作为java的编码规范——也是在项目开始后才整理的编码规范。
3. 后台的接口相对比较稳定，前端的修改对后台一般没有影响，或影响很小。

六、完善当前的特性——最重要的任务

在当前功能的可用性， 用户体验没有彻底满足， 将不会开发新的特性， 全力提高已有功能的用户体验是当前最重要的任务，没有之一。

1. 从用户角度优化流程，改进视觉效果。
2. 让用户试用我们的网站， 交流改进我们的用户体验。

七、58bancai全部开源

Evistorm团队决定， 在2016年6月15日， 58bancai网的代码全部开源。