3

我的问题不是技术性的。这更像是一种哲学,实际上取决于个人喜好。我正在设计和开发一个应用程序(Web + 桌面),这发生在我身上,想知道你们(程序员和设计师)是否曾经遇到过这个问题:

一些设计者相信应用程序可以运行 3 到 5 年,并且对它们的任何更改都会反映在它们上,而无需求助于系统核心更改。作为一名程序员,我知道事实并非如此。小的外观变化确实会发生,但通常在一两年后它们就会消失,随着时间的推移,会出现需要核心更改的更改,最终您将创建一个新的应用程序。

鉴于技术的快速变化,设计一个应用程序 5 年下来是相当荒谬的,恕我直言。好吧,我的意思不是设计,而是这个应用程序将运行 5 年的想法以及我们不需要创建新应用程序的信念,我认为这是生活在傻瓜的天堂。我的意思是,程序员同胞们,大多数具有运行流程的关键任务或基本小型应用程序通常在几年后重新制作/重新构建/重新组织/重新编码。

所以我的问题是,为什么要保持这种态度,让这个完美的应用程序可以运行十年。这真的很愚蠢,因为您知道技术每年都会发生变化。新框架、新方法、新技术将会出现,您的客户会想要它们。所以,如果你原谅我使用这句话,WTF 是重点?

我一直告诉我的设计师,无论如何,该应用程序将在几年内重新设计,试图让它从它的@ss 拍摄照明是没有意义的,因为它永远不会。没有完美的应用程序。

我希望你们能明白我的意思。小伙伴们是不是也有同感。顺便说一句,我从事软件编程业务已有大约 7 年了。如果你真的想一想,你真的认为 Facebook 会在未来 5 年保持不变吗?可以肯定的是,设计每年都会改变,以保持“时髦”,但核心每隔几年就会改变一次。我对此深信不疑。我是偏执狂还是什么?请告诉我有其他程序员跟我一样。任何人?

4

9 回答 9

9

我的方法是为改变而设计。这意味着我可以编写最可维护的代码,保持松散耦合和模块化,尝试以尽可能标准的方式做事,以便其他开发人员可以快速掌握代码,等等。

我通常会在数据库设计的未来验证上投入更多的精力,因为在许多情况下,更改可能比更改代码困难得多。

于 2010-08-09T15:00:58.547 回答
5

我曾在两家不同的公司工作过,它们的软件产品已接近 10 年以上。尽管它们已经扩展了许多新功能并进行了许多改头换面,但自第一个稳定版本以来,应用程序的核心基本上没有受到影响。这可能不是典型的,但如果架构师足够熟练,系统可以构建为模块化和可扩展的,足以适应惊人的增长量。

于 2010-08-09T15:09:22.837 回答
4

就个人而言,我永远不会着手设计任何类型的应用程序,假设它会在几年内被替换。通常,那些“更新”和“重写”会被推迟,以实现不想等待全新应用程序的客户所需的快速修复。当然,需求会发生变化,需要功能,但在当前迭代中通常会需要它们。

我的意思是,有很多应用程序、语言和设计模式都有相同的想法,并且今天仍在使用。一个突然出现在我脑海中的是 y2k 错误。70 年代的程序员从没想过他们的代码会持续 30 年,而且肯定有人会在世纪之交之前将这些年份的值扩展到 4 个数字。我们都记得这种想法是如何产生的……

于 2010-08-09T15:05:06.153 回答
4

“伟大计划的最大障碍,是对完美计划的梦想。”

我同意——设计一个可以优雅地适应未来所有可能变化的完美系统是徒劳的。每一个成功的项目都是一种权衡:在您确信需要它的地方(或者在容易做到的地方)建立灵活性;并在您认为不太可能发生灵活性/更改的地方构建一些快速的脏代码。如果您很好地分析了系统并且客户对他们的需求/要求有一个很好的了解(并不总是给定的),那么您至少在大多数情况下都会获得正确的平衡。

然而,整个系统每 3-5 年就会被一些更新的技术取代的想法也是一个谬误。对于每个想要最新、最新、最性感系统的客户,有 5 个客户害怕放弃(或无法负担更换)他们的旧 COM/VB/MS-Access/任何一个意大利面条逻辑泥潭的系统随意构建,而不考虑可维护性、灵活性或可扩展性。您不想成为构建该系统的人;如果你是,那么你就是在伤害你的客户/雇主。

于 2010-08-09T17:38:20.537 回答
3

我相信,如果系统的核心是建立在多年来没有太大变化的原则上,那么系统从根本上不会有太大变化,大多数变化主要是审美上的。

一些久经考验的原则至今仍然很强大,例如数据库规范化、代码模块化等。

所以这取决于你定义的核心。对我来说,核心意味着系统的设计,如果做得好,将来可能根本不会发生太大变化。

于 2010-08-09T15:03:23.270 回答
3

这真的取决于环境。我发现我们的内部企业应用程序在发布后的 18 个月内进行了全面检修(通常已停用)。这不是任何人的错——业务优先级改变、需求改变、新系统上线。同时其他系统运行很长时间。

我们当然不会开发任何应用程序,期望它很快就会退役,但有业务需求需要立即解决,有时最好让应用程序尽快上线并交付最终用户手中。我们更新、迭代并确定下一个最佳步骤。

于 2010-08-09T15:11:23.210 回答
3

数据和数据结构(通常)需要经过合理设计才能持续数十年。算法、用户界面和其他一切都有望迅速发展。

如果您的数据代表法律文件、财务记录,您可能需要保留数十年。

尽管这也可以走极端。有些数据子集在 50 年内可能没人会关心,比如可能存储在数据库中的内存性能计数器。

于 2010-08-09T15:21:04.083 回答
3

我记得我相信 James Kovac 的一句话,在 .Net Rocks 的播客之一中,他将我们的行业描述为:

唯一不变的就是变化

这就是为什么您应该设计灵活性,以便在发生变化时,并且在大多数情况下不可避免地*您将更容易适应/更新您的应用程序。这并不是说您不应该尝试在坚实的基础上构建您的应用程序,而是拥有一个可以轻松更改的灵活解决方案比第一次完美解决方案更重要。

*我知道在许多银行中,人们仍在使用古老的应用程序,因为更改它们的风险太大,而且他们根本没有专业知识来更改它们。

于 2010-08-09T15:25:21.667 回答
2

好吧,我认为理想的设计是完全正交的,但你只需要接受它很少能按照你想象的方式工作。如果您从未阅读过 The Pragmatic Programmer,那么它会谈到很多关于未来验证您的代码的内容。

于 2010-08-09T15:04:05.640 回答