DEV Community Follow A space to discuss and keep up software development and manage your software career Future Follow News and discussion of science and technology such as AI, VR, cryptocurrency, quantum computing, and more.
0 0 719 0 この 4 年間、Dropbox では、デスクトップ クライアントの同期エンジンを白紙の状態から再構築しようと懸命に取り組んできました。同期エンジンは、デスクトップ パソコン上の Dropbox フォルダの陰に隠れた魔法です。これは、Dropbox で最も長く使われているコード部分であり、最も重要なコード部分の 1 つでもあります。今回、新しい同期エンジン（コードネーム「Nucleus」）をすべての Dropbox ユーザー向けにリリースさせていただくことを、ここに発表いたします。 同期エンジンの書き換えは本当に大変な作業で、多くの環境でマイナスともなりうる構想であったことに鑑みると、手放しで祝う気持ちにはなれません。結果的には Dropbox にとって素晴らしいアイデアであったわけですが、それは、私たちがこのプロセスにどのように取り組むべきかを熟考したからこそ、たどり着
It was a late evening. My colleague has just checked in the code that they’ve been writing all week. We were working on a graphics editor canvas, and they implemented the ability to resize shapes like rectangles and ovals by dragging small handles at their edges. The code worked. But it was repetitive. Each shape (such as a rectangle or an oval) had a different set of handles, and dragging each ha
アプリケーションを実装していくと、「大規模なUI改修」に遭遇することがある。 あちこちで見聞きした結果、以下のようなパターンがあるように感じたのでまとめてみた。 （UI改修なので基本的にフロントエンドからみた内容） これは一般的に「技術的負債」と呼ばれることが多いが、デザインの負債（UIを置く場所が無くなったり無くなったり、同じ概念のUIが分散したり）である場合も多い。 （ちなみに、デザインの負債は「ダイアログを多用する」とか、「最小画面サイズが大きくなる」とかの形で現れやすい） そして、デザイン負債に対応するために実装の困難なUIが増えるため、技術的負債も高くなる傾向がある。 （サーバサイドの技術的負債がDBの負債に起因する場合が多いことと似ているかもしれない）
数年前のプロジェクトで100行未満のファイルをプロジェクト全体の95%にする。 という趣意でメンテしやすさを確保しようとした。 (テストやコードジェネレートしたものは除いて計測するような指標) speakerdeck.com これはわりと簡便で良い指標だと個人的に感じている. どんなプログラミング言語やアーキテクチャでもすぐに適用でき、ある程度プロジェクトの健康状態がそこからわかるからだ。 この話をすると、クラス感の依存関係をみたり、コミットログでの編集頻度などより複雑な解析しようと試みる人がいる. それはそれでとても良いのだけど、個人的にはこの指標の柔軟さ、簡便さ、費用対効果の高さが気に入っている. ファイル行数の分布グラフがばらついているプロジェクトは、だいたい何か設計や機能が失敗している. 昔どこかの勉強会で、行数が多いほどエンバグする可能性が高まるという当たり前の事実を聞いた。 実
Martin is the host of martinfowler.com, the author of Refactoring, and the Chief Scientist at Thoughtworks. For the past two years, I've been working on a second edition of my book “Refactoring”. Here I have details about the new edition and some memos describing my thoughts in the last months of this project. The book is now available and you can buy it from informit (the web presence of the publ
オープンセミナー2017@岡山
※いずれも『レガシーソフトウェア改善ガイド』より抜粋（記事掲載に合わせ一部改変）。 この本について 本書のスコープは欲張りなもので、放置されたレガシーコードベースを、あなたの組織に価値をもたらす保守が可能で十全に機能するソフトウェアへと変身させるのに必要なことを、すべて伝授しようというのです。もちろん、1冊の本で、すべてを完全に網羅しようとする試みは、達成できるわけがないのですが、私はレガシーソフトウェアの問題点に対して、さまざまな角度からアプローチすることで、それに挑んでいます。 コードがレガシーに（というのは、大ざっぱに言って、保守が困難に）なるには、多くの理由がありますが、ほとんどの原因は、技術ではなく人間に関係しています。もし人々のコミュニケーションが十分でなければ、人が組織を離れるとき、コードについての情報が失われます。同様に、開発者、管理者、そして組織全体が、仕事の優先順位を正
みなさんもきっとそうだと確信いたしておりますが、プログラマというのは、どういうわけか実装のちょろまかしには頭がまわるもので、今や丁寧なコードを書く人の鏡とまで言われるワタクシも、それはそれは手抜き方法ばかりうかんだものでした。 技術的投資のいくつかは、不本意ながら技術的負債になりまして、いろいろと世間様にもご迷惑をおかけした次第です。みなさんもきっとそうだと思いますが。 この話は、そんな「誰にでもある」小さな事件のひとつです。1 この記事は CrowdWorks Advent Calendar 21 日目の記事です。 昨日は @tmknom さんの 「アプリケーションアーキテクチャに関するポエム」 でした。 設計に関するトピックは幅広く、かなり広範な知識が求められますよね！早く DDD を読まねばという気分になりました（笑）。 さて、この記事は、著者がここ１年ほど携わった簡単なデータ構造の
ステップ数で評価が決まる現場では全く役に立たないテクニックではありますが、ソースコードの減らし方について紹介したいと思います。 開発Div. エンジニアのayasudaです。 2014年の夏にジョインし、会社名と同じサービス、クラウドワークス の開発に携わっています。 ご覧の通り、消したソースコードの方が多いので、ステップ数換算だとマイナスの働きしかしてませんね！ 本記事では、特に Ruby on Rails の運用されているプロダクトコードにおける、ソースコードの減らし方について紹介していこうと思います。 基本的な考え方 ソースコードを減らすときの大原則は「ボーイスカウト・ルール - プログラマが知るべき97のこと」です。 普段、ソースコードを触るときに、一つでも良いので簡単な改善を入れる。これを積み重ねるのが大事です。 一度に一気に直そうとするのはあまり良くありません。大抵の場合、デグ
Martin is the host of martinfowler.com, the author of Refactoring, and the Chief Scientist at Thoughtworks. Many years ago, when I was writing the refactoring book, I opened the book with a (very) simple example of refactoring some code that calculated a customer's bill for renting some videos (in those days we had to go to a store to do that). I was contemplating this refactoring example recently
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
