多人数プロジェクトで学んだこと - <s>gnarl,</s>技術メモ”’<marquee><textarea>￥

この書き方はまずいからあとで直そう→直さない あとで拡張する必要がありそうだ、必要になったら設計を変えよう→まずい設計のまま他人に使われる コミュニケーションしなくても正しい判断ができるようにする 正解がないことは、走りながら臨機応変に変えなければならない。でも、始まった時から正解がわかることがある。そういうものについては、最初からよく考えて正解を選ぶ。 どちらか迷ったら、変えやすいほうを選ぶ。AからBとBからA、どっちが変えやすい? 初期に書くコードはすごく重要。後から参加する人は既存のコードにスタイルを合わせる。 軌道を修正するコストは早ければ早いほど小さい。 仕組みを変えることにはコストが伴う。心理的コストも。 走り出したら何も考えられない。よく考えてから走る。あるいは、走ってない人が考える。 一度動き出した仕組みを変えるときは、移行コストが小さくなるようよく考えた上で、無理やり変え

[todesking]

我ながらいいこと言ってる

[Naruhodius]

ふむふむ〜

[hiromark]

あるある。。。

[wasai]

この手のあとで、ってと言うのは大体直さないですね

[takasumasakazu]

このエントリすばらしすぎるとチームラボ社内で話題になった　さすが @todesking

[fuktommy]

少人数でもそうなるよなあ。全面リニューアルと称するものを3回か4回やって、結局最初の(イマイチな)コードがそのまま残ってたりね…

[teppeis]

多くの問題は漸進的な改善の仕組み（＝アジャイル？）がないことが原因なのかな。

[deg84]

嫌というほど経験している。後から～ってのは大体そのままになりますね。

[totttte]

＞ワークフローの最適化が大事。

[jacoby]

些細なことほど、最初からよく考えて設計することが重要./あとで直そう→直さない/迷ったら、変えやすいほうを選ぶ。

[legnum]

こういうのもっと共有されてくれ