【日記】壮絶なクソコードをリライトした話

wrongwrong163377.hatenablog.com

続きというか、以下の記事を紹介して頂いたのでそのアンサー的な記事として書きます。最近VBの記事が増えた原因がこれです。

hiroronn.hatenablog.jp

背景

5年程度担当者を代えながら煮込まれた結果できてしまったクソコードのリライトをしました。

リライトに踏み切った理由は、以下の3点からリファクタリングは不可能でリライトしたほうが早いと進言し、それが容れられたためです。

  • 自分がそのプロジェクトに振られた目的は新機能の実装であったが、コードは修正不能な量のバグと不合理を含んだ状態であり、新機能の実装が非常に困難な状態であった
  • コメントアウトされたプログラム行があまりにも多く、「何故この処理をする必要があるか」というコメントも無く、ドキュメントも無く、共通した処理が多くのファイルに分散して配置されており、見通しを立ててコードを管理できる状況に無かった
  • 流用できるコードもあるだろうという期待があった

記事を紹介していただいたのはリライトの終了後でしたが、正直もっと早く知ることができていたらという気分と、それでもリライトを選んだのは間違いではなかったかなという気分とがあります。

実際にやった結果

紹介した記事のレガシーの改善項ではリライトを選択する害として以下の4点が指摘されていましたので、各項目について結果を書きます。

  • 利用者にほとんどメリットが無い
  • もともとがバグだらけ
  • たいてい時間を超過する
  • アーキテクチャ的に不可能となるかもしれない 
利用者にほとんどメリットが無い

自分がリライトしていたのは簡易的な動画の編集・再生アプリケーションでしたが、微細なメモリリークや無駄な処理に起因する再生中の動画のフレーム飛びなどがありました。リライトによってこれらの問題を解消し、もっさりすることがあった動作の改善や何点か機能の追加も行えたため、利用者のメリットという点ではリライトは悪くない選択であったと思います。

そもそも新機能を実装できない程度には設計レベルで整理されておらず、使用しているライブラリの機能や仕組みへの理解もされているとは言い難いコードだったため、仮に旧コードに対して新機能の実装を行ったとしてもそのコードにバグが無いことを担保できる状況にありませんでした。よって、あの場面ではリライトするしか無かったと個人的には思っています。

ただし、書き直している間はアプリがそもそも利用できず、外面が同じものを作るだけでは動いているものを利用している側にとって全くメリットが無い訳で、新しい機能を追加するだとか、どうしても解消しなければならないバグが有るだとか、そういった状況がなければどれだけ魅力的に見えてもリライトするメリットは小さいとも感じました。

もともとがバグだらけ

これに関してはどうしようもない程に実感させられました。リライトを選択した時点ではもっと流用できるコードが有ることを期待しておりましたが、残念ながら使いまわせたのはUIだけで、そのUIも大きめに作り直しが入りました。

流用できる程度に作り込まれたコードは皆無でしたし、使えると思って移植したコードもバグや根本から仕様に合致していない処理を発見して結局全部作り直すなんてこともありました。

リライトに当たって流用できるコードは皆無だという前提で居たほうが良いという点は強く同意します。

大抵時間を超過する

超過しました。

計画を立てる段階での見通しの甘さもそうですが、作り直すからぶち当たる問題というものが非常に多く有り、仕様書のように絶対的な基準となるドキュメントも存在せず、当初は2週間程度で終わると思っていたリライトに5週間を要しました。

他人のせいにするような物言いになってしまいましたが、この点は見通しの甘さと自分の能力の不足を痛感した部分でもあります。アプリケーションをリライトするとなると広範な知識が必要となり、詰まった部分は単純な機能に対する勉強不足に起因していることがほとんどでした。また必要が無い状況で細かい部分を弄るなどして結果的に無駄とした時間があったのも反省点です。

アーキテクチャ的に不可能となるかもしれない 

これに関しては本を読んでいないため真意を理解できていませんが、実際OSやライブラリのバージョンの違いから実装不可能かもしれないという危機に陥る場面も有りました。

結果的には回避できましたが、リライトがそもそも完全に無駄になるような事態も覚悟するべきだという点に関しては痛感しました。

それでもやり切れたと思う面

今回のリライトでは苦労も多く有りましたが、最終的には何とかやり切ることができ、非常に良い経験もできました。

Git/Githubを用いた開発の経験

個人レベルですがGit/Githubを用いた開発を経験できました。

最初は完全に個人レベルでの利用に留めるつもりでしたが、バイトの方の中にはGit/Githubを使える方もおり、チーム開発というものを多少は経験できたかなと思います。Git/Githubへの理解も深まりました。

また、Gitだけでも使う効果は絶大だと感じました。旧コードではコードにコメント化を重ねた結果メインウィンドウだけで5000行を超えており(動いているコードは半分以下)非常に可読性の低い状況となっていましたが、リライトに当たってはコメント化されたコードによって可読性を損なうような事態を避けることができました。引き継ぐ際もGitを導入できたらいいなあ……。

コミットやブランチ作成のお作法などはまだまだ勉強中という感じですが、一歩目としては良い機会だったと思います。

開発をやり遂げた自信

リライトにあたっては内部的な設計を全て自分で考え、ほぼ全てのコードを独力で書き上げることができました。今までは「自分がどれ位できるのか」という点で全くと言っていいほど自信がありませんでしたが、今回の件で自分が思っているよりもできるんだということが確認できたと思います。

コーディング面でも、1日100コミット以上を何度も記録することができました。これまでは最大でも1日50コミット程度しかしたことがありませんでしたが、状況によってはそれだけ集中してコーディングに取り組むことができるということを知ることができて非常にいい機会となりました。

リライト中には細かいものも含め仕様変更が20回は入ったと思いますが、そんな中でも破綻させずにコードを書き上げることができたのは素直に嬉しかったです。

最後に、自分のリポジトリへのコントリビュートです。

2,102 commits  60,493 ++  46,161 --

補足

この件について愚痴を聞いて頂いた際に「クソコードとは言うけれど、書きたくてそうなった訳じゃないかもしれないんだからあまり口に出し過ぎないようにね」という旨の忠告を頂きました。

「コードはコード、個人の人格を攻撃している訳じゃないんだからいいじゃないか」とその場では思いましたが、過去記事を読み返すとしっかり人格攻撃に走っていましたね……(というかあの記事からもう1ヶ月経っていたことに驚きました)。

口は禍の元、自分は口が悪い方なので自重を心がけようと思います。