Questions tagged «changes»

我已经在一家大公司（拥有8000多名员工）工作了将近2年，而在我完成学习课程后才被录用。 这里的每个人都必须每天处理遗留代码，这些遗留代码通常设计得很糟糕并且充满了骇客。首先，我保持低调，尽量不要批评太多。但是，从目前的情况来看，这种情况已经变得很难适应，而且似乎没有人愿意改进/替换我们使用的工具。 更明确地说，我们有： 过时的源代码控制工具（Visual SourceSafe） 普通的旧makefile，仅支持完全重建 .def 所有现有体系结构必须手动维护的文件 整体头文件和包含很少文件的项目（但每个头文件都有大约3000行代码，有时需要处理非常不同的任务） 不使用“新”语言工具（std::string不是新语言，但除我以外没有人使用它） 几个月前，我决定通过设计一个新的编译环境来对此做一些事情。我可以使增量构建可靠地工作，更快的编译时间，更好的结构化项目，自动.def文件生成。我什至还创建了一个从Git到Visual SourceSafe的桥梁。 我向几位同事和我们的老板展示了我的成就，但没人关心。他们都像“嗯...人们现在已经习惯那样做了。我们为什么要改变事情？” 我建议的更改是为了使我们能够从旧系统到新系统的一个软过渡而设计的。每个改进都可以单独安全地应用。 我什至试图让我的一些同事参与到变更中。但是到目前为止，还没有成功。 您是否已经遇到过类似情况？如果“以身作则”无效，该怎么办？

40 architecture  productivity  changes 

我的一个朋友正在一家小公司工作，每个开发人员都讨厌这个项目：他被迫尽快发布，他是唯一一个关心技术债务，客户没有技术背景的人。 他给我讲了一个故事，使我想到了这样的项目中设计模式的适当性。这是故事。 我们不得不在网站的不同位置展示产品。例如，内容管理者可以通过API查看产品，还可以查看最终用户或合作伙伴。 有时，产品中缺少信息：例如，刚创建产品时，其中一堆没有任何价格，但尚未指定价格。有些没有描述（描述是具有修改历史，本地化内容等的复杂对象）。一些缺乏货运信息。 受到最近关于设计模式的阅读的启发，我认为这是使用神奇的Null Object模式的绝佳机会。所以我做到了，一切都变得顺畅而干净。只需致电product.Price.ToString("c")显示价格或product.Description.Current显示说明即可；不需要有条件的东西。直到一天，涉众要求通过使用nullJSON 来以不同的方式在API中显示它。对于内容管理者，也显示“未指定价格[更改]”，这也有所不同。而且我不得不谋杀我心爱的Null Object模式，因为不再需要它了。 同样，我不得不删除一些抽象工厂和一些建筑商，最终我通过直接和丑陋的调用替换了我美丽的Facade模式，因为底层接口在三个月中每天两次更改，甚至Singleton也离开了我当需求告知相关对象必须根据上下文而不同时。 超过三周的工作包括添加设计模式，然后在一个月后将其撕裂，我的代码最终变得面目全非，甚至包括我自己在内的任何人都无法维护。最好首先不要使用这些模式，这会更好吗？ 确实，我必须在那些要求不断变化的项目类型上工作，而这些项目实际上是由那些并不真正考虑产品的凝聚力或一致性的人所决定的。在这种情况下，无论您有多敏捷，都将为问题提供一个优雅的解决方案，当最终实现该问题时，您会发现需求发生了巨大变化，以致于您的优雅解决方案不适合不再。 在这种情况下，解决方案是什么？ 是否不使用任何设计模式，停止思考并直接编写代码？ 进行一次团队直接编写代码，而另一个团队在打字之前三思而后行的经历会很有趣，这冒着几天后不得不扔掉原始设计的风险：谁知道，也许两个团队都会拥有同样的技术债务。如果没有这样的数据，我只断言，它不觉得不对劲，恕不另行思维上有20人月的项目工作时输入代码。 保留不再有意义的设计模式，并尝试为新创建的情况添加更多模式？ 这似乎也不正确。模式用于简化对代码的理解；放置过多的模式，代码将变得一团糟。 开始考虑包含新要求的新设计，然后慢慢将旧设计重构为新设计？ 作为一名理论家和偏爱敏捷的人，我完全投入其中。在实践中，当您知道必须每周回到白板并重做以前的设计的大部分内容时，并且客户只是没有足够的资金来支付您的费用，也没有足够的时间等待，这可能行不通。 那么，有什么建议吗？

32 design-patterns  agile  changes 

在SE和其他网站上阅读所有这些“敏捷开发”内容时，我总是想知道一件事： 在“传统”软件工程中，您 收集用户的需求， 根据这些要求编写规范， 把它交给客户，并向他收取到目前为止已完成的工作的费用， 做一个（粗略的）技术设计，以便您可以估算实施成本， 为用户提供实施的价格报价， 等待客户签署规格书并接受报价， 设计，实施，测试， 法案。 如果在此过程中需求发生变更，则您发送所需变更的报价（有价格）（如果变更很小，则免费提供，您喜欢客户，而客户却不经常这样做） 。 那么，这在敏捷项目中是如何工作的（财务上），而频繁的需求变更是流程的一部分？ 您是否为每次设计变更都写报价？（这不是很乱吗？） 还是您协商固定价格并希望客户不要经常更改要求？（可能会有风险，我知道客户会在接受该项目完成之前利用这个机会请求多年的新功能。） 还是只向客户收取所需的总时间费用？（对于事先不知道成本的客户可能会有风险。）

13 agile  business  financial  changes 

这是一个相当模糊的问题，但这是我在阅读有关适当设计的内容时从未感到满意的答案。 通常，在学习面向对象的编程，抽象，分解等方法时，设计的圣杯以及它们始终声称您使用的是开发技术的原因是，这将使您的程序“易于更改” ，“可维护的”，“灵活的”或用于表达这种有效果的概念的任何同义词。通过将ivars标记为私有，将代码拆分为许多小的自包含方法，使接口保持通用，可以使您完全轻松自如地修改程序。 对于较小的更改，这对我来说效果很好。改变类以提高性能所用的内部数据结构从来都不是主要困难，而且独立于API的用户界面端也没有改变，例如重新设计文本输入系统或检修游戏元素的图形。 所有这些更改似乎天生就是独立的。就所涉及的外部代码而言，它们均不涉及对要修改的程序组件的行为或设计进行任何更改。无论您是以程序编写还是以OO样式编写（具有大型功能还是小型功能），即使您只有中等程度的设计，也可以轻松进行这些更改。 但是，每当更改变得繁琐而繁琐时（即，对API进行更改），我的所有宝贵“模式”都无法挽救。巨大的变化仍然很大，受影响的代码仍然受到影响，并且大量的错误产生工作摆在我面前。 所以，我的问题是这个。适当的设计声称能够促进多大的变化？是否有一些其他的设计技术，或者对我来说是未知的，或者是我没有实现，确实确实使粘滞性修改变得简单，还是那个承诺（我听说过这么多不同的范例）仅仅是一个好主意，完全脱离了软件开发的一成不变的真理？我可以添加到工具栏中的“更改工具”吗？ 具体来说，导致我进入论坛的问题是：我一直在努力实现一种解释性编程语言（在D中实现，但这无关紧要），并且我决定将闭包的参数设为基于关键字，而不是当前的位置。这就需要修改所有现有的调用匿名函数的代码，幸运的是，这很小，因为我很早就开发了我的语言（<2000行），但是如果我稍后再做出决定，那将是巨大的。在这种情况下，是否可以通过适当的预见性设计使修改变得更容易，或者确定（大多数）变化本质上影响深远？我很好奇这是否是我自己的设计技能的失败-如果是的话，我 明确地说，我绝不怀疑OOP或其他常用的模式。但是，对我而言，它们的优点在于代码库的原始编写而不是维护。继承使您可以很好地抽象出重复的模式，多态性使您可以通过人类理解的函数（哪个类）而不是由机器理解的效果（switch语句的哪个分支）来分离代码，而小的独立函数可以让您以一种非常愉快的“自下而上”的风格写作。但是，我对他们的灵活性表示怀疑。

11 design  object-oriented  maintenance  abstraction  changes 

完成项目后，可能需要进行大量调整和更改才能使其正常工作... 我该怎么做才能避免这种情况？

9 project  changes