俺のコードのどこが悪い？ の商品レビュー

藤原克則【著】

2015/01/09

俺のコードのどこが悪いねん - まほろば技術パーク
http://komeshogun.hatenablog.jp/entry/20141026/1414310220

2013/08/10

内容が「古い開発向け」の印象で、ある程度読んだら読むのを辞めました。扱う言語次第では役に立つのかな？JavaやRuby等を利用している場合はあまり参考にならない気がします。

2012/10/27

　ゆっくりコードを書く時間があったので、真面目に設計やコーディングスタイル、処理の効率などを考えていたところ、独学では詰まる部分が出てきました。そんなときに買ってみた本です。

　前半の失敗学の考え方は面白いので、そこだけ読むのもありかも知れません。
　全体としては、基礎知識が十分にある人ならスラスラ読めて、＋αを手に入れられる本だと思います。上級者にはコラムレベルかもしれませんが。
　例として、C系統の話が多いですが、他言語でも十分に使える知識です。コーディングや設計時に処理速度やリソースの消費について、あまり考えた事のない人にこそ、ぜひ一度読んでいただきたい本です。

2012/08/01

●俺のコードのどこが悪い

●心得
・設計段階では前提条件と選択候補を検討し、アウトプットとして記録に残す
・コードレビューの際にはクラスが定義されている場所、構造体が定義されている場所、関数が定義されている場所を素早く参照できるように準備する
・コードレビューのTIPSの裏には、コンパイラやインタプリタ、OS、CPUなどの愉快な仕掛けが隠されている。プログラマにとってこんなに楽しいことはない

●レビューの観点
・想定される最大値／最小値に対して、変数型の値域が十分であるかをチェックする
・switch文では、どのような範囲の値を取るかを把握し、caseラベル列挙の漏れが無いようにする
・関数の戻り値には、計算結果の返却、処理成否の通知、獲得したリソースの返却等の役割がある。関数の役割を考慮して戻り値をチェックすることが必要
・データにタイムスタンプが入る場合、検証時における時間経過の影響があるか考慮する必要がある

●保守性
・類似の処理がコード中に散在していると読み手が混乱する。保守性の見地からも、似た処理は集約することが必要
・式はなるべく単純な形とし簡単に読めるようにした方が後のメンテナンスが楽になる
・括弧や空白の配置に関するコーディング規約は、最初から完璧を期すのではなく、自分の成長に併せて、自分のコーディング規約を変化させるのがよい
・密接な処理は1つの関数に収めるべきだが、数百行に及ぶような関数は、処理の分割を検討すべき
・環境依存部分を局所化することで、環境依存性の影響を最小限とする

●性能改善
・メモリコピーのコストは、CPU時間を消費してメモリ転送が実施されるだけではなく、CPUの持つデータキャッシュの内容も更新されてしまう
・コード上で1行で表現される処理でも、単純な計算と遠隔ホストとのネットワーク通信では負荷に雲泥の差がある。各行の負荷を正しく把握することが必要
・関数の引数が増すと、スタック消費量が増加し、スタック領域メモリへのデータコピー量増加するというデメリットが生じる。引数の数を適切に設定することが必要・待ち合わせ方式にはスピンとブロッキングがある。スピンではCPU使用効率が悪化し、ブロッキングでは実行状態保存／復旧のオーバヘッドが発生する
・扱うデータ量が小さい場合には双方向リンクトリスト、多い場合には平衡ニ分探索木やハッシュテーブルなど、データ量に応じて効率的なデータ格納方法を選択する・連携先との接続障害が発生した場合、明示的な接続破棄が発生してその通知を受け取らなければ、タイムアウトまでスレッドが停止し他の処理を実行できなくなる

●セキュリティ
・実装担当者の個人利用や内部管理者向けのソフトであっても、実装担当者の思惑を超えて想定外の人に使用されることに備え、安全性を考慮した設計とすべき

2011/08/21

俺のコードのどこが悪い！？

悪いんです！！

レガシーコードは重罪です。

レガシープログラマになりたくないあなたは読みましょう。

2011/06/12

コードレビューの対策書。

というのが表向きだが、内容はコードの書き方指南書。

対象の言語にCを使っている部分もあり、若干古くもあるが、具体的に良いコードを示しているため、勉強になる。
これを読んで、実際に書くことでコードレビューで通るコードが書けるだけではなく、人にコードの書き方を教えることにもつながると思う。

また、冒頭のレビューに対する心構えは必見。
「責任の共有」や間違えたことを指摘されることで改善出来るようになる、など失敗学と言われるものから持ってきている考え方は若いうちに学び、実践するべきことなのは間違いない。

また、指摘する側にも勧めたい本。

2011/04/18

「レビュー」という趣旨での書籍ではありますが、実際にコードを作成している人に取っては「一種の指標（こんな感じでコードを書くと良い）」、バグで悩んでいる人に取っては「こんな原因で不具合が発生しやすい」、テストを担当している人は「こんなところに不具合が紛れ込みやすい」といった感じで、比較的幅広い範囲で役に立つのではないかと。

また、コラムも結構参考になるところもありそうです（p208-209の「例外が発生する部分をコメントアウトする」というのは、実際に見たことがあるような・・・（笑））。

１点気になるところとしましては、Java5に触れている部分がある(p140)一方で、Javaにはenumがない(p59)と記載されている点でしょうか。確かに、Java1.4まではenumはありませんでしたし、Java5以降のenumもCのenumとは若干違う仕様ではありますが・・・。

2011/03/30

良本でした。

基本的なことからなかなか深いところまで書かれていました。

少し関係ないですが著者さんのコードの書き方で条件式にNULL == pのように定数を先に書くことの意味がわかり、感動しましたｗ

本における正誤情報がこちらの著者さんのサポートページに掲載されているので、本を読む前にチェックしておくといいかもしれないです。
http://www.lares.dti.ne.jp/~foozy/fujiguruma/books.html

2011/03/17

平易な文章でわかりやすく書かれているので、
プログラミング初心者向けの本かと思いきや、
ときどきドキッとするような高等な話が書かれていて勉強になった。
（システムコール発行の流れとか、スレッド間の同期の話とか）
たださすがにもうプリントアウトしてコードレビューする人はいないんじゃないだろうか。