说到这个“技术流”,现在网上到处都在讲,好像是个挺厉害的标签。不少刚入行的哥们儿觉得,只要技术够硬,跟着某个“流派”走,就能一路通关,解决所有问题。听起来挺美的,对?但实际干起来,完全不是那么回事儿。
我刚开始接触项目的时候,也是这么想的。那时候特迷恋某个后端框架,觉得它的设计思想简直完美,想着以后做啥项目都得用它,这就是我的“技术流”。心里盘算着,需求来,我就用这套东西,唰唰唰建模,写代码,测试,上线,一套标准流程下来,肯定又快又
一头扎进去的开始
那时候真是有点“天真”。接个项目,甲方需求看着挺简单,就是个信息管理系统。我当时就想,这不正好练手嘛把我那套“技术流”方案搬出来,绝对没问题。于是我兴冲冲地开始搭环境,建项目结构,一切都按照那个框架的最佳实践来。
最开始几天,确实挺顺。基础的增删改查很快就弄出来,自己跑跑测试,感觉良心里还美滋滋地想:看,“技术流”就是牛,效率高,代码也漂亮。
现实的“毒打”
好景不长。问题很快就来。
- 是甲方那边,需求开始变。一开始说好的简单信息录入,后来又要加权限控制,再后来又要对接他们一个老的、用十多年的系统,取点数据。那个老系统,文档?没有。接口?Emmm,大概算有,但返回的数据格式能让你怀疑人生。
- 然后是我自己选的那个“完美”框架。它确实设计得但太“纯粹”。对于这种需要跟“老古董”打交道、处理各种脏数据的活儿,它就有点水土不服。很多地方得绕着走,写一堆适配代码,把我原本觉得很“优雅”的结构搞得乱七八糟。
- 还有就是团队里其他人。不是所有人都跟你一样熟悉或者认可你这套“技术流”。有人习惯用别的工具,有人觉得你这套太复杂,学习成本高。结果就是,代码风格不统一,沟通成本直线上升。为一个简单的功能实现方式,能开会讨论半天。
那段时间,我感觉自己不是在“技术流”地写代码,简直是在“救火”。东边堵一下,西边补一块。原本想好的标准流程?早就忘到九霄云外。每天大部分时间都在调试那些奇奇怪怪的问题,跟不同的人沟通,处理各种预料之外的状况。
咋整的
项目是交付,但过程嘛一言难尽。我开始反思,所谓的“技术流”到底是个
后来我琢磨明白,真正的“技术流”,可能不是死守着某一套技术或者工具不放,觉得它是万能钥匙。那玩意儿更多是理论上的,或者小范围内的“最佳实践”。到实际战场,面对复杂的业务、遗留系统、不断变化的需求,还有形形色色的人,最重要的能力是“解决问题”的能力,是那种“见招拆招”、“不管黑猫白猫抓到老鼠就是好猫”的实用主义。
你得懂你的“流派”,但你更得懂什么时候该坚持,什么时候该妥协,什么时候该跳出框架去想办法。手里得有锤子,但也得知道啥时候该用扳手,啥时候甚至得上老虎钳。
现在再有人跟我提“技术流”,我一般就笑笑。不是说技术不重要,技术当然是基础。但光有技术,不懂得怎么把它灵活地应用到乱七八糟的现实里,那顶多算个“技术匠”,离真正的“流”还差得远。实践出真知,这话一点不假。你得亲自下场,被现实“毒打”几顿,才能慢慢摸索出真正属于你自己的、能在实际工作中淌过去的“流”。
还没有评论,来说两句吧...