开发方法是否应该压制开发人员的个人主义？

我正在大学的最后一个学期，正在学习软件工程课程。在课堂上，我们学习各种软件开发方法。我们关注并用于开发项目的方法是瀑布方法。

我觉得教练可能执行错误。在我们的类图中，我们必须列出所有属性和方法，包括私有属性和方法。我读过几本书，即“清洁代码”，该书说，要使功能尽可能简短和集中。如果它们不能帮助其他开发人员列出所有小功能，这似乎很麻烦（它们是私有的，没有其他人可以使用它们）。另外，在设计程序时，我可能不会想到每个微小的功能，在重构时它们可能会出现。

讲师是否要求我们列出所有功能，以告诉我们错了？而且，这些设计方法是否压制了开发人员的个人主义以编写代码，从而使他们更好地理解代码？

您是否问过老师为什么必须列出所有方法？

就像在教室环境中需要的很多东西一样，其目的可能不是使您的类图对开发人员更有用，而是帮助您和您的同学考虑如何设计您的类。当学生学习如何将较大的问题分解为较小的问题时，考虑可能需要的私人方法可能对他们有所帮助。这对于教师更好地了解学生正在考虑采用哪些方法，以便在未认真考虑某人的设计的情况下尽早介入过程中可能有所帮助。课堂环境中的文档通常比现实环境中的文档涉及更多的内容，因为讲师的

当然，导师也有可能认为此文档水平对实际项目很有帮助。在这种情况下，讲师可能会过时或来自于适合该级别计划和文档的特定细分背景。例如，如果要为航天飞机构建导航系统或设计医疗设备，通常更适合的是在开发前投入大量资金进行前端设计，而不是重构代码。另一方面，如果您正在开发一个社交网站，则更敏捷的方法更合适。

不，如果您使用瀑布方法，则指导老师会正确地告诉您列出所有属性和方法。 Wikipedia注意到对瀑布的批评：

许多人认为瀑布模型在实践中是个坏主意-认为任何不平凡的项目都不可能在进入下一阶段并向其学习之前完美地完成软件产品生命周期的一个阶段。例如，客户可能在审查可用的原型并对其进行评论之前并不确切知道他们需要什么要求。他们可能会不断更改他们的要求。设计师和程序员对此几乎没有控制权。如果客户在完成设计后更改其要求，则必须修改设计以适应新要求。这实际上意味着使大量工作时间无效，这意味着成本增加，尤其是如果已经在Big Design Up Front中投入了大量项目资源。

这些设计方法不会压制设计个人主义的实现者，因为仍有很多部分需要解释，并且可以在结构上施加独特的触感，例如，给图片加上骨骼，并添加肌肉和其他组织以创造出动物，想知道多少你有自由设计那种动物吗？

您已经找到瀑布的缺点，是的，但是一切都有其优点和缺点。

在课堂上，我们学习各种软件开发方法。我们关注并用于开发项目的方法是瀑布方法。

您可能已经学习了经典的Waterfall模型，该人从一开始就将其介绍给软件开发人员，这被认为不适合开发大型软件系统。您可能会对阅读Winston Royce的论文《管理大型软件系统的开发》感兴趣，以了解更多有关许多人认为是瀑布模型的问题的信息。

但是，瀑布模型非常适合教您进行软件开发的整个生命周期，并且可以花费时间来学习和执行需求工程，体系结构设计，详细设计，实现，测试和维护的过程非常清晰，不同。

在我们的类图中，我们必须列出所有属性和方法，包括私有属性和方法。我读过几本书，即“清洁代码”，该书说，要使功能尽可能简短和集中。如果它们不能帮助其他开发人员列出所有小功能，这似乎很麻烦（它们是私有的，没有其他人可以使用它们）。另外，在设计程序时，我可能不会想到每个微小的功能，在重构时它们可能会出现。

这些都是非常有效的观点。

列出设计阶段中的所有属性和方法，即使在使用Waterfall时，也可能会过大。您绝对应该列出所有公开的内容以及基本属性。实际上，其他所有内容都是实现细节，您可以通过将实现反向工程到图中来获得。

Clean Code的建议（我从未读过-我只是按照您发布的内容）似乎是公平的，并且即使在使用Waterfall方法时也适用。您可以根据“ 单一职责原则”，关注点分离和SOLID的其他原则设计类和方法。Waterfall不会告诉您如何设计，只是在您需要进行设计时。就是说，在您学习和思考在实施过程中实现此目标的更好方法时，这很困难。

我认为这指出了一个事实，即设计和实现之间必须非常清楚地进行迭代，这是传统的Waterfall无法解决的问题。

如果它们不能帮助其他开发人员列出所有小功能，这似乎很麻烦（它们是私有的，没有其他人可以使用它们）。

如果您认为这很乏味，请等到完成真正的工作编程。考虑一下，对于您来说，软件可能不是一个可行的职业。

另外，在设计程序时，我可能不会想到每个微小的功能，在重构时它们可能会出现。

所以？

讲师要求我们列出所有功能，是否告诉我们错误？

不，这是常见的要求。

而且，这些设计方法是否会挤压设计的实现者（开发人员的个人主义）来编写代码，从而使他们更好地理解代码？

是。令人心碎的是软件开发的重要组成部分。任何时候都将以所有可能的方式击败所有程序员的所有个性。它说，在“上帝的编程规则”中，某处从一座山传给了一位先知。

不，你只是在沉闷中停滞。克服它，重新开始工作。

编程是在约束内工作的艺术。CPU提供了有限的指令集。IO受硬件设计的约束；创建OS API是为了鼓励某些行为并限制其他行为；高级语言通常被设计为促进一套习惯用法超越其他语言。

方法也被精心设计来限制。

在开发过程的所有方面，您面临的挑战是在这些约束条件下实现自己的愿景。您是否会在硬件，语言，API和方法论引发的每一堵墙上ash之以鼻？还是您会找到一种方法，使您希望实现的目标与允许和鼓励的目标相协调？

你做 真的认为您的老师希望阅读无休止的细节吗？然后测试该理论：分解程序，并记录每个原子。当他的书桌在沉重的压力下垂时，我宁愿怀疑您会发现他的真实愿望与您的期望有所不同。

或者像准备的文档，你认为合适的。讲清楚，理解，读起来像达西耶尔·哈米特小说。然后坐下来与他交谈，向他展示您的所作所为，使他信服它的优点。

我认为讲师很有才华，可让您执行此项目，从而教会您Waterfall开发的优缺点（主要是缺点）。

衡量项目分析复杂性的简单经验法则是：“开发人员或他所工作的公司是否可以对所创建的软件所发生的足够戏剧性的事情（通常包括死亡或大量金钱损失）负责？”

我的某些课程与您有相同的经历。有军事背景的人会教我们分析。这将是完整而详尽的分析，甚至在最小的细节中都计划整个项目的过程。这种项目无法承受很多迭代（炸弹爆炸也可以，预算爆炸也不行），因此在这里没有创造力的地方，您必须按计划进行。

另一方面，如果您已经阅读了一些，那么您肯定会读到有关敏捷方法论的文章。通常，文档减少了，开发人员在开发解决他确实遇到的问题的解决方案时可以发挥自己的创造力的空间更大。

总之，您获得的经验越多，越好，并且您的教练向您展示的内容的确适用于整个行业。只是要知道，管理和设计项目的方式肯定有与编码方式一样多的方式。您会发现所有捍卫者和批评者。在学习时对它们进行测试，然后选择自己喜欢的一种。

有些软件工程课程（例如我所修过的课程）以一种奇怪的方式教授，其中“失败就是成功”，成功是从失败中学习的浪费机会，而且越来越少，越来越多。如果这是其中之一，那么只需坚持做作业并享受怪异。

我认为您的老师与您联系不上。商业软件很少设计或记录到这种程度。它太昂贵了，并且如果没有更多的花费就无法维护最终的文档。自从通常使用汇编语言进行编码的日子以来，IMO的此类惯例已成为历史。您最好将时间花在尝试更敏捷的实践上：测试驱动的开发，结对编程，连续重构。

老师有没有“告诉你错”？

我认同。

将无聊的工作分配给知识产权工作者是浪费的。在学校里，无聊的工作几乎没有教学价值，只是为了确保学生从事无聊的工作。这样的练习对学生和整个行业都有负面影响。由于浪费时间，学生受到伤害。该行业受到损害，因为一些学生可能会得出这样的乏味是必要且有用的结论。两者都不是。在软件开发的30年中，我能想到的唯一工作既无聊又有用，那就是更换备份磁带。有机器人可以做到这一点，但它们的价格过高。