【寄稿】Software Design 2024年12月号 第1特集 第4章 落し穴に落ちないシェルスクリプト開発のススメ
祝！Software Design 3回目の寄稿
技術評論社のSoftware Design 2024年12月号 第一特集に寄稿させていただきました。3回目です。びっくり！未読の方は、是非ご一読ください。
過去2回に引き続き、内容はシェルスクリプトに関する記事です。2022年1月号はPythonに関して説明していますが、シェルスクリプトと比較した記事になっています。過去の寄稿に関する感想は、別記事でまとめてあります。
本記事では、自分向けの備忘録として、執筆スケジュール、記事構成について、ヤラカシたこと、余談3点を紹介します。
今回の執筆スケジュール
基本的には、1ヶ月ほどで原稿を一度書き上げるスケジュールとなっています。原稿提出後に、半月ほどで微修正を行います。今回は、期間中に3連休が2回あったため、余裕を持って書き上げることができました。
以下がタイムラインです。ちなみに、私はGitHubで原稿を管理し、毎週日曜日に書きかけの原稿を提出するようにしています（進捗報告したいだけ）
- 2024年09月10日：寄稿依頼をメールにて受領
- 2024年09月11日：構成変更の提案
- 2024年09月12日：章の構成案を連絡
- 2024年09月13日：章の構成案がApprovalされる
- 2024年09月17日：50%執筆
- 2024年09月23日：10ページ執筆完了（ページ数オーバー）
- 2024年10月07日：技術評論社からフィードバックを受領
- 2024年10月12日：原稿（フィードバック反映済み）を提出
- 2024年10月15日：一次締め切り
- 2024年10月21日：PDF見本+フィードバックを受領
- 2024年10月23日：フィードバックに対して回答完了
- 2024年10月28日：誌面の修正完了日（技術評論社側）
- 2024年10月29日：ShellCheckとShellSpecの取り違えに気づく
- 2024年10月31日：完成（入稿）
赤字の部分を後述していきます。
構成変更を提案した理由
最初は、技術評論社側から以下の内容（シェルスクリプトの落し穴）を提案されていました。
- 正しくオプションを設定する
- 変数の罠
- 普通のプログラミング言語ならできるけど、シェルスクリプトではできないこと
- ShellCehckによる静的解析
上記の項目を見たとき、「中級者以上が面白みを持ってくれるだろうか」「過去の記事で殆ど取り扱ったことがある（原稿執筆に苦戦しそう）」「シェルスクリプトに向いてないことはあっても、できないことは少ない（”できない”と表現すると反感を買う可能性がある）」と、考えました。
また、落し穴を多数紹介する方式だと、どこかのネット記事のコピペになってしまう恐れがありました。
そこで、開発プロセス（ツール）に焦点を当てれば、初心者から中級者までカバーでき、面白みのある記事になるのではないかと考えました。誌面で紹介できる落し穴には限りがありますが、ツールを導入すればツールが網羅的に落し穴を塞いでくれます。
問題はページ数が増える可能性が高かったことです。幸いにも、編集ご担当者様が快くページ増をご許可くださいました。
最も書きたかったのは、ShellSpecを用いたユニットテストに関してです。「シェルスクリプトでテストしたくない」という意見が出るのを待っていましたが、あまり見かけませんでした（not for meは見かけました）。ユニットテストを書くぐらいなら別言語を採用するのか、シェルスクリプトをユニットテストで動作保証していくのかは、開発者自身が判断することだと考えています。正解はないです。
テストを書くということは、テスタブルに実装する必要があります。記事中では直接的に説明しませんでしたが、「関数化は当たり前」「シェルスクリプトでもライブラリを作れる」という雰囲気を醸し出したつもりです。
入稿ギリギリに盛大な誤記に気づく
今回、大変申し訳無いことに、入稿直前に盛大な誤記を見逃していることに気づきました。
具体的には、ShellSpecと書くべきところをShellCheckと書いたり、その逆をやらかしていました。また、ツールの仕様に関して誤解を招く記述をしていた点もありました（こちらは誤記ではない）
申し訳無さと、「このままリリースされたくない」という気持ちで一杯でした。
このやらかしは、間違いなく2024年No.1です。この場を借りてお詫び申し上げます。次回からは、第三者チェックの回数を増やします（一応、今回は会社の方がチェックした原稿でした）。
余談1：TDDやBDDは気を使って書いた
TDD（テスト駆動開発）やBDD（振る舞い駆動開発）は、誤った捉え方をされないように、注意を払って書いたつもりです。ただし、分量の都合で、必要最低限しか触れられませんでした。
誤った認識とは、以下のような捉え方です。
- TDDは、テストから書く手法
- BDDは、Gherkin記法でGiven、When、Thenを使ってテストする手法
TDDは、期待される動作をリストアップして、テストリストを作るところから始まります。いきなりテストを書くのが正解ではありません。詳細については、t-wada氏の記事（テスト駆動開発の定義）を参考にしてください。
BDDは、プロダクトオーナー、エンジニア、QA担当者などの関係者がユーザーストーリーに対して、ルールや疑問を発見（Discovery）することから始まります。Gherkin記法が登場するのは最後です。
TDD／BDD界隈からマサカリが飛んでこないように、注意したつもりです（TDDは、本当に少ししかフォローの文章を書けなかったので、誤解を招いた可能性があります）
余談2：サンプルコードはmacOSで偶然エラー
記事の終盤では、テストコードを書きながらサンプルコードを組み立て、GitHub Actions（自動テスト）を実行すると「おや、macOSでシェルスクリプトが動かなかったね。直してみようか！（意訳）」のような流れで進みました。
この流れは、狙ったものではありません。
最初に書き上げたサンプルコードがmacOS（※）で動かず、私は内心焦っていました。しかし、途中で「TDDを採用している書籍だと、わざとエラーを発生させてから修正する流れがあるな。そんな感じで書くか」と思い直し、軌道修正しました。
※ 私のメインPCはLinuxです。Typoraエディタで執筆しました。
なお、今回は意外とmacOSが鬼門でした。特に、sedコマンドがバージョンアップされてて、「昔はGNUライクに書けなかったのに、今は書ける」みたいな状況が多々発生しました。
余談3：ヤラカシのせいで伝えられなかった一言
実は私、シェルスクリプト界隈の開発者ではありません。
bash互換のosh、bashにコンパイルできるamberなどをウォッチしていますが、シェルやシェルスクリプトに関する知識が突出している訳ではありません。
本業は、GolangやAWSを使うバックエンドエンジニアです。Golang製のOSSを沢山作っています。そんな私には「Golangの記事も書いてみたいな〜」という下心がありました。
ずる賢い私は、「今回の記事を書ききったら、”Golangもイケるので、寄稿の機会があれば是非！”と最後に売り込みしよう💡」と画策しました。
しかし、愚かな私は盛大な誤記をヤラカシたので、売り込みするチャンスを失いました。あたしって、ほんとバカ。
ロシア人と国際結婚した地方エンジニア。
小学〜大学院、就職の全てが新潟。
大学の専攻は福祉工学だったのに、エンジニアとして就職。新卒入社した会社ではOS開発や半導体露光装置ソフトを開発。現在はサーバーサイドエンジニアとして修行中。HR/HM（メタル）とロシア妻が好き。サイトに関するお問い合わせやTwitterフォローは、お気軽にどうぞ。
