開発者が知っておいた方がいいんじゃないかな？と思わない気がしないでもない65535の事。　～第一章～

どうも、畜産ペンギンです。

 

プロ野球が開幕しましたね、優勝出来る気がしませんので少し憂鬱です。

 

今回は開発者が知っておいた方がいいんじゃないかな？と自信なさげに思った事を語って行こうと思います。

本当はもう少しテーマの指向性を絞って書きたかったのですが、中々頭の中でまとめきれなかったのでもう、いいやと。

流れも何も気にせずその時その時で思った事を書いて行く楽したいシリーズですね。

 

今回の目次は以下の通り。

 

目次

・DRY原則について ・技術的負債との向き合い方 ・まとめ

 

DRY原則について

DRY(Don’t Repeat Yourself)原則とは、その名の通り繰り返しを避ける事、といった意味合いです。

達人プログラマーという本で「すべての知識はシステム内において、単一、かつ明確な、そして信頼できる表現になっていなければならない。」という言葉で紹介されているのが有名みたいです。

 

「同じコードを繰り返し書かない」というのはコードを書き始めた人間にとって一番頭に来るんじゃないかなってくらい品質の高いコードを書く際の指標となると思いますが、DRY原則についてはコーディングだけでなく作業全般にもかかっています。

何度も作業する事は自動化したり、等も当てはまるという事ですね。

 

ですが、どうしても重複を避けられない場合もあります。

たとえば、データベースにプログラムからアクセスする際、基本的にはテーブル情報のエンティティクラスを持つことになると思いますが、これはデータベース側のテーブル定義と重複している事になります。

まぁ一つの何かしらのファイルに持たせてそれを参照する、等も出来るは出来るでしょうがその方がむしろコードの可読性等は低いと感じます。

 

では、どうやってDRY原則を守るべきか例外とするべきか判断するべきでしょうか。

結論から言うと、正解はわからん。

 

ただ、言い訳をすると正解が無い物に対して何かしらの指針を定めて「比較的良い」とされるアプローチを取る事がまぁプロフェッショナルのすべき事なんじゃないかなぁと。

 

では、「比較的良い」とされるアプローチをとる為には何が必要なのかというと一つの方法として、色んな原則を知り、状況に適した新たな原則を適用する事かな、と。

 

「原則」なのにアップデートが入る事に多少の矛盾を感じますが、まぁ周りが変わる限り不変で許されるものはないよねという「原則」が優先されるよねというパラドクスがうんたらかんたら。

 

 

技術的負債との向き合い方

技術的負債とは、ざっくり言うと技術的な事に関してやっつけ仕事等で将来困る形で進めてしまって残ったモノです。

 

例を言うとイケてないコードを書いた事にレビュー時に気付いたが、まぁ現段階で動かない訳じゃないし時間ないし、、、と問題を先送りするアレです。

 

長い間アップデートを続けているとこういう事の積み重ねが非常に足を引っ張り、直した所と全然関係ないと思ったところでバグが起きたりします。

最近の銀行の事故なんかも多分この辺の積み重ねでしょう。

 

気付いた時に直せばいい、と言ってしまえば簡単ですがコレは中々ハードルが高いです。

何分時間がない、等の理由でスルーされていたり時が経つと担当者も変わりますし、現状動いているものをリファクタリングする為にリソースを用意するのも中々ハードルが高いです。

 

というかぶっちゃけ、やっぱり、めんどくさいんですよね。

個人レベルで気付いたとしても、コードを直すとなると、テストを追加で実施しなければならない。状況によっては設計書も直さなきゃならない。勝手にやる訳にはいかないので承認を取らなければならない。

将来的な事を考えれば直した方がいいかもしれないと思っていても、その時は担当が自分で無くなるかもしれない。目の前で楽したいとか考えてるとやっぱり中々やる気は起きない物です。

 

では、どう対策していくかと言うといくつか方法はあると思いますが、やっぱりそもそも技術的負債を「始めから作らない」方向に進むのが楽かなと思います。

 

最近だと、コード解析でイケてない部分を抽出してくれるツールも結構進化しているみたいなので、その辺使っていければ一番いいですかね。

 

話が反れますが、コーディング技術を上げたい！と考えてる人はこの辺のツールを使って訓練していく、というやり方があるらしく確かに有効だなぁと思ったり。

 

まとめ

当たり前っちゃ当たり前ですが、一つのプロジェクトでも色んな思惑やルールで動いているので常に考え方ややり方のアップデートは必要ですね。

 

まずはアップデートを常にしていく、という仕組みを整えていくのが第一優先かなぁ。

 

今回はここまでです。

 

さようなら。