日記: 仕事に向く言語・フレームワーク
この記事の「あなたは map 派？ それとも collect 派？」のくだりを見てちょっと思うところがあった。
個人的に下の3条件を満たすのが仕事に向く言語・フレームワークなのかと思います。
目的に対して手段が多すぎない
「あなたは map 派？ それとも collect 派？」に関連しますが、
いくら多様なシンタックスが用意されていても、実際に開発で使用する範囲はコーディング規約で制限する事になると思います。
そうなると手段の豊富さが規約違反のリスクやコーディング負荷の要因などマイナス要素になってしまうように思います。
好みの域の問題をコードレビューでやってしまうのは避けたいところ。
バージョンアップの負担が少ない
下位互換を意識して開発されているツールを優先して選ぶとバージョンアップ時に旧バージョンのコードを置き換えるコストが下がり、
価値を生み出す仕事にフォーカス出来ると思います。
例えばplaybookの互換性を100%保持することを目指して新しいバージョンを開発しているansibleが良い例です。(4ページ目参照)
組織的サポートが保証されている
優れたツールでも個人開発のものだと気まぐれによるモチベ低下などで停止するリスクがあります。
停止した場合運良く引き継いで開発する個人や組織が出現すれば良いですが完全に運任せです。
例としてPHPフレームワークのsymfonyは長期かつ規則的なリリースサイクルが定められており、廃止予定機能はかなり前から告知されるので、
開発停止リスクを回避しつつバージョンアップの計画を立てる事が出来ます。
The Release Process (Contributing to Symfony)
ここまで書いたけども仕事に向くというテーマなら爆速でサーバ台数減らせるからelixir、
みたいにお金に直結する理由から絞り込むベキなんでしょうかね...
ある程度採用されているものの中から好きなやつ選べば大体なんとか出来る気がするので、
曖昧な根拠で言語・フレークワークの良し悪しを議論しても不毛なのかな、と...
職業プログラマならその時一番年収の高いものが答えって事でd(○´ω｀)bぃぃでしょ？
