不知不觉已经工作4年了，博客也荒废了多年，今年对于我来说是个不可思议的一年，项目也已经成功上线收尾了，是时候给自己总结一下这一年的得失，也希望这篇博文能给大家带来一些新的想法与方向。
生活上
从国内来到了国外，想念家人、朋友、食物，但并不想念雾霾、地沟油、三聚氰胺、瘦肉精、挤公交...
国外确实是蓝天白云，空气很清新，大部分人都很有礼貌、很有秩序，公交师傅会和每个上车的乘客问好，马路上的车辆会停下让你先过，可能与生活节奏有关吧，国外的生活节奏没有国内那么快，也没有国人那么勤劳。感觉国人每天都很着急，公交师傅会着急让你上车下车，快递员会着急让你马上签单，听到最多的一句就是“赶紧啦”。
工作上 （感触）
感触一：专注眼前，跌代更新
当什么都想做的时候，团队会很容易失去重心，很多事情会做的不好。
Scrum: 不要同时忙于多个user stories，请先专注于把当前user story完成后再去观注下一个user story，一条小河两条船并进比四条船挤来挤去要快。
Agile: 先专注眼前，没有关系的，产品是跌代出来的，当然架构还是要有的。
感触二：持续学习，持续进步
客户公司开发组小于30岁的应该少于1%，在国内应该会很少见，但他们始终保持着对新技术的关注，跌代升级开发框架。
感触三：文档化
对于公司来说，一个文档化的平台可以减少人员变动带来的风险，比如讨论issue相关问题，那就在issue页面上讨论，这样会给后面维护的人员带来很大的便利，Email/MSN/Skype/QQ随着人员变动容易丢失。
知识积累也类似，一般公司会有一些技术分享会或者新技术的探讨，如果都可以文档化那会对新进员工或者缺席员工带来很大的帮助。
感触四：多陪陪家人
要有自己的私人空间与时间，不要把自己的所有时间都放在工作与代码上，多陪陪家人，放假就好好放假，把工作邮箱设置成自动回复。
应该把加班当成不正常现象，而不是正常现象，加班应该是很糟糕的事情，但感觉很多博友把这个当成是正面的东西，让我很不可思议，当然你下班回家去学习一些新技术那是另外一回事，庆幸我们公司这个问题比较小。
工作上（新名词）
这一年接触的新东西太多了，下面总结下我觉得比较有价值的东西，可能对于一些朋友来说已经不新了
Scrum, Agile
每天早上的站立会（15分钟左右，回顾昨天，打算今天）
站立会让团队成员工作更紧密，可以让项目经理了解团队进度及时调整工作安排。
每周一关于这个礼拜的规划会议（1到2小时，讨论user story与估分，最终的分值其实并没有那么重要，重要的是让团队成员间打成共识，更加了解user story）
每周五的回顾会议（1个小时）
回顾过去才能更好的展望未来，这个礼拜做的不足的地方，团队成员达成共识，选取最多人提到的两点不足来改进，因为人的精力有限，当什么都想改进的时候可能就会什么都没改成功。
Team Board
为了让任务清晰可见，我们引入了Team Board（白板）
1. TD (Technical Design)
2. TEST BASE (开发人员与QA对user story达成共识，QA输出测试用例)
3. DEV（开发中）
4. CODE REVIEW（开发人员之间互相review代码，结对编程可省去code Review）
5. TESTING (测试中)
6. PO REVIEW （产品经理review）
7. SHIP TO TRUNK (合并到主分支)
8. ACCEPTANCE
9. DONE
（在博友曹宗颖《敏捷中的沟通与故事点》的文章中我有更详细的评论，如果有兴趣的朋友可以看看 http://www.cnblogs.com/czy/p/agile_communication_story.html）
TDD，jMeter, Selenium, TFS
以前做的项目周期一般较短，所以很少会去写单元测试，这一年都专注在 API 开发上，所以就需要单元测试来保证原有功能在持续跌迭的开发过程中始终保持正常，如果多团队基于同一个代码库单元测试的作用就更加明显，因为会经常出现其它团队修改了相关代码，影响了你的功能，单元测试是第一道防线。虽然还没有真正测试先行，但这一年也一直保持着测试后行，项目单元测试覆盖率也始终保持在90%以上，对待单元测试的观念也发生了微妙的变化。
单元测试始终是代码级别的，jMeter是一个很好的API测试工具，因为它关注在API request 与 API response，可以灵活的Follow request，构成了我们的第二道防线。
Selenium专注于UI层面的测试，也就构成了我们的第三道防线。
单元测试 + jMeter + Selenium都通过 > TFS build绿了，那恭喜你了，发布到LIVE吧。
DDD
项目业务逻辑复杂，需要很多领域知识，多亏了DDD，domain看起来很直观，不过IRootAggregate<>在后期的维护中容易被滥用，比如碰到要查询非RootAggregate实体的时候有时会出现直接给domain加个IRootAggregate<>接口然后用上repository。
TFS, GIT
Trunk branch (主分支)
Team1 Main branch (Automated build-deploy to Team1 DEV server)
Team1 Feature1 branch (Local)
Team1 Feature2 branch (Local)
Team2 Main branch (Automated build-deploy to Team2 DEV server)
Team2 Feature1 branch (Local)
Team2 Feature2 branch (Local)
这是我们使用的TFS分支结构，有个缺点就是QA想要测试Team1 Feature1，他必须切换到Team1 Feature1 branch然后本地运行程序，给QA带来了很大的困扰。如果合并到Team1 Main branch部署到DEV server测试，那如果发现BUG就会Block其它Feature合并到主分支。
GIT的分支结构与TFS不同，并非树状结构，所以可以很灵活的绕过这个问题，我们已经在其它项目中使用了 :)
Visual Studio database project, Liquibase
多人协作开发基于同一个数据库冲突在所难免，比如开发人员A 在 Team1 Feature1 branch上修改了数据库结构和代码，开发人员B 在 Team1 Feature2 branch上开发其它功能时就会容易碰到异常。
如何避免这种问题呢？我们可以使用 Visual Studio database project 来维护数据库结构的变更，然后开发人员可以使用 local database 进行开发，如果你需要一些更高级的功能，比如Tag, Version，Rollback那你可以考虑使用Liquibase但需要学习Liquibase的语法。
Web API + HAL JSON
发现园中大佬 Artech (http://www.cnblogs.com/artech) 在写相关的技术文章，博友有福了 :)
应该说Web API的使用上我们并没有碰到比较麻烦的事情，但在跨域问题上我们还是发了一些力气，IE, Chrome, Firefox, iPhone (xx), iPad (xx), iPad mimi (xx), Android (xx) 更种行为你懂的。
比如：IE在跨域的情况下无法获取4xx, 5xx状态下的response，Android 和 IOS 5在跨域的情况下无法支持 302 / 301 重定向。
HAL JSON标准的理解与实现上我们也发了一些力气，但实现出来的API对前台开发人员更友好易用，适合复杂度较高的API，API间互相联系而不再是孤立的个体，API已经可以自描述了。
Logging
以前经历过的项目复杂度较低，只是log程序异常而已，也没有碰到什么大问题。
但当业务逻辑复杂度较高时没有详细的log信息，debug难度可想而知，每次都需要翻阅代码才能定位问题可不是好主意。
你可以想象下：
当用户在LIVE上做了一系列操作，然后打电话过来告诉你，为什么我的支付页面打不开，然后你和QA努力尝试重现，但每次都可以正常打开支付页面是件多么郁闷的事情。
你会开始怀疑用户，怀疑人生，然后用户为了证明自己的清白，截图给你看，确实是个自定义错误页面，里面显示你的页面出错了，然后你翻遍log去寻找异常信息，却得不到足够的信息重现问题，询问用户如何重现，最后用户自己也重现不出来了，说自己可能点了这个，然后填写了那个，blabla 然后就挂了。然后就不了了之了，等待下次再被投诉或者流失用户。
当你遇到过以上情形时，那恭喜你，你碰到了一个好用户，正常情况下是运维人员在LIVE上看到了异常，直接让你研究去，如果你可以在异常log记录中找到用户唯一识别，然后关联出该用户的所有操作记录，这是一件多么酷的事情，那运维人员也可以从log中看出一点端倪。
BI
如果你有了以上完善的log，你会发现，你可以识别出用户了，你记录了用户的各种操作，是不是可以分析一下用户行为了呢？做些统计分析了呢？
如果你对新开发的功能或者页面在生产环境上的表现情况一无所知，那这是一件多么沮丧的事情。
Settings
如果你的公司拥有多个子公司，或者你的公司拥有多国站点，然后你的程序中遍布if else，或者你们可以考虑独立的配置系统，你可以设置默认值，然后在子公司级别或者其它语言级别去覆盖默认值。
配置系统在不同项目间的复用度还是非常高的。
Rules
我见过很多电子商务系统一直努力的往他们已经很复杂的产品编辑页面继续添加新的checkbox，是否显示A，是否显示B，是否显示C，然后点开一个checkbox又会展开一堆的textbox或者dropdown让你填，我只是想加个简单的产品而已，不要这么折磨我吧。
这些checkbox可以独立出去吗，因为我商店的1000个产品中只有10个产品会碰到这种需求，如果这些checkbox看起来更像规则，而不像产品本身的通用功能，那我们是否可以独立出去不放在产品编辑页面？
2014年我会继续努力，2014年你呢？加入我们吧 http://www.kooboo.com/ 我们有阿不，我们有JS神人ppchen，我们有各路英雄好杰，我们在美丽的厦门 :)
