プログラマの思索

技術的負い目の記事がすごいのでリンクしておく。

【元ネタ】
16年間うごいているWebアプリケーションが抱えていた技術的負い目を考察する | GMOメディア エンジニアブログ

たくさんの負のレガシーがあり、しかも本番稼動中であり、バックアップ容量も多い。
そう簡単にリファクタリングしにくい。
そんな中で色んな対応をされている。
以下、自分が今後参考にしたいためにメモ。

【1】JDKが古い。

古いJDKはセキュリティホールもあるだろうから危険。
性能要件も低いだろう。

→JDK6からJDK8へバージョンアップ。
　Gradleでビルド環境を作る。
　ライブラリの依存関係はMavenリポジトリから探し、Gradleで依存関係管理させる、と。

【2】コード重複率も多く、デッドプログラムも多い。

長年運用したシステムは、デッドプログラムが多い。
でも、リスクがあるから、デッドプログラムをうかつに消去できない。

→リファクタリング、Jenkinsで単体テスト自動化、Sonarでソース解析、Githubフローで開発プロセス改善で30万行を削除。
　その結果、その後の機能改善もやりやすくなった、と。

【3】エラーログ件数が3000件以上もあり、エラーが常態化している。

この状況もよくある。
エラーログが全く使いものにならないから、本来の障害を検知しにくいし、代わりのエラー検知の手作業が増えてしまい、システム運用のコストが大きくなる。

→エラーログ件数のグラフ化して見える化。
　エラー件数が多いエラーをパレート分析して、1つずつ対処していく。
　ログレベルをFatal～Debugまで整理。
　エラーログから検知した内容は、ChatWorkに通知する。
　その結果、一日平均50件ほどまで減らすした、と。

【4】デプロイによってシステムが一時的に壊れる

古いシステムほど、リリース作業のプロセスもデプロイツールも古いままなので、手間がかかりやすい。
その分、リスクも大きい。

→Tomcatを停止する前に、ロードバランサーにワーカーを切り離させる。
　trunkのみでの運用をやめ、プルリクエストベースの開発プロセスとした。
　Tomcatの起動後にアプリケーションがリクエストを処理できるようになるまで待機する処理を入れた。
　リリース内容はChatWorkに通知する、と。

他にも、認識されていない単一障害点、ワイルドなバッチ処理など、たくさんあって、技術とプロセスの両方で改善されたテクニックやプラクティスがすごく参考になる。