架构太过？可能 ，也可能不是
对多对多软件解决计划常见的品评是其架构太过重大 ，在设计、笼统、实现、安排或其他方面造成不须要的重大性、明确难题、维护不易、多余或过失。然而 ，太过架构的指控往往缺乏配景或支持性叙述 ，并可能成为工程师推卸责任的一种利便手段。本文探讨了有问题的架构的三种基本类型：差别的架构、过失的架构和太过架构 ，并对这些类型的特征和示例提供了看法。
对多对多软件解决计划经常听到的品评是 ，它架构太过 ，这意味着设计、笼统、实现、安排或其他方面不须要地重大、难以明确、无法维护、不须要或过失。品评往往是无中生有 ，没有配景或支持性叙述 ；品评往往是长期的。
那么将解决计划标记为太过架构有什么利益呢？
通常 ，这是软件工程师的最终出狱卡 ，在没有客观剖析甚至不相识目今实验情形的情形下 ，将凌驾预期的事情量和时间表的责任推卸给别人。不幸的是 ，高层向导通� ；嵋酝榈摹鞍� ，架构太过 ，我很歉仄”的耸肩来盲目接受诠释 ，当最初的工程师无法填补需求、决议、实验等方面的空缺时 ，这种要领尤其有用。
是的 ，最初实验的架构可能与您首选的架构（手艺客栈、营业假设、笼统等）正交 ，但您是否可以绝不迷糊地说它是太过架构？自最初实验以来 ，贵公司的营业目的或手艺偏向是否爆发了转变？需要思量哪些非功效性需求？提交新闻中有什么有趣的内容吗？
最主要的是 ，您担心的是架构太过照旧爆发了一些不那么危险的事情？嗯 ，我不确定！
软件工程师 软件工程师
若是你更喜欢维护现有代码而不是编写新代码 ，请举手。若是你喜欢维护别人的代码 ，请举手。啊 ，我想是的。
当被分派维护事情时——无论以何种形式——工程师都会寻找允许他们修改、重组、重写并总体上使事情更有趣的角度。若是责任批注太过变换、循环重大度过高或代码确实变得无法维护 ，那么这是一个准确的决议。诚然 ，产品所有者和Scrum 主管不会兴奋 ，但在某种水平上 ，已往的罪孽再也不可被忽视了。
果真称现有代码架构太过 ，你可能会如愿以偿。然而 ，无意有人会要求更深入的诠释 ，这让人嫌疑其缘故原由 ，由于工程师：
不明确目今的实现 ，也不肯意起劲去学习
不相识营业或手艺要求或其他基本假设
差别意使用的设计模式或代码结构
不喜欢代码气焰气焰或名堂 ，甚至不喜欢编程语言自己
并且 ，绝不希奇 ，重写比预想的要大 ，由于具有讥笑意味的是 ，他/她必需最终明确现有的解决计划才华重新实现它：只管你声称自己没有铺平蹊径 ，但不可阻止地你可能需要这样做 ，而这在没有周全明确的情形下是不会显而易见的。您的组织真的准备好接纳API First、微效劳、NoSQL 或简历中添加的其他任何工具了吗？
工期越来越长 ，向导层越来越沮丧 ，其他主要事情被推迟和延期 ，这一切都是由于工程师坚持以为这是须要的。我们都见过这种情形 ，我们中的许多人都是始作俑者 ，并且这通常不是一个优美的故事。
但问题依然保存：它的架构是否真的太过了？
有问题的架构
软件工程学科中应用的架构有多种标签：例如 ，企业、系统、应用程序、软件、云和集成。更令人疑心的是 ，组织经常凭证其内部需求界说架构学科 ，这使得很难明确界说每个学科的职责和界线。这绝对不是一个一刀切的较量。
话虽云云 ，若是您寻常而谈 ，而不是试图在架构学科内界说详细内容 ，那么界说有问题的架构是可能的。我发明有三种基本类型的潜在问题架构。
1. 架构差别
架构差别的解决计划是指对解决计划中非功效性需求的解决方法保存差别看法的解决计划。针对云的解决计划应该是云原生的照旧云无关的？稳固性和可靠性比吞吐量和性能更主要照旧更不主要？支持资源是凭证本钱、功效照旧两者来选择的？
您对底层架构的任何担心或诉苦都必需与非功效性需求相平衡 ，由于非功效性需求关于乐成的解决计划至关主要。您可能差别意非功效性需求 ；因此 ，您的担心或诉苦可能只有在重新确定非功效性需求的优先级时才有意义。无论您的感受怎样 ，只要知足非功效性需求 ，解决计划就是有用的。
纵然您完全赞成非功效性需求 ，差别的工程师也一定会建设差别的解决计划：同步与异步、面向工具的继续与组合、功效性或基于 CRUID 的 API 端点 SQL 与 NoSQL、API First 与 MVC。这是主观的 ，由于每个解决计划实质上都是准确的 ；只是您的要领与我的差别。
“ Hello, World !” 可以用数千种差别的方法实现 ，每种方法都同样准确或过失 ，因此差别的工程师和架构师将以差别的方法处理每个问题。这是错的吗？不是。这是架构太过吗？若是非功效性需求获得明确识别和实验 ，可能不是。但您仍然可能差别意我设计和实验的内容。
2. 架构过失
识别架构不当的解决计划通常需要从构想到安排对有缺陷的实验举行解构：需求界说不明确或不明确、代码质量差、项目执行不力、时间表不切现实以及架构无用。问题（以及责任）通常是多方面的。
抛开这些重大性不谈 ，过失架构的解决计划具有以下配合特征：
纵然已经确定了非功效性需求 ，也不会予以解决。
组织内部不具备乐成实验所需的手艺手艺和配景。
该架构需要在组织焦点竞争力之外构建组件 ，尤其是在保存现有组件的情形下。
安排的解决计划不稳固 ，需要按期关注以阻止中止。
维护和扩展依赖于被以为不可替换的小我私人。
若是您一经加入偏激车失事项目 ，您可能会认出其中之一。您还可能意识到 ，您以为架构过失的现实上是没有架构的。最主要的是 ，这些项目及其爆发的解决计划通常无法拯救 ，与之相关的一切都是铺张时间。
3. 架构太过
是否有任何解决计划是太过架构的？很可能。这个电灯开关是不是有点过头了？关于我们大大都人来说 ，也许云云 ，但这个天下上的鲁布·戈尔伯格 (Rube Golberg)和创客们可不这么以为。
以下履历可能代表了太过架构 ；也可能只是过失架构 ，绝对是差别的架构。
问题陈述
在我担当自力软件照料时代 ，我曾被聘为一位刚去职员工的增补职员。这位前员工为公司构建了第一个真正的 Web 应用程序 ，并设计、实验了一个自界说框架（大部分事情都由他完成）：他/她留下了示例实验和少量（没有？）文档（设计、使用等） ，剩下的员工不得不实验料理残局。
[关于阅读本文的千禧一代 ，请记着 ，早期的 Web 开发没有真正的标准或最佳实践 ，开源还处于起步阶段 ，其时照旧蛮荒的西部 ，每小我私人都在寻找谜底。性能缺乏的用户盘算机难以应付简朴的浏览器端剧本（DOM之前） ，每个浏览器供应商的浏览器都自由地诠释 HTML 标准。那时Internet Explorer最先其恐怖统治（但不知何以至今仍然保存）。与今天完全差别。]
我的使命：拥有框架 ，相识它的神秘 ，并界说开发应用程序的蹊径图。
明确并内化
从 100K 英尺/30.5K 米的高度来看 ，看法上很简朴：效劳器端天生要建设的 HTML ，由处理请求、响应、导航等的 Java Servlet 应用程序（框架）举行编排。在 50K 英尺/15K 米的高度 ，事情就没那么简朴了。在 25K 英尺/7600 米的高度 ，事情就变得很是恐怖了。
我越深入研究 ，担心就越强烈。页面细密耦合 ，看似细小的转变会迅速影响到相邻页面。页面直接天生 HTML ，很难确保整个应用程序的一致性。更改默认框架行为依赖于找到响应的钩子 ，而这些钩子通常数目众多且令人疑心。编排在原始 servlet 引擎（Sun Java Web Server）中有用 ，但若是更改则无效（最先关注Tomcat 的性能）。外地开发需要按期同步其他工程师的代码 ，而其时的版本控制（CVS、Subversion、Visual Source Safe等）使同步变得难题。
我已经遗忘了其他恐怖事务的担心 ，但障碍令人望而生畏 ，乐成的时机渺茫。必需做出艰难的决议。
决议时间
我的结论是：该框架仅适适用途（委屈） ，但不适合开发 ；任何继续的实验都会让剩下的工程师不知所措 ，并且很可能永远无法完成。
值得赞扬的是 ，司理赞成了 ，并决议镌汰损失。长话短说：我们设计了一个更简朴、更专注的框架 ，在三周内 ，工程师们就可以最先在事情模子上开发应用程序 ，并在两个月后乐成演示了我们的希望。最终 ，我们很是乐成 ，并在退役前用于多个应用程序。
讯断效果
以为原始框架架构太过的缘故原由有：
缺少非功效性需求：没有护栏来控制设计和实验
自我驱动设计：实验通过包括除厨房水槽之外的所有工具来展示你有多智慧
过于重大：难以实验、维护和支持
缺乏差别化：架构功效并不是竞争差别化因素 ，并且会大大延伸产品上市时间
您可能会说架构不当 ，或者架构差别 ，但这只是语义问题。无论怎样 ，我们在改变战略之前做了应尽的视察 ，客观地诠释了这一点 ，而不是仅仅说架构太过。
最后的想法
软件解决计划的架构千差万别 ，取决于许多外部因素：营业与软件市肆、手艺职员的履历和手艺、可用手艺、组织成熟度等等。这是意料之中的。
许多时间 ，人们在不相识事情配景的情形下就很快放弃了一项实验。正当理由可能证实部分或所有重新实验是合理的 ，但也可能是为了工程师的私利。作为认真任的软件工程师 ，我们应该证实事情起劲最有利于组织 ，而不是为了软件而软件。这并不料味着除了功效和手艺之外什么都不应被诅咒 ，而是意味着我们应该能够证实所提出的手艺事情是合理的。视察、纪录、叙述、证实。
以上就是架构太过？可能 ，也可能不是的详细内容 ，更多请关注本网内其它相关文章！
