コード品質向上のいろは – 先達に学ぶ実践例 Lunch LT

https://findy.connpass.com/event/300912/

に参加した聴講メモです。

LT①『「コードがむずかしい」からの脱却』 株式会社メルカリ 濱村甚平(@jinpeih )

資料

https://speakerdeck.com/jimpei/kodogamuzukasii-karanotuo-que

途中から参加したので、メモは途中から

「コードが難しいから改善したいので時間ください」だけだと、相手には伝わらない。

そのため

• それはどのくらい悪くて
• 改善するとどのくらい効果があって
• どのくらいの時間が必要なのか

などの指標が必要。

複雑度の指標

SonarQube 等のツールがあるのでそういうのを活用した

ただ、だからといって数値が悪いイコール絶対改善！というわけでもない

複雑度が高いからといって、そのコードを滅多に変更しないなら改善してもあまり嬉しくない

また、複雑度はやり方によっては回避できる。

例えばネストさせない代わりに関数を分割させまくると複雑度の数値は下がるが、

それは複雑度の低い複雑なコードなだけである。

指標を下げることが目的ではないので、あくまで補助的な使い方。

ひとりで書くのは難しい

ペアプロで意図を共有しながらコードを書くと、少なくとも二人の間では意図が通じてる

Q&A

Q1

他の人や他のチームの数値が見えすぎると、良い部分はある反面少し競争のような形になってしまうなとも感じています。

どこまでの人と数値を共有するかなど、意識されたりしていますか？

A1

比較するものではないので、競争とかにならないように数字数字という扱いにしていない。

共有は広く共有したほうが、参考になるのでいいと思う。

Q2

認知的複雑度を数値化してからは、やはり不具合は減ったのでしょうか？

A2

これは簡潔に yes/no かは言えない。というのも、数値化した後にチームを離れることもあるし、

まだ数値化したあとに不具合の数がそれによってどうなったかを追っていないというのもある。

不具合が減った要素はいろいろあるので、そこまで追うのも難しいかも。

ただ、将来的には、不具合を減らしたいから数値化しているというのも目的の1つにはある。

LT②『なぜリアーキテクティング専任チームを作ったのか』 株式会社アンドパッド 白土慧(@kei_s)

資料

https://speakerdeck.com/kei_s/naze-riakitekuteinguzhuan-ren-timuwozuo-tutanoka

現状のアーキテクチャ

中心となる Rails に付随する形で各プロダクトが存在

Rails は8年選手

Rails のライブラリアップデートが滞っていた

• ライブラリの開発が停止してたりしたが、そのままだった
• アップデートしようにも、そのライブラリは複数のチームに跨っているので、1つのチームで責務を持ちにくい

これによって、古いライブラリに依存したコードを書かなければならなく、メンテナンス性が低下。

OSSのメリットもあまり受けられない状態に。

リアーキチームの発足

• 特定のサービス等には責任は持たない。そこは既存のチームが担当する
  • その代わり、チーム目線だと難しい全体目線で考える部分を担当
• 共通利用されているところとか担当
  • 逆に、特定のチームでのみ使っている部分とかは対応しない

さじ加減

「ライブラリアップデートは、リアーキチームの仕事」としない。

特定の人の仕事ではなく、改善意識は全員が持つべき

Q&A

Q1

お話であったように、エンジニア全員で改善をするというマインドが失われないようにするための取り組みはありますか？

専任チームを作ることで、各自から課題が出てこなくなるリスクもあるなーと

A1

わいわいと「ここ改善したいよね」みたいな話をしたり

リアーキチームに限らず、改善活動するのは良いことである、みたいなのを浸透させるようにしている

Q2

ライブラリアップデート時の影響範囲調査の進め方など、専任だからできるメリットをもう少し聞きたいです

A2

専任チームのいい例は、専門でそこの領域に調査の時間とかとれたり知見がたまるのが良いと思う。

逆にプロダクトチームほど知見がないので、「この挙動ってどうなってる」「こういうテストを考えてるけど抜け漏れないかな？」

みたいなコミュニケーションを取るようにしている。

LT③『10年モノのAndroidアプリのコード品質を改善していく、3つの取り組み』 Chatwork株式会社 奥澤 俊樹(@okuzawats)

資料

https://speakerdeck.com/okuzawats/4de89f92-6dff-4d77-8701-10882ff27be7

なんでコード品質を改善したいのか

• メンバーやチームが増えた
• コード品質が開発速度に直結
• 改善したい

コードレビュー

「自分がコード品質について誰よりも考えレビューすればよい」と思っていた。

が、自分が門番になってしまうと開発速度が落ちると思ったので、そうはしなかった。

自動レビュー

静的解析ツール

• danger
• ktlint
• android lit
• sonarcloud（今日の話はこれに着目）

メリット

• コードが怪しいところ（Code Smells）の検出
• 複雑度を出してくれる
• 閾値を満たさないと CI が落ちる

勉強会をするようにした

https://creators-note.chatwork.com/entry/code-readability

ガイドラインの作成

Kotlin のスタイルガイドみたいなのを参考にした

できれば Lint がスタイルガイド通りに反応してくれたら嬉しいので、検討中

Q&A

Q1

SonarCloud検討しているのですが、他に検討したツールや自作していたものなどありますか？

また、どういう観点で使う判断をしたか参考に聞きたいです

A1

もともとある程度SonarCloudの知見があったから使った

Q2

ストリームアラインドチームメンバーをどうアサインしたか気になります

A2

それぞれのエンジニアがどういう仕事やキャリアにしたいか等で検討した

LT④『DMMプラットフォームにおけるコード品質を改善する取り組みの理想と現実』 合同会社DMM.com pospome(@pospome)

資料

https://speakerdeck.com/pospome/dmmpuratutohuomuniokerukodopin-zhi-wogai-shan-suruqu-rizu-minoli-xiang-toxian-shi

レガシーシステムのリプレイスをするよ

コードの品質を高く保って、開発速度を改善したい。

品質を高く保つための持論

リファクタリングや静的解析ができても、設計スキルが高くないと品質は上がらない

が、設計スキルが高いエンジニアを雇うのも育てるのも難しい

そこで、レビューシステムの導入

各チームのコードを設計スキルの高いエンジニアがチーム外レビューする取り組み

うまくいく自信があった

が、それだけだとうまくいかなかった

なぜなら、チームによって課題が様々だから

• リファクタリングの時間確保
• 良し悪しの判断が難しい
• 意思決定権持ってる人への、品質に対する理解

まとめ

組織が大きいとコード品質改善は大変。

特に意思決定の部分が大変なので、戦略を持ってやらなければ。

Q&A

Q1

pospomeさんの考える「設計スキルが高いエンジニア」の基準をお伺いしたいです！

業務知識に詳しく、アーキテクチャ図を描ける人、静的解析に詳しい、など

A1

SOLID 原則とか分かってたり、もちろん業務知識も必要

図を書くためのスキルみたいなのはあまり必要ないかも。

Q2

専任チームを作る話が本日多数ありましたが、

最初にチームを組成した時に、他のチームへどのように介入したか、より失敗談や工夫した点などがあれば聞きたいです。

A2

まずはレビューやらせてくれという姿勢で入った。

失敗談の話になるが、結局チームのテックリードや意思決定者を巻き込まないといけないので難しかった。

参加しての感想

各社、ある種似たような悩みを抱えていて、それに対して社内の状況に合わせたアプローチを試行錯誤しているんだなぁと感じた。

そういう意味でも、今回のような会は各社の知見を共有して自社に活かすことに繋がるので良いなぁと感じた。

各社概ね共通していることは

• 現在の状態を整理
  • 課題は何か
  • 必要であれば静的解析ツール等を使って数値化、見える化
• 対策を検討
  • どこまで対応するか
  • 専門チームの立ち上げ
  • コードレビュー
  • 品質意識の浸透
• 対策を実行したり、更にブラッシュアップしたり
  • 指標に対する考え方
  • やること・やらないことを明確に
  • より活用にするためにどうするのが良いか
  • チームの課題に合わせて動くように

などがあるなぁと思った。

当たり前かもだが「これが最近流行ってるやり方！」「とりあえずこれやっとけ！」みたいなのがある訳ではなく

課題が何で、どういうゴールを想定していて、理想の状態にするために何をすればよいかを考え、改善し続けるという、課題解決の基本的な考え方と同じだよなぁと思った。

その中で、テクニカルな部分や参考になる手段として静的解析ツールの導入や、専門チームの設立などがあるなぁと思った。

 

SonarCloudは触ったことないけど、コードの怪しそうな部分（Code Smells）を教えてくれるのが気になった。

リアーキテクチャことはじめ～事業成長を最大化するための技術選定と登り方～

https://flexy.connpass.com/event/259853/

に参加してきたので、そのときのレポートです。

 

レガシーの定義とは？

今回のレガシーの定義では

と定義します

ここで大事なのが４で、簡単な機能追加に時間がかかってしまうことがある。
そこで、リアーキテクチャが必要になってくるが、
単に「このシステムは今ここがよくないのでこうすべき」というのは誰でも言えるが
将来の事業成長や拡張性を見据えてどうするか、ということも考えられるのが必要になる。

そこで、今日はリアーキテクチャをどのようにやってきたとかの話を事例を交えてする。

各社サービスの背景からみるリプレイスの事例

事例1

バージョンアップしたいが、なかなか難しく、負債が高まっていっていたため、リプレイスを検討した。

リプレイスを検討していると
現状のシステムを分析した結果、複数の境界線を跨っていることがわかった
そこで、記載しているような設計にした。
稼働年数10年とあるが、システムをリプレイスするのは稼働年数と同じくらいかかる。
今1.5年ほどリプレイスを進めているが、まだ序の口。

とある業務フローがあり、
伝統的なシステムだと、とあるデータを同じデータとして扱いたいが
業務フローを精査してみると、違うデータとして扱う必要がある。
例えば、セブンイレブンにあるお弁当とかは、全部同じものではなく、店舗によって近い工場で造られている
お弁当の申請をするとそれはパートナーが登録したデータだが、申請されたデータを承認するのは別の工程で行う。
それを処理するには、申請されたイベントから派生させて行うのが良いとなり、そうしている。

事例2

最古の commit が 2012 年だが、それ以前にも何かあったらしい。
一番社歴が長い人でも5年前で、その人に歴史を確認しながら進めることもある。
中身を見ていると、名前がおかしなものもちょいちょいある。
改修の際に調査が長引いてしまいデリバリーが遅くなることがあり、リプレイスを検討した

1日30分くらいつかって地道にLaravel に載せ替えることもしていたが、長続きせず頓挫することもあった

現在は本腰をいれてリプレイスを進めている。
いま進めているリプレイスも何年かかるか分からないが、進めている状態

リプレイスする際に、ちゃんと技術選定していかなければならない。
Rust を採用した理由は？と聞かれて「流行ってたからです」となると
未来で困る人がその理由は聞きたくないだろう。

事例3

読み取りと書き込みは別要件なので、それぞれ別個に最適化したような設計をした

事例4

内部事情を知らないといけないので、入った人が戦力になるまで時間がかかる

コードベースでモジュラーモノリス化した

事例5

マイクロサービスアーキテクチャ化をすすめている

マイクロサービスアーキテクチャにするとビジネスが推進されますよという見出しの記事がよくあるが
それを行うには何年単位という時間が必要になる
ドメインを分析したり、業務フローを精査したりなんなら業務フローを変えたりする必要もある
もろもろ全部考えた上で、決断する必要がある。
なんのためにマイクロサービス化するのか、技術ファーストではなく、ビジネスのためにどうするのか、というのを考える必要がある。

Q&A

Q1

リプレイス後のアーキテクチャはどのように決められましたか？トップダウン、ボトムアップなど。また、ボトムアップの場合で、メンバー間で意見があわない場合はどのようにアーキテクチャを決定されましたか？

A1

あらたまさん

トップダウンだった
現場で、どうすればいいか分からないという状態だったので、トップダウンで行った
また、リプレイスというのは向こう数年にわたって投資をしていくという判断なので、経営判断が必要になる
のでボトムアップだけだとうまくいかないと思う。
経営的に、いまここに投資するべきか、という判断をしている

ytakeさん

トップダウンだけでいくというのはあまりやっていない
メンバー間で意見が合わないばあい
スキルセットが合わない人ももちろんいるので、ディスカッションはする。
が、技術レベルを下げることはあまりしない。そこを下げてしまうと、周りが面倒をみる必要が出てくるし、会社の技術レベルが下がってしまう。
ので、習得してもらうようにしている

Q2

言語やフレームワークを大きく変更したとき、メンバーに対するキャッチアップはどのように実施されていますか？（ex. 週1で学習時間を設けているなど）

A2

あらたまさん

輪読回をしたりしている

ytakeさん

技術習得が難しい人もいるし、本だけだとわかりづらいところもあるので、質問があれば自分が噛み砕いて答える、ということをやっている
エンジニアだけに限った話じゃないが、技術習得のアップデートというのは当たり前ではあるので、そういうのを自主的にやっていけると良い

Q3

リプレイス中に仕様変更がある場合、どのように取り込んで開発していますか？

A3

あらたまさん

リプレイス中の使用変更はブロックするようにする

ytakeさん

やらないといけないことあやるようにしている

Q4

退職者が多いことによる辛み=技術的負債とした時に、リプレイスに時間が数年かかるとなると今作っているものを以下に負債にしづらくするかというのが大事だと思っています。そこに対する取り組みとかありますか？(ドキュメントは工数がかかりすぎたり、陳腐化する懸念がありどう考えているか伺いたいです)

A4

あらたまさん

ドキュメントはコンフルエンスとかにたくさん書くだけではなくて、コードコメントとかも大事なドキュメント
細かくドキュメントを残していけるかが、システムの寿命にもなると思う

ytakeさん

陳腐化するのか防げないので、定期的に確認する必要がある。
書いた人の考えていることの一部を読んだ人が得られるので、劣化した情報が伝わっていくので陳腐化は防げない
ので、定期的にメンテナンスする必要がある。

まとめ

ytakeさん

作るものだけを考えるのではなく、技術ファーストではなくビジネスのことも考えよう

あらたまさん

サービスや事業に対する理解を社内の人とたくさん話をして解像度を上げていく必要がある
自分の考えた最強のシステムを作りたくなる気持ちもあるが、そこを抑えて考えていく必要がある

参加しての感想

イベントの中でも出てきましたが、リプレイスはしなくて良いのであればしないほうがよく

日頃の業務の一部をリプレイスに投資するという判断をしなければならないので

ある程度ストレスがかかることもあると思います。

また、リプレイスをするというのは現状の負債と立ち向かうものなので、作業自体にも結構な負荷がかかると思います。

全体的にですが、そんな話を笑いも交えながら話をしてくれてとても安心しながら聞けました。

また、リプレイスは単発で終わるものではなく、数年かけて行うこともあるので

何をどうするということをしっかり決めたり、どういうプロセスでやっていくのかという計画を立てたりすることが重要だとあらためて感じました。

何度か出てきましたが、技術ファーストで考えるのではなくビジネスのことも考えていこうというのはとてもうなづけました。

いまのレガシーなシステムでつらいことを感じることもありますが、それだけの理由でリプレイスしたいというのは目線が自分に向いているので、ビジネス目線でどうなのか、ユーザー目線でどうなのか、ということまで考える必要があると、改めて感じました。（つらいのを許容するべきという意味ではない）

 

【サポーターズ勉強会】システムを構築するときに気をつける10のこと

https://supporterzcolab.com/event/233/

に行ってきたので、その時のレポート

資料

基本的に、このスライドに書かれていることをなぞって講演していただいたので

このスライドをみればだいたいイベントの内容が分かります。

ただ、口頭で説明のあった箇所などはメモをとっていたので

下記に記載します。

まえおき前提

web業界において、スピード重視でサービスリリースするような開発

アジャイル開発などを対象に今回の講演をします。

登壇者の方がよく思うことが、

サーバーサイドエンジニアから受ける質問として

「この機能作りたいんですけど気をつけることありますか？」

と聞かれることがあるのだが、気をつけることはいっぱいある。

だが、書籍とかで気をつけるべきことの情報は見つけにくい。

それで、今回ざっくり説明をしていただける。

安定稼働にはコストとリソースがかかる

設計とかで、結構時間がかかる。

オンプレで動いてたものをクラウドで動かすとかだと、

どのくらいの費用がかかるのか、どういう設計にするのが良いのかが検証してみないとわからない。

例えば、クラウド環境で冗長化するとして、

マシンを1台で動かしてたものを2台にするとかだったら、2倍料金がかかる。

1台が死んだら2台目に切り替わるという仕組み作りの検証もしておかないといけない。

運用体制コスト

誰が通知を受けて、、誰がエスカレーションして誰が対応するのか

とかとかのマニュアルが必要。

ディザスタリカバリを考え、日頃から訓練する。

オペミスとかでデータが消失したときの対策

これは結構難しい。

設計はしたけど、日頃訓練しておかないと

いざ障害が起こったときに、うまく動けないことがある。

擬似的に障害発生させて訓練しよう

システムが落ちたという報告を誰が誰にエスカレーションしないといけないのかを決めておく

例えば、上司に報告して、上司はお客さんに報告するとか。

モニタリングのメトリクスは細かく取る

こういうのを細かくとっておくと、

障害が発生したときとか、スケールするときに情報になる。

ただし、メトリクスをとりすぎると逆にマシン負荷になるので注意が必要

代表的なメトリクスはグラフにしたりしておく

また、そのメトリクスの意味を理解しておく

「query/sec というメトリクスってなんのクエリなんだっけ？」とか。

システム全体がスケールできる

ネットワークのスループット

例えばデータセンターだったら、外から入って行くるのが1本だったら、それに耐えられるのかとか。

外部連携

例えばBIツールを使っているときも、外との連携でスケールできるんだっけとか。

設計/選定した技術には責任を持つ

使ったけどちょっと違ったかなというときは

ちゃんと自分で負債を返していかないといけない。

技術選定が間違っていたとかいうこともあるが

それをちゃんと返して行こう

そのためにも、採用した技術には一番詳しくなっておこう。

仕様やデータ構造の変更は必ず発生する

仕様とか技術は変わっていくので

変わってもいいように設計を考えておきましょう。

データの保管場所は塾考する

例えば、クラウドからオンプレに持って行きたいとなったときに

データ量が多いと、転送時間に時間がすごくかかるので気をつけないといけない。

データレイクというのが最近注目されている

データレイクとは、1箇所に全てのデータを集めて使えるようにしましょうという考え方。

セキュリティ対策は必要だが、コストと時間がかかる

権限管理はすごい大変

ここはちゃんと設計しておかないと行けない。

権限の設計が必要

　→　しかも、変更が入るので、柔軟な設計が必要

誰が管理して、だれが付与して・・・

転職とか退職とか、人の入れ替わりがあって、権限の管理が大変

クラウドを信頼しすぎない

クラウドはだいぶ安定・安心できるが、100%の安定では決してない。

EC2の場合、メンテナンスのために強制的にシャットダウンされることがある。

だが、EC2の中でvmが動いていて、vmの中のメモリでアプリケーションが動いていて、

シャットダウンさせるには、メモリにのっているデータを退避させないといけないとかの状況の場合もある。

だが、シャットダウン日は10日後に迫っていてつらい。。みたいな状況もある。

謎のサービスレベルの低下

AWSに質問した。

回答は、他で使われているインスタンスの負荷で、それに引っ張られてますとかの回答がきた。

結局、言いたかったこと

優先順位を決めよう

セキュリティが重要だったらそれからやろう。

スケールが大事だったらそれからやろう。

全部やれるにこしたことはないが、時間もないので。

Q & A

Q.どんなメトリクスで区切るとかコツはある？

A.僕（登壇者の方）の場合は低レイテンシーが求められているので、

　1msec, 4msec, 10msec, …. とかで返したクエリとかでメトリクスを切っている

　そのときのメモリの使用量とかを分析できるので、目的別でメトリクスを区切るようにしている。

 

Q. おすすめのメトリクスツールは？導入が簡単とか。

A. saasサービス

   New Relicとか。

   Datadogをリソースの管理で使っている。

   Datadogは楽。

   どちらも外部サービスなんで、アラート飛んできたらどこにいても見れるとかのメリットはある

   ただし、セキュリティに厳しい会社だとそれができないかも

   zabbixとかも、サポートが手厚い。

   

Q. 外部のメトリクスサービスを使うのではなく、逆に自分たちで作らないといけないときの条件は？

A. KVSとか、高速にクエリを処理したいときとか。

　AirSpace?というKVSと使っているがDatadogとかだと対応していなので

　分析用のシェルを自分でつくって、それをDatadogに投げるとかのことは自分でしないといけない。