読者です 読者をやめる 読者になる 読者になる

by shigemk2

当面は技術的なことしか書かない

開発者は仕事でリーダブルなコードを書けるのか? #devmi

勉強会

404 Not Found

(前置き)
システム環境はおおきく変化
システム開発をやるSIerも増加

現場やエンジニアの役割がどのように変化したのか

リーダブルなコードを紹介
開発者にとってリーダブルなコードとは?

対象は開発者
リーダブルなコード

これはリーダブルなコード?

class Model
  def data=(data)
    @data = data
  end
end

ではこれは?

class Person
  def initialize
    @mutex = Mutex.new
  end

  def name=(name)
    @mutex.sychonize do
      @name = name
    end
  end
end
class Person
  def initialize
    @mutex = Mutex.new
  end

  def name=(name)
    sychonize do
      @name = name
    end
  end

  def synchonize
    @mutex.synchonize do
      yield
    end
  end
end

どのコードがリーダブルなのかこのセッションでごにょごにょしても意味ないので、
現場の環境で確認しておくとよい

Rubyコードの感想戦
るびま」から

  • コードはコンピュータが実行するだけではない
  • 読む人がいる
  • コードは書いた人の意図を語る

どうしてそのコードを書いたのか読む人は読み取らなければならない
→コードを見れば分かるのがリーダブル

書いた人の意図が分かるコード

リーダブルコード

  • わかりやすい
  • 直しやすい
  • 調べやすい
  • 試しやすい

リーダブルコードってうれしいの?
動けばいいんじゃないの?

反論1 開発者にとってストレスが減る
なにをしているか分からないコードは、読んでてつらいし、ストレスフル

反論2 楽しい
すぐに対応出来るから
他のメンバーの要望にその場で対応できるよ→オレってばスゲー感

nightmare language
「オレってばスゲー感」を他の人にも体感してもらおう

すぐに対応できるのは、言語のライブラリが整備されているから?
それもあるけど、リーダブルなコードが「オレってばスゲー感」を助けてくれる

作らないほうがいい?
まず、作るかどうか何度も検討する。(作るのに時間がかかるとか、時間がかかるわりにあんまりパフォーマンスがよくない、とか)
でも、考えている間に試してみたらいいんじゃないだろうか。
すぐに出来るものは、さくっと試してみたらいいんじゃないだろうか。

→必要のないことに時間をかける≠作らない

反論3 コストが下がれば試せる
コストが下がるとは…
実サーバー→仮想マシン (すぐに追加削除が出来る)
設定を楽々にしとくといいんじゃないだろうか

→コードでも同じようなことが出来る
→コードが読みやすければ、素早い対応が出来る

素早くない反応
このくらいで終わりそう…→このコード読みづらいし拡張しづらいし、バッファ2倍くらい積んどけば…
→リーダブルなコードであれば、既存のコードをちょっと追加して試してみて、また相談…っていうことが出来る

信用
いつも素早く対応してくれる人が時間かかるのであれば、
それはよっぽど大変なことなんだろう。

リーダブルなコードだと、チームの皆が簡単に直せる

あるべき設計を維持できる
読みづらいコードだと、「担当じゃないから分からんから直せん」、みたいなケースはざらだね★
リーダブルコードだと他の人が作ったモジュールも皆が簡単に直せる
「チームの結束が強くなるかもしれない」

誰でも直せる?
直せても直してはいけないのか?(でも直しといてそれがエンバグしたら責任が…)
出来る人にだけ負荷がかかる?(出来る人ほどツライ… 出来ない人のほうが得?)

開発者は仕事でリーダブルなコードを書けるのか?

書ける。でもなかなか難しい

コードレビューしたほうがよい?
リーダブルなコードを目指すためにコードレビューを導入したけど、誰もやってくれない
→まず、あなたがやってみたらいいんじゃないの?

時間がない
自分は他の人のコードを読む時間がない
→時間を決めて読んでみませんか?ペースが分かれば取り組み方のアイデアも分かるはずですよ

でも…でも…

→コミットへのコメントサービス
(→株式会社クリアコード)

なんで読むの?

  • 読まないと読みやすいコードは書けない
  • 読む人を想像しろなんて無理
  • 自分が読む人になる

あなたが読む事を支援

  • どうやって読むの?
    • よいところを学ぶ(良いところを共有する)
    • 悪いところを探さない
  • どういうタイミングで?
    • pushとかcommitしたあと
    • 一区切りついているでしょう?

こうすると読みやすい
よいコードを見た、真似してコミット
いいね!やブクマしているだけではない。行動しているからより本物

他の人が何をしているか分かる
あの人はあそこらへん詳しそう
相談してみよう

他の人が困っていないのか分かる
1時間ひとつもコミットしていないけど大丈夫?
このコミットすっごいゴチャゴチャしてるけど大丈夫?

さいごに

  • リーダブルコードが大事そうなのを理解しましたか?
  • 仕事でリーダブルなコードを書けそうですか?
  • 支援があれば書けそうですか?

オープンソースソフトウェアの開発に参加しませんか?
そこで体験してよかったら自分の言葉で説明出来るはず。


口で説明するより、具体例を出してみたらよいのではないだろうか。

1時間に1回コミットとかハードル高すぎじゃね?
ペアプロやってて、コミットの通知を皆でしてれば、それなりのスピード感が
得られるのではなかろうか。

ネストだらけのコードを改善するためのコツ→
自分の書いたコードは基本忘れて、読んでまた思い出すようにする