作者：Timo Heinapurola

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

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

Geek And Poke Code Quality(from fk81.de)

创建原型阶段

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

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

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

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

坚持质量标准

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

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

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

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

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

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

框架

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

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

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

实用建议

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

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

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

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

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

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

总结

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

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

代码质量的一个最重要层面就是优秀而清晰的框架。这包括任何来自组件交互、编码惯例的东西。它组成了团队成员之间的交流基础，并令代码更易可读性。（本文为游戏邦/gamerboom.com编译，拒绝任何不保留版权的转载，如需转载请联系：游戏邦）

Prototyping and Code Quality

by Timo Heinapurola

Prototyping is a popular method for getting a feel for the core features of a given application. It is often used as the first step when your company is looking into a new prospect with a lot of uncertainty. The method relies on short iterations to quickly verify whether a set of new functionality is worth investing in.

In this article I focus on how code quality is related to a project developed using prototyping. I will first go through some of the main stages of such a project followed by some pit falls that you should avoid when moving into actual production.

The prototyping phase

Let’s imagine you are in the following situation. You have a great idea for an application or a game and the competence to make it. The first stage of development is going to be research. You will start looking at competing products in order to see what their shortcomings are and whether you should tackle them in your product.

After you have figured out a suitable set of features and nailed the higher level vision of the product you can start prototyping. In prototyping you build one or more smaller applications in order to test the core features that were found to be central to your product.  This stage of development consists of a number of very small iterations where your primary goal is to implement features so that decision makers can try them out to see whether they work or not.

At this point in development it’s important not to focus too much on code quality and documentation. Code written for the prototype should be clean enough for you and other developers working on the prototype to be able to develop features with. Supporting a too high quality level slows down your work and does not add much value to the prototype. This is because, as will be discussed later in this article, prototype code is meant to be “thrown away”.

To minimize the amount of work being thrown away, the code should be as light as possible. This means using architectures and frameworks that allow flexibility and don’t lock you in on certain ways of working. For instance, if you are developing a game that is going to have an online component but the feature set you are currently prototyping does not require online play, you can safely omit the online part all together.

Moving on to quality code

Once you are ready to move into production with the software, I would recommend using the prototype as a reference more than an actual initial implementation. This is because you now have a rather detailed map of the path in front of you when it comes to implementing the prototype features in the actual product and keeping the prototype intact helps you navigate in the future.

Reimplementing the features in the prototype has multiple benefits:

You get to focus on code quality without the need to wade through messy prototype code.

The prototype code will remain as a standalone implementation without dependencies on systems that will now change during actual implementation.

You are practically forced to go through and review the algorithms and data structures developed for the prototype.

You have more than just design on paper as you know exactly how you CAN implement the application features. It’s now about making it work with cleaner code and on the required platforms and frameworks.

Architecture

When starting to develop the actual application you should first do some research on the platform and frameworks you have chosen to use and make sure your choices are still valid. You might want to draw a couple of images and write a few lines of design documentation that will lay out the base of your application architecture. Architecture documentation is important but you should not overdo it. I wrote earlier about documentation in general and I think it’s important to keep it on a sensible level. Architecture documentation, however, is the most important kind of documentation as it gives you the frames within which to work. It’s also very difficult to describe architecture in code commenting or code itself. This is because architecture defines aspects like naming conventions and component interoperability that are more global in nature.

The software architecture will follow you throughout the project. It forms the basis of the whole application, it’s form, if you will. This is why it should be clean and clearly communicated and all developers in the project should follow those same guidelines. Good architecture actually forms the basis of good quality code, which is why it deserves its own section in this article. If all code follows the same form it’s easier for everyone to understand the details when the form is already understood. This also leads to less buggy code as developers know instinctively what is happening and where, as you speak the same language with familiar words.

Once you have an idea of the software architecture you can start working on the actual code. Sometimes you will have to make modifications to the architecture during development. It’s not as frequent as making modifications to individual features due to requirements changes but it still happens. These changes should be clearly justified either by significantly improved code quality, performance or just making a crucial feature possible. Changes to architecture should not be made lightly. It’s like changing the constitution of the application, and constant changes will lead to chaos. You should also always modify the whole application to meet the new architecture definition. It’s not a good idea to have remnants of the old world lying around.

When developing the architecture of the application you should also consult people who are going to be developing the application with you. They might have ideas about the high-level implementation of the software. It’s much cheaper to take those ideas into account at this stage of development instead of incorporating them at a later point in time through architecture changes.

Practical tips

Keeping up code quality is a constant process that requires input from every single member of the team. This is why the whole team has to stand by the common guidelines. No single person should dictate developing the software architecture. It’s important to get feedback from all developers as they will spend all their coding hours using it. Minimizing aggravation minimizes the potential of bugs and makes you want to do a better job overall.

I would also recommend leaving the codebase in a better state than you found it in. This will eventually improve the quality and will not require anyone to use a couple of days to get things in order.

Syntax auto-formatting and refactoring in programming tools have been steadily improving making it easier to maintain common coding conventions. They might not be the holy grail and often do little in the form of naming conventions, though. You should always try and use the same terms everywhere in the code with method and property names being formed in the same manner. It might make sense to try and keep an appendix on used terms but I personally would recommend just getting to know the code base and getting a feeling of the different words being used and then just trying to use them in your own code. Although, conventions like always using the word “Is” in front boolean typed properties should be documented in the naming conventions part of the architecture documentation.

Peer review is also a good way of spotting potential issues in code. If done right, you will get valuable feedback on your code. Peer review also has the added benefit of sharing information about the code base. Features implemented by you will be seen by your peers and wise versa. Having someone review your code will show you how understandable the code actually is. It also pushes you to write code you can feel proud of.

In addition to peer review I personally recommend going through your code changes just before pressing the commit button. You should perform a self review, if you will. This way you might recall situations where you thought you would like to do something but had moved on forgetting to write down what it actually was. You also have time to check whether the code is legible, remove debugging code and add commenting if required.

Perhaps the most important tip I can give you is that you should always take code quality seriously. It makes sense from a business point of view but it also helps you as a developer to make your days that much easier and less frustrating!

Summary

Prototyping allows you to figure out what might work and what doesn’t. You should not overdo code quality in this phase as prototype code should be light and quick to write. The application prototype should also be used more as a reference than an actual basis to develop the final product on.

Good quality code, especially in the final product, can sometimes mean the difference between success and failure. Code that is written with predefined conventions and following structures that everyone agrees on makes it easier for new people to get into working with the system while also minimizing misunderstandings and thus those pesky bugs.

The most important part of code quality is a good and clean architecture. This includes anything from component interactions to coding conventions. It forms the basis of communication between teammates and makes code much more readable.（source：gamasutra）