关于创建原型与保证代码质量的实用建议

创建原型是让人们获得某一应用核心功能的一个惯用方法。它通常是作为你的公司打算需要一个具有许多不确定性的新理念时的第一个步骤。其方法有赖于短暂迭代，以便迅速确认开发者是否值得投入一系列新功能。

在本文我将专注于讨论代码质量与使用创建原型方法开发项目之间的关系。我将从这种项目的几个主要阶段入手，并讨论你在实际制作过程中应该避开的几个误区。

Geek And Poke Code Quality(from )

创建原型阶段

让我们假设你处于以下情况。你有一个很棒的应用或游戏理念，并且有能力令其实现。那么第一个开发步骤就是进行调查。你要开始查看竞争产品，以便找到他们的短处，以及你是否该在自己的产品中克服这些问题。

在你想出一套可行的功能，并且敲定产品的更高级版本之后，你就可以开始创建原型了。在创建原型阶段，你可以制作一个或更多个小型应用，以便测试那些将成为产品核心的功能。这个开发阶段包含一系列非常小型的迭代，你的主要目标是执行功能，以便决策制定者试试它们是否可行。

在这个开发节点上，不可过于关注代码制作和文档。为原型编写的代码应该足够清晰，以便你和其他开发者在这个原型的基础上开发功能。支持过于高级的关卡可能会降低你的工作进程，并且不会为原型添加多少价值。这是因为，原型代码本来就是为了“被抛弃”。

为了最小化被抛弃的工作量，应该尽量保持代码的轻便性。这意味着你应该使用具有灵活性，不会将你局限于特定工作方式的框架和结构。例如，你在开发一款拥有一个在线元素，但你目前在创建原型的功能集并不需要在线体验，你就可以忽略这所有的在线功能。

坚持质量标准

当你开始进入软件的制作阶段时，我建议你将原型作为一种参照而不是一种真正的初始执行标准。这是因为在真正的产品中执行原型功能时，你已经拥有一个相当详细的路径，保持原型的完整性有助于你未来的导航。

在原型中重新执行功能具有多种优势：

1.你无需编写大量原型代码就能保证代码质量。

2.原型代码将保持独立执行，无需依赖那些将在真正执行过程中发生变化的系统。

3.你会被迫检查为原型开发的算法和数据结构。

4.你绝不能只是纸上谈兵，因为你清楚自己该如何执行应用功能。现在要用更清晰的代码，并且要在所需平台和框架上执行操作。

框架

当开始开发真正的原型时，你应该首先调查你所选择使用的平台和框架，确保你的选择仍然有效。你可能会想绘制一些图片，并撰写几行将奠定应用框架基础的设计文件。框架文件虽然重要，但你不可以过分行事。我通常都会早点撰写整体文件，我认为有必要将其保持在合理水平内。框架文档是最重要的文件，因为它能够让你确定开发框架。用代码注解或代码本身来描述框架也非常困难。这是因为框架定义了命名惯例和组件互用性等更为全局性的层面。

软件框架将跟随你贯穿整个项目。它形成了整个应用的基础。这正是为何应该保持它的整洁性以及传达清晰性，项目所有开发者都应该遵从相同规则的原因。良好的框架实际上构建了高质量代码的基础，这正是我单独将其撰写成文的原因。如果所有代码都遵从相同的形式，那就更易于所有人理解其中细节。这还可以产生更少的漏洞代码，因为开发者本能地清楚发生了什么情况，因为你们使用的是大家熟悉的语言。

当你有一个把软件框架的理念时，你就可以开始撰写真正的代码。有时候你在开发过程中得做一些调整。这并不像因为需求变化而需针对个体功能做调整那样频繁，但这种情况仍然会发生。你可以通过极大优化代码质量、性能或只是令一个重要的功能具有可行性来鉴定这些变化。框架的变化不应该是无足轻重的。这就好像改变应用的成分，而不断变化则会导致混乱。你应该一直调整应用使之符合新框架定义。让旧世界的残余势力弥留并不是一个好主意。

实用建议

保证代码质量是一个需要团队每个成员持续输入的过程。这正是为何整个团队都必须坚持普遍指导原型的原因。没有一个人能够决定软件框架的开发。应该获取所有开发者的反馈，因为他们会投入自己所有的编码时间来使用它。最小化恶化可以最小化出现漏洞的可能，也会让你的整体工作更顺利。

我还推荐你令代码库处于更好的状态。这会最终优化质量，也不需要任何人花上数天时间让一切井然有序。

编程工具中的语法自动格式化和重构会持续优化，以便更易于维持普遍的编码惯例。但它们可能不是最棒的方案，通常在命名惯例的形式上无甚作用。你应该总是尽量在代码中使用相同的术语，令方法和性能名称以同样的形式出现。你可以试着在二次术语中保持附录，但我个人建议你只要知道代码库，了解不同词语的使用，并尝试在自己的代码中运用它们即可。不过，像总是在布尔型性能之前使用“is”的这个惯例就必须记录在框架文档中的命名惯例中。

同行评审还是发现代码潜在问题的一个好方法。如果执行得当，你就会获得关于自己代码的宝贵反馈。同行评审还可以增加关于代码库信息共享的好处。你的同行可以看到你所执行的功能，反之亦然。让某人来评审你的代码可以让你了解自己的代码的可理解性如何。这还可以促使你去编写足以让你自豪的代码。

除了同行评审之外，我个人还推荐你在确认提交之前再浏览一遍自己的代码。你应该实行一次自我审查。这样你可能就会回忆起你曾经想做某事，但却忘了写下来究竟是哪件事，之后就将其遗忘了的情景。你还有时候检查代码是否易懂，移除调试代码，并在必要的时候添加注解。

也许这里最重要的建议就是，你要一直重视代码质量。从商业角度来看，这合乎情理，但它同时也可以让开发者的工作更轻松无压力!

总结

创建原型可以让你明白哪些可行和不可行的做法。在此阶段，你不应该在代码质量上浪费过多精力，因为原型代码必须简单而容易编写。应用原型应该更多作为一种参照，而非开发最终成品的真正基础。

高质量的代码，尤其是在最终成品中的代码，有时候就能决定成功与失败。用既定惯例编写的代码以及人们都认同的框架可以让新人更容易融入系统，并同时最小化其中的误解，从而减少漏洞的产生。

代码质量的一个最重要层面就是优秀而清晰的框架。这包括任何来自组件交互、编码惯例的东西。它组成了团队成员之间的交流基础，并令代码更易可读性。

中山注册公司章程

企业并购顾问

深圳工作签证条件