Railを捨てて荒野に繰り出す決断をした話
久しぶりの技術ネタです。
今の会社で1年前にRuby on Rails(以下RoR)を採択して
今まさにPHPへの移行を行おうとしています。
技術選定におけるあれこれについての反省を書き連ねて行ければと思います。
前提としてRoRはとても素晴らしいFWです。
「RoR disってんのかよこのクソPHPerが！」
という声が聞こえてきそうなので念のため書いておきますが
RoRは本当に素晴らしいFWです。
基本をPHPとしつつPerlもJSもPythonも触ってきましたが
とてもしっかりとしたレールが轢かれていて
ライブラリも豊富にあり
web開発においてとても有力な選択肢のうちの一つだと思いました。
勉強しながらの開発ではありましたが
レールに乗って開発をする楽しさはなかなか面白いと感じる事が出来ました。
でも乗り換えるには理由がある
RoRにおける最大の問題としては
処理におけるブラックボックスが発生しやすいという事だと思います。
これはRubyの問題ではなくFWにおける問題の一つです。
うまくFWにはまっている開発を行う分には良いのですが
FWから逸脱した要件が発生した時にフルスタックフレームワークは牙を剥いて襲ってくるなと感じました。
PHPにおけるLaravelやSymfonyにおいても同様の問題は発生しがちです。
もちろんあらゆる問題を解決するために様々なモジュールやライブラリの開発が行われていますが
根本の解決に繋がらないケースやフレームワークの根底に対してチャレンジングな実装をしているものも多々あると感じます。
特に外部インスタンスに依存するようなAPI開発やNoSQL接続に関しては
かなり神経質にならないといけない上に
ライブラリに合わせて開発を進めてしまった後でライブラリの不具合や仕様要件不足
はたまた開発停止などでライブラリを乗り換えなくてはいけなくなった時に
本当の地獄の始まりをひしひしと感じます。
乗り換えにあたって重視した点
現在のシステムはAWS上で稼働しており
RDS、ElasticsearchService、mongoDB、外部API(http)との接続があります。
データが複数インスタンスに跨って管理されているものを
ひとつの業務システムのデータとして扱わなくてはいけないので
割とゴリゴリとした実装になりがちで
データの複雑性に耐えられる、かつ実装のスピードが確保出来る保守性の高いシステムでなくてはいけません。
技術選定にあたって今回気にしたのは
- ライブラリの変更が容易である(フレームワークにロックインされない)
- 技術情報が豊富にある(メジャーである)
- エンジニアの誰かが中心になれる(詳しい人が内部にいる)
- 採用が容易である(メジャーである)
- ソースを追いやすい(困った時には外部から取り込んだライブラリでもソースを追うため)
という点です。
採択にあたっての決め手
選定における条件の中で「ライブラリの変更が容易である」という点を重視したため
今回はマイクロフレームワークを中心に考えることになりました。
社内のエンジニアの技術スタックの中で共通している言語はPHPとJSでしたが
「詳しい人がいる」という点でPHPが有力視されました。
また、過去の職場でマイクロフレームワークでの開発実績があり
今回の要件にマッチしそうという事でSlim3が最終的に選ばれました。
SlimはPHPのフレームワークでroutingしか無い、という
マイクロフレームワークの中でもかなりマイクロな構造です。
過去のプロジェクトや個人的な開発のノウハウを投入して移行先のベースは作りましたが
各オブジェクトが疎結合な状態でテストをちゃんと回せる状態になっており
かつライブラリと自作部分を組み合わせて一般的なMVC構造になっているので学習コストも割と低いと思います。
今後の展望
PHPにおいて容易で学習コストが低い故に
低スキルエンジニアを量産してきた歴史がある事は否定できませんが
容易で学習コストが低いからこそ高度な事に手を出しやすいのが今のPHPの良い所だと思います。
もっと綺麗で見通しの良いコードが書ける言語も出てきていますし
どうしても言語特有のバグの問題や
WEBの世界にロックされがちでPHPのタグが気に入らないという意見も受け止めるべきだとは思いますが
食わず嫌いだけでPHPを避けるより
言語選定においてまだまだ有力な選択肢のひとつであるという事を知ってもらえればと思います。
いや本当はRuby使うならSinatraとか使えば良かったじゃんって話なんですけどね。
CodeIgniterじゃなくてSlimってところが今のシステムの悩ましいポイントです。
