読者です 読者をやめる 読者になる 読者になる

歩きやすい道と歩きにくい道

最近思うのがどんないいプログラムでも時間が経つと旧式化し老朽化しうるということ。
それも意外と早く。それに対してプロダクトの寿命はずっと長いということ。

それで困るのが、そのときは最善なコードを書いた、ちょっと先のことも考えて柔軟性も持たせた!しかしここのメンテ辛いなぁ。。。というケース。

ただそこにもいろいろ話があって、

そのメンテしようとするプログラムが機能追加することが多いとか、パフォーマンス対策でよく改修が必要なところとかだと比較的変更しやすかったり

一方、機能追加があまりないとか、特に問題が発生せずいい感じに動いているプログラムはいざメンテしようとすると難しさを感じることがあります。


!

世話のかかるプログラムほどメンテ、継続的な改善がしやすい?

人がよく歩く道は整備され歩きやすい、
人がめったに歩かない場所は整備がされておらず歩きづらい。

ということは現実の世界でよくある話かと思います。
これと同じことがプログラミングでもありそうです。

"人がよく歩く道は整備され歩きやすい" というのは、"そのメンテしようとするプログラムが機能追加することが多いとか、パフォーマンス対策で改修することが多いなどの場合は比較的変更しやすい " という場合です。
一度自分が行った改修箇所についてはその知見があるため安心感があります。自分でなくとも先人が行った改修、作業と同様の作業などは安心感があります。もしかしたらそこに何か罠があったのなら先人がすでにそれを踏んだあとだったり。
あとは、そのプログラムの開発当時にはできなかった、実際に稼働した後だからこそできる改善がされていることもあります。開発当時よりも仕様がより明確になっている、新しい技術が取り込まれている、など


"人がめったに歩かない場所は整備がされておらず歩きづらい" というのは、 "機能追加があまりないとか、特に問題が発生せずいい感じに動いているプログラムはいざメンテしようとすると難しさを感じることがあります" の場合です。
まずそのプログラムを理解する必要があります。そのうえで、ここのプログラムをこうすればよさそう!とわかってもありうるリスクを検討する必要もあります。本当に?他によくない副作用はない?万が一のときの影響範囲は?などなど


!


では、継続的な改修のしやすさのためにどうするか

完璧なプログラムなんてないので必要なときに必要な改修はやはりする必要があります。
対策としていくつか、

  • テストを書く(道の例えで言うと、その道がどこからどこにつながっているかを示すこと)
  • CIを回す(交通量を増やす)
  • 監視、アラート
    • そもそも改修が必要な時がわからないといけないので。道が崩壊していたらなるべくはやく気づいて対応したい
  • 可読性
    • 国道 or 酷道
    • 不要な道は作らない
      • => やっていることがわかりやすいプログラム
      • => コメント、ドキュメントも一度書いたならその後のメンテが必要なもの。コメント、ドキュメントを書くのに時間を割くよりはそのコードに注力したい
      • => そのプログラム(道)を見る(通る)人が誰なのか
  • 重要な処理部分で問題が起きないように
    • 道のたとえで言えば、通行止めをする
    • => 権限で制御、ネットワークで制御
    • => 盛大に落ちるテスト、監視
  • ここにコードが集中しそう
    • 道のたとえで言えば、道でないところをショートカットしようとする対策。あえて歩きづらくするとか
    • => 用途を絞った命名にする、とか
    • => 使っているライブラリ等のバージョンのチェック

!



コードを生き物と表現される方もいますが、ここでは継続的改修のしやすさに注目して「道」と表現してみました。

© karahiyo