フリーランチ食べたい

No Free Lunch in ML and Life. Pythonや機械学習のことを書きます。

命名が上手くいかないときは検算をしてみよう

命名はソフトウェア開発において、全開発者が毎日行う重要な作業です。モジュール名、クラス名、変数名など様々な種類の命名を考えなければいけません。

私はテックリードとして働いているので、チームメンバーが命名に苦戦している場面を良く目にします。命名に関するプラクティスはたくさんあるのですが、まだ紹介されているのを私は見たことがないプラクティスを紹介したいと思います。と、書くとイノベーティブなプラクティスを書くように思われるかもしれませんが、すみません、そんなことはありません。恐らくある程度経験を積んだ開発者はみんなやっていることかと思います。

そのプラクティスは「検算」です。

なぜ検算が必要かというと、命名が上手くいっていない方の多くが、実態からのみ命名をしてしまっているからです。検算というのは、この逆向きを確認することを言っています。つまり「命名から実態を引けるか」という確認です。私のプラクティスは端的に書くと、「実態→命名」をして「実態→命名」をすると上手くいくことが多いです、ということです。これでわかる方は以降の説明は不要かと思いますが、流石に言葉足らずかと思うので、もう少し説明させてください。

具体例で見てみましょう

こういうときに良い例を挙げるのは、かなり難しいのですが、頑張って考えてみます。 例えばブログサービスを開発していて、記事を非公開にする処理を書いているとしましょう。非公開時には記事のステータスを変更して、ユーザーにそれを通知する必要があるとします。

class Post:
    def XXX(self): # このメソッドの命名をしたい。
        # 状態の更新
        self.is_published = false
        # ユーザー通知
        # notify_users(self.author)

ここで、この XXX というメソッド名を命名するとしましょう。ここで良くやりがちな間違いが update_and_notify という命名をしてしまうことです。「そんなことしないよ」と思った方、確かにこの例は簡単過ぎるので、バカバカしいと感じるかもしれないのですが、詳しく分析してみると、広い意味では同じことをしているコードを見たり書いてしまった経験があるはずです。それでは詳しく見てみましょう。

実は update_and_notify という命名はある意味では正しいのです。なぜなら、このメソッドには updatenotify という処理が含まれているからです。「実態 → 名前」という方向においては正しいのです。そして、実際にこういう命名をしてしまう方が多くいます。

しかし、この命名は良くないものです。なぜなら「名前から実態を引くこと」ができないからです。update_and_notify というメソッド名からこの実際の処理を推測できる人がいるでしょうか。「名前から実態を引くこと」を考えると、命名は、多くの方が最初に思いついたかもしれませんが、unpublishmake_private のような名前にするべきだと思います。検算を行うことで、このような update_and_notify という悪い命名を防ぐことができます。

検算がもたらす効用

検算がもたらす効用についてもう少し考えてみます。「名前から実態を予測できる」命名に注意を払うことは、書籍 "A Philosophy of Software Design" において言及されている認知負荷を抑制する上で非常に重要です。この本では、ソフトウェアの複雑性を高める要因の一つとして認知負荷が挙げられています。認知負荷は、ソフトウェアを理解、使用、開発する際に必要な精神的労力のことを指し、この負荷が高いと生産性が低下します。

良い命名は、この認知負荷を大幅に減らすことができます。もしよかったら検算を使ってみてください。

時系列モデル(ARIMA/Prophet/NNなど)を統一的なAPIで扱えるPythonライブラリ「Darts」がかなり便利

時系列モデルを扱う上でデファクトスタンダードになりそうなPythonライブラリが出てきました。

f:id:mergyi:20200825003540p:plain

時系列モデルを扱うPythonライブラリは、 scikit-learn のようなデファクトスタンダードなものがありません。そのため時系列モデルを用いて実装を行うためには、様々なライブラリのAPIなどの仕様を理解しつつ、それに合わせてデータ整形を行い、評価する必要があり、これはなかなか辛い作業でした。

スイスの企業 Unit8 が今年(2020年)6月末に公開した Darts はまさにこういった課題を解決するライブラリです。時系列に関する様々なモデルを scikit-learn ベースのAPIで統一的に扱うことができます。

github.com

続きを読む

たった数行でpandasを高速化する2つのライブラリ(pandarallel/swifter)

pandas はデータ解析やデータ加工に非常に便利なPythonライブラリですが、並列化されている処理とされていない処理があり、注意が必要です。例えば pd.Sereis.__add__ のようなAPI(つまり df['a'] + df['b'] のような処理です)は処理が numpy に移譲されているためPythonのGILの影響を受けずに並列化されますが、 padas.DataFrame.apply などのメソッドはPythonのみで実装されているので並列化されません。 処理によってはそこがボトルネックになるケースもあります。今回は「ほぼimportするだけ」で pandas の並列化されていない処理を並列化し高速化できる2つのライブラリを紹介します。同時に2つのライブラリのベンチマークをしてみて性能を確かめました。

f:id:mergyi:20200726173057p:plain

続きを読む

PyCon JP 2019でスタッフとしてWebサイトの開発運用をして得た知見と反省

今回PyCon JP 2019にスタッフとして参加し、Webサイトの運用(と最適化アルゴリズムを用いたタイムテーブルの提案)を行いました。そこで得られた知見と反省をまとめて、今後他のカンファレンスなどでWebサイトの開発運用をする方の参考になれば幸いです。

本当はポスター参加記とまとめたかったのですが、ポスターの記事が長めになったので分けました。

blog.ikedaosushi.com

セッションへの感想はこちら。

blog.ikedaosushi.com

続きを読む

PyCon JP 2019でポスター発表をして得た知見と反省

PyCon JP 2019が終了しました。聴講者としてセッションを見た感想は1つ前のエントリにまとめました。 このエントリでは、自分が行った「ポスター発表」について書きます。今後カンファレンスでポスター発表をする方の参考になれば幸いです。

blog.ikedaosushi.com

続きを読む

PyCon JP 2019で見たセッションの聴講記録20個分 / 資料・動画・関連リンクなど

2019年9月16日/17日に開催されたPyCon JP 2019で自分が直接/YouTubeで聴講したセッションについてのまとめです。主に下記の内容を書いています。

  • スピーカーURL
  • 配信動画
  • スライド
  • 発表内で出てきたライブラリなどのURL
  • 自分の感想

「あのセッションで話していたライブラリなんだっけ」と思い出したい方やざっくり内容が知りたい方に読んでいただければ幸いです。PyCon JPに自分も発表者としても参加し、スタッフとして参加し、Webサイトの開発もしたので、それについては改めて書きたいと思います。

f:id:ikedaosushi:20190917173649p:plain

pycon.jp

続きを読む