技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
【翻訳】技術的負債という概念の生みの親 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 と共にソフトウェアに輸入した人であり、「アジャイルソフトウェア開
プロダクトマネージャーとエンジニアリングマネージャーで協力して使われなくなったコードを消していった話 - Retty Tech Blog
Rettyの松田です。普段はプロダクトマネージャーとしてSEOに関わっていることが多いですが、今回はエンジニアリング寄りのブログです。 元々Webエンジニアをしていたのである程度はコードを読むことができ、現実的にプロダクトの改善につながるものがあったため、週1時間ぐらいを確保してコードリーディングするのを半年ぐらい続けていました。 一定の区切りがついたのと、実際にいくつか不要なコードを削除することができたので、その取り組みについてまとめてみます。 きっかけ プロダクトの主要なページについて、現状を把握することが難しくなってきていることが課題として存在していました。 主要なページは数多くの施策が行われている分コードの変化も多く、ユーザーさんに価値を提供し続けられなくなってしまったものも取り残されてしまっていました。 他の施策の実行に合わせてリファクタリングできるレベルであればよかったのですが
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
新人プログラマ アンチパターン：原理原則多すぎて脳みそOOMエラー - Qiita
この記事で伝えたいこと（忙しい人向け） 新人ほど「保守していく」ことの感覚が腹落ちしにくいのではないか説 我々は保守しやすいコードを書くべきであり、保守しやすいコードを達成するための手段として原理原則やデザインパターンが存在している 保守ってなんで必要なんだっけ？という体系的な理解を持ったうえで、具体的なテクニックを学んでいくことが大事 // 追記（2023/12/9） なんとミノ駆動 さんにコメントいただけました。 もちろん良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方は読んで影響を受けてます。 とってもうれしい。 想定読者 新卒 ~ ２年目くらいまでのプログラミング初心者 Webアプリの保守開発をしているエンジニア 3ヶ月前くらいの自分（未経験からエンジニアになって１年くらい） こんなことないでしょうか 先輩などから原理原則の観点を共有してもらったり、
僕が考える「良いコード」 - give IT a try
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
モブプログラミング-チーム全体のアプローチ by Woody Zuill - kawaguti’s diary
This is a translated article. You can access the original here: Mob Programming – A Whole Team Approach by Woody Zuill モブプログラミング-チーム全体のアプローチ by Woody Zuill Translated by Yasunobu Kawaguchi, Ikuo Suyama and Ken Matsumoto 1. はじめに モブプログラミングとは、チーム全体が同じものを、同じ時間に、同じ空間で、同じコンピュータで作業するソフトウェア開発のアプローチです。これはペアプログラミング[PAIR]に似ています。ペアプログラミングは、2人の人が同じコンピュータの前に座り、同時に同じコードを共同作業するというものです。モブプログラミングでは、1台のコンピュータを使ってコード
良いコードとは何か - エンジニア新卒研修 スライド公開
株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
GitHub Copilot Chat ベータ版がすべての組織で利用可能に
今年初めにGitHub Copilot Xを発表した際、GitHub上の開発者エクスペリエンス全体にわたり、生成AIとGPT-4のパワーをもたらすことを目的とした、テクニカルプレビューを数多くご紹介しました。本日、GitHub Copilot Xをあらゆる組織に提供するための第一歩として、Visual StudioとVS CodeのすべてのGitHub Copilot for Businessのユーザーを対象するGitHub Copilot Chatの限定パブリックベータ版をリリースしました。 この新たな進歩により、GitHub Copilotはコンテキストを理解した会話アシスタントとしてIDE内で機能するようになり、その結果として開発者は最も複雑なタスクの一部を簡単なプロンプトで実行できるようになります。職歴の長短に関わらず、チームのすべての開発者がアプリケーション全体の開発や膨大なコー
コード品質はやはりビジネスに影響を与える - mtx2s’s blog
私たちソフトウェアエンジニアは、コード品質についてしばしば論ずるけれども、ではコード品質の良し悪しがどれほどビジネスに影響するのかと問われると、回答に窮する。只々、「コード品質が悪いと変更により多くの時間がかかります」だとか、「欠陥の修正に追われて開発時間が奪われます」だとか、個人の経験やエンジニア的一般論に頼った定性的な説明に終始するしかない。ソフトウェアを繰り返し変更する頻度が高いほど、コード品質が開発時間に影響を与えるのは確かにそのとおりだと思えるが、はたしてそれは、どれほどのインパクトなのだろうか。 2022年の研究論文 "Code Red: The Business Impact of Code Quality – A Quantitative Study of 39 Proprietary Production Codebases" では、コード品質がビジネスに与えるインパクト
[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、
![[翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/dfb840670b1246203f99547145b4b7b27db28e26/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Fadvent-calendar-ogp-background-7940cd1c8db80a7ec40711d90f43539e.jpg%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwU2hvcGlmeSVFMyU4MSVBQiVFMyU4MSU4QSVFMyU4MSU5MSVFMyU4MiU4QiVFMyU4MyVBMiVFMyU4MiVCOCVFMyU4MyVBNSVFMyU4MyVBOSVFMyU4MyVBMiVFMyU4MyU4RSVFMyU4MyVBQSVFMyU4MiVCOSVFMyU4MSVCOCVFMyU4MSVBRSVFNyVBNyVCQiVFOCVBMSU4QyZ0eHQtY29sb3I9JTIzM0EzQzNDJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9NDUxODQ2MjU3YTEzNDMwMjQ4MDU3ODNmYzM3MjM3NGI%26mark-x%3D142%26mark-y%3D100%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9OTcyJnR4dD0lNDB0a3lvd2EmdHh0LWNvbG9yPSUyMzNBM0MzQyZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPWZiZDJlOGIzYmQzMjk3ZDIxOTA4MjFhZDlkMGI0NTE2%26blend-x%3D142%26blend-y%3D455%26blend-mode%3Dnormal%26txt64%3DaW4g6aOf44G544Ot44Kw%26txt-width%3D972%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%25233A3C3C%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D550%26s%3Dfb3a6bbe6d17db94858fcbdae8bc1b62)
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
プロダクトと向き合いながら 目の前のコードと戦うには / Fight the code in front of you
コドモン社でのセミナー内容です
リーダブルテストコード / #vstat
「リーダブルなテストコードについて考えよう ～VeriServe Test Automation Talk No.3～」で使用したスライドです。 https://veriserve-event.connpass.com/event/243280/ 登壇動画はこちらで公開されています。 http…
そのコードレビュー、使い捨てになっていませんか？
こんにちは。株式会社プラハCEOの松原です。 どんな人にこの記事を読んで欲しいか コードレビューの効率化に悩んでいる コードレビューのやり方に自信が持てず、何か参考になる事例を知りたい 使い捨てコードレビューに翻弄される日々 1~2年ほど前に自社サービスを開発していた頃、弊社では全てのプルリクエスト（以降PR）に対してランダムに割り当てられたレビュワー2名、もしくはテックリード1名にapproveされない限りマージしない運用で開発していました。開発者が5名ぐらいだったと記憶しているので、規模の割にはリッチなレビュー体制だったのではないでしょうか。 修正点があれば指摘して、直して、再確認して、merge。 来る日も来る日も、確認、指摘、修正、再確認、merge。 次第に「僕ら業務時間の大半をコードレビューに使ってね？」と、レビューに費やす時間が気になるようになってきたあたりで、一度自分たちの
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
リーダブルコード by DDD / Readable Code by DDD
リーダブルコード by DDD モデリングを起点に可読性の高いコードを実現する
天才プログラマー・オードリーさんがたった200行で効果的なアプリを作れる秘訣
天才プログラマー・オードリーさんがたった200行で効果的なアプリを作れる秘訣 オードリー・タン台湾デジタル大臣との対話 - 未曾有の危機に幅広く使える未来思考（後編） 2021年1月19日、『コロナ vs. AI 最新テクノロジーで感染症に挑む』（翔泳社刊）が発売されました。医師の起業家からAIの研究者・ITの先端技術コンサルタントによって執筆されており、コロナ対抗策としてのAIの社会実装事例・AI研究事例・医療研究事例をわかりやすくまとめられています。今回本書の発売を記念して、収録されている台湾のデジタル大臣、オードリー・タンさんへの特別インタビューから、一部内容をご紹介します。株式会社キアラ 代表取締役の石井 大輔氏による寄稿です。（前編はこちら）。 石井：今回の私の質問は少し技術的なことです。オードリーさんは天才プログラマーとして有名です。GitLab Taiwanのエンジニア友人か
The Twelve-Factor App （日本語訳）
はじめに 現代では、ソフトウェアは一般にサービスとして提供され、Webアプリケーション や Software as a Service と呼ばれる。Twelve-Factor Appは、次のようなSoftware as a Serviceを作り上げるための方法論である。 セットアップ自動化のために 宣言的な フォーマットを使い、プロジェクトに新しく加わった開発者が要する時間とコストを最小化する。 下層のOSへの 依存関係を明確化 し、実行環境間での 移植性を最大化 する。 モダンな クラウドプラットフォーム 上への デプロイ に適しており、サーバー管理やシステム管理を不要なものにする。 開発環境と本番環境の 差異を最小限 にし、アジリティを最大化する 継続的デプロイ を可能にする。 ツール、アーキテクチャ、開発プラクティスを大幅に変更することなく スケールアップ できる。 Twelve-F
良いコードを書くための8つの習慣
成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
