Oasistブログ

言語学、エンジニアリング、ライフ記事を気まぐれにお届け

スクリプト言語の嬉しみ・つらみ

f:id:oasist:20201106131903p:plain
スクリプト言語

目次

1. はじめに

最初に断りを入れさせて頂きたいが、これから書くことはあくまで個人の感想であり、「これが正論だ」というつもりは毛頭ない(まさかり大歓迎)。
あくまで私個人が感情的につらみと感じていることを、他人に言語化して伝えられるレベルに整理するために書かせて頂ければと幸いである。

私は元々SESのシステムエンジニアだったが、転職活動をきっかけにRuby on Railsを初めて触り、そこからRubyを本格的に習得した。
そして、元々大学の専攻が英語学であったということで言語に強い興味があり、自然言語処理をやるためにPythonを習得した経緯がある。
奇しくも、RubyPythonというスクリプト言語から動的型付言語という変遷を辿っている。
SES時代に研修でJavaを書いたことはあったが、本格的にコンパイラ言語を習得したことはない。

そこそこの期間スクリプト言語を書いてきて酸いも甘いも体験してきたつもりだ。
すでに世の中には私がこれから書こうとしていることに類する記事が掃いて捨てるほど公開されており、「どっかで見たことあるな」と思うような内容かも知れないが、そこはご容赦頂きたい。

2. メリット

2-1. 直観的でプログラミング初心者「には」書きやすい

特にRubyを書いているときに感じるのが、まるで文章を書いているかのようにコードを書けて、実際にそれが動かせることだ。

文系出身の全くのど素人からプログラミングを学習した私にとってはこの感覚は大きなメリットであった。
何故なら、文章を書くことや読むことは得意だったので、スラスラ書けて動かせることは生産性に直結したからだ。
また、読みづらいコードには結合度やメソッドや変数の命名ビジネスロジックそのものに問題があるので、文章力がデバッグリファクタリングで活かされるというのも幸いした。

ただし、『プログラミング初心者「には」書きやすい』としたように、C系のかっちりした言語から移ってきた人には違和感が満載らしいので(配列の添え字が負の値の場合クラッシュする等)、あくまで限定的な文脈において書きやすいという言い方をさせて頂いた。

2-2. コミュニティや勉強会が盛ん

まだ当記事公開時点ではPythonのコミュニティや勉強会には参加したことはないのだが、Rubyにおいては特に顕著なメリットだ。

プログラミングの習得というと独りでもくもくというイメージが強いかもしれない。
これは間違ってないし、この積み重ねがないと実力が伸びないのは事実だ。

しかし、第三者の知見に触れたりレビューを頂いたりすることで視野が広がったり新しい発見があるもので、そうした外部からの刺激がないといつしか「独りよがり」なコードを書くようになってしまう。

また、モチベーション等メンタル面においても、同じような嬉しみやつらみを共有できる人がいるという安心感を得られることは大きい。

2-3. 公式ドキュメントやチュートリアルが整備されている

コードを書いていて分からないことは必ず出てくるが、そうしたときに玉石混交なウェブ上の情報から欲しい知見を得るのは骨の折れる作業だ。
この点においてはRubyPythonに限った話ではないかもしれないが、公式ドキュメントという最新版に追従した信頼できるドキュメントを参照できることは、「なぜこういう実装をしたのか」を自分自身にも他人にも腹落ちさせられる根拠を示すことを可能にする。

3. デメリット

3-1. 書き方に絶対的な正解がない

Ruby on Railsの思想の一つにCoC(設定より規約)というものがあり、柔軟性を担保するために性善説に基づいて規約という合意の上でコードを書く風習がある。
コード規約は公式で存在するのだが、この合意は所属する会社やコミュニティにより異なるため、様々な「正解」の書き方が存在することになる。

それが悪い方向に作用すると、全然読めないくらいめちゃくちゃな書き方だけど、なぜか動いてるスパゲティコードの量産に繋がる。
つまり、リーダビリティの担保は実装者に良くも悪くも委ねられる訳だ。

ヒト、モノ、カネのリソースが足らない、または時間との戦いという状況においては、メリットに挙げた「書きやすさ」によって驚異的な初速を享受できる訳だが、それを長い目で見たときには話が変わってくる。
どんなに密結合でも、クラス設計がめちゃくちゃでも動いているコードは、後述するメンテナンスにおいて大きな足枷となる。

3-2. メンテナンス性の属人性

ここからは特にフレームワークにおいて顕著なデメリットを述べたい。

Java等、コンパイル言語であればコンパイル時にエラーを吐いてくれるので、機械的に動作が保証されている状態が担保されている。
しかし、RubyPythonのようなスクリプト言語は実行しないとエラーが分からない。

先述の通り、いわゆる「クソコード」でも動いてしまう。
だからこそテストコードを書くことが大事なのだ。
テストコードを書くメリットは沢山あるが、個人的に仕様を意識したコードを逆算して書くことが出来ることが大きいと思っている。
TDD(テスト駆動開発)が全てにおいてできるわけではない(テストが先に書けるということはその時点で仕様がすでに固まっていることが前提になるため)が、少なくともどういう動作をしなければならないか、またそのためにはどういうコードを書かなければならないかを意識するようになるので、自然と綺麗なコードを書くようになる(さもなくばテストコードを書くときに自分が辛くなる)。

しかし、スクリプト言語で動作が担保されるのはテストを書いた部分のみなので、「どこまでテストコードを書くか」が実装者によってまちまちになりやすく、これがメンテナンス性の属人化に繋がると思っている。

スパゲティコードの上テストが全く書かれていないコードは、言語やライブラリのバージョンアップにかかるコストが天文学的に莫大となり、もはや産業廃棄物と呼ぶにふさわしい代物だ。

スクリプト言語を扱うのなら、少なくとも自分が実装した個所のユニットテストくらいは最低限書くのが義務だと思っている(いくら属人性があると言っても)。

3-3. フレームワークに使われている > フレームワークを使っている

最近、「Rubyを書くのは好きだがRuby on Railsは嫌い」という感覚が自分の中で芽生え、強くなった。

RubyPythonスクリプトを書くのは最適なロジックを考えたり、どこまでテストコードを書こうかなど、自分自身が工夫できる余地が多いからか、「書いてて楽しい」と思う。
しかし、フレームワークは規約に則ってコーディングする予定調和なお約束コードを書くことのほうが多くて、書いてて楽しいと思うことが少ない。
Ruby on Railsコミッターの方々が、実装者が意識しなくても安全で確実な動作の最適化が進めて下さっているお陰でコードを書く量が減り、それによって特にセキュリティ面で様々な恩恵を意識せずとも享受できるというのは厳然たる事実である。

しかし、それによって先述の「フレームワークに使われている」感が否めないのもまた事実ではないかと思う。

4. まとめ

個人的にRubyPythonアルゴリズムを素直に視覚化できて書いてて楽しいので好きだが、チーム開発においてデメリットを感じる部分ことが多くなった。
今更ながらGo langやJavaなどの設定で縛ってくれる言語への憧憬が日々強くなってきている。

そろそろ本格的にコンパイル型言語を習得する潮時なのかも知れない。
もしかしたら「やっぱりスクリプト言語がいい!」と言い出すかも知れないが。