技术大牛观点整理摘录

1、怎么看待技术兼顾业务？
我第一个小软件也是修改了flash文件将操作光驱的代码植入，然后调研了各种业务场景，最后成功的传播出去并操纵了一把，那时我就默默的感到传播才是关键。今天也是如此，我和每个程序员包括我老板一样担心我自己分心到业务上是否会废了自己的“武功”，其实取决于：1.你到底code了多少代码？（你会因为一个月用叉子吃饭忘记怎么用筷子么）2.你到底是喜欢写代码做技术，还是为了生活所迫？（后者无论你写多少代码还是一个没内功的人）3.写了10年代码以后你留下的只有那些代码和技术入门文档，还是有更多的设计理解。（你用了hadoop除了会配置，会修改部分性能代码，对他适用场景的理解，整个流程的瓶颈点设计，所有分布式都纠结的问题是否有感知）这么多年了，为什么只有那些paper不断的给人启示去做更多的工程化内容，因为用筷子吃面和叉子吃面没那么大的区别。（关键是吃的人怎么理解面难吃的原因）

所以，前面1,2,3都是你在coder时候做到了，那对业务的理解只会让你如虎添翼（重要的是更多去学习和倾听，放空自己的程序员经历，做个用户）

2、如何学习技术？
不用急着什么都学，珍惜每一次不同工作的机会，挖深做细，几年以后回过头来原来自己积攒了那么多！xml解析分成几种模式，各种解析的优劣？http 1.1协议中的Header中的缓存设置，返回头里面的trunked什么用途？分布式计算关键问题是什么（调度，协同，数据交互）？应用压力测试瓶颈如何评定，导致瓶颈的代码所属操作可能分成哪几类? …… 要留下更多疑问背后的答案，而不仅仅是那一点代码，那一些入门文档。

3、怎么看待平台产品？
先要活下来，服务好一个产品线，如果没有任何其他产品线过来，那么就不要在乎平台的称呼，留好口子就可以了。当有多个产品接入，同样要活下来，因为脱离单一业务线为了更好的平衡个体需求和平台发展，但重要的是要找到自己有群聚价值（也就是只有集成在一个平台上，多个业务得到的平台功能才会最大化），这样就业务方就不会独自建立平台来快速响应需求。最后如果业务非常繁荣，那么更多的考虑为业务方挖掘业务价值，而不要聚焦于平台，帮助别人就是帮助自己。（这是平台永远都正确的说法）

4、优化这东西就四步：1.找。2.定位。3.分析。4.迭代平衡瓶颈

5、腊月同学那天在围脖上说：如果自己做事情，老板不知道甚至都不在乎，那是自己的无能还是老板的无能。我给回了一下：如果你认为是老板的无能，那你离成功又远了一点，如果你认为是自己的无能，那你会去选择改变，你离成功又近了一步。改变自己有时候是改变处境最快最有效的方式，同时审视自己的不足是提升自己，为机会到来做准备最好的动力。在阿里需要面对变化，没有一点乐观的心态，那么有时候就自己郁闷去了

5、程序员陷入在自己的一亩三分地

主要表现得症状

1.       PD的需求就是目标，踏实的实现，不懂的就猜。

2.       经验盖过一切，设计系统就是要够完备够复杂。

从开发人员角度来看，第一种人多半比较有自己的想法，同时也有不少的工作经验，同时可能对技术比较着迷。另一种人多半是刚刚工作或者经验不足，要么就是习惯性把工作当任务，而不是爱好，写程序也就是一份赚钱的活。但看起来其实各自都在自己的一亩三分地上捣鼓，忘记了作为一个开发人员最基本的原则：“满足客户需求”。