ホーム » ハンズオン » #DevLOVE リーダブルコード勉強会

#DevLOVE リーダブルコード勉強会

小雨の中、初☆IIJさんに行ってきましたッ!

DevLOVE主催で訳者の角さん(@kdmsnr)とクリーンコードの須藤(@ktou)さんが講師でした。

↓この本の勉強会だったんですけど、翻訳出る前から気になってて、角さんが訳すと知って原本を諦めた記憶があります。

4873115655

1). リーダブル リーダブルコード

当日のスライド

View more presentations from Masanori Kado

ノート

リーダブルコードとは、つまり

他の人が再短時間で理解しなければいけない〔p3〕

つまり、

金にはならない。でも、やるしかない!

という説得が必要になる。
実際にどうすればいいか、ひとつめ

式は自分で音読するつもりで書こう
発音可能な名前で書こう

実際、誰かとソースを見ながら話したときに、「この、ええと…、なんて読むの?シーアルティ—・・・」みたいな記憶が沸々と蘇った。「ちょっと説明しにくいので、自席まで来てもらっていいですか?」が起こるのもこれができていないからかもしれない。

実際にどうすればいいか、ふたつめ

監督コメンタリーをとしてコードに置いてしまう。〔p60〕
(コミットする前のコード、使わなかった選択肢、却下された要望や提案、これからやること)

理由は重要との事(引用元:『影響力の武器』)

影響力の武器[第二版]―なぜ、人は動かされるのか

出来る限り理由を書くことで、相手も理解&受け入れやすい、とな。
コード=思考の断片を刻む場所となります。

では、ドキュメントはどうすればいいのか

角さんは、

  1. これから行いたいこと(仕様ともいう)をあらかじめコメントとして書く。
  2. その行間にコードを埋めて行く
  3. 結果を整形する。
    (最終的にコメントはゼロになる)

というような実装をされてるとのこと。
こーすることで、仕様が分かる人には、分かりやすい実装になるかもしれないと思った。以前にいたPJでは、詳細設計書を作っていたけれど、内容が変化するからと全ての実装が終わった後に作っていた。これってつまり、ドキュメントにあらかじめ落とせてなかった時点でダメだったのかもしれない。仕様が確定してなかったとはいえ・・・ぐぬぬ。

APIリファレンスを全部読めればさらにイイ!

また、こういう実装にすることにより、「試しにやってみる」ではなくて、「不要な要求は削除する」ことになる。前向きな感じがしていい。

ぼくのかんがえたさいきょうのリーダブルコード

続いてワークショップ!

今回の手順は、以下の通り。

1.みんなで話す
2.センセイのぼくならこう書く
3.質疑応答

“disりあいじゃなくて、考える事が目的の会” だそうです。

実は、登録するときにgithubのアカウントを求められてました。選定の基準はリリースされたものということでしたが・・・

みなさん、ソーシャルコーディングしてないんですね。
みなさん、もっとコードを書きなさい!

と、ありがたいお言葉を頂きました・・・(すみません)

0. yaruo_tdd_triangle 小芝居

角さんと須藤さんのやり取りの中で得た気づきなど

  • 修正する場合は、ひとつひとつ直すたびに、理由をコメントに書いてgitにコミットする。
  • ソースコードは同じように書く事(見せ方)で同じ事をしていることを示す
    =読者に余計な気を遣わせない為の工夫、少し違うとそこに何か意図があるのではないかと疑ってしまうため。
  • ロジック自体に一貫性を通そうとするのであれば、名前のつけかた(ハイフンやキャメル含め)、return処理の仕方にも気を配ろう。

一通り終わった後で、場内から質問が上がりました。

A男
「これからワークショップを始めるにあたって、このままだと読みやすく見た目を整えるという話に焦点が行きがちになってしまう。私は、実装方法や『書き手の意図になってるのかな?』という話をしていきたいと考えている。」

須藤さん
「翻訳が正しいと受け入れやすいように、一見本質と違うように見えるところでも、正しくすることで余計なところに集中しなくて済むという視点も私はそれと同じぐらい大事だと考えている。」

かど
「本来の意味的なところに半分以上の時間を使ってもらえればokだと思う。」

と、場内はますます活気づく中、いよいよワークショップスタート!

演習1.fast_spork_runner

演習内の気づき

  • 頭にreturn ifをばばばっとまとめて書いてメソッドの初期処理をこなすのがruby流
  • 規約を読む、明日からな!と同じように、rubyそもそもの規約を知らなければ見当違いの指摘をしてしまい、本来掛けるべきでないところにコストがかかる可能性がある。

ぼくだったら、こうする

  • センセイはemacs使い
  • 流れの中で、一部分に改行がなかったため、修正し、gitのコミットコメントは、”Add a missing line”
  • to_argument(line)という名前は直感的でない。line.to_argument()ならば、行に対しての処理だと分かるが、引数なのは納得がいかない。
    また、lineという名前も不適切に感じるが、1行の事をRSPECでなんと呼ばれているか今分からないので、名前を変えるのであれば、RSPECに合わせて変更したい。
  • line.chomp が2回続いてるので、一旦、lineに代入し直しておく
  • ここはこうしてるんだろうなぁと考えながら、調べてから直す
  • ひとつのメソッドだけ見て、意味が通じるようにしたい。
  • メソッドに引数を渡す段階で処理するのはもやっとするので、渡す前に処理したい。
  • RSPECのconfigに対する処理だから、メソッド名がconfigになってるけど、実際はconfigのoptionを処理しているので、名前を付けるとしたら、optionsではないか。

演習2.axlsx

演習内の気づき

  • 長過ぎて、みんな別の場所を見てしまったので、ファシリが必要だった。
  • 1行がやたら

ぼくだったら、こうする

  • fit_to_page が長い
    => 字面(パッと見た感じ)から入る/縦とか横に長いと不安になる/ここにあっていいのか悪いのか
    => 分割したり、return ifで分けたり、メソッドに切り出したりする。
  • # @deprecated Use {SheetView#show_grid_lines=} instead.
    => 指摘する場合、これを使った方がいいというところまでサジェストできるといい

Q and A

  • Q. ひとつのメソッドでxmlを作成しているため長くなっているが、それは同じ場所で処理して分かりやすくする為に、あえてやってるのか。それともある程度分けた方がよいか。
    A. 僕の場合、worksheet要素の追加なので、構造が分かるような形でメソッドを追加していく。
    => 作者「スピードのために、汚いけど、仕方なくやってる」
    => strはxmlに変えた方がいいのでは?
    => 分割するだけだったら、スピードは落ちないし、ちょっと頑張ればできるはず。
    => メソッドの名前自体に疑問。DOM返却かもしれないから、stringは必要?

まとめ

須藤講師より、

本を誰かを殴る為に使うのではなくて、いいコードを自分の周りに広げるために、買って下さい。

明日から本気を出す、ではなくて、私も以前、レビューしたことがあるし、設計したものを人に頼んだときに、全然伝わってなくて(名前も処理も)愕然とした記憶がある。次にレビューをすることがあれば、この本とこの日の記憶を胸に、自分なりのポリシーを明確にして、毅然とした態度で取り組みたいと思います。ドヤッ!

関連エントリ

関連書籍

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

著者/Dustin Boswell Trevor Foucher
翻訳/角 征典

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
オライリージャパン
2012-06-23
売り上げランキング : 1824

Amazonで詳しく見る by G-Tools

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中