业务越来越复杂，组件越来越多，技术人该何去何从？

公告:文章会第一时间发在微信公众号《魔笛手CTO》，欢迎关注 

可能很多开发人员都遇到过类似的场景：随着业务的发现，越来越多的技术组件被引入到系统架构中来。开发人员要去了解每个组件的功能和特性，解决组件之间交互产生的问题，最关键的是每个组件都在不停更新新的特性。很快开发人员的精力就会被耗尽，这时候往往会做出一些匪夷所思的行为。

有人曾在某项目的GitHub下留言： “求不要更新了，老子学不动了”

 

 

“吾生也有涯，而知也无涯”，怎么样才能避免被技术工具拖累呢？

 

一、基础

郭靖能成为天下第一，不是因为他博采了江南七怪的各家所长，而是因为马钰教给了他全真教的内功心法。正是因为了有了内功作为根基，郭靖才有机会把握后面的每一次奇遇，学会降龙十八掌，参悟《九阴真经》。当一切水到渠成之后，郭靖才有自信在打不过欧阳锋的时候，仍能说出：“饶你三次性命”。

 

学技术也是一样，正所谓：基础不牢，地动山摇。而技术的内功是什么？无外乎算法与数据结构、编程语言、操作系统，无论多牛逼的软件都是建立在这三大块的基础之上的。

 

打好基础之后，面对层出不穷的技术组件，才能避免盲目追随，做到有的放矢。

 

二、抽象

抽象之与计算机科学的重要性无论怎么吹捧都不为过，神作《计算机程序的构造和解释（SICP）》开篇就介绍了抽象这个概念。

 

实际上，我们对客观世界的认知，不是因为我们从娘胎就带来了世界观，而是学习了一个又简单的认知之后，形成的复杂认知。

 

设计良好的计算系统就像设计良好的汽车或者核反应堆一样，具有某种模块化的设计，其中的各个部分都可以独立地构造、替换、排除错误。

 

拿Web服务中常用的MVC来说，在业务的初始阶段，一个Controller只需要从数据库读取Model，并渲染成View响应就完成了全部工作。但是随着业务的发展，现在缓存进入到系统架构中来了。一个糟糕的缓存的设计就是将缓存放在Controller中到处缓存，到处缓存就必然会造成：

• 有的地方因为加了缓存导致刷新不及时

• 有的地方因为少了缓存导致性能下降

 

三、重构

《人月神话》给老张留下的其中一个深刻印象是：再好的设计也会腐烂。熵增是宇宙规律，软件当然也逃不出其魔爪。技术架构不是一成不变的，其演进过程中难免会产生各种各样的问题：

• 业务的发展导致系统负载爆了

• 当初过早优化针对的场景迟迟没有出现

• 出现了更牛逼的技术方案

 

学不会动态的看待系统架构，必然会被其拖累致死。而避免这一切的手段就是重构。

人月神话(40周年中文纪念版)

 

 

四、砍需求

这可能是最简单的，但是确是最不容易做到。

 

围绕互联网公司究竟是技术驱动还是业务驱动的讨论很多，老张坚持认为没有纯粹的技术驱动，不说当今世界科技巨头把持着最好的技术专利，回头看计算机的出现还是因为造原子弹产生的算力缺失。

 

新的需求往往意味着能给公司带来更多的收入。但是，对代码负责的不是产品经理，而是开发人员。面对不合理的需求，如果开发一开始没有大声的说不，最终解决问题的还是开发自己。

Vista的失败恰恰是因为产品经理的“我全都要”

 

 

结语

老张也有过类似的困惑，以上就是老张的思考。在有过类似困惑之后，老张才深刻的体会到韩信那句“韩信将兵，多多益善”是多么的豪迈。

韩信是老张非常喜欢的一个历史人物，老张很想为他写篇文章，可惜我们是一个技术号