python 侵蚀_开发产品的侵蚀

python 侵蚀

SDLC或软件开发生命周期是整个应用程序（从需求到发布）的整个开发阶段（任何类型，Web，服务器，移动设备）的不同阶段，并继续进入持续维护阶段。 存在许多SDLC过程，例如瀑布，迭代，螺旋，敏捷，精益，开发操作等方法论。 他们每个人都有自己的优点和缺点。 瀑布方法非常严格，没有考虑到无法预先知道需求的事实。 需求随着对问题的理解的发展而变化，因此不可能在开始开发之前一次性设计所有内容。 迭代过程尝试解决此问题，但是修复成本变得很高。 敏捷倾向于通过设计现在已知的需求并在以后进行适当调整来将其修复到一定程度，但这会导致设计过于分散，如果开发人员不愿重写，就无法轻易修复。需要重写时输入代码。

随着时间的流逝，出现了两个相互冲突的核心问题，这些问题侵蚀了软件流程。 首先是“ 需求变更。 第二个是“ 设计人员和开发人员都是人，总是反对变更，尤其是快速变更。 为什么这些冲突？ 需求驱动设计，设计驱动开发。 如果需求经常变化，则设计也会随之变化。 由于设计人员和开发人员反对频繁的更改，因此他们倾向于做补丁工作以使其适用于这种情况，因此，即使在程序编写之初，我们最终拥有的产品还是很多补丁。

因此，尽管瀑布模型，迭代模型或螺旋模型的校正成本很高，但最初编写的产品补丁工作量较小，并且经过优化，足以至少维持和维持几年的粗暴处理。 但是，采用敏捷方法， 该产品的第一个版本已经是拼凑而成的，从产品发布之日起，该产品的支撑性就受到了质疑！

尽管敏捷对于增强功能和错误修复有好处，但尝试从头开始将其用于产品开发却弊大于利。 在开发新产品时，我们不能一开始就积压待开发的功能。 我们必须先从最初的一组基本功能开始设计，然后围绕这些功能添加其他功能。 敏捷的待办事项列表和2周或固定的短时故事和史诗肯定已解决了“需求变更”。 问题，使人们对第二个更严重的问题“设计人员和开发人员倾向于反对变革”的关注成为焦点。 不能将新产品分解为适合短期开发的故事和史诗！ 这导致我们即使在第一个版本中也开发了腐蚀产品。

纵观我们面临的问题，很显然，我们无法消除“需求变更”的问题。 没关系。 随着理解的变化，需求也随之变化，而理解只有随着时间的流逝而来，我们才能掌握一些具体工作的软件。 这导致我们遇到第二个问题。 那么，我们如何解决潜在的人类倾向反对快速变化的问题呢？

我相信，只有在理解了反对变更的根本原因后，才能找到解决办法。 产品往往具有较大的模块，每个模块的交互设计都很笨拙，它们之间的交互网络很难记住所有的模块及其交互。 存在设计文档，但是随着需求的变化，这些文档往往会过时并且不能被依赖。 因此，尽管随着产品开发的进展，将欢迎并快速完成产品开发阶段开始时的更改，但是即使是很小的更改也会难以分析。 在瀑布模型中，要分组开发更大的块，通过查找更大的块可以很容易地得出影响，敏捷及其简短的故事和不断增加的变化，变化的影响非常大。难以分析和查明变化传播的所有位置。

仅当到目前为止存在准确的现有功能的快照时（通常仅是代码），才能修复此问题。 因此，我们可以使用代码还是当前产品版本来检测变更的影响。 仅在设计无需人工干预或代码生成的情况下直接将其转换为代码时，才可以这样做。 如果我们拥有一个可以将设计用作输入来生成代码的系统，则在部署之前更改最新设计会更改代码，而不会遗漏任何点。

换句话说，我们需要消除在产品开发中输入设计代码所产生的不必要的浪费。 这给我们带来的好处是多方面的。 完全避免了将设计转换为代码的繁琐步骤，从而确保最大限度地减少了对变更的反对。

具有状态跟踪单个产品或项目开发状态的项目经理的要求已完全消除，仅在各个项目之间就需要进行项目管理，并且仅在实施期间需要。 仅需要质量保证来测试代码生成的准确性，一旦完成，测试就可以自动化。 客户的定制可以是基于给定客户的增量设计插入的代码再生。 与“开发这种代码生成器需要花费时间和精力”这一单一缺点相反，这种产品开发方法的优点很多。 这是pocit.online提供的。 在这里尝试。

翻译自: https://www.javacodegeeks.com/2019/02/eroding-product-developed.html

python 侵蚀