「技術的負債とはどういうものなのか？」をテトリスに例えるとこうなる
テトリスは落ちてくるテトリミノを積み上げ、横一列に並べて消すという有名なゲームですが、そのテトリスを例に「技術的負債」がどういうものかたとえた記事を、エンジニアでありコンサルタントでもあるというエリック・ヒギンズ氏が公開しています。 Technical Debt Is Like Tetris – Featured Stories – Medium https://medium.com/s/story/technical-debt-is-like-tetris-168f64d8b700 「技術的負債」とは、ソフトウェアの開発において、時間がかかるより良いアプローチではなく一番早く新機能の実装などの目的を達成できるアプローチを選んでしまったために生じたソフトウェアの複雑さのこと。例えば既存の機能を変更した際に説明書を書きかえなかった場合、後から別の人が動作を把握するにはソースコードを読む作業が
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
