2014年12月23日火曜日

ヒトの書くコードとそのコードの保守性

コードをメンテナンスするということ

ChefやAnsibleだろうと何を使おうと、再度使う予定があるコードは保守開発の対象になるし、普通そうだと思う。

Infrastructure as Codeはやらないよりやる方が良いと思うけど、その一方で、コード自体の保守性(maintainability)と情報共有が低い組織では技術的負債を生み出す可能性が高いと思う。

コードを書く経験が少ない人の方が、保守性の低いコードを書くことが多いのはよくあることだし、そもそも1人でやってるような状態だと、情報共有やドキュメンテーションがが大事だと知っていても、それに割く時間よりも、他の業務が優先になることはあるあるだと思う。


結局はヒト(ある特定のではなく)の問題なので、潜在する問題はヒトが動いてなんとかしないとそのまま問題として浮かび上がってくる。モダンな開発環境や手法をやろうとするのも大事なんだけど、ヒトがモノやサービスを作る現場なので、その現場のヒトの意識や姿勢が大事で、それが良し悪し関係なく文化や習慣を作ると思う。もちろん機械による自動化も。


Sassも同じ

Sassでは変数や関数が使えるので、そこでも差が出てくる。
サイズなので、とりあえず$s、$m、$lとつけて、その変数を数百行後で使ったりするのは経験が少ない側。(height: $m)
変数名が被ったり、名前から何なのか推測しやすいものにするのは、経験を積んだ側。(height: $pane-height-mid)
compassを使ってベンダープリフィクスから解放されたら、良いコードを書くよう実践していくべき。
セレクタの優先度や構造に強く依存しないCSSが書けないと、追加や変更の多いWebアプリではすぐに破綻する。

CSSは軽視されがちだけど、すぐに肥大化して、保守が困難になる。
他の人が書いたCSSを嫌がるケースって少なくないし...Web業界の人だと何かしらさっするだろうと。
Sassを導入しても、先ほどの一例のような問題は解決しない。
結局のところ、性質が違うにせよ、コードを書くので、保守性の高いコードを書けることが大事。


業務でコードを書く人は保守性の高いコードを書くべき

プログラマーはリーダブルコードは読むべき。
CSSやjQueryでちょっとしかコードを書かない人には辛いと思うので強制はできない。
そういう人は、デザインやコードの現場で、その苦労は嫌という程 実例があると思うので、そこから出てきたベストプラクティスには耳を傾けるべき。


トラックナンバー(バス係数)を減らす

チーム内で1人でやってる人は自分がトラックナンバーを増やす要因にならないように頑張るしかないのではと思う。
4〜5人のチームでは、得意分野がそれぞれ違うことが多いのではないかと思う。
というより、今まさに自分がそうで、ほかの人にも同じように開発してもらうには、いろいろと覚えてもらうことが多いし、お互いに負荷が高いし、そうしない方が開発自体は速い。
ずっとそのままというのもまずいので、、もし自分が事故で仕事ができなくなっても、今ならRuby/Railsの中級者は世間にはたくさんいるし(むしろ自分より経験の多い人の方が多いのではと思う)、
その人が入って、READMEさえ読めば、あとはコードを追っていくなりすれば大丈夫!というところは目指しているところ。
久しぶりに、最初の最初から自分が携わるプロジェクトなので、責任は大きいし、良い方向に持っていきたい。
あと、自分が必ずしも良いコードを書いているわけじゃないし、むしろもっと良いコードを書けるよう刺激は求めてるし、受け身にならず頑張っていきたいところ。(最近受け身なろうとしがち...)


その辺を把握した上で、いろいろマネージーメントしないといけない。と、リアルおっさんになる前に、将来の自分へのお手紙として、ここに書き記しておこうと思いました。まる。
(マネージャーでもマネージャー志望でもないけど)

0 件のコメント: