对于在日企工作的反思

今年进入日企外包，在项目中学习到很多东西，也遇到很多烦恼的事情，但是可以学习下他们开发的思想和模式。

首先介绍工作的环境首先是一系列的协同办公工具：

1.Redmine 是一个基于web的项目管理软件

2.Zeplin是一个前端与设计协同软件

3.sourceTree是一个Git客户端管理工具

4.Slack是一个企业聊天工具

然后是一系列的文档

1.开发参照资料（主要是一系列的需求采用图文并茂的方式）

2.画面定义书（也就是大家常见的UI设计图-很详细的介绍了页面走向和展示细节）

3.API接口文档

4.UI设计PSD图（PS底稿）

项目开发采用敏捷开发

转载自uxyheaven：

http://blog.csdn.net/uxyheaven/article/details/49618097

在项目中每个迭代周期为2周一个迭代，对接时间为一周一个迭代。
下面我说下我在开发中的一些感受：
一.交流。
1.任务安排模式：
在工作中使用Redmine安排任务，每一个任务（task）都会有不同的类型（type），大致分为story（新功能）、bug（修改Bug）、ameliorate（改进功能）、other（其余杂项），每个任务都会固定的格式(task 6520-bug6533)，每天结束后都会以task编号发送日报。
- task（任务） 6520
- story
- bug
- ameliorate
- other
2.项目标记
在项目中推崇团队开发理念，在项目中每一个命名，每一个空格、每一个换号都有极高的要求，在文档上都有固定的格式和规范的说明方式。
例：在每一个主页面上除了注释都会有一个页面的标识，在交流中都会以页面的标识来作为这个页面的名称而不会说具体的类名，而且在日常工作安排中也会使用页面的标识来安排具体的模块。每一个模块的UI设计图+代码+后台接口都为同样的标识，这样就能很方便的获取到这个模块从设计到开发完成的所有信息。
标识格式为：模块简写+页面编号+页面子编号

/*
 * 主页面
 * [H-P3—1]
 */
 public class MainActivity extends BaseActivity {
 }

3.文档
在这个公司你能享受到完善的文档带来的快乐，也能体会到写问题的蛋疼。。。。对的是蛋疼！在代码中除了类名和方法名和属性名需要加上文档注释（以后会导出文档），而且在开发中很多细节需要进行文档留档，方便以后版本迭代（注：有多个版本，新的版本在开发，老的版本需要维护）。后台的API接口文档和前台开发参照资料+版本说明书。

二、协同
1. 使用Redmine处理和 完成任务
每个一个task（任务）都会有问题描述、问题过程、期望值，让人能很清晰的知道你当前的任务是什么！ 也会有一些状态（目标版本、优先级、完成进度、指派角色等）
2.问题交流（Slack）
在项目中遇到需要交流的问题都会在GitHub中留下回复或者使用Slack发出一个提问，但是有一个特定的格式，比如页面问题会带上页面的编号+问题描述很多时间带上了代码截图然后以论坛方式提问和回复！
3.Zeplin（设计交流）
在项目中使用了Zeplin 我才知道这样一个神器（以前公司使用的DesignBoard），它可以看到每个设计图并且可以查看每个组件之间的间隔数值和组件的长宽高，很直观的了解整个页面的参数。

总结：有了上面一系列的工具和规范，公司进入一个新人也能快速的了解整个项目。但是在工作中也增加很多费时的工作量，其实个人感觉这样的开发模式对于开发者来说完全是一种折磨，写10行代码就需要一抹的的文档。但是也可以学习下他们遵于规范、看重细节的思想，没有规矩就不成方圆。