2016年4月

编程、工作与生活一样,真正有价值的道理简单而朴素,我们在一开始就已经知道,但从来不去好好遵守它。

这些天一直在看和实践敏捷开发,2005年以后,还没有再看过源代码了,现在又在看,并帮助工程师们提高。这个过程中就发现,工程师们对一些编程基本原则的反应是“太理想化”,“确实应该是那样的,但实际因为种种问题是不可能完全做到的”,这些原则“可能并没有那么重要”……

什么原则呢?比如代码应该有高可读性,比如变量命名应该遵循统一原则(驼峰或下划线),比如应该写充足的注释,比如应该做到逻辑代码与界面的 分离(MVC/MVVM)……为了说服大家,我不得不买上几本经典书,把《代码大全》里面的一段章节翻出来给他们看。

然而,这可能并不能起到立竿见影的效果。人们总是知道道理,却却在实践中大打折扣。

在《程序员修炼之道》的中文序言《程序员心里的小声音》中,指出了这种现象,以编程DRY(Don't repeat youself)原则举例,指出“能不能用正确的原则知道正确的行动本身,其实就是区分是否是高手的一个显著标志”。

我觉得这种现象可以称之为编程界的“人格分裂”,知道什么是正确的但不去做或不好好做。

我们每个人或多或少都有些这方面的分裂。全世界人类或多或少都有这方面的分裂。什么原因?对人来说,知道并不等于懂得,特别是实践欠缺,还没有踩到足够的坑来说明不遵循会产生多少问题。

对我国人来说,国民教育环境也促使了这种分裂。思想品德课本上的道理讲着诚实守信,哲学课本讲着全面和联系的观点,历史课本上却讲着和谐过的抗日战争。国家人格分裂,我们每一个人自然而然也跟着一起分裂了。

有什么好的方法治疗?世界上没有银弹,那么路只有三个:一个是按正确的道理办事;一个等自己踩了足够多的坑后再去领悟,“不到黄河心不死,不见棺材不掉泪”嘛;最后一个是,到了黄河也不死心——彻底没救了。

前两天看新闻,真的有这个地方,真在中国,真的焚尸炉。就这个月开业,开业日期是清明节。这就是上海的4d死亡体验馆。

写遗嘱,进棺材,遗体告个别,然后丢进焚尸炉。哦,叫火化炉好了,焚尸的感觉好像对我们自己的尸体不够尊重一样。

据说还不少人,想“死”还得排个队。不过中国现实更有趣,那个放盒子的地儿太贵,可能还死不起。

开设的体验馆的人有心理学背景,焚尸哦不对火化完之后还安排了投胎转世的重生环节,把体验者的心理重新拉回人世。

这家体验馆正式名称是4d死亡体验馆,不少媒体报道时变成了生死体验馆或者生命体验馆,这或许就是人对死亡有意无意的回避态度。

不知怎么,一讲到生死,我想到了两个哲学命题,一个是加缪的西西弗斯,一个是叔本华的钟摆。前一个每天推石头上山,石头石头推到顶又滚下来,因为太无聊也毫无意义,西西弗斯变着花样推,每天都给自己找点儿乐子。后一个说,人生满足了就无聊,无聊了就没事找事,找到事了就痛苦,一辈子这两种状态,像钟摆一样摆来摆去,不是在去无聊的路上,就是在去痛苦的路上。一个是瞎乐观的无聊,一个是穷悲观的无聊。这就是没事找事的人生。

这里一篇文章http://developer.51cto.com/art/200906/129424.htm

不过蛮啰嗦的,写了那么长……

rest就是要无状态,sessionid就是要保存状态,当然就不restful了。需要在每次请求都发送认证信息,才可以restful。

为什么要无状态?这样每次请求可以独立测试啊。

别的好处自然是,服务器很容易做分流了,服务器之间也解耦了。

今天去听了一个干货满满的讲座, 解答了我的一些敏捷的疑问, 也更加确定了我以前的一些想法和做法.

这次由leangoo和scrum中文网组织的讲座, 主讲人是廖靖斌, <<Scrum敏捷软件开发>>的第一译者, 也为很多公司做过内训, 经验丰富.

按讲演的顺序谈谈体会:

一. 敏捷思维

这个包括三部分:

* 价值驱动. 这一点就是要交付, 并且尽快交付有价值的东西. 这次的更深体会是, 一切有价值的需求都是驱动力, 不只是产品, 还包括技术需求, 测试, 重构, 改BUG, 甚至撰写文档.提到一个Zappos的典型案例.

* 适应变化. 这个主要是快速迭代了. 大家并不陌生.  内涵包括频繁交付, 频繁确认, 频繁交付正确成果. 后面两点, 是需要自动化测试, 持续集成保证的了.

* 自组织团队. 这个以前并不够关注, 也没有足够的方法. 这里面提到, 将用户与团队直接对接的重要性, 举了小米的例子, 要求开发团队每天要泡45分钟论坛. 目的是对用户的使用情况有直观的感受.

讲到从契约模式到共享责任这一点, 我们猫宁团队目前还在很努力的去探索. "一荣俱荣, 一损俱损"的方式.

二. SCRUM框架和流程

包括三个角色: PO, SM, 开发团队, 大家一条船, 又是讲前面的 "一荣俱荣, 一损俱损".

三个工作: 产品Backlog, sprint backlog, 燃尽图.

里面比较有感受的是四个会议+1, 分别说一下:

* +1 的会议, 是需求准备的会议, 在开Sprint计划会议之前几天, 提前将准备好的需求,UI,UX等, 与开发沟通清楚. 不清楚的需求补充好, 或者不在此次开发.

* Sprint计划会议. 对应我们猫宁团队, 就是每次迭代前的需求讲解, 用户故事划分为任务,  然而又有几个重要不同: a. 计划会议大约2~4小时, 需要在会上确定前后台接口, 将用户故事划分为任务, 按优先级依次排列用户故事. 但不去确定谁来开发.

* 每日站会. 15分钟内. 这个会议上才去确定谁去做哪个任务. 非常重要的一点是.A. 大家要按优先级去做用户故事. B. 大家要做同一个用户故事, 交付后才能一起做下一个故事 C. 大家自己领取任务, 做完了再继续领取别的任务. 哦, 可是我做IOS不会Java后台啊... 这里提出了要去学习其他的能力, 帮助其他人做事情, 从简单的文档, 测试等开始做起.

* Sprint评审会议. 这个目前我们没有做. 举了个例子, 某个北京的公司 , 周五下午, 老板什么也不做, 就是看各个scrum团队讲这次迭代开发的内容. 全公司其他人有兴趣的都可以参加, 包括市场, 销售等.团队要解答参加者提出的问题. 评审前, 要将产品发布到预发布环境中, 也就是上线前的测试环境.

* Sprint回顾会议. 团队内进行的查漏补缺. 在下一次Sprint时候改进. 这一个我们目前也做的不够.

三. 用户故事地图

我们之前用的是需求池, 感觉结构上类似. 用户故事地图更好的地方在于, 横向上再次用用户角色进行划分(不同泳道), 并且将用户的业务流程从上到下依次排列. 业务下面再划分用户故事. 其他纵向的按Sprint划分, 与我们现在按版本划分差不多.

四. 其他

* 可视化协作. 看板放在一个人人都能随时看到的地方非常重要, 对所有人都有很好的督促作用. 所以他建议买一个大电视一直用来放看板. 而且也确实有公司这么去实践了.

* 自动化. 自动化是解决技术债务的唯一方式了. 把那些无聊的重复的工作都自动化了吧! 不用再有疑问了.

* 文档. 目前出现的接口文档和实际接口不一致的问题. 那么把文档也作为验收标准, 作为需求的一部分吧!

Powermockito对java代码可以进行静态方法的Mock. 用于junit单元测试, 但由于依赖问题, 在运行Junit时候, 会遇到Initialization error
一般见于Powermockito <1.6.1的版本和Junit<4.12的版本.
解决方法: maven中修改依赖为:

<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-api-mockito</artifactId>
  <version>1.6.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.powermock</groupId>
  <artifactId>powermock-module-junit4</artifactId>
  <version>1.6.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>4.12</version>
  <scope>test</scope>
</dependency>

即可

参考:

http://stackoverflow.com/questions/26192929/unable-to-run-junit-test-with-powermockrunner