今天在Q群里唠一个新技术（关于phper如何学习swoole）的时候，突然一群友发一句“脱离业务的技术都是耍流氓”，顿时让我等老鸟无言以对。然后，就是一堆的不明群众复制、刷屏。。。
幸好本人反应够快，快速输入下面这段话：
分享一些工作的经验：不存在脱离业务的技术。所有新技术都是为了解决一些业务痛点，让特定业务更爽。
当我们掌握足够多的技术，在遇到问题时就可以选择适合的技术进行解决。反之，如果没有技术储备，就会手足无措，又或者说选择一些不太恰当的技术进行解决，最终都会走一些弯路、踩一些坑。走弯路、踩坑固然是所有项目都会遇到的一个问题，一个人走弯路、踩坑也许不是什么大问题，但整个项目走弯路，这个最终苦的还是我们这些技术人员。
技术储备至关重要，不论是团队还是个人。有了足够的技术储备，才可以游刃有余，做到胸有成竹，遇到问题可以快速找到N种解决办法，并评估各个方案的优缺点进行合理选择。
总之一句话：根据业务场景选技术，但前提是对各种技术都有深入的理解，能熟知其利弊。
下面会围绕这个观点，做一些延伸思考：
1：技术由何而来？
关于这个问题，我的同事 "江边望海" 曾经提到一种关于"技术人员的成长之路"的思路可以拿来借鉴：
第一个阶段： 做技术人员的前3年，不断的做业务，做各种各样的业务。
第二个阶段： 3-5年，解决一些异常问题，遇到足够多的问题。总结其规律，找出业务痛点
第三个阶段： 根据痛点、规律制定流程（开发规范、协作方式、设计模式），开发新的解决方案（新技术的诞生）
不谋而合，新技术的目标就是为了解决一些痛点，优化工作效率。无论新技术是一种实际的技术，如redis、hadoop等解决现有存储的问题。还是如MVC、设计模式、OAuth一般只是提供一种思路，不同语言有不同的实现。新的技术（思想）只是针对特定痛点的一剂良药，用的得当便可事半功倍，用的不得当便会事倍功半。
2：如何寻找业务的痛点
先说一段题外话：很久以前的一次聊天中，我给客服小妹讲一黑科技：现在有一种技术，可以模拟任何人的手机号给任何人打电话、发短信。
然后客服小妹就问，这技术有什么用呀？
可以把自己伪装成任意一个人，然后给你打电话，你怕不怕。
然后呢？
这么说吧，假如给你家人发短信，上面显示你的手机号，让汇钱，怕不怕
我家人才没这么笨。。。
那。。。
然后我就各种解释，想让她明白这技术多么牛逼，多么有用。
“好啦，我明白了，我逗你玩的，别太认真，哈哈哈哈”
然后就这样了。。。技术是很牛逼的技术，只是要想让别人认可这项技术，寻找这项技术所解决的痛点尤为重要。幸好只是跟同事瞎聊，如果就拿类似这样的方案跟领导讲技术解决方案，说不明白各模块所存在的必要价值，估计就惨了。
好吧，说正事， 如何才能寻找开发中的痛点？
- 主要还是多做业务，做足够多的业务，做足够多重复无味的工作。其它的岗位也是一样，只有足够多的使用自己的产品，才会去反思如何提升效率。
- 一旦有了反思，有了提升的想法，便进入上面所提的第二个阶段。
在这个阶段，开发效率便会有所下降，因为想的更多，反思的更多。但这些想法往往不被认同，因为这些想法不符合常规的思路。所以你需要更加的努力，整日整夜的忙，产出却跟其它人并无区别。需要补更多的课，比如他人认为完全用不到的TCP/IP、网络编程、算法导论等基础知识。思考的更多，总结更多的规律，就会发现越多不知道的东西。这个阶段也许要2年，也许永远走不出来，永远对一些理论抱着仰望的态度，却从未花时间去真正了解，期望着有大牛封装这些功能。如果愿意花一个周末全心的去了解，没有哪项单一的技术是解决不了的。所谓积少成多，多读书，多看官网，此时可以借鉴的资料已经不是特别多。但此时有一个好处，只要是能找到的资料都是非常有价值的，不会再有那些眼花缭乱的翻版与误解。 - 选择对业务有用的东西，深入理解、总结其利弊、分析其应用场景，然后快速进入下一阶段尤为重要。
- 在这一阶段，就是要总结业务痛点，综合所了解的知识，提出适当的解决方案。适当的时候需要开发自己的一套解决方案，如上所说，也许是一套理论，也许是一个实际的工具软件。
3：引入新技术存在的问题
引入新技术可能存在一些问题，这是大家的共识。具体问题包括但不限于以下几点：
- 不可控因素，突然not work怎么办。所以很少有人在核心业务中引入一些不是常规的第三方解决方案。
- 学习成本。一般公司都有自己的技术储备，一旦引入新技术，就需要自己的团队去尝试、培训、上线测试、填坑。
- 部分员工的排斥心理。这个不解释
曾经听过滴滴架构师李令辉的一次分享《用灵活的架构去适应变化的业务》，明确指出了我们不引入新的开源技术。这看似有些难以理解，但却有其意义。引入新技术有其优势，也有其弊端。再引用李令辉的一句:
我们还有野心重新梳理整体业务架构，中国架构师比较不自信，当设计一个新架构的时候，你的领导和同事就会问是否有大公司这么做过，大公司包括了BAT3M。
技术方案固然重要，但有一点更为重要，就是团队的“内研”能力。团队的内部研发能力如果较弱，就算拿最牛逼的技术依然会走弯路。别人的技术方案只是一种工具，内研能力才是决定我们是否能把这个工具用在正确地方的主要因素。
4：如何引入新技术
- 分阶段而论，如果是创立阶段，制定一些框架类的规定，其它的技术方案选型以快为主，唯快不破嘛。能快速解决现有问题的方案就是好方案。
-
到达盈利模式后，解决掉技术债务（把欠的东西都还上），这样才能一身轻松的快速前进。积累经验，分析各技术方案在业务中的利弊，发挥其长处、避开其弊端，充分提升业务能力。制定开发规范、优化协作模式，新技术的引入、使用、深入分析、适用场景分析。当做好这些准备后，个人认为开发效率至少能提升5倍以上。
重新说明一下：新技术不只是指实际的软件，也可以是一些思路、一些模式。
5：最后
最后还是说一说开始的话题：phper有没有必要学习swoole。本来就是想说这个话题的，结果被打断了，好吧，我还是很执着的。swoole做为一个新的技术（其实成熟版本已经存在3年以上），与php充分融合，借用php的语法，使用php的cli运行模式就可以测试其全部功能。看似swoole是php的一个扩展方法，实则不然。swoole是一套网络框架，看过其源码就会明白，其中有大量的C代码，实现了并发、网络编程、共享内存操作方面的东西，最终只是以php的扩展方式做为最终呈现。
那么，还有必要学吗？当然有，php做为一种脚本语言，常规的职责就是藏在nginx/apache的后面接收请求，处理请求并返回给nginx。存在的问题是每接到一个请求就需要初始化一些资源，返回结果后就把资源释放掉。这就决定了php只能做web应用，做服务就略牵强。举个例子来说，用php提供一个分词服务，分词的服务端需要先加载词典，然后接收用户传入的文本，将其分词并返回。整个过程最耗时的就是加载词典，而php常规的php-fpm模式需要每次加载词典，这无疑是个很大的问题。如果把php前端的nginx去掉，php直接对外提供服务，那么就可以让php启动一个进程并一直存在，词典也只需要加载一次。
这看似简单的调整，实则已经改变了php在整个架构中的职责。如swoole官网所写：重新定义PHP。
要如何学？官网的demo看起来很简单，但刚才已经说了，swoole不再是单纯的php，是重新定义PHP。常规phper所不了解的网络编程、并发、进程间通信在这里已经是常识问题，不会有单独的文档介绍这些内容，需要自己去补充。如果有java、C/C++的并发编程经验，上手这个会更方便。如果单独去了解一下相关的知识，再来看这个东西，会有一种遇到神器的感觉：swoole简化了网络编程的许多方面，可以让phper以最快的方式实现一个网络服务器。然而也有一步一个坑的走过来的phper，真是边走边在心里咒骂，怎么这个坑在文档中没有说明，为什么这个变量不起作用。具体的坑在另一篇文档中有说明（入口），这里就不再调戏swoole了，哈哈。至于swoole能做什么，有人问能做数据采集吗，这里也不做解释，swoole提供了更多的可能。掌握此技能很有必要（业余时间），不管现在你是否有适用场景。
不是有个段子吗：如果你有一把锤子，看哪都是钉子。但如果你有100种熟练使用的工具呢？
所拥有的见闻（技能），决定了所看到的世界。
