美文网首页
传统软件公司技术迭代再思考

传统软件公司技术迭代再思考

作者: 夫礼者 | 来源:发表于2020-07-25 01:18 被阅读0次

书接上回谈传统软件公司技术迭代与革新

1. 概述

在上一篇博文中,笔者臆断了一条破局之路——通过刻意的引导和选拔,筛选出一批主动性人才来推动技术迭代革新的落地。

本文是对前文的补充性说明,力求进一步解释理论基础和实践细节。寄希望于通过反复地思考研究最终找出一套切实可行的落地方案。

2. 问题再总结

前文已经就问题进行过一些简单的陈诉,以下将是更为详尽的汇总补充(注:以下问题相信只要在这个行业里待过的,都能感同身受,这不是一个公司的问题,是全行业的问题):

  1. 单个研发中心内部,各个小组之间的技术栈都无法做到统一(看似都是SpringBoot + Vue,但在人类主观能动性的支持下,最终是一龙生九子,九子各不同)。更妄论多个研发中心的技术栈统一了。
  2. 人员缺乏规范性培训。入职员工基本没有经过规范性培训直接上岗,导致其将上一家公司的技术栈和代码风格毫无保留地引入到本公司产品内部,进一步丰富了产品代码库的编码风格。
  3. 人员流动速度快。这不仅仅体现在离职率上,还体现在各个项目组之间的人员频繁互调。
  4. 缺乏有效的监管和反馈机制。限于繁重的业务压力,导致领导以及下面的一线管理人员都无暇对整个软件开发流程和产品代码质量进行监管。而按照"熵增定律",这势必导致系统快速进入无序状态。
  5. 软件产品化。对于软件公司而言,领导层对于软件有着天然的"产品化"动力,毕竟「一次投入,多次收益」这种一本万利的好事任何人都无法拒绝。而这导致的结果就是一个系统需要持续迭代数年,我们总是有着无数的历史债要还,跳着镣铐跳舞的同时却不敢进行有效的重构。
  6. 基础设施缺失。缺乏专业运维,CI/CD也没有提上日程,DevOps更只是个概念。
  7. 缺乏积累沉淀。技术研究各自为战,很少沉淀,研究成果基本是在相关人员的脑子里,组内分享都存在障碍。
  8. 等等。

3. 分析

以上总结的多个问题,彼此之间并不完全孤立,反而因为经常是在一起相互影响,产生出「 1+1 > 2 」的威力(这实在不是什么好事......)。

所谓"逆水行舟,不进则退",面临这些问题的时候,我们必须找到一些突破。

其实我们在摆出上述问题的同时,相应的解决方案也是暗含在了其中,而且这些解决方案并不是互斥的,可以同步进行,但我们确实需要排个优先级。正如习惯的养成一样,你最好一次只关注一个。这次我们将目标锁定在「技术栈的统一」上。

注意我们上面所说的统一,不只是某个功能实现时候使用的第三方依赖的统一,甚至还会涉及到开发工具等的统一,总之一句话:"相较于能力超群的独行侠,我们更需要集团军中的每一个人"。

我们要求极致的统一,我们要:

  1. 将注意力放在真正值得消耗的位置,其他的地方尽量统一掉,方便集中力量办事。
  2. 降低对人的依赖。实现项目组之间,部门之间,甚至研发中心之间的人员互调,基本条件之一就是统一的技术体系(诚如上面所说的,我们要求的是从编码风格,功能点解决方案上的一致,而不是仅仅一个SpringBoot +Vue就算是统一了)。

4. 行动

  1. 将技术研究和技术推广进行剥离,严格进行划分,方便进行职责认定和研究成果的落地。我们总是急于求成,或者没有刻意去理解这两者之间的区别,现在必须作出改变了。
  2. 研究的完成不仅仅是当事人理解了其中的原理和使用它解决了当前的问题,将研究成果沉淀下来让更多的人能够快速入门才是技术研究的最终形态。研究的过程中以及研究成果推进过程应该沉淀下大量的经验,这一步非常重要,怎么强调都不为过。自上而下的强行推动技术栈的统一往往导致相互推诿,怨声载道进而事倍功半,所以在"推"的同时我们还要使用"拉"的技巧——吸引其他组或者部门的人员来使用我们的技术栈,而一整套完整的入门手册和踩坑分析文库积累胜过无数次的游说。

5. 最后

厚颜无耻地招聘一波,看完以上内容之后,欢迎认同其中理念,有意挑战自我,作出一些成就的仁人志士投递简历。(虽然招聘到人才的机会渺茫,但是万一呢?咸鱼也得有个梦想不是)

我们的要求不多:

  1. 理念认同。本文尾部给出的链接可以作为补充去看看。
  2. 基本功到位。软件开发的基本理念应该都知道,经典书籍啥的也都看并且思考过了。
  3. 积极主动。这一点最为重要。我们实在是不能接受为了让某个人工作,还得再搭进去半个人去盯着他。另外我们将要做的事情很难做到定量衡量,因此主动性更显得尤为珍贵。
  4. 最后一点:我们不在乎你解决当前这个问题耗费了多少时间? 我们在乎的是你在解决了这个问题之后,你是否会考虑如何让其它同事或朋友不再去踩同样的坑?毕竟做事方式可以教,做事态度教不了。

最后例行介绍:
苍穹数码技术股份有限公司武汉分公司多个部门,诚招中高级Java方向,前端研发。有意者邮箱:lqzkcx3@outlook.com

6. 补充

以上"行动"小节提供的方案中,笔者个人推荐对于技术积累比较薄弱的部门,可以采用外援的方式来引入统一的技术栈,然后通过文档等形式沉淀下来对于技术栈的理解和研究,这样的一套完整的闭环实现了:

  1. 作为外援引入的优秀技术框架能够省却了大量技术选型和踩坑的时间,能够将解放出来的精力集中到框架研究和文档编写,以及人员培养和监督上。
  2. 后续研究和文档能够让我们对于上面的技术框架烂熟于心,使用起来胸有成竹,并为人员流动和更迭做好充分的准备。

7. Links

  1. 知乎Answer - 为什么做 Java 开发的公司需要那么多程序员?
  2. 知乎Answer - Java 项目开发团队有必要统一 IDE 吗?
  3. 知乎Answer - 如何避免自己离开框架就什么都不会?

相关文章

  • 传统软件公司技术迭代再思考

    书接上回谈传统软件公司技术迭代与革新 。 1. 概述 在上一篇博文中,笔者臆断了一条破局之路——通过刻意的引导和选...

  • 谈传统软件公司技术迭代与革新

    个人的一些呓语。其实标题也可以改为"论公司技术氛围的形成——'潜龙计划'的执行?" 1. 前因 规模比较大的传统软...

  • 2020-05-04敏捷项目管理模式

    敏捷项目管理模式 项目管理使用传统给的APM管理,迭代管理使用scrum,技术层使用XP。 技术包括从持续集成到结...

  • 传统软件行业中技术团队的发展(现状篇)

    传统软件行业中,技术团队人才梯度如何迭代和演进? 技术人员如何破局,实现个人发展与公司发展的契合。认清它,承认它,...

  • Facebook增长黑客笔记

    ——馒头商学院 Growth:增长 Hack:马上上手、快速搞定、持续迭代 特点:非传统,技术驱动,数据为王 Fi...

  • SAM场景化课程开发技术介绍

    来自美国AllnIntractions公司的SAM敏捷迭代课程开发技术 传统的课程设计需要做知识类别分析,即判别教...

  • App月度迭代计划

    一:迭代时间安排: 四周为一个迭代,时间安排如下: 二.迭代流程图: 三.迭代执行规范: 1、技术审: 技术审在可...

  • 建筑智能化未来发展方向是什么

    随着互联网、人工智能、物联网及自动化技术的发展,传统行业纷纷转型并向智能化智慧化靠拢。然而技术不断迭代,将建筑行业...

  • 世界观是这样形成的

    我们总结了什么是历史,发现了两个线索,就是,人类社会技术的迭代升级和思想的迭代升级。而技术的迭代,自然就引导出技术...

  • 先写再迭代

    先写,写不好,也没关系,因为,好内容是迭代出来的。

网友评论

      本文标题:传统软件公司技术迭代再思考

      本文链接:https://www.haomeiwen.com/subject/cwdbfktx.html