これ僕.com:行動分析学マニアがおくる行動戦略

意図と行動のギャップから生じる「不自由さ」への挑戦。果たして僕たちに自由はあるのか?

The 実装技術!

開発の現場 特別版 vol.001 The 実装技術!

開発の現場 特別版 vol.001 The 実装技術!


"技術"をメインに据えたムック本。

パート1. プログラミング&テスト 実装力UPのツボ
パート2. エンジニア業務効率化のためのツール&テクニック集
パート3. 上流エンジニアリングの基礎知識と勘所

パート1の「明日からできるコーディング上達法(arton氏+宇野るいも氏)」は、エンジニアだったら必読じゃないかと思った次第。特に「昨日の常識は今日の非常識」というコラムちっくなのが良かった。常識とされているコーディングルールに対して、これは「これこれこういう理由だからOK(NG)」という著者の見解と共に、それぞれのルールが有効(または無効)であることを示している。理由が明快なので、いいなぁ。

メソッドの戻り値にnullを使わない → 有効
フィールドはprivateとする → 無効

などなど。
あと、「要所を押さえて、実用的なテスト仕様書を作成する!(中村 秀剛氏+マーク・マッギー氏)」に出てきた

テスト仕様書とは、皆の想いや現場のノウハウが詰まった「宝石箱」である。

というのは名言だと思った。
他にもパート2の正規表現、パート3のアーキテクチャパターン、データベース設計の記事らも必読だ!


以下、自分用メモ。

コーディングルール

  • 名前付け
    • ×: kokyakua, kyokyakub
    • a, bの方がまだマシ(↑のは間違えやすい)
  • 説明的なコードを作るルール
    • 分かりやすいクラス名、メソッド名、フィールド名を付ける
    • 変数の命名は意味的な区別を重視する
    • 変数のスコープは短く取る
    • メソッドは20行程度、ブロックは3行程度に収める
  • 上達のために
    • 折に触れて良質なソースコードを読むようにしてください。こうした経験を積んでおくと、好ましくないコードを見たときに自然に「悪い予感」を感じるようになります。

品質基準とテスト

  • 優先順位
    • 単純にテストするのではなく、機能または要件に優先順位をつけ、その優先順位に従ってテストするのがQCDのバランスからいって理想的でしょう。
  • 不具合
    • 不具合の検出はテストではできない。
    • 不具合がないかどうかは、リリース後でなければ正しい判断はできない。
  • 品質をリスクとして考える
    • ビジネス上のリスクを考えてから、品質にどの程度のコストをかけられるか検討する
    • ビジネスリスクから、テストの優先順位を決める
      • 機能の重要度とビジネスリスクをそれぞれ5段階に設定
      • テスト要件の重要度 = 機能の重要度 × ビジネスリスク

テスト仕様書

  • 中止基準
    • テストフェーズごとに、この状況だったらテストを中止すべきという「中止基準」を持っておく
    • 対応策と再開基準もワンセット
  • アーキテクチャに合わせたテスト手段
    • ソフトウェアの構成要素ごとに、「この検証内容をこの手段でテストする」というのをマトリックスにしておく。
  • 「基本から学ぶソフトウェアテスト」より
    • テストドキュメントはテストの技術的な面で作業を容易にする。
    • テストドキュメントはテスト作業及びプロセスに関するコミュニケーションを改善する。
    • テストドキュメントはテストプロジェクトの組織、計画、そして管理に関する骨組みを提供する。

フレームワーク

  • プロダクトが選択されたなら、好むと好まざると、アーキテクトはそのプロダクトの設計思想を正しく理解することが大切。
  • 重要なのは、プロジェクトとアプリケーションフレームワークの思想に大きなギャップが無いことです。

データベースのセキュリティ設計