He's Pirate.
thought
敏捷的误区
四 26th
人和交互重于过程和工具。
即便你的团队都是一等一的人才，有着超强的技术和超强的表达力。但是如果过程是一团混乱，并且还没有趁手的工具。那一切依然是扯淡。所谓关注人这个核心生产力是对的，但不是说其他就不重要。
可以工作的软件重于求全责备的文档。
相信很多人鼓吹敏捷就是为了以这条来遮羞。写出同样垃圾的软件，而且还能逃避写清晰文档的责任。多么美好的事情啊。课要知道，真正的程序员所追求的不应该只是可以工作，而是要那种可以工作的非常好的软件，比如架构简单，代码整洁。同时，在你代码无法说明问题的时候，依然需要编写完备适时的文档，来提高维护性。
客户合作重于合同谈判。
这点我不懂，但是我想如果合同都是模糊不清责任不明的，将来出现分歧应该会更头痛吧，我相信，客户总有不高兴的时候，无论你怎么合作。
随时应对变化重于循规蹈矩。
又是看似很合理但很傻逼的一句话，如果你的计划是确实可行，考虑周全的。那么我真得不相信你上哪里来那么多变化，需要不停的应对，即便是软件这个所谓变化频繁的行业。这句话是头脑不清晰，做事不周全的人最好使用的借口。
我依然如同03年刚接触敏捷时候一样相信这宣言本身是真诚的确实有重大意义的，但是这么多年过去了，看着周围各种的绕梁小丑群魔乱舞的，让我本能的已经对‘敏捷’这个词产生了条件反射性的恶心。所以才产生了上面这些诡辩，真的。你们这些的所谓的‘敏捷专家’、‘敏捷布道者’让我看来跟坨狗屎好不了哪去。真比忽悠，宁亚还真不一定是我对手。
网络时代的专业化
四 1st
最近突然发现了很多事情都有一些相似点。
- iPhone受到人们的追捧，并不是CPU和内存比别的手机快多少大多少，关键是iPhone OS的体验和App Store里海量软件。
- 把照片存在flickr，把邮件存到Gmail，免费用光了掏钱就可以随时升级。不用考虑自己添置硬盘，刻录CD。
- C/S程序用的地方越来越少。而大部分情况，一个现代化的浏览器就足够完成大部分的日常工作与生活娱乐。
- 很多web应用开始使用Amazon EC2以及Google App Engine来部署自己的应用。而不是自个买服务器、搞集群。
这是随手列的几点，应该还能找出很多的例子。这些例子基本都是从不同层面消费者的角度来说的。但共性只有一个，就是消费者只应该关注与自己真正的需求，而不是杂七杂八的东西。对于手机而言，最重要的是好用，而不是手机的硬件多先进。数码相片与邮件，重要的是可以随时随地以一种方便的方式来保存与查看。用电脑办公，而不用总是担心用装有什么操作系统的电脑办公，不用担心兼容性和互操作性问题，只要有个好用的浏览器，那么对于大多数用户，linux/win的差别已经不那么大了。对于web开发者，主要关注于自己的业务本身，用code表达出来之后。其他的事情交给第三方could平台去做吧。
这些事情都让我觉得IT开始进一步专业化了，在PC时代，Windows抓住了机会，成为了最流行的平台。而在网络时代，目前应该还刚刚开始。你看，在后台有各种云服务，什么存储阿，计算能力阿，并发阿。在前台，有浏览器，iPhone。而以后，普通的应用开发者，只需要关注于你的业务逻辑以及展现方式，什么伸缩性阿，健壮性阿，通通交给后台的云吧。而专注于提供云服务的公司则是一门心思的提升自己的云服务的质量，从而赢得更多的客户来使用。
当然，在我眼里后台的公司提供的不仅仅是普通意义的什么存储能力，计算能力，我觉得提供数据也是一种平台。你像twitter这么简单的一个玩儿，因为开放了API，促成第三方程序蓬勃发展，各式各样呢。还有刚刚开始支持Oauth认证的Gmail，以及淘宝的数据魔方等等。
所以细分起来，我觉得未来的网络时代主要归为三类。
一类是提供云服务的，包括各种计算能力，存储能力，甚至将来还有带宽能力等。
一类是提供数据平台的，在这个平台下面有很多有价值的数据数据，可以根据指定的API访问。
一类是提供服务终端的，能够占领大部分的普通消费者市场，并且附有一套强大的SDK支援各种操作。
剩下的就是终端上的各种最终应用了，应用可能基于某平台也可能是独立的，应用本身的主要功能集中在展现上。而业务逻辑之类更加耗费资源的任务挪到后端的云中来处理。
所以基于这几点看法和目前的格局。我觉得未来是属于Google和Apple、以及广大有创意有想法的个人、小团队。
Google在三条线上已经是齐备了，从Google Apple Engine到Gmail、GReader这种保存用户大量数据的应用或者叫平台，再到Andriod、Chrome以及未来的Chrome OS。但最出彩的我觉得还是第二天，Google有着很多优良的互联网服务并且都基本有着良好的API开放性。其他两者，前有比较成熟的Amazon EC2，后又有iPhone这么一座高山，还没占到什么优势。
Apple目前最大的领先趋势在第三类，终端上靠着iPhone有着强大的优势，加上App Store，已经基本可以说是统治了未来互联网的入口了。而在前两类产业中，目前还没看到什么迹象。
其他也可以站立山头的我觉得就是Amazon和Twitter以及Facebook了。其中以twitter价值最大。因为我觉得内容为王这点永远都不过时。而内容为王很大程度要依靠内容的时效性。
恩，这就是近期胡乱感想吧。也许有点乱，有点文不对题。但至少自己感觉思路开朗了。我觉得这是一个巨变的时刻，而把握住多的人，就可以在未来更容易立足一些。脚下的路，还是一步步走，但务必保证方向性正确。我很兴奋。
随便聊聊-结对编程的三点看法
三 5th
眼睛一睁一闭，一天就过去了，嚎~~~~
嗯呐，一不小心，就又是好几天没更新blog。时间真的过的太快了。今天开了一上午的会，大伙聊了很多东西，搞的人比较high，这会离下班还有半个小时。任务也提前完成了。所以拿来写篇BLOG吧。
今天呢，就是同事给我们讲了一些Pair Programing的一些东西，算是Agile的一部分吧。当然，像我这种一贯喜欢否定的人总还是会提出很多自己的看法，毕竟，独立的思想与完整的人格我觉得是必须坚持滴。哇咔咔
好吧，不自夸了。今天要说的三点究竟是哪三点呢。请看大屏幕下面继续。
一，Pair Programing不一定就提高生产效率以及代码质量。记得我第一次看完《人月神话》之后，就坚信了一个观点：没有银弹。任何方法论或者所谓的最佳实践都有其自身的局限性，所以你要是给我说一个东西怎么都好，我直接心里就否定了。没有怎么都好的东西，包括现在这么hot，甚至都快过气的Agile这个big buzz word，当然也就有PP这个子集了。因为想起这些我就想起了CMM在很多年前的样子。诚然，Agile是有很多不错的理念，但千万要记得，没有银弹。PP也不可能面面俱到的。比如，性格不合的两个人去PP，互相谁也说服不了谁，结果一个变量的命名究竟是叫love_you还是LoveYou就争执了一上午，导致啥都没干。我主观不认为这会提高任何效率与质量。同样，俩人如果关系特好，互相默契很高，但如果很不专业，在一块躲在角落里偷偷的看《Prison Break》，然后每个小时看一集，再用剩下的不到20分钟时间里随便堆砌点垃圾去提交。这也是敷衍了事滴。再比如，如果你的上级给你们小组4个人每个人分了30个ticket。要求2天做完。这种根本是Mission Impossible的事情。你说这4个人会有心情PP么，会有心情考虑如何帮对方把代码写的优雅，把逻辑写的清楚不？反正我不信。还有，如果说我今天只不过是要修改一些页面上的typo或者是小样式，如果叫个人跟我Pair，他80%的时间里肯定觉得非常无聊。你觉得呢？上面举了好几坨例，有时候两个人会把事情搞的更糟，有的时候虽然不会搞的更糟，但是也会造成效率的浪费。想想Yahoo的衰败以及SINA的收购，过分的民主或者过分的股权分散，其实都是很不好的事情，会浪费很多机会，也会浪费很多时间去扯皮。在PP这里呢，就是PP不能确保提高效率以及质量。
二，一切方法论，包括Pair Programing其实最重要的因素都是人。嗯，确实是这样，从我上面举的例子应该看出来基本都是人造成的PP好用或不好用。其实这基本等于废话，计算机来说1+1等于2那就是定了。人喝多了那他可什么答案都敢说。人本身充满着不确定性，所以，把一切问题都归结到人肯定是放之四海而皆准的废话。可我还是喜欢强调这个，就是因为我发现虽然大家都知道人是问题的根源，但大家却不一定能重视这个认知。我把这个现象叫做‘认知回避’，是啊，谁没事愿意觉得自己这个物种是很不完善的呢。需要改进的呢。但回避也没用，反而后果更大。早点正视这个问题，正视你我包括所有人都有优缺点，都有不完善的地方，都会犯错误这个神一般存在滴事实，是很有益处的。只有你清楚的知道你的优缺点，你才知道如何去改掉缺点，或者如何避免你的缺点所造成的负面影响。好吧，说远了，回到PP，PP其实好处也是一大堆呢，具体的就google吧。可是如果想使PP发挥到如同那些大牛所说的魔力或威力的话，有一个很重要的条件，就是实施PP的人（之所以不说是第一重要的条件是因为第一条件肯定是得有台电脑-_-###）。你想想大牛说的那些魔力威力来自于PP，其实很大一部分也来自于那些人本身。因为他们本身就足够优秀，所以如果配上合适，科学的方法的话。那肯定做出来的成绩就更加的优秀了。所以，你如果想用PP也能收到同样的效果，那有很重要的一点就是除了按照大牛告诉你的最佳实践来实施PP本身，还一定要努力让自己向大牛看齐。包括你的人品，素质，性格，看待问题的角度，理解能力，沟通能力等等。这就好比乘法：PP比如说是5，如果你是2，那么得到的结果就是10，如果你是-2，那么得到的结果就是-10了。现在想明白了吧，PP重要的其实是你自身，流程啊，方法论，书上的探讨了，但是大部分PP的资料都不会讲关于提高你自身的方法，所以，速度补上这块短板吧。不然即便PP再好，你是个-2，那也没辙。
三，客观点，科学点。嗯，今天其实听同事讲PP这个topic，真的是听起来很美，但是最让我感到忐忑的就是没有数据。虽然developers都积极的表明PP提高了很多代码质量，可是从QA的角度就是还没有个数据。我觉得其实数据很重要。否则，空对空，很容易使大伙回到几十年前“赶英超美”那个疯狂的年代。所以，务实点，尽量脱离主观感觉，通过客观的数据来证明一件事物的属性，或者一件事情的好坏，或者一套方法论的可用性。这才是科学的态度啊。所以，我在会上也提了，希望可以量化PP带来的好处。看看PP对于我们的实际帮助到底是怎样的？不能莽撞认为我实施了PP，那PP资料里面所描述的那些个好处，我自然就得到了（想象曾经的EJB，真正让你得到了多少好处呢？）。科学的态度不是这样的，因为不要忘记了，想要发挥PP最大威力，你还得是那个2才行。（参见第二点）。
嗯，一不小心，就说了这么长，其实挺恨自个的，老喜欢跟人抬杠。但是吧，我爱科学啊。科学家最喜欢干的事儿就是怀疑与否定了。所以，对于这些看起来都很美的东西，一定不能让自己一下子就被带进去。不管是SOA, Agile还是最近的REST和SNS。因为真理往往掌握在少数人手里，也许你能多独立思考那么一晚上，你可能就能领悟到比别人更多的东西。同时也能训练着自个变得更加的客观。何乐而不为啊。
咳，老是一不小心就又扯的没边儿。好吧，准备就此搁笔吧。关于PP，其实我并没有深仇大恨，只不过赞扬的人太多了，我就想客观的说点别人没说或者没想的东西。
其实经历过这5，6年的软件开发，真的慢慢感觉出来一个道理：
成功的因素存在太多偶然性，而失败的因素中，很多原因确是具有必然性的，所以关注失败也许是为了迈向成功更好的一种途径。
所以，我现在很喜欢研究失败，研究最差实践，嗯，基本大伙管这个叫-教训。我想也许以后我会多聊聊关于失败，关于错误的事情？哈哈，看我时间吧。
PS：下一篇，准备简单聊下我对项目中各色各样的文档的看法。欢迎拍砖。
最近评论