達人プログラマー を読んだ【書評】
こんにちはtozicaです。
今日は日曜日！
この記事は、エロゲーとか作ってるクリエイターの制作日記です。
noteなので直接的なエロ表現はありませんが、えっちな話が苦手な人は気をつけてね。
達人プログラマー を読んだ
この本、何年か前にKindleで買って、ずっとKindleライブラリの肥やしになってたんですよね。
それで、さすがにそろそろちゃんと読むかぁ…って思って最近ちょこちょこ読んでまして、この前読み終わりました。
なので、今日はその感想を書きたいと思います。
この本は、タイトルからも分かると思いますけど、プログラマーの人に向けてのある種の自己啓発というか、より良いプログラマーになるための心構えみたいなものを書いた本です。
コーディングする上でのテクニックだけじゃなくて、周りのチームメンバーとの関わり方とか、知識や技術をどう高めていくのかとか、そういうプログラマーとしての生活全般に関するトピックが書かれてる。
この本、もともと2000年頃に出版された書籍で、それが2016年に新装版として改訂されて出版されたという経緯なんですよね。
わたしがこの本を買ったのも、会社に入ったばかりのまだやる気に満ち溢れてた頃だったので、たぶん2017年前後とか……そこらへん？
なので、出てくる固有名にもだいぶ時代を感じるし、特に移り変わりの早いIT業界においてはもはや歴史書のような風体さえ感じるところさえあります。
C++の話題で「std::auto_ptrを使おう！」みたいに書いてあったりとか。
もう10年以上前のとっくの昔に std::auto_ptr は使用非推奨になっていて、今では主に std::unique_ptr や std::shared_ptr 等がその代わりに使われています。
その一方で、本書で書かれているトピックの数々は、いずれもプログラマーとして生きていく上では非常に普遍的であり、例え具体的に使う技術の名前は陳腐化していたとしても、本質的な部分にはずっと色褪せない価値があるな、と思いました。
実際、上のAmazon商品ページのやつは、わたしが買った時よりもさらに後（2020年）に第二版として出版されたものなんですよね。
そのくらい不朽の名作として評価された作品だということです。
昨今ではテスト駆動開発やアジャイル開発など、様々な開発手法が提案され活用されていますが、この本はそれらの用語がまだ生まれていなかった2000年頃に書かれた本であるにも関わらず、それらと同等のテクニックの重要性を紙面の多くを割いて説いているんですよね。
こういうところからも、この本の革新性、オーパーツっぷりが分かるのではないかと思います。
記憶に残ったトピック
以降は、この本に書かれたTipsのうち、個人的に記憶に残ったものについてつらつらと書いていこうと思います。
Tip 20. 知識はプレインテキストに保存すること
ソフトウェアの設定とか、何かしらのデータとか、そういうものはバイナリデータじゃなくてプレーンテキストで保存した方が、後々の取り回しが良くて便利だよ！…という話。
透明性が保証されるとか、そのデータの本来の用途以外にも色々活用できるとか、テストが容易になるとか。
これね～～～、ゲーム制作においても本当にそうなんですよね。
アイテムの情報とか、敵のパラメーターとか、そういうものはなるべくプレーンテキスト形式の外部ファイルとして扱うようにしておくと、ゲームのプログラム本体で使う以外にも色々な解析とかに使えるようになる。
例えばデータをPythonとかで読み込んで何か解析したりとか、逆にデータを自動的に生成してゲームで使ったりとか、そういう感じで制作の効率化に繋がるわけです。
なので、この章はとても納得しながら読んでた。
Tip 22. 一つのエディターを熟知すること
色んなエディターをつまみ食い的に浅く広く使うんじゃなくて、一個の多機能エディターに熟達して、全ての作業をそのエディター上で行うようにすると仕事が捗るよ！…という話。
わたし自身、何年か前までは全ての作業にEmacsを使っていて、その後はVSCodeに移行しています。
正直まだまだ熟達したというほど使いこなせてはいないんですけど、それでもここで書かれていることは「確かにそうだなぁ…」って頷きながら読んでた。
ちなみに本書は上で書いたとおり2000年に書かれた本なので、この章で出てくる「例えばこんなエディタを使うといいよ！」っていう例の中にVSCodeは出てこないんですよね。
具体的には Emacs とか Vim とか、あと2016年に足された注釈だと Sublime Text とか Atom とか。
VSCodeがリリースされたのが2015年とかなので、載ってないのもまぁそれはそうか…と思うんですけど、こういう所からもプログラマー界隈の時間の流れの早さを感じちゃった。
もう最近はだいたいみんなVSCodeだもんね。
Tip 29. コードを生成するコードを作成すること
本書では色んな方向からとにかく「自動化できるものはなるべく自動化しよう！」という話をしてるんですけど、これもそういった話の中の一つですね。
新規にソースファイルを生成する時にテンプレートに出来る部分はなるべくやっておこうとか、同じデータ構造を異なる言語で多重的に書く必要がある時には自動的にそれらのプログラムを生成できるようにしようとか。
これも本当にその通りだと思うんですけど、自分自身ではまだあまり実践でてきてない部分でもあるので、頑張りたいなぁって思いました。
例えば拙作「カナデエスケイプ」の制作においては、各シーンのスクリプトを全部Godotの標準である gdscript で書いてるんですけど、これらのシーンスクリプトの中には、各シーンにまたがって何度も繰り返し出てくる記述とか、一つのスクリプトの中で多重的に記述されてる情報とかがめちゃくちゃあるんですよね。
例えばシーンの冒頭でユーザーデータを呼び出す処理は、どのシーンスクリプトにも書いてある…とか。
だから、もし今もう一度これをもっと賢く作るなら、各シーンを定義するgdscriptを生成できるようなオリジナル形式のスクリプトをデザインして、その上で書いていけば良かったのかも知れませんね。
そうすれば、本作の制作スピードは今よりももっと上げられたのかな…って思ったり。
もしまた似たようなシステムのゲームを作ることがあったら、その時はそういう作り方をチャレンジしていきたいな。
Tips 44. 偶発的なプログラミングを行わないこと
ここで言う「偶発的なプログラミング」というのは要するに、境界条件を含めた厳密な動作確認とかそういうちゃんとしたテストを行わないまま、とりあえず動かしてみてそれっぽく動いてるようならそこで満足する…というようなコーディングのやり方のことです。
つまり、偶発的なプログラミングをやるなっていうのは、ユニットテストとかをちゃんとやろうね、って話なんですけど。
この歌詞……私のことだ……。
これはね～～～～、ほんと思い当たる節が多すぎて「すみません…」ってなっちゃった。
もっとちゃんとテストする習慣はつけたいなぁとは常々思ってはいるんですけど、思うだけで改善しないままここまでズルズル来ちゃってるので、良くないよねぇ…ってなってる。
次は……次こそはがんばります……。
そんなわけで、なかなか身につまされる部分もありつつ、非常に有用な知見が色々得られる本だったなぁって思いました。
これが20年以上前に書かれた本ってことを思うと、著者の先見の明には改めて驚くばかりですね。
そんなわけで、多少なりともプログラムを書く人にはオススメの本だと思うので、興味がある方はぜひ読んでみてね。
座右の書としてもかなり有用だと思います。
おしまい。