2023/10/31 @ Barフロントえんどう で発表した「リアーキテクトと開発生産性について」です。
リアーキテクトと開発生産性について
2023/10/31 @ Barフロントえんどう で発表した「リアーキテクトと開発生産性について」です。
技術的負債とステークホルダと説明責任と / The Debt
Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801
レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
技術部の外村（@hokaccha）です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが
「技術的負債」の概念は間違って広がっている？ | スラド デベロッパー
プログラミングにおいては、品質の良く無いコードが負債のように積み上がるさまをイメージさせる「技術的負債」という語句が広く用いられているが、これは実際には発案者の意図を外れて意味が独り歩きしているのではないかという話が上がっている（【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 t-wadaのブログ、Ward Explains Debt Metaphor、Ward氏本人による説明動画）。 この話題は、テスト駆動開発で知られるt-wada氏が、発案者のWard Cunningham氏の発言を翻訳したブログが発端となったようだ。Ward Cunningham氏が「負債」という表現を用いたのは1992年の事であるが、当時氏は金融系ソフトウェアの開発に関わっており、そのため問題を上司と共有するために「負債」という用語を用いたのだという。ただし、氏の発言では「負
技術的負債 - Martin Fowler's Bliki (ja)
ソフトウェアシステムでは、クラフト（出来の悪いもの）が生まれやすい。システムの修正や拡張をしようとしても、内部品質の欠如がそれを難しくしている。「技術的負債」とは、Ward Cunninghamが作ったメタファーである。ファイナンスの負債のように考えることで、こうしたクラフトの扱いのことを考えやすくなる。たとえば、新機能の追加にかかる余分な労力は、負債の返済にかかる利子である。 あらゆるソフトウェアシステムには、タスクを実行するために必要とされる「本質的な」複雑さが一定量含まれている…… ……だが、ほとんどのシステムには「クラフト」が存在しており、理解を難しくしている。 クラフトがあると、変更するのに余分な労力がかかる。 技術的負債のメタファーは、こうしたクラフトを「負債」として扱う。変更に必要な余分な労力は、負債の利子の返済に相当する。 私のコードのモジュール構造が複雑だったとしよう。こ
技術的負債の四象限 - Martin Fowler's Bliki (ja)
http://martinfowler.com/bliki/TechnicalDebtQuadrant.html ここ数ヶ月の間に、 技術的負債 に関する投稿がいくつかあった。設計上の不備の中で、技術的負債と呼ぶべきものは何か？ 逆に、そう呼ぶべきでないものは何か？といった疑問が挙げられていた。 その一例が、アンクル・ボブの投稿「a mess is not a debt（散乱は負債ではない）」だ。 彼の意見は、次のようなものである。 良い設計方法を知らない人が書いた単に汚いだけのコードを負債と呼ぶべきではない。 長期的な持続性はなくても、 リリースなどの短期的な利益を生み出す設計指針をあえて選択することがあるが、 技術的負債はそのような特別な場合に使うべきである。 要するに、負債を抱えれば早めに価値を生み出すことができるが、 負債はできるだけ早く返済する必要がある。 だが私は、 設計の不備
【翻訳】技術的負債という概念の生みの親 Ward Cunningham 自身による説明 - t-wadaのブログ
システム開発の世界において「技術的負債（Technical Debt）」は繰り返し話題になり、しばしば炎上しています。 技術的負債という概念の生みの親は Ward Cunningham （ウォード・カニンガム）です。彼は 1992 年にオブジェクト指向プログラミングの国際カンファレンス OOPSLA '92 の Experience Report でコードの初回リリースを負債に例えました（"Shipping first time code is like going into debt"）。 Ward Cunningham はソフトウェアの世界に多くの貢献を果たしてきました。Wiki の発明者であり、XP と TDD の父 Kent Beck の師匠のような存在であり、建築の世界の「パタン・ランゲージ」を Kent Beck と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
フロントエンドの開発体験向上と脱レガシー - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは。フロントエンドエキスパートチームの@nakajmgです。 私が所属しているフロントエンドエキスパートチームは、プロダクトのフロントエンドを横断的に支援するチームです。今回はフロントエンドエキスパートチームが行っている、プロダクトへの支援活動について紹介します。 フロントエンドエキスパートチームがどういったチームかに関しては、次の記事をご覧ください。 サイボウズのフロントエンドエキスパートチームの紹介 フロントエンドエキスパートチームの活動 サイボウズは主力プロダクトとしてGaroonとkintoneを提供しています。この 2 つのプロダクトはそれぞれ提供開始の時期が 2002 年と 2011 年となっており、浅くない歴史を持っています。 サイボウズの Web フロントエンドは、フロントエンド専任ではないエンジニアがバックエンドと合わせて担当しています。そうした背景もあり、フロン
レガシーソフトウェアをチームで改善するためにまずしたこと | Recruit Tech Blog
はじめに 今年度、新卒で入社した suke です。インターネットではよく omuomugin というアカウントを使っています。現在はゼクシィアプリの内製開発チームでソフトウェアエンジニアとスクラムマスターをしています。 ゼクシィのiOSアプリは2011年から開発されており、レガシーになっている部分も多くありました。本記事では、去年の5月に立ち上がったゼクシィアプリの内製開発チームで取り組んできたレガシーなソフトウェアに向き合うためにやってきたことを書いていきます。レガシーなソフトウェアの定義は様々ですが、レガシーソフトウェア改善ガイドによれば、優れたテストコードがなかったり、ソースコードが変更に対して柔軟でなかったり、いわゆる技術負債が溜まってしまっているソフトウェアのことを指します。 僕らのチームでは、改善の最初のステップとして大きく以下の3つのことをしてきました。 「レガシーソフトウェ
脱レガシーフロントエンドのために知っておいたほうがいいこと
2020/1/19 Kanazawa.js meetup#01
GMOペパボ柴田博志が教える。経営者も理解しておくべき「技術的負債」 - FLEXY（フレキシー）
GMOペパボ株式会社で執行役員 技術部長 兼 VPoE（VP of Engineering）を務める柴田博志（@hsbt）と申します。CTOの栗林健太郎さん（@kentaro）と共にGMOペパボのエンジニアをまとめています。 技術的負債、どこの組織にもありますよね。どうやって返済していますか？ 会社として技術的負債にどう立ち向かうべきか、そのコツは人のマネジメントにあると考えています。今回はflexy読者の皆様と技術的負債を考えていこうと思います。 技術的負債とは： 技術的負債とは、開発の中で先送りにされる、ドキュメンテーション不足、保守コストのかかるテストコードや不必要に複雑なコードなどを指します。技術的負債が蓄積してしまうと、将来的に重大な問題を引き起こしたり、対応コストが雪だるま式に増えてしまいます。すべてのコードに技術的負債が発生する可能性があり、組織はどこかのタイミングで技術的負
技術的負債とどう向き合っているか？ ITベンチャー4社が語る、開発チームのリアルな裏側 Part3
技術的負債とどう向き合う？ 広木：では次のテーマにいきましょう。弊社の技術的負債について。デプロイパイプラインの自慢をさせてくださいってやつですね。どうでしょう？ 横路：マイクロサービスって「最初からマイクロサービスにするな」って言われるでしょ？ うちには育ち切ったモノリスがあります！ 広木：すばらしい！ 横路：ぜんぜん自慢できることじゃないんですけど。サービスが8個くらいあるんですが、最初の会計サービスは丸々と太っていて、もうフォアグラですね。だいたいRailsなんですが、クックパッドのコアの部分も相当じゃないですか。あれの半分くらいはあると思います。 なので、モデルもコントローラーの数もだいたい数千ですね。フロントエンドのコードも数十万から100万行くらいですね。それをこれからしっかりマイクロサービス化していけるのがうちの強みだと思ってます。 マイクロサービスが役立つのはだいたいあれで
Living with legacy systems
デブサミ2019 14-A-6 「レガシーのいい感じの付き合い方」
一休.comホテルページのスマホ版からjQuery依存を取り除くためにやったこと - 一休.com Developers Blog
一休.comでWebフロントエンドを開発している宇都宮です。 先日、一休.comホテルページのスマホ版から、jQueryを取り除きました。jQueryを取り除いた経緯、やったこと、結果について書きます。 ちなみに、ホテルページには以下のURLでアクセスできます（スマホで開くか、PCの場合はUAをスマホに偽装する必要があります） https://www.ikyu.com/sd/00001290/ なぜjQueryを取り除いたのか？ どうやったのか 何をやったのか jQuery.ajax() => fetch に置き換え fetchのpolyfillを採用した理由 DOM操作を標準APIに置き換え 要素の取得 show/hide addClass/removeClass html/text アニメーション $.ready() イベントフィルタリング jQueryの使用を防ぐ目印 jQuery削
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債と向き合う
How we replaced a 10-year-old Perl product using Scala