品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（後編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 本記事は前編と後編に分かれています。いまお読みの記事は後編です。 品質とコストのトレードオフ関係も一概 ここでちょっと視点を変えて、Philip Crosbyさんの「Quality is Free」を見てみたいと思います。 というのも、今日のテーマでは品質と開発ス
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020
品質を犠牲にすることでソフトウェア開発のスピードは上がるのか？ 和田卓人氏による 「質とスピード」（前編）。デブサミ2020 ソフトウェア開発のプロジェクトにおいて、リリースに間に合わせるために開発スピードを優先させ、ひとまず質には目をつぶろう、という判断がしばしば行われることがあります。 はたしてその判断は正しいのでしょうか。2020年2月13日と14日の2日間、都内で行われたイベント「Developers Summit 2020」（デブサミ2020）」の和田卓人氏のセッション「質とスピード」は、これを深く考察したものでした。 この記事では、会場に立ち見がでるほど大人気だった本セッションの内容をダイジェストで紹介します。本記事は前編と後編に分かれています。いまお読みの記事は前編です。
やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか？要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった！ ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ
新卒エンジニア向けに品質の話をした, Asakusa.rb 第368回 - HsbtDiary(2016-07-26)
■ 新卒エンジニア向けに品質の話をした slideshare だと keynote から書き出した日本語が消えてしまうので speakerdeck で。 https://speakerdeck.com/hsbt/yatutemiyou-tqc ペパボでは新卒エンジニアの研修の一環で座学という形で60min何かを講義するという取り組みをここ数年続けているので、自分も品質というキーワードにまつわるあれこれを講義してきた。こういう話、社内では自分くらいしかしないだろうから丁度いいだろうというレベルで若干ふわっとした話をしてきた。 資料だけだと、「ちょっとこれは雑すぎない?」というのがあるとは思うんで、この辺もう少し詳しくということがあったら、是非ディスカッションしましょう → https://pepabo.com/recruit/pepaluncheon/ ■ Asakusa.rb 第368回
バグゼロを実現した話とその後の顛末 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、アプリケーション基盤チームの青木(@a_o_k_i_n_g)です。好きなメソッドは emptyIfNull です。 僕は、自社クラウドである cybozu.com のミドルウェアを開発するチームで働いています。具体的には、検索サービスやファイルサーバー、非同期処理用ワーカー、セッションマネージャーなどなどを提供しています。 僕がこのチームに来たのは数年前ですが、当時はバグの多いプロダクトでした。今はすべての既知のバグを直し、残存不具合件数が 0 件、つまりバグゼロな状態になりました。また、バグゼロを実現してから 2 年ほど経過していますが今もその品質を保っています。今回はこのバグゼロを実現した方法と、その後の顛末について記そうと思います。 以前のコード 数年前に提供されていたこのミドルウェア群は、はっきり言って、バグの塊のようなプロダクトでした。 当時のコードは保守性とは程遠い
ノウハウの共有文化がない場所にコードレビューをねじ込んでみた結果とか - タオルケット体操
「コードレビューをキメると品質も上がるし自分のレベルも上がるので最高」みたいな論が巷を賑わせていて、以前はそういうイケてる制度を指をくわえてみるのみだったのだけれど、最近職場と、それと個人的に関わったプロジェクトでコードレビュー制を無理矢理交渉して導入してみた結果、世間のイケてる書籍やエントリから得られる情報とはまた少し違う知見が得られたので書いてみる。 割と泥臭かったり、あまり希望に溢れてたりはしない感じのエントリなのでそういうのは期待しないほうがいいです。 準備 些末なコードレビューを極力避けるために、コードの規約やスタイルについてはlintとフォーマッターを用意した。 他は無策。 結論 結論から言うと、理想的な運用は出来なかったものの、コードレビューについて世間で言われるような成果（作業を共有する意識、レベルの向上）は得られた。良かった。 ぶっちゃけ僕なんかが浅はかな考えで導入しても
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
