最小限のコードで動く最も汚いコードから始める

最小限のコードで動く最も汚いコードから始める 2023.09.02 コードを書く際の重要な要点は、読みやすく他人に理解される「良いコード」を書くことです。しかし、完璧を目指して最初から書こうとすると行き詰まります。代わりに、荒削りながらも動くコードを作成し、徐々にリファクタリングして完成度を高めます。型エラーやリントエラーを無視しても構わないので、まずは動くものを作成しましょう。それからリファクタリングして「良いコード」を作成できます。 コードを書くときに最も大切なことってなんだろう？聡明な読者諸君ならご存知だろうが、コードは書く時間よりも読む時間のほうが長い。だから他人に読まれることを意識して、読みやすい「良いコード」を書かなくっちゃならない。コンポーネントは適切な粒度で分割されていて、適切な名前がつけられている。型システムに安全性だって守られてるし、最新のなんとかアーキテクチャにも準拠

[asiamoth]

良かった。「Done is better than perfect.」なワケだが、「それってどのくらいの粒度の話？」を具体的に書いてあってありがたい。ほかのプログラマの思考が垣間見れてホクホク顔。

[devorgachem]

記事末にある通りテスト駆動開発のテスト書かないバージョン。テストまでちゃんと書いた方がいいこと多いと思うけど

[jay-es]

タイトルが TDD っぽいと思って読んでいたらまとめに書いてあった。フロントエンドだとテストファーストしづらいので多かれ少なかれこういう開発手法になりがちよね

[nihonbuson]

"ブラウザで確認してみよう。" / これこそまさにテストしている証左だと思う。私だったら最初のベタ書きの内容をテストコードとして流用してみるかも。「フックを呼び出す」の際の期待値としても使えるはず。

[diveintounlimit]

思考のトレースとしては妥当性は高いと思うのだが、別に汚いコードから始めてないんだよな。

[kuracom]

作業の進め方がとても勉強になる

[kazokmr]

注釈2で、別にコミットしたっていいじゃんと思ったけど注釈元を見て納得した

[suekunhello]

とても良いと思う。

[nemoba]

ぶっちゃけコンポーネント指向は実装してみないと分解のあたりが付けられないってとこも大きい。レイヤリングがしっかりしてるならコアから辺りを付けて作る。まあ、ゴールの詳細から入るなって意味では同じだけど

[aceraceae]

「汚い」って言い方はともかく最初は行って帰ってくるだけの Hello World 的なものを枠組みにしてそこにざっくり必要そうなものを埋めていく感じかな。

[sawat]

いいね。ペアプロとかやれればこの辺の進め方は自然に伝わるんだけど、リモートでコミットされたコードしか見ていないと分からないね。

[rryu]

UIを実装する時は大体こんな感じでやる。どんなUIになるか分からないとコンポーネントをどう分割すれば良いか分からないし、それなのに単体テストからとかだとゴールが遠すぎて気が遠くなるという。

[suneo3476z_tn]

まさに Vue をこんな感じで書いてた。先に正解の見た目を作っちゃった方が「ゴールは一応している（完璧ではないが）」という安心感が得られるので。

[onk]

これは良い読み物。開発の流れが非常に分かりやすい / こういった読み物特有の文体があるような気がする (「素晴らしい」「おめでとう」とかがちょくちょく挟まる感じ？) けど、何由来なんだろうな？ / もしかして：Yeah!

[xlc]

個人開発のOSSとかならこれでOK。ても予算の決まったSI案件ではこれはあり得ない。「業務アプリ」なら書き方をパターン化してコピペできるようにすべし。リファクタリングの予算などない。

[takilog]

面白かったです

[ghostbass]

きわめてまっとうなやり方で所謂「きれいなコード書け派」もこういう事繰り返してるはずだし、あとはどの程度時間を掛けるかって話

[koogawa]

めっちゃ良い記事👏自分もこんな感じでコード書いてる

[mr_ozin]

初学者にはいきなりプロダクションのコード見せるんじゃなくて、公式チュートリアルの後にこういう思考で組み立てる例が欲しくて、まさしくこれだった。

[ardarim]

なんか創作に通じるところがあるな。下手くそでもいいからまずは完成させろ的な

[fusionstar]

ふだんプログラム書くときこんな感じでちょい足しを繰り返して作っていくけど、こんなに丁寧に文章化できるのすごいな。

[szsszs]

storybookでコンポーネント単位でこれをやると良いよ。

[pwatermark]

ちなみに、「何度も書いて慣れてくると」この辺の作業を頭の中だけで済ませていきなりコンポーネント単位で書けるようになってくる

[yarumato]

“Reactで荒削りな動くコード作成からリファクタへの実例。テーブル表示なら、まずはAPIコールも変数ループも後回し。ダミーデータをJSXに直接べた書き。ブラウザで確認＝テスト駆動。ユーザーの一覧取得も動かすが先”

[zentarou]

手動での都度確認が面倒になったらテスト書くようにしてる。面倒じゃないまま完成しちゃったらe2eテスト書くだけで済ませる。e2eテストがコケたり組み合わせ爆発したりしたら単体テスト書く。

[iwtn]

普段漏れ出ない思考が読めるの良い。

[tettekete37564]

そんな感じだね。デバッグしながらちょいちょいリファクタリングして最初のpushで7〜80点のコードならOK。デバッグのためにテストを書く感じなので、今回はこのぐらい実装出来てればOKだろというところでテストと一緒に

[closer]

最初の段階ではあるべきすらわからないからテストすら書けないわけだけど、手動で確認している手順がある程度確立してきたらそれをテストに書くのが良いと思う。

[lbtmplz]

この方針はとっても分かる

[m_ogawa]

よい