TDDの権化、t_wadaさんによるTDDワークショップに参加しました

t_wadaさんによるTDDの1dayワークショップに参加しました

2018/2/27(火)にTDDのスタンドの使い手 id: t-wada さんによる、1日ワークショップに参加してきました。 一ヶ月以上もブログ書くのが遅れてしまった…

ワークショップアジェンダ

ワークショップは以下のような流れですすみました。

  • TDDについての講演
    • 講義とライブコーディング
  • ペアプロ
    • 全員参加のコードレビュー大会

TDDについての講演

テスト駆動開発とは何かというところから始まり、TDDがうまくいかない(主に技術的でないもの)原因を学び、TDDを実際に行うためのサイクルをライブコーディングを交えつつ披露していただきました。

こちらの詳細な内容については、 以下で非常によくまとめていただいていたので詳しい内容は割愛して僕の感想だけ書こうと思います。(講義時のメモをまとめたら全く同じ内容の記事ができてしまったため)

developer.ntt.com

予測可能性について

講義の中で、今はまだソフトウェアが工学(Engineering)になりきれておらず、予測可能性が低いという話をされていました。

まさに目からウロコといった表現で、実体験としてこういうことを感じており非常に心に響きました。言い方をかえると「書いてみないとわからないことが多い」という当たり前のようなことですが、設計してるときはついつい忘れがちになります。 わりと緻密に設計をしたつもりでも、いざコードを書いてみると全く想定していないところで動かないことは頻繁にあり、今までは単に「辛い」と女子高生のような語彙力の低さを撒き散らしていたので、これからは「予測可能性が低いから(キリッ)」と言おうと思います。

どうやって「動作するきれいなコード」へいくか

ソフトウェア工学の世界では予測可能性が低いので「動かない汚い -> 動く汚い -> 動くきれい」(動かない汚いって単体で見るとすごい表現だな)というステップを踏もうとします。 そのために取れる手法のうちの一つがTDDというわけです。 しかし、このステップを進もうとするときにどす黒い感情が我々の前に立ちはだかります。

  • 堕落
    • 動いてればいいじゃん
  • 焦り
    • 動いているから、もっとほかのところ、次のところをやるべきではないか
    • 内発的な焦りと外発的なプレッシャー
  • 恐れ
    • 動くコードをきれいにしていく過程で動かなくなったら意味ないじゃん
    • しかし、ソフトウェアの世界が日進月歩なので動いているものを手をいれて変えないと、いつか動かなくなる

これらはそれぞれ誰にでも経験があるだろうことで、もっと言えばみんな上司とか偉い人から言われたことあるよね????(ぼくはあるよ)。

こいつらを乗り越えないと「動かない汚い -> 動く汚い -> 動くきれい」といった順番に乗れず、予測可能性が低い方法(しつこい)を取らざるを得なくなったり、動くけど汚いコードのまま過ごすはめになるわけです。

TDDではこの中でも特に「恐れ」に対抗する手段としてとれる手法とおっしゃっていました。

TDDのサイクル

- 次の目標を考える
- その目標を示すテストを書く
- そのテストを実行して(予想どおり)失敗させる(Red)
- 目的のコードを書く
- テストを成功させる(Green)
- テストが通るままでリファクタリングを行う(Refactor)

TDDのサイクルを載せました。TDDではこの中でもrefactoringが一番折れやすく、ないがしろになりやすい(「堕落/焦り」ですね)のでここは普段のプログラミングや日課に紛れ込ませてやるのがいいとおっしゃっていました。

(例えば、テストと目的のコードをたくさん書いたあと、次のスプリントはまるまるリファクタリングさせて下さい! よりも日々の中にリファクタリングを積んでしまったほうが良い。スプリントまるまるリファクタリングに費やすと新規機能が0なのでSMやPOからしても指示や承諾がしづらい)

ペアプロとコードレビュー大会

さて、午後からはペアプロの時間でした。お題は Semantic Versioning(参考: Semantic Versioning 2.0.0 | Semantic Versioning)です。

1時間半程度のペアプロをしてその後全員参加のレビュー大会をする、という流れを二回繰り返しました。

載せて良いのかわかりませんがその時のペアプロしたものと、あとからいろいろと変更を加えたものをおいておきます。

github.com

私はpython3 + unittestを利用して課題に取り組みました。 行った感想としては

  • ペアと一緒に要件を書き出していって、書き出した順に実装していたのですが、もう少し順番を考えたほうが良かった。
    • 今回はスピード勝負ではないので問題ないといえば問題ないんですが、一番複雑なところから手を付けてしまった。
  • 要件の洗い出しについては「近いところを詳しく、遠いところはざっくりと」ということをt_wadaさんがおっしゃっていて、非常に重要な感覚だなぁと思いました。色々な要件を実装する際に最初からすべて考えようとすると、前提条件の実装が動いていないので非常にコストがかかる感じがしました。そろそろ実装するぞ(=近い所)というところだとすぐ実装を決められます。最初から全ての要件を綺麗にしようとすると予測可能性があれということをこの時間のうちに体感できました。
  • python的な書き方に少々つまずき、綺麗でない実装になってしまった
    • ちゃんとgitに上がっているやつは直しています。commitログをみるとすごい複雑なif文が表れますw

全体的な感想

  • Testを書くこと自体もそれほど得意ではなく(やったことはあるが体系的に学んだことがない)、TDDに関しては完全にノータッチだったのでイチから学ぶ機会を頂いて非常に良かった。
  • 単純にペアプロしてレビューするのが楽しかった。
  • 企画してくれた先輩にとっても感謝します。

マイグレーションコンペティション 2018で優勝してきました

マイグレーションコンペティション 2018に参加して優勝しました!!!!!!!!!111

マイグレーションコンペティション 2018 winter

詳細は以下のURLより御覧ください

日本MSP協会のコンペティション担当による、運用技術を競うコンペティションです。次代を担う若手運用技術者同士の交流・競争を通して日本のMSP事業者における運用技術の向上を目的としています。

とのこと。

今回は EC2の1インスタンスにいるWebAppDBサーバその他もろもろをAzure上に移行する、というお題でした。

優勝のご様子 f:id:renjikari:20180129000822j:plain

メンバー

運営が当日ランダムでチームを組むのですが、チームメンバーはid:kani_bさんと大阪からいらっしゃっていたokazakiさんでした。 主にid:kani_bさんがDB周りの移行とチームマネジメント(リーダー)、okazakiさんがWebAppの移行、私がメール周りの移行を担当しました。 メール周りなんて大学生ぶりにさわるのでまじで怖かった

お題詳細

今回のお題はEC2サイトの移行ということで、移行元サーバには以下のような物が稼働していました。

最終的な方針

私達のチームでは最終的に以下の方針で移行を進めていきました。

  • ミニマムなところから移行し、お題の必須項目を完璧にやる
    • これができたら+αをやっていく
  • 具体的な方針
    • サーバ切替時にはメンテナンスを入れる
    • バージョンアップは無理せず, CentOS7.4のデフォルトパッケージでyumインストールされるものを利用する

覚えている感じのタイムスケジュール

今回は競技時間が10:30 ~ 17:00でした。

11:30 頃まで

自己紹介と移行元サーバの把握をしていました。また、リーダーの提案でgithubリポジトリを作成し、issueで進捗管理をすることに。(これとても良かった) また、予算がいくらくらいあるのかを担当者に確認し、現行の+-20%程度にしてくれという回答をもらいました。 この時点でAzureを使うと冗長化できなさそうかな〜みたいな話をしていました。

13:00 頃まで

途中ご飯を食べながら方針を決め始め、それぞれの役割分担を決定。このときはまだ、無停止でサーバ切り替えできないか模索していました。確か、MySQLを旧新サーバでレプリケーションしてデータ移行させれば無停止でいけるんじゃ?みたいな議論をしていたと思います。

担当者にはDNSTTLを60秒にしてもらうことと、サイトでなんらかの作業がある場合は14時までに実施してもらうよう連絡していました。(商品追加の作業があると言っていた気がする)

14:30 頃まで

チームとしてはそれぞれの移行をやっていましたが、MySQLのrootが取れないことが判明。root取れないとレプリケーションが組めないし、root取るためにはMySQLの再起動が必要なのでここで無停止を諦め、メンテナンスを入れてrootを乗っ取ることに(14:00頃)

私はメールサーバの移行をしていまして、saslを触ったことがなかったので、そこを一旦無視してPostfixDovecotの移行をやっていました。たぶんここらへんで/etc/postfixと/etc/Dovecotをごっそり移し替えて起動するくらいまではできていたような気がする。

15:30 頃まで

この頃にEC-CUBE及びメールサーバがほぼほぼ移行完了し、そろそろ切り替えれるんじゃないかみたいな話になっていました。

私はというとsaslをググったらそんなに大変そうじゃなかったので移行元サーバをまるぱくり、間違いがないかpostconf -nやdovecot -nを読んでいたのですが、virtual mailboxの設定をしていないことに気づき、/var/spool/vmail(だったような)の移行を開始。 ディレクトリ自体はそのままrsyncしたんですが、移行元サーバに/var/spool/vmail/をホームディレクトリとするvmailユーザがいたのでやり方に不安を覚えつつ/etc/passwdと/etc/shadow, /etc/groupを移行して、vmailユーザを作成しておきました。(これどうすればよかったのかな…)

16:30 頃まで

担当者に連絡し、16:00からサーバ切り替え作業とDNS切り替え作業を実施。移行が完了

17:00 まで

残りの時間で、id:kani_bさんがAzureのバックアップを作り、okazakiさんを中心に引き継ぎ&実施した内容のドキュメントを作成(Google Docsで作った)、私はドキュメントを手伝いつつlinuxユーザの整備などをしていました。

全体的な感想

ながながと書きましたが、だいたいこんな感じで進めていて、優勝をいただくことができました。 率直に言って最高だった(勝ったから)。 一番良かったのは、必須項目以外はやらない、位の勢いでもろもろを切り捨てる方針で進められたことだと思います。 あとid:kani_bさんのエンジニア視点のマネジメントが最高だった。 ぜひ来年も遊びに行きたいと思います。