有人向我提到，我将成为大型新系统背后的唯一开发人员。除其他事项外，我还将设计 UI 和数据库架构。
我相信我会得到一些指导，但我希望能够让他们大吃一惊。在此期间我可以做些什么来准备，当我坐在电脑前使用规范时需要记住什么？
需要记住的几点：我是一名大学生，正在从事我的第一份真正的编程工作。我将使用Java。我们已经为 SCM 设置了自动化测试等...所以工具不是问题。
【问题讨论】：
标签： java oop architecture
在您开始编码之前，请计划好您的数据库架构 - 其他一切都将由此产生。尽早获得合理正确的数据库将节省您的时间和以后的麻烦。
【讨论】：
您对 OOP 了解很多吗？如果是这样，请查看 Spring 和 Hibernate 以保持您的实现干净和orthogonal。如果你明白了，你应该会发现 TDD 是保持设计紧凑和精简的好方法，尤其是因为你已经启动并运行了“自动测试”。
更新： 看着第一批的答案，我不能再不同意了。尤其是在 Java 领域，您应该找到大量关于使用 Objects 开发应用程序的导师/资源，不是以数据库为中心的方法。数据库设计通常是微软员工的第一步（我每天都这样做，但我在一个恢复程序中，呃，Alt.Net）。如果您将重点放在需要交付给客户的内容上，并让您的 ORM 弄清楚如何持久化您的对象，那么您的设计应该会更好。
【讨论】：
我反其道而行之。我发现，首先执行数据库模式会使系统陷入难以从持久性中抽象出来的数据驱动设计中。我们尝试先进行域模型设计然后基于这些设计数据库架构。
然后是基础架构设计：团队应该首先确定如何构建程序的约定。然后我们一起工作，首先就系统通用功能的设计达成一致（例如，每个人都需要的东西，比如持久性、日志记录等）。这成为系统的框架。
在我们将其他功能分开之前，我们首先一起工作。
【讨论】：
主要是能够抽象出系统的复杂性，这样您就不会一开始就陷入困境。
首先像阅读故事一样阅读规范（略读）。不要停留在每一个需求上，然后就地分析它。这将允许您在没有太多细节的情况下获得系统的整体情况。此时，您将开始识别系统的主要功能组件。开始放下这些（如果你愿意，可以使用思维导图工具）。
然后取出每个组件并开始分解它（并将每个细节与规范文档中的要求联系起来）。对所有组件执行此操作，直到满足所有要求。
现在，您应该开始查看组件之间的关系，以及各个组件之间是否存在重复的特性或功能（然后您可以将其拉出以创建实用程序组件等）。大约现在，您的脑海中会有一张详细的需求图。
现在，您应该考虑设计数据库、ER 图、类设计、DFD、部署等。
首先执行最后一步的问题是，您可能会陷入系统的复杂性，而没有真正获得全面的了解。
【讨论】：
我也不同意从数据库开始。数据库只是您的业务对象如何持久化的工件。我不知道 Java 中的等价物，但 .Net 具有出色的工具，例如 SubSonic，可让您的数据库设计在您迭代业务对象设计时保持流畅。我会说首先（甚至在决定要引入哪些技术之前）关注过程并识别您的名词和动词......然后从这些抽象中构建。嘿，它在“现实世界”中确实有效，就像 OOP 101 教你的那样！
【讨论】：
这听起来很像我的第一份工作。大学毕业后，我被要求设计数据库和业务逻辑层，而其他人则负责 UI。与此同时，老板正看着我的肩膀，不愿放开曾经是他的孩子，现在是我的孩子，并用手指戳了进去。三年后，开发人员纷纷逃离公司，而我们距离真正出售任何东西还有 X 个月的时间。
最大的错误在于过于雄心勃勃。如果这是您的第一份工作，您 会犯错误，并且您将 需要在写完之后很久才能更改工作方式。我们有各种各样的特性使系统比它需要的更复杂，无论是在数据库级别还是在它呈现给其他开发人员的 API 中。最后，整个事情太复杂了，无法一次支持，就死了。
所以我的建议：
如果您不确定单枪匹马承担如此大的工作，请不要。告诉你的雇主，让他们为你寻找或雇用可以帮助你的人。如果需要将人员添加到项目中，那么应该在开始时完成，而不是在事情开始出错之后。
仔细考虑产品的用途，并将其归结为您能想到的最简单的一组要求。如果给你规范的人不是技术人员，试着看看他们写的东西，看看什么会真正起作用并赚钱。与客户和销售人员交谈，了解市场。
承认自己错了并不可耻。如果事实证明整个系统需要重写，因为您在第一个版本中犯了一些错误，那么最好尽快承认这一点，以便您可以着手处理。相应地，不要试图在你的第一个版本中创建一个可以预测所有可能的意外事件的架构，因为你不知道每个意外事件是什么并且只会弄错。写一次就扔掉然后重新开始——你可能不必这样做，第一个版本可能很好，但如果你这样做了，那就承认吧。
【讨论】：
将大系统拆分成更小的部分。 并且不要认为它如此复杂，因为它通常不是。考虑得太复杂只会毁掉你的想法，最终毁掉你的设计。有些时候你会意识到你可以更轻松地做同样的事情，然后你重新设计它。
至少这是我在设计中的主要错误。
保持简单！
【讨论】：
根据我的经验，最后考虑数据库的 Java 应用程序（也包括 .NET）在放入公司环境时很可能表现不佳。你需要真正考虑你的观众。你没有说它是否是一个网络应用程序。无论哪种方式，在考虑如何处理数据时，您正在实施的基础架构都很重要。
无论您考虑哪种方法，如何获取和保存数据以及它对性能的影响都应该是您的第一要务之一。
【讨论】：
我发现了关于开始一个新的大型项目的非常有见地的想法，基于
在书中Growing Object-Oriented Software, Guided by Tests。
它仍在开发中，但前 3 章可能是您正在寻找的内容，恕我直言，值得一读。
【讨论】：
我建议考虑如何使用此应用程序。未来的用户将如何使用它？我相信你至少知道一些关于这个应用程序需要处理什么的事情，但我的第一个建议是“想想用户和他或她需要什么”。
把它画在白纸上，考虑在哪里分割代码。记住不要将逻辑与 GUI 代码混合（常见错误）。这样，您就可以在未来将您的应用程序范围扩展到 servlet 和/或 applet 或任何出现的平台。分层分段，这样您就可以更快地响应大的变化，而无需重新构建所有内容。除了最近的相邻图层之外，图层不应看到任何其他图层。
从真正的核心功能开始。所有那些耗时的绒毛（这将使您的项目延迟 4 周）对大多数用户来说并不重要。一旦您确定可以按时交付，以后可以添加。
顺便说一句。尽管这与设计无关，但我只想说您不会按时交付。对时间消耗做出一个现实的估计，然后将其加倍 :-) 我在这里假设您在这个项目中不会孤单，人们会随着项目的进展来来去去。您可能需要在项目中途培训人员，人们去度假/需要手术等。
【讨论】：