コード書き仕草

たまには雑談っぽいことでも書くか〜

他の開発者のためにコードを書く

コードを書くにあたっての話題は尽きることがないです. ざっと思いつくようなことを挙げてみるだけでも,

  • 性質
    • 可読性
    • 柔軟性
    • 堅牢性
    • 変更容易性
  • 原則
    • 驚き最小
    • DRY
    • SOLID
  • 道具
    • コーディングスタイル
    • 設計
    • 契約
    • テスト
    • ドキュメント

などなど.

ところでこれらが何のために存在するか考えたことがありますか?

もちろん最終的にはユーザーにとっての価値を産むということなのですが, コードの書き方自体が直接ユーザーの価値になることはないです. まあほぼ絶対にない.

私は他の開発者のためだと考えています. コードの書き方を工夫することで, 他の開発者が価値を提供するのに役立てば良い. これは単純に私の性質の問題もあって, 元々そういう裏方的なコードを書くのが好きなのもあるし, 必ずしもユーザーに価値を提供することに興味がないような場合もある.

他者のためと言うといかにも良心の問題っぽく聞こえるけど, これは上に書いたような無数の性質・原則を個別に覚えるのは大変なので, より単純な「他者の役に立つ」というモデルを仮定しているというだけの話であって, こういうことができる・できない人は良心がある・ないという話をしたいわけではないです. そもそも私も夜中に靴を完成させるのは善行だというよりは, 夜中に靴が完成していたら明らかに異常で面白いだろうという気持ちでやっているので...

使いやすいライブラリと使いにくいライブラリ

他の開発者のためのコードといえば, まさにライブラリは他の開発者も使えるように書かれたコードのはずです. 一方でそういったライブラリであっても, 使いやすいものもあれば, どうにも使いにくいものもあります. 例をいくつか挙げると,

  • React は使いやすいライブラリの一例で, 内部の仕組みはしばしば変更されているようですが, 使い方は数バージョンにわたってほぼ変化していません. また脱出ハッチのような拡張のための機構も用意されています
  • 単機能の小さなライブラリについては, ドキュメントに書いてあることだけを確実に行ってくれるため, 使いやすいと感じることが多いです
  • とある汎用的な HTTP プロキシライブラリは, 特定のケースでリクエストボディを加工するというドキュメント化されていない挙動があり, そのケースを踏むことで予想外の不具合につながってしまいました
  • とある CLI ツールはライブラリとしても利用可能になっていますが, ライブラリとして使用した場合もグローバルな領域を汚染してしまうため, その CLI を作る以外の用途にはほとんど使えないものでした

使いにくいと感じるライブラリの共通点として, 汎用的に見えて実は (おそらく作者自身が使う) 特定のユースケースにのみ特化していて融通が利かないというものがあります. そもそもそういったライブラリに使いづらいと文句を言うのはお門違いだったりするわけですが, それはさておき他の開発者も使えることと, 使いやすいかどうか (ひいては他の開発者のことを考えて作られているか) は別ということです.

ライブラリだけの話だと思っていませんか? ドメインモデルやユーティリティなど, アプリケーション内で共通で使われるコードについても同じことが言えます. もちろん内部のコードで不特定多数のユースケースまで想定しておく必要はないですが, ある程度の汎用性と使いやすさは求められるはずです.

つまり何が言いたいかというと, ライブラリや共通コードなど, 他の開発者が使うことを想定しているものについては, 特に他の開発者のために書くということを意識しているという話でした. 実際それがどう評価されているかというと...?

推敲

より他者の役に立つような「綺麗な」コードを書くことと, 開発速度を高めることにはしばしばトレードオフの関係があると言われます. そもそも常にトレードオフなのかついては私はやや懐疑的ですがそれはさておき, もしトレードオフがあるのであれば, どの程度まで綺麗なコードを書くのかというバランス感覚や, バランスが取れる点をより綺麗なコードを書く側に近づける術を身につける必要がありそうです.

ところで私は学習もしくは最適化の方法として, 自分の出力を自分に入力するのを繰り返して収束させるということをよくやります. 自然言語の文章なら推敲という作業ですが, あんまりコードに対して推敲って言葉は使われませんね...

もちろん推敲を繰り返している分だけ時間はかかりますが (そして他の人に同じことを提案すると大体嫌な顔をされるのですが...), 木こりのジレンマに通じる部分なので, 本当に時間がないときでなければちゃんと時間を使うようにしています. 極端なケースではありますが, 全部書き直すのも厭わないです (ここで素早く書き直すためにテストの網羅性を上げておくと役に立つんですが, これもまた嫌な顔をされがち...).

もちろん上に挙げたようなライブラリや他のコードを持ってきて, 自分ならこうするといったことを考えてみても良いのですが, 正直自分の書いたコードを変更して試してみるのが一番楽です. 自分の書いたコードなら好きに変更できますし, 誰も文句を言わないので.

まとめ

  • コードを書くにあたって重要な性質・原則などは様々ありつつ, 他の開発者のためと自分に説明している
  • ライブラリや共通で使われるコードについては, 特に他の開発者にとって使いやすいかを気にしている
  • コードに対しても, いわゆる推敲と呼ばれる作業を繰り返している

といった調子で私はコードを書いています. みなさんはどうですか?