有人向我提到我将成为一个大型新系统背后的唯一开发人员。除此之外,我将设计 UI 和数据库模式。

我确信我会得到一些指导,但我希望能够让他们大吃一惊。在此期间我可以做什么准备,当我坐在电脑前阅读规范时需要记住什么?

需要记住以下几点:我是一名大学生,正在从事第一份真正的编程工作。我将使用 Java。我们已经设置了 SCM 和自动化测试等...所以工具不是问题。

有帮助吗?

解决方案

你对OOP了解很多吗?如果是这样,请研究 Spring 和 Hibernate 以保持您的实现干净且 正交. 。如果您明白了这一点,您应该会发现 TDD 是保持设计紧凑和精简的好方法,特别是在您已经启动并运行“自动化测试”之后。

更新:看了第一批答案,我完全不同意。特别是在 Java 领域,您应该找到大量关于使用对象开发应用程序的导师/资源, 不是以数据库为中心的方法. 。数据库设计通常是 Microsoft 人员的第一步(我每天都会这样做,但正在进行恢复计划,呃,Alt.Net)。如果您将重点放在需要交付给客户的内容上,并让 ORM 弄清楚如何持久化您的对象,那么您的设计应该会更好。

其他提示

这听起来很像我的第一份工作。大学刚毕业,我就被要求设计数据库和业务逻辑层,而其他人则负责用户界面。与此同时,老板在我身后看着,不愿放开曾经是他的孩子、现在是我的孩子,并用手指戳了进去。三年后,开发商纷纷逃离公司,而我们距离实际出售任何产品还有 X 个月的时间。

最大的错误在于过于雄心勃勃。如果这是您的第一份工作,您 将要 犯错误而你 将要 在你写完之后很长一段时间都需要改变它们的工作方式。我们拥有的各种功能使系统变得比实际需要的更加复杂,无论是在数据库级别还是在向其他开发人员提供的 API 中。最后,整个事情太复杂了,无法一下子支持,就死了。

所以我的建议是:

  1. 如果你不确定是否要独自承担如此大的工作,那就不要这样做。告诉你的雇主,让他们找到或雇用可以帮助你的人与你一起工作。如果需要将人员添加到项目中,那么应该在项目开始时进行,而不是在事情开始出现问题之后进行。

  2. 仔细思考产品的用途,并将其归结为 最简单的 您能想到的一组要求。如果给你规范的人不是技术人员,请尝试看看他们写的内容是真正有用和赚钱的。与客户和销售人员交谈,了解市场。

  3. 承认自己错了并不可耻。如果事实证明整个系统需要重写,因为你在第一个版本中犯了一些错误,那么最好尽快承认这一点,这样你就可以解决它。相应地,不要尝试在第一个版本中创建一个可以预测每种可能的意外情况的架构,因为您不知道每种意外情况是什么,并且只会出错。写一次就着眼于扔掉并重新开始 - 你可能不必这样做,第一个版本可能很好,但如果你这样做了,就承认这一点。

我也不同意从数据库开始。数据库只是您的业务对象如何持久保存的一个工件。我不知道 Java 中是否有类似的工具,但 .Net 有一些出色的工具,例如 亚音速 使您的数据库设计在您迭代业务对象设计时保持流畅。我想说,首先(甚至在决定引入哪些技术之前)关注流程并确定名词和动词......然后根据这些抽象进行构建。嘿,它确实在“现实世界”中有效,就像 OOP 101 教你的那样!

在开始编码之前,请规划好您的数据库架构 - 其他一切都将从这里开始。尽早使数据库合理正确将为您节省时间并减少以后的麻烦。

最重要的是能够抽象出系统的复杂性,这样你就不会一开始就陷入困境。

  • 首先像读故事一样阅读规范(浏览一下)。不要在每一个需求上都停下来立即分析。这将使您能够了解系统的整体情况,而无需了解太多细节。此时,您将开始识别系统的主要功能组件。开始记下这些(如果您愿意,可以使用思维导图工具)。

  • 然后取出每个组件并开始分解它(并将每个细节与规范文档中的要求联系起来)。对所有组件执行此操作,直到满足所有要求。

  • 现在,您应该开始查看组件之间的关系,以及各个组件之间是否存在重复的特性或功能(然后您可以将其拉出以创建实用程序组件等)。现在,您的脑海中就会有一张关于您的需求的详细地图。

  • 现在,您应该考虑设计数据库、ER 图、类设计、DFD、部署等。

首先执行最后一步的问题是,您可能会陷入系统的复杂性之中,而无法从一开始就真正获得全面的了解。

我则相反。我发现首先执行数据库模式会使系统陷入数据驱动设计,而很难从持久性中抽象出来。我们首先尝试进行领域模型设计 进而 数据库模式基于这些。

然后是基础设施设计:团队应该首先确定如何构建项目的约定。然后我们共同努力,首先就系统通用功能的设计达成一致(例如,每个人都需要的东西,如持久性、日志记录等)。这成为系统的框架。

在我们将其余功能分开之前,我们首先共同解决这个问题。

根据我的经验,最后考虑数据库的 Java 应用程序(也包括 .NET)在放入企业环境时很可能表现不佳。你需要真正考虑你的观众。您没有说它是否是网络应用程序。无论哪种方式,在考虑如何处理数据时,您所实施的基础设施都很重要。

无论您考虑哪种方法,如何获取和保存数据及其对性能的影响都应该是您的第一要务之一。

我建议考虑如何使用这个应用程序。未来的用户将如何使用它?我确信您至少知道该应用程序需要处理的一些事情,但我的第一个建议是“考虑用户以及他或她的需求”。

把它画在普通纸上,思考在哪里划分代码。请记住不要将逻辑与 GUI 代码混合在一起(常见错误)。这样,您将来就可以将应用程序的范围扩展到 servlet 和/或 applet 或任何出现的平台。分层分区,以便您可以更快地响应大型更改,而无需重建所有内容。除了最接近的相邻层之外,层不应看到任何其他层。

从真正的核心功能开始。所有那些耗时的琐事(这会让你的项目延迟 4 周)对于大多数用户来说并不重要。一旦您确定可以按时交货,就可以稍后添加。

顺便提一句。尽管这与设计无关,但我只想说你不会按时交付。对时间消耗进行现实的估计,然后加倍:-)我在这里假设您不会孤单地参与这个项目,并且随着项目的进展,人们会来来去去。您可能需要在项目中途培训人员,人们去度假/需要手术等。

将大系统分割成更小的部分。不要认为它如此复杂,因为通常情况并非如此。如果想得太复杂,它只会毁掉你的想法,最终毁掉设计。在某些时候,你只是意识到你可以更容易地完成同样的事情,然后你重新设计它。

至少这是我在设计上犯的一个重大错误。

把事情简单化!

我发现了关于启动一个新的大型项目的非常有见地的想法,基于

  • 常见的良好做法
  • 测试驱动开发
  • 和务实的态度

在书里 以测试为指导不断发展面向对象的软件.

它仍在开发中,但前 3 章可能是您正在寻找的内容,恕我直言,值得一读。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top