DoorKeeper（告知サイト）
http://devlove.doorkeeper.jp/events/1846
DevLove 2012 公式
http://devlove2012.devlove.org/
Togetter
https://docs.google.com/spreadsheet/ccc?key=0AhD6eLMu1vRNdEdGakNieGRpNUFvMTdEODNXVmcyR0E#gid=1
先日、其の壱として和智さんのセッションについて書きましたが、今日は以下のセッションについて書いてみようと思います。
| 講演者 | 和田卓人さん |
| タイトル | 愛せないコードを書くには人生はあまりにも短い |
| セッション | 2012/12/16(日) 17:10～18:00 Room A |
| URL | http://devlove2012.devlove.org/speaker#speaker_31 |
| Togetter | http://togetter.com/li/423728 |
| スライド |
■自己紹介
- ブログのIDはt-wada。ハイフンは「真心」。
- TwitterのIDは、@t_wasa。アンダースコアは「下心」。
- githubはtwada。ハイフンもアンダースコアも無い、「心が無い」。
- プログラマ兼社長。
- プログラマが知るべき97のこと、という書籍の監修を3年前くらい前にやった。
- DevLove2012で、TDDについて話す人が多すぎる。なので今回はポエムっぽい話をしようと思う（笑
- TDDはもう宣伝とかは十分な地位にある。今日は、自分にとって、あなたにとってのTDD、という話だけをする。
■アジェンダ
- １．誇りを失う仕組み
- ２．誇りを取り戻す一歩
- ３．予期せぬ変化を予期する
■１．誇りを失う仕組み
- 自分が楽しいプログラミングと楽しくないプログラミングの違いとは何か？
- コピペ駆動開発
- うんこ形式のコメント（バージョン管理システムを使わず、ソースに修正履歴がコメントで膨大に書かれている。）
- 「動くコードに触れるな」（どうしても触れるときにはうんこ形式のコメントを残せ）
- 一番レベルの低いエンジニアに合わせたルールにする。（例：三項演算子を使ってはならない）
- コードレビューは、被告席に立つようなもの。綴りミスとか延々指摘される。
■人海戦術
- タコ部屋 ・・・ プロジェクトが炎上して人員投入 → 一人の作業スペースがXX(cm)になった。。。
- エビデンス・・・方眼紙Excelに貼り付けられたスクリーンショット。。。
- 負荷テスト・・・偉い人が号令を掛けて、体育館に集まったエンジニアが一斉にクリックして負荷テスト。。。
■ドキュメント
- 大事なドキュメントはゼロでもいけないし、多すぎてもいけない。
- ドキュメントというものの存在と難しさが、日々の仕事を疲れさせてしまう原因の１つ。
■技術的負債
- 技術的負債という言葉は、悪い言葉ではない。（例：企業がビジネス上必要な賭けとして、市場にソフトウェアを早くだして挑戦のステージに立つために、テストを省く場合）
- 技術的負債の問題は、返すチャンスが少ないこと。
- 技術的負債を気づいているのに、直せない。
- リファクタリングせよ、というタスクがずっと残ったままになると、心理的負債になる。（～せねばならない、というのをバックログで毎日見てると、自分の心や誇りをすり減らす原因のひとつ）
- ～なんて当たり前、と言って出来る人と、目の前にいる自分とを比較して、打ちのめされる。心をすり減らす原因の一つ。
■でも、本当は知っている本当のこと
- 自分が自分のコードに愛着に持てなくなってきた原因は、ホントはみんな自分で知っている。
- それは、自分の頭と自分の実力が、それについていけなくなったから。それを認めたくない。
■自分を失う原因
- 自身を失う仕組みは、自信の持ちすぎである。
- その自信は、自分の幻影。サクッと終わらせるつもりだったものがサクッと終わらせられない自分にガッカリする。
- さくっと行かない現実とさくっとやってみせるはずだ、というギャップに打ちのめされる。
- そういうので、自分の仕事やコードに愛着や自身が失われていく。
■自分の弱さ、自分の弱さ
- なので、自分の弱さに立ち向かっていかないといけない。
- 忘れっぽい、とか、移り気、というのは人間のスペックである。多かれ少なかれ、みんなこう。
- なので、これに正面から立ち向かって克服する術を見つけていかないといけない。
■誇りと愛着を殺すもの
- 誇りを殺すのは、自分の弱さ。
- 誇りと愛着が持てないと、作るシステムは良くならない。
■ご参考「原メソッド」
- スライドに講演者（自分）に対する指示を埋め込んでおいて、チェックポイントを自分に見せるというもの。
- 原信一郎さんが提唱している手法らしい。
■２．誇りを取り戻す一歩
■教育的すぎる世界に抗う
- ～できて当然、という話はどうでもいい。問題は、自分がどうあるか。
- 人は、自分の成長速度でしか変われない。今できている人と比べたって仕方がない。打ちのめされるだけ。
- ただし、諦めてはいけない。
- 大事なのは、過去の自分との相対評価。
- 過去の自分と比べる。過去に自分が書いたソースより良くなっているか、とか。
- 他者と比べてしまうと、出口がないものが待っている。
■愚直であれ
- 自分がガレー船の絶望と戦ったやり方は、愚直になれ、だった。
- 写経をやる。自分がやりたいことを写経して動かしてみる。
- そこのフィードバックから何を言おうとしていたのかを読み取る。
- 技術書の写経の方法、でググると、t_wadaさんが140文字にまとめている。↓
技術書の「写経」の方法。 1.ローカルで使える SCM を用意 2.「ほんたった」などで対象の本を固定 3.ひたすらサンプルコードを写して実行 4.実行するたびにコミット(コミットログにページ番号を含める) 5.疑問点があったらコミットログや本に書き込む 6.章ごとにタグを打つ
— Takuto Wadaさん (@t_wada) 2月 12, 2010■3本柱
人間の限界（忘れっぽいとか、継続してできないとか）と戦っていくために道具を身につけましょう。
- バージョン管理
- （CVSの頃は、ブランチ管理を手動でやる必要があった。）
- ソフトウェアは意外に長生きする。人間の記憶力を、ソフトウェアの寿命はあっさり超えていく。
- バージョン管理を身につける、ということは、自分の記憶力を拡張する、ということ。
- バージョン管理をしないというのは、一回もセーブせずにRPGをやるようなもの。大きなリスクがある。
- バージョン管理を使うと、簡単にブランチがきれる。
- 自動テスト
- ドキュメントと自動テストは強い相関がある。
- 最近のソフトウェアを自然言語で書くには複雑すぎる。
- 動くドキュメントとしてテストコードを書いていくほうが、最近では合理的である。
- 劣化しないドキュメントとしてテストコードをメンテナンスしていく。それがテストコードの良いところ。
- 自動化
- 同じことを続けていると精度が落ちて、疲れて、飽きてくる。
- 3回同じものを書いたらアウト。BY増井さん
- 変更の阻害要因は全部リスク。
- どれだけ変更についていけるか、を人間が努力せずに機械がサポートしてくれるか、を機械と歩んでいくための仕組みが自動化。
■動作する、きれいなコードへ
- 動作するきれいなシステムを作りたい。
- 官僚主義的な強迫観念とか技術的負債とかで、まず動くことに価値が求められる。
- 動作する（グラフの右下）ことは正義。
- だけど、グラフの右下（汚いけど動作する）にいると、心理的負債によってプライドがすり減っていく。
■リファクタリング
- コードは動かなくても現実世界は動くんだから、結局コードにはどんどん変更を入れていかなければいけない。
- 動くコードに触れずにそれをやらないといけないということになると、何が起こるかというと、コピー＆ペーストになる。
- それで誇りが失われている。
- だから、リファクタリングには「意志の力」が必要。
- 意志の力と、コツコツとテストコードを貯めていく努力、この２つが必要。
■TDDと黄金の回転
- TDDにおける「テストコードを先に書く」というのは、コードの綺麗さには寄与しない。
- TDDのサイクルと４象限のモデルを組み合わせると、黄金の回転になる。
- 技術的負債がたまると心理的負債が溜まってプライドがすり減っていく。
- 技術的負債を返すための期間とか予算とかの仕組みが必要になってくる。そうなると説明責任が発生する。
- → どれだけ黄金の回転を小さく回して毎日ちょっとずつリファクタリングしていけるか、が重要。
- 「リファクタリング」しましょう、と名前がついてしまう時点でやりにくくなるというジレンマがある。
- そうじゃなくて、リファクタリングというのはプログラミング。
- プログラミングの一部として、リファクタリングを入れる。
- リファクタリング、というものとして切り出してしまうと、リファクタリングできなくなる。
- プログラマはリファクタリングによって綺麗なコードを書いている実感によって、誇りを取り戻す。
■三本柱と黄金の回転の力
- バージョン管理、自動テスト、自動化、TDDを回る４象限の力によって、恐怖を克服して、変更の勇気を得るための協力な仕組みになる。
- これらによって、これまで自分をすり減らしてきたものに対するリベンジするための準備が整う。
- 規模の大小は関係ない。自分たちの限界を認め、自分のスピードで自分の限界を引き上げる。
- それを助けるための道具は近年揃っている。それを知って、使って、自分の弱さを克服し、限界を引き上げていきましょう。
■３．予期せぬ変化を予期する
「予期せぬ変化を予期する」という言葉は、先ほど和智さんのセッションで議題だったGOOS本に出てくる。
■予想外の変更
- プログラムは価値を社会に提供している限り、変更に晒される。
- 変更が予想内であることとはほとんどない。大体変更というものは斜め上からやってくる。
■予想できないことだけは予想できる
- 自分が変更を予想できない、ということだけは予想できる。
- 良いコードであればあるほど、FIXされない。良いコードであるほど使われ続けて、後から要望が出てくるから。
- 変更は予想を超える。予想外に備えるためには、鎧を着込むのではなく、身軽であること。
- どれだけコードが身軽であるか、が予想外に備えるということ。構えすぎないこと。
■シンプルさを保つには
- 歴史を知る。これまで生き残ってきたものには理由がある。きっと何らかの秘密がある。良いと思うことを見抜くこと。
- まだ生き残ってて上手くいっていると思うもの。
- UNIX
- REST
- SQL
- これらには身軽である、というヒントがある。
- UNIX
- 自分が変わるんじゃなくて、組み合わせることで対応する指針。
- パイプとプロセス間通信の仕組みが発達している。一つ一つは単純だが、組み合わせることで複雑なことができる。
- KISS（Keep It Simple, Stupid）
- 単純に動け。（複雑にすると怒られる文化。シンプルなものを組み合わせて予期しないものに立ち向かう）
- REST
- URLが偉くて振る舞いが少ない。
- できることは少ない。状態を持たない。これらが繋ぎやすさを生み出している。
- URLがわかれば、やりたいことは4種類くらいに絞られる。その4種類は大体が合意されている。
- SQL
- すべてが集合。
- できることは少ない。
- すべての単位として、集合に帰ってくる。クロージャ。
- 共通するもの
- インタフェースが少ない。けど、インタフェースの組み合わせによっていろんなものができる。
- 少ないインタフェースの合意が成されていて、かつ実装に依存していない。だから時間を跨がれる。
- 40年前にかかれたプログラムの出力を、今書いた自分のプログラムが受け取って、その出力を30年前のプログラムに渡す、とか。
- 再利用がしやすい
- 穏当なコードで書きたい
- 直行：自分がやりたいことを認識していて、他のことと離れていること。変更理由が1個。
- キレイで読みやすくて、アクロバティックではないコードが良い。
- アクロバティックなコードはスピードを求められる場合。
- 時を跨いで使われるコードは、如何にも動きそうなもの。アクロバティックなコードはこういうものではない。
４．TDDとは何か
■プログラミングを支えるものは何か
- 楽しさとか情熱とかモチベーションが、日々のプログラミングを支えている。
- それらの多寡によって自分のモチベーションが変わる。
■TDDは弱い私たちのためのもの
- TDDは、自分たちにプログラミングの楽しみを思い起こさせてくれる。
- TDDは、自分の足で歩き出すための技術であり、道具。
- 手元に、原風景の残す。TDDをやると、プログラミングの楽しさが蘇ってくる。
- TDDはプログラミングの楽しさを取り戻すもの。
■TDDは結局のところ何なのだ？
- 今が自分が思った通りに動いているし、静かな自信の上に歩いていけるのがTDDの良いところ。
- 徹夜して気合で頑張るのは、勇気じゃなくて蛮勇。
- TDDは、自分が自分の足で限界を引き上げて、静かな自信の上でもう一歩を踏み出すこと。そこには心の平安がある。
■作業者になるな
- 大事なのは、考えることをやめないこと。
- 考えること以外はコンピュータに取って変わられる。
- 変化に対して、蛮勇ではなく静かな自信で立ち向かうために、一歩一歩砦を自分の中に構えていく。
■TDDはスキルです
- TDDは才能ではなく技術です。才能は、ジョジョ風に言うと、スタンド。
- ジョジョの第１、２部を私が好きなのは、才能に対して、技術と努力に立ち向かう物語だから。
- 後天的に才能を得る寸前まで行って、そこから離れていく。（ジョジョねた）
- 誰でもできるはず。
- 大事なのは才能ではなく技術。自己研鑽によって取得することができる技術。
- 練習すればするほどテストコードやリファクタリングはうまくなる。才能の入る余地はない。
- 迷ったら、愚直に戻る。写経をする。
- 自分の足で、自分の成長のスピードで一歩を踏み出す。
★感想：
和田さんのセッションはいつも熱いお話が多くて、この日もジーンと涙腺に来ちゃいました。
私の心はどちらかというとSEやマネージャといったロールではなく、かなりプログラマ寄りなので、同感する話が非常に多かったです。
和田さんが力説していたTDDを実践していくためにも、GOOS本の写経を頑張ろう。。。
