那些令技术人纠结的困惑（下）
极客时间编辑部
讲述：初明明大小：4.96M时长：05:25
你好，欢迎收听极客视点。
此前，美团到店餐饮算法策略负责人刘丁在公众号“美团技术团队（ID：meituantech）”总结了自己在工作中遇到的一些技术人典型困惑。极客视点摘录了其中的八个问题，供你参考。在上一篇文章中，我们分享了其中四个困惑，本文接着来看其余四个。
1. 平台化的传说
平台化算得上是“高大上”的代名词了，很多工程师挤破头就为了和“平台化”沾点边。然而和其他业务需求相比，平台化需求并没有本质上的区别。无论是平台化需求还是普通业务需求，它的价值都来自于客户价值。不同点如下：
很多平台化需求的客户来自于技术团队，普通需求的客户来自于业务方。
产品经理不同。普通业务需求来自于产品经理，平台化需求的产品经理可能就是工程师自己。
很多平台化的关注点是接入能力和可扩展性，而普通业务的关注点更多。
归根结底，平台化就是一种普通需求。在实施平台化之前，一定要避免下面两个误区：
平台化绝对不是诸如“统一”、“全面”之类形容词的堆砌。是否需要平台化，应该综合考虑：客户数量，为客户解决的问题，以及客户价值是否值得平台化的投入。
平台化不是你做平台，让客户来服务你。一些平台化设计者的规划设计中，把大量的平台接入工作、脏活累活交给了客户，然后自己专注于所谓“最高大上”的功能。恰恰相反，平台化应该是客户什么都不做，所有的脏活累活都由平台方来做。本质上讲，平台化的价值来自于技术深度。真正体现技术深度的恰恰是设计者能够轻松把所有脏活累活搞定。
所以平台化的最佳实践是：投入最少的资源，解决最多的问题。平台解决一切，客户坐享其成。
2. 搞基础技术就一定很牛吗
经常听到人表达对基础技术部同学的敬仰之情，而对搞业务技术的同学表示轻视，认为存储、消息队列、服务治理框架、Hadoop 等才能被称为真正的技术。事实并非如此，更基础的并不一定更高深。
比如下面这个流传很久的段子：越高级的语言就越没有技术含量。但真是这样吗，就拿 Java 和 C 来说，这是完全不同的两种语言，所需要的技能完全不同。C 或许跟操作系统更加接近一点，和 CPU、内存打交道的机会更多一点。但是为了用好 Java，程序员在面向对象、设计模式、框架技术方面必须要非常精通。Java 工程师转到 C 方向也确实不容易。
基础技术和业务应用技术必然会有不同的关注点，没有高低之分。之所以产生这种误解，有两个原因：
第一，基础技术相对成熟，有比较完整的体系，这给人一种高大上的感觉。业务应用技术相对来说，由于每个团队使用的不一样，所以成熟度参差不齐，影响力没有那么大。
第二，基础技术的门槛相对来说高一点，考虑到影响面，对可靠性、可用性等有比较高的最低要求。但是门槛高不代表技术含量高，另外成熟技术相对来说在创新方面会受到很大的约束。但是最先进的技术都来自活跃的创新。
对比下来，业务技术和基础技术各有千秋。但真正的高手关注的是解决问题，所有的技术都是技能而已。
3. 可行性调研的那些坑
工作中开展可行性调研时有发生。做可行性调研要避免如下情况：
把可行性调研做成不可行性调研，这真的非常糟糕。不可行性的结论往往是：因为这样或者那样的原因，所以不可行。
避免“老鼠给猫挂铃铛”式的高风险可行性方案。可行性调研一定要细致入微，避免粗枝大叶。
避免调研时间过长。如果发现调研进展进入到指数级复杂度，也就是每前进一步需要之前两倍的时间投入，就应该果断停止调研。
可行性调研的结论应该是收益与成本的折衷，格式一般如下：
明确预期的结果，并按照高中低收益进行分级。
阐述达成每种预期结果需要采取的措施和方案。
给出实施各方案需要付出的成本。
4. 效率、效率、效率
经常看到有些同学给自己的绩效评分是 100 分——满分，原因是在过去一段时间太辛苦了，但最终的绩效却一般般。天道酬勤不错，但是天道更酬巧。工程师们都学过数据结构，不同算法的时间复杂度的差距，仅仅通过更长的工作时间是难以弥补的。为了提升工作学习效率，我们需要注意以下几点：
主要关注效率提升。很多时候，与效率提升所带来的收益相比，延长时间所带来的成果往往不值得一提。
要有清晰的结果导向思维，功劳和苦劳不是一回事。
做正确的事情，而不仅仅正确地做事情。
以上就是今天的内容，希望对你有所帮助。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论