ThoughtWorks Developer的全体验

为什么要坚持主干开发？
为什么 DB Migration 只做Up 不做Down？
为什么要做 Story Kickoff 以及 Desk Check？

当一个新加入的开发者，看到团队的开发方式，跟自己的经验有很大的差异，对着整个团队抛出以上的好奇，甚至是质疑的时候，团队应该采取怎样的方式应对？

这样的“搅动”，能给日复一日的团队活动带来新鲜的思考以及回顾，这让我个人感到点兴奋，毕竟，即使那些认为方法和纪律理所当然的人，也未见得就是深刻理解了它们背后的成因。

然而更重要的是，我意识到，我们长期以来坚持的开发方式和纪律，已经开始竖起一道难以在短时间越过的壁垒，它们中的相当比例，因为开发实践方式之间彼此勾连，往往总结于经验教训。这对于持有相似的经验背景的人不啻于醍醐灌顶，但对于尝试短时间内仅仅单纯去理解它们的人来说，就显得不那么友好，甚至反而容易被归咎为僵化。

我挺相信有Developer全体验这样的一个东西存在，因为ThoughtWorks是如此一个具有自己特殊软件开发理念的组织。虽然可能会心安于被冠以学习型组织和团队，但个人的学习仍然是不能轻易可以迈过去的门槛，这其中需要个人持续不断的努力。

下面是我的几点建议，给那些往着具有更丰富的全体验方向的人参考。

多看多想，先不急于表达

真实表达自己的想法和疑问，并不代表它们不是应该先通过仔细的思考。而这往往是那些急于证明自己的人所忽略的。如上所言，当下看似僵硬的纪律和理念，多是出自长久以来的经验，和开发者之间潜移默化的传承，这些“不可言说”的隐性知识多是宝贵的财富。

我很建议不着急表达疑问，尤其在没有搞清楚上下文之前。司空见惯的现状当然不见得都是正确的，但厘清了上下文之后，会有更满意的答案和解决方案。这更像是“守破离”中的守，守得了“形”，才可能进入到“破”。

多读书，多看分享

同样，由经验竖立起来的壁垒，很难在日常的团队活动中，通过只言片语的游说就得以彻底翻越。而轻易由完全采取信服的姿态，这反倒是未经深入思考的不成熟。读书，本该是全面领略知识体系结构的不二选择，现在似乎变成了最奢侈的选择——只因为读书已经不再是多数人心目中最具捷径意味的学习方式。

来自有经验者的分享，文章或是演讲，也许是另外一种相对于读书而言，稍微具有捷径意味的学习方式。

主动分享

证明是否有深刻或全面的掌握，最好的方式是自己能够面对众多人讲出来或者写出来，没有之一。这是ThoughtWorks推崇的方式，无需多言。但现在看起来，这不是多数人容易迈过去的障碍——在众多人面前讲话，兼具经过设计的内容结构。多多练习，不怕失败。

换新项目

这几年，我看到不少开发者从加入，到离开，一直未有超过一个项目的经验。我为他们觉得遗憾。就我自己的经验而言，这里的项目区别很大，个人的体验也可以完全面目全非。

换一个新项目，不止是新的客户和行业需求，以及新型的技术栈，更吸引人的，是一起合作的新的同事和经验的碰撞，以及在新的语境下，所做出的种种选择时的平衡之美。而这是在这里成长的妙不可言处的一处。

尝试新技术

尝新的动力来自于孜孜不倦的兴趣和勇气，在不影响交付客户价值的前提下，即便可能为团队埋坑，也是不可多得的经验。重要的是习得这些经验还能分享出来。