Dropboxは全部Pythonで信頼性の高いソフトウェアを作った(後編)~PyCon APAC 2013

2013年9月19日

Pythonユーザーが集まり、情報交換し、交流するためのカンファレンス「PyCon APAC 2013」が9月13日、14日に都内で開催されました。PyCon APACはこれまでシンガポールで開催されており、今回初めて日本で開催されました。

(本記事は「Dropboxは全部Pythonで信頼性の高いソフトウェアを作った(前編)~PyCon APAC 2013」の続きです)

Pythonは遅いのか?

fig

Pythonに対するクレームについて見ていきましょう。

まず、Pythonはすごく遅いと言われます。

fig

でもたぶん、あなたのアプリはCPUによって制約されているわけではないでしょう。ごく限られた分野、例えばゲームとか科学計算ではないのならば、多くの制約はハードディスクやネットワーク、もしくはメモリから来ているのではないでしょうか。

それにもしも本当にCPUによって制約されているのであれば、そういうアプリはだいたいCやC++で書かれているとは思うけれど、Pythonにも選択肢はあって、それはCythonやPyPyを使うことです。

fig

あるいは、CPUに制約されている部分を小さく分離してCで書き直すのがいいでしょう。

fig

Pythonは並列処理もサポートしている

Pythonはマルチスレッディングをサポートしていないという指摘。これは正しくもあり、間違ってもいます。

fig

まず、マルチスレッディングがあるのは並列処理(Parallelism)や並行処理(Concurrency)のためで、並列処理は物理的に複数の処理をすること、例えばマルチコアの活用など、並行処理は論理的に複数処理をすること、例えばサーバのイベント処理などです。

Pythonは並列処理に対応しています。もしもプロセッサがマルチコアならば、multiprocessingを使えばいいのです。(追記 9/19 10:36 このセンテンスの表現を正確にするため一部書き換えました)

fig

並行処理も、tornado、twistedなどでサポートしているのです。

fig

さらにシェアドメモリさえサポートしています。

fig

つまりPythonでは並列処理や並行処理のためにマルチスレッドを用いる必要はない、ということなんです。

fig

動的型付けで得るもの、失うもの

最後の指摘は、動的型付けは得ることよりも失うものの方が大きい、というものです。

fig

まず、得るものとは何か? について考えましょう。ここで僕が言えるのは、動的型付けではなくダックタイピング(注:ダック型付けと書くべきか?)をすべきということです。

fig

動的型付けの利点を得ようとするのならば、規律をもってコードを書くこと、その方法を学ばなければなりません。それにはこれを読むことをお勧めします。これは僕の人生を変えた記事です。

fig

では、動的型付けで失うもの、コストとはなんでしょうか? その典型がNamErroの発生でしょう。

fig

これは変数名や関数名のスペルミス、間違った属性へのアクセスなどで起きます。でもこれはPythonの問題なのでしょうか? いや、あなたのミスですよね。

例えば、アプリケーションがデッドロックしたらそれはmutexのせい? ポインタがエラーを起こすのはNull値があるせい? そうではありませんよね。

Mutexはシェアドメモリへのアクセスを実現してくれるし、Null値はそうした値を表現してくれます。だったら、なぜNamErroが起きたことでPythonを非難するのでしょうか? コンパイラがなくてそうしたエラーを事前に指摘してくれないから?

静的分析は実行前に一般的な実行時エラーを見つけてくれます。

fig

Pythonにはそうした優れたツールもすでにあります。それにコードに対するヒントなども教えてくれるので、規律あるコードを書くのに役に立つはずです。

fig

Dropboxでも過去にNameErrorやAttributeErrorなどを見つけてくれています。

fig

自動化されたテストを書こう!

それから(静的分析に加えて)僕がさらに言いたいのは、自動化されたテストを書こう、ということです。

fig

このことは何度も聞いてるとは思うけれど、これは、絶対にするべきなのです。本当に。

fig

静的分析もテスト自動化もどちらも優れた方法であり、事前にあなたのエラーを見つけるための方法です。

そのうえ、将来あなたと一緒に働く人にとって、より自律的にコードをかけるようにもなります。将来の誰かを助けることになるのです。

fig

実は、われわれも長い間自動化テストを書いていませんでした。そのおかげで開発がどんどん遅くなっていきました。

fig

2009年11月の時点で自動化テストは0でした。いまではクライアントで1000を超えるテストコードがあります。

fig

結論。Pythonで信頼できるソフトウェア基盤は作れます。

fig

サンキュー。

このエントリーをはてなブックマークに追加
follow us in feedly


関連タグ プログラミング言語 / Dropbox / Python / SaaS / システム開発



タグクラウド(β版)

クラウド / AWS / Azure / Google Cloud
コンテナ / Docker / Kubernetes
クラウドネイティブ / サーバレス
クラウド障害 / 運用・監視

プログラミング言語 / 開発ツール
JavaScript / Java / .NET / WebAssembly
HTML/CSS / Web標準
アジャイル開発 / スクラム / DevOps / CI/CD
ソフトウェアテスト・品質
ローコード/ノーコード開発

データベース / RDB / NoSQL / 機械学習・AI
Oracle Database / MySQL / PostgreSQL
Office / 業務アプリケーション

ネットワーク / HTTP / QUIC / セキュリティ
OS / Windows / Linux / VMware
ハードウェア / サーバ / ストレージ

業界動向 / 働き方 / 給与・年収
編集後記 / 殿堂入り / おもしろ

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本