给新人程序员的一些建议

作为一个从业快10年的程序员,我想给新入行的程序员们一些建议。这些建议是我希望自己可以在毕业的时候就读到的,也希望它们可以帮助你成为一个更好的程序员。 简单归纳一下,总共有7条: 保持健康 编程之外的爱好 持续学习 正确应对犯错 不要囿于角色 展示你的创意 刻意练习手速 下面我来详细说说每一点。 保持健康 三寸气在千般用,一旦无常万事休 –《金瓶梅》 首先要说的当然是健康,脱离的这个本钱,一切都无从谈起。久坐、不运动、睡眠不足、不注意及时补充水分、长期的伏案工作会对健康造成很大的影响,而不幸的是程序员这几样全都占了。很多程序员往往很年轻就已经有了各种各样的疾病:颈椎病、腰椎间盘突出、高血脂/高血压、胆结石、腱鞘炎等等,关于程序员过劳死的新闻更是隔一段时间就来刺激一下我们的神经。 研究表明,长期保持同一姿势(不论坐着还是站着)对身体都有不同程度的害处,而且这种害处是无法事后弥补的。也就是说,如果白天上班坐8个小时,那么就算你下班后去健身房练一个小时也于事无补。这几年很流行的站立式办公也是一样,如果你白天站立时间过久,会对膝关节造成较大的压力,同样会损害健康。比较推荐的方式是,写30-40分钟代码就起来走一走,喝杯水,远眺一会,跟同事聊聊天。 我知道,作为程序员我也常遇到那种写代码写High了连厕所也不想去的时候。不过为了长远的健康,还是要养成良好的习惯。 戒除不良习惯 除了长时间保持同一姿势之外,有很多程序员还有各种不良习惯。比如: 吸烟 喝酒 嗜糖(碳酸饮料,其他高糖饮料) 这些习惯一般都会美其名曰提神,大家都知道,程序员加班在业界算是比较常见的,萎靡不振是常态。然而这些号称提神的方法,其实没有一个是真正管用的。这些不良习惯说到底都是一种毒瘾,跟吸食大麻在本质上并无二致。不过好消息是你完全可以戒除这些不良习惯,只需要坚持一段时间,让毒瘾过去就好了(和真正的毒瘾一样,它们更多的是精神依赖,一旦你战胜了自己对它的精神依赖,就可以获得自由)。 我在大学和刚开始工作的前几年,也有烟瘾。写代码写累了就回去办公室外边冒一根,那种一氧化碳中毒带来的短暂的微醺感确实令人有放松的错觉,但是抽完烟回来写代码会感觉更累。而且口中老感觉有异味,咽喉不适,最主要的是精神萎靡,终于有一天我受不了了,决定戒烟(事实上和很多人一样,之前也有过无数次的戒烟)。当烟瘾发作的时候,我就去喝杯水,晚上则站站桩(站完之后口齿生津,神清气爽)。刚开始的3天是最难的,一周之后我就基本可以控制住去抽烟的欲望,然后就越来越轻松,完全感觉不到烟瘾对我的影响了。 碳酸饮料,高糖饮料也是一样。在饮食本来就不充裕的自然界,我们的祖先遇到了富含可以为身体提供能量的糖(比如蜂蜜)自然会大量摄入。这种嗜糖的基因在今天还在不断的产生作用,但是不同的是,我们现在可以很轻松的在食物、饮料中摄入比身体所需多得多的糖。这些糖会给健康带来很多问题,比如肥胖,高血糖,冠心病等等。 更多时候,我们想要喝饮料更多的是精神上的依赖,也就是上面说到的毒瘾。戒除对糖的依赖比烟和酒要困难一些,因为生活中有很多陷阱,比如酸奶,面包,饼干,水果等等。 零度可乐的陷阱 现在香烟的包装上印有焦油含量,有10mg的,有15mg的。焦油含量是影响一支烟口感的重要因素,通常说的“绵”其实是说焦油含量角度,这会让你感觉比较健康。然而陷阱是,一支烟抽完觉得不过瘾,神经感受到的刺激不够强烈,这会驱动你抽第二支,结果吸入的焦油反而更多。本来15mg焦油的一支烟就可以让你过瘾,现在两支10mg的才能达到同样的效果,相当于摄入了20mg。 零度可乐也是一样,那种无糖的有着甜味的添加剂会刺激你对糖的渴求,你需要摄入更多的糖来抵消这种虚幻的渴求 – 然后变得更不健康。 有人可能会说,没有这些嗜好,那活着有什么意思呢?相信我,当你戒除了这些毒瘾,有了一个健康的体魄,才真正能体会到活着的乐趣。当你为这些嗜好所控制,产生的那种病态的舒适感其实是虚无缥缈的。 一些建议 有规律的做一些运动,可以缓解颈椎,腰椎的不适,可以加快新陈代谢的速度,消耗多余的会沉积下来的能量。比如比较容易接触到,也容易上手的运动: 瑜伽/普拉提 乒乓球 跳绳 选择一个适合自己的运动方式,然后将其培养成一个习惯(比如坚持每周两次瑜伽,或者每天中午打30分钟的乒乓球)。如果这些和工作有冲突的话,比如公司要求长期晚上加班,那你可以考虑换一家公司。 培养一个编程之外的爱好 如果让不同的人对程序员打标签并排序,宅一定会排在前三。在任何的聚会上,程序员总是很容易被识别出来的:聪明,戴眼镜,话不多,略显闷骚,聊天容易冷场等等。也难怪,长期钻研技术,沉浸在非黑即白的二进制世界,爱刨根问底,这样很容易把天聊死。 我建议新手程序员可以找一个编程之外的爱好,一来可以拓展自己的社交圈,周末可以有个不一样的过法(而不是宅在家里写代码);二来可以帮助你成为更好的程序员。 你肯定有过这样的经历:一个编程问题一直困扰着你,试了很久都找不到解决方法,结果出去散了会步,或者和别人唠家常,突然脑海里灵光一闪,想到了问题的答案。事实上,我们大脑的工作方式就是如此奇妙,换一个完全不同的上下文就可以让大脑得到很好的休息,而且往往可以产生1+1>2的效果。写代码写累了去听听音乐,或者打一会乒乓球就可以很好的缓解疲劳,甚至可以打开思路,产生新的灵感。 一些建议 学习一项与编程无关的技能,比如: 乐器(比如吉他,架子鼓) 绘画(素描,水粉,水彩等)或者书法 制作美食 某一项武术(拳击,泰拳,空手道等) 这些看似毫不相干的爱好可以帮助大脑休息。另外需要注意的是,你无需真正成为某一项爱好的专家,不要有额外的压力:担心演奏不好、没有绘画天赋等等。没关系,它只是一个爱好而已。 我自己就尝试过很多不同的爱好,比如素描、书法等。 持续学习 软件开发是一个需要终身学习的行业(其实如果你不想做那种混吃等死的人的话,基本上每个行业都是这样)。我毕业的时候,SSH(Spring Struts Hibernate)是Web开发的主流,jQuery则是前端的新锐。有一些企业开始尝试Adobe的ActionScript,不过这个语言很快就消逝在了人们的视野。基于jQUery,但是融入了MVC理念的Backbone.js提供更高级的抽象能力,成为了开发“大型”前端应用的首选;紧随其后的,大而全的Angular.js则通过内置的双向绑定,依赖注入,完善的测试支持等让前端开发变得和后端开发一样健全;再后来虚拟DOM,Reactive范式的React栈则又一次颠覆了前端的开发方式。虽然现在还不知道下一次的颠覆会在哪里发生,但是可以肯定的是它一定会发生。 除了基础框架之外,各种构建工具也是层出不穷,从最早和后端放在一起的maven,rake,到基于NodeJS的grunt,再到gulp,到webpack,最后又回归到npm script。 程序员被裹挟在技术演进的洪流中,不能自已。作为程序员,你不但要非常扎实的掌握基础知识(操作系统原理,计算机网络,数据结构,算法等),还需要有非常强的快速学习能力,以及愿意不断去学习的态度,而后者可能更重要。 一些建议 读书 通过视频/文本教程等学习新技术 建议新手可以每天抽出一个小时来读书,周末可以多读一些。ThoughtWorks有个读书雷达,是一个很不错的书单,包括了很多的经典书籍。读书之外,还可以在线学习一些教程,比如Tutorialplus和Egghead等,都非常值得经常去看看,如果有比较新鲜有趣的技术,不妨自己亲自动手试一试。...

July 25, 2017 1 min

如何设计一个培训

培训元模式 最近在帮客户设计一个微服务进阶版培训的材料,整理的过程中我意识到这类事情我已经做过好多次了。比如在ThoughtWorks的P2能力建设项目,3周3页面工作坊等等,我觉得应该将设计课程/设计培训中的模式、原则和实践都提取一下,形成一个元模式(即关于培训的培训)。 一个培训中的活动,按照时间顺序可以分为三个步骤: 设计培训内容 培训前期准备 培训中的一些实践 设计培训内容 根据经验,只有那些正好处于瓶颈阶段,需要别人给予一些具体指导的人,培训是最有效的。比如我最近在学习iOS开发,那么用Swift开发一个Todo List应用就特别合适,而另一个基于Objective-C的自动化测试则对我来说一点用也没有(即使这个可能更高级,讲师更牛)。 在任何一个培训可能的设计之前,首先需要回答几个问题: 培训目的是什么? 参与者对主题的了解程度如何? 参与者的组成比例(比如junior占比,senior占比等) 结果如何检验? 一个例子 例子是人类的好朋友,这里我们来看一个例子: 客户要为负责开发的同事做一次培训,培训的目的是要帮助他们建立微服务架构下的常见实践的知识框架。从结果的长期效果来看,这次培训要能指导实际的开发工作。参与者对微服务的一些概念有初步了解,也做过小的练习,但是诸如如何划分服务边界,如何拆分微服务等,都不了解,也比较迫切的想要了解。 根据这个上下文,客户希望在培训中可以传递这样一些内容: 如何拆分微服务 常见的微服务设计原则 拆分微服务的时机 如何做微服务的测试 为了确保信息传递的准确性,我问了一遍上边都提到的列表,并且得到了答案: 听众是开发经验相对丰富的开发(3-5年) 学习拆分为了将大的应用拆分,以方便维护 自动化测试能力和意识都较为薄弱 听众自己的期望是可以有一些切实可以指导实际开发的收获 在有了这些输入的情况下,我做出了这样一些调整: 不专门讲拆分微服务 主要精力讲DDD(Domain Driven Design) 设计迭代式的,逐步变得复杂的场景来练习DDD 讲解和练习自动化测试(Consumer Driven Contract) Session+Workshop+讨论的形式 看了这个计划之后,客户开始觉得挺困惑,说这个怎么跟我们梳理的课程诉求不一致?对于这个疑惑,我的建议是这样的: 之前的例子不能落地(找不到足够复杂的,又适合在培训中拆分的场景) 微服务的核心不是基础设施,而是设计原则,或者说如何在开发中找出边界 有了DDD的指导,划分本身并非难事儿 自动化测试(集成测试和契约测试)的能力和认识必须建立 然后我把整理好的课件,实例分解,课程安排给客户讲了一遍之后,他觉得很满意。客户自己也是懂技术的,在分析了现状之后,后来又专门要求给部门内做一些DDD培训(而不是微服务本身)。 培训方式 同样,方式上也需要一些问题的解答才能有效进行: 培训总时长 更偏重练习还是偏重讲解(工作坊还是Session,以及各自的占比) 参与者如何投入(比如是工作时间,还是晚上等) 根据经验来看,不论是TWU还是对客户的培训,工作坊和Session结合的方式效果最好。 Workshop至少需要包含这样几部分: 明确要做的练习(多长时间,达到什么目的等) Showcase(参与感,如果有多轮的话,要保证每个人都有Show的机会,而不是每次同一个人) 讨论环节(点评,这个时机可以做一些小结,将要传递的信息润物细无声的传递出去) 应该避免的做法是:...

September 10, 2016 1 min