Incremental Development We’ll be developing this application incrementally. We won’t attempt to specify everything before we start coding. Instead, we’ll work out enough of a specification to let us start and then immediately create some functionality. We’ll try ideas, gather feedback, and continue with another cycle of minidesign and development. インクリメンタル開発 このアプリケーションは、段階的に開発していきま す。コーディングを開始する前にすべてを指定 (Specify)しようとはしません。そのかわり、いく つかの機能をすぐに作り始められるように、十分な 仕様を決めておきます。アイデアを試し、フィード バックを集め、ミニ設計と開発のサイクルを繰り返 します。
このスタイルのコーディングは、常に適用できるわけ ではありません。アプリケーションのユーザーと密接 な協力関係を築く必要があり、フィードバックを得な がら進めていきたいからです。間違うこともあるかも しれませんし、クライアントが最初はあるものを要求 していたのに、後になって違うものを要求してくるこ ともあるかもしれません。理由は何でもいいんです。 間違いに早く気付けば、その分修正費用も安く済む。 このように、開発スタイルには変化がつきものです。 This style of coding isn’t always applicable. It requires close cooperation with the application’s users, because we want to gather feedback as we go along. We might make mistakes, or the client might ask for one thing at first and later want something different. It doesn’t matter what the reason is. The earlier we discover we’ve made a mistake, the less expensive it’ll be to fix that mistake. All in all, with this style of development, there’s a lot of change as we go along.
そのため、私たちが考えを変えたときにペナルティを 受けないようなツールセットを使う必要があります。 データベースのテーブルに新しいカラムを追加したり、 ページ間のナビゲーションを変更したりする必要があ ると判断したら、コーディングや設定の手間をかけず にそれを実行できるようにする必要があります。この ように、Ruby on Railsは変化への対応に優れていま す。理想的なアジャイル・プログラミング環境なので す。 Because of this, we need to use a toolset that doesn’t penalize us for changing our minds. If we decide we need to add a new column to a database table or change the navigation among pages, we need to be able to get in there and do it without a bunch of coding or configuration hassle. As you’ll see, Ruby on Rails shines when it comes to dealing with change. It’s an ideal agile programming environment.
Along the way, we’ll be building and maintaining a corpus of tests. These tests will ensure that the application is always doing what we intend to do. Not only does Rails enable the creation of such tests, but it even provides you with an initial set of tests each time you define a new controller. その過程で、私たちはテストのコーパス(訳注:例文 の集合)を構築し、維持することになります。これ らのテストは、アプリケーションが常に私たちの 意図したとおりに動作することを保証するもので す。Railsはこのようなテストを作成できるだけで なく、新しいコントローラを定義するたびに、初 期テストのセットを提供してくれます。
Page Flow We always like to have an idea of the main pages in our applications and to understand roughly how users navigate among them. This early in the development, these page flows are likely to be incomplete, but they still help us focus on what needs doing and know how actions are sequenced. ページフロー 私たちは常に、アプリケーションの主要なページ についてのアイデアを持ち、ユーザーがその間を どのように移動するのかをおおまかに理解したい と考えています。開発の初期段階では、これらの ページフローは不完全である可能性が高いですが、 それでも、何をする必要があるかに焦点を当て、 アクションがどのように連続するかを知るのに役 立ちます。
Some folks like to use Photoshop, Word, or (shudder) HTML to mock up web application page flows. We like using a pencil and paper. It’s quicker, and the customer gets to play too, grabbing the pencil and scribbling alterations right on the paper. The first sketch of the buyer flow is shown in the following figure. PhotoshopやWord、あるいはHTMLを使って、 Webアプリケーションのページフローをモック アップするのが好きな人もいます。私たちは、鉛 筆と紙を使うのが好きです。そのほうが手っ取り 早いですし、お客さまも鉛筆を手に取って紙に書 き込むことができます。買い手のフローの最初の スケッチを次の図に示します。
It’s pretty traditional. The buyer sees a catalog page, from which he selects one product at a time. Each product selected gets added to the cart, and the cart is displayed after each selection. The buyer can continue shopping using the catalog pages or check out and buy the contents of the cart. During checkout, we capture contact and payment details and then display a receipt page. We don’t yet know how we’re going to handle payment, so those details are fairly vague in the flow. 極めて伝統的な方法です。買い手はカタログのページを 見て、そこから一度に1つの製品を選びます。選択され た各製品はカートに追加され、選択のたびにカートが表 示される。購入者はカタログページで買い物を続けるか、 チェックアウトしてカートの中身を購入することができ ます。チェックアウトの際には、連絡先や支払いに関す る情報を取得し、レシートページを表示します。決済を どのように行うかはまだ決まっていないので、これらの 詳細はかなり曖昧なフローになっています。
The seller flow, shown in the next figure, is also fairly basic. After logging in, the seller sees a menu letting her create or view a product or ship existing orders. When viewing a product, the seller can optionally edit the product information or delete the product entirely. The shipping option is simplistic. It displays each order that hasn’t yet been shipped, one order per page. The seller can choose to skip to the next or can ship the order, using the information from the page as appropriate. 次の図に示すように、売り手のフローもかなり基本的 なものです。ログインすると、商品の作成・閲覧や既 存の注文の発送を行うメニューが表示される。商品を 閲覧する際には、商品情報の編集や商品の削除が可能 です。 出荷オプションはシンプルです。まだ出荷されていな い注文が、1ページにつき1件ずつ表示されます。販売 者は、次のページに進むか、そのページの情報を使っ て注文を発送するかを選択することができます。
The shipping function is clearly not going to survive long in the real world, but shipping is also one of those areas where reality is often stranger than you might think. Overspecify it up front, and we’re likely to get it wrong. For now, let’s leave it as it is, confident that we can change it as the user gains experience using our application. 出荷機能は明らかに現実世界では長くは生きられ ませんが、出荷もまた、現実が想像以上におかし いことが多い分野のひとつです。今のところはこ のままにしておいて、ユーザーがアプリケーショ ンを使う経験を積んだら、変更できることに自信 を持っておきましょう。
Data Finally, we need to think about the data we’re going to be working with. Notice that we’re not using words such as schema or classes here. We’re also not talking about databases, tables, keys, and the like. We’re talking about data. At this stage in the development, we don’t know if we’ll even be using a database. データ 最後に、これから扱うデータについて考える必要があり ます。ここでは、スキーマやクラスといった言葉は使っ ていないことに注意してください。また、データベース、 テーブル、キーなどの話もしません。データについて話 しているのです。この開発段階では、データベースを使 うかどうかさえわかりません。
Working on the data diagram raised a couple of questions. As the user buys items, we’ll need somewhere to keep the list of products they bought, so we added a cart. But apart from its use as a transient place to keep this product list, the cart seems to be something of a ghost—we couldn’t find anything meaningful to store in it. To reflect this uncertainty, we put a question mark inside the cart’s box in the diagram. We’re assuming this uncertainty will get resolved as we implement Depot. データ図の作成作業をしていると、いくつかの疑問が 湧いてきました。ユーザーが商品を購入すると、購入 した商品のリストを保存する場所が必要になるため、 カートを追加しました。しかし、この商品リストを一 時的に保存する以外に、カートは何か幽霊のようなも ので、保存する意味のあるものが見つかりませんでし た。この不確実性を反映させるために、図中のカート のボックスの中にクエスチョンマークを入れました。 これは、Depotを実装していくうちに解決されるもの と考えています。
Finally, you might have noticed that we’ve duplicated the product’s price in the line item data. Here we’re breaking the “initially, keep it simple” rule slightly, but it’s a transgression based on experience. If the price of a product changes, that price change shouldn’t be reflected in the line item price of currently open orders, so each line item needs to reflect the price of the product at the time the order was made. 最後に、商品の価格を項目データで重複させているこ とにお気づきでしょうか。これは、「最初はシンプル に」というルールを少し破っているのですが、経験則 に基づいた違反行為です。商品の価格が変更された場 合、その価格変更は現在開かれている注文の項目価格 に反映されるべきではないので、各項目は注文された 時点の商品価格を反映する必要があるのです。
Again, at this point we’ll double-check with the customer that we’re still on the right track. (The customer was most likely sitting in the room with us while we drew these three diagrams.) ここでもう一度、お客様に正しい道 を歩んでいるかどうか、再確認しま す。(この3枚の図を描いている間、 お客さまはおそらく同席していたは ずです）。
Let’s Code So, after sitting down with the customer and doing some preliminary analysis, we’re ready to start using a computer for development! We’ll be working from our original three diagrams, but the chances are pretty good that we’ll be throwing them away fairly quickly— they’ll become outdated as we gather feedback. Interestingly, that’s why we didn’t spend too long on them; it’s easier to throw something away if you didn’t spend a long time creating it. さあコードを書こう さて、お客様との打ち合わせと事前分析が終わり、 いよいよコンピュータを使った開発です。最初に 作成した3つの図を元に作業を進めますが、フィー ドバックを得るうちに古くなり、すぐに捨ててし まう可能性が高いです。面白いことに、あまり時 間をかけずに作ったものほど捨てやすいのです。
We like to work with the customer so we can jointly agree on priorities. In this case, we’d point out to her that it’s hard to develop anything else until we have some basic products defined in the system, so we suggest spending a couple of hours getting the initial version of the product maintenance functionality up and running. And, of course, the client would agree. 私たちは、お客様と一緒になって、優先順位を決 めていきたいと考えています。今回のケースでは、 システムで基本的な部分をある程度定義しないと 他の開発が難しいため、まずはメンテナンス機能 の初期バージョンを稼働させるために数時間かけ ることを提案します。もちろん、クライアントも 納得してくれるはずです。
kawaguti
takumakume
junjikoide
elcuervo
gaelvaroquaux
yuhattor
nishiharatsubasa
yurihondo
prathamesh
junjunjunk
ramimac
th0x0472
sansantech
bermonpainter
smashingmag
addyosmani
destraynor
brianwarren
jacobian
quramy
62gerente
michaelherold
3n
malarkey
afnizarnur