个人2013年

不知不觉已经工做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，咱们有各路英雄好杰，咱们在美丽的厦门 :)