プログラミングの入門書、「ゼロからコードを書いていく」ことは教えてくれるけど、「今あるコードをどうやって壊さず機能を追加してくれるか？」というのは教えてくれないんだよな
— magnoliak🍧 (@magnolia_k_) 2022年3月19日
ゼロからコードを書いている時間より、既存のコードを読んで影響を確認し、改修している時間の方が圧倒的に長いのに
プログラミング言語の文法や、ツールチェーンの使い方を一通り覚えた後、実際にプロダクションコードを書く場面で最初にアサインされることって、”プロダクションレベルのアプリケーションのコードをゼロから一気にリリースクオリティまで書き上げる”ことではなく、”既存のコードに対する小さな改修”だったりしませんか。
そんな時、『入門 機能追加』があればいいのに、と思ってしまう。
『入門 機能追加』の執筆が待たれる
— magnoliak🍧 (@magnolia_k_) 2022年3月19日
・設計意図を残すドキュメント・コードの書き方
・効果的なコードリーディングの方法
・既存コードを壊さない改修の方法、プラクティス
・先を見据えたリファクタリングの方法
コードは書かれる時間より、読まれる時間の方が圧倒的に長いのだから。
前回のエントリでも書いたけど、目の前の最短が必ずしも全体の最適・最短ではない、みたいな話も有って...当たり前に適用していかないといけないプラクティスを変えていかないといけないのかもしれない。
昔はテストコードを書くことだって、「特別なこと」だったし、それでコストが増える、となれば「余計なこと」と思われた
— magnoliak🍧 (@magnolia_k_) 2022年3月19日
でも、今では書くことが当たり前になっていて、書かないことへの理由（スピードとか、濃淡とか）を表明する方に変わった
リファクタリングも同じ位置付けになる日がくるか？
リファクタリングに向けて言語機能や、ツールチェーンがどんなサポートをしてくれて、当たり前に適用していく...これを特別なことではなく、現代におけるテストコードを書く、というのと同じくらい当たり前のことにしていければいいんじゃないか
— magnoliak🍧 (@magnolia_k_) 2022年3月19日
とは言っても、そんな本、容易に書けるのかなーという話もあり、世界は難しい...
これ欲しいけど、既存コードと実装言語に依存するから書籍化（パターン化）するの難しいんだよね。書籍にしたとしても "良い実装から逆算したものを問題のある実装として、リファクタリングを進める"みたいな内容になるので、現場で活かせないんだよな。 https://t.co/tKart3tZ3U
— pospome (@pospome) 2022年3月19日
結局「その書籍の例だとそうかもしれないけど、じゃあ僕が今抱えている実装だとどーなるんですか?」ってなってしまう。だからプログラミングって難しくて面白いんだよね。エンジニアとしての実力が出る。
— pospome (@pospome) 2022年3月19日
これはデザインパターンを暗記したけど、どこで使えばいいか分からない問題に似ている。
— pospome (@pospome) 2022年3月19日
という話をしていたら、こんな話もあり、世界はまだ希望が有る！ようです。
これを解決するのが僕の本なのだ。 https://t.co/ms44ps2C0L
— ミノ駆動 (@MinoDriven) 2022年3月19日
