建筑学如何提高我的编码技能

过去几年，我花在深入架构和技术写作上的时间比在 IDE 上敲代码的时间还多。今年夏初，我回归全职开发一个新项目。令我惊讶的是，虽然语法有些生疏，但现在我的编程水平比以前高多了。我想借此机会，谈谈我的思维方式和方法上的一些变化。

概览

我注意到的第一件事是我的视角发生了变化。我的注意力不再只集中在眼前的工单上，而忽略了其他一切。我知道我的任务是什么，我关注的是它如何成为一个更大系统的一部分，以及我为什么要构建它。我意识到我所做的改变会影响其他工单和系统。

在我职业生涯的早期，我希望确保我的代码能够正常工作，确保它高效。现在，我专注于确保能够正常工作的代码对整个项目来说是合适的，并且我们清楚它所要实现的更大目标。

首先考虑可用性

这些更大目标的一部分在于认识到成功完成一项任务比编写一个高效的 for 循环更重要。我们不应该指望以后能够重构，而应该花时间提前做好。这意味着响应式设计、可访问性和国际化从一开始就应该融入其中。

它还延伸到考虑 API 体验，优先考虑用户和未来开发者的一致性。考虑代码库的可读性和组织性。选择最不具主观性的方案，这样当您需要改变行为或进行大规模重构时，就不会被束缚。

所有这些“小心谨慎”的考虑让我成为了一名更优秀的程序员。这再次提醒我，我们的技能远不止语法。

优先级

第一次就把事情做好，这句话意义重大。如果我们把这种心态用在所有事情上，就永远无法交付。大多数项目都会落后于计划，很大一部分原因是优先级划分混乱。

考虑全局并了解最重要的功能意味着我知道何时会遇到潜在的权衡。这个功能会花费更长的时间，并且可能会导致一些复杂的代码。我们真的需要我们描述的功能吗？或者，稍微改变一下功能或实现方式，对项目来说会更好吗？

在我职业生涯的早期阶段，我可能不会想到要质疑眼前的罚单。但现在我意识到，这通常并非对团队或项目最有利。这并不意味着你要不断地尝试缩小工作范围。只有当它的好处大于坏处时，你才应该这么做。

意识到整合问题

即使我写的代码完美无缺，满足所有需求，我也知道它最容易出问题的地方就是集成。构建大型系统时，其他应用程序、数据库等之间会有多个交换点。

在完成系统架构设计之后，我现在会特别注意了解代码中的每个集成点。确保我理解其中的复杂性、挑战以及潜在的边缘情况。这既需要抬起头来环顾四周，也需要确保左手与右手协调一致！

这个要怎么部署？这个数据格式能跨系统兼容吗？我传递了所有必要的信息吗？

安全焦点

我比以前更加关注的另一点是安全需求。通常情况下，我们会有一个总体计划，但具体细节并非附在每张工单上。编写代码时，我需要了解安全计划中的哪些部分适用于我的功能。

这适用于我的代码和我之前提到的集成点。最大的漏洞往往出现在数据在系统之间移动时。确保我考虑到这些复杂性并提出正确的问题，会对后续发展产生重大影响。

沟通

这是最大的变化。在我开发生涯的早期，我以为证明自己能力的最好方式就是接下任务并完成它。然而随着时间的推移，我意识到失败的最大根源往往在于人员和团队。缺乏沟通和协调会导致严重的问题。

现在，当我发现项目中存在冲突时，我更有可能提出来。我更有可能联系同事确认设计方案，而不是坐等问题自行解决。我现在知道，这些潜在的缺陷会对最终产品造成巨大的影响。

结论

你无需花时间构建系统或规划庞大的项目来内化这些概念。随着你积累更多经验，参与更多类型的项目，你开始发现失败和成功的规律。你会了解哪些事情应该优先考虑，哪些事情可能要放在次要位置。但这正是我的人生轨迹，所以我想分享一下。