最初は作るだけ作って、後でまとめてリファクタリング

昔のコードを保守開発することになると、まず第一に既存のやばいコードに出くわすでしょう。そういう絶望に立ち向かった人なら誰でも、後でリファクタリングすることの難しさというか不毛さを痛感しているはず。最初からベストなコードを書いて、後追いのリファクタリング不要にしておく。プロジェクトの期間内に100%綺麗にするのが無理でも、該当箇所にコメントを入れてわかりやすくし、そのプロジェクトのデプロイ直後にhotfix的に追加デプロイして解決する等工夫すれば、決して不可能ではない。。

責務を無視したクラス設計

オブジェクト指向言語を使っていると特に起こりやすいかと。

たとえば一般的なクレジットカードの支払い機能を実装する場合、ログインしているユーザのクレジットカードの契約番号が欲しいなら、どう考えたってその責務を持つべきなのはそのユーザ(もしくは課金情報を別で持っているテーブルpaymentがあるなら、userとのassociationをつけてuser.payment.contract_numberとか)になるはず。しかしこの挙動をaction内に書いてしまったり、全く関係ないモデルのclass内に書いていたりするかもしれません。後述する”動けばいい”思想だとactionに書いてあろうが関係ないモデルに書いてあろうが動くことには動くから、まあいいや、で済まされるかも？

難解なコードを書いて満足

つまり周りに認めてもらいたいあまりに、自分の読解力、技術力を評価して欲しくて意図的に読みづらい、面倒臭いコードを書く人がいるかもしれません。Railsなら__send__とか黒魔術を乱用するんじゃねーよと言いたい。

そういう物好きにはIOCCCを勧めて、しばらくの間そちらに没頭してもらうのがいいかも？チームのみんなのためにならないうん○コードを書くような人に精神をすり減らすのは酷だし、都度リファクタリングするのも面倒。コーディングルールの読めない人にはコーディングさせないなどの配慮も必要でしょう。

趣味ならともかく、仕事では好き放題できるわけがない。大事なのは読みやすく拡張性がありDRYに則った書き方であり、決してスキルをひけらかすことではないので。。

その場しのぎ、穴埋め的な、暫定治療で満足

プロダクトが動けばいい的な考え方です。作ったものが本当に納得いくものかは別。特に納期が迫っている時や作るのが怠くなってきたときに起こりやすいです。

確かにユーザからみたら中身のコードがどんな作りになっているかなんて気にならないし、ひとまずは納期を守ることはとても重要なので、いざとなれば”動いてるけどしっくりこない”コードをデプロイせざるをえない時はくるかも。

しかしその技術的な負債が積み重なることによって後で取り返しのつかないことになります。特に酷いものだとベテランの方々でも完全な治療はお手上げだというかもしれない。だから先述した通り、後追いでもいいからすぐに修正版をデプロイし、最高の品質を保つ努力をすべきです。理想かもしれないが、きっと誰でも頭ではそう思っているので。。

もしかしたら他にもっと奇抜なのとか、あるかもです。

最初の一番何もわかっていないうちは熟達したエンジニアの思考をパクることと、それでわからないことは聞くか調べるなりして、いち早く変な癖を矯正するのが一番上達する近道じゃないですかね〜

もっと早い段階で気づいていればよかった( ´艸｀)

今回はこの辺で。