ロンジェフリーズのいう「YAGNIと技術的負債と手抜きの違い」をチャートにしてみました。 https://t.co/ker1E2fN5G
kawasima on Twitter: "ロンジェフリーズのいう「YAGNIと技術的負債と手抜きの違い」をチャートにしてみました。 https://t.co/ker1E2fN5G"
ロンジェフリーズのいう「YAGNIと技術的負債と手抜きの違い」をチャートにしてみました。 https://t.co/ker1E2fN5G
開発スピードと技術的負債 - oinume journal
よくある「開発スピードを優先させるか技術的負債をなるべく発生させないようにするか」という議論、ケースバイケースだとは思うけど、ことプロダクトの立ち上げ段階では、悩んだら「開発スピード」を優先させるようにするべきだと自分は思ってる。 理由は 市場は待ってくれないから。どんなにいいプロダクトでもユーザーに使われなくては意味がないのと、プロダクトを取り巻く外部の環境(競合プロダクトや市場でのニーズ)は自分ではコントロールできないものなのに対して、技術的負債については適切に管理されていればコントロールしながら返済できるから。もちろんバランスも重要だとは思うので、どんな技術的負債も生み出していいかと言われるとそうではないけど。 というわけで自分は「ああこれクソコードだけど機能は満たしてるからそのままリリースしたいなぁ」というのはだいたいクソコードのままリリースしています。(こうやって免罪符を作ってい
人のコードを引き継ぐときに一番困るのは「使われていないコード」 | mah365
プログラミングを生業としていると、人のコードを引き継いで開発するなんてこともままある訳ですが、そういうときに一番困るのは「使われていないコード」だなー、としみじみ感じます。 使われていないコードがもたらす弊害 特に動的言語で書かれたコードというのは前触れ無く呼び出される可能性があるため、本当に利用されていないのかどうなのか、きっちりと調べあげるのは困難なケースがあります。例えばrubyであれば、method_missingでキャッチしてsendで動的に処理先を振り分けるなんてことをしていると、単純にgrepして利用状況を見るだけでは不十分な場合があります。 そういう意味では「使われていないコード」というよりは、「使われているのか使われていないのかはっきり分からないコード」という方が適切な表現かも知れません。 そういった「はっきりと判断のつかないコード」がある状態だと何が問題なのかと言うと、
「技術的負債」をコントロールする定量評価手法への期待
「「技術的負債」を問いなおす」というタイトルでJAWS DAYS 2014で話してきた #jawsdays - delirious thoughtsにて、追記でコメントいただけたので、外野として好き放題言わせてください。すばらしいスライドありがとうございます＆いつもすみません。 僕が興味がもつとすると、それは「技術的負債」の定量評価手法についてです。 なぜ、そういう前提を置くかと言うと、それは、たとえばKrutchenによる「技術的負債」の定性評価は、とてもわかりやすいものの、技術を取捨選択するツールとしては使えないからです。 スライドでは、技術評価における将来の不確定性を象徴する問題としてSSDの普及前夜にシャーディングをがんばって実装してしまう例をご紹介いただきましたが、実際、そのような不確実性を織り込んだ正しい決定を我々が日々のエンジニアリングで下すことができているのか疑問に感じるこ
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
技術的負債という(非エンジニアにとっての)隠しパラメータが生産性100倍を起こす - mizchi's blog
元糞コードマイスターとしては、生産性については思うところある。 技術的到達深度が深い人じゃないとそもそもかけないコードってのももちろん存在して、その前提で10倍とか100倍になりうる話をする。 そもそもマイナスになる人がいるって話。 隠しパラメータをモデル化 エンジニアA:「週に10の成果を出して3の負債を生む人」を考える。この人は開発を止めてリファクタリングをすれば10-3 = 7の技術的負債を返却できるとする。 ここで正確には成果10には* aの係数が掛かっている。これはプロジェクト開始時1.0で、技術的負債が貯まるほど0に近づいて行く 次に、エンジニアB:「週に15の成果を出して10の負債を生む人」を考える(これにも係数aがかかる)。この人は見た目上は上の人の1.5倍速く成果を出しているように観測できるが、負債もたまりやすい。リファクタしても綺麗になりにくい。 これは割とエンジニアに
プログラマではありませんが、プログラマの話をさせてください - mixi engineer blog
はじめまして。8キロのダイエットに成功しましたが、最近リバウンド気味の土戸と申します。 私は今、弊社イノベーション・センター案件である、Plannah(プランナー)のプロダクトマネージメントとマーケティングに携わっております。 先日我がチームの開発メンバーである衣川から、簡単にPlannahの紹介がありました。多くの方々に記事を読んで頂き、そしてPlannahに関心を持って頂き、大変感謝しております。本日は、Plannahの話は割愛させて頂き、ちょっとしたプログラマ話(?)をしたいと思います。 私はプログラミングを職業としているいわゆる"プログラマ"ではありません。ミクシィに新卒入社した2009年からしばらくは営業マンでしたし、その後も今に至るまでサービスディレクターとして勤めてきました。少しさかのぼって、小学校の頃は当時流行っていたGW-BASICでmud gameなどを作ってみたり、大
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
技術的負債を管理する
1992年にWard Cunningham氏が、技術系ではないステークホルダにこの問題を伝えるために、初めて「技術的負債」というメタファを使いました。品質の低いコードと自動テストによるカバレッジがないことは、財務的負債と比較されます。このようなコードは、開発者だけでなく、すべてのステークホルダが負う財政的な重荷になり、将来的に利息が課される負債になります。元本額は、コードベースを将来簡単に変更できるようにリファクタリングするコストです。利息は、チームがよいコードではなく、汚いコードに取り組まなければならない場合に、将来支払う余分なコストです。 財務的負債とは違い、技術的負債は返済しなくてもよい負債です。時には、返済するのが無駄なこともあります。ある部分のコードを読んだり、変更したりすることはめったにないか、決して起こらないかもしれません。そのため、技術的負債も、どのくらい起きそうかを考慮す
悪いAPIは伝染していく（2）: 柴田 芳樹 (Yoshiki Shibata)
以前、「悪いAPIは伝染していく」という短い記事を書きました。 APIが悪いライブラリを使用する別のライブラリを設計する場合には、元のライブラリのAPIの悪さを、新たなライブラリでは修正することが可能です。しかし、よく見かけるのは、使用する元のライブラリのAPIの悪さをそのまま引きずったライブラリが設計されることです。その意味で、低レベルのライブラリのAPIの悪さは、上位レベルへと伝染していきます。悪さが伝染しないように新たにAPIを設計できるエンジニアは少ないようです。 きちんとしたAPIを持つライブラリを使用しているのにもかかわらず、出来の悪いAPIを持つ上位のライブラリが作成されることがあります。私自身がかなりレビューしてAPIを整備させたライブラリを使用して、その上に出来の悪いAPIを持つライブラリが設計されているのを見ると、がっかりしてしまいます。 どんなAPIでも、最初のバージ
「工業製品」としてのソフトウェア - 勘と経験と読経
ソフトウェアの品質というと国際基準や規約というものがまずあるのだけれども、そういった観点とは別に「工業製品としての品質」という考え方もあるのではないかと思っている。美しいコードは品質が高いと言われているけれども、それは「芸術品」を目指したものではないか。われわれが作っているものは「芸術品」なのか「工業製品」なのかということを考えるべきではないだろうか。 そのソフトウェアに「品質過剰」は無いか？ 知り合いのプロジェクトで「複数のシステムが使う共通検索機能」があって、スケジュールの関係もありバラバラに(共通化せず)構築してしまった話を最近聞いた。そのプロジェクトでは開発フェーズの終盤で顧客からクレームがあり、該当の機能は苦労して再度共通機能として作りなおしたそうだ。比較的よく聞くたぐいの話だけれども、いくつかの点で少しひっかかった。 内部実装がバラバラだったとしても、外見上の機能性がまったく一
どうやってソフトウェアのまずさを数値化するかを調べてみる
開発エンジニアのsugimotoです。 弊社サービスのMARKETING PLATFORMの開発を担当してます。 近頃はソースコードのまずさによりメンテナンスコストの増加やメンテナンスによる新たなバグの発生で悩むことが多かったので、今回はこのまずさをどう数値化したものかを調べてブログに書いてみます。 ○技術的負債 ソースコードのまずさを負債と捉えて数値化できるのではと考え技術的負債について調べてみました。技術的負債のちゃんとした内容はWikipediaとかInfoQとかの記事を見てもらうのが良いので、ここでは理解した内容を簡単にまとめてみます。 ・負債 まず負債って何？ということなんですが、お金と同様に借金です。ソフトウェアの場合、借金に当たるのが良い設計(あるべき姿)に対してどれだけ妥協した設計で作ったかを表します。式で表すと 負債 ＝ 良い設計で作ったもののコスト － 妥協した設計で作
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
