原标题：3种CTO要小心的架构技术债
图片来源: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）的概念。他表示，许多人认为舍弃既有程式码，便意味着失败，“但现在你能写出最好的程式码，往往几年后也会被舍弃。”
曾义峰也表示，即使必须舍弃现有架构，未必是一件失败的事，重点在于清楚必须放弃的理由，以及新架构该如何执行、何时执行，“清楚明白打掉重练比较好，就勇敢执行吧！”他表示。
相关：
我酷新闻网记者黄有容/综合报道各国车商无不积极发展电动车、自动驾驶、车联网等领域，台湾车业不让外商专美于前，在8月29日的“台湾汽车科技发展创新高峰会”中，以LuxgenS3EV+车体展示各种台湾自研发技术。台湾本土
我酷新闻网记者/洪雅筠综合报道你曾经疑惑过他人在看自己的社交贴文时，面部表情是开心还是厌恶的吗？虽然Facebook已有各种表情符号可供使用者传递自己对贴文的反应，但现在这款新的照片社交应用程序将通过人工智慧的
汇流新闻网记者黄有容/综合报道台湾自制卫星“福卫5号”在8月25日凌晨顺利升空、进入任务轨道后，陆续与地面接收站进行了3次通联，也代表福卫5号已经踏出执行任务的第1步。国研院太空中心副主任余政宪更指出，福卫5号
我酷新闻网记者黄有容/综合报道台湾自制卫星“福卫5号”在8月25日凌晨顺利升空、进入任务轨道后，陆续与地面接收站进行了3次通联，也代表福卫5号已经踏出执行任务的第1步。国研院太空中心副主任余政宪更指出，福卫5号
微软揭露深度学习加速平台专案Brainwave，用FPGA架构加速AI运算效能
图片来源: 微软 微软于本周二（8/22）在Hot△Chips高效能晶片研讨会上，揭露深度学习加速硬件平台专案Brainwave，目的为即时人工智慧（AI）运算，让系统能以超低延迟，在接收到要求指令的同时能够快速处理。同时，Br