プロフェッショナルとは

1792viewsNaosukeNaosuke

このエントリーをはてなブックマークに追加
Clean Coder プロフェッショナルプログラマへの道

プロのあり方

プロが備えるべき最低限のこと

  • デザインパターン: GOFの24のパターンについて説明できる。POSAのパターンを実際に使える知識がある.
  • 設計原則: SOLID原則を知っている。コンポーネントの原則を熟知している。
  • 方法論: XP・スクラム・リーン・カンバン・ウォーターフォール・構造化分析・構造化設計を理解している。
  • 規律: TDD・オブジェクト指向設計・構造化プログラミング・継続的インテグレーション・ペアプログラミングを実践している。
  • 成果物: UML・DFD・構造チャート・ペトリネット・状態遷移図・状態遷移表・フローチャート・デシジョンテーブルの使い方を知っている。

仕事

  • 自分が効果的に働ける残業時間を知っている。
  • 労働のコストがどれだけか知っている。

責任

  • バグのないものなんかできなくても、責任は取らなきゃいけない。
  • 守れないような約束はしない。
  • 見積もりに願望を含めない。
  • プレッシャーの中でも落ち着いて判断ができる。

能力

  • (ソースコードを)来た時よりも美しくする(ボーイスカウトの規則)。
  • 給料が支払われないときに練習することで、よりよい給料につなげる。
  • 10分間の朝のウォーミングアップや夕方のクールダウンとして型を1〜2つやる。
  • 仕事でC++を使っていたら、Pythonのプロジェクトを探して貢献する。

プロの手法

TDDの3原則

  • 失敗するユニットテストを書くまでプロダクションコードを書いてはいけない
  • テストを失敗させる目的以外でユニットテストを書いてはいけない。なお、コンパイルできないのも失敗に含まれる。
  • 失敗しているユニットテストが成功するまで他のプロダクションコードを書いてはいけない。

テスト

  • 自動テストがあればコードを変更するのは怖くない。
  • 先に書くテストは攻撃、あとで書いたテストは防御。
  • ユニットテストはドキュメント。

継続的インテグレーション

  • ソフトウェアは適切なコストで変更できなければいけない。
  • 早すぎる要求仕様の詳細化は、不確定性原理によって無効にされる。

原則

  • 練習や規律を忠実に守るのが最善の方法。
  • 会議は明確な議題・時間割・目標がなければいけない。
  • チームがすべてのコードを所有すべき。

ツール

  • FitNesse
  • 内蔵されたLispのおかげでEmacsはこれからあと何十年も生き残る
  • EmacsはIDEと張り合うことはできない
  • EclipseとIntelliJ
  • IDEは、強力なコード操作の機能を持つ
  • TextMateは学習曲線が緩やかで、操作が直感的
  • Pivotal Tracker
  • Lighthouse
  • Jenkins
  • CppUTest

関連まとめ

本のまとめカテゴリー


コメントを書く