レガシーソフトウェア改善ガイドの感想

DevOps

書簡


最近起こった出来事もあり特にレガシープロジェクトの健康状態をどうすれば良いか考えていた時にちょうど良い本がありました。

書籍の中で述べられている方針自体は真新しいということはないのですがクリスさんの経験に基づく話もあってプロジェクトの品質を良くするためには何をすれば良いのか綴られており、この本を読むたくさんの人は共感が得られるのではないのかと思います。


この本の中ではレガシープロジェクトを"保守または拡張が困難な既存のプロジェクト"と定義しております。レガシープロジェクトが生まれる原因としては例えばコミュニケーションの不足であったり、ドキュメントが不足、その上にプロジェクトの担当者自体が単独でコミュニケーションを取れる相手がいないなどありまして、そのようなハードな環境で働いているエンジニアは世界中にもたくさんいるのではないでしょうか。


そのような環境に置かれると現状の維持だけしか考えなかったりとか良くあると思います。自分もとりあえずコードの可読性やロジックの簡略化にさえ気をつけておけば良いという、いわゆるコード見りゃわかるからの考えが昔はあったのですがそれは間違いでした。ソースコードのライフサイクルは開発時以外にも運用やカスタマイズの時まで意識する必要があります。そのためのコミュニケーションが不足していると自分の管理すべきコードに対して次第に責任を持てなくなります。    


プロジェクトを健康に保つためのコミュニケーションが行われる環境やインフラストラクチャの自動化についての実例を元にしたサンプルがあったのでまずはそこを意識して自分が担当しているプロジェクトにも取り入れていきたいと思います。    


この本は最後に"自分が書いたコードにはプライドを持とう。別の誰かが書いたコードを渡されたら先人の人のためにも後から来る人々のためにもコードに敬意を払い育成しよう。自分たちが残すべき遺産は誇らしい遺産にしよう。"と述べられています。エンジニアとして楽しく働いていくためにもこの考えは徹底していきたいと思います。

今後の改善

まずは自動化について以下について以下のものに取り組んでいくのが良さそうだと思いました。

  • ビルドツールをGradleにする
    • 環境ごとにビルドを行えるようにする
  • テスト環境をAnsibleで構築できるようにする
  • Jenkinsを利用する
    • gitにPush, Mergeされたタイミングで自動でビルドして結果を見れるようにする
    • ビルド時にテストスクリプトを自動で実行できるようにする
    • ビルド時にテスト環境に自動でデプロイをこな得るようにする
  • Fulentdでログを集計後Elasticsearchに突っ込んづkibanaで可視化する

もしも自社がクラウドサービスを運用しているのでしたら、セキュリティの面で自信を持ってサービスを提供するためにもこの辺りは行えなきゃいけないのかと思います。よく研究されたフレームワークはいつ攻撃を受けてもおかしくありませんので、脆弱性が発表された当日、翌日ですぐに対応版をリリースできるようにするためにもこの辺りは徹底していきたいです。