設計品質vs開発速度

松岡@ログラス/DDD,アジャイル @little_hand_s

質問箱にエモい投稿があったので皆さんの回答を募集してみたいと思います。この投稿にリプライしてもらえたらリツイートしますので、皆さんのご意見をぜひ！ pic.twitter.com/Pme505cgQD

拡大

さかはら @_k812_

@little_hand_s 採用いただきありがとうございます。 また，皆様も多くの回答頂きありがとうございます。 １つ１つ読ませていただきますm(_ _)m

hiro@miraito @hirodragon112

テストコードを書く事はスピードとトレードオフになっている訳ではない。 テストコードが無いってのは、レジで一度掴んだお釣りを確認せずに返しているようなもの。 スピード優先しているのではなく、最低限の品質すら落としているだけ。 それをスピード優先したトレードオフとは言わない。

luccafort @luccafort

この質問主の期待する解答にはならないけど要はバランスおじさん的なもの以外ないんじゃないかな？ 結局チームとしてプロダクトとしてどこを諦める、諦めないを決めるだけの話だと思う。 あとから変えにくいところはコストかけたほうがいいし、それが難しいならそれを込みで設計するしかないと思った。 twitter.com/little_hand_s/…

赤谷 @akamai86117477

同感。自分は1度目はアプリケーションレベルのテストは書いてリファクタできる状態にはするけど凝ったことはしない。2度目以降の変更を加える時に必要な分だけ頑張るように意識はしてる。(1度目で必要以上にやりすぎちゃうことが多い) twitter.com/little_hand_s/…

タピオカ龍太郎:wq @mixmarukun

@little_hand_s 速度を優先する等で設計を崩す時、どれくらい理想から崩れるのかを認識する事が大事だと思います。将来返済できる範囲で崩すならそれなりに、もう返済は考えないなら思いっきり崩す等。そういった「崩す程度」のバランスコントロールのために設計をキッチリ理解している事が重要になるのだと思ってます

hori @hori_ryota

コストがかかるのは良い設計や良いテストではなくそれらを試行錯誤して模索するところで、そこを妥当にバランスが取れるようにするためにみんな日々修練していると思っている （良い設計や良いテスト自体はむしろコストを下げるものだし、良い設計は必要なテストも減らすと思っている） twitter.com/little_hand_s/…

切腹コロ助 @6J1jgLOJXSWe35i

この手の話語られるときって自社サ/自社プロダクト前提の文脈で語られることが多い気がするけど、PKGのユーザ向けカスタマイズで考えるとどうかっていうのも是非誰か語って欲しいでござるなァ twitter.com/little_hand_s/…

会川 / ｴﾋﾞﾃﾞﾝｽ･ｽｸｼｮ･ｴﾝｼﾞﾆｱ @nameless_gyoza

元の質問で「品質 vs 速度」となっているのが非常に興味深いですね...。 twitter.com/little_hand_s/…

T.A.C. @TAC_yacht

基本的には会社も幸せにする。品質を落としたところでそれほど得られる速度は無いのが経験則でも以下の参照先でも語られているとおり speakerdeck.com/twada/quality-… twitter.com/little_hand_s/…

コンマナ @0to999

時として技術的負債を出さないことに固執して遅延してる案件はよくありますね ですが、それは失敗ができない業種が多いから仕方ない部分もあるかと(金融・証券とか) 逆にたいした被害が出なさそうな自社サとかなら雑に出してフィードバックもらうとかが機会損失しないために大事なことだったりもして twitter.com/little_hand_s/…

まつやん @lv3_makumattun

@little_hand_s 変更を先延ばしにできる設計であれば〇〇アーキテクチャに完全に準じると言った観点での品質ならいらないと思います。 ex)ここからはviewの要件なので、そう言った変更はこの箇所に押し込めるなど、モデリングの観点なら依存の関係、has a, has many, is aなどは適切に表現するなどは必ずやるなど

松下正嗣 @masatsugumatsus

この話、３つあると思ってて、 ①レイヤーの整理みたいな事前の設計 ②重複排除みたいな最低限の設計 ③深いモデルのような深いドメイン理解に基づく設計 ①、②は標準スキル依存で、トレードオフの要素は少ない。むしろ速度を上げる。③はエキスパートの存在や検討時間、リリースタイミングでバランス twitter.com/little_hand_s/…

jx.matsushita @jxmtst

@little_hand_s speakerdeck.com/twada/quality-… 品質とスピードはトレードオフの関係にある、は誤解（短期的には得られる）

shuheisakai @darshuheider

この方の言っている技術的負債が保守性の低くなったコードや古くなってしまった技術基盤のことを指しているのであれば、いっぺんに返済していくみたいなことは対象をしっかり選ぶべきかなぁとは思いますが、元々の負債の意味的には、限られたスケジュールの中でできるところまでやって twitter.com/little_hand_s/…

いつも真面目なおっぱいエンジニア @jnakanaka1

良い設計・良いテストが会社を良くするのではなく、会社を良くする設計・テストが、良い設計・テストなのです。 作るものの性質を考えて、設計・テスト方針を考えましょう。やり方は一つではありません。 twitter.com/little_hand_s/…

成る程くん@IT @tec_man0123

目先の1プロダクトしか見てないなって言う質問だなぁ、テストも含めて品質の良いコードを書いた経験値は次のプロダクトで活かせるでしょ 業務委託とか派遣ばっかでやってる会社じゃなければだけど twitter.com/little_hand_s/…

ハンマー猫 @AHammerCat

この手の「コストかかるからやらない」論は10年以上前のアジャイル界隈でも親の顔よりよく見た話。 そういう時確認してたのは次の2点。 ・その「コスト」の内訳って何ですか ・「やった時にかかるコスト」と「やらなかった時にかかるコスト」ってどっちがデカいですかね だいたいウザがられたw twitter.com/little_hand_s/…

脱脂綿/だっしー/Tomoya Suzuki @anchor_cable

@little_hand_s 質とスピードがトレードオフではない前提で、違う事を書きたい。本来の意味で「良い設計」には、質問者さんの言う過剰な設計を避ける意味が入っている。「Design It!」の3章に、設計にどれくらいの時間を掛けるべきかの議論があります。少なすぎても多すぎてもいけないのが設計の妙だと思っています。

いたしか@エンジニア @itashika_gu

それが中期的に開発効率に寄与する品質にフォーカスして高めることを考えてます。 具体的には自動テストやタスク分解しやすいアーキテクチャを用意するなどです。 長期的展望を考えればDDDやマイクロサービスを積極的に導入するんですが、ここら辺は事業が求めるスピード感と相談です。 twitter.com/little_hand_s/…

linyclar @linyclar

@little_hand_s エッセンシャルスクラムに技術的負債に関する章があるので、そちらを読まれると良いと思います。 極端な例で「競合を出し抜くために一瞬でも早く市場に投入しろ。競合が真似してくるまでの3ヶ月間動けばいいんだ。競合が参入してきたら、手を引いて次の商品を開発するだけだ」って話がでてきます。

fuuki @fuukidev

@little_hand_s > 技術的負債を作らないことは大事 の前提が違う気がする。 価値を出すためにあえて負債を借り入れる選択肢は、そもそも有りな話だった気がする

Yoshizu / S2 Factory @n0442

@little_hand_s 課題によっては同じゴールに辿りつく場合でも設計に時間をかけるよりまず動くものを作ってからテストコードを担保にリファクタリングしていく方が効果的なケースもあるという実感はあります。

すぎちゃん @koheisg

スタートアップで長くフルスタックにエンジニアリングに関わってるので、この問いが僕の食い扶持でもある。 設計やコードではなく課題のリファクタリングをすれば設計もコードも素直になる。 というのが私の結論。 twitter.com/little_hand_s/…

Yoshizu / S2 Factory @n0442

@little_hand_s このアプローチの場合は最後までリファクタリングしきることが品質に直結しますので、途中で手を止めてしまえばスピードと品質はトレードオフの構造になり、品質低下を招きやすい側面があります。よって最初から設計に時間をかけたりテストを書きやすくしておく方が効率的ですね。