我曾经提到过，我将成为大型新系统背后的唯一开发人员。除其他事项外，我将设计一个UI和数据库架构。

我确定我会得到一些指导，但是我希望能够把他们的袜子踢掉。在此期间，我可以做些什么准备工作？当坐下来使用规范时，我需要记住什么？

请记住以下几点：我是第一份真正的编程工作的大学生。我将使用Java。我们已经通过自动化测试等设置了SCM，因此工具不是问题。

解决方案

回答

在开始编码之前，请计划数据库架构，所有其他一切都会从中产生。尽早使数据库合理地正确将为我们节省时间和以后的麻烦。

回答

我们对OOP了解很多吗？如果是这样，请查看Spring和Hibernate以保持实现整洁和正交。如果我们了解到这一点，那么应该发现TDD是保持设计紧凑和精简的好方法，尤其是因为我们已经启动并运行了"自动测试"。

更新：
看着第一批答案，我完全同意。尤其是在Java领域，我们应该找到大量关于使用Objects而不是以数据库为中心的方法来编写应用程序的指导者/资源。数据库设计通常是Microsoft员工的第一步(我每天都在做，但是在恢复程序中，例如Alt.Net)。如果我们专注于交付给客户的需求，并让ORM找出如何持久化对象，那么设计应该会更好。

回答

我反过来做。我发现首先进行数据库架构设计会使系统陷入数据驱动的设计中，而这种设计很难从持久性中抽象出来。我们尝试先进行领域模型设计，然后再基于这些模型进行数据库架构设计。

然后是基础架构设计：团队应该就如何最重要地构建程序达成约定。然后，我们共同努力，首先就系统通用功能(例如，每个人都需要的诸如持久性，日志记录等)的设计达成一致。这成为系统的框架。

在将其余功能分开之前，我们所有人首先要共同努力。

回答

最主要的是能够抽象出系统的复杂性，这样一来，我们就不会陷入僵局。

• 首先阅读该规范，就像一个故事(浏览整个过程)。不要停止所有要求，然后立即进行分析。这将使我们获得整个系统的概况，而没有太多细节。此时，我们将开始确定系统的主要功能组件。开始放下它们(如果愿意，请使用思维导图工具)。
• 然后取出每个组件并开始分解(并将每个细节与规范文档中的要求联系在一起)。对所有组件执行此操作，直到满足所有要求为止。
• 现在，我们应该开始查看组件之间的关系，以及各个组件之间是否存在重复的特征或者功能(然后可以拉出它们来创建实用程序组件，等等)。大约现在，我们将在脑海中清楚了解自己的需求。
• 现在，我们应该考虑设计数据库，ER图，类设计，DFD，部署等。

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

回答

我也不同意从数据库开始。数据库只是有关如何持久化业务对象的构件。我不知道Java中的等效语言，但是.Net具有诸如SubSonic之类的出色工具，可以使数据库设计在我们遍历业务对象设计时保持流畅。我首先要说的是(甚至在决定采用哪种技术之前)要着重于过程并识别名词和动词……然后从这些抽象中构建出来。嘿，就像OOP 101教那样，它确实可以在"现实世界"中工作！

回答

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

最大的错误是过于野心勃勃。如果这是第一份工作，那么我们将犯下错误，并且在编写了很长时间后就需要更改工作方式。在数据库级别和提供给其他开发人员的API中，我们具有各种各样的功能，这些功能使系统变得比原来的复杂。最后，整个过程太复杂了，无法一次全部支持，甚至死了。

所以我的建议：

• 如果我们不确定要单手承担这么大的工作，请不要。告诉雇主，让他们找到或者雇用可以与我们合作的人，他们可以为我们提供帮助。如果需要将人员添加到项目中，则应在开始时进行操作，而不是在出现问题后再进行操作。
• 非常仔细地考虑产品的用途，并将其归结为我们可以想到的最简单的一组要求。如果为我们提供规格的人员不是技术人员，请尝试回顾他们所写的内容，直到它们真正起作用并赚钱。与客户和销售人员交谈，了解市场。
• 承认自己错是没有耻辱的。如果事实证明整个系统需要重写，因为我们在第一个版本中犯了一些错误，那么最好尽快确认这一点，以便我们可以使用它。相应地，不要尝试在第一个版本中构建可以预见所有可能意外情况的体系结构，因为我们不知道每种意外情况是什么，只会弄错它。只写一次就扔掉然后重新开始-我们可能没有必要，第一个版本可能没问题，但如果我们愿意，可以接受。

回答

将大系统拆分为较小的部分。
而且不要以为它是如此复杂，因为通常情况并非如此。过于复杂的思维只会破坏想法，最终破坏设计。有些时候，我们只是意识到可以轻松完成同一件事，然后重新设计它。

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

把事情简单化！

回答

根据我的经验，最后考虑数据库的Java应用程序(也包括.NET)在置于公司环境中时极有可能表现不佳。我们需要真正考虑听众。我们没有说它是否是一个网络应用程序。考虑到如何处理数据时，无论哪种方式，我们正在实现的基础架构都是很重要的。

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

回答

我发现了有关启动新的大型项目的非常有见地的想法，

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

在《由测试指导的成长中的面向对象软件》一书中。

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

回答

我建议考虑如何使用此应用程序。未来的用户将如何使用它？我确定我们至少了解一些有关此应用程序需要处理的内容，但是我的第一个建议是"考虑用户以及他或者她的需求"。

将其画在普通纸上，考虑在哪里分割代码。请不要将逻辑与GUI代码混合使用(常见错误)。这样一来，我们就可以将应用程序扩展到将来的servlet和/或者applet或者任何附带的平台。分层进行划分，以便我们可以更快地响应大型更改而无需重建所有内容。除最接近的相邻层外，其他层不应看到其他任何层。

从真正的核心功能开始。所有那些费时的工作(这会使项目迟到4周)，对于大多数用户来说并没有多大关系。一旦确定我们可以按时交付，便可以在以后添加。

顺便提一句。即使这与设计无关，我也想说我们不会准时交付。对时间消耗进行现实的估算，然后将其加倍：-)我在这里假设我们不会孤单在这个项目中，随着项目的进行，人们会来去去去。我们可能需要在项目进行中培训人员，人们去度假/需要手术等。