也算机缘巧合，一个不能称之为机会的机会让我再次和国外现在炙手可热的F
公司(
由于也不想过多的说这家公司的名字，因此就用F
作为代号了)
做了一次技术和公司文化的简单交流，这里做个简单的交流分享，希望能够让更多的朋友能够从中找到自己团队或者公司有帮助的内容。但这里还是丑话说在前头，中国有句成语：东施效颦。国外的月亮多圆我不知道，但是我们需要客观的看待不同环境的差异，看到目标，而不要过多模仿过程。下面的阐述将都分成场景和观点，如何做三部分，场景描述了具体的情况，观点仅仅代表我自己的一些感触和理解，如何做是对问题Action
提出自己的想法。
场景1：
F公司的任何一个小Team（业务上划分或者职能上划分）都需要熟悉整个系统从前到后从上到下的代码实现。例如相册团队，从前端脚本，到业务逻辑，再到底层的Memcached或者图片服务器代码在必要的时候都能自己修改和实现业务需求。UserGroup团队是负责对全球业务的用户做统计分析的，当希望做一些变革能够尝试着提升用户转化率的时候，首先是考虑自己如何动手去修改已有系统的功能，而不是去协调各个团队去做。
观点：
垂直化的开发模式其实挑战了国内很多企业的横向细分化流水线方式的开发模式。从技术的横向细分，到业务的模块化细分，好处是提高企业的生产效率，坏处是对人全方面的培养成为一种制约。最大的问题：对自己上游系统的需求了解不透彻，对自己依赖系统的实现完全不理解。
如何做：
横向切分的方式和纵向的方式都有适应的场景，因此可以考虑在互连网企业中部分部门中实施垂直化开发模式，这些部门人员素质较高，能够从产品层面全局的考虑整体的发展，通过实际的参与各个业务线和各个层次的技术中间件开发，为横向切分的部门工作做出改进和建议。这样在高素质人才发展和网站规模化整体化发展之间找到平衡点，相互促进。
场景2：
F公司的任何一个技术框架都可以被挑战和替换，只要用数字和测试结果作为有效的证据，大家都抱着对公司负责的态度来对待技术选型。因此在F公司中，技术的发展完全是最原始的优胜劣汰机制。
观点：
这点其实很赞同，首先技术如果不是用数据来说话，采用自上而下的方式来决定选型，那么就是拍脑袋做事情。另一方面，如果技术不持续的按照用户需求来优化和演进，那么一定会烂掉，最好的触动不断发展的方式，就是竞争。有人会担心技术竞争会带来资源消耗，其实烂掉的东西在被使用的过程中一样在消耗。
如何做：
首先当然还是提倡积累，能够在已有的技术基础上不断积累发展是最好的，其次也应该鼓励创新，如果有足够理由证明成熟的技术能够替代现有技术，而现有技术又没有发展的动力时，变革并不是坏事（也许这种压力就会迫使原有技术实现者去更好服务客户），最后就是给每个人都有改变任何一部分代码的能力，因为依赖的不稳定也决定了上层系统的不稳定，作为一个产品来看，每个人是对产品负责，而不是对一个组件负责。
场景3：
没有任何文档。最多写一点wiki。
观点：
设计从简，代码需要更优雅，注释需要更全面。文档是代码的骨架。
如何做：
应该有产品需求文档，理解业务需求。技术文档多半是总体性设计和一些协议描述，多一些代码注释和Demo，更利于学习和阅读。
场景4：
应用都被编译在一个包里，一台机器就运行了诺大一个网站的所有功能，不存在服务器间的应用服务调用，都是本地服务方法调用（服务依赖较少）。
观点：
这和Java类型的应用还有些差别，Java的第三方依赖较多，版本凌乱复杂，导致应用部署在一台机器上很困难。但很多大型网站的系统设计慢慢地就将模块分的很细，结果导致服务调用和依赖特别复杂，自身的可用性和稳定性变得难以估量。
如何做：
需要审视服务粒度的合理性及垂直化设计在不同系统中的应用，需要在可扩展和可用性及效率中差别对待不同系统设计，同时降低服务差异性，减少应用服务器由于应用差异导致无法复用的问题。
场景5：
任何一个应用或者中间件开发完成后，都会有一个监控应用伴随诞生。（有些是直接通过已有工具实现，有些独立实现）
观点：
1：1的透明化开发比unit test来的还要重要，因为运行期的系统透明化是业务分析，系统优化，系统监控告警最基本的要求。
如何做：
最低代价就是将监控数据记录打点，应用或者外部系统对数据进行计算和分析，最终提供结果给外部系统展现和处理。
场景6：
没有测试团队，任何开发都是测试人员，通过工具完成页面，接口，集成测试。
观点：
强大的测试工具框架为开发人员提供了测试的规范性和便利性，同时开发人员自身的责任感增强，也让开发人员在测试过程中总结和思索开发设计的常规性错误，理解边界问题。
如何做：
需要有专人专职来负责测试框架的有效性，当然对于这个人或者这么一个小团队来说要求很高。可以借鉴的是，测试团队应该有更加高效的方式自动化测试，同时应该将测试框架开放给开发人员，增强开发人员对产品质量的责任感。
场景7：
没有线下的压力测试和极限测试，线上引流和部分区域发布来做测试。
观点：
一直认为线下的网络环境，用户数据的仿真度都难以模拟线上，因此很多压力测试和极限测试的数据基本就不能成为依据。在数据透明化体系完成后，线上的任何改变都可以获得数据的支持，这样单独或者对比的结果就是压力测试或者AB测试的结果。
如何做：
系统透明化工作为基础，结合Beta发布或者局部发布的模式来验证和测试不同压力下的新老系统。
场景8：
Hack Day，一个晚上通宵做出原型，第二天在全公司面前展现创意，用技术来说服有兴趣的同事一起去做一些有创意的工作。F公司最典型的视频项目就出自于Hack Day。
观点：
通过自己努力和时间的投入，在公司给的平台上展现，最后取得好的效果。
如何做：
公司给平台，个人挤时间。
场景9：
公司中所有的开发人员都是Engineer，每个人可能不同Level，但是每个人的工作都是自己来考虑，上级M只是替Engineer去协调资源。此时任何Team的人如果有想法和创意，如果要做，也需要资源，只能靠自己去说服同事一起做，而M没有权利否定或者强制Engineer去做任何工作。
观点：
由于考核都是同事之间点到点的评价，因此其实M没有任何实质性的技术管理职能在，任务分配和工作目标也是工程师自己需要去考虑的，主动权掌握在自己手中。工程师需要去考虑自己有限的工作时间中如何做有效的做出最有用的内容。能力越大责任越大，因此原本认为束缚工程师的方式，其实反而给工程师偷懒思考的机会。
如何做：
在工程师技术能力达到一定阶层时，国内的公司可以考虑采用这样的方式去管理他们，同时为他们提供更广阔的技术空间去创新和渗透到他们希望渗透的产品中。
场景10：
对于问题从效率角度去考虑如何解决，而不是简单的从资源角度去考虑。
观点：
公司发展壮大，业务战线不断变长，往往第一就考虑需要资源，往往忽略了如何用技术提升效率。增加资源有时候反而是增加内耗和降低工作效率的诱因。
如何做：
压力带来动力，决策者需要判断和观察。
场景11：
每个新人进来都会进入新兵训练营，每个人选择自己有兴趣加盟的两到三个团队，一个月内完成两到三个团队的一些线上问题修复，在熟悉业务的同时，也锻炼了自己的能力，同时更加明确自己感兴趣的团队究竟是哪一个。
观点：
这种方式可以最直接的让新人了解业务，熟悉将来的方向，同时也是检验一个人能力的最有效的手段。
场景12：
不同Level的错误有不同的通报，产生较大问题时，全公司邮件通报，但考核并不看问题发生次数和严重程度（因为每个人都可以修改各个层次内容，多做多错，少做少错这种事情不应该鼓励）。同时，任何过失需要描述四方面内容：现象，问题原因，解决方法，防范措施。范例：有一个同事修改了底层配置系统的部分代码，结果导致全站系统2小时不可用，全公司通报。遂这个同事花了几天时间全部重写了底层配置系统代码，为了防止别人和他犯一样的错误，后遇人都笑谈他重写代码的事，而不是那次问题。
观点：
首先，大家都抱着乐观的态度去看待犯错，看到别人的总结，也是审视自己的工作。其次，最重要的是问题的解决和预防，这点是透明化问题的关键所在，也是驱动犯错者改进自身不足的动力。
如何做：
倡导这种氛围，提升工程师的责任感。
场景13：
对于所有代码的更新时间有监控，很久没有更新的代码将会被提出来，作为烂掉的代码告警全团队。
观点：
很多时候不是做减法不易，而是没人知道什么时候该减什么。
时间有限，其实也没谈太多技术内部的东西，但是从周边的这些内容聊下来，两点让我感觉和去年自己做的一些工作很类似，也很重要。产品责任感，系统透明化。
不论是业务或者技术的垂直化，测试工作前移，产品设计后移（在另外文章中有提到），技术工作自我定义，其实都是在考验一个工程师对产品的责任感，不简单的约束自己在某一个技术领域，在某一个产品环节，在某一个岗位职责，也许听起来是一个较高Level的工程师（国内叫架构师）所需要考虑的，但其实也只有这样的工程师才会称得上是合格的工程师。
不论是1：1系统设计方式，线上仿真测试，丰富的监控系统，其实就是要求做每一个业务系统或者技术框架一定要做好透明化工作，系统透明化是对当前系统负责，对依赖这个系统的外部系统负责。当一个网站各个零部件都能被外部所观察到的时候，出现问题不为人知，缓慢出现量变病化，业务模式AB结果都将变得一目了然。