10个顶级软件开发人员原则(错误开发人员事情功能代码)

作为首席软件开发人员，我收集了一些我经常在日常工作中积极使用的原则。
这些原则是随机列出的，有些甚至可能相互矛盾，然而，它们都是有帮助的，并且易于应用。

你知道在不成为你编写代码的业务专家的情况下，生产有效的优质软件有多难吗？

你可能确实知道。
开发人员经常与他们一无所知的企业和领域合作。
但让我告诉你，在大多数情况下，领域专业知识胜过技术知识。

只有技术知识，你才能在技术上正确地做错误的事情，这比什么都不做更糟糕。

尽你所能寻求所有的领域知识。
吸收它。
把它写下来。
随时把它放在手边。

想要更多这样的文章吗？在这里注册。

这适用于很多事情。
构建小功能比构建大功能要容易得多。
在小团队中发展比在大团队中更容易发展。
三个人比六个人协调得更好。
比起少数大类，小班级系统更受欢迎。

小通常是要走的路，有时制作一口大小的碎片也更难。
复杂性很难隐藏在小地方，但原生于大。

不可否认，从头开始构建绿地项目和全新的功能比修复一些旧的性能问题或古怪的界面更令人满意。

我明白了。

新是有趣的。
正是它吸引了所有的注意力。
但是，修复旧代码中的东西，即通常是生产软件，通常比构建新功能更重要。
客户正在购买已经在那里的东西，如果那里的东西坏了，那么客户就会离开。

您可以从错误修复和性能优化中获得很好的学习，确保您将构建的新东西在这些学习的基础上变得更好。

修复任何错误的第一步通常从创建一个测试开始，该测试使用导致程序失败的确切数据。
您会想自信地重现错误。
如果你做不到，你怎么能确定你正在修复正确的事情？

每当我修复生产中发现的错误时，我都会尽可能地模仿实际情况。
我们是否从数据库中获取数据？确保使用真正的数据库，例如使用测试容器。
我们是否调用了外部HTTP API？发出与API返回的实际响应相同的调用。
文件是从磁盘加载还是写入磁盘的？做同样的事情。

更进一步。
调查导致错误的原因。
是疏忽吗？分配的开发人员是否不够熟练？我们做了草率的代码审查吗？这是一个写得不好还是模棱两可的用户故事？接受标准不完整吗？

如果您不知道导致错误的根本原因，您将如何防止未来的错误？错误不仅仅是因为开发人员搞砸了。

假设软件开发中的任何事情都是一个坏主意。
然而，有一个例外。
总是从假设开始，即人们用他们拥有的时间、知识、资源和能力，尽其所能地完成工作。
人们通常不喜欢做出错误的决定、编写错误的代码、从事恶意行为和忽视。

一定要认识到错误和缺点源于时间限制、知识差距和有限的资源。

这不是借口高级或首席开发人员不知道自己在做什么。
这只是试图强迫细致入微的思考，而不是公然批评他人的作品。

在极少数情况下，我听到开发人员说类似“我不确定这应该如何运作。
如果错误，我们将让QA创建一个错误票。
”不要让像那样的评论滑动。
如果你需要在那里进行一次不舒服的谈话，那就进行吧。
没有这种愚蠢的空间。

我明白你可能想把它推到QA来弄清楚。
也许甚至经常。
但是，退后一步，做点别的事情。
回来后，一定要寻求你需要的所有澄清。
问问你需要的人。
展示示例。
演示不同的方法，做任何你需要做的事情来灌输你所做的事情的确定性也是正确的事情。

想要更多这样的文章吗？在这里注册。

始终在开发过程的早期寻求澄清。
这一核心原则是一个至关重要的价值观，它强调在开始实际开发工作之前，需要深入了解需求、制约因素、期望、质量水平和时间框架。

了解任务或功能的重要性，并确定能够帮助您的最有知识的人。
认识到您经常会遇到未知的未知情况，特别是在进入新域时。
通过在整个开发过程中不断寻求澄清来保持积极主动的方法。
在您开始实施潜在解决方案之前，请花点时间考虑以下问题来评估您的准备情况：

我喜欢问业务分析师或产品负责人“你没有问我什么问题来表明我理解这一点？”

我知道我刚刚说了，但我会再说一遍：在没有限制的情况下编写任何好的软件都非常非常困难。

制约因素阻止我们过度工程、镀金、专注于所有错误的事情，以及制造不可理解的架构和系统。
了解功能的约束使设计、实现和评估变得容易得多。
你知道它的界限，以及应该有什么可能。
测试和验证很容易。

当涉及到构建一个功能时，情况正好相反，你不知道它的边界在哪里。
你会如何测试它？

据我所知，一个植根于写作的原则。
我第一次听到这个表达是在本科学习时。

对我来说，在软件开发中，这意味着删除任何不符合目的或不必要的代码或评论。
这也许是你最好的作品。
你写的最有创意的代码。
但是，如果它只是为了你的自我放纵，那么它必须离开。

提前考虑。
这个功能将如何演变？我们有可能把这个换掉吗？我们稍后会添加更多选项吗？

提前思考是便宜的。
构建进化比重新利用现有代码更容易、更安全。
考虑可扩展性点和实现功能，以便它们可以交换、扩展或修改，通常是一项不错的投资。

我鼓励每个开发人员获得良好的商业政策和规则。
虽然政策通常保持相当稳定，但构成政策的规则经常变化。

这不是金盘所有东西的免费通行证。
构建灵活的代码是关于预测，并最终允许改变，也是关于深思熟虑地权衡不允许改变的后果。

始终以专业的方式展示自己，展示自己的行为和技术能力。
不要从事单身或竞争性讲故事。
根据客户的条件与客户沟通。
永远不要垃圾谈论现有代码、前同事和工作场所。
避免参与指责游戏、指责转移和替罪羊。

分享战争故事是可以的，但不要在上面写上名字。

作为一名专业人士显然不是软件开发所独有的事情，但不幸的是，我确实认为许多软件开发人员具有独特的能力，可以在工作场所表现得非常不专业。