一家不懂技术的公司的顾问！

Question

我得到了一份顾问的工作，在一家有另外三个程序员的公司。我的工作是用Java、Spring等重写所有旧系统，但是工作人员程序员只知道perl，而管理人员不懂任何编程。

我试图让他们明白，我这里有6个项目要重写，但没有人有设计文档或规范。职员程序员从来不需要写任何文件。另外，我不能让经理理解新的java技术。他不断地询问一些员工对事情的看法，但员工们不知道也不理解。

从这里我应该去哪里让经理明白职员、程序员或其他人必须写一份设计文档，这样我就知道要构建什么了。或者，如果我必须写文件，我如何获得信息？

Answer 1

似乎有点奇怪的是，员工不知道你被要求重写他们的工作平台。你离开后会发生什么？谁会支持你的工作？

因此，您有一个复杂的系统，没有适当的文档，您必须在一个不同的平台上重新创建系统。在你的职位上，我要做的是确定必须在新系统上“签字”的单身人士。在那里，阅读一些用户故事，以确定如何将需求分解成可以用简单英语描述的比特大小的块。它们的格式类似于“作为USERROLE，在SYSTEM中，我希望完成行动，从而实现目标。

为了进一步解释用户故事，您可以在“给定条件然后结果”的格式中添加“成功标准”，以解释父用户故事中不同操作发生的情况。这是一种很好的方法，可以将功能分解成可以单独理解的部分，并且可以帮助您从不同的组编写不同的故事(只需确保在工作上签字的高层人员保持不变)。

因此，将系统的所有旧功能重写为用户故事，然后询问项目所有者在Java版本中是否需要任何新功能。添加故事来满足这一点，如果有的话，然后开始编码。

基本上，你需要能够揭露职员程序员的无能。让项目所有者要求他们为你提供一些故事的成功标准，这样如果他们给你糟糕的输入，你就可以把它作为你的官方要求。他们漏掉的任何东西都是他们的错，不是你的错。

Answer 2

我参与了一个项目，其中整个系统都是用Oracle表单编写的，但没有任何文档。这种技术本来可以很容易地采用Perl。下面是将系统迁移到Oracle ADF的攻击计划(但也可以很容易地成为任何其他平台)：

1. 为业务需求创建一组代码类别(功能、bug、验证、ui等)。
2. 为屏幕创建一组类别(根据类似的功能对它们进行分组)。
3. 为整个应用程序创建一个所有屏幕的列表，并在电子表格中枚举它们。
4. 为每个屏幕分配一个代码类别和一个代码类型(例如，业务规则、系统需求、技术)。
5. 反向工程代码以提取业务需求，对每个需求进行一句描述。

此时，您将已经记录了应用程序的业务规则。对于任何下一个必须维护这个系统的人来说，这本身就是黄金。此外，它还将给您一个机会来查看系统的哪些部分被复制。(在我的例子中，我们发现超过60%的代码库是重复的。)

从这里开始，您可以通过管理层对业务需求进行排序。例如，这可能需要制作用户故事。这也将揭示高层次的重复功能，并提供在迁移过程中简化和增强系统的机会。我已经包括了电子表格的屏幕截图，以展示跟踪和记录需求的一种方法。

您可能需要对您的Perl进行仔细研究。;-)

一旦您对项目进行了反向设计，您就可以使用一套工具来帮助您完成软件开发生命周期。(我们正在使用JIRA，但还有许多其他软件套件可以工作。)您可能有一些斗争要做，但一旦您有了需求，您将希望转移到以下环境：

• 创建文档环境(例如，wiki)。
• 创建一个开发(DEV)环境。Web服务器、数据库服务器、源存储库等。
• 创建一个反映开发的测试(测试)环境。
• 创建一个准确反映生产的预生产(PREPROD)环境，并且可以充当生产系统的故障转移。
• 创建一个生产(PROD)环境。

考虑使用面向社区的服务来满足最终用户文档的需求。一个与StackExchange套件类似的优秀软件包是OSQA。让用户构建帮助系统(这是一个非常聪明的策略)。

SDLC变成：

1. 开发人员在DEV中进行并测试应用程序更改(使用存储库)。
2. 系统工具自动将定期构建部署到测试中。
3. 一旦测试人员对应用程序感到满意，应用程序就会部署到PREPROD中。这也允许对部署过程进行测试。更多的测试发生在PREPROD中。
4. 一旦测试人员对PREPROD感到满意，应用程序就会最终进入PROD。

我发现这是一种高度组织化的方法，适用于不同的开发方法。第一次通过，我在这里已经描述过，应该被认为是一个“广泛的一笔”--你不想在这一点上对技术细节过于详细(陷入困境)。(例如，用户界面要求由每个屏幕捕获。只要您枚举了屏幕，就不必迭代每个输入字段--只需链接到屏幕快照或工作URL。)

最后，为了查看源代码，我们自动生成了一系列网页(每个功能的“屏幕”有一个网页)。这很好，因为PL/SQL代码可以分割成不同的文件，并自动转换为具有语法突出显示的HTML。使用Perl，这可能不适用于您。但是，您可以在电子表格中创建锚链接，这些链接指向强制执行业务需求的代码部分。(顺便说一下，这还允许多个开发人员并行地逆向设计系统需求，因为每个开发人员都可以同时处理不同的屏幕。)

一个示例源代码片段(+是一个锚链接)：

您可以建议雇用几位Perl专家来帮助完成分析任务。

我认为指出其他人正在做“糟糕的工作”并不是很有效率；相反，你应该寻求改进产品，并给人们一个机会来帮助实现这个目标(也许还应该学习如何在这个过程中提高他们的技能)。也就是说，您不知道其他开发人员知道什么，在他们开发系统时您也不知道。这一做法使整个过程开放，并使每个人都能作出贡献。

老实说，经理们会亲眼看到谁是真正的乐于助人，谁想提高。

Answer 3

他们没有文档，而且他们的代码太差了，以至于雇了其他人用另一种语言重写它。开始从源收集需求。您将发现许多特性和功能不再使用或可能无法正常工作。同样重要的是要知道什么是不应该建立的。

一旦您发现用户需要什么，就可以确定当前应用程序中已经包含了哪些内容，以及必须从头构建哪些内容。在现有的部分中，您可以查看代码并与devs对话。

任何宣称自己需要一切的人都不会费心去检查。从不重写应用程序是有争议的，但这假设一切都以用户希望的方式工作，而这并不总是正确的。他们使用它是因为没有其他选择。给他们一个更好的选择。