本文的目的是从一个不仅仅坐在椅子上并且完全按照他们所说的方式做某事的人的角度来介绍软件开发。


它强调软件开发是一个非常复杂的过程，需要遵循许多较小的步骤才能构建高质量的东西。需求收集，体系结构，测试，编写可维护代码，所有这些都汇集在一起，创建了一个可在整个生命周期内得到支持的产品。


本文讨论了这些要点，并从最终结果的角度详细说明了它们的重要性。


文章还强调了我们自己的经验和态度如何对最终结果产生重大影响。





首先，我们需要了解我们正在构建的内容。


在编写任何代码之前，我们需要回答一些问题。


我们正在构建一个全新的应用程序吗？


这是重写吗？


它是复杂系统的一部分吗？


它可以独立工作吗？


有任何依赖吗？


我们了解我们需要构建什么吗？


我们是否了解如何使用该软件？


我们知道谁会使用它吗？


我们了解这个软件的作用吗？


那段代码的维护怎么样？


正如你所看到的，有很多问题需要直接回答。我们甚至没有编码任何东西。所有这些问题都为我们提供了我们正在建设的背景，条件和限制。它们基本上决定了我们经营的区域。


为什么这些问题很重要？为什么我们关心这是一个新的应用程序还是重写？


好吧，如果这个应用程序是重写，那么我们需要理解为什么我们重写它。


重写一些东西很可能是一项昂贵的练习，因此通常有充分的理由。也许它的使用一些旧的技术无法适应更大的系统项目，也许我们需要增加新的功能，也许我们需要使它更容易被它的用户使用。也许我们需要让它更容易维护。


是的，维护非常重要。


我们可能已经编写了世界上见过的最令人惊奇的软件，但是如果没有人理解它是如何编写的，如果其他开发人员看到它并且吓跑了，那么很可能每一个小修复或改变都不会只是很长一段时间但很可能会引发问题。


我们可以做很多事情来涵盖其中的一些问题，并确保每个问题都有一个好的答案通常是一个很好的起点。作为开发人员，我们需要做的我们并不总是在维护代码。因此，我们可以处理基础：清洁代码，良好的命名策略，SOLID原则，测试以证明它的工作原理。


如果这些事情得到妥善处理，那么我们已经处于一个好的位置。


软件架构


从一开始就设计应用程序的体系结构是我们所关注的。它涵盖了系统的工作方式，一旦到位，即使不是完全不可能，也很难改变。


这就是我们开始的地方，我们了解一切可能如何工作，事物如何相互作用，子系统如何相互通信。做一些概念验证（POC）的小应用程序通常是一个好主意，看看一切是否真正按照我们认为应该工作的方式运行。


这也是我们可能决定实际上我们对某些方面知之甚少的地方，我们要么寻求帮助，要么学习如何去做。


知道何时做这些事情很重要。没有人知道一切，我们应该很高兴承认我们不知道的事情。


当我们知道我们不知道的时候，那就是我们学习的时候。那时我们才知道我们需要学习什么。作为一名开发人员，我们必须不断学习，有很多东西可以让人感到畏惧。当发生这种情况时，退一步回到基础通常是一个好主意。


有些人决定专注于某些方面，这很好，因为他们对某些事物有很好的了解。其他人喜欢更多的通才，所以他们知道很多事情。


这些方法都没有错。


你知道的越多越好。在做出任何决定时您将拥有更多选择，并且更容易解释您为什么首先做出这些决定。


还记得我们如何说软件开发是一项非常社交活动吗？它是，因为你需要与他人互动，你需要解释你的选择，阐明为什么某些事情应该以某种方式完成。这完全取决于沟通，所有这一切都是为了接受建议并能够发现一个好主意，即使它不是你的。


我想这会把我们推向一个非常明显的方向。了解软件开发中的社交方面，并将其用于您正在构建的任何内容的优势。如果你从等式中移开并看到更大的图景，那么很明显，目标是提供一些好的东西。你如何达成某些决定将不再那么重要。重要的是这些决定的结果和结果。


您当然可以说架构并不是那么重要，它将由您正在使用的框架来处理。例如，它可能类似于MVC。


这不是我所说的。


框架将为您提供一个起点，它将通过提供一些方法为您提供帮助。它通常非常注重特定类型的活动。这只是你正在建设的一小部分，所以从一开始就理解这一点很好。


但是，框架不会包含与其他应用程序的依赖关系和交互。您甚至可以使用多个框架来构建某些东西。也许您将实体框架添加到组合中，也许您也可以添加其他框架。现在你已经有了很多框架，你需要让它们很好地一起玩。


系统的体系结构与这些事物分离。如果你以某种方式想象事物，它会有所帮助。即使在白板上画画也会创造奇迹，因为它可以帮助你看到差距。


态度


是指解决方案，而不是指问题。


软件开发是一项社交活动，您将与他人进行大量互动。让你的自己掌控并处理大量的问题是很容易。因为你不必向别人解释，你为什么这么做，但这通常会导致混乱。这种态度对项目不利。


开发人员之间会缺乏信任，然后他们就会只做自己的事情，如果你不让他们了解情况（他们为什么要这样做？）。在你知道它之前，整个事情慢慢走向失败，因为每个人都以自己的方式做事而不考虑项目的好处。


这就是工匠心态最关键的地方。项目是第一位的。这意味着您需要相应地考虑更多的事情，代码的优化，图片的加载优化等


快速修复与正确的修复


有时人们能力比较强，能快速的修复bug，完成工作。通常这样做是为了挑选出具有负面影响的小东西，通常是在系统投入生产时。


在更大的项目中发生的事情是，快速修复了bug，但是我们没有深究问题造成的根本原因。我们只是用了临时解决的方式，这样造成了项目后期的维护困难


作为工匠，我们需要了解这些事情。我们不仅仅是一台机器，可以整天拿着比萨饼和可乐来制作代码。


这是一项高度逻辑性和创造性的活动，其中经验很重要，您可以在其中发现某些事情的发展方向。


是的，有时您可能需要应用快速修复来阻止亏损，如果系统由于某个问题每小时损失数百万，那么一定要尽快修复它。一旦你完成了这个，确保有适当的修复，不要让这些快速修复最终导致项目的崩溃。


这归结为是花时间了解问题并提出一个确保问题不会再发生的修复。这当然是一个更大的讨论的一部分，因为我们通常有截止日期，因为我们只有这点时间可用。然而，能够阐明和解释问题，忽视问题的解决方案和危险是至关重要的。我们不只是为了编码，我们在那里分享我们的经验并防止这些事情发生。


在某种程度上，态度是一个有趣的。


这是因为如果你被一群有类似方式看待和理解事物的人所包围，这会更好。但即使你不在这样的地方，也许你应该说明为什么这种态度有效并且有助于构建更好的软件，也许你可以引领改变的方式。


你想要的最后一件事就是妥协并接受平庸，因为产品最终会成为平庸！


了解要求并填补空白


通常，我们想要的实际要求，是很难轻易大成的


我们举一个简单的例子。您的一个要求是使用用户名和密码构建登录页面。这有多难？包含两个字段和一个按钮的页面。


好吧，走着瞧。


用户名是电子邮件地址，电话号码还是别的？


当您按下“登录”按钮但未填写用户名时会发生什么？


如果密码丢失怎么办？


你在哪里显示错误消息？


用什么颜色显示错误消息？


是否应该有注册页面的链接？


忘记密码链接怎么样？


忘记用户名怎么办？


你如何与任何人联系以恢复它？


你如何确保不会成为SQL注入攻击的受害者？


如果用户非常快速地点击“登录”按钮50次会发生什么？


问题清单越来越大。这只是一个登录页面，想象一下构建比这更复杂的问题时的问题数量。


这就是我们通常所做的事情，我们会查看一项工作并开始提出问题以确保我们构建正确的事物。我们想到任何可能出错的事情，我们借鉴过去的经验。一旦我们将系统置于实际状态，一旦我们进行安全审核，这有助于澄清在构建任何内容时我们应该问什么样的问题。经验真的很重要！


不要附加代码








这是一个有趣的。很容易接受我们的代码，甚至对我们做出的选择采取保护。其他人不可能理解我们正在做的事情的美丽，对吗？


嗯，这就是事情。在现实世界中，没有人会关心。有一个简单的事实，代码需要执行一个函数，就是这样。要么它做了，要么没做。


由于没有过于依恋，我们允许自己看到缺陷和缺点。


它允许我们进行更改而不会感到遗憾。它让自我离开了门，然后我们可以专注于重要的事情，这是商业价值。这在我看来非常重要，代码并不存在于并行世界中，它只需要执行一个功能并提供价值，也许可以节省一些人的时间，也许它比以往任何时候都更快，比以往更快。总是有一个原因，为什么代码存在，如果原因消失，我们可以简单地删除它，没有任何第二个想法。


首先关注商业价值！


清洁代码


我们已经将编程视为社交活动。有许多重要的事情，能够支持和维护代码库，就在最顶层。无论我们是大团队还是单人团队的一员，我们仍然需要思考当我们编写的代码投入生产时会发生什么。


我们能在几个月或几年内看一下它还能理解它吗？


其他人是否能够接受并维护它，修复错误，甚至可能添加新功能？


我们都害怕遗留代码，但如果我们停下来思考一下，我们很快就会发现，我们编写的每一段代码都会在投入生产的那一刻成为遗留代码。我们认为这个闪亮的新框架将解决我们所有的问题，给它六个月的时间，这将是旧的新闻，而其他一些东西将成为本月的风格。


考虑到所有这些因素，更多地关注我们编写代码的方式是有意义的。


那么干净的代码到底是什么？好吧，为了理解一些代码，我们需要能够像读一篇文章一样并理解它。这意味着我们的变量需要具有适当的名称。


例如，而不是


_uRep =whatever


我们可以使用类似的东西：


_userRepository =whatever


如果我们查看一行代码并且无法快速掌握它的作用，那么就该改变它了。让我们不仅想到这个时刻，当我们头脑中的一切都清晰时，让我们想想在几个月内当所有背景消失并且我们从头开始时会发生什么。


因此，良好的变量名称和良好的方法名称可以帮助理解代码，并在时间到来时更容易维护它。


另一个好方法是避免使用智能和复杂的一个衬垫。我们都知道它们是什么 - 那些美丽的结构在很多方面做了很多。分解，让它看起来简单，易于阅读和理解。


希望到现在为止，出现了一个明确的模式; 保持简单从未如此重要。


开始应用一些SOLID原则。我们不需要盲目地应用所有东西，只需要有意义的东西。例如，单一责任原则是一个很好的开始。这意味着我们编写有一个目的的类和一个做一件事的方法。


这允许我们编写可测试的代码，这对于将来的维护非常重要。


我认为现在是时候停止证明为什么测试代码很重要了。这是常态，而不是例外。大部分时间我们都没有这样做，因为我们有截止日期，没有足够的时间来实际编写测试。这将我们推向下一部分。


尝试成为一名工匠心态的程序猿


我们软件开发人员需要开发性的让别人测试我们的代码。我们不应该证明为什么我们会花时间为我们的功能添加自动化测试，我们就这么做。当然，我们可以解释这实现了什么，但不能作为理由，我们测试的是因为这有助于产品，因为我们是工匠，因为我们知道我们在做什么。当有人要求我们估算一件作品时，我们会考虑测试。


测试是我们工作的一部分。


没有人告诉水管工如何做他的工作，他们使用它的经验来处理事情，我们也是如此。所以，让我们停止证明我们知道需要做什么，让我们去做。因此，产品会更好。


这让我们回到了行业的切入点。正如我所说，让我们成为解决方案的一部分而不是问题。我们知道偷工减料并没有帮助，我们知道不断引入技术债务最终会带来巨大的成本，因此尽可能做到最好尽量减少它。


这是您正在进行的当前项目的快速测试。看看有多少技术使用，有多少框架，有多少库。


可能会出现一些令人讨厌的惊喜。


有多少人在那里，因为有人想要使用特定的东西？


有多少个库是因为有人需要做一件事，在一个地方而不是写一个小方法，他们引入了一个全新的库来完成这项工作？


如果我们将焦点从我们自己转移到项目本身，这一切都可以解决。只有在有明确，持久的利益的情况下才能添加新的东西。


测试








我们已经知道编写可测试代码然后添加测试以实际证明它按预期工作的好处。


想象一下，这些单元测试运行得非常快，因此可以确定系统以可预测的方式运行。想象一下能够重构而不必担心你可能会破坏某些东西。想象一下，获取错误报告，编写一个突出显示错误的失败测试，然后修复代码以使测试通过。想象一下，还有一个测试可以保证你刚才修复的特定bug不再显示它的丑陋头脑。


这些都是好处，但等等，还有更多！


想象一下，每次发生变化时都不必继续测试整个系统，想象维护阶段会更短，更便宜，因为您不再需要这么多的手动测试。我们需要准备好阐明为什么这种工作方式更好，即使是在我们之间，甚至对于可能不会以相同方式编码的其他开发人员。这有助于将每个人提升到更高的水平，以现代的方式工作，享受改变的工作流程，而不是在发布即将到来时无数的额外时间跑来跑去。


代码安全性






我们现在正在进入那个没有人喜欢谈论的领域，这就是安全问题。由于某些原因，这似乎是我们最终总是在考虑的事情。


我们如何构建安全代码？这不是那么微不足道，但它需要开发人员自己思考，因为大多数时候这个领域不会被需求所覆盖。因此，我们需要确保我们刚刚编写的漂亮登录页面确实是安全的。


我们是那些看到这样的网址的人：www.baidu.com / user-details / 1。并且自己想一想，“嗯，我想知道如果我在URL中用1替换1并且输入”，会发生什么？“ 我们确保不暴露敏感数据。我们确保构建一个只能由目标受众访问的API，而不是其他任何人。


这是一个巨大的主题，值得一篇文章。现在，因为我们有一个工匠的态度，我们可以查看我们的登录页面并开始思考，我们将如何破解它？也许我们去阅读一些关于道德黑客攻击，获得一些想法，看看世界的另一面如何运作并试图破解我们自己的代码。它不会是完美的，它不会是100％，但它是一个开始。


专注于改变的事物


我们都希望研究最新和最伟大的事物，但这并不总是可行的。


无论是最新的框架，最新版本的东西，也许是一个新的数据库系统，也许是一种新的API类型，无论它是什么，我们都想要它！这不一定是坏事，最好跟上最新的发展。然而，也意识到需要保持相对的平衡。


通过快速地从一件事跳到另一件事，我们可能无法深入学习任何东西，我们最终只能获得表面知识。这绝对不是一件好事！


有很多产品用语言和版本编写，这些产品已经有好几年了。有人仍然需要维护甚至升级它们。企业很少会接受完全重写的应用程序，它可以很好地完成工作。这是预期的，我们需要了解这一点。是的，即使在较旧的产品中也总会有一些我们可以改进的东西，如果我们能够提供足够的理由，那么某些变化就会发生。


这完全取决于我们向客户解释变更的价值。它不是用技术语言完成的，非技术人员必须理解它。这完全取决于沟通技巧和商业价值。


结论


我们需要不断学习，不断充实自己。如果我们在一个由十个开发人员组成的团队中，我们帮助他们每人提高10％，那么对每个人来说，总计100％。


我们自己的价值并不是我们带到桌面上的唯一价值，我们可以为别人做些什么甚至更多。


我们需要更加相信我们的技能并负责，确保正确的事情完成，确保仍然存在平衡，我们可以构建能够经得起时间考验的项目