10

有人向我提到，我将成为大型新系统背后的唯一开发人员。除其他事项外，我将设计 UI 和数据库模式。

我相信我会得到一些指导，但我希望能够让他们大吃一惊。在此期间我可以做些什么准备，当我坐在我的电脑前，我需要记住什么？

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

4

10 回答 10

11

你对 OOP 了解很多吗？如果是这样，请查看 Spring 和 Hibernate 以保持您的实现干净和正交。如果你明白了，你应该会发现 TDD 是保持设计紧凑和精简的好方法，特别是因为你已经启动并运行了“自动测试”。

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

于 2008-08-19T04:32:30.200 回答
5

这听起来很像我的第一份工作。大学毕业后，我被要求设计数据库和业务逻辑层，而其他人则负责 UI。与此同时，老板正看着我的肩膀，不愿放开曾经是他的孩子，现在是我的孩子，并用手指戳了进去。三年后，开发人员纷纷逃离公司，而我们距离真正出售任何东西还有 X 个月的时间。

最大的错误是过于雄心勃勃。如果这是你的第一份工作，你会犯错误，而且你需要在写完它们很久之后改变它们的工作方式。我们有各种各样的特性使系统比它需要的更复杂，无论是在数据库级别还是在它呈现给其他开发人员的 API 中。最后，整个事情太复杂了，无法一次支持，就死了。

所以我的建议：

  1. 如果您不确定单枪匹马承担如此大的工作，请不要。告诉你的雇主，让他们为你寻找或雇用可以帮助你的人。如果需要将人员添加到项目中，那么应该在开始时完成，而不是在事情开始出错之后完成。

  2. 仔细考虑产品的用途，并将其归结为您能想到的最简单的一组要求。如果为您提供规范的人不是技术人员，请尝试查看他们所写的内容，了解实际可行并赚钱的内容。与客户和销售人员交谈，了解市场。

  3. 承认自己错了并不可耻。如果事实证明整个系统需要重写，因为您在第一个版本中犯了一些错误，那么最好尽快承认这一点，以便您可以着手处理。相应地，不要试图在你的第一个版本中创建一个可以预测所有可能的意外事件的架构，因为你不知道每个意外事件是什么并且只会弄错。写一次，着眼于扔掉并重新开始——你可能不必这样做，第一个版本可能很好，但如果你这样做了，那就承认吧。

于 2008-08-19T10:34:35.897 回答
3

我也不同意从数据库开始。数据库只是您的业务对象如何持久化的工件。我不知道 Java 中的等价物，但 .Net 具有出色的工具，例如SubSonic，可让您的数据库设计在您迭代业务对象设计时保持流畅。我会说首先（甚至在决定要引入哪些技术之前）关注过程并识别您的名词和动词......然后从这些抽象中构建。嘿，它在“现实世界”中确实有效，就像 OOP 101 教你的那样！

于 2008-08-19T06:08:31.770 回答
2

在你开始编码之前，计划好你的数据库模式——其他的一切都将由此而来。尽早获得合理正确的数据库将节省您的时间和以后的麻烦。

于 2008-08-19T04:31:27.770 回答
2

最重要的是能够抽象出系统的复杂性，这样您就不会在开始时就陷入困境。

  • 首先像阅读故事一样阅读规范（略读）。不要停留在每一个需求上，然后就地分析它。这将允许您在没有太多细节的情况下获得系统的整体情况。此时，您将开始识别系统的主要功能组件。开始放下这些（如果你愿意，可以使用思维导图工具）。

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

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

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

首先执行最后一步的问题是，您可能会陷入系统的复杂性，而没有真正获得全面的了解。

于 2008-08-19T06:03:57.347 回答
1

我反其道而行之。我发现，首先使用数据库模式会使系统陷入难以从持久性中抽象出来的数据驱动设计中。我们尝试先进行域模型设计，然后基于这些设计数据库模式。

然后是基础架构设计：团队应该首先就如何构建程序达成约定。然后我们一起工作，首先就系统通用功能的设计达成一致（例如，每个人都需要的东西，比如持久性、日志记录等）。这成为系统的框架。

在我们将其他功能分开之前，我们首先一起工作。

于 2008-08-19T04:39:11.963 回答
1

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

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

于 2008-08-19T11:21:50.450 回答
1

我建议考虑如何使用这个应用程序。未来的用户将如何使用它？我相信你至少知道一些关于这个应用程序需要处理什么的事情，但我的第一个建议是“想想用户和他或她需要什么”。

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

从真正的核心功能开始。所有这些耗时的绒毛（这将使您的项目延迟 4 周）对大多数用户来说并不重要。一旦您确定可以按时交付，可以稍后添加。

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

于 2008-10-22T15:09:21.450 回答
0

将大系统拆分成更小的部分。并且不要认为它如此复杂，因为它通常不是。考虑得太复杂只会毁掉你的想法，最终毁掉你​​的设计。有些时候你会意识到你可以更容易地做同样的事情，然后你重新设计它。

至少这是我在设计中的主要错误。

把事情简单化！

于 2008-08-19T10:48:18.100 回答
0

我发现了关于开始一个新的大型项目的非常有见地的想法，基于

  • 共同的良好做法
  • 测试驱动开发
  • 务实的态度

在《Growing Object-Oriented Software, Guided by Tests 》一书中。

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

于 2008-08-19T21:31:46.883 回答