アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き (単行本)
お盆休み前に読み終わってたんだけどブログを更新していなかったので。
「振り返り」時に使える技法を効果とともに紹介／解説してくれている。最初に効果的な振り返りの流れを定義した後、問題の抽出、解決のためのアイデア出し、チームとしての方針決定などで使える事例がたくさん載っています。自分たちでやり方を考えるのは大変だし、どういうときに効果があるのかもやってみないと分からないのが解説されているのはいいかも。
Pragmatic Programmer(達人プログラマー)シリーズの一冊だけど、プログラムの話はいっさい出てきません。業務全体に活用できる話かも。
今回がラスト
○第１４章 継続的改良
コマンドライン引数を解析するArgsクラスを題材に著者がリファクタリングをしていく過程を追体験できる。
最初に最終結果が提示されたため、それがスタート地点かと思ってびっくりしたが実際は真逆だった。
最初に最終結果を見せなければもうちょっと追って見る気力が出てきたのに。
○第１５章 JUnitフレームワーク
JUnitに対して著者がリファクタリングをしていく過程を追体験。
特記事項は無いので割愛
○第１６章 SerialDateのリファクタリング
OSSのライブラリに対して著者がリファクタリングしていく過程を追体験。
特記事項は無いので割愛。
○第17章 においと経験則
筆者によるチェックポイントのまとめ、よくまとまっていて、レビュー時に使えそうなので全て写経!
これで400ページ弱の本が読み終わったー！
○第８章 境界
内部コードと外部コード(3rd party製のライブラリとか)をうまくつなぐ方法について。
直接使うのではなく、ラッパを一つかませると良い。使用者側は特定のニーズに特化したインターフェースを求めるが、ラッパがあれば万事解決。
外部コードをつなぐときには、テストコードを先に書くと振る舞いの勉強ができ、かつ次回以降のアップデートでテストケースができるためオススメ。こうしたテストには「学習テスト」という名前があるらしい。
よい設計は過大な投資ややり直しを求めること無しに変更への対処を可能とする。自分たちのコードの広範囲が3rd partyの実装詳細に関する知識を持たないようにする。
○第９章 単体テスト
テスト駆動開発(TDD: Test Driven Development)の3大原則
テストコードと製品コードはほぼ同時に書く、テストコードの方が数秒先行するだけ。
きちんとやればテストコードの行数は製品コードの量に匹敵し、管理上の問題が必要になるぐらいのはず。
(同じぐらいの分量だと足りない気もするんだけど、適切な量はどれぐらいなんだろう・・・？)
テストも製品コードと同等の品質基準に従うべき。きちんとメンテナンスされ続ける必要がある。
テストがメンテナンスされてないと、新規コードを書く時間よりテストコードを書く時間の方がかかるようになってしまい、テストがされなくなってしまう。結果製品コードも腐ってしまう。
単体テストが以下の性質を実現する。
テストがあれば変更を恐れずできる。
テストに重要なのは何を置いても「読みやすさ」である。
製品コードほどの実行効率は必要ないことに気づく。読みやすさの工夫の余地が広がるはず。
きちんと整理された1つのテストは「構築ー操作ー検査」のパターンに合致するはず。
1つのテストでは1つの概念を扱う。
クリーンテストはF.I.R.S.T.の規則に従う
○第１０章 クラス
クラスは小さくなければならない。行数ではなく、1つのクラスが担う責務に着目して測るのが重要。
クラス名は責務を表した名前を付け、実装は単一責務の原則(SRP: Single Responsibility Principle)に従うようにする。
責務に着目するとクラスの分割がやりやすくなる。
クラス内のメソッドが操作する変数が多い方がクラスの「凝集性」が高い。
凝集性が高いとメソッド変数は互いに依存し合っていることになり、全体として1つのロジックをなすようになる。
○第１１章 システム
システムレベルでもきれいな状態に保つことは大事。
依存性注入(Dependency Injection)を考慮したフレームワークを使うといいよ。
最初から正しいシステムというのは神話、適切に関心ごとを分離して保守していくことでアーキテクチャも改善していくことができる。
モジュール化と関心ごとの分離は管理と意思決定を延期することができ、一般的に後で決断をする方が最善の情報に裏付けられた決断を行うことができる。
○第１２章 創発
単純な設計のための4つの規則
・全テストの実行
システムがテスト可能でなければ検証可能でない。
SRPに従ったクラスはテストも容易。
システムを完全にテストしようとすると依存性注入などのテクニックが自然と使われるようになり、より優れた設計を生み出してくれる。
コードを壊す恐れが減るため、リファクタリングも思い切ってできる。
・重複の排除
重複は余計な作業、余計な危険、不必要な複雑さを引き起こすため悪である。
大きな再利用を実現するため、小さな再利用を理解することが大事。
・表現に富む
書き手の意図が明快であるほど、別の人が理解しやすくなる。
書いた本人が書いた時点で理解できるのは当たり前、なぜなら解く対象の問題を深く理解しているから。
ソフトウェア開発の大半は保守なのでメンテナンスのしやすさの方が大事。
表現に富んだコードを書くには以下が重要
・クラスとメソッドを最小限にする
規則の中でも最も優先順位が低い。最小限にするあまり実際的でないルールや実装を行ってはならない。
○第１３章 同時並行性
きれいな同時並行プログラムを書くことは困難を極める。
それでも同時並行性が必要なときは以下の点に留意する。
同時平行性の大抵の問題は以下のいずれかか、組み合わせで表現できる。
問題を早期に発見して作り込まないようにする。
例によって括弧書きはコメント
○第５章 書式化
チームで仕事をしているなら1つの書式ルールで合意をとり、すべてのメンバーはそれに従うべき。
(当たり前のことだけどできてないことが多いコードが多い。ルールを文書化しておくと規約に沿ってないコードを書いたときも指摘しやすい。静的解析ツールのルール定義をしておくのもありかなと思う。)
コードの書式化は宗教戦争の引き金ではなく、長期にわたって保守容易性と拡張性を提供してくれるもの。
大きなファイルよりも小さなファイルの方が理解しやすい、当たり前のこと。
ソースファイル中の記述は抽象レベルが高いものが上、実装詳細が下にあることが望ましい。新聞と同じ構造。
縦方向で書式化に関連するのは空行の入れ方。パッケージ宣言、インポート文、各関数など別の概念のものは空行を挟むと良い。
逆に一続きの処理の間に空行がはいると読みにくくなる。関連するコードは空行を挟まず、物理的に近い位置に記述できることが望ましい。
変数宣言は使用位置に近いところで、ループ変数はループの中で宣言する。
横方向の書式化はインデントや空白、1行の文字数がある。
文字数はモニタに入りきるぐらいで、120文字ぐらいがいいのではないか。
空白をうまく挟むことで処理を強調できる。代入の左右に置くと変数名が読みやすくなるし、計算式の途中に入れると演算子の優先順位が読みやすくなる。
タブを使った変数の位置合わせは意味が無い。位置あわせしないと読みづらいような宣言はそもそも何かおかしい(関数／クラスが大きすぎる とか)。
○第６章 オブジェクトとデータ構造
すべてのメンバにゲッタとセッタを用意するのはアホのすること、最悪。
目指すべきは「抽象インターフェースを公開することで、データの実装を知らせること無しに利用者に対してデータの本質を操作することを可能とする。」
データ／オブジェクトには非対称性があり、状況に応じて使い分けることが大事。
データ構造(structとか)を使用するコードは新たな関数を既存のデータ構造に影響を与えずに追加することが可能。オブジェクト指向の場合、既存の関数を帰ること無く新たなクラスを追加することが可能。
言い換えると
データ構造を使用するコードは、新たなデータ構造を追加する場合、既存関数全てに手を入れる必要がある。オブジェクト指向の場合、新たな関数を追加する場合、既存クラス全てに手を入れる必要がある(interfaceを使った場合ね)。
○第７章 エラー処理
エラー処理は重要だが、エラー処理のせいでロジックが不明瞭になっているとしたらそれは間違っている。
例外が使えるなら戻り値によるエラー情報でなく、例外を積極的に活用する。
3rd partyのライブラリなど多数の例外に対応する必要がある場合はラッパを作って、不要な例外処理をロジック側に書かなくてもよくする工夫も有効。
nullは返さない、nullを渡さない。
nullを返す実装を作ると呼び出し側でチェックが必要になり、記述が複雑になる。空のリストを返すとか工夫をすることで、nullを返すのと同じ効果を得ることが可能なはず。
nullを渡すコードを原則禁止にしてしまえば、nullが渡って来た場合、誤りであるとすぐに気づくことができる。
少し間が空きましたが、3章進みました。
納得できるもの、感心できるものもあれば疑問に思うところもちらほら。
○第２章 意味のある名前
いい名前を付けるには時間がかかるが、より多くの時間をあとで節約できる。
以下の命題に答えられる名前を付ける。
嘘の情報や、紛らわしい名前はさける。具体的には”意図した意味以外に使われる名前”は避ける。例えば配列名にAccountListと名付けるとList構造で実装されていると連想させてしまう。(よくこういう名前を付けてるけど混同したこと無いな・・・)
(最近は長い名前の変数名も使うようになった気がする。省略形をうまく作ったつもりでも引き継げないことの方が多い。
システム全体で用語集/語彙集を作っておくというのはいいかも。作ったときはコード規約に入れておくといいのかな?)
○第３章 関数
関数の原則は”小さくある”こと。一つの関数では一つのことだけを行い、それ以外のことを行わないこと。この原則に従うとif/else文やwhile文のブロック行は１行になり、関数の中にはネストされた構造も登場しなくなる。
関数の実装から別の関数を抽出できるか調べることで、関数が一つのことに集中しているかどうかを調べることができる。
関数は抽象レベルが高いものを先に記述する。こうすることでコードを物語のように読むことができる。(1ファイル中の並びはアルファベット順でいいのかと思ってた。確かに抽象度順がいいかも。)
関数の引数は0が理想、3以上は避けるべき。オブジェクトの状態を変更するようにコードを書くことで、0引数の関数が実現できる。あわせて出力先を引数で受け取るのも避けるべき(C言語ではこれは無理だ・・・)
例外を多用する、戻り値でエラーコードを返さない。エラーコードを使うとすべてのファイルが特定のエラーコードが記述されたファイルを参照するようになり、そのファイルの修正がしにくくなる。
try〜catchでエラーを補足するのも１つの処理になるので、エラーを補足する関数も別途分ける。
○第４章 コメント
「ダメなコードをコメントで取り繕っては行けない。書き直すのだ。」
適切なコメントのあり方は、コードでうまく表現することに失敗したとき、それを補うのに使うこと。
コメントの使用がダメな理由は古いコメントはメンテナンスされる保証が無いから。
コメントを書く労力はコメント無しでコードを明確化する努力に当てるべき。
不正確なコメントがあるぐらいなら無い方がマシ。書かずに済むコメントよりも良いものは無い。
必要なコメントもある
ダメなコメントの例
今週からクリーンコードを毎晩読んでいます。
コードをどう書くべきか、かなり泥臭いところを懇切丁寧に解決した本です。
まだ触りを読んだだけですが、良書の感じがします。
あまりネット上に言及している記事が無いので自分の勉強がてら勉強したことを書いていくことにします。続くと思います、多分。
○前書き
ソフトウェア開発では小さなことこそが重要。
建築家はきちんと閉まらないドア、曲がった床のタイル、汚れた机をよしとするか？
「神は細部に宿る」
5S原則はソフトウェア開発にも当てはまる。
設計に終わりは無い。常に元あった状態よりも良くしてチェックインすること。
ソフトウェア開発における改善(リファクタリング)はコストではなく、価値につながる。
○序論
職人技の習得は
からなる。
クリーンコードを書くには努力が必要。経験則とコードを洗練してく過程で行った判断が何よりも重要。
○第１章 クリーンコード
要件を詳細に定義し、機械に実行可能なものとするのがプログラミングであり、コードである。
よく定義された要件はコードと同じ、常にコードは必要である。
粗悪なコードはコードを追加／修正するのに必要なコストが結局高くつき開発スピードが遅くなって管理できなくなってしまう（ウェーディング(wading)と言うらしい)
プログラマはコードのプロなので、混乱のリスクを理解できない管理者に屈服してはならない。
きれいなコードを「読める」のと「書ける」のには大きな差がある、センスが重要。クリーンコードの定義は人により異なるが、以下の要件を満たすものが挙げられることが多い。
クリーンコードにも流派があって当然で、この本で紹介しているのは流派の1つに過ぎないことを頭に留めておくことは大事。
家電名機カタログ—古今東西の傑作家電を完全網羅 (100%ムックシリーズ) (大型本)
家電批評のムック本を本屋で見かけて衝動買いしてきました。ずば抜けた歴史に残る家電 ”神機” を扱っています。以前の雑誌記事をつなぎ合わせた感じも否めませんが、まとまっていて保存するにはこっちの方が便利かもしれません。
はてなブックマークのホットエントリにあった エンジニアがタイトル買い、著者買いすべき本 – {Fight the Future => じゅくのblog}を見て、去年新人教育用に何冊かリストアップして渡したことを思い出しました。実際に読んでくれて役立ったか分からないけど、挙っていた本だとリファクタリング—プログラムの体質改善テクニック (Object Technology Series) (単行本)とJoel on Software (単行本)とアジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 (単行本（ソフトカバー）)がありました。元ネタに挙っていた本は個人的にもお勧めなものばかりです。
他にも数冊渡したはずで、全部は思い出せないのですが思い出せる限りでオススメの本をあげておきます。
C言語ポインタ完全制覇 (標準プログラマーズライブラリ) (単行本)
↑多分渡して一番役立った本です。研修でポインタを教わってもどう使っていいのか分からないのが新人の常なので適切な問題(ポインタに絡む実装や修正の依頼)とセットで渡してあげると効果が倍増するはずです。
定本 Cプログラマのためのアルゴリズムとデータ構造 (SOFTBANK BOOKS) (単行本)
↑またはプログラミングの宝箱 アルゴリズムとデータ構造 (C magazine) (単行本)でもいいかも。
下手な研修だと木構造とか文字列検索とか教わってこないので素養としてこれぐらいは読んでおいて欲しいかも。
ライト、ついてますか—問題発見の人間学 (単行本)
↑実際には渡せなかったけど、あるならこれも渡したかった。
元ネタにはワインバーグの本は無かったけど、著者買いしてもはずれが少ない人だと思います。
我らクレイジー☆エンジニア主義 (講談社BIZ) (単行本)
↑最後は趣味、仕事に望む気持ちの持ちようとして希望に燃える新人にはいい刺激になるかも。
他にもいい本はいっぱい触れてきた気がするんですが、いざまとめるとなるとなかなか出てきませんね。
実践的です。実用で鍛えられただけあります。
行動を起こすための実用書
1月の下旬から2月に読んだ本なんですが、感想を書き忘れていました。
達人プログラマシリーズの1冊ですが、前に読んだ”アジャイルプラクティス”の方が個人的にはお気に入りです。自分にとって既知の内容が多かったからかもしれません。
次は”Manage It!”か”Release It!”を読みたいと思っています。
Here is the XXX sheep.が25回。
会社でお世話になっているオーストラリアの研究所の方から出産祝いに貰った絵本です。
平易な英語で、いろいろな羊の絵が書いてあります。
うちの娘は色使いがきれいな”bath sheep(お風呂に入っている羊)”が好きみたいです。
オーストラリアでは有名な絵本らしいのですが、こういうプレゼントはうれしいですね。
© 2012 tune web · Proudly powered by WordPress & Green Park 2 by Cordobo.
Valid XHTML 1.0 Transitional | Valid CSS 3
