とりあえずやってミタ

とりあえず技術的っぽいことをいろいろやってみるブログ

クソプログラムについて語ってみた

      2015/07/25

自分がメンテをしてるクソプログラムがある。もちろん作ったのは自分ではない。



クソプログラムの定義

何をもってクソプログラムとそうでないプログラムを分けるか、エンジニアなら自分なりの基準を持っているだろう。そして一見クソでも見方を変えれば肥料になるクソも存在する。
だがしかし、、、

ここでは現在進行形で経験しているどうにもならないその内容を差し障りない程度に書き留めとく。今後この惨劇を繰り返さないように戒めとしたい。



その内容

ソースコードがクソ

  • 1ファイルのソースが数千行
  • そんなファイルが数百とある
  • ファイル名から何をするソースかは推測不可能
  • 変数名・関数名にも命名規則がなく、ローマ字と英語が混在のうえスペルミス多数
  • アルファベット1文字の変数名を乱発。そして、それがたまにグローバル変数

DB設計がクソ

  • 一意の値のためのデータが文字列型で定義されてたり
  • 整数型のデータに対して『あいまい検索』をかけてたり
  • 正規化がされておらず複数のカラム・テーブルを同時に更新しないと整合性が崩れたり
  • 日毎のバッチ処理でキロ単位でデータが増える時限爆弾のような設計

関数化がクソ

  • 一つの関数が数百行あったり
  • そんな関数が1ファイルに何個も羅列
  • 各関数が何をするものかは関数名から推測が不可能
  • それぞれの関数を頑張って読むと実は数行程度しか違いがないことが多い
  • その関数で返された値はどこにも使われないまま終了とか

モジュール設計がクソ

  • モジュール名から内容の推測は不可
  • 各モジュール分けの定義が全く検討つかない
  • 微妙に各モジュールが依存していて分割できない
  • DBコネクションをはるモジュールが二つ存在し、当然のようにデッドロック発生

その他

  • ドキュメントの欠如(というか元からない)
  • 長年の運用でシステム全体の仕様が複雑化
  • 基幹で毎日バッチ処理されているシステムなので容易にメンテできない
  • 新たに予算がつく予定はない
  • リニューアルするために新たな人材リソースも時間も避けない
  • 基幹なので修正には責任とリスクが伴う


なぜこうなった?

結局すべての原因は手がけたスタッフのスキル不足と、とにかく動かせ的なマネージメントにある。それらが積重なってこのどうしようもないスパゲッティーモンスターを生んでしまった。当時のスタッフの責任を追及したところで何も変わらないのが辛いところだ。



どうする?

技術的にも仕様的にも実は大したことないのに、人為的に仕組まれた不具合のために自分の時間を費やさないといけない。それをやったところで会社からの評価もないし、技術的に得るものもない。なにより直したところで本来あるべき姿に戻るだけという。

こんな条件なので冗談抜きに個人的には2時間も続けてリファクタリングすれば鬱になる。




とにかく頑張る
(2015/7/24 内容を一部修正しました)

 - メモ

  関連記事