3种CTO要小心的架构技术债
2017-09-02 10:01:19 | 来源:ithome | 投稿:尤慧 | 编辑:dations

原标题:3种CTO要小心的架构技术债

图片来源: iThome 番茄、黄瓜等作物需要背后支架作为支撑,才能顺利往上长,而企业想要继续蓬勃发展,撑起其运作背后的IT架构,也扮演著类似地位,例如,软件架构、程式语言的选择,在数位转型、产品转型等重大决策都...

图片来源:

iThome

番茄、黄瓜等作物需要背后支架作为支撑,才能顺利往上长,而企业想要继续蓬勃发展,撑起其运作背后的IT架构,也扮演著类似地位,例如,软件架构、程式语言的选择,在数位转型、产品转型等重大决策都有举足轻重的地位。

而书亚集成技术长曾义峰表示,最理想的技术决策是根据团队、公司需求,搭建出最合适的技术组合,“但现实状况中,技术组合大多是由技术长、架构师等关键人物决定”,如此运作下,一家公司的技术决策,也会跟该关键人物的开发偏好有相当关联。

他表示,不时听到来自软件社交、企业或新创公司的开发者,抱怨如此重大决定,却只通过技术长或是外部顾问所决定,例如一举决定放弃.NET,改为使用Java;或认为使用PHP开发步调太慢,全部改使用RoR,“这些决策未必错,但是必须能够让人信服。”

而曾义峰认为,执行技术决策时,总共有三大重点。首先,必须视架构为最优先考量,“架构会影响商业文化”,同时,不能只重视技术,而忽略既有内部流程跟人员,他表示,当开发者晋身为技术长、架构师后,思维要超越程式码层次,“不能只了解技术。”

第二要素是选择最适合自家的架构,“完美的架构并不存在,更没有可以套用在所有应用情境的架构”,他表示,当开发者不能列举某架构存在的缺陷,也意味着对它不够熟悉。最后一个要素,则是不过早改良架构,“架构必须逐渐演进”,他认为,太早追求一步到位,反而是短视近利。

设计不良的架构,将衍生出后续架构债

而设计架构时,无外乎希望能同时满足三个条件:节省成本、具有扩展性,以及能快速进入市场。然而,一旦没有满足其中的任一条件,都会衍生出后续三种架构债(Architectural△debt)。

第一种架构债常常出现在具备实战经验的技术团队,没有快速进入市场压力下,通常偏好导入最新、最佳化的架构,因此,在此碰上过于架构过于早熟(Premature)的问题。而曾义峰提醒:“我们都不是AWS、Google或是脸书等大公司”,真正重要的问题在于,现阶段组织的营运规模是否适合导入该架构。

再者,当开发团队欠缺架构系统经验时,系统就会发生缺乏延展性(Scalability)的痛点,导致程式码不能重复使用,也很难导入高可用性架构或使用水平扩充,“在还清技术债前,只会债台高筑。”曾义峰表示。

最后一种架构债,则出现于起初推出良好商业模式的团队,在不缺乏资金的情况下,导入品质良好的IT服务,像是使用AWS等基础架构,执行基本的服务。曾义峰表示,只要营运状况良好,并足够支撑这些基础架构的费用并非坏事,“而一旦后续募资没有成功,只好裁员节省成本。”

曾义峰观察,以上3种架构设计时出现的痛点,最常出现的是系统缺乏延展性,其弹性不足以支撑业务成长,即使想要增加硬件、水平扩充时,“系统架构也不允许,导致升级很困难。”

碰上这些挑战,曾义峰表示,导入最小可行性产品(Minimum△viable△product,MVP)的观念也是一种解决方法。此概念就是迅速将产品推上市场,验证产品理念是否有符合市场需求。他比喻,就像最初先推出滑板这个最基本的商品,再陆续让产品功能趋于完整,演进至脚踏车、摩托车甚至汽车,“每阶段的产品都推上市场中试验。”

但是,“如果MVP没有控制好,技术债会迅速成长”,曾义峰表示,由于每阶段产品都面临许多变更,老旧程式不容易清除,导致程式码很难重复利用。外界也有部份人认为,当产品通过市场验证后,再利用投资人的提供资金,作为技术转型所需的支出即可。但他认为,处在迅速成长阶段的新创公司,并没有过多时间进行技术转型,“因为投资人或高层主管都希望尽快将产品推上市场”,不仅如此,除了原型产品离进入正式环境还有一大段距离外,先前快速推出产品也会遗留许多技术债,“只会让转型变得更加困难。”

推动MVP时,必须设定技术债的上限值

因此,在推动MVP时,曾义峰建议,必须设定技术债的上限值,当开发团队发现超过上限值时,得着手清除技术债。不过,“现实往往是债台高筑”,特别当开发团队中没有敏捷教练或架构师,或公司正处产品转型的阶段时,特别容易碰上这样的痛点。

面临庞大技术债的压力,“即使找上大神,他们也觉得头痛”,碰上系统架构重构的挑战,曾义峰提出了3种解决方法。他利用位于空中的飞机,比喻营运不停机的企业,而飞机引擎就是支撑企业营运的系统架构。

“第一种解决方法是空中换引擎”,在企业成长的同时,一并进行技术转型。但曾义峰表示,落实此方法的难度相当高,因为位处高度成长的企业,不仅许新业务需求必须被满足,更有许多先前累积的技术债得清偿。

第二种做法是“落地换引擎”,企业暂时停止开发新功能,全心投入技术转型,虽然此种作法的技术难度低,但曾义峰也提醒,此方法必须衡量该公司商业模式是否适合,“允许新功能推出的步调慢,甚至无进展。”

最后的方式则是“空中小修,地面重建”,现阶段仍然继续投入开发新功能,逐步清偿技术债,等待时机成熟再数位转型。

而曾义峰解释,此决策必须投入许多资源。在落实时,得要将现有团队拆分成不同工作分组,或是另聘团队投入新架构的建置,“但如果没有解决本质的问题,未来新架构也会碰上一样的问题。”

需求永远不明确,因此系统架构得要具有弹性

碰上棘手的技术债,业界也出现了许多解决方法,像是敏捷开发、DevOps、测试驱动开发(Test-Driven△Development),“这些方法都是在解决概念完整性(Conceptual△Integrity)的问题”,曾义峰表示,如果没有解决此问题,导致各方对产品的想法存在落差,后续工作将出现许多疑难杂症。例如,需求方与开发方沟通不顺,需求方并没有提出足够详细的规格书,导致开发者无法实作部分功能,满足该方需求。

肇因沟通不良,导致需求永远不明确的困境。对此,曾义峰表示,沟通应该是双向,除了需求端提出要求外,开发方应该也要化被动为主动,提出回馈。

不仅如此,开发者也得让系统架构更有弹性,当需求改变,导致程式设计有改变时,“预想但是不过早优化,不该把每次的新需求都视作独立需求。”

曾义峰举例,当业主提出开发需求,要求受众在一天内不要看到重复的广告。而这个看似简单易懂的需求,其中就隐含了许多变数的操作空间,像是时间颗粒度,仍可继续向下切分。因此,曾义峰建议,当需求方提出规格时,开发者不该只单线式思考,反之,“要使用抽象化思考的模式,仔细剖析该需求中,存在着哪一些变数。”

不过,即使架构设计的再如何完善,终有一天必须被拋弃。Thoughtworks首席科学家Martin△Fowler就提出了一个牺牲架构(Sacrificial△Architecture)的概念。他表示,许多人认为舍弃既有程式码,便意味着失败,“但现在你能写出最好的程式码,往往几年后也会被舍弃。”

曾义峰也表示,即使必须舍弃现有架构,未必是一件失败的事,重点在于清楚必须放弃的理由,以及新架构该如何执行、何时执行,“清楚明白打掉重练比较好,就勇敢执行吧!”他表示。

tags:

上一篇  下一篇

相关:

裕隆率台湾车业秀MIT技术 电动车、自驾有一套

我酷新闻网记者黄有容/综合报道各国车商无不积极发展电动车、自动驾驶、车联网等领域,台湾车业不让外商专美于前,在8月29日的“台湾汽车科技发展创新高峰会”中,以LuxgenS3EV+车体展示各种台湾自研发技术。台湾本土

Polygram运用AI技术让读者“脸部表情”全都露

我酷新闻网记者/洪雅筠综合报道你曾经疑惑过他人在看自己的社交贴文时,面部表情是开心还是厌恶的吗?虽然Facebook已有各种表情符号可供使用者传递自己对贴文的反应,但现在这款新的照片社交应用程序将通过人工智慧的

福卫5号与地顺利通联 顶尖技术将为台湾带进航太商机

汇流新闻网记者黄有容/综合报道台湾自制卫星“福卫5号”在8月25日凌晨顺利升空、进入任务轨道后,陆续与地面接收站进行了3次通联,也代表福卫5号已经踏出执行任务的第1步。国研院太空中心副主任余政宪更指出,福卫5号

福卫5号与地顺利通联 顶尖技术将为台湾带进航太商机

我酷新闻网记者黄有容/综合报道台湾自制卫星“福卫5号”在8月25日凌晨顺利升空、进入任务轨道后,陆续与地面接收站进行了3次通联,也代表福卫5号已经踏出执行任务的第1步。国研院太空中心副主任余政宪更指出,福卫5号

微软揭露深度学习加速平台专案Brainwave,用FPGA架构加速AI运算效能

图片来源: 微软 微软于本周二(8/22)在Hot△Chips高效能晶片研讨会上,揭露深度学习加速硬件平台专案Brainwave,目的为即时人工智慧(AI)运算,让系统能以超低延迟,在接收到要求指令的同时能够快速处理。同时,Br

站长推荐: