yuwji.hatenablog.jp

雑多に色々

2018/12/17 DevLove関西「レガシーコードに立ち向かっている者達の話」に参加しました

勉強会/カンファレンス

※2018/12/21 市原 功太郎(@ichi_taro3)さんが資料を再アップされていたので更新しました。

2018/12/17のDevLOVE関西「現場でレガシーコードに立ち向かっている者達の話」に参加しました。 スピーカーお二人とも資料公開頂いているので、資料にないことや気になったことを中心にメモを残しておきます。
※但し言語に特化した質問はまるで意味が分からなかった…。

https://devlove-kansai.doorkeeper.jp/events/83358

そもそも自分のコンテキスト

  • 1次受けSIer
  • 開発はほぼ全て協力会社様依存
  • テストを書く習慣は全くない　

レガシーコードとは

テストコードがないコードをレガシーコードと言う ※レガシーコード改善ガイドより

開始前の情報共有・ヒアリング

全体的な所感

  • UTから始めるのが良い
  • 新しい機能等、変更箇所からテストコードを書いていくのが良い
  • テストに詳しい人がいないなら、詳しい人にセミナーなりワークショップなりやって貰うのが良い
  • 知らないと、今のやり方が最良だと思ってしまい、大変さがあっても受け入れてしまう。
  • まずは知ることが大事。
  • 物理的・心理的に関わらず、困っていることを簡単にできるとなると、一気に普及する。

セッション１：レガシーコードに向き合ってみた話

市原 功太郎(@ichi_taro3)さん　＠株式会社MonotaRO

スライド補足

  • 基本的に単体テスト(UT)を自動化していった話
  • 17.ユニットテスト通過がリリース要件になった
    テストをメンテしないといけないという雰囲気作りができた
  • 18.テストができるローカル環境を構築
    開発PCはWindowsが多く、対してテスト環境はLinuxの共用サーバーだったので、作って即テストがし辛い環境だった。
    VagrantとAnsibleでローカル環境を作ったことで、気楽にテストがしやすくなった。
    この辺りで突然皆がテストを書くようになった。つまり、書き方ややり方が分からなかった為にテストコードを書いていなかったと思われる。
  • 27.衝撃
    今までは、何人かで変更していたコードをmergeしてからテストをしていたので、動かしてみて初めて不具合に気付き、原因がどこにあるか分かりにくい事態が頻発していた。（何か分からんけど上手くいかないですー状態）
    Commitの度にテスト出来るようになったので、どこが原因で失敗するか分かりやすく、手戻りが少なくなり、全体のスピードが上がった。
    ※カバレッジとかはまだ見れていないとのこと。

質問

かなり多くの質問が出た為、メモしきれておらず、多少再構成しているので、意図からズレているかもしれない。ニュアンスとして読んでいただければ。

  • リファクタリングしたいけど、テストコードがないためにリファクタリングがし辛い状況をどうしているか？
    書き換える部分のテストだけを先に書いて、それからコードを書き換えている。つまり、テストを先に書くようにしている。
    特に、Python2系から3系に順次変更している中では、変更しないといけない箇所は限定されていて、かつ、放置できない＝書き換えないといけない状況下にあるので、テストすべきところは分かっているので、このようにするメリットがある。
    ※この後、ダイアログで話した方も同じようにしていると言っていたので、よくやる方法なのだと思う。

  • どうにもテストが書けないコードはなかったか？
    諦めたところもある。
    例えば、機能テスト・E2Eは手動テストにしたし、単体テストの中でも、APIのIFに関わるところ等は、外からAPIを叩いてもテストになるから、対象外と判断したところもある。

  • 責務をバラすとかはどうしたか？
    頑張って全てをやろうとすると、スタブ・ドライバ・パッチでぐちゃぐちゃになるので、難しいところには手を付けていない。分離しやすいところや、わかりやすいところを対象にしている。

  • 参考書籍は？
    レガシーコード改善ガイド。全体の方針を示してくれるし、時折応援してくれる。

  • 乗り気じゃない人をどうした？（事件とか工夫とか）
    衝突はあまりなかった。辛いことを辛いと言える環境にして、必要だから議論できる状態だった。

  • 必要ないやん派の上司はいなかったか？
    上司が推進派だった。（参加されてました）

  • E2Eから攻めて行く方が良い場合もあるのではないか？
    両方から攻めていくのが良いと思う。
    ちなみに、レグレッションテスト用にE2Eは存在はしているが、完璧ではないし、落としている機能もある。単体テストとは、タイミング・役割が異なる感じで使っている。

    • E2Eはリリース単位で実行している。
      • リリースするブランチに対して流す
      • 問題なければリリース
    • 単体テストはコミット単位

  • テストケースの粒度・ノウハウ
    浮動小数点の演算とかはテストコード化しておらず、if分岐等ロジック部分を見てる

  • ビジネスサイドからの抵抗はなかったのか？

    • 現場のエンジニアの体感としてはなかった。
    • テストコード書くということは説明していない（わざわざ言わない）
    • 聞かれても、「人間だから書くのが当たり前」と言い張った

  • 単体テストをやることでITの量や質が変わったりした？

    • Excelの手動テストは激減した
    • 手動のテストは、エビデンスを捏造できる以上、テストした本人しかテストしたことを証明できない。

  • テスト専門家・職人・QAを雇う、という方向性にしなかったのは？

    • 品質管理工程が増えるので、遅くなるのでは？
    • 小規模チームなので、品質担保しやすい
    • 上司の方曰く…
      • QAエンジニアを上手く雇えなかった
      • また、仕様が明確でないと、QAを雇っても質問が返って来るだけで進まない現象が発生する懸念があるので、仕様を明確にするのが先決という判断。

セッション２：レガシーチームでテストを書いた話

谷口 英司(@eijit)　＠株式会社ピクセラ 資料 speakerdeck.com

スライド補足

質問

残念なことに、質問内容がよく分からない物が殆どだった…勉強不足…

  • 勉強会は業務時間内でやった？
    テストに関する勉強会は、業務時間内で押し通した。 リーダブルコードの勉強会等は業務時間外でやっている。

  • テストに詳しい人がいない場合どうしたら良い？

    1. テスト駆動開発を読む
    2. Rails Tutorialにはテストに関してのチュートリアルもある。
    3. 一番手っ取り早いのは、専門家呼ぶこと。
      • 手っ取り早いがテストを書くんだという心を持っている人は必要
      • 専門家はググったり、SlideShare等でスライドを検索したりする。

  • ペアでコーチした人の手離れはどうか？

    • ベテランの人がずっと付いてはいて、フォローしている。

Dialog

Dialogについて

メリット・デメリットを語るような議論とは異なり、お互いに問いかける等して深掘りして、考え方や見識を広める為の場

Dialogで出た話題

  • テストのコード化が目的と化したテストおじさんが存在する。微に入り細を穿つようなテストを自動化する意味があるのか、きちんと考えてテスト化対象を見極めた方が良い。
  • 自分のグループ・チームから、小さく始めるのが良い
  • 知らない、という人にとっては、テスト書かないのが普通
  • 詳しい人がいないという状況では、中途採用（外の文化）のメンバーによってテスト文化がもたらされることもある。
  • ローカルで仮想でもテストできる。vagrantとかdockerに詰め込んでおく
  • セッション関連もモックで適当に詰めてやれば出来る
  • 画面テストだと、selenium/geb/groovyでやる
  • utからがやりやすい

以上です。