写作驱动学习

本周在公司做了一次内部分享,主要目的是鼓励大家写作。但是作为一个建的博客比写的博客还多的人,心里实在是没什么底气讲这个题目,所以就搜罗了大量的资料,看能不能从前人的智慧中吸取一些灵感,显得不那么无知,结果做下来,收获破多。

众所周知,写作有很多的好处:可以记录和巩固学到的知识、扩大自己的影响力、提升和推销自己等等,甚至很多人通过写作出书,成名,改变了人生的轨迹,这种例子很多很多。至少我每次听到这类的故事都会陷入深深的自省,痛恨自己没有早一天开始行动,然后痛定思痛,立即新建一个博客或是把之前落满灰尘的博客打扫打扫,重新发一篇《新的开始》,然后……就没有然后了。周而复始,自己也慢慢失去了对自己的信心。

所以问题的关键不在于我们不知道写作的好处,而在于我们做不到,就像大多数的鸡汤文一样,要知道“总有一天”是不靠谱的。对于放弃我们总能找到很多理由:没有时间,总有更重要的事情;反正知识已经掌握了;不知道写什么;觉得自己想写的东西不值一提,怕被人笑话等等。后来我想清楚了,归根到底就是四个字:觉得不值,假如有人给我500万让我写篇博客,我想上边那些理由就都不再是任何问题了。

那么什么样的事情是我们心甘情愿想去做的呢?为什么我们喜欢玩游戏而不喜欢写作业?那些我们根本不需要”坚持”就能一直做下来的事情都有什么样的特点呢?想来想去我认为一般要符合两个条件:快速的正向反馈、相对容易

我就曾经疑惑过学习与玩的区别到底在哪?玩游戏可以让我们相对容易的就能短时间内满足生理或是心理上的需求。但是学习首先不容易,有好处但反馈周期都相对较长,我们很难获得比较快的正向反馈。可是有些好学生就非常喜欢学习不是么?因为他们可以从每次考试,每次回答问题,从老师家长赞赏的同学羡慕的眼光中中得到很多正向反馈,而更重要的是这种反馈足够快,所带来的收益已经抵消甚至大过了在学习上投入的成本,这就是为什么好学生会越来越喜欢学习的原因。

我们常说要培养孩子的兴趣,这样他就能某一方面作出成就。我认为这个逻辑反了,应该是先促使或是找到或是暗示孩子在某方面的成就,让他觉得自己在这方面比别的小朋友强,他就能在这件事情上持续获得更多的正向反馈(例如夸奖,奖励,其他小朋友的羡慕),就会越来越喜欢做这件事情,兴趣自然而然的就形成了。

所以说学和玩本质上没有什么大的区别,主要是付出成本和短期收益的差别,甚至通过调整这两个维度学与玩是可以相互转换的。例如每个电子竞技选手每天都要在一个游戏(竞技项目)上玩(训练)超过10个小时,对每一个操作细节都要反复练习,而每提高一点点都非常的困难,每天要被教练训,在比赛中还很难获胜,需要承受着家庭和社会的压力,对于他们来讲,这已经不是在“玩游戏”了,虽然外人看起来没有什么差别。

很多牛人可以通过心智自我管理,推迟幸福感,用长远利益来驱动限制自己的行为。不过那是需要天赋和训练的,对于我等凡人,如果一定要坚持做一件事情我们认为需要坚持才能做到的事情,我认为可行的办法就是:能否找到一种适合自己的鼓励方式能让我们自己在做这件事情的时候能够得到持续快速的正反馈,并尽量把这件事情变得容易。

回到写作这件事情,抛开那些“总有一天”才能实现的好处外,眼前的好处无外乎就是帮助我们记录理解消化沉淀学到的知识了。不过我们的内心里总有一个声音反复出现:反正书看了,Session听了,感觉知识已经学会了,那还值得花时间写么?我用这个时间多学点东西不更好?

李光磊在《知行合一》中将知识划分为信息,知识和智慧。这解开了我很多对于学习的疑惑:为什么我看了很多书还是不会用某项技术?为什么我们听了很多Session,但是感觉却没什么用?为什么同一本书不同人看或是同一个人不同时期看会有不同的收获?原来我们之前所认为的学习只是获取信息而已,如果不思考,不行动,这些信息将一文不值,随时间消失,而浪费掉的却是宝贵的时间。而同样的信息,不同的人或是人的不同时期通过思考转化为的知识也是天壤之别的,所以说书只是一面镜子,我们读的看的其实是我们自己而已。

所以为了真正的学到知识,而不单单的是收集信息。我们需要用行动来将获取的信息加工吸收变为自己的智慧的一部分,而写作算是比较简单廉价的方式了,所谓写作驱动学习,正是如此。就像测试驱动开发中的测试一样,写作一旦完成,理论上就可以丢掉了,发不发布,有没有人看,写的好不好,都已经不是那么重要,它已经体现了它的价值。相信只要能体会到这种好处,不断地用写作来驱动学习,注重积累和推广,那些长远的好处也会自然而然的在某一天突然到来。

最后,不论你觉得上面这段文字有没有道理,它对你来讲只是一段信息,如果没有思考,没有行动,那就只是在浪费你的时间而已了。

Share

在ThoughtWorks做BA是怎样一种体验?

BA,英文全称Business Analyst,也称业务分析师,或需求分析师。Linkedin上BA相关的职位不到产品经理或项目经理的四分之一。到本土的拉勾网、智联招聘等网站上,BA的职位就更少了。那么,

  • BA究竟做什么,有没有必要设置BA这一岗位呢?
  • BA具体会做哪些工作?一天会是什么样?
  • BA有哪些能力要求?BA的职业发展如何?

下面我仅就个人在ThoughtWorks的经历做些分享,可能不能代表所有BA,给大家一点参考。

 

BA做什么?为什么需要BA?

BA顾名思义,就是做业务分析。具体说来,就是能够把业务需求和用户需求转化为软件需求,保证最终的软件能满足用户需求,并带来业务价值。举个例子,

01

在软件开发过程中,大家都知道,需求信息要在很多角色中流转。没有BA的团队,需求大概是这样传递的:

02

大家知道,信息每传递一次就会衰减;况且在图上的每一个节点上,往往不是一个人,多人参与更容易失真。根据《组织行为学》中的相关数据,这样跨五层的传递,大约60%左右的信息能被完整无误地传递了。

而有BA的团队,需求则是这样传递的:

03

BA和每个角色都保持无缝的沟通,尽量在每一个节点向前验证需求,保证沟通的每个环节都是闭环,最大程度地减少需求失真。

目前在ThoughtWorks,90%的团队都会配置专职的BA, 只有少量规模很小的团队(如人数<=5个人),则会由其他角色兼任。

 

BA的一天,大概什么样?

如前所说,BA的工作主要围绕需求来展开。在ThoughtWorks的敏捷团队里,使用User Story(用户故事)来表达需求,所以具体的工作就是用户故事的发现、捕捉、拆分、设计、定义、Kick-off、预验收、演示和验收、上线及反馈等,这个过程中会与客户、用户、设计师、开发和测试沟通协作,确保大家做的是有价值的需求,并且对需求的细节有一致的理解。比如我现在的一天:

  1. 早上8:50到公司,看邮件,理一下今天的todo-list, 可能包括如下项(我当前这个组很特殊,会同时负责2个项目
  • 准备项目A在下周一的Showcase
  • 项目B下个迭代的故事卡 – 需要与另外一个BA再过一遍,确保卡上的细节准确无误
  • 项目A的两个故事卡Kick-off
  • 到客服中心去做用户访谈
  • 跟踪下昨天测试报告的外部服务接口好没好
  • 需要与设计师碰一下,把项目B涉及的UI改版的需求再梳理一下
  • ……
  1. 9:15和客户、团队一起站会
  • 更新自己负责的项目需求状态和变更信息
  • 认真听其他人的更新,及时发现有没有需要自己要澄清或跟踪的需求问题
  1. 9:30-9:45 给组里的新同事解答业务相关的疑问
  2. 9:45-10:15 处理一下紧急的客户邮件
  3. 10:15-11:00 与其他BA过项目B下个迭代的卡;
  4. 11:00-12:00 主持迭代计划会议 (怎么做,昨天已准备好)
  5. 12:00-13:00  午饭+休息,刷朋友圈
  6. 13:00-13:40  约到开发、测试,一起kick-off项目A的两张卡
  7. 13:40-16:00  出发去客服中心,用户观察和访谈
  8. 16:00-17:30  准备项目A的showcase讲稿,拉测试做一遍演练、检查外部服务接口是否好了
  9. 17:30 迭代计划会时发现了两个需求问题,发邮件跟客户确认一下
  10. 18:00 查看早上整理的todo-list,还好高优先级已经处理完

 

在ThoughtWorks做BA,跟在其他公司做BA有什么区别呢?

04

我之前也在一家通信企业工作过,属于PM兼BA的角色,对比下来,觉得区别主要在下面几个方面吧:

  • 在TW,我最常用到的工具是白板,PPT,卡片,便利贴;以前最常用的是Word和Visio。
  • 在TW,墙上贴得花花绿绿的,各种需求相关信息,开发测试问到需求,我也是随时随地都能解释;以前都是要翻出需求规格明书,对照着看,才能知道到底做什么。
  • 以前,基本上是做系统分析,到我手上的都是功能需求,有时候明知道做好了没有用户真正用这个功能,还是硬着头皮对照需求规格说明书逐条实现;现在在TW,会真正关注业务问题,用户场景,基本每一条在我手上经过的需求,知道它为什么要做,有什么价值。
  • 以前,几乎从来看不到客户,也不知道用户行为是什么样的;现在几乎天天跟客户打交道(只不过有时是在视频里),还有机会做真正的用户观摩和访谈、用户测试。
  • 以前,一年几乎只能看到1-2次产品上线;现在在这个组,每月都要有很多次产品上线,时不时能得到客户发的巧克力,T恤衫,还是挺受鼓舞的。

 

BA的职业发展怎么样?目前ThoughtWorks中的BA是不是仅能在内部发展?

以我自己的经验来看,BA是个综合技能要求很高的岗位,需求大局到细节的把控、提供业务方案建议、引导决策等等,尤其是大型的产品团队中,更需要综合的影响力和领导力。

之前的BA同事离开ThoughtWorks之后, 有的去做了产品经理,有的去做了数据分析,到其他大型公司里面做BA教练,还有的去创业等等。

在ThoughtWorks内部,有的BA想精专在某一产品领域,比如O2O, P2P还有金数据,实际上承担产品经理的职责,做需求分析的同时,还做售前、看市场和运营;有的则深钻某一个行业,去更多地做业务咨询、解决方案设计、数据分析师等。也有一部分,因为综合影响力和领导力得到了极大的锻炼,横向发展成为管理人员,比如目前我们的全球CEO办公室负责人,我所在组的大客户经理等。

ThoughtWorks是一个人才观非常开放的公司,在内部会鼓励大家“不设限”,主动去尝试很多不同的工作,创造新的“岗位”。

 

在ThoughtWorks做BA,觉得最好的一面和最坏的一面是什么?

最好的一面,是可以接触到各种类型、各种行业的客户,每次都能发现新鲜东西去学习去尝试;最差的一面,其实也是这个,因为有时候要短时间学习很多技能,压力很大。当客户老板说“五分钟之内把图画好”,我们说“好”的那一刻,万分紧张和忐忑;最终把事搞定之后,又是酣畅淋漓,痛与乐并存吧。

 

去TW做BA有什么具体要求呢?

还真没有硬要求,不讲专业,不需资历,也不需软件背景。大致说来,有这四点:

  • 有需求转换的能力
  • 逻辑思维好,清晰有条理
  • 沟通好,复杂的事情也能三言两语说清楚
  • 爱挑战,爱学习

还有的一些不是必须的,但如果能做到,就是加分项了:

  • 喜欢琢磨研究行业市场
  • 善于图形化表达信息
  • 懂敏捷和精益

 

以前没做过BA,但想试试,有书推荐吗

 

最后,以我们内部训练营的BA宣言结尾:

“Skill-set over Role; BA is Business Analysis rather than Business Analyst

角色不重要,真正有两把刷子才重要。大家共同学习,多多增长技能,才是重点。

Share

如何培养自己的自信心

c23e73362a1f1bafc564405455850d38

self-confidence(自信心)——是一种反映个体对自己是否有能力成功地完成某项活动的信任程度的心理特性,是一种积极、有效地表达自我价值、自我尊重、自我理解的意识特征和心理状态,也称为信心。自信心的个体差异不同程度地影响着学习、竞赛、就业、成就等多方面的个体心理和行为。

当你被指派一个任务时,你会基于你目前所拥有的资源和能力做出一个评估,结果得出自己是否能胜任这个任务。自己目前能力<该任务所需能力,你却得出能胜任的结论,那就是你对自我认知不足,盲目乐观,这就是自负的表现。自己目前能力 >=该任务所需能力,而你却认为无法胜任,那就是过于贬低自己,这就是自卑。

从自负被打回原形比较容易,因为你多自负几次,多栽几个跟头,那么你就老实了。而从自卑上升到自信则难多了,因为由于自卑,你根本不会去领取任务,这意味着你不会完成该任务,从而无法提升自信,有新任务来时又主动退缩,陷入死循环。

 所以大家可能看出来了,培养自信心的关键在于,多做事,做没做过的事。不断的检验自己,校正自己对自己的认知。但是大家在面临工作中的挑战时,报的都是比较谨慎的态度,因为事情没做成,轻则挨顿骂,重则丢了饭碗,所以又陷入一个死循环,谨慎接任务->无法突破自身->自信心(能力)无法提升->谨慎接任务。

 所以培养自信心可以从生活中的事情开始。有一个很好的任务就是跑一个马拉松。如果你之前没有跑过马拉松,那么你肯定有很多问题想知道。

1. 马拉松距离有多长?

2. 跑马拉松需要什么样的装备?

3. 从现在开始训练,需要多长时间能够完成马拉松?

4. 需要什么样的训练计划?

5. 如何安排自己的训练时间?

这么多的问题要把你淹没,自己完成一个马拉松似乎变成了一个不可能的任务。如果这时你退缩,那么我可以告诉你,你自卑了。因为据科学家研究,一个普通人,只要你没某些不适合跑步的疾病(比如心脏病等)以及肢体残疾(有些残疾人也能完成马拉松),通过训练都可以完成42公里的跑步。我说你行,你缺少的就是干劲。

虽然有这么多问题,你还是决定试试。那么首先要解决这些问题。如何解决不需要我教了吧?网上一查,资料一大把。多去跑步圣经、跑步吧里逛逛,买几本关于跑步的书,找几个身边的长跑健将聊聊天,大多数的问题都迎刃而解。小部分的问题可能会使你纠结,比如有人说跑步需要3呼3吸,有人说2呼2吸,有人说亚索800方法好,有人说MAF有奇效。不用纠结,你要进入下个环节了,实战训练,从训练中感知这些理论方法,从而找到更适合自己的方式。

 刚开始训练感觉新奇,时间久了似乎各种问题又来了。最近太忙,训练时间很难保证;跑了这么久,距离还是无法突破;到底是先练距离还是先练速度那?…….说时间紧的那我劝你不练了。因为咱们的任务就是跑一个全程马拉松,你没时间训练,那就别干了。这就好像老板喊你7天搭一个网站出来,你说对不起最近LOL正在冲击排位,没时间做。跑马拉松这件事本来就是你自己给自己定的任务,老板就是你自己,所以时间问题你看着办。其它问题好说,搞IT这行的最不缺的技能就是利用资源。多看书、多逛跑步论坛、多找过来人交流….(怎么还是老三样)再加上自己在训练中融会贯通,我就不信你不长进。

好了,经过一段时间训练了,感觉自己进步很大,但还是拿不准啥时候能跑个全马。如果你想达到“万事俱备,只欠东风”,那么对不起,你不是诸葛亮,东风啥时候来你是不会知道的。这就需要你设置个deadline了。先报名一个几个月后的全马比赛(一般马拉松比赛都是提前几个月报名),然后你的训练会更加鸡血。而且你会找到一群志同道合的基友(没找到?不知道咋找?我膝盖前叉断裂,都轻松找到了一群病友,你到底用心没?),一起集训,相互鼓励。

比赛的日子越来越近了。回想这几个月来,你为了这一目标付出了这么多实打实的汗水,肯定感慨良多。你认识了一群基友,熟悉了周边没逛过几次的公园,看到了早晨7点钟的城市,学会了跑步中对自我反思….恭喜你,这些都是跑马拉松给你带来的从来没有的体验。虽然在迎接这天的过程中,你激动的内心有些忐忑,但是你似乎已经得到了很多意想不到的东西。

 比赛这天终于到来了,站在起点前,和好几万人一起打算度过数小时的地狱旅行。这时你的心里除了激动还是激动。比赛结果其实已经不重要了,当你站在跑道上的时候,你就比以前的你强了。如果能顺利完赛,你已经不是以前的你。如果因故未完赛,放心,这绝不是你最后一场马拉松,相信你已经谋划下一次冒险了。

 好了,你已经完成了生活中的一个任务了。有没有收获?自信心有没有提升?你试一下你就知道了。可以放心的告诉你,这种感觉绝对比你考试得了全班第一的感觉还要美好。另外,跑完马拉松不是你这个任务的终点。它就像给你打开了一个潘多拉魔盒,你会发现有更多的事情你可以去做,比如铁人三项,比如越野跑……

好吧,可能有点标题党。明明讲如何提升自信心,但通篇却在讲如何完成个人首马。其实很多事情都是相通的。因为你已经发现了如何做一件没做过的事情。

首先,先答应下来。这个最关键。

然后,发动所有的资源,了解这个事情。

接下来,做吧。别忘了边做边验证,吸收过来人的经验。

最后,接受检验吧。检验结果不用担心,因为无论通过与否,你整个过程已经有了大量的收获。

 看完以后是不是有种自信心爆棚的错觉?别忘了关键两点:

1. 坚定决心要做;

2. 努力想如何做。

最后,尽情享受事情做成后带来的成功感和喜悦吧。

Share

在ThoughtWorks我们如何做内部培训?

banner

ThoughtWorks内部培训

对新人的培训是每个企业都绕不开的一个话题,企业当然想要每个新人都能直接独当一面,最好可以直接上项目贡献自己的价值。但是从经验来看,所有新人到一个新环境都需要学习很多不同的新东西(新技术,框架,语言,工作方式等等),而每个企业对于培训新人都有各种各样的策略,比如老人带新人,比如扔到项目上让新人自己学。

在ThoughtWorks,我们有着丰富的培训方式,有面向社招的,有面向毕业生的,有民间自发的,有官方组织的,有内部的,也有面向社区的。

TWU

TWU全称ThoughtWorks University,面向毕业生,入职之后的第一堂课。TWU的地点设在印度,之前在班加罗尔,后来改到了普内。每一期5周,学生们需要和和全球其他国家地区的同学一起,一般会尽量将各个地区的学生打乱安排,尽量让学生体会多元化的文化,培训内容设计公司文化,软件开发方法论,敏捷开发(Project SImulation)实践等,同时还需要保证学生有足够的代码练习机会。

我在2013年作为讲师参加了一起TWU,对我自己的帮助也非常大,在和来自不同地区的讲师一起备课,学习中学习到了很多的东西,之前似是而非的一些概念也得到了纠正。

twu

TWI

TWI全称ThoughtWorks Immersion,面向有经验的社招同事,主要涉及的内容为公司文化(合作,沟通),专业服务(如何专业的解决客户的问题),软件开发流程,敏捷开发方法论等。

我在2012年时参加过TWI,并整理了几篇相关文章,可以参考这里这里还有这里

twi

Session

Office局限在ThoughtWorks办公室之内,内容随意,参加不参加随意,可以随时加入或随时离开。虽然内容没有限制,但是大多数时候分享的都是技术主题。比如自动化部署自动测试Spring 4Ruby中的构建工具等等。

Sessoin的形式是主讲者找一个自己感兴趣的主题,一个人讲,其他参与者听,鼓励互动。时间一般控制在一个小时以内,所以一般选择在中午饭的时候,有的session会给大家订饭,一边吃一边听。

虽然大部分Sessoin的主题是技术相关的,但是并不局限于此。比如旅游见闻,历史,财务,摄影等等,都可以分享,有时候这些趣味性的Session的参与者更多。

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相关的培训,一方面是找自己组内的专家组织一次内部培训,,另一种是找办公室内相关的专家来进行培训,形式比较灵活。

  • 项目中已经在使用的技术
  • 项目中将要使用的技术
  • 请别的组的专家来咨询

group learn

社区

  • OpenParty
  • Rails Girl

rails girl

问题

  • 谁当讲师
  • 活动经费
  • 内容如何持久化(人,内部知识分享系统)
  • 如何保证效果(宽松)

由于对任何的话题都没有限制,也没有对参与者的限制,因此任何人只要感兴趣都可以作为讲师。而又由于没有任何的强制措施,参与者和主讲者都凭着自己的热情来组织,这也算是比较独树一帜的事情。

而关于内容的持久化,更多的是为参与者打开一扇新的窗户,或者说洒下一些火星,而至于火星如何形成燎原之势,则完全在参与者自己的自觉。好多次和客户分享了我们的培训机制之后,被问到最多的问题是如何强迫参与者产生热情?

这个问题在ThoughtWorks不是问题,我们在一个人进入公司的最开始,也就是面试的时候,就考察了他的热情,如果在热情上有缺陷,则很可能会直接拒掉,免得破坏我们好不容易构建起来的学习氛围。

Share

重复造轮子有何尝不可?

在软件行业,或者说在程序员这个族群中,流行着这样一句话:不要重复造轮子。相对好的意思是应该尽可能用现有的实现来解决问题,而不太好的意思就是你太笨了,有现成的还要重写,醒醒吧?然而,纵观整个开源社区,几乎每段时间总会有各种各样的轮子被重复的造出来,不管是DI容器也好,还是MVC框架也罢。虽说随着语言的发展,有些新的轮子确实比旧的轮子优秀,然而大部分轮子都很快的销声匿迹了。当作为一个旁观者看到这样一番景象时,“重复造轮子是不好的”这个概念就会在你的大脑中被慢慢的强化,于是渐渐的,你就变成一个轮子的搜寻者,而放弃了作为一个轮子的创造者的机会。

放弃作为轮子创造者的机会?这是什么大不了的事情吗?也许是,也许不是。如果你真的不关心这个轮子,甘愿成为轮子的附庸,那么它确实不是什么大不了的事。然而,如果你愿意仔细的观察轮子,甚至拆开轮子看看里面的内容,那么也许你会惊喜的发现一个轮子设计者的世界,一个不同于程序员的世界(好吧,设计者也是程序员,有点混淆视听的嫌疑)。

在程序员的世界,可以这样说:我们的每一行代码都是设计。这个设计包括两个最基本的特性:正确性和可维护性。就拿我自己来说,写代码的过程其实是人格分裂的过程,第一种人格要求要把自己想象为一个功能的设计者和实现者,第二种人格需要把自己想象成为这段代码的阅读者和维护者。对第一种人格的驾驭是相对简单的,只要功能实现,通过测试,运行正确就算完成了。然而,第二种人格却要求更高的代码质量,更明晰的代码结构和更好的扩展性。想要成为一名合格的程序员,对这两种人的驾驭是必须修炼的课程。

而在轮子设计者的世界,又至少多了一种人格:轮子的使用者。当你有幸成为轮子的设计者并转换到这种人格时,应该考虑什么问题呢?— 就是为什么要用你的而不用别人的,你的轮子要表达的是什么。更确切的说是你的轮子应该具有怎样的态度,即想要传达的设计理念以及你的坚持和取舍。这就要求你需要考虑:设计应该是大而全还是小而精?是Based On Configuration还是Convention over Configuration?是明确的告诉使用者Please stop, you are doing wrong!!还是OK, I can handle it for you,等等。当前,很多成熟的框架或者语言,它们都有自己相对明确的态度,比如,Spring就是为了解决J2EE的问题而生的,所以它不仅仅是一个IoC的容器,不仅仅是一个MVC的框架,它需要覆盖J2EE的各个方面;而Guice,就是要成为一个轻量级的DI容器,抛弃烦人的XML文件,转而采用了代码即配置的方式;再如Go语言,它是在语言界难得的愿意去做减法的语言(对比Java语言的发展以及又裹了一层语法糖的Java8…)。所以,即使你是完完全全的重复造一个轮子,那么沿途的风景也是十分诱人的,想象一下在你大脑中三种人格的不停切换以及无休止的争吵是不是会让你兴奋?

最后,来看看伟大的数学家和哲学家笛卡尔是如何看待造轮子这件事的。笛卡尔在他未能完成的遗作《思维指导法则》(Rules for the Direction of the Mind)写到:“年轻时,每当我听到一些精妙的发明,我就尝试自己来发明它们,甚至是在没有读过那个作者的文章的情况下。在这样做的过程中,我逐渐发现我自己正在使用某些法则。”。程序员们,选择一个你们喜欢的轮子,重复造它一次吧!

Share