多くの人が、1回で最高の命名をしようとする。これは難しく、うまく行くことなんて滅多にない。問題はネーミングというのは設計であるということだ。あらゆるものに収まりの良い場所を与え、正しい抽象化をしなくてはならない。これを最初の1回で完璧にこなせる可能性は低い。だから進化的ネーミングについて話をしよう。
命名のプロセス - kawasima
多くの人が、1回で最高の命名をしようとする。これは難しく、うまく行くことなんて滅多にない。問題はネーミングというのは設計であるということだ。あらゆるものに収まりの良い場所を与え、正しい抽象化をしなくてはならない。これを最初の1回で完璧にこなせる可能性は低い。だから進化的ネーミングについて話をしよう。
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
- 不吉な匂い
不吉な匂いとは、リファクタリングを必要とするコードから感じられる雰囲気を、比喩で表したものです。 ここでは、感じ取った不吉な匂いに対して、どのような解決法を選ぶことができるかを取り上げます。 匂いとして示されているのは、次の２２のケースです。ひとつずつ見ていきましょう。 また、解決法に添えられている数字は、参考書籍「リファクタリング」の何ページに記されているかを示しています。
マーチン・ファウラー氏「リファクタリング 2nd Edition」で20年ぶり内容刷新、サンプルコードはJavaScriptに。Web主体で書籍はエッセンシャル版の位置づけ
マーチン・ファウラー氏「リファクタリング 2nd Edition」で20年ぶり内容刷新、サンプルコードはJavaScriptに。Web主体で書籍はエッセンシャル版の位置づけ マーチン・ファウラー氏が20年ぶりに大幅に内容を刷新した書籍「リファクタリング 2nd Edition」を今年秋に出版する計画だ。サンプルコードはJavaからJavaScriptに変わる。また、コンテンツ本体はWebサイトとなり、書籍はそのエッセンシャル版の位置づけとなる。 「リファクタリング」とは、ソフトウェアの機能追加や変更、性能向上などに備えるため、開発されたコードの外部に対する振る舞いは変更せず、より整理された、あるいは洗練されたコードに書き換えること、あるいはその手法のことを指します。 いまでは開発者の間で広く知られているこのリファクタリングについて、その目的や手法などを書籍としてまとめあげ、出版したことで啓
技術的負債のパターンと悪影響・原因・返却方法について考える - $shibayu36->blog;
先日飲み会で技術的負債についての雑談をしていた。結構いろいろな側面の話をしていたのだけど、技術的負債って一括りにしているのが今はあんまり良くなくて、負債の性質によって技術的奨学金、技術的FX、技術的年金などと言葉を変えると良いのではみたいな半分冗談で会話をしていた。 いろんな問題が技術的負債という一言にまとめられてしまっているので、負債の性質に合わせて、技術的奨学金、技術的FX、技術的年金、など用語を分けると良いのではないか、という話をした— 趣味はマリンスポーツです (@hitode909) 2018年3月27日 技術的負債について - hitode909の日記 それで技術的負債のパターンを見つけて、それによりどういう悪影響があるか、それがなぜ起こるのか、どう返却するかについて考えておくと良いのではと思ったので、今日思いついた3つのパターンをメモしておく。 思いついたパターンは3つ。 変
フロントエンドの負債と向き合う - mizchi's blog
某所で書いたものを公開用に書き直したもの 前提 フロントエンドでTDDは難しい、というかほぼ不可能である。なぜなら事前に副作用をデータとして表現できるか不明だからだ。たとえばあなたのプロダクトの画面の何処かにボタンを追加するために、その内部表現を事前に思い浮かべることが可能だろうか？ react-redux などのFluxフレームワークは如何に副作用をアクションとして表現することで、テスト・デバッグのための情報を残すか、という視点で発展してきた側面がある。あの冗長なアクション定義は、全てデバッグのために書いていると言っても、過言ではない。それすら「Textは文字がある」といったトートロジーなデータになりがち。 フロントエンドの現実的な単体テストは、他の開発者のために、自分が書いたコードの要求を満たしているか検知する手段として、防衛的にテストアフターしておく。これぐらいしか現実的な手法がない
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか
1000万行のコードと向き合う3つのステップ――富士ゼロックスはリファクタリングにどう取り組んでいるのか（1/2 ページ） 大企業では実施が難しいと思われるソフトウエアのリファクタリング。富士ゼロックスでは、どのように取り組んでいるのか。リファクタリングの実施を決断した理由、課題とその対応方針、成果、今後の展望などについて聞いた。 バグの有無ではなく保守性を品質管理の指標にすべき 1962年設立の富士ゼロックスは、主に複合機やオフィスプリンターなどに内蔵されるコントローラーソフトウエアの開発を行っている。コントローラーソフトウエアは、スキャナーで撮り込んだ画像の加工や印刷、ネットワーク経由の通信、セキュリティなどの各種機能を、操作パネルのユーザーインターフェースを介して制御しており、昨今の多機能なオフィス機器の要といえる。 一方で、多機能になったことでコードは大規模かつ複雑化の一途をたどっ
else句を使わないのが良いコードなの？いや、そんなはずは・・・ · DQNEO日記
if (条件) { return 20; } else { return 30; } ↓ if (条件) return 20; return 30; こうすれば確かにネストは浅くなりますが、いつも毎回こう書く方がよいのでしょうか？ elseを書いた方がよいケースもあるのではないか 条件の部分が特殊・例外的な場合は、確かにこの方がわかりやすいと思います。 例えば、スーパーマリオで、マリオの状態が「無敵・チビ・大きい」の３種類しかないとします。 敵に触れたときの挙動を関数として書きます。 (オブジェクト指向っぽくないかもしれませんが、本記事の主眼はif-elseの書き方です。) function () { if (マリオ.is無敵モード) { 敵.死ぬ(); return ; } //以下、通常モードの場合のコードを書く } 無敵モードは特殊な状態だから、これはよいと思います。 しかし、マリオ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubエンジニアによる「リファクタリングにおける冒険とは」の翻訳 - Qiita