转载

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

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

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

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

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

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

一、基础

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

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

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

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

二、抽象

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

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

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

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

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

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

三、重构

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

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

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

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

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

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

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

四、砍需求

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

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

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

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

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

结语

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

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

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

原文  https://mp.weixin.qq.com/s/2g_K_0s6aSE1dO--D-zkVA
正文到此结束
Loading...