ヤバい設計をするチームの言葉
はじめに
現在の派遣先の契約が今月で無事に切れ、自社開発の案件を担当できるようになったため、半年の経験をもとに「どんな言葉がヤバい設計につながるのか」を考えてみようと思う。
技術レベルとしては、「ユニットテストが存在しておらず、手動テストの結果のスクリーンショットをエクセルに貼り付けて図形機能で加工するレベル。なおかつ自動化への意思が一切ない。」と書けばなんとなくわかるかもしれない。
「動いてるものが正義だから」
この言葉の問題点は既存のコードへの改善の意思が見られないこと。
下記記事の「Failure Demand という利子の支払いに追われるエンジニアの疲弊」の項にあるとおり、コード品質を意図的に落とした状態で耐えられるのは数週間以内とされている。
この言葉が問題だと思っているのは、上にある「数週間」を過ぎているコードとそれに起因する問題が起こっているのにそれを見なかったことにするための言葉だからだ。
「今後開発速度は落としていき、非効率な作業を行っていく」宣言に等しいのだ。
どうすればよいかは…これを言う立場であれば「レガシーソフトウェア改善ガイド」を読むとヒントが書いてあるかもしれない。言われる立場であれば…どうせ相手の技術レベルは低いのだから、自分の担当している部分は時間を少し使って改善してしまおう。
「とりあえず～～しておきます」
上の「動いているものが正義だから」とセットで考えよう。その「とりあえず」は基本的には修正されない。
どれだけ高く見積もっても修正される確率は10%程度で、特に「とりあえず」が口癖になっているような人であれば修正される確率は0%となるだろう。
「Commonクラス内に定数を定義しておきます」
そのような名前の付け方をするクラスだと、凝縮度・結合度は最悪の部類になる。基本的にすべてのクラスからアクセスできてしまうため、「お風呂場に布団を敷いて寝ることができる」ぐらいの動作ができてしまう。
凝縮度と結合度については、この記事を見ておけば良いと思う。
基本的に「Commonクラス」と呼ばれるものの各要素の間には関連性がなく、事実上のグローバルデータとして使われている。上の記事の基準で言うなら偶発的凝縮と共通結合の状態になっている。
どこで使われているかを確認して、最も関連性のあるモジュールに定数の宣言を移動させた方が良さそうに感じた。
まとめ
今回紹介した発言には共通の意識があるように感じた。
「妥協」である。
プログラムは書いたようにしか動かないため、「今のままでいいや」と問題を放置してもその問題は残り続ける。そのまま開発を続けても負債は確実に開発速度と品質を悪化させる。
半年所属していたチームは全体として現状を改善する知識がなく、改善しようとする意識も無いことにより技術力が低く、それが勉強時間の低下などにつながっているように感じた。
要は下記の状態である。そうならないように妥協はしないようにしよう、というのがこの半年の個人的な教訓となった。
この記事が気に入ったらサポートをしてみませんか？