#code_kaizen コードの改善について語り合うコード改善 meetup #1に参加してきたまとめ

公開日：2016/05/27 最終更新日：2016/05/29

チームでコードの改善を進めていくにあたって工夫している点を話し合うコード改善 meetup #1に参加してきたのでそのまとめです。

ちなみに、発表後にQAの時間がありましたが、発表者だけでなく、参加者同士が質問、回答しあうような形で開催されました。

circleci 小ネタ集

Twitter

https://twitter.com/rela1470

Jenkinsからcircleciに移行した
PHP 5.5 PHPUnit GitHub circleci FREE Planで回してます

複数gitのclone

circleciには他のgitをcloneする機能がないのでcircle.ymlで頑張った
- コマンドを指定できるのがあるのでgitコマンドをベタ打ちした
cloneする権限はDeploy keysをuser keyに差し替えて紐付いた権限を取得している

ビルドの手動実行

circleciはスケジュール実行などがないが、REST APIが充実していて、課金機能以外は全部できる
- 逆にAPIしかない機能もある
branchを指定して新ビルドを行うAPIをcronで叩いてます

カバレッジ集計

XdebugをONにしてcoverage-htmlで$CIRCLE_ARTIFACTSに書き出せばHTMLファイルが吐き出せる
しかしビルドに長時間かかるので、短縮するためにpush時に毎回やるのではなく、引数で明示的にした時だけ集計するようにした
注意点として、XdebugをONにするとPHPUnitなど重くなるのでカバレッジを取得するときだけONにすること
build_parametersを付与してビルドしてます

システム簡略化

circle.ymlにシェルも書き込みが出来ます
- yamlのブロックスタイルは改行をそのまま使えるのでコマンドを書きやすくなる

つらくないコードレビューの運用

GitHub

serihiro - Overview

https://github.com/serihiro/

Software Engineer. serihiro has 30 repositories available. Follow their code on GitHub.

おすすめ資料：デキるプログラマだけが知っているコードレビュー7つの秘訣
レビューおじさん問題
- コードレビューあるあるとして、チームに1人仕様に詳しい人がいてその人がレビューばかりをしている
- productionでバグが見つかるとコードレビューおじさんがプレッシャーをうける
特定の人だけがレビューしていると…
- コードの知見が共有されない
- メンバーのレビュー力が育たない
- 属人的でスケールしない組織になる
なぜうまれるか
- 古いサービスで発足時のメンバーじゃないとわからないことが多すぎる
- 実力差が大きい
- なんとなく〜さんがやらないとダメな気がする
- 最初に作った人がレビューしないとダメな気がする
- おっさんがレビューしないとダメな気がする
解決法
- 新参メンバー知らない→学べ！
チーム全員で提案しよう！
- 誰もが互いのコードをレビューすると、プロダクトの責任が共有され、コードの仕様を広く共有される
しかし、現実は忙しくてレビューできなかったり、レビューできる自信がないなどといってしてくれない
しかし、レビューはやらないとできるようになるのは難しい

コードレビューを回しやすくするtips

レビューして欲しい内容の説明を詳細に書くように仕組み化する
- PRのdescriptionをテンプレ化する
- PRが解決する問題、背景、TODOを書くようにしている
- PRするときに勝手に突っ込むように仕組み化している
レビュアーはhubot-reviewr-lottoを使って公平に割り振ってもらう
レビュアーを気遣う
- 厳しいと思ったらレビュアーに「わかりづらかったら質問下さい」と声をかけてみる
- 不明点を聴きやすくする雰囲気作りが重要
レビュー=勉強の話として認識する
- 指摘することがなくても仕様でわからないことがあったら積極的に質問する
- 質問するだけでもレビュアー・レビュイー双方の気づきにつながることが多い
- 指摘しないといけないというプレッシャーがなくなる
- おすすめ記事：自信が無いエンジニアこそコードレビューをするべき

QA

【質問】チーム全員でコードレビューをしようとしている流れを作っているが、PRがたまっていってさばけない問題が発生している。どうすればいいか
- あまりPRが貯まることはないが、締切時間を区切って回している
【意見】レビューに時間が取られて進まないという問題があって、レビュアーを徐々に増やそうと、ペアレビューをトライしてみたが、疲れて続かなかった。レビュアーとレビュイーがペアになってレビュイーのほうが説明しながら突っ込んでいくといったことをした。
コードレビューが最優先のタスクとなっている
- レビューが遅れれば遅れるほど鮮度がなくなっていくので早めに返していくのがいい
- どうしても忙しいなら他の人にタスクを投げる
【質問】メンバー構成やプロジェクトの規模はどれくらいか？
- サーバサイド5人（serihiro様）
- 10人いるが、プロジェクトが大きい
【質問】レビュイーは複数人でやっているか？
- 【意見1】全員にPRを投げていて承認を得てからマージしている
- 【意見2】8プロジェクトを10人で回しているが、PRは1人ずつみている
【質問】jenkinsからcircleciに移す時に課題はあったか？
- オンプレミスでプラグインが50個も入っていて移行したが、移行によりプロダクト毎にPHPのバージョンを変えることができたので恩恵のほうが大きかった
【意見】週3時間継続の時間をとる風呂部をやると1ヶ月で1日とめているくらいになるが、1日分有給をとってるつもりで実施している
- 月に3個くらいは問題が解決している
【質問】コード改善しないといけないが、中々取り組めない人はいるか
- ビジネスサイドにエンジニア文化をわかってもらうのが大変
【質問】風呂部みたいな、週3時間改善をやっているみたいなことやっているか？
- メルカリを真似た（メルカリは月1日止めている）
【意見】コードを改善してデグレを出さないのが大事だと思っている
- 自分たちでQAを回してQAチームに負担をかけないように徹底するのが大事

テストで疲弊しないためのふわっとした話

Twitter

https://twitter.com/ushigara_nekoe

全体像も現在地もわからないと迷子になる
- 全体像：条件の組み合わせを網羅した情報。テストケースの一覧ではない
  - テスト項目：条件ABCが成り立つときXはYZである
  - テストケース：手順1を実行すると期待値は2になる
- 現在地：どの条件をテストする/しないという情報。テスト実施するたびに変化するもの。
  - 例えばリリース前のテストだとテストする項目は直したところだけなど、テスト項目が変わっていく
全体像はどうすれば可視化できるか
- 現実に起こりうる条件の組み合わせをマトリックスで表現するが、真面目に全部やると大変
テストする・しないはは以下の情報を元に優先順位付きで決める
- どんな実装を行ったか
- どんな仕様にしたか
- ユーザーが何をするか
- どんなバグを防ぎたいか
よくある間違い
- 自動テストを闇雲に導入して安心する
  - 自動テストは全体像を明確にした上で頻繁にテスト対象となる部分のテスト実行コストを下げるために導入するもの
- 専任のQAチーム、テストチームに丸投げ
  - 組織としては正解だが、専任のチーム作ったから終わりではなく、専任のチームの中で全体像が書けるチームを作ったりなど組織づくりをしていくべき

QA

【質問】単体テストの話か？品質テストの話か？
- 品質テストです
- QAは機能的にちゃんと動くのと、ユーザビリティもチェックしている
【意見】セレニウムを使えばWebアプリでもリリースの際の違いをチェックしやすくなると思われる
【意見】お金に関するところやログイン周り、ユーザが登録して申込むところは多めにテストしている
- 不安がないところはテストをスキップしたりもして割り切っている
- バグが起こっても影響が少ないところはバグが起こってから直したりしている
【質問】基準はどうきめるか？
- チーム全員で話して決めた
【意見】全体像をマインドマップでみんなで出してから絞ったりしていった
【質問】クレームが来る前に早めに来づける仕組みをつくっているか？
- pushうつAPIを叩き続けるbotを作って、遅延が起こらないかチェックをしたりしている
【質問】QAの規模はどれくらいか？
- QAは一人
- エンジニアが7〜8人のときに一人入ってきた
- 一人がテスト計画を作るがテストをするときは全員でやる
【質問】QAが来る前はテスト計画は誰か作っていたか？
- エンジニアの誰かが作っていた

コード改善ことはじめ

SatoshiHonda様

技術的な負債を返す方法はたくさんあるが、全部はできていなかったことが多々ある
営業が強い会社に所属した時の話
- 初期
  - コストを抑えるために安くする作り
  - エンジニアが作っていない
- 〜中期
  - 利益になることが軸になってスピード優先に。
短期的な施策の比重が大きくてなかなか施策に取り組めない
営業、マーケ、企画、エンジニアがそれぞれプロダクトをよくしていくが、営業、マーケ、企画は交渉がうまい
- エンジニアは交渉事が苦手なことが多い
- いつのまにか、エンジニアが一番下のトップダウンな構造になっていることがよくあった
部分的な最適化が始まり、本来やるべきタスクが後回しになってしまう
- スピード優先になると品質が後手になる
- 既存コードの再利用をして質が上がらない
- 品質改善の時間が取れない、継続しない
エンジニアの役割
- サービスを安定稼働させる
- 改善のPDCAサイクルを高速化する
- ビジネスの変化に柔軟に対応させる
ユーザへ継続して勝ちを提供して対価を得るビジネスとしての改善
組織が成長していくうえで負債を産んでしまったという考えに行き着いた
ビジネスというものに対して価値を提供することができないのは本末転倒
短期中長期とバランスよく改善は入れる必要がある
- 負債はおきる前提だが、中長期的に改善していくのが大事
参考記事：スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ

どういうふうに課題を解決したか

課題認識の共有とオープン化を始めた
- フェイス・トゥ・フェイスでコミュニケーションの機会を増やした
- 課題の情報をオープン化はissueや日報を活用した
課題の認識はみんな同じだった
技術の標準化を進めています
- 勉強会を開いている
- 教えて学ぶというのが大事
- リーダブルコード実践するなど
- 勉強会を通じてコミュニケーションを取る機会を増やした
プロダクションコードをもとに読みやすい、読みにくいと感じたコード、疑問点、気をつけたいことをディスカッションした
- リーダブルコードには名前付けの重要性、早期return、中間変数の利用など書かれているが、やってみると話題が膨れ上がっていい意味でいろんな話題が出る
CodeSnifferをやってみた
お問い合わせが頻繁になってきたので、フォームを用意して実績値として対応した時間を書くようにした

最後に

組織で起こった負債をみんなで認識することが大事
自発的なアクションとしてまずは手を上げていくべき
実現しているということは組織としての共通認識でもある
ユーザに価値を提供し続けるために改善をしていくことが大事

QA

【質問】コードの指摘が入ってむっとした時どうされてますか？
- 歴史的書き方の前置きをいれてコードの書き方を進めたら丸く収まったことがあった
フェイス・トゥ・フェイスのコミュニケーションは大事だと思っているが、リモートワークしている人がいたらコミュニケーション量が違うと思うが、どうやってカバーしているか
- 【意見1】リモートでもいいと思っている人は情報を理解する速度が速いのでコミュニケーション量が少なくても必要な情報が伝わる
  - だめと否定されてもへんなふうに受け取ったりしない
- 【意見2】極力馬鹿な言い方をしている
- 【意見3】月1で飲みに行くのはどうか？
- 【意見4】リモートワークしていた時にskigle？というツールがあって、3分ごとにキャプチャが流れてPCがいるかどうかのチェックができ、通話したかったら気軽に通話ができる
【質問】勉強会をやらないといけないと思っているが、上と下に開きが多く、題材を決めても興味のない人も出てきてしまう。どうやって学習の題材をきめればいいか？
- リーダブルコードがオススメ
【質問】手を動かさないと続かないが、そういう人に対して続けてもらういい方法はないか
- 【意見1】いろんな題材を試したり、業務に近いものを試したりと、継続して回数を繰り返せばいいと思う
- 【意見2】業務で必要とされている課題をお題にするといいと思う
【質問】コードでディスりあってチームがちぐはぐになることはあるか？
- 【意見1】カバレッジを下げた人をディスったりするのはある
- 【意見2】静的解析でrobocop, eslint, csslintなどをいれて、ガチガチにかためている