在软件行业中典型的不良编程习惯是吗？[关闭]

一个月前，我刚开始担任软件开发人员的第一份工作。我所学到的有关OOP，SOLID，DRY，YAGNI，设计模式，SRP等的所有信息都可以丢到窗外。

他们使用C＃.NET Webforms并使用很少的外部类（绝对不称为对象）来执行“代码隐藏”中的几乎所有操作。他们确实使用自定义控件并重复使用它们。关于唯一使用的对象是Entity Framework。他们为每个客户端重用代码隐藏。他们有400行长的方法来处理所有类型的工作。对于新客户端，他们采用aspx和aspx.cs并剥离客户端代码，然后开始添加新的特定于客户端的代码。

他们的第一个借口是增加额外的维护，更多的代码就是更多的维护。这是一家包括我在内的三个开发商的小商店。一个开发人员拥有30多年的经验，而另一个则拥有20多年的经验。一个曾经是游戏开发人员，另一个曾经一直使用C和C ++工作。

这在软件行业中有多普遍？我如何确保自己掌握OOP和相关原则？我在业余时间进行练习，我觉得我真的需要在一个经验丰富的开发人员下工作，以更好地使用OOP。

1. 您在问题中引用的原则就是…… 原则。 它们不是命令，法律或命令。
2. 尽管提出这些原则的人非常聪明，但他们并不是绝对的权威。他们只是提供自己的见识和指导的人。
3. 没有“正确”的编程方式。 事实证明，随着时间的流逝，我们“接受”的方式已经发生了巨大的变化，并将继续发生变化。
4. 运输产品通常要优先于“正确”的方式。这是一种非常普遍的做法，它的名字叫：技术债务。

5. 某些常用的软件体系结构并不理想。 最佳实践正在从大型的整体应用程序发展为松散耦合的模块集合。

6. 上下文很重要。 只有当您使用大型程序或特定领域时，许多架构原则才能证明其价值。例如，继承对于受益于深度嵌套，紧密耦合的UI层次结构和其他结构最为有用。

那么，您如何遵循一条“正确的”道路，一条原则性的道路，以便您可以从旷野走出来？

1. 研究适当性，而不是正确性。在软件开发中执行任何操作的“正确”方法是最有效地满足您的特定要求的方法。
2. 研究权衡。 软件开发中的一切都是一个折衷。您想提高速度还是减少内存使用量？您是否需要一种很少有从业人员的表达能力强的编程语言，还是许多开发人员都知道的表达能力较低的语言？

3. 学习永恒。 一些原则经受了时间的考验，并且将永远是相关的。类型系统是通用的。一流的功能是通用的。数据结构是通用的。

4. 学习实用主义。 务实很重要。如果您无法发货，那么数学上的纯正，水晶大教堂的建筑和象牙塔的原理就毫无用处。

5. 做工匠，而不是狂热者。 最好的软件开发人员是知道规则的人，然后知道在合理的情况下如何打破规则。他们是仍然知道如何解决问题并自己思考的人。他们使用原则来告知和指导他们的选择，而不是指示他们。
6. 编写代码。 很多。在您编写大量代码并开发出如何正确应用它们的本能之前，软件设计原则是过早的优化。

这并不少见。要认识到的一件事是，软件行业是极其多样化的。一些公司处于领先地位。领先的大学和创新软件公司（甚至包括大型实验室！）以及四人帮等有福的人或团体分析了常见的做事方式和发明新的语言，机器，工具和模式的问题。新公司（通常是分拆公司）会尝试将其用于商业用途，有时会取得惊人的成功。想想Facebook或Google。

但是，如今，软件几乎在所有地方都可以使用，可能主要是在实际上不是软件公司的公司中使用。我主要在运输行业（汽车和铁路）工作，经验混杂。但是它们都不是接近“最前沿”的地方。有时他们不能做到；与安全相关的软件取决于经过严格审查的工具（我们目前使用的是1990年代经过验证的C ++编译器）。有时他们没有合适的人。通常，软件是由其他领域的工程师开发的，而当软件变得越来越重要时，他们恰好进入了公司的软件开发。不能指望他们了解或使用软件工程原理。

要考虑的另一件事是在现实世界中工程师重要的事情。从字面上看，手头的任务通常不是火箭科学。非软件公司中的头疼问题可以通过适度的软件手段解决。造就一个有用的甚至是优秀的软件工程师的部分原因是造就一个优秀的通用工程师的部分：负责地组织和记录您的工作；合作 进行良好的成本和时间估算（估算的有效性比实际成本和时间更重要！）；了解您可以做什么和不能做什么。这里明显缺少的是“了解并使用最新的工具和过程”。您所描述的是一家已经建立了适用于他们的工具集和流程的公司。他们可能永远不会产生任何性感或非凡的东西，但它们满足客户需求的程度足以产生稳定的收入来源。那可能是工程学的定义;-)。

是的：在大学里学到的东西实际上在很多领域并不常见。

我想补充一点安慰，或者说更乐观。您学到的东西不应丢到窗外。您可以在日常工作中应用更好的原则，以免破坏工作。也许会有机会引入新的工具或设计模式。当旧的工作方式对同事不满意，或者他们在管理复杂性或维护方面遇到问题（创新解决的两个最棘手的问题）时，机会是最好的。有机会时准备好进行改进。产生积极影响并逐步改进方法和工具；将知识传播到值得赞赏的地方。

他们使用C＃.Net Webforms并使用很少的外部类来完成代码背后的所有工作

那里有您的解释。如果您不知道，那么开箱即用的Web窗体代码几乎与OOP，SOLID，DRY，YAGNI，Design Patterns，SRP等完全相反。甚至几年前Microsoft的官方示例今天会让你畏缩。

Web Forms将自身推向程序流程，其中某些虚假的“事件”由控件单击等触发。花费大量时间进行Web窗体开发的开发人员通常也似乎也不愿意离开它，这可能是因为他们花了很多时间来学习页面生命周期以及如何进行动态呈现的控件，以至于他们讨厌现在就把这些知识扔掉面对更新/更好的方法。沉没成本谬论的无意识版本。这些开发人员花了多年的时间学习如何处理Web窗体，现在不会轻易脱离这些专业知识，因此他们谈论“维护”时间。

顺便说一句，这在.NET Web窗体空间中很常见。

这在软件行业中有多普遍？

很普通的。这与水管工破坏您的水管，木匠运送垃圾或廉价裁缝制作不合适的西装一样普遍。也就是说，都是人类。

发生这种情况有一个很好的理由：未经真正培训（或没有热情）的人不得不在压力下实施某些措施。

这些问题主要不是那些人的问题，而是通常是该公司中围绕软件开发的结构的问题。例如，一家公司可能有很多实习生来开发他们的内部软件。即使这些实习生很聪明而且知识渊博，他们也只会在这里呆上几周或几个月，所有权也会经常变化。

或者，某个领域中有才华而不是程序员的人可能会一起破解某些VBA等应用程序，因为一开始似乎很容易。

否则，一个制作精良的应用程序会在维护阶段结束，所有优秀的开发人员都会继续前进，然后继续由很少了解它的人（最糟糕的情况：一个）来开发它，他们没有文档，等等。

我如何确保自己掌握OOP和相关原则？我在业余时间进行练习，我觉得我真的需要在更有经验的开发人员下工作，以更好地进行OOP。

有两个可能的答案：

• 可以：与您的老板讨论此事，并确保您进入干净的项目。如果不可能，找到一个新老板。
• 或者：对此承担责任。这意味着您可以自己做-在您的业余时间，或者如果可以的话，在公司中，但要靠自己（不太可能）。

如果第二个答案对您来说太愤世嫉俗了，那么让我向您保证不是。谁家里有木工车间木匠将最肯定会超过一个谁不能做一个更好的木匠。

例如，对于某些人来说，例如深入研究诸如Ruby之类的新语言，不仅学习语法，而且深入学习该语言的特殊面向对象方面，而且确实深入研究，绝对是有可能的，并且会带来很多乐趣。所有这些都在您的业余时间，与您的工作没有任何关系。这只是一种业余爱好，但是作为您自己的专业培训，它可以和坐在某个主要开发人员旁边并尝试遵循他们的工作一样有效（或更有效）。然后，这将完全适合您的个人发展和您自己的乐趣。如果您这样做没有乐趣，或者发现自己根本无法理解，请从头开始，然后返回第一个答案。

那个正在培训您的首席开发人员很可能正是通过这种方式学习到这些东西的。

我认为在西班牙这是一个常数，因为当开发人员在公司任职多年后，他（或她）通常会被提升到更多的管理领域，例如分析和项目管理。结果，没有同行评审，并且代码通常是由经验不足的人编写的。

这些经验丰富的人的失败永远不会得到纠正：相反，他们唯一的焦点就是完成工作。结果，代码中累积了越来越多的错误做法。

最终，一些聪明的驴子说最好的“解决方案”是更改为一种新兴技术，该技术将生成更干净，更可维护的代码，并创建一个新的应用程序。好像技术本身可以做到那样。

再说一次，没有经验的程序员会使用这种新技术，没有人审查代码，并且这个圈子又被封闭了。

您在学校学习的某些“最佳实践”在实际项目中既不实用也不具有成本效益。我注意到的最大变化之一是格式和注释。我的大多数教授都强调了广泛编写代码的重要性，但是在现实世界中，好的代码通常（并非总是如此）是不言而喻的，更重要的是，许多老板不想为您付出更多的时间来花时间编写代码评论。

有时您会看到程序员迫不及待地想要使用快捷方式和反模式，而这些快捷方式和反模式所需的模板要比质量解决方案少。

但是，我在许多团队和项目中注意到的最大问题之一是不愿意学习新事物。。与我交谈过的许多较老的程序员的职业生涯始于软件工程的“狂野西部”时期，当时，资格考试开始并结束时就愿意编写代码。他们通常主修完全不同的领域，并在机会出现时跳入编程，几乎没有或没有接受过正规教育（例如，他们的雇主没有程序员，需要有人学习才能构建内部软件）。这些老式的自学成才的程序员中的一些从不努力学习现代编码实践，并且继续以他们几十年前学到的任何风格进行编码。当由于资历高而最终负责新项目时，他们往往会拖延项目并损害整体代码质量。

当然，以上内容并不适用于所有较老的程序员，而新一代编码器可能同样有罪。我与许多年轻的程序员一起工作，他们从大学毕业后就学到了一些工具和库，然后完全停止学习。他们将下载一次IDE或库，除非其公司要求，否则绝不对其进行更新（您有时可以根据他的库的过时程度来猜测程序员毕业的那一年）。他们没有跟上所选语言的新功能，也从不学习新语言。他们不会学习新的编程策略，并且可能会滥用模式或范式，因为他们不知道更合适的选择（哦，MVC，您遭受了多大的虐待）。随着时间的流逝，他们的工作流程变得越来越过时，并且他们变得比资产更重要。

总而言之，混乱的代码库的两个最大原因是仓促的截止日期和知识过时或不完整的程序员。不幸的是，这两个问题的责任都落在老板或CTO身上，他们必须确保截止日期是切合实际的，并且员工必须掌握最新的知识和技能。如果老板对良好的编程习惯一无所知，那么您能做的最好的就是尝试建议更改，并希望他们愿意接受建议。不幸的是，他们可能倾向于相信一个不懂OOP并且喜欢编写10,000行类的高级程序员的话。

一些不良的编程习惯是由于必须使用几十年前开始开发的旧版软件而导致的。如果有一个庞大而复杂的软件，则重写所有内容可能不是一个选择。理解代码实际上正在做的一切甚至可能非常困难。最好的选择可能是只复制有效的方法，同时尝试整合更好的编程实践，如果可以的话，又不会破坏任何内容。

我认为重要的是，不仅要对错，而且要知道每一个对与错背后的原因。当您知道原因后，就可以预测后果。为什么使用这个或那个原理，不是因为在一本书中已经描述了它，而是因为我们知道它如何帮助以及应该打破它究竟会发生什么。如果您知道何时会发生什么，则可以权衡利弊并做出决定。这也将帮助您每次争论自己的立场。如果使用得当，SOLID和OOP也可以减少维护。

如果SOLID的用法过于教条，则会导致太多的类和方法，但效果也不尽如人意。不要过分。这在某种程度上是我们的教科书和教程的一个大问题，因为他们经常在没有正当理由的情况下试图推广思想。OOP也有其缺点。许多原理和范式相互矛盾。您不需要处于最高位置，您需要使一切都合理，合理，优雅且简单。

另外，因为这是您的第一篇工作，所以这些程序员可能不是很熟练。但是话又说回来，他们可能不是很艰巨的任务而受到信任，这些任务不需要太多的技能就可以完成，而熟练程度较低的编码员则可以降低工资。这就是经济学的原理。每个工作场所都不同。

我理解你的感受。不要惊慌。您将需要知道的信息，也许不是立即需要，但是它将为您提供帮助。也许在不同的工作场所，也许在某些场合。您还有时间可以走得更远。