要严格还是务实？

我开始意识到开发软件（以及其他）是一个不断问自己问题的过程。有关代码质量，关注点分离，最小化依赖关系的问题，...

但是主要的问题是：如果不去精神病医院就可以走多远？

我正在申请一份新工作。昨天我与一个可能的未来雇主一起，他想测试我的编程能力。练习之一是：解释此代码的作用。我浏览了他们开发的应用程序（vb.net中的winforms）的一些代码（这是医院的管理应用程序）。这给了我一次真正看清他们如何对待事物的机会，这真是令人失望。

一些例子：

• 我在某处看到了：调用[在此处插入子例程的名称]->我很震惊：这不是VB6的内容吗？
• 他们使用ado.net拥有一个单独的数据层，但是我必须检查的一种方法将数据集返回到调用层。因此，无论是否使用单独的数据层，应用程序都与ado.net绑定在一起（如果它们从不切换到其他数据访问方法，也永远不会成为问题）。
• 该数据集是按原样读取的，因此它仍然是一种以数据为中心的方法（当然，可以争论您可以在“ Patient”或“ LabAnalysisRequest”等类中放入多少逻辑/行为。
• 我还相信已经看到了通过字符串串联构造的sql查询。
• 他们使用存储过程（对我来说，这意味着：逻辑分散）
• 没有提及视图/控制器：全都是形式驱动的
• 我看到的最丑陋的事情是：

      如果是TestEnvironment.IsTesting然后
         someVar = [一些硬编码值]
      其他
         someVar = [一些动态获取的值]
      万一
      [这里的其他功能]
  

这与我在学校学到的完全不同：（不可知性）域层，可持性层，表示层，单元测试，...

因此，我改写我的问题：一个人应该是多么基础或教条？程序员应该在多大程度上坚持自己的原则，或者只写能完成这项工作的代码？

我知道这并不能直接回答您的问题，但是我仍然觉得这比评论还值得：

当您进行工作面试时，您面试他们的次数与他们面试您的次数一样多。停止在面试时习惯，因为您会爬行到肚子上恳求他们为您提供一些东西。他们结帐了您，但您也结了帐。如果他们不喜欢您，他们将不会雇用您。如果您不喜欢它们，请不要去那里工作。

是的，在行业中，由于存在紧迫的期限，缺乏资源和财务限制，随着时间的流逝，三位具有不同背景，技能和热情的开发人员逐渐将其破解了十年的旧代码库，这些代码永远不会看你（应该）学会的样子。您将不得不做出一些让步。但是，多少和在哪里划清界限，完全取决于您。
当然，很难找到让您做出更少让步的工作。但是它们可能会更有趣。

FWIW，到目前为止，我（从事该行业已有10年以上）从未在拥有很多开发人员的大公司工作过（〜30个开发人员最多，一打规范），因为您在小范围内进行更改的可能性更大公司。只要我有足够的钱不让孩子挨饿，我就不想成为一家大公司的小齿轮，我要做的就是与其他设备保持同步。
在看到他们希望我通过的测试后，我拒绝了工作机会。我是C ++开发人员，那里有许多C ++测试，这些测试太糟糕了，它会使您的脚趾甲令人讨厌，而且我不想花时间与风车作战，因为他们雇用了无法编写干净代码的白痴。
几个月后，我也离开了工作，因为尽管他们在访谈中说了不同的话，但他们的编程理念（短期目标，明年没关系）与我的能力（长期代码稳定性）不符。

切勿编写仅能完成工作的代码。但是同样愿意检查您的学说。仅仅因为您在学校学习过，并不意味着它是当前的想法，甚至不是有效的想法。由于编程必须对商业世界更加敏感，因此软件设计生命周期已过时。有时，笨拙地链接的软件解决方案会笨拙地链接，因为在允许的时间内更换了零件。

以下是我整理的一系列问题，这些问题将决定您如何适应公司的编码方式。

1. 他们花了多少时间来预留时间来重构和更新其代码库。他们如何看待更新的代码库将是决定您的适应程度的主要决定因素。
2. 他们多久购买一次第三方，而不是在内部进行编码。
3. 他们如何看待开源软件。他们是否意识到自己在更改代码方面具有灵活性。他们是否像购买第三方一样看待它。
4. 您将在某个抽象层上工作。您与之互动的团队会为您确定界面吗？界面的哪层/团队/一侧具有更大的决策权。
5. 在制定决策时，主管会听取程序员多少意见。当程序员发出危险信号时，主管会停止并检查他们的决定。
6. 您是否考虑有管理经验的程序员？他们如何看待自己的经历？他们的经验有效吗？他们是否让过时的经验影响决策？
7. 代码库的粘性如何？
8. 他们多久更新一次编程工具（IDE等）

这些问题的答案比看看它们是否符合您的教条更适合您如何看待他们的编程生活方式。

教条将不可避免地被破坏（我们只是没有时间更新X）。但是，优先级将定义您与他们的风格和决策冲突的程度。

我认为您必须将其作为整体的一部分来考虑。我记得我的第一份工作是在一个小组中的一个职位，该职位告诉我他们正在做面向对象的C ++，这是我刚刚在学校学习几年的经验。

他们的自我评估是错误的-他们在做一些笨拙的C。它本质上仍然是功能非常强大的设计，我必须自己拿一本C书来教我自己printf和getf以及我从未学过的其他C机制。团队中没有人甚至意识到C就像他们的代码一样，这一事实表明，这种“ C ++设计”的意义已落空了。当时我的目标是进行OO开发，所以这有点令人反感。

但最终，我很高兴能加入团队。他们是一群充满活力的，非常聪明的人，我被很多难题困扰着，我必须全生命周期地工作，从那以后，我对问题域（PKI）的了解为我的事业注入了活力。团队在功能领域所做的工作非常出色，我仍然非常喜欢该产品和工作经验。更好的是-我今天仍然与其中一些人（后来有几家公司）一起工作，他们仍然是一个灵感，我们仍然在做得很好。

我认为，完美实现编码语言的最佳实践并不意味着良好的工作经验或良好的团队成败，而推动职业发展的工作远不止于此，并且如果产品具有良好的表现，质量，团队具有良好的工作条件（例如Joel测试），并且团队中充满了精明的人并能完成工作，因此实现的完美是次要的。剥夺好工作，好人，好工作条件等因素-不管代码是否奇怪地组合在一起，都不值得坚持。

应该是多么的根本或教条？程序员应该在多大程度上坚持自己的原则，或者只写能完成这项工作的代码？

这里要记住的最重要的一点是您的目的是什么？

在大多数公司中，人生目标不是编写完美的代码。您的目的是为用户创造价值。编写优质的代码通常是交付优质产品的最佳方法，该产品还易于维护，排除故障并开发。

好的代码是一种应在可以带来良好投资回报率的地方应用的工具。

一些例子：

1. 我将花费大量时间来设计和编码我的API，尤其是业务层的API。许多其他程序员将使用它们，如果设计适当，它将节省大量时间和麻烦。
2. 我将在表示层中放宽规则。在那里，我将更倾向于牺牲代码“完美”以支持增加更多功能

最重要的是，您需要有原则，但是当它们带来的危害大于价值时，您还应该足够灵活地打破这些原则。

我在一家电子商务零售商工作了几年。当我从那里开始时，他们内部应用程序的代码都是用VB编写的，用于MS Access，至少可以说这太可怕了。我有一个由3个开发人员组成的团队，在接下来的几年中，我们用适当的VB.Net应用程序替换了它。

但是由于我的招聘预算非常有限，所以我只能负担初级程序员。而且，当然，他们产生的代码并不是很好。但是它奏效了，该公司每天都使用这些应用程序来赚钱。

然后我开始和我的家伙们一起工作。在OOD，数据库设计，MVC和C＃中进行了一些培训。多年来，情况有所改善。当我四年后离开时，代码库仍然不是很好，但是它比我刚开始时好100倍。

您所描述的情况通常是必须使用可用资源的结果。我们没有生活在理想的世界中。同时，这是一个真正有所作为的绝好机会。

顺便说一句：这些应用程序中的一些仍在使用中，与3年前相比几乎没有变化，它们仍然可以赚钱。

我认为遵守您的原则非常重要。您应该始终努力在给定的约束范围内产生最好的代码。但是，如果您在原则列表中添加“永远不必阅读或更改错误的代码” ，则将很难找到工作。请记住，有50％的程序员毕业于他们课程的下半部分。即使在一个人的团队中，“今天的你”比“上个月的你”更适合解决问题。能够使用非理想的代码只是工作的一部分。

许多雇主意识到这一点，因此他们给您阅读的代码可能代表了代码库中最糟糕的代码，而不是最好的代码。如果从上下文中不清楚，您应该问。我有时采访的一位同事有一页代码，他故意写得不好，只是用作采访问题。

在99％的情况下，您应该坚持称之为“教条”。教条是由经验丰富的人经过多年的实践而制定的，在某些时候看来实用的东西实际上常常不是。这通常比您还不足以正确解决该问题的事实更为重要。

但是，不要盲目遵循教条。记住哪些结论导致人们遵循该教条。因为您会发现一小部分不应遵循的情况。无论如何，这些情况很少见，在做出这样的决定之前，您应该始终与其他经验丰富的程序员讨论。

重要时要严格。大括号样式（或其他编码约定）？没关系 使用商店使用的那一种。无缘无故破坏封装（或其他基本编程原理）？不那么琐碎。

Stack Exchange使用表格进行布局（许多其他主要的赚钱网站也是如此）。这会使烟雾从纯粹主义者的耳朵中冒出来吗？当然可以。但是，实用主义每次都会胜过纯洁。每次运输产品都胜过使其完美。

从历史的角度来看，整个域层，持久层，表示层，单元测试的东西仍然是相对较新的。那里有大量仍在使用客户端/服务器模型的软件，并且不会因为“更好”而被更改为最新的体系结构样式。