「Pythonを開発言語として採用したいが、生産性はどうなのだろう?」
Pythonを採用したことのないエンジニアはそう思うかもしれません。
Pythonの生産効率は高いと言われていますが、それにはきちんとした理由があります。
この記事では、実際に私がPythonを活用していく中で、生産効率が良いと感じたポイントを解説します。
フレームワーク
Pythonのフレームワークは、学習コストがやや高いものが多いです。なので、導入に二の足を踏むかもしれません。
しかし、学習コストが高いということは、高機能で、決まりきった記述をすればその機能が使える、ということなのです。
親切に設計されたフレームワークが多く、できることをたいていほぼカバーしています。
ただし、「複雑な処理をフレームワークを用いて簡潔に書ける」という特徴は、「定量的な作業の割り振りができない」という欠点にもつながることは書いておかなければなりません。それを欠点と呼ぶかどうかは議論のあるところだと思いますが。
Pythonのコードは、コード量と処理の複雑さが全く比例しません。逆比例の場合もあります。したがって、割り振りは難しいところです。
他言語の筆者の経験だと、難しそうな処理のまとまりをハイスペックなエンジニアに割り振り、新人エンジニアは定型的な処理の部分を割り振られる、というケースが多かったですが、定型的な処理を極端に簡潔にしたPythonは、新人エンジニアの職を奪うのかもしれません。
しかし、プロにならなければ仕事がない、という面では、Pythonはエンジニア全体のスペックの向上に寄与するような気もします。
設計
Pythonはオブジェクト指向を備えています。そしてその機構は極めて簡潔です。
ただ少し、プライベートメンバ、パブリックメンバの命名規則がややこしいですね。PEP 8というPythonの命名規則のサイトから引用します。
・_single_leading_underscore: “内部でだけ使う” ことを示します。 たとえば from M import * は、アンダースコアで始まる名前のオブジェクトをimportしません。
・__double_leading_underscore: クラスの属性に名前を付けるときに、名前のマングリング機構を呼び出します (クラス Foobar の __boo という名前は _FooBar__boo になります)
引用:https://pep8-ja.readthedocs.io/ja/latest/#id24
平たく言うと、
「__で始まるとそのままの名前では外からアクセスできない」
ということなのです。
つまりプライベートメンバとパブリックメンバの区別は機構的にはないのです。
でもこれが、簡潔な設計をもたらします。
いちいちアクセス権に頭を悩ます必要がありません。
ここではオブジェクト指向の例を挙げましたが、このように、Pythonの機構は簡潔です。
これが設計をやりやすくします。
コーディング
Pythonのコーディングは速いです。
まず、処理が簡潔な記述で書けることが挙げられます。決まりきった処理はもう頭に入っていますし、それほど込み入った関数名もあまりありません。かといって、シェルのコマンドのように過度に省略されていて職人でないと意味が分からないということもありません。ですので、テンポよく書き進めることができます。
それから、Djangoの開発でよく思うのですが、例えばモデルの変数名、HTMLテンプレートで使う変数名、views.py内で使う変数名を同じものにしていても大丈夫だったりします。これは混乱しません。このような考慮がPythonのフレームワークでは随所に見られます。コーディング規約を守っていれば、これほどコーディングしやすい言語はないでしょう。
保守
Pythonの保守の最大の生産効率の良さのポイントは、誰が書いても同じ処理なら似たような記述になることです。これが可読性を大幅に上げることは言うまでもありません。なので、他人の書いたコードでも保守しやすいです。
チーム開発
Pythonはチーム開発がやりやすい言語です。
Pythonのコードは、完全にファイル内で完結しています。
グローバル変数は、スコープがファイル内です。そのシステムに普遍的なグローバル変数はありません。
また、import文を見ればどのファイルを参照しているか分かります。
したがって、ファイルさえ与えられれば(クラスを継承しているときは元のクラスも見れば)処理が理解できるのです。
これはチーム開発を容易にします。他人の書いたコードが一目瞭然なのです。
また開発の分担もファイル単位、できないときはクラス単位にすればいいでしょう。これで問題なく分担できます。
また、保守のところで触れましたが、処理の記述の仕方が決まっていて、誰が書いても大幅に違うコードにはならない、というところも、コードの読解には大いに役立ちます。チーム開発では他人の書いたコードを読む機会が増えますから。
誰が書いても大幅に違うコードにはならない、というのは、PEP 8という規約に従うことで実現します。
例えば、インデント。タブではなく、スペース4つが推奨されています。
(https://pep8-ja.readthedocs.io/ja/latest/#id5)
命名。
パッケージやモジュールの名前は、小文字の短い単語にする。
クラスの名前は、CapitalizedWords方式にする。これはこの英単語のように、単語の先頭を大文字で以下を小文字で書き、単語を連結させる方式です。
変数名や関数名は、lower_case_with_underscores形式にする。これはこの英単語のように、単語を全て小文字で書き、アンダースコアで連結させる方式です。
(ここまでの参照:https://pep8-ja.readthedocs.io/ja/latest/#id19)
このPEP 8に従って書くことで、大幅に違うコードにならないことを担保します。必ずしも従えというものではありませんが、Pythonのフレームワークが全てこの方式を採用していることもあるので、できるだけ取り入れます。取り入れることでコーディングスタイルが一致し、可読性が向上するのです。
まとめ
この記事ではPythonの生産効率が生産効率が良いと筆者が感じたポイントについて書いてきました。
Pythonの生産性の高さが技術により裏付けられたものだということが分かりました。
Pythonを使用できる開発はまだまだああります。積極的にPythonを採用していきましょう。