本記事はPerl Advent Calendar 2018の3日目の記事です。
初めてPerlを使った開発プロジェクトに携われたのが嬉しくて、そのことについて書こうと思います。
記事を書くきっかけ
自分はSESで主にSIer系の様々な現場に出向して仕事をしています。
今の現場ではPerlが採用されています。自分自身、懐かしいなーと思いながら日々開発を進めています。
Perlの文法は自由度があって楽しいです。ですが、これがチーム開発となると制約が大きくて敬遠される
という声も聞きます。
そこで、実際に業務でPerlを使うときの良い点・悪い点を自分なりに整理できればと思いました。
稚拙な点はぜひご指摘ください。
記事の目的
・開発現場でPerlが主な言語として採用されており、なぜPerlを採用したか調べるため。
・開発現場の事情は普段なかなか目にすることはできないので、少しでも情報を共有できれば良いな
と思ったため。
本文
- 顧客・開発現場の組織特性
- 組織特性を踏まえたPerl採用のメリット
- Perlを採用したことで起きている問題・デメリット
- 今後の展望
顧客・開発現場の組織特性
・組織としてPerlを採用したのは2008年くらいから。開発者が各自で使っていたのは20年前くらいから。
・サービスの長期継続を見込んでいる(5~15年くらい)
・「自前主義」な面が強い
お客さんは自前のデータ収集機構を持っています。収集したデータをさまざまな用途に
加工して、ユーザにサービスすることで対価を得ています。利益の最大化というより
は、利益の出る範囲内で長期的にサービスを行うことが主目的のようです。
なぜかというと、お客さんが提供するサービスは生活に密着しており、データの質が流行り
に左右されないからです。
お客さんはエンジニアの個人的な能力を評価する傾向があります。そのため、能力の
ある個人が主体となって開発を進めることが多いです。自分が担当しているサービスはRDBMS
を使わず、データはJSONファイルをUNIX OSのディレクトリに格納して管理しています。
データベースといえばRDBMSを想像していたので衝撃を受けました。
RDBMSがメジャーになる以前から大容量のデータを取り扱っていたということもあってか、
RDBMSを使うとデータ容量が爆発的に増えてストレージ容量を圧迫する可能性が高いということ
で使っていないのだそうです。
これは推測ですが、ミドルウェアを使うと障害発生時でもベンダーの内部事情に大きく制約され
るので、それが嫌なのかも知れません。Oracleとか、露骨にそいういうことをやりますよね。
緊急障害なので早く対応して欲しいのに、ビジネスインパクトがどうとかいう書類を書かされて、その内容によって対応の優先度を変えられたり。。そもそもビジネスインパクトを第一に考えるならクソ高い
データベースなんか採用したくありません。ただでさえ高いライセンス料を支払って、更に待たされないために書類を書かされるときました。お役所仕事ここにあり。これこそがベンダーロックインの最たるものと疑いません。
組織特性を踏まえたPerl採用のメリット
・言語として安定しており、長期運営に向く
サービスの長期継続を見込んでいるので、流行に左右されないのは大きなメリットです。
Perlはシステム開発に必要な機能が安定したレベルで一通り揃っています。リファレンスも
充実しているので、導入コストは低いと思います。
また、10年以上前に開発メンバーによって書かれたローカルライブラリでさえ、現役でバリバリ使えるのでとても助かります。
言語として後方互換性が保たれているのはかなり嬉しいことです。
Perlを採用したことで起きている問題・デメリット
・モダンな開発に対する意識を育てにくい
・高品質な開発を推進しにくい
言語の問題というよりも周りの環境の問題ですかね。
最新のフレームワークに触れたり、継続的インテグレーションを考えたり、OOPを意識したり、
そういったことを推進しにくいです。
個人的には、言語のデメリットはないと思っています。
Rのように、大量データ加工に向かないだとかいうこともありませんし。
モダンな環境に触れていると、（それが良いか悪いかはともかくとして）最新の考え方を取り入れやすく
なります。何も考えずにPerlで書くと、OOPをやらずとも一枚岩のロジックで何とかなってしまいます。
開発規模も小規模なものが多いので、テストコードを書かなくても何とかなります。
ただ、ソフトウェア開発の質を高めようと思うと明らかなマイナスです。技術負債も大きくなります。
1000行近くもあるmain関数が一つだけの.plファイルは読みたくないですよね？
自由に書ける一方、良い書き方を啓発しづらいのはデメリットです。おそらく、Perlの最新書籍が少
ないのも原因の一つだと思います。
今後の展望
・フレームワークの使用
・より高品質な開発に耐えられるようにする
現行システムは、構成としてはWebアプリです。フレームワークを使えばある程度効率的に
開発できると思います。フロントエンドは独自フレームワークっぽいものをJavaScriptとJQuery
を使って実装しているので、Mojoliciousを使うことも考えています。SPAを意識して作ら
れていますが、実装の欠陥も多いので、どうやって技術負債を返済するか考え中です。
また、TDDを推進するためにテストコード作成に力を入れたり、OOPを意識して柔軟な開発を
できるようにしたいと思っています。
お客さんはシステム開発に重きを置くよりも、サービス開発に重きを置いています。
柔軟で変化に強く、すばやく結果を見られるように開発を行うことが、より求められ
ていくと思います。
できるだけソフトウェア開発の制約に縛られることなく、お客さんがやりたいことをやれる
ようになっていきたいと思います。
記事を書いていて思いましたが、ソフトウェア開発の品質を制約するのは、使われる言語
ではなく開発者の意識の持ち方にありそうです。というわけで、今後も堂々とPerlを使って
楽しく開発を進めていこうと思ったのでした。
明日は@hkobaさんです！