Rss Feed

嘉瑜的知性探索

2011年梦想主色调：书、茶、咖啡、红酒、运动、日记、音乐、自制美食、干净明亮的房间

Archive for '码农日记'

MSS 2010 学习手记

June 15th, 2011 by , under 码农日记. No Comments

欠债，

  • MSS的配置方法

以下为MSS的相关资料

MSS API及SDK文档：

教学文档：

内容爬取相关：

记一次jQuery+WCF页面的离岸协作

March 12th, 2011 by , under 码农日记. 2 Comments

背景：与美国某公司的一个离岸外包中的一个页面，最后交付物为，20来多存储过程，4000行左右的C#代码量，2000行左右的JS代码量，数个文件，7个jQuery plugins，参与人员及职责：

  • BA一名（美国方），负责把握进度、控制风险、阐述需求、解答需求问题。
  • Application Developer（美国方技术接口人），负责建议/帮忙解决开发中出现的技术疑问，负责C#及SQL Code review，审核代码质量、安全性和性能，负责性能测试。
  • jQuery前端开发人员（美国方），是临时从另一个项目中调派过来的，负责所有前台的代码，包括jQuery及插件的使用和选择，与BA沟通确定方法接口，负责解决客户端有关的性能问题和BUG修复。初期稳定后，会撤离项目组。
  • C#和数据库（我），负责所有的C#、WCF和数据库相关开发，BUG修复，稳定后的维护工作。

难点：

  • 离岸协作，16小时时差，即美国上班时中国在睡觉，所以基本都是美国方在加班与我进行协作，通常都是他们晚上9~11点，我这儿中午12~1点。
  • 代码交付问题，尤其是前后端的衔接非常紧密，所以若有一方因为代码交付问题，另一方则会完全被stuck住，风险较难控制。
  • 由于使用典型的敏捷迭代，所以时间的要求上其实很急，规定上线时间根本没得商量，如果不能完成只能等下一次迭代。
  • 各种新技术：采用全新jQuery dataTables展现grid，后期使用线上数据库才发现性能完全不行。性能测试不足，出现之前没有预料的问题。
  • 沟通，我这边的老大曾经建议过直接onsite开发，不过美国方没有同意，这个页面因为需要无间的配合，所以对沟通的要求其实很高，我们后期是采用的每日~每两日一次会（会经常持续达半~1个半小时，有几次甚至达到了2小时，包括我和前端讲述头天已完成项，整理BUG完成情况，讲解新发现的BUG，指派新BUG的负责人，列出明日交付计划等等），每天必须使用邮件来更新开发进度并列出明天的计划和交付。倘若交付出问题（也确实出过），整体交付的日期会延迟。
  • 整个过程使用英语沟通。
  • 其它。

整体页面如下:

2011-03-12_183720

我们的协作方式：

  1. 由BA确定需求时，对方技术负责人告知前端与我的技术需求、扩展和重构，
    我之前从来没用过WCF，我需要在这期间做出WCF POC，更新我的auto-complete控件使之支持WCF，
    前端需要了解dataTables等相关技术。
    （耗时一周左右）
  2. 初步需求文档，列出主要web methods，当时一共只有15个，在这段过程中web methods的命名和需求往返超过不下于8次
    前端给出后台需返回的JSON结构及request参数等。
  3. 任务分解。
  4. 前端进行页面代码的初步编写和插件研究；我同步进行数据库设计，后台代码框架等，并做出几个初步的web methods，准确代码合并。
  5. 第一次代码合并是比较痛苦的，因为前端会改我的后台代码，他本身也懂C#，这样我们经常会有代码冲突，于是此时美国的技术接口人提出了协作原则，洋洋洒洒一大篇，即双方不允许互相修改对方代码。我补充说，希望每天有一次进度汇报，包括change log、明日计划、needs等。
  6. 第一次合并后，发现问题很多，比如我写的web method对方不能使用或出错，第二次我就开始做unit testing，每个方法都使用Nunit进行过单元测试，这样大大提高了我每日后台代码的交付质量。
  7. 在开发阶段，每天会有一次这样的报告，发现BUG会及时汇报，每日back and forth不下于5次，好在美国方总在晚上8~11点能联系到（即中国时间早10点~中午1点），所以这期间能clarify很多疑点，总之每天计划都能完成，第二天另一方会收到相应的代码更新。
  8. 开发近一周半后，第一个版本发布到DEV服务器上，初步测试开始，BA生成简单的excel文档记录BUG清单，excel包含2个sheet，一个列出bug，一个列出尚未实现或打算实现的功能。每天会有一次电话会议，来确定这些BUG的负责人，并写上计划完成日期，每日有更新。每日会有一次构建，都会在DEV服务器上发布新版本以供BA测试和检验BUG修复情况。新BUG仍然会有层出。这个BUG清单最后有80来条，各种大大小小包括performance和页面布局问题等。
  9. 第二次成熟版本发布后，对方使用线上数据库（dune版）来做性能测试。性能测试的结果，比如：loading会有timeout的错误，正式发布前都有处理。
  10. 全部的回归测试。
  11. 发布上线。从协作开发到第一版本上线一共耗时一个月整。

关键词：

  • 任务：任务分解、初期需求不必完美、过程控制、任务负责人清楚明确
  • 沟通：每日进度汇报及计划、快速跟进修复BUG、积极响应、频繁会议、清晰沟通、无情绪沟通
  • 测试：单元测试、性能测试、集成测试
  • 交付：严格遵循不修改对方代码、bug tracking、遵行每日计划交付目标、后期每日构建、允许迭代

遇到的技术难点：

  • 上线后，当即发现另一个性能问题，因为使用jQuery datatables我们当时并没有做服务器分页，所有filter和pagination全部客户端，即提交查询请求后，从数据库返回全部数据（比如5000行），形成庞大的json串会导致出现script无法响应强制终止脚本的提示。BA当即只能决定将先只返回800条查询数据，在第二次迭代中再想办法提升。
  • 另一个性能问题就是左侧层级列表，数据量不少，页面载入后，分别有左侧4个及右侧3个widgets的数据需要异步载入，第一次访问页面的速度很慢。使用cache也不能很好解决这个问题，只能将左侧jstree做成服务器端异步提交显示。
  • end-users的反馈很强烈，很多人使用得不习惯，很多抱怨和反馈纷至踏来。
  • 很多东西都必须改，第二次迭代开发开始。

我们开始第二次迭代：

  • 所有存储过程都需要分页，问题比较麻烦，因为存储过程和C#方法有27个之多，如果每个存储过程都必须加上7个参数（startFrom, limit, sortBy, totalCount, Archived totalCount, etc)，每个接口也必须如何加上7个参数，所有方法都需要动。
  • 左侧jstree需要改动。
  • 更多performance tunning。

我们开始第三次迭代：

  • 由于客户端已基本稳定，前端退出开发团队，我继续进行维护工作，并需要了解所有使用到的前端技术和jQuery插件等。客户反应渐好。

总结：

  • 深刻感受到西方的敏捷开发模式和沟通方式，很受启发，很喜欢。
  • 交付质量和承诺至关重要，否则一天的耽搁，可能会引起两到三天的延时，严重者会使进度失控。
  • 一个小遗憾：我做出的WCF其实并没有体现WCF data contract的优势，仍然返回JSON串，可是时间太紧，一直没有去解决这个问题。也是后期想要解决的。

Tags:

Stack exchange上的高投/趣题

March 10th, 2011 by , under 码农日记. No Comments

读书类

编程语言类

灵感类

应用 & daily work类

工具类

有趣的

面试

Tags:

2011.March Links

March 9th, 2011 by , under 码农日记. No Comments

趣读

架构

ASP.NET/数据库（后台）

MVC,  Castle

nHibernate,   StructureMap

团队、Scrumb

jQuery/脚本（前端）

其它（临时）

技术博客

关注图书

各种点滴：

  • 在此文中的评论看到一句“Also keep in mind that the .d is there for a reason. Avoiding unwrapped JSON arrays does legitimately defend against a certain class of cross-site attacks.”原来是这样… 当初总是不明显为何ASMX的JSON返回的总带着.d，原来是为了防止跨站攻击使用未经wrap的JSON串吗…有空研究研究，现在去sleep!
  • 工作中关于每日备份的问题是否有过思考呢？前段时间听闻老大提到system admin/ DBA有每日备份的习惯，倒是真的很想学一学，2年前曾看过一篇DBA注意事项大概是60条，里面有不少都谈到了每日备份和工作项目，还有译过（可惜没找着…）。 what r the daily responsibilities of u as a system administrator

静下心来思索，决定放下所有链接一个月，安静读本书。就读高效开发的那个？

Tags: ,

读微博小感

March 9th, 2011 by , under 码农日记. No Comments

我觉得我还根本没能知道TDD究竟是个什么玩意的时候，我只体会到那种由上至下、由大到小所带来的好处，一天的开始，如果能够给自己10分钟左右时计划今天需要做什么，那比一上班就抓着头天留下的工作，感觉上，要强上很多。去年老大偶尔会提到“写design document”，我觉得写design doc真的是挺耽误时间而且蛮马后炮的事，因为我还没有学会如何在开发之前就写清楚design doc，而我总是将它做成了软件文档，所以我觉得那些文档化有时性价比实在不算高，特别是我这人有完美主义的弊病，所以容易浪费大把时间，很心疼。我在这次quote时，尝试着自己“偷偷”用了一种test-fist的概念，我在想，虽然BA将需求将SPEC已经细节到了牙齿上，可如果能自己按照这个流程，写出简单却尽可能全面的test-case，那这个quote就真的不是在“走过场”，纵观全局，这感觉就象站在了小上坡了，就象看书要先看TOC，就象画画要先描轮廓，这样我写代码的时候，就能做到胸有成竹了，而且事先的impact analysis，即使好像是在double work，不过从后期来看，用老大的话说“未必真的比你不做这些分析文档用掉的时间多”。

工作中，有很多东西都需要自己时刻用一种重新审视的态度，偶尔学会批判自己，这样可以从不同角度来审视，就象几个思维在内部brainstorm一样，很崩溃很分裂很浪费时间很高压，不过收益是有的。近来在新浪微博、博客园和InfoQ上，真的有看上很多让我惊喜的内容，体会到忙碌一天后，微博快速阅读与分享所带来的便利。摘抄今天刚看到的，如下：

@李开复：网友问如何提问才是好领导：1）愿意承认“我不知道”，2）鼓励提问，3）解答的过程才是重要的，不是寻找“正确的答案”。4）正面提问、鼓励性提问，5）专心听，不要打断，正面回馈， 6）避免质询，问“这是谁的错”，7）记得常问：“我可以如何帮助你？”，8）用开放式问题，引导员工自己解答疑难。

@王晓明同学：不但领导，每个团队成员都要做到。增加四条交流时候的注意事项：1) 避免过早定论，“这样设计肯定不对”；2) 通过5Why来寻找问题本源(root cause)，最终帮助团队找到针对本源的解决方案；3) 淡定； 4) 遇到跑题的情况要及时打断，“我们来focus眼前这个问题，您的观点很有价值，我们稍后讨论”

我自己有些很严重的问题，我在过去这大半年，我在很有意识的争取去避免，争取最后能够开成习惯，

  1. 我是属于一说话就停不下来的人，而且说话会非常快，似乎是急着将自己的想法全盘脱出，我将这种思想筛选重组的过程给略去了丢给了listener，而且经常就喜欢用brainstorm的方式说话，想到就说，好坏不论。我一点都不害怕说出自己的不足，甚至不害怕表露自己的缺点和成长中的那些扭曲和蹒跚，有时我也会想，这是不是一种正确的说话方式。
  2. 我有个非常大的毛病，就是不喜欢one time one thing，比如对方在说A的时候，我很容易把注意点又分散到B，当然A和B是有关联的，不过在当时的context下，B是可以“暂缓再议”的，我这一点，就好像把议题给跑了，遇到这种情况，如果是和WY开会，她会非常果断的将我拉回来，她会说“one time one thing, let’s focus on this now"。
  3. 老大曾不止一次的说过“you’re not a good listener“，我开始其实蛮不懂的，因为我比较喜欢打断别人，去年年中以前，我这问题非常明显。我当时总固执的认为我记性很不好，你在说话的时候，我灵光一闪就必须扔出来告诉你、打断你，你得过会再接上去，这会我一定要表达我的见解。后来我思考过很多次，觉得打断别人不止是不尊重了，更有可能是失去了听取别人的意见的好机会。我将签名改成了“想要打断人家说话时，就咬住自己的舌头”，不过舌头后来的确是没有咬了，可好处是后来我都会很有意识的避免随机去打断任何正在表达自己见解的人。

不过这三点，我都还在不断的修正中。至于5 why，这东东我有09年底研究过的，觉得非常有趣，指的是问为什么要刨根，一直问到第5个，随便来举个例子：

场景一：这个为什么(1)会出错?  因为我改了。你为什么(2)要改? 因为我觉得它不好我想重构。那么为什么(2)BA没有测到? 因为我没有做完整的impact analysis而且没有告诉BA。你为什么(4)没有告诉BA? 因为觉得这个改动很小，我顺手可以做了，而且我以为它会没有问题的。

这样一步一步刨根问底，就可以发现一个表面简单的问题背后更深层的原因，这样就能更早发现问题，更早收集缺陷。以能得到及时改进 – 不管是从认知、流程、沟通、工作方式等方面。当然我举的这个例子实在太小了点，如果真要有人有个BUG我要这么的刨下去，问题没怎么发现，倒把人给刨走了。其实在自我管理、anti-pattern, anti-management的团队中，这种过程倒更多的是应该用来省视自己。所以可以将它改成这样 –

场景一（改）：这个为什么(1)会出错? 因为我改了。我为什么(2)要改? 因为我觉得它不好我想重构。那么为什么(2)BA没有测到? 因为我没有做完整的impact analysis而且没有告诉BA。我为什么(4)没有告诉BA? 因为我当时觉得这个改动很小，我顺手可以做了，而且我以为它会没有问题的。

这样的话，效果是不是会完全不同呢?

@王晓明同学：分析一下我们的开发慢的原因：1. 产品经理想一步到位，在concept没有得到用户验证的情况下过度开发；2. 缺少必要的需求分析，很多需求没有想清楚；3. Dev没有强烈的质量保证观念；4. Dev不关注细节；5. 没有遵循敏捷原则Simplicity–the art of maximizing the amount of work not done–is essential.

这个“过度开发”的说法太有意思了，我非常的感同身受。就是我在第一段中说到的另一个问题，我经常喜欢看到有点挑战性的工作，就当即磨刀霍霍的开干起来，通常有时那个resolution客户都没有正经确认，如果这个阶段还在anaylsis，还在确定这次iteration的backlog时，我就动手开始做了，甚至有次有觉得legacy code太丑看上去看难看，所以直接把它大刀阔斧的给重构了下，我根本没有获得BA的反馈和确认，其实这就是一种“过度开发”，过度开发，在我身上表现出来的结果，就是BA很无奈，你告诉她你已经做了，她会需要为了catch deadline重新调整自己的需求来适合你，打乱很多事，我记得WY曾经和我说过“your intention is good, but as a BA, I can see farer than you”，还提到，"you’re develop a long-standing project, there maybe has a lot of legacy code which are bad,  but please stop it first“这话说得太棒了，后来我又看到一篇文章，里面讲到这种coder恰恰是最可恶的，因为他好心的随手重构了下，可是未来可能带来很难troubleshoot的BUG，这问题，我经常犯，比如我觉得以前的一个popup小公共方法没有把窗口居中，我觉得很难看，就随手给居中了，结果后来另一个页面就看上去完全不是那么回事。所以我后来一直在克制自己，尽量从客户角度思考，而不是凭自己喜好局限在自己的思维里。这又得提到design doc和test-first的优点了，如果先有全局思考，则会比较少的限在这些局部问题中，而是从大局出发，考虑全局。（关于这个，我依然还在学习和思考中）

@王晓明同学：技术人员通常会犯两种错误:1. 学而不思，比如网上看到一种新颖的设计就建议在自己的产品上应用，没有考虑使用场景，用户需求及所面对的问题。2. 思而不学，比如遇到一个问题即刻冥思苦想，尝试各种方法来解决，其实最简单的办法是看这个问题是不是有人解决过，直接利用现有方案即可。即学且思才是王道。

@王晓明同学：有两种“聪明”的领导。一种是“Smart”，智商超长，任何事情喜欢亲历亲为，喜欢团队按照他的方法做事，追求完美，关注细节，关注过程；另外一种是“Wise”，喜欢聆听，提供辅导，帮助团队建立流程，利用工具，使团队可以自组织的完善流程，做好事情，更关注结果。你喜欢哪一种？

@王晓明同学：沟通能力(或者说影响能力分4种):Persuasion, Assertion, Bridging 和Attraction。演讲使用Persuasion和Assertion的能力，是让听众可以接受你的观点，并且信服。日常的交流主要使用Bridging和Attraction的能力，为了可以更好的理解大家的观点，并且使团队达成一致。交流能力是资深开发人员的必备技能。

容易成功的10种能力：1.解决问题时的逆向思维能力 2.考虑问题时的换位思考能力 3.强于他人的总结能力 4.简洁的文书编写能力 5.信息资料收集能力 6.解决问题的方案制定能力 7.超强的自我安慰能力 8.岗位变化的承受能力 9.勇于接受份外之事 10.积极寻求培训和实践的机会

虚拟座谈会：TDD有多美？

再谈敏捷和ThoughtWorks中国咨询师

TDD的学习资料

书：

  • Kent Beck的“测试驱动开发”
  • Martin Fowler的“重构”
  • Bob大叔的“敏捷软件开发原则、模式、实践”和“代码整洁之道”
  • Michael Feathers的“修改代码的艺术”
  • Gerard Meszaros的“XUnit模式”
  • Roy Osherove的“The Art of Test Driven Development”
  • Steve Freeman的“Growing Object Oriented Software Guided by Tests”
  • Eric Evans的“领域驱动设计”等。

视频

  • 到Google去查Kata
  • James Shore的“Let’s Play TDD”系列

Tags:

开发小海绵之11年3月记

March 8th, 2011 by , under 码农日记. 5 Comments

1. using 语句在离开自己的作用范围时，会自动调用被“使用”的对象的 Dispose

2. SqlException 严重程度等于或小于 10 的消息是信息性消息，它们指示由用户输入信息中的错误所导致的问题。严重程度 11 至 16 的消息是由用户生成的，可以由用户更正。严重程度 17 至 25 的消息指示软件或硬件错误。当发生严重程度为 17、18 或 19 的错误时，虽然可能无法执行特定语句，但仍可以继续工作。

3. DataSet v.s DataReader

  • 执行以下操作使用 DataSet：
    • 在结果的多个离散表之间进行导航。
    • 操作来自多个数据源（例如，来自多个数据库、一个 XML 文件和一个电子表格的混合数据）的数据。
    • 在各层之间交换数据或使用 XML Web 服务。
    • 重用同样的行组，以便通过缓存获得性能改善（例如排序、搜索或筛选数据）。
    • 每行执行大量处理。
  • 对于下列情况，要在应用程序中使用DataReader：
    • 不需要缓存数据。
    • 要处理的结果集太大，内存中放不下。
    • 一旦需要以只进、只读方式快速访问数据。
  • 注意在访问相关 Command 的任何输出参数之前，必须关闭 DataReader。完成读数据之后总是要关闭DataReader。
  • 当访问列数据时，使用类型化访问器
  • 一个单一连接每次只能打开一个 DataReader。
  • 默认情况下，DataReader 每次 Read 时都要把整行加载到内存。这允许在当前行内随机访问列。如果不需要这种随机访问，为了提高性能，就把 CommandBehavior.SequentialAccess 传递给 ExecuteReader 调用
  • 如果已经完成读取来自 DataReader 的数据，但仍然有大量挂起的未读结果，就在调用 DataReader 的 Close 之前先调用 Command 的 Cancel。

SQL Server 里面逻辑标识符的优先级为：NOT > AND > OR, 即：如果 A and B or C and D = (A and B) or (C and D)

Tags:

转前端总结的JavaScript 学习资源

March 6th, 2011 by , under 码农日记. No Comments

小博注：来自JavaScript 学习资源推荐 ，是篇实在的博客，lifehacker讲述的都是自己看过的书和资源，于是推荐出来，很赞很务实。很赞同他在最后写的那段，也是自己现在正在困扰的，最近很多次的想到妈妈对我的这段劝告“事多不要紧，一件一件做，做这件事时不要管其它的事，不要因为后面有事所以赶着做手头的事，要细心”，看来是时候再去一次古德寺做一次静心陶养之旅了。原文如下：

最近 reddit 有讨论：References for JavaScript Mastery. 去年 Rey Bango 博客上也有一篇文章：What to Read to Get Up to Speed in JavaScript. 下面是我的整理，希望能对你有所帮助。
登堂入门
  • DOM Scripting: Web Design with JavaScript and the Document Object Model – 2005 年，这本书的第一版是我最喜爱的前端书籍之一。知识点的讲解轻松有趣，例子由浅入深，引人入胜。去年发现这本书有第二版了，增加了 HTML5 章节，原有内容也与时俱进。我相信无论新人还是老手，都会发现这是一本好书。
  • Eloquent JavaScript – 这是一本在线书籍，里面的例子都可调试。作者缓缓道来，内容翔实丰富。从 2007 年始，这本书历经四年，直到今年一月份才正式出版。建议国内有志人士翻译成中文，在保证翻译质量的基础上，造福国内前端。
  • jQuery Fundamentals – Rebecca Murphey 在 github 上维护的这本书，个人觉得是最好的 jQuery 入门教程，没有之一。
  • JavaScript: The Good Parts – Douglas Crockford 的这本书薄而精，在不同阶段阅读，会有不一样的收获。建议通读一遍，日常可随意翻翻。
  • 我阅读过的还有几本：Professional JavaScript for Web Developers, ppk on JavaScript, 1/e, Object-Oriented JavaScript. 都挺不错的，如果时间精力充沛，不妨读读。特别是 Stoyan Stefanov 的 Object-Oriented JavaScript, 个人觉得是非常好的一本教程式书籍，特别适合已有 OO 编程经验、同时想学习 JavaScript 的开发人员。
更上层楼
  • JavaScript: The Definitive Guide – 学 JavaScript 的如果没读过这本犀牛书，就好像基督教徒没读过圣经一样。此书前面的章节很耐读，后面的语言参考，则方便查阅。这是 JavaScript 语言学习和参考查阅的首选书籍。该书第六版已完成，期待电子版和纸质书早日面世。
  • Pro JavaScript Techniques – John Resig 的这本书，展现了 JavaScript 的专业开发技巧。如果想深入了解 jQuery 源码，这本书会非常有帮助。
  • Secrets of the JavaScript Ninja – 这本书汇集了前端开发所需掌握的 JavaScript 知识的方方面面，是今年最值得期待的专业书籍之一。目前前 14 章已有电子版，最后 3 章 John Resig 还在编写中。中文版我和沉鱼已经在翻译，敬请期待。
  • High Performance JavaScript – 如果你关注 JavaScript 的性能，那 Nicholas C.Zakas 的这本书是绝对值得一读的。
  • JavaScript Patterns – 偷懒是程序员的优良品质，模式则是先人们总结的偷懒招式。Stoyan Stefanov 的这本书，从 JavaScript 的实际使用场景出发，提炼了不少可以让前端们偷懒的实用招式。模式的探索、创新，将永远是程序员自我提升的一条修炼之道。
  • Douglas Crockford’s JavaScript – Crockford 大牛在 JavaScript 方面的总结，有不少经典文章，值得研读。
  • JavaScript Garden – 这里汇集了 JavaScript 的一些经典话题，很值得花时间研读。
  • 我阅读过的还有：High Performance Web Sites, Even Faster Web Sites, HTML5 Up and Running.
参考查阅
  • Mozilla Developer Network – 这是 Web 开发人员的宝藏，遇到问题建议优先到这里查查，闲时没事也可以到这里逛逛。我相信，作为 Web 开发人员，你会喜欢这里的。
  • MSDN Web Development – 遇到 IE 的兼容性问题时，如果 Google 不能解决，请马上到这里搜索。对前端来说，最经常查阅的是 HTML and CSS 与 Scripting 两部分。不要恨 IE, 一旦你了解了她，你会爱上这个敌人。
  • ECMA-262 系列：ECMA-262 3rd Edition 和 ECMA-262 5th Edition, 这两个链接都是在线版本，查阅方便。此外非常推荐注释版：Annotated ECMAScript 5.1, 有阅读笔记和关联链接，适合研读。
  • 还有 W3C 等站点，就不细说了。
订阅关注

这个有很多，列举太耗时费力。可以 follow 我的推荐：

Google Reader 里，我的 Shared Items 很谨慎，读过且觉得值得一读或有查阅价值的文章我才会 share. Twitter, 最近用得比较少，有时会推荐一些资源，大家可酌情订阅。在我的 following 里，有一些国内外著名的前端开发人员，推荐大家根据兴趣，选择性 follow.

再推荐一个站点：JSMentors.com, 这里收集了不少全世界范围内有影响力的前端导师们，建议选择性订阅。

写在最后

这里只推荐了 JavaScript 相关的学习资源。作为一名前端工程师，还得具备 HTML, CSS, 基本的后台开发知识，以及交互设计等用户体验相关知识。这些方面的学习资源，是另一个话题，以后有机会再和大家讨论分享。上面提到的书籍，是我读过的部分。提到的网站，是我经常光顾的。我相信还有非常多优秀的书籍和网站，期待大家的挖掘和分享了。书籍版本的选择，我的排序是：英文纸质版 > 英文电子版 > 中文高质量翻译版。这只是我个人的一个 taste, 建议根据实际情况，选择合适自己的即可。

国内的原创前端书籍，我仔细看过的只有《悟透 JavaScript》和《JavaScript 语言精髓与编程实践》。翻译类书籍里，只抱着研究翻译的心态，看过部分译稿。如果有英语阅读能力，个人不是很推荐购买译本。目前国内前端译作，个人感觉质量较烂，甚至离及格还有距离。高质量的翻译，需要我们所有前端共同努力了。

最后想提一点：要让自己有效消费信息，而不要让信息消费你。比如书籍，一个阶段，读一两本就好，贪多嚼不烂。学习阶段容易产生焦虑，甚至自我否定，要调整好心态。要明白你花了一晚上可能都没弄明白的一篇博客，作者当初可能花了好几个月才研究整理出来。保持良好的心态，不断挖掘自己的真正兴趣点和擅长点，在自知的基础上自我弥补、自我提升，在自我提升的螺旋中进一步自我认识、自我坚持。这是一种修行，有苦有乐，冷暖自知。付出汗水，登上峰顶，才有可能见到满眼的精彩。

Tags: ,

Let’s to be a bug-free programmer

March 1st, 2011 by , under 码农日记. 2 Comments

开会时听到James提到，有一个目录被我excluded from project and pushed to Production line，我心当即一整个的碎了一地，在随后的数小时中我一直处于抓狂到需要不停“啊啊”大叫的状态，连带骚扰了一群人，在公车上依然是一想到就呲牙咧嘴恨不得找块豆腐当场撞过去得好。我的这种在别人眼里很奇异的状态自从加入本公司后出现过不少次，在这期间，我承受着自己施加给自己的巨大压力，从刚入公司到现在，这种对线上BUG的恐惧感始终未曾消失，甚至对自己所有BUG的自责感连连增加。

工作中，这种错误的出现一次一次成为那双踹着我去安静下来省思的无影脚，我甚至在stackoverflow上问出了How to be a zero-bug programmer? 在这样被不断要求完美而又永远不可以达到的状态下，我一次一次对错误本身着迷，对变化和改进着迷，每一次错误都意味着我有动力继续省视和回看自身，永远都没有必要满足于现状因为我还没有能触到"glass celling“，依然有成长空间。

去年6月James来武汉时，大家坐在一起聊了很多，关于如何提高编码质量、如何建立更好的沟通等，我当时曾写了一篇蛮长的文章，并且在之后在onenote下更新了important页面，写下了30来条注意事项，每一次check其实都有“尽量”做得蛮充分，比如，在“每次”check in前必定会使用beyond compare或其它diff工具与本地所取得的最近trunk来做文件夹或是单个文件的对比，并检查所有差异点，再简单的数行代码也会反复审查，但一个人的力量实施起来就是很有限，

在出现问题后，美国方的表现总让我对自己愈加惭愧，问题出现的当即，不抱怨，不表示出任何负面情绪，不责备，所做的不过是三件事：
1、如何做才能将损失降低到最小；
2、询问事情出现的原因；
3、如何避免再次出现。
但在事后，总会好好做一番总结。

让我对“如何规避粗心”作一点思考，先来找点极端的示例来做对比。比如，外科医生做阑尾手术，并在手术过程中“不小心”将棉芯遗落在病人腹中并造成之后甚至致命的严重后果。这看起来似乎是南辕北辙，不过在粗心、不规范、缺少检查等方面具有共通性。

1、手术是阶段性操作，有开及收两种临界状态，是一个阶段性过程。

在开发的过程中，保证阶段性的专注是必要的，这样能避免在这个过程中偶然突发其想的做出一些之后未能重新捕获的操作，特别是在这过程中，因以期在短期内得到反馈，故只是将注意事项移到大脑某处的临时“存储”空间而未能记录下，有时大脑这个“任务篮”有时不靠谱，在它被中断、打扰或是被其它事物突然性占据时，会出现遗漏甚至遭遇dispose()，进而造成之后难以觉察的内容细小却可能严重的问题。

有一个较流行的PROMODORO（番茄）时间管理法 (中文官方网站)，是一种将任务划分为25分钟突击的时间管理法，每开始一个25分钟，期间不允许被打扰 (可参阅《时间管理圣经——番茄工作法》），结束后，可休息，再继续下一个25分钟。不过，这种以时间块划分的方法未必符合开发工作，我需要改良一下：有意识的将开发工作阶段化，大任务化为小任务，形成短时的task-based的高度集中化，临时起意的开发和没有结果的暂停，都不是好习惯。在每次开启这次iteration时，明确的问自己，这次我需要完成什么，记在本上。在高度集中下，如同一个堆栈块，不会出现临时的搬移和重新分配，空间连续性增强，出错可能性降低，就象剪切版，当前已存事物，如果再次ctrl+v，会将之前的覆盖，开发或任何工作时，尽量避免不同事务，在这个之前已定的阶段性任务到达结尾时才可以被终止、打断，或是重新开始下一个工作。这期间，任何如切换音乐、弹开QQ等，可以被尽量暂时延后。这种训练之下，相信大脑会更加容易集中，减少“粗心”的可能。

2、医生为何要将棉芯放在病人腹中？不要将材料放在病人肚子里，即使当时放进去，也要尽快在短时内取回吧。

在决定做一件“很冒险”的事前，问自己是不是必须得这样做，在这种询问下，能加强自己对它的警觉性，我不断的犯过这种问题，对有的改动看得“很小”，“一会再改回来不就得了”，“我会记得的啦”，我是很喜欢折腾的人，比如早前将global.ascx异常处理整个return掉，或是做一些有的人认为“天呐，这可一定得记下来，不然一会忘记了就惨掉了”的事，如果认为一定需要做，拿笔记下，在必须要做时，人为增加一个可捕获的检查点。即使自己已经在之前有“可能会产生问题”的疑虑，就不要放过它！更不应该让明知道会带来问题的代码或行为长时间的停留不作处理。要记得“好记性不如烂笔头”，有敏感性操作 – 比如增加test代码或操作时，拿笔记下来，划个红圈，标注下。

注意，如果你在你觉得你需要写下它时，记得去看一下，你是否当下有时间去完成它！如果它超出2分钟，记下它！如果2分钟内就可以顺手完成，当时就完成它！这“2分钟原则”也是GTD原则之一。

3、在做手术时，不能同时听音乐，护士坚决不可以吵闹以分心，不然，就算我把棉花掉进病人胃肠里，我也可能转头就忘记了。

做开发，不需要一颗不清醒的头脑、不清晰的思维、不成熟的分析、糊里糊涂的代码和操作。要做到这些，除了需要保证良好睡眠、暂时放下情绪垃圾、只着眼当下，还要在当下清除各种distractions，例如：音乐、QQ的闪动、打断等。我是属于临时性记忆堆栈空间过小的人，所以这个时候，如果一定需要做出回应，而且脑堆栈里又有事，最好花半分钟时间将它们记下来，以免它们划入冰山底层然后bite you back。，比如这个BUG中所涉及到的exclude操作，在我决定这么做时，应该给它一个结束的动作将它include回去，可在这过程中，我也许自己干扰了自己，在这种需要连贯的过程中如果出现停顿，就有可能会产生问题。

4、医生在切除阑尾的过程中，切到一半，突然看到肠壁有点脏，动手将消毒水先清理了下。

我没一点切除阑尾的概念，不过正在进行一件事时，如何被无关紧张的事情吸引住而走神，想来一定不是好事。在写代码时，会很正常的突然被某个老旧的代码分心，楞就是想做个简单的refactor，它与当前逻辑根本无关，这时，在#1提到的阶段性中，建议不应打断，可以将它们用//todo 标注下来，要时刻记得one time one thing原则，这也是wai-yin在与我开会时提过几次的问题，在当前有预期结果的计划下，不要停下，在下一次迭代中统一再做不迟。至于其它不可以写进//todo的，可以就手记在纸上，随意写在文章的某处，任何地方，不需要再建个NOTE之类，直接就地取材，笔记不在乎有多漂亮，快就等于高效。

5、做手术时，医生需要护士，并且需要做阶段性的检查如心跳、血压、呼吸等是否正常，每一步严格按事先设计好的步骤来。

人毕竟不是机器，大脑的组织千奇百怪，神经有可能突然搭错钱，可我们不能可以说，出了错是正常，我们有太多方法可以规避它。所以“规避”，就是使用规则去避免不利情形的产生，比如，

  • 医生需要护士，程序员需要tester和code review，或pair programming；
  • 阶段性的检查，在一个有完整开始结束状态的过程后，做一个检查，清除之前的注意事项，不让它一直appending下去；
  • 使用明确的check list或test case或是在开始之前做的plan，都可以是规避的一种，有的test-first，impact analysis，再大一点的就是design doc，以及code analysis tool，都可以做到“规避” 。

很多时候，我们会说“人一懒”就忽视了这些，而错误和我之后一些“啊啊啊”的状况，从我的实际经验来看，我的大部分问题都不是代码问题，而是归结于“当时人一懒”“忘记记下了”，“以为不会有事的啦”等懒、自以为是或是侥幸心理，不管做任何事，这些都是要不得的。

6、手术成功了，结果又“临时起意”做了病人不需要的或是事先没有确认的事，犯了严重错误。

在写代码时，因为看到其它旧的代码并不好看，你一时“好心”的去“改正”它，又并没有通知其它人知晓，你一个人用着“应该没有问题吧，我觉得还蛮straightforward”的态度，最后“好心办坏事”的情况，对我来说也是屡见不鲜了。这世界上不止怕坏人，也怕蠢人 – 怕蠢人好心办坏事，不自省下次还要接着犯并自以为自己正确的。

在敏捷团队中，就比如crum，需要一个ScrumMaster充当相当于PM的角色；需要一个ProductMaster，他需要通过与客户的沟通并从客户角度来分析问题，定制优先极、确认需求，确定解决方案，并按照当前sprint的quote来决定backlog；team member，执行者，负责实现功能、保证deliver working software。明确的知道不同角色的职能区别，善于主动沟通、保持团队透明是敏捷团队的基础。即便是我坚持认为这样更好，也需要与BA做沟通，更别谈，任何一点改动都必须对BA透明，不管从测试、support等，都是必须的。

7、借助工具，做足检查。

“多检查”事实证明，其实是没有什么作用的，检查多不代表有效，有效的也不需要“反复”检查，写下Check list，总结过程中产生的注意事项笔记，更新test-case等，都是方法在敏捷开发中，错误的产生，多半是出于在破坏其它与任务无关的部分而产生的，所以test-first和TDD，是需要的。各种diff工具，和sandbox也可以降低失误率。。test-fest是需要训练的，我也准备为之努力。

还有很多需要反省，希望自己能以谨慎、科学的态度来看待coding和相关工作，做一个真正能够self-directed、自管理自成长的开发人员！（TODO: 将important points导入。）

Tags: