コード書いてるときの実行確認頻度
コンソールやブラウザで実行するだけで動く、100行くらいのコードを書く場合
コードは「まあ実装できるかな」と感じる程度の難易度
使ったことのある言語で書く（ので一から学習するコストはない）
実行確認とは、普通にターミナルでコマンド打ったりブラウザでロードしてみたりすること（原始的）
テストコードでも良い
変更検知して再実行してくれるの(nodemonとか)を使うmiyamonz.iconkuuote.icon
なるほどsta.icon*2
先にテスト書いて、テストが勝手に動くようにすると楽ですねmiyamonz.icon
1行～数行書くたびに実行するsta.iconkuuote.iconsuto3.icon
スモールステップ&リアルタイムフィードバック、凡人の戦略です suto3.icon
あんまり細かくやっていると、ソースコードを書き換えたい時に億劫になりそうMijinko_SD.icon
十数行くらいの単位でがーっと書いてから実行＆修正していく
50行くらいがーっと書いてから実行＆修正していく
型が強い言語だと、IDE上の型のエラーを消しながら作っていくとエラーが消えればだいたいうまくいってるmrsekut.icon
「IDE上に表示されるコンパイルエラー」は「実行」に含めるのかわからないけど、
テスト結果をリアルタイムに実行してIDE上に結果を表示できるので、同じようなものかもしれない
ブラウザ上の処理を見ていなくても、何かしらのフィードバックを手掛かりに実装を進めてるという点では同じ
という意味では、「1行~数行書くたび」なのか？
100行一気に書いてから実行＆修正していく
よくないとは思いつつ、ついやってしまうyosider.icontakker.icon
よくできるなと感心してしまうkuuote.icon基素.icon
実行しないといつでも誤った仮定の元に作業を進めているのではないかという疑念が発生してしまう
疑念はあるけどそれ以下のコードがガラッと変わる程間違ってはないだろうという慢心yosider.icon
僕もめっちゃ感心しているsta.icon
どこがおかしいか見抜ける力（？）がないので、小さく作り上げていかないとお手上げになってしまう
何も考えずに書くと1000行届かずにもう手も足も出なくなる
1行くらいで実行しまくるスタイルにしてから1000行以上のコードもつくれるようになった
1000行一気には無理yosider.icon
でも、使ったことないメソッドとかで出力の型がわからないときはそこだけ実行するyosider.icon
これはやるtakker.icon
ほとんど何も考えていないtakker.icon
考える前にどんどん手が動いてしまう
多分実装方法の目途がだいたいついているからだと思う
ぜんぜん知らない言語やライブラリだとこうはいかない
バグが含まれていないか心配になることもあるけど、手が止まらないのでどうしようもない
こまめにテストしたほうが後戻りが少ないのに、そのままcodingすることを継続してしまう
以下は別
テストしやすい言語環境のとき
たとえばDenoで純粋なalgorithmを書くときは、テストも同時に書く
書くといっても、結局1module書き上げたあとにはなってしまうが
実行せずにバグの洗い出しをできるのでとても便利
静的解析ツールが充実しているとき
文法チェックと型チェックである程度バグを防げる
UserScriptをScrapboxにベタ書きする場合は文法チェックすらないので大変だった
よくあんなこと平気でやってたな……
100行の項目に書いたけど、実際のところはよくわからないtakker.icon
そもそも行数とコードの複雑度？の相関がどれほどあるか疑問
コメントや空行も含まれているし
100行の函数1個と10行の函数10個なら、(まともに責務を分けている限り)後者のほうが複雑度が小さいだろうけど
おっと前提を読み飛ばしていた
この条件なら確実に全部書いちゃってから動かしているな
テストを書くのを面倒くさがっているだけかもyosider.icon
結局全部書いて動かしてみないと正しく書けてるかわからないと思ってしまう
型ぐらいならわかるけど
デバッガなしだと行数増えるとつらいyosider.icon 挙動が予測できない複雑（または不慣れな）なソースコードを書いている時は、少し書き換える度に実行することがある
別の場所にテスト用のコードを書いて実行することもMijinko_SD.icon
うまくいったら、そのテスト用コードを本筋のコードに移植する
そうではなくある程度のノウハウが自分の中にあって、書くべきコードがなんとなく思いつく程度のレベルであれば、あまり細かいテストをせずにざっと書いてしまうことがある
これだなあtakker.icon
その過程で想定外の細かいバグは出るかもしれないが、それらは書ききってからデバッグするのでも直せるので気にしない
カプセル化を確実なものにするために、ある程度の塊を作ったら実行して検証してみる（のが理想だけどしないこともある） その時点でその塊が想定通りの動きをしたならば、後から手を加えたりコードを読み返したりする必要性が小さくなる
逆にこれをやらないと、小さなバグ（誤字など）でもコードの大部分を確認する羽目になって大変
予め「この部分は正常に動く」ということを検証しておかないと、範囲が無駄に広くなって原因の特定に時間がかかってしまう
前提条件にある100行くらいのコードではあまり関係のないことだけれども