共同開発の反省

42にてminishellという共同開発課題をする機会があったのでそれについての反省。minishellのヒントとかない。ただの日記。チラ裏。

大きく以下4つ
・技術的に手に余る部分を受けてしまう(受けるどころか取りに行く)
・ギブアップ宣言が遅い
・開発順序の考慮が足りない
・仕様理解が甘い

とにかく大きいのが仕様理解の甘さ。後になってあの機能この機能の追加で別のところからバグが出てくる地獄。
今回は割といろんな記事を読んだつもりだったためどうしてこうなってしまったのか、一見スムーズに進んでるようなチームはここをどういう風に取り組んだのか不思議。
そもそもbashの公式ドキュメントしっかり読もうって話か。
いろんな人の雑多なshell周りの記事はたくさん読んだけど一番大事なbashの公式ドキュメントとman bashにはそこまで目を通していなかった。という反省。正直書いてあることと読み取ったことに違いがでる自分の頭でここをどうにかできるようになるのか謎だけど、、、永遠の課題になりそうな予感。
解決策　たくさん場数を踏むことくらいしか思いつかない

仕様の理解がそんなものだから「抽象構文木作りました！」（構文解析器はエスケープ周りでバグが頻発したので作り直してもらいました。）
「さあこれからどうしましょう、作った木はどうやって使えばいいんでしょうねぇ」みたいな話になる。あほか。
結局木を使うことなくパラメータの受け渡しでどうにかする。どうにかなってよかった。再帰の深さが心配だったけど、、、
解決策は仕様の理解をしっかりして全体の構造をつかむとか？
先は長そう。いや、当たり前のことなんだけども。

ということで木の作成でグダグダしている間に他のほとんどの処理をお相手に作って頂いてしまっていた。で自分はこれからredirectとpipe。しかも自分がやりたいって言っちゃったやつ。流石にここは頑張って土日は完全に潰して徹夜とかしちゃって仕事もきつくて帰ったらminishellで、ここまで来てやっぱ無理ですなんて絶対言えないし死にたくなりながら勝手に一人で炎上してた。

勝手に一人で炎上、ほんとに意味がわからない

結局最後の最後までredirectとpipeで格闘して自力でなんとか納得いくとこまで行ったのはよくやったと思う。で、結局そもそも仕様を読み込めてないわけだから微妙にbashと挙動の違いが生まれちゃったり、斜め上なケース試されちゃったり、最後にちょこちょこっと修正掛けたところでバグが生まれてたりするのだった。

口癖のようにやります、やってみますっていうのもだめだな。

あと、タームキャップの実装でメルカリで本を購入した後、届くまで一回休み状態になったのも良くない
その間に他のことをやればいいのにできなくなるのなんなんだろう
何かを待たないといけなくなった時に他の事やらずにイライラしながらただひたすら待ってしまうのはなんか動物っぽい挙動だな。

で、なんとかちょっと強引なディフェンスしてminishell通ったものの一人炎上の副作用か自宅ＰＣの前に座れなくなった。座ると磁石の反発のように精神に抵抗が出るので別な開発環境考えないと。

追伸
メルカリで初めて本を買いました。コメントに「購入ありがとうございました。特にいうことはありませんけど、購入量に対して送料が気になりましたね。次はまとめて買うといいでしょう。」
とありまして、送料の割合緩和のためにいらんもん買っとったら本末転倒やろがい。と存じます。