我的2016

大事记 把女儿心心哄睡着之后,我躺在她旁边,听着她平稳的呼吸声,心里充满了幸福和感激。女儿降生的那种感动,是无以伦比的,之前的很多事情变得无所谓起来,这当然是我今年最大的收获。 当然,初为人父,有好多好多东西需要学习,她还在月子里的时候,我整理过一次思维导图: 今年也有一些其他的里程碑: 骑行了第一个100公里 学会了驾驶(已经行驶了近6000公里) 学会了抱娃,换尿布,给娃洗澡,试水温等等 《轻量级Web应用开发》被翻译成繁体中文版在台湾发售 Hiking到了秦岭最高点(大爷海,海拔3500m) 学习 今年的大部分时间都不在办公室,在客户现场出差有8-9个月。最大的感受是归属感的缺乏,另外就是大部分时候再输出,会导致积累的存货快要被掏空的感觉。很多知识需要花时间来补充上,咨询工作本身有很大一部分是需要咨询师在非咨询项目上做积累,然后再去输出的。 这一点希望在2017年可以做的更好一些:减少一些出差,多在办公室的项目上工作,然后能有更多的时间来积累自己的知识库。 上半年花了一些时间和设计师唐婉莹合写的《在迭代1之前》,后来出差网络比较封闭的时候,就只有唐婉莹在做更新(频率和质量都很高),我自己的开发部分很久没有改动了,算是一个比较遗憾的地方。2017年希望可以完成其中的烂尾部分。 总体来说,2016年很多时间是做咨询工作,内容比较杂乱。我梳理了一下,大致如下: 一些微小的练习 我的第一个React Natvie应用,感谢傅若愚: 闪电计划的页面局部,感谢张小虫: Graphviz一个例子: 闪电计划 7月,和另外两个同事组织了一个系列的活动,这个活动旨在通过一系列的刻意练习,包括但不限于: TDD,Tasking,构建,环境自动化 自动化测试(集成测试,UI测试) 项目中的常见场景(多表关联,异常处理,RESTful API设计) 常见静态页面 一些具体而微的端到端Web项目 闪电计划的另一个副作用是找出了一些前端的Kata,可以供后续的前端们做练习用。我已经找张小虫,李彤欣做过了第一次的实验,证明是一个比较合理的方向。在2017年,可以作为新的Workshop进行。 项目经历 元月份经历了一个史上最奇特的咨询项目:Staffing好的3个人中,有两个离职了……。不过还好,通过两个月的微小工作,客户最终还是比较满意的,也很顺利的有了项目的第二期(虽然由于其他原因,第二期只做了一半)。 其他的经历比较平淡: 在回南天的3月去了一趟广州出差,做了一些前端性能相关的测试。 在最热的7月份去了一趟上海出差,莫名其妙的做了一些前端性能相关的测试,以及React Native的一些预研。 最后在寒冷的12月去了一趟深圳出差,做了一些安全测试(基于OWASP)、依赖关系图(基于Doxygen)等的Spike。 不过总体来看,2016年经历的项目是最多的,而且多样性也很高: 3个咨询项目 3个交付项目 3个售前 其他 应王欢要求,除了一起吃过几次饭之外,今年跟王欢基本上没有交集。倒是多亏了他的脸,在楼下的来福士和他喝了不少次咖啡。 这是九月份去付莹家的黄河时和同事们的合影,第一次开车走高速去那么远的地方,后座还有一个澳洲的客户。 骑行了一半儿,有一群开着车的同事追了上来,跟我们一起吃了个饭,我们骑车回去,他们则开车/坐车回去了。

December 28, 2016 · 1 min · 邱俊涛 | Juntao Qiu

如何总结你的上一个项目

下项目之后 通常来说,下项目总是一件比较高兴的事(大部分团队还会一起吃个饭庆祝一下)。这里面既有终于摆脱了厌烦了的技术栈的解脱感,也有对新项目/新技术的向往,可能还有些在旧项目中做的不太满意的事情,可以在新项目重头再来的期望。 可能有点老生常谈了,不过这里我想说说下项目后如何做总结的事儿。对上一个项目的总结,其重要程度可能要远远超过你的想象。我是在2014年初,在一个客户现场的一个会议室和一位同事谈我的Annual Review的时候,才意识到这个问题的。 Annual Review会回顾我们过去一年的项目经历,有哪些方面的进步,同时也会展望未来的计划。但是这其中有几个问题:第一个问题是以年为单位的Review粒度太粗,有些经历已经淡忘,也有人可能一年会换好几个项目;第二个问题是对于大多数人来说,展望未来是一件比较容易的事儿,每个人或多或少都会有一些计划(比如学会前端的某些技术,尝试一些DevOps方面的工作,或者了解一下大数据等等);但是对于回顾过去,我们其实并不擅长;最后一个问题是即使做了回顾,回顾的层次非常浅,作用并不大。 说到回顾过去,更多时候我们关注的是从项目中学到了什么样的新技术,这种浅层次的回忆和记流水帐是容易的,但是对于我们的成长并不会有太大的收益。真正会为帮助我们在将来的项目中做决策,甚至会影响我们学习效率,解决问题能力的是:深度回顾。 深度回顾练习 深度回顾可以帮助我们梳理知识,将实际的案例归纳总结为实际可用的知识。要获得这种能力,需要做一些针对性的练习。根据我自己的经验,这些练习大约可以归为3类,难度依次增加。 项目上的直接经验 这个练习比较简单,就是问问自己:“我在项目里学到了什么?” 要回答这个问题是很容易的,项目中用到的技术如模板引擎,前端框架,自动化测试套件,build工具等等,总结这些内容的过程,对于我们的PS来说都是“自动”发生的,几乎不需要付出额外的efforts。这些回顾、总结可以帮助我们成为一个“熟手”,即当下一次遇到相同或者类似的场景时,我们可以很容易直接应用这些经验。 更进一步,再问问自己在项目中的其他收获。比如客户关系处理的经历,团队建设的经验,甚至是写英文邮件的技巧等等方面,看看做的有没有问题,有没有提升的可能? 人类最牛逼的技能是:可以审视自己的行为。也就是站在旁观者的角度来看待自己的行为,随波逐流式的在各种琐事中沉浮事实上无法得到提升的。可以经常性的将自己置身事外,以一个旁观者的角度来审视自己做过的事情。并从中找出做得好的地方和不足的地方,然后自己给过去的自己一些建议,并记录下来。这些刻意的练习会帮助你养成回顾,从经验中学习的习惯,而这个习惯正是一个人区别于另一个人的绝对“捷径”。 练习讲故事 这个练习是,假想你遇到了一个同一个办公室的同事,他对你刚做完的这个项目很感兴趣,你来给他描述一下这个项目。描述的内容包括但不限于这些方面: 项目的背景介绍 该项目以何种方式,为那些用户,带来了什么样的价值?(business model是什么) 该项目的实际用户数量是什么级别? 项目的部署,运维是如何操作的? 项目的监控是怎样做的? 当遇到系统故障,项目组是如何反应的? 能把一件事情描述清楚是一件非常了不起的能力。我见过很多的程序员,写起代码来好不含糊,但是却很难将一件简单的事情讲清楚。我们当然要提防那些夸夸其谈,华而不实的“嘴子”,但是也至少得要求自己做到清晰,准确的将自己经历过的事情描述清楚。 描述项目背景需要至少需要交代这样一些内容:客户是谁,最终的消费者是谁,项目以何种方式运作(离岸交付,本地,onsite,咨询,培训等),我们帮助客户为消费者带来了什么样的价值。客户的商业模式是什么,在我们周围有哪些类似的项目。 即使在技术方面,也有很多被Dev忽略掉的信息,比如项目在产品环境中如何部署,数据中心建在何处,客户如何运维、监控等。实际的发布周期如何,发布流程如何,客户的内部论坛上都会有很多的这样的信息,但是很少有人关注。从一个项目roll off的时候,这些信息即使做不到了若指掌,至少也能描述清楚,否则难免有些“入宝山而空回”的遗憾。 回顾项目中的挑战 从简单的CRUD系统,到复杂的分布式计算,从企业内部的管理系统,到支持高并发、要求实时处理的交易平台,每个项目都会遇到一些挑战。除了技术上的挑战之外,还有陈旧而无文档的代码库,复杂的业务场景,不配和的客户接口人等等。挑战无处不在,那么作为项目中的一员,你是如何应对这些挑战的呢?最后又是如何解决的? 现实世界是一个充满了trade off的世界,我们需要做种种权衡,代码测试覆盖率和交付压力,性能和客户能负担的机器实例数量,框架A和框架B的优劣等等。我们在采取这个方案的时候,只能舍弃其他方案,由于谁也无法在事先准确预料采取某个方案一定是对的,那么在一个失败的方案背后,其实也是一个很好的教训,至少可以为未来的决策提供帮助。 遇到的最大的挑战是什么? 这个挑战是如何被解决的? 如果有机会重做,你会如何考虑? 其他练习 这里列出了一些我常用的,辅助性的练习。它们可以帮助你更好的梳理项目上学到的技能、知识,并且转换成你自己的知识。这些练习未必一定要等到项目结束之后才做,事实上它们都可以应用在日常的工作中。 记笔记 写博客 在办公室内演讲 去社区贡献话题 很多人都会记笔记,但只有一小部分的人在记录之后会持续翻阅。很多人会使用Evernote/印象笔记之类的工具将一些临时的想法,问题的思路,知识点的细节等记录下来,但是仅仅记录是不够的,笔记需要不断的检索、整理、提炼、修正、总结和归纳。在不断的加工之后,这些笔记可能会得到沉淀,并升华形成一些更有意义的内容(比如个人博客,或者可以发表到InfoQ/IBM DeveloperWorks平台上的文章等)。 除了记录笔记之外,写博客也是一种很好的总结形式。通过将素材不断充实、整理、完善,最终形成一个可供别人直接消费的文章,不但可以锻炼到总结能力,还可以很好的提升表达能力,而且可以帮助你将已有的知识体系化。如果你的博客写成了系列,也很容易通过Gitbook等将其发布为一本电子书,从而影响更多人(说不定还可以赚点咖啡钱)。 写博客/电子书,终究是书面形式的。事实上一个人可以很容易的通过文字将自己的实际情况隐藏起来。举个极端的例子:如果有足够的动机(比如公司的KPI要求),即使不熟悉某种语言/工具,仅仅通过Google,一个人也可以通过这种“作弊”的方式写出一篇“专家级”的文章。但是对于演讲这种面对面的形式,则基本上无法作弊,从而也更具有挑战性。另一方面,对于一个新的知识、技能,自己掌握是一回事儿,要讲出来让别人也能听懂,并从中收益,则完全是另外一回事儿。作为咨询师,语言表达(包括书面和演讲)能力的重要性勿庸赘言。整理知识,并归纳为演讲,会帮助你将体系化后的知识更好的表达出来。 在办公室里讲session有一定的挑战,但受众毕竟是“自己人”,压力相对会小一些(比如在ThoughtWorks,我们非常鼓励员工为其他人讲session,具体可以参看我的这篇文章)。要在社区中演讲则要面临更大的挑战,通过将话题不断锤炼,不断归纳,最终形成可以在社区分享的话题,则不但可以提高内容的质量,也可以更好的锻炼表达能力和临场应变能力。 不过归根结底,这些活动的重要输入还是对之前项目中的知识、经历的深度回顾。 总结 从项目上下来之后,需要深入思考并总结之前的经验,这种深入思考会帮助你建立比较完整的知识体系,也可以让你在下一项目中更加得心应手,举一反三。如果只是蜻蜓点水般的“经历”了若干个项目,而不进行深入的总结和思考,相当于把相同的项目用不同的技术栈做了很多遍一样,那和我们平时所痛恨的重复代码又有什么不同呢?

January 5, 2016 · 1 min · 邱俊涛 | Juntao Qiu

我的2015

2015年总结 2015年在不经意间就过去了。又是一年。按照惯例,我会在年末回顾一下这一年自己的进步,收获以及一些感慨(牢骚)。然后对来年做一点展望,看看什么地方可以做的更好。 项目经历 今年基本上经历了三个项目,性质也都不一样: 海外交付 国内交付 国内售前 3月前的项目以及没有什么印象了,依稀觉得项目上的所有实践都是“错”的,可能由于太过与荒诞,所以大脑自行将这段抹去了。 4月到6月在深圳的一个国内交付项目上,交付压力还挺大。不过也是在这个项目上,非常直接的体会到了其他角色的不容易。无论是客户的接口人,客户的项目经理,客户的领导,我们的开发,我们的UX,项目经理,还有交付的lead,所有人都不容易。 《项目经理是大傻逼吗》这篇文章就是为了纪念这个项目,或者说是被这个项目驱动出来的。 6月之后回到办公室,在一个海外交付项目上。说是一个项目,中间其实换了6,7个不同的工作内容(出钱的是同一个客户而已)。总之一片混乱,所幸我们在10月前就结束了和这个客户的合作。这个项目事实上除了锻炼项目上人的耐心外,基本毫无益处。甚至对于很多毕业生来说,是深刻的伤害。 10月之后,我难得的在beach上待了下来,而且一待就是3个月。中间在一个联合国的项目上工作了2周,然后就是为另外一个咨询项目准备了几周方案。当然,闲是不可能闲着的。在beach上,如果不出意外,肯定会比项目上更忙!比如打黑工啊,内部什么系统的改进啊,总是有好多事情。 由于有一些本地的项目机会,而我又不在具体项目上,就来做这个售前的角色。帮助客户梳理需求,分析问题,设计方案,计算工作量等等。但是这个过程往往循环往复,一轮接着一轮,在合同确认之前,需要很多次讨论和交流。这应该不会是我自己的一个方向,在项目上写代码,培养新人,分享自己的学习所得,和他人一起进步,是我自己比较有热情的方向。 技术方面 在海外交付项目上,乏善足陈,项目中用到的也是非常厚重,已经至少10年的技术。通常来看,这样的大组织,没有人对要做的事情真正关心。好不容易遇到一个特别靠谱的人,结果我们的项目又结束了。国内项目上倒是有很多有意思的东西: 如何在前端代码中很好的使用MVC 流畅的前端开发模式 如何做前端的测试 上面这三点,我希望可以找时间整理出一本电子书,可以让没有工程级做过项目的前端工程师能有一个参考。 另一方面,由于项目的压力,和项目人员的特殊性(开发就俩人,一个做前端,一个做后端,要集成就pair一下),所以很多实践都没有应用,比如结对,自动化测试等,做的都不够好。虽然我们很推崇,强调CI/CD的实践,但是当和客户的后端系统集成时,就各种悲剧。 联合国的项目上,技术栈比较新颖,上一家的技术人员使用了他们当时能找到的所有酷炫的新技术,并用在了项目中,然后他们公司被收购。留给我们的在今年来看,依然是比较新的: React Reflux ES6 mocha/chai 而在国内售前,基本上没有写过一行代码,更多是更高层次(高不一定是好哦)的工作。确认需求,估算工作量,确定方案(前后端测试,开发方式,部署策略,自动化测试等等)。 2016年,我希望可以多学习一些具体的编程知识,比如: mongodb 数据分析,数据挖掘 容器技术如docker 书籍 今年读了一些技术方面的书,更多的则是一些非技术类的。《自私的基因》是在2012年11月去墨尔本时,在广州白云机场买的,路上10个小时,读了几页。直到2015年才又拿起来,读了两章左右,基本上颠覆了我之前建立的对“进化论”的认识。 另外读了一些科普类的,比如《哲学家在干了些什么》,《上帝掷骰子吗》等,又扫了一次盲。再就是一些佛教相关的书籍,《西藏生死书》,《能断:金刚经》,《正见》等,人生观和价值观得到了刷新。 技术类的,主要是一些与具体技术关系不太大的,比如《恰如其分的软件架构》,《企业级应用架构模式》,《发布!》,《实例化需求》,《持续发布》之类。 虽然竣工于2014年,但是我的一本著作和一本译作都是2015年才发布出来,那就算作2015年的吧: 《轻量级Web应用开发》 《7周7Web框架》 社区 今年在深圳的时候,有幸和ThoughtWorks的首席科学家马丁.福勒在同一次活动中作为讲师。 回到西安之后,在本地社区中还讲过一个前端工程师需要掌握的技能列表的session 2016年希望可以做一些更加深入的topic,以及一些更有意思,可以帮助到更多已经在路上的工程师们。 People Development 这个不知道如何翻译了,但是确实做了一些具体的事情: 给我的sponsee们安排了读书会 组织了一次《编写可维护的JavaScript》的workshop 组织sponsee来做一个side project 组织《Web开发实战》的workshop 我自己总结出来了一套组织workshop的方式,其实很简单: 做好计划,做好课表,做好课件 找学员,同时从学员里找出有基础,而且有意愿接着run workshop的人 讲课,收集feedback,并改进课表,课件 将run workshop的任务传递给那些有基础,而且有意愿接着run workshop的人 2016年希望可以找到更多的候选人,并帮助他们成为更好的讲师,教练。...

January 2, 2016 · 1 min · 邱俊涛 | Juntao Qiu

在Thoughtworks我们如何做培训

ThoughtWorks内部培训 对新人的培训是每个企业都绕不开的一个话题,企业当然想要每个新人都能直接独当一面,最好可以直接上项目贡献自己的价值。但是从经验来看,所有新人到一个新环境都需要学习很多不同的新东西(新技术,框架,语言,工作方式等等),而每个企业对于培训新人都有各种各样的策略,比如老人带新人,比如扔到项目上让新人自己学。 在ThoughtWorks,我们有着丰富的培训方式,有面向社招的,有面向毕业生的,有民间自发的,有官方组织的,有内部的,也有面向社区的。 TWU TWU全称ThoughtWorks University,面向毕业生,入职之后的第一堂课。TWU的地点设在印度,之前在班加罗尔,后来改到了普内。每一期5周,学生们需要和和全球其他国家地区的同学一起,一般会尽量将各个地区的学生打乱安排,尽量让学生体会多元化的文化,培训内容设计公司文化,软件开发方法论,敏捷开发(Project SImulation)实践等,同时还需要保证学生有足够的代码练习机会。 我在2013年作为讲师参加了一起TWU,对我自己的帮助也非常大,在和来自不同地区的讲师一起备课,学习中学习到了很多的东西,之前似是而非的一些概念也得到了纠正。 TWI TWI全称ThoughtWorks Immersion,面向有经验的社招同事,主要涉及的内容为公司文化(合作,沟通),专业服务(如何专业的解决客户的问题),软件开发流程,敏捷开发方法论等。 我在2012年时参加过TWI,并整理了几篇相关文章,可以参考这里,这里还有这里。 Session Office局限在ThoughtWorks办公室之内,内容随意,参加不参加随意,可以随时加入或随时离开。虽然内容没有限制,但是大多数时候分享的都是技术主题。比如自动化部署,自动测试,Spring 4,Ruby中的构建工具等等。 Sessoin的形式是主讲者找一个自己感兴趣的主题,一个人讲,其他参与者听,鼓励互动。时间一般控制在一个小时以内,所以一般选择在中午饭的时候,有的session会给大家订饭,一边吃一边听。 虽然大部分Sessoin的主题是技术相关的,但是并不局限于此。比如旅游见闻,历史,财务,摄影等等,都可以分享,有时候这些趣味性的Session的参与者更多。 WorkShop Office之内,内容随意,以动手为主,讲解为辅。 HTML/CSS Testable JavaScript 设计工作坊 OO BootCamp Ruby BootCamp 一般来说,Workshop都会组成一个系列,通常会占用几天到几周不等。参与者需要带上电脑,在课堂上进行练习之外,课后还会有一些练习。 3周3页面和可测试的JavaScript是我去年做的两个Workshop。由于Workshop会在下班后或者中午的休息时间,公司会为每个参与者订饭,以节省时间。 郑大晔校 面向刚刚得到offer的毕业生,在上项目之前,我们希望学生的基本技术达到特定的水平,因此设置了一系列的练习。包括 编程基础 开发流程 工作方式 公司文化 等等。郑大晔校的周期为每周一次,一次一天。涉及的内容会与大多数项目上的要求一致,比如西安office的Java/Ruby项目居多,我们的课程安排就会涉及到Java/Ruby方面。当然,各种软技能如工作方式也会在课程中涉及,尽量的寓教于乐。 每期郑大晔校大概会有10周,学生入职之后有的会直接去TWU,有的则会在项目上工作一段时间再去TWU。 组内培训 各个组内自行组织,并不要求其他同事参加。比如某个项目需要一些docker的知识,或者需要AngularJS相关的培训,一方面是找自己组内的专家组织一次内部培训,,另一种是找办公室内相关的专家来进行培训,形式比较灵活。 项目中已经在使用的技术 项目中将要使用的技术 请别的组的专家来咨询 社区 OpenParty Rails Girl 问题 谁当讲师 活动经费 内容如何持久化(人,内部知识分享系统) 如何保证效果(宽松) 由于对任何的话题都没有限制,也没有对参与者的限制,因此任何人只要感兴趣都可以作为讲师。而又由于没有任何的强制措施,参与者和主讲者都凭着自己的热情来组织,这也算是比较独树一帜的事情。 而关于内容的持久化,更多的是为参与者打开一扇新的窗户,或者说洒下一些火星,而至于火星如何形成燎原之势,则完全在参与者自己的自觉。好多次和客户分享了我们的培训机制之后,被问到最多的问题是如何强迫参与者产生热情? 这个问题在ThoughtWorks不是问题,我们在一个人进入公司的最开始,也就是面试的时候,就考察了他的热情,如果在热情上有缺陷,则很可能会直接拒掉,免得破坏我们好不容易构建起来的学习氛围。

January 25, 2015 · 1 min · 邱俊涛 | Juntao Qiu

我的2014

依照惯例,我每年在元旦时候都会写一篇回顾,总结过去,展望未来。不过很少跟上一年指定的计划真正去比较,一般都是列举一下这一年做的事情。 大致分下来,可以分为上半年和下半年两部分,这当然不是废话。因为上半年和下半年分别在两个完全不同的项目上工作。 技术咨询项目 上半年在一个国内咨询项目上,主要做的事情有(其实我是作为前端专家加入的,不过后来工作重心发生了改变): GIS平台 大数据平台 关于GIS最后的产出是一系列博客,而且还在InfoQ上发表了一篇。 而后来我又根据我iPhone上照片的经纬度信息,汇总出了一个热力图(使用QGis): 大数据相关的所有东西都在我的gist上,还没有时间整理。 硬件 回到办公室之后,发现了硬件小组提供的一大堆有意思的工具和器件,包括3D打印机,Arduino的一些芯片等,为了纪念我的GIS项目,我还打印了一个瓦片: 不断将我拖延了4年的机器小车组装了起来,而且还使用舵机,蓝牙,超声波等模块制作了一个实际的雷达: Sessions & Workshop 5月底回到办公室后,我发现Office的气氛其实比我来的时候低落了很多,ThoughtWorks的感觉非常淡了。 一方面是新人太多,而来新的项目所在的11楼由于客户的关系(我自以为),同事们的积极性极低。一个最容易看到的信号就是Session变得很少,我尝试做一些改变。 分别做了一些关于自动化测试,JavaScript方面的Session和Workshop,下面是《可测试的JavaScript》的Workshop。这是我第一次组织比较大的,而且时间比较长的Workshop。 有了上一次的Feedback,在年底的时候,我又组织了一次为期3周的Workshop,受众更是扩大到了各种角色,包括BA,UX,UIDev,QA等等。 写作 今年的博客数量减少了,一个原因是我在编写我的第二本书《轻量级Web应用开发》,经过几个月的坚持和努力,这本书已经编写完成,应该会在明年(2015年)年初与读者见面。 另外,在休年假的时候(3周3页面之后),我将Workshop的内容做了整理,并加入了一些设计相关的内容,形成了一本电子书,名为《3 web designs in 3 weeks》。 其他 我正在努力的向UX角色的转变,所谓千里之行,始于足下。我在休年假期间,买了一大堆UX相关的书籍。目前正在努力学习画画: 在今天的CST的创新课上,我们一起设想了几个场景,下面是我自己画的图: 最后是一张我自己设计的自己的名片: 希望来年可以在自己努力的路上看到一些成果吧。

December 27, 2014 · 1 min · 邱俊涛 | Juntao Qiu