プログラミングの作業に何の価値も見出せなくなってしまったd金魚による日記 このページをアンテナに追加 RSSフィード

 iTunes Music Store(Japan) なかのひと あわせて読みたいブログパーツ
|

0001 | 00 |
2004 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 00 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2008 | 01 | 02 | 03 | 05 | 07 | 08 | 09 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 |
2010 | 03 | 04 | 06 | 07 | 09 | 10 | 11 |
2011 | 01 | 02 | 10 |
2012 | 04 |
2013 | 01 | 05 | 06 | 07 | 08 | 10 |
2014 | 02 | 03 | 05 | 09 |
2015 | 04 |
2016 | 09 | 11 | 12 |
はてな一覧
アンテナに追加
私のアンテナ
私のダイアリー
私のアーカイブ
私のアイデア
私のブックマーク
私のグループ
私のキーワード
ニュース系、今まで続いているシリーズモノの読み物
dKingyo Utility Toolkit Projectのリリース情報
やっぱり暗号化は大人の味(笑)
プログラムのパッキング方法を調べよ
ココが厳しいよMinGW
ライブラリアン通信
ゲームプログラミングどうしよう
CRCについて
ビット演算練習
d金魚の今更Ajax
Windows Tips
VC6 Tips
Win32 WTL Tips
Ruby for C++ User
Ruby Tips
今日のRubyで嵌った事
正規表現PIECE
書きかけ
続く・・・

私のダイアリーの人気記事
新しくブックマークされた記事


あまり、役に立たなそうな個人的に調べた情報や妄想に耽った事、今 勉強している事ヒソヒソと公開していたりします。 | 登録してくれている方々 | d金魚にメール | 当サイトは640x480の画面解像度に対応しています。
日記へのリンク、アンリンクはフリーですが、selfタグのついている部分のコンテンツの引用はご遠慮願います。ご協力よろしくお願いします。


 | 

2013-08-17 アプリを作る際の手順論

[][]アプリを作る際の方法論ではなく手順論 アプリを作る際の方法論ではなく手順論を含むブックマーク アプリを作る際の方法論ではなく手順論のブックマークコメント

 方法論は色々あると思うが、手順のみということで手順論を示していこうと思う。この手順に沿っていないと人的リソースの出入りでアプリ開発のノウハウ散逸してしまうのでそれを防止するためである。今のこのエントリーではまだとりあえずの私見としての草稿段階であるしかし、手順についての有用な手法を持っていない人には役に立つであろう。

1.コーディング規約を決める。

例:

オブジェクト指向で作る。『インターフェース』と『共通の機能は基底クラス』、『派生クラス』の分離を行なっておくこと。

・実装を変える際は正常に動いているものは残しておいて、別のクラスに実装して入れ替える。(すなわちストラテジーパターン

・状態遷移はアクセプタFSMベースにする。

エラー処理の方法VM言語場合は処理速度的に例外エラーを返した方が良い。Native言語場合アーキテクチャに寄るが、C++場合は処理速度的には基本的に戻り値エラーを返す。」

ビジネスロジック部(アプリ固有の状態遷移部)とライブラリ部(アプリで使用する機能、その他共通する機能群)の分け方を明確にする。

ビジネスロジックの実装はストラテジーパターンで簡単に入れ替えが出来るようにしておく。

コメントは〜〜のように書くなど(英語か?日本語か?)doxygenjavadocスタイル準拠させるか?など 特にifやswitchなどの条件分岐の理由をコメントで残しておくとソースコードがぐっと見やすくなる。

2.簡単な仕様書ドキュメントとして残す、書いておく

例:

テスト環境、本番環境コーディング環境などの作り方、設定方法などのノウハウ。(これら3つの事を丁寧、親切に記していないとかなりのタイムロスが起こる事がある。)

必要機能と実装優先度

ユーザーから操作の詳細

エラーが起こった際のチェックする所やエラー原因の特定方法ログファイルパス名など

コード内の構造ソースコードファイルの説明など

Subversiongitなどのコード共有場所など

アプリに使用する機能のついての所感や多数のソリューションがある中での採用理由、メリットデメリットなど

以下3〜5は必要に応じて横断的に行う。

3.テストケースの実装

・要するにTest Driven Developmentである。正しいテストケースの無いプロジェクトは人的リソースの出入りによって炎上する。

フルスクラッチ場合このテストケースを作る際にインターフェースエラーチェックの機能を実装する事が多い。

4.機能の実装

・要するにライブラリ作りであるライブラリを作り終わったら前に作ったテストケースを用いてテストして不具合バグが無くなるまでしっかり作ろう

5.ビジネスロジックの実装

・ある程度の機能が実装できてきたらビジネスロジックを実装しよう。ビジネスロジックテストケースも作ってテスト自動化させよう。

6.ユーザー視点からテスト

ユーザーが使う視点から実際にアプリを起動させて動作確認をしよう!動作確認リストをこの時に作ったほうが良い。(3・4・5のうちに色々あって2で作ったユーザー視点での動作確認リスト時代遅れになっている可能性が高いから

エンドユーザーテストしてもらって色々と改善箇所を洗い出そう。

7.ユーザー用、開発者用のマニュアルを作ろう

マニュアルがなければどんなに高機能アプリでも意味もワケも分からない無用長物に成り果ててしまうでしょう。

ユーザー側は画面の画像と矢印などを使って懇切丁寧に

開発者側は別の言語や開発環境を使っている人が見ても分かるように書いておく。既知のバグリストと決定稿の仕様書もつけておく。

・6のエンドユーザーテスト結果を元に厳密な仕様書テストケースを作る。必要があれば3〜5に戻って改修、作り直し

8.厳密なテストケースを通過したらリリース

7で洗いだした厳密なテストケースを通過したらリリース可能なクオリティーになっているのであとはリリースを待つだけ!

トラックバック - http://d.hatena.ne.jp/studiokingyo/20130817
 | 
Program | Debug | dKingyo Utility Toolkit | library | D言語 | 御本とか | 備忘録 | テクニック | WayBack | 格言 | 英語 | 他力本願 | news | software |

デースケドガー