第78回ruby関西での登壇資料です。 https://rubykansai.doorkeeper.jp/events/62491

1. rubocopとの付き合い方

2. self.inspect
植森 康友
所属：株式会社Aiming
役職：エンジニア
管理ツール開発
WebAPI開発
Dockerおじさん
SNS:
twitter: @wakaba260yen
github: yuemori

3. 今日の話
コードレビュー
rubocop
守破離

4. コードレビュー

5. コードレビュー、してますか？

6. コードレビューがなぜ必要なのか
新人教育
品質向上
相互学習

7. でも、ちょっとまって

8. そのレビュー、本当に必要？

9. 例えば、こういうレビュー

10. コードレビューの本質
コードレビューに慣れないチームが、何の考えもナシにコードレビ
ューを始めるととにかく気になったこと大小様々な指摘が行われる
ことになる。一見、いろいろな指摘が出て議論が活発になっている
ように見えるが、だいたい議論が紛糾しているのは「コードのイン
デント幅が違う」とか「return が省略されてる。俺はreturn があ
ったほうが好み」とか「その場合は字下げをした方が綺麗にみえる
んでは」とか、そんな些末なことばかりである、ということが多い
naoyaのはてなダイアリー「些末なコードレビュー」より
http://d.hatena.ne.jp/naoya/20140313/1394664578

11. コードレビューの本質
そんなことを延々議論していたって、はっきり言って何の意味もな
い。何の意味もない、は言い過ぎにしても、そんなところを改善し
たところで実質的な品質は何ひとつ上がらないわけだし、どうして
も揃えたいならlint ツールか何かで機械的にチェックすればよいこ
とであって人間がやることではない。
naoyaのはてなダイアリー「些末なコードレビュー」より
http://d.hatena.ne.jp/naoya/20140313/1394664578

12. コードレビューの本質
やらなければいけないのは、「その設計は拡張に対して開いていな
いから開くべき」とか「これではエッジケースが想定されていない
からこういう不具合につながるのでは」とか「そのテストでは後日
見返したときに第三者が要求仕様を解釈しづらい」とかそういう指
摘である。
naoyaのはてなダイアリー「些末なコードレビュー」より
http://d.hatena.ne.jp/naoya/20140313/1394664578

13. 再び、コードレビューがなぜ必要なのか
新人教育
品質向上
相互学習
=> より本質的なことにクローズアップした教育をしたい
=> 変更や拡張、バグ回避などに重点を置きたい
=> 設計や実装などのより良い議論に時間を使いたい

14. "lint ツールか何かで機械的にチェックすればよい"

16. rubocop、使ってますか？

17. rubocopとは
Rubyの静的解析ツール
コーディングルールを始め、様々な静的解析を行ってくれる
コーディングルールは同作者のruby‑style‑guideに準拠
https://github.com/bbatsov/ruby‑style‑guide

18. コーディングルール？
Rubyには公式のコーディングルールがない
Rubyの思想＝ Happy Hacking!
楽しくプログラミングできるようにデザインされた言語
おのおのが好きなように、楽しくかけるのが重要

19. コーディングルール？
しかし、必ずしも一人が楽しければHappyではない
他人のコードを読む・触るとき
他人にコードを書いてもらうとき（Pull Request!）
業務においてはコードが自分だけのものではない
状況に応じた適切なコーディングルールがあるとみんながハッピー
になれる

20. 静的解析の恩恵
rubocopはスタイルチェックだけではない
Metrics、Performance、Security、etc...
より良いコードを書くためのチェックも行う
より綺麗で読みやすいコードを書けるようになる

21. rubocopの機能紹介

22. Cop
In RuboCop lingo the various checks performed on the code
are called cops
rubocopの用語で、コード上で実行される検査のことをCopと呼ぶ
Copの種類
Style
Layout
Lint
Metrics
Performance
Security
Rails
Bundler

23. StyleCop
コーディングスタイルに対するCop。
コーディングルールの一貫性のチェックを行う。
デフォルトはruby‑style‑guideに準拠。
設定により変更することもできる。

24. LayoutCop
レイアウトに対するCop。
インデント、alignment、空白などに対するチェックを行う。

25. LintCop
エラーに対するCop。
曖昧な表現や、エラーに対するチェックを行う。

26. MetricsCop
メトリクスに対するCop。
コードの複雑さや保守性などのメトリクスを解析しチェックを行う。

27. PerformanceCop
パフォーマンスに対するCop。
パフォーマンスの低いコードのチェックを行う。

28. SecurityCop
セキュリティに対するCop。
セキュリティに問題のあるコードのチェックを行う。

29. RailsCop
Railsに対するCop。
Railsに特定したコードのチェックを行う。

30. BundlerCop
Bundlerに対するCop。
Bundlerに特定したコードのチェックを行う。

31. auto‑correct
auto‑correct対応のCopに対し、自動整形を行う。

32. Todo
rubocop --auto-gen-config を実行することで、Todoリストを作成
することができる。
「今は直せない負債」を目に見える形で残すことができるため、既存プ
ロジェクトへの導入などに効果的

33. 守破離

34. rubocopはきょうせいギブス

35. rubocopはきょうせいギブス
1ファイルに警告×300個

36. やかましい！

37. ちょっとまった

38. Configuration
.rubocop.ymlを設置することで設定を変更することができる
コーディングルールなどプロジェクト内の設定を記述する

39. 守破離って、知ってますか？

40. 守破離
日本での茶道、武道、芸術等における師弟関係のあり方の一つ
個人のスキル(作業遂行能力)を3段階のレベルで表している

41. 守破離
まずは、師匠の教えを守る
「型を守る」ところから修行を始める
=> 支援のもとに作業を遂行できる(半人前)
=> 自律的に作業を遂行できる(1人前)

42. 守破離
型を研究し自分と照らし合わせていき、自分にあった型を見つける
自分の型を作ることで「型を破る」
=> 作業を分析し改善・改良できる(1.5人前)

43. 守破離
最終的に師匠の型と自分が作り出した型の上に立脚する個人になる
型から自由になり、型から「離れ」て自在になることができる
=> 新たな知識(技術)を開発できる(創造者)

44. 守破離
守：rubocop先生に教えを請う
破：rubocopのルールを自分に合わせて改善する
離：自分なりのコーディングスタイルを確立する
自分のレベルに合わせたrubocopの活用をしていく
画像引用： http://www.motivation‑up.com/motivation/shuhari.html

45. rubucop.yml
rubocop用の設定ファイル。rubucopの警告の挙動を変更する
デフォルトでイケてないなと思う挙動を変更する（結構ある）
不要なルールは無効化する
好きな方を選べるルールも多い（インデントスタイルなど）
‑> 自分なりのrubocop.ymlを育てていくことで「離」につながる

46. よりrubocopを活かすために

47. rubocopを入れただけでは平和にならない

48. rubocopを入れただけでは平和にならない
入れただけでは守らない
そのうち警告がうるさくなってきて無視
そして戦場へ...

49. CI、自動チェック
git hook
pre‑commit, pre‑push
チーム全体でhookを共有しておくのがおすすめ
github連携
houndci, sideciなど

50. 設定相談
rubocopの設定を議論することで共通認識ができる
気に入らないルールはissueなどで相談する
‑> rubocopの設定をチームの合意にする

51. ローカルでの自動チェック
エディタ連携
guard‑rubocop

52. rubocopの導入
既存プロジェクトに入れるのはコストがかかるのでtodoを活かす
プロジェクトに入れるなら最初から入れる
個人プロジェクトにデフォルト設定で入れるのが一番おすすめ
自分のコーディングの弱点を知る
そのうち「これは本質的な警告じゃないな」と思うようになる
rubocopの教えを理解した上で無効化するようにしていく

53. まとめ
自動化できるチェックはrubocopで自動化する
rubocopは自分やチームの段階に応じて調教していく
rubocopと一緒に成長し自分なりのコーディングスタイルの確立へ

54. ご静聴ありがとうございました

55. 最後に一つ宣伝を

57. rails developer meetup
第一線で活躍する開発者や企業から知見を学び現場で活かせる考え
方やテクニックを得る非営利勉強会
所属企業と地域の枠を超えた技術コミュニティ
なんのコネもない開発者・企業に唐突に登壇依頼をする運営スタイ
ル

58. 次回
日時： 8/24(木)の19 30～
connpassの募集は8/1から
ハッシュタグ： #railsdm
keynote： pockeさん、伊藤淳一さん
興味のある方は是非ご参加ください