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

basyura's blog

あしたになったらほんきだす。

ソースの書き方

苦悩

お金を出す側も仕様を出す側も実装する側も深くはないけど状況とか負荷とか内容とかがヘタに見えたり分かってしまったりすると、いろいろとしんどいことが増える。どちらの気持ちもわかってしまうので。これに理想が加わるとカオスになって、もうどうでもいやってなる。動けばイイ、とか嫌われてもイイとか割り切れたりもろもろを感じなかったりすると楽なんだろうけど。

主にリファクタリング目的で実装してもらったソースを独断と偏見で直してしまうことがよくある (たまにデグレる)。基準として、自分がメンテできるかどうか。実装段階によってはこれカオスだよって突き返すこともできるけど、せっかく実装してもらってテストだーって時にたまたま見つけてしまったソースに対して自分の感覚的なところで依頼するのは心苦しい。ので、自分でやる。多少デグレってても今後のことを考えれば放置できない (と、自分を正当化して)。

仕事は C# で型があるからトリッキーな実装でなければ Visual Studio でガリガリ直してしまう。逆に型が無い言語の場合はそんなことは無理なので、実際リファクタリングしなきゃ・・・ってなったときにはテストがあるか、通るかが前提になるんだろう。どっちが楽かといえば「型によるコンパイルが通る」という「テスト」が通ったの方が楽、に思えるが型があるからリファクタリングが必要なほどになってしまったのか、型があるからリファクタリングが楽なのか難しいところ。少人数でレビュー体制がしっかりしていて、それぞれがソースコードを見るような状況であれば型なしで少ない記載で表現、実装できる方がいいんだろうなぁ。スピード感あるし。

で、ここからが本題で「ここはコアなところなのにカオス!確実にメンテで死ぬわ!」と思って一日かけてリファクタリングしながら思ったこと。どうしたらカオスになりにくくするか。

  • region をつかうな
  • 引数を縦に並べるな
  • 俯瞰してざっと理解できる程度に1クラスをおさめろ

region をつかうな

ソースコードの折りたたみ機能は使うな。臭いものに蓋をするな、利用する前に実装に目を通せ。
折りたたんでたら 100 行だったのに、展開したら 10000 行だったとかシャレにならない。
ココに追記して折りたたんどけばいいやという安直な考えを回避できる。

引数を縦に並べるな

メソッド定義で引数を縦に並べると、「あ、この引数も必要だったわ追加」という安直な考えを回避できる。
横に並べて長いと感じる場合は改善の余地がある。引数が多いことがそもそもおかしいのではないか?メソッド名や引数名が長いのではないか?

俯瞰してざっと理解できる程度に1クラスをおさめろ

そのまんま。記憶力を駆使しないと追えない実装はメンテできない。

まとめ

結局個人の力量に依存してしまうし、個人の力が伸びていくように教育なりレビュー体制を強化しないといけないとは思うのだけど、実際問題みんな忙しくて優先度が下がってしまうし個人任せになってしまう。まぁ、僕なりにいろいろ活動はしたつもりではあるけど。実行力のある人が強行的にすすめないとその場限りで終わってしまう。うまいこと「仕組み」ができればいいけどね。それこそ Github のように topi branch で pull request だしてレビューしてマージするような仕組み。

ただ、上記の 3 つぐらいを意識してもらえば「基本は」なんとかなるんじゃないかなぁ。
そこからクラスをどう分割して役割をもたせるかはまた別。でこれがまたカオス。