技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
サービス間通信のための新技術「gRPC」入門 | さくらのナレッジ
たとえば次のような「user.proto」というプロトコル定義ファイルを用意し、これを変換する例を見てみよう。 syntax = "proto3"; message Picture { uint32 id = 1; uint32 width = 2; uint32 height = 3; enum PictureType { PNG = 0; JPEG = 1; GIF = 2; } PictureType type = 4; } message User { uint32 id = 1; string nickname = 2; string mail_address = 3; enum UserType { NORMAL = 0; ADMINISTRATOR = 1; GUEST = 2; DISABLED = 3; } UserType user_type = 4; repeated
「技術的負債」とは何か。原典とその対応策を探る
負債とは要するに借金のことですが、システム開発においても技術的な借金、つまり「技術的負債」（Technical debt）がある、という表現がしばしば使われます。お金の借金をすると利子を払い続けなければならないのと同じように、技術的負債を抱えると、そのツケを払い続けなければならなくなる、という比喩です。 「技術的負債」という表現は、WikiWikiの発明者で著名なプログラマとして知られるウォード・カニンガム氏が1992年に使ったのが原典とされています。しばしば目にするこの「技術的負債」というのはどういうものなのでしょうか？ 調べてみました。 カニンガム氏とファウラー氏による「技術的負債」 カニンガム氏が「技術的負債」という表現をはじめて使ったのは、1992年に行われたACM主催のイベント「OOPSLA '92 」(Object-Oriented Programming, Systems,
技術的負債 - Wikipedia
技術的負債（英語: technical debt）、設計負債[1]、またはコード負債とは、ソフトウェア開発における概念であり、時間はかかるがより良いアプローチを選択する代わりに、簡単ではあるが限定的な解決策を選択することで生じる、将来的な手直しにかかる暗黙のコストを示すものである[2]。 金銭的な負債と同様[3]に、技術的負債も返済されなければ、「利子」が蓄積され、変更の実施が困難になる。技術的負債を処理しないと、ソフトウェアのエントロピーが増大する。金銭的負債と同様に、技術的負債も必ずしも悪いものではなく、プロジェクトを前進させるために（概念実証として）必要な場合もある。一方で、「技術的負債」というメタファーは、その影響を最小限に抑える傾向があり、その結果、修正するために必要な作業の優先順位付けが不十分になると主張する専門家もいる[4][5]。 コードベース上で変更が開始されると、コード
だから、「COBOL」の問題じゃないってば | おごちゃんの雑文
日経コンピュータの馬鹿がまた俺に喧嘩を売る気らしい。 [3]COBOL資産を守って、若者の可能性をつぶす愚 この手の話は既に何度も言ってるので、繰り返しにしかならないのだが、別に「COBOL」が悪いわけじゃない。 それはCOBOLのせいじゃない COBOLは「負の遺産」なんかじゃない 言いたいことはこれらのエントリで言い尽しているのだが、問題は「COBOL」という言語にはない。ある程度歴史を持ってしまった汎用言語は全て同じ危険を持っている。 件のエントリでは「COBOL資産」はあたかも「負債」であるかのようなことを言われているのだが、それ自体は特に負債ではない。そもそも私は、 技術的負債 とかって言葉は嫌いだ。技術者の血と汗の塊を「負債」呼ばわりするなぞ、失礼の極みだ。 件のエントリで問題視するべきなのは、そこじゃない。てか、実のところ件のエントリはそこに触れているのに、力が足りない。 「
技術系メーリングリストで質問するときのパターン・ランゲージ
目次 はじめに メーリングリスト —— サポートセンターではなく互助会です 表題 —— あいさつではなく用件を書きましょう 自己紹介 —— 自分の知識・技能・経験を簡潔に書きましょう 書き出し —— 最初に問題の要旨を書きましょう 肩書き —— 会社の名前を背負っていることを忘れないように 実行手順 —— 手順は箇条書きで書きましょう 結果の予想 —— 期待した結果を書きましょう 実際の結果 —— 実際に起きたことを書きましょう ステップ明記 —— どこからうまく行かなくなったかを書きましょう 実際の値 —— 条件を具体的に書きましょう エラーメッセージ —— 必ずコピー＆ペーストしましょう 判断理由 —— そのように考えた理由を書きましょう 文献の引用 —— 読者の手間を省くように書きましょう ソース —— 関連する部分を抽出して示しましょう スレッド —— 関連する話題なら「返信」しま
卜部昌平のあまりreblogしないtumblr
どうも。グリーのアカウントは持ってる1けどモバゲーのアカウントは持ってない卜部です。 ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。 だからまあ、こう言ってしまうと身も蓋もないかも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
