タオルケット体操

サツバツいんたーねっとでゲームとかガジェットのレビューとかをします

書いたコードはチャンスさえあればパッケージに切り出して公開すべき

Sponsored link

どうもTypeScriptおにいさんです。

こちらはLOB Advent Calendar 2018年の記事です。

前回はmojibakeo氏による TypeScript + React で i18n (国際化/多言語) 対応を楽して続けるためのアレコレ でした。
i18nには多くの苦しみがありますが、ECMAScriptはASTの規格がしっかり決まっているおかげでパースしやすくてよいですね。

そして今回ですが、またフワッとした話をします。

コードをパッケージに切り出して公開するメリット

はい。

業務でコードを書いていて「あれ、もしかしてこの処理って汎用性あるんじゃない?」っておもうこと、あるんじゃないかとおもいます。
この記事では、そういう処理はちっさくてもいいからパッケージに切り出して公開しちゃおうぜ! と、そういう感じで推奨しちゃう内容になります。
なお、実際にTypeScriptを例にとってnpmパッケージを公開する手順についてはまた後日紹介する予定です。今回は心構え編ですね。

1. 依存性を減らさざるを得なくなり、コードのクオリティがあがる

普通にアプリケーションのコードを書いていると、大抵はどのロジックも暗黙の依存性を抱えこんでしまいます。
単体テストのメリットの一つは、コードをテスタブルにする過程で依存性が明確になり、コードのクオリティが上がるというところにあるのではないかとおもいますが、パッケージ化はこれを更に推し進める形になります。

2. パッケージ配布のエコシステムを知ることが出来る

PyPIやnpmをはじめとして、各言語それぞれパッケージの公開と配布を行うエコシステムがあります。

普通にコードを書いている場合はinstall用のコマンドだけを知っていれば事足りるため、別に知らなくても職業プログラマーとしてやっていくのに基本的に問題はありません。
しかし豊かな人生のためには幅広い知識があるに越したことはありません。あとJavaScriptを書いてていると稀によく発生するのですが、利用しているパッケージの依存が壊れている場合のトラブルシューティングは、この辺の知見がないと苦労するでしょう。

どんな内容を学ぶのであれ、実践以上の近道はありません。
そういうことです。

3. 再利用しやすくなる

時々勘違いされていることがありますが、パッケージ管理ツールはかなり柔軟な形でのインストールが可能です。
なので仮に公にできない類のライブラリであっても、作法に沿ったパッケージングをして管理しておくことで社内の各プロジェクトでの導入や更新がやりやすくなります。

zipでの配布やソースコードのコピーでの運用をしなくて良くなるということですね。

3. (可能であれば)OSSにすることで誰かの助けになるかもしれない

これを最初から目指してライブラリを作るのは単純な技術力に加えて様々な技能が必要になるため、あくまで付随するメリットとなりますが、他の誰かの需要に刺さって利用してくれる……あわよくばプルリクエストを送ってくれるかも……なんて可能性もなきにしもあらずです。
また可能なのであれば、積極的にOSSを公開することで社風をアッピールして採用がしやすくなるかもしれません。

コードをパッケージ化して公開するデメリット

1. 慣れないと大変

これは各言語のエコシステムの出来にもよるとおもうのですが、実はできることがめちゃくちゃ多かったり、ドキュメントが不親切だったり……みたいな感じで最初の一歩がとにかく重たいです。筆者はPythonで最初の一歩を踏み出しましたが、当時のPythonはsetuptools問題などがありマジで辛かったことを思い出します。
プログラミングは心の強さなのでがんばりましょう。

2. セキュリティリスク

業務ドメインのコードを入れるわけにいかないので依存性が減る……の項と微妙にかぶってしまうのですが、例えばセンシティブな内容がハードコードされていたコードを切り出して使ったが、一部見逃しがあったり、しょうもないコメントを消し忘れてたり、コードの中に脆弱性を匂わせる部分があり、そこから運用しているサービスを逆引きで探されたり……。
可能性だけ上げればキリはないですが、しかしリスクがゼロではないということはちゃんと頭に入れておくべきでしょう。

3. オーバーエンジニアリングになりがち

さきほどから「依存性のないコード」なんて簡単に言ってますが、そういうコードを書くのは訓練が必要な特殊技能にあたると僕はおもっています。
外部への再利用性なんかを一切考えずにべったりで書けばする書き上がるものなのに、パッケージ化を考慮したせいで余計な時間がかかってしまった、というのはありがちな問題です。

前述したように、コードの純粋なクオリティは向上するのでどこかで手間はペイはするとおもうのですが、プロジェクトの進捗など、その時の状況に応じて対応する必要はあるかもしれません。

まとめ

いかがだったでしょうか。今すぐにでもあのヘルパーやあのコンポーネントをパッケージ化したくなってきたんじゃあないでしょうか。がんがんやっちゃうといいとおもいます。

次は cheung-chifung氏による 猫も杓子も結合テスト です。おたのしみにね!