現場のコード意識を 変えるために導入した リーダブルコードとガウディの思想

1

はじめまして。

2

だいごろうと申します m(_ _)m

本日は お集まりいただき

ありがとうございます ( ・∀・)ﾉ

3

せっかく甲子園でチャレンジさせてもらえるので、

普段無いような観点から （むちゃくちゃな観点から） 面白く紹介できればと思います

4

自己紹介

5

名はだいごろう 職はアプリエンジニア 歴は４年目 趣味書を読む

自称

6

魔法戦士系のエンジニア

どういうことかというと

7

プログラミングも楽しいし、UIも楽しいけど、インフラも楽しい、だけど、ビジネスも面白いし、統計学もかじりたい、Hadoopつかってビッグデータも解析したい. Ruby on Railsをもっと触りたいし、Responsive Web designもいいけど、dockerとVagrantで面白いことできる気がする

本題

8

現場のコード意識を 変えるために導入した リーダブルコードとガウディの思想

こういうことない？

9

• 現場のコードがなんか読みづらい

• 改修する時に、コードの解読

• このソース、なにを書いてるんだ？？　　<- コミットログは俺だった。

こういうことない？

10

• 現場のコードがなんか読みづらい

• 改修する時に、コードの解読

• このソース、なにを書いてるんだ？？　　<- コミットログは俺だった。立ち上がれ同士よ

リーダブル＋ガウディ

11

+

お話したいこと

12

• 現場のコード意識で変えたかったこと 1.リーダブルコードの導入 2.ガウディの思想の導入

• どうやって、導入していくか • 導入した結果（途中

現場のコード意識で変えたかったこと

13

リーダブルコードがおすすめだよ。

当時の俺たち

14

俺 隊

２人だしもっと効率よくコードを書きたいね。

当時の俺たち

15

俺 隊 隊 隊 隊

バイブル あれ？ あ、なんか、 動いた、OK

昔のコピーで変数書き換えよう

昔のレガシーだけど、無理やりやろう。

当時の俺たち

16

俺 隊 隊 隊 隊

バイブル あれ？ あ、なんか、 動いた、OK

昔のコピーで変数書き換えよう

昔のレガシーだけど、無理やりやろう。いくら減らしても

減らない難読コード

当時の俺たち

17

• 修羅の道を決意

俺 隊 隊 隊 隊

げ、現場の意識を変えないと。。。

現場のコード意識で変えたかったこと

18

• ネーミングが酷い

• 意図が見えないコード（コピーとか

• 変更部分を動くようにすればいいでしょ？っていう考え

• とりあえず動けばいいやという発想

!

• とりあえず動けばいいやという発想頭の中

一番の問題はここにある

19

隊

動く

意識改革のゴール

20

• 動けばいいから、

• 読みやすいコード

• 引き継ぎ • などを考えてコードを書くことを意識

ファーストステップ リーダブルコードの導入

21

簡単な

コーディング中に 「動く」以外の考えることを

意識してもらおう ( ・∀・)ﾉ

22

リーダブルコード

23

リーダブルコード

24

コードは理解しやすくなければいけない

つまり 誰かが読んで理解するのに最短となる

詳細は、読んでね

リーダブルコード

25

• 表面上の改善

• ループとロジックの単純化

• コードの再構成

人は急に変わらない まずは、「動く」から 簡単でいいので

別のことも考えるという ステップ

26

コーディング中に考えることを増やす

27

• １つずつ埋め込んでいく

隊

動く

可読性俺

シンプル

ネーミング

コメント

リーダブルを導入する

28

• 簡単なことから意識してもらう

• 表面上の改善

– ネーミング

– シンプル・ショート

– コメントにコード書いた人の考え

ネーミング

29

• 変数・メソッドのネーミング

シンプル・ショート

30

• １ロジックずつ分割

コメント

31

• 書いた時の考え

コーディング中に考えることを増やす

32

• 脳のストレッチを進める

• 楽しくなる？

隊

動く

可読性

俺

シンプル

ネーミング コメント

セカンドステップ ガウディの思想の導入

33

ガウディの思想って そもそもなんやねん

(； ･`д･´)

34

サグラダ・ファミリアの不幸

35

・ガウディの事故死 ・模型、設計書の損失

でも、 サグラダ・ファミリアは 建築が続いている

36

ここに引き継ぎのヒントがあるはず！

(ﾟдﾟ)！

37

コーディング中に考えることを増やす

38

• 引き継ぎを考えよう

隊

動く

可読性

俺

シンプル

ネーミング コメント

引き継ぎ

ガウディの思想の導入

39

• 設計書より、小さな模型で説明する • 設計書ではなく設計思想を残す

ガウディの建築

40

• 設計書より模型（実物）

• 模型（仕様）は常に変わり続ける

• 変化することを前提とした構築

ガウディの建築

41

• 設計書より模型（実物）

• 模型（仕様）は常に変わり続ける

• 変化することを前提とした構築アジャイルじゃない？

小さな模型で説明する

42

• 図面ではなく、1/25くらいの模型で職人に説明し、理解させていた。その方がはるかに伝わったから。

現場に）小さな模型で説明する

43

• 簡単に実装を書いて説明しあう

• 簡単で良い

• 全体像を意識

現場に）小さな模型で説明する

44

• 簡単に実装を書いて説明しあう

• 簡単で良い

• 全体像を意識

自分と相手の理解が統一でき 統一されたコードを書くことができる

設計思想を残す

45

• 雨が当たる部分には石とレンガを使え

• 建材は特に指定しない

• 建築手法などで良い物があれば試行して、よければ採用してもよい（実際、途中から鉄筋コンクリートが導入されている

現場に）設計思想を残す

46

• コメントに設計思想を残す

現場に）設計思想を残す

47

• コメントに設計思想を残す

明日から、俺がいなくても 大丈夫だ(ﾟдﾟ)！

コーディング中に考えることを増やす

48

• 読みやすく

• 引き継ぎやすい

隊

動く

可読性

シンプル

ネーミング コメント

引き継ぎ

お話したいこと

49

• 現場のコード意識で変えたかったこと 1.リーダブルコードの導入 2.ガウディの思想の導入

• どうやって、導入していくか • 導入した結果（途中

導入するためにやったこと

50

• 自分でやってみる • コードレビューで指摘してみる • ペアプロをしてみる • 隣のプログラマに聞いてみる

• コメントを意識して残す • 手本を残すような気持ちで書く

自分でやってみる

51

俺

コードレビューで指摘してみる

52

• 口頭の説明が必要なら、そこにはコメントが必要なはず

• 違和感のある変数名とメソッド名は、理解のじゃまになる

ペアプロしてみる

53

• 名前付けとか、構造の作成を二人で討論しながら決めてもらう

• なぜを説明できるまで討論する • 簡単な模型 • 短時間で良い

隣のプログラマに聞いてみる

54

• メソッドのコメントだけでどんなメソッドだと思うのか聞いてみる

• 間違った答えならば、６か月後の自分は同じ結果となる

お話したいこと

55

• 現場のコード意識で変えたかったこと 1.リーダブルコードの導入 2.ガウディの思想の導入

• どうやって、導入していくか • 導入した結果（途中

結果（途中報告

56

コードの意識はどうなった？

57

• ネーミングと共にやることが明確に。 • 自分が何を書いているのか明確に。 • どこにそのコードは置くか意識するように。 • コードの説明をする機会が減った。 • 逆に、レビューのときに動作の不備を見落とす傾向がある。注意が必要。

• やり方の導入者の意見が正となりがちになってしまう

次は？

58

• メンバーに求めるもの • 本を書くようなコードを書くこと • コード設計をもっと詳しく説明

• 課題 • 継続するための環境と仕組み作り

まとめ

59

現場のコード意識を 変えるために導入した リーダブルコードとガウディの思想

60

お話したいこと

61

• 現場のコード意識で変えたかったこと 1.リーダブルコードの導入 2.ガウディの思想の導入

• どうやって、導入していくか • 導入した結果（途中

意識改革のゴール

62

• 動けばいいから、

• 読みやすいコード

• 引き継ぎ • などを考えてコードを書くことを意識

リーダブルを導入する

63

• 簡単なことから意識してもらう

• 表面上の改善

– ネーミング

– シンプル・ショート

– コメントにコード書いた人の考え

ガウディの思想の導入

64

• 設計書より、小さな模型で説明する • 設計書ではなく設計思想を残す

導入するためにやったこと

65

• 自分でやってみる • コードレビューで指摘してみる • ペアプロをしてみる • 隣のプログラマに聞いてみる

コードの意識はどうなった？

66

• ネーミングと共にやることが明確に。 • 自分が何を書いているのか明確に。 • どこにそのコードは置くか意識。 • コードの説明をする機会が減った • 逆に、レビューのときに動作の不備を見落とす傾向がある。注意が必要。

• やり方の導入者の意見が正となりがちになってしまう

さいごに

67

良いコードは

68

• より多くのビジネスチャンスを掴み

• ヒューマンエラーを少なくし

• 特定の人の存在に依存しなくなり

• 次の世代への、最高の教科書になる