项目已接近完成，但过程意大利面代码。我是重写还是一直试着把它运出去？

Question

我是一个初学者的网页开发(一年的经验)。

毕业几周后，我得到了一份工作，为一家所有者不太懂技术的公司制作一个网络应用程序。他聘用我是为了避免剽窃他的想法，避免一家服务公司收取高昂的开发成本，并让一个他可以信任的年轻人长期维持这个项目(我在被录用很久后就得出了这些结论)。

尽管当时我很自大，拥有计算机科学的文凭，但我接受了这份工作，认为我可以做任何事。

是我说了算。经过一些研究，我确定了PHP，并从简单的PHP开始，没有对象，只是丑陋的过程代码。两个月后，一切都变得一团糟，很难取得任何进展。网络应用程序是巨大的。因此，我决定检查一个MVC框架，这将使我的生活更容易。在PHP社区里，我偶然发现了一个很酷的孩子: Laravel。我喜欢它，它很容易学习，我马上就开始编码了。我的代码看起来更干净，更有条理。看上去很不错。

但同样，网络应用程序也是巨大的。该公司向我施压，要求我提供第一个版本，很明显，他们想要部署这个版本，并开始寻找客户。

因为和Laravel一起工作很有趣，这让我想起了我当初为什么选择这个行业--当我陷入糟糕的教育体系时，我忘记了这一点。

因此，我开始在夜间从事小型项目，阅读有关方法学和最佳实践的文章。我重温了面向对象的设计和分析，并阅读了鲍勃叔叔书清洁代码.

这让我意识到我真的什么都不知道。我不知道如何以正确的方式构建软件。但是现在已经太晚了，现在我快完成了。我的代码一点也不干净，只是意大利面代码，修复一个bug真的很痛苦，所有的逻辑都在控制器中，很少有面向对象的设计。

我一直认为我必须重写整个项目。但是我做不到..。他们不停地问什么时候一切都会完成。

我无法想象部署在服务器上的代码。另外，我对代码效率和web应用程序的性能仍然一无所知。

一方面，公司在等待产品，不能再等待了。另一方面，我看不出自己对实际代码有更深入的了解。我可以完成、打包和部署，但是只有当人们开始使用它时，天知道会发生什么。

我是重写，还是继续尝试，还是我错过了另一种选择？

Answer 1

你无意中发现了大多数CS教育的致命弱点:他们教你工具和技术，而不是贸易。构建软件是一种技术，你只有通过多年的实践和使用软件的经验才能获得这种技能(用户比老师更严厉地批评)。构建软件也常常是一项业务，业务目标可能会凌驾于技术野心之上。

首先，船。如果你向企业主展示软件，而他们觉得软件已经准备好了，那么就发货吧。如果还没到那个地步，但接近了，就把它完成。唯一重要的软件是实际使用的软件。唯一赚钱的软件企业是有产品的。

其次，你学到了很多有价值的东西，所以你应该欣赏它教会你的东西：

1. 在没有计划或架构的情况下抛出代码是一种灾难。
2. 除了编写代码之外，编程还有更多的内容。
3. 非技术企业主通常不了解技术决策的影响(比如雇佣谁)，这取决于开发人员向他们解释事情。
4. 在现有的框架中，大多数问题已经解决得比您要好得多。了解现有的框架以及何时使用它们是有好处的。
5. 刚从学校毕业的人被分配到一个没有什么指导的大型项目中，他们往往会产生一碗意大利面代码。这很正常。

以下是关于如何继续下去的更多建议：

1. 沟通。您必须对项目的状态和如何进行的想法非常开放和坦率，即使您不确定并且看到了多条路径。这让企业主可以选择该做什么。如果你把知识留给自己，你就剥夺了他们的选择。
2. 抵制完全重写的诱惑。当你重写的时候，企业没有产品。而且，重写也很少像你想象的那么好。相反，选择一个体系结构并逐步将代码基迁移到它。即使是一个可怕的代码库也可以这样挽救。阅读有关重构的书籍，以帮助您度过难关。
3. 了解自动化测试/ 单元测试。您必须建立对代码的信心，这样做的方法是用自动化的测试来覆盖它。这和重构是密不可分的。只要您没有测试，就手动全面地进行测试(尝试破坏您的代码，因为您的用户会这样做)。记录所有你发现的bug，这样你就可以对它们进行排序和修复(你没有时间去修复所有的错误，没有软件在现实世界中免费提供bug)。
4. 了解如何部署web应用程序并保持其运行。这本书网络操作:按时保存数据是一个很好的开始。

Answer 2

这听起来就像所有其他被扔到我身上去修复的系统。

放松，这种事发生在很多人身上。一个没有经验、没有帮助、没有支持、没有指导的低年级学生并不是成功的秘诀。雇用和期望初级程序员从头开始构建一个工作良好、性能良好和可维护的全新系统是不现实的。如果这一切都发生在高级程序员身上，那你就太幸运了。

在我看来你必须坦白。这可不好玩。告诉他们你已经尽了最大的努力，这很有效(主要是)，但是你担心它可能表现不好，并且会有很多错误(总是有but )。它需要由高级程序员审查，并且他们应该能够很快地解决任何突出的性能/安全问题。或者他们可以部署它并交叉手指。要么没事，要么冒烟。也许你可以在问题出现的时候解决它们。如果你有一个庞大的用户基础，也许没有。

或者你可以做大多数人在这种情况下所做的事情:拿钱，消失让他们解决。我将由你来决定道德的选择是什么。

编辑(因为这个问题有很多选票，我也可以增加一些内容)

作为一名程序员的乐趣之一是非技术人员(可能是你的经理，当然是业务的其他部分)不知道你在做什么。这是好的也有坏的。缺点之一是，您必须不断地解释软件开发项目是如何工作的。计划，需求，代码评审，测试，部署和错误修复。你的工作是解释测试的重要性，并留出时间进行测试。你得在这里站稳脚跟。人们不会理解它的重要性(“我们就不能开始使用它吗？”)但是一旦他们开始测试(而不是在现场环境中！)他们很快就会明白其中的好处。他们雇用你的原因之一是因为他们对软件开发一无所知，所以应该由你来教育他们。您需要在这里强调测试和错误修复的重要性--记住，他们不是程序员，他们不知道除以零和被破坏的html标记之间的区别。

通常，出现的许多问题并不是真正的bug。它们将是可用性问题，错过的需求，已经改变的需求，用户的期望(为什么我不能在我的手机上使用这个？)然后是实际的真正的错误。在你开始工作之前，你需要解决这些问题--很多bug可以在几天后被处理或修复。如果人们期望有一个完美的系统，他们会承受很大的痛苦。如果他们预期会有虫子，那么在接下来的几周里，你的生活会变得非常轻松。

哦，不要把用户测试和单元测试混为一谈，也不要混淆系统测试。

• 单元测试-我的代码函数是否返回正确的值？
• 系统测试-当我单击X时它会抛出错误吗？
• 用户验收测试(UAT) -程序是否符合要求？它能做他们让你做的事吗？它能直播吗？

如果你没有写下他们要你做的事情的要求，那么UAT就会更加困难。这是很多人跌倒的地方。把他们想要的系统写在纸上，会让你的生活更容易。他们会说：“为什么它不做X呢？”你可以说“你叫我做Y”。如果程序错误，就修复它。如果需求是错误的，修复文档，要求增加一两天(不，坚持)，进行更改，更新文档并重新测试。

一旦你经历了几次这个过程，你就可以开始研究敏捷了。但那是另一个世界:)

DR测试是好的。

Answer 3

无论何时从零开始，您几乎肯定会犯同样多的错误，甚至更多的错误是由于第二系统综合征造成的。您的新错误将是不同的，但是调试所需的时间将是相似的，因此也会对它如何不合适而感到失望。如果部署了第一个版本，它还将延迟部署到生产或新特性的部署中，这将给公司带来严重的麻烦。Joel称它为“单一最坏的战略错误”，任何公司或开发人员都可以这样做。

建议的方法是在维护过程中一点一点地清理最初的混乱。甚至不要为了它而试图重构它。此外，管理者通常认为这是浪费金钱(通常是这样)，并带来不必要的风险，引入新的缺陷。一旦您痛苦地调试代码，它可能不是很漂亮，但它会工作。因此，让它，直到你需要触摸它出于其他原因(无论是一个错误修复，新的功能，或只是一个市场要求的改变)。然后清理那些最难调整的部分。这通常被称为童子军规则。

在这一点上你不需要和经理争论。只需将最小期望的重构包含在请求的估计中即可。你会从经验中学到的，当你可能承担得起一点让步，因为公司真的处于困境，当你不想在未来制造问题，只是不承认任何可能迅速侵入它。

最后，还有一个推荐阅读：大泥球。