END TO END。
在传统软件工程的世界里，有一个说法大概是这样，软件生命周期中设计阶段的时间大约是开发时间的三倍，如果再算上测试，需求，等等的阶段，在整个项目周期里编码开发的过程也许不过两成有余而已。这当然只是个大概的比例，却从侧面反映出人们对软件开发的理性认知之后的其中一个重要结论：写代码远不是软件中多么重要的一部分。
软件开发这个行业发展到如今，许多传统的软件工程的思想都已经被不断的更新甚至挑战，人们不断的用新的工作方式去改变传统，人们在无数失败的经验里总结，从无数失败的项目里吸取教训，不断的重新定位每一个参与者的位置，每一个阶段的不同责任，于是我们有了敏捷开发，有了测试驱动，有了很多整个人类世界尚未正确认识软件的时代，完全无法想象的驾驭。但有趣的是，无论这个小世界变成了怎翻模样，你惊奇的发现在任何一个理智的模型里，编码工作都是那么的无足轻重，人们从不会高估它的难度，也从来不会过度的预期它的工作量。写代码这件小事在整个项目里显得那么容易，那么轻描淡写，那么甚至可以说是无足轻重。
可软件开发是如此的难，软件项目的成功率在所有行业的所有项目中，成果率低得如此的不可思议，似乎在软件的代码和产品的产生之间有着巨大的鸿沟，它们总被低估却一口一口吞噬着每一个轻率于它的笨蛋，这些鸿沟很少有人知道如何去填，在高屋建瓴的人们和勤恳的码农之间，似乎有一条总是断开的线。
前几天给一个印度小伙Review代码，他领到的是一个非常简单的小改动，一共只需要新写两行代码而已。他得意的写完并且在本地写了测试代码验证他那原本就简单无比的改动是没有错误的（刚开始写Unit Test的时候，每个人都干过这种事，写一个不会出错的模块，再明知故问的去验证它），他把这些碎片般的作业交给我的时候，我忽然意识到了那到鸿沟的存在，意识到了为什么给了你这么多人，你仍然觉得举步维艰，意识到了人的价值究竟在哪里。
印度小哥写得代码一点错误都没有，但他没有创造出任何一点价值，代码只有在项目里存在才有意义，任何的小齿轮都必须存在于大机器里才有价值，我脑子里有这个机器的蓝图，可我收到的只是一个齿轮的照片。
End to End何其的难，何其的重要。
软件系统的从无到有，是上百种不同的因素的组合，从服务器到网络，从编译环境到系统内核，任何一个环节不正确，哪怕其他的一万个地方都没有差错，你得到的仍然是一个不能正常运作的系统而已。代码本身只是这万千因素里的一个，如此渺小不足道，那么一个只懂代码的工程师，便自然不足道。
可惜，多数人如此，只如此。
愿不久将来，诸位都能成为End to End(全栈)工程师，能扛起一片大天，而不是单单为了一个项目一个功能而战，那好生无趣。
共勉。
以上，写在Ops Team Kick Off第一周。
