DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 Read less
YAGNI - Wikipedia
英: You ain't gonna need it[1]、縮めて YAGNI とは、機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 理由[編集] YAGNI原則を提唱する人々は、その理由として以下を挙げている。 後で使うだろうという予測の元に作ったものは、実際には10%程度しか使われない。したがって、それに費やした時間の90%は無駄になる[2]。 余計な機能があると、仕事が遅くなり、リソースを浪費する[2]。 予期しない変更に対しては、設計を単純にすることが備えとなる。そして、必要以上の機能を追加すると、設計が複雑になってしまう[2]。 人生の時間は、貴重である。したがって、人間の能力は、ただコードを書くためではなく、現実の問題に集中するために使うべきである[3]。 結局は、その機能は必要ないかもしれない。もしそうなったら、あなた
Joel on Softwareに面白そうな記事が載っていた。 とはいえ、どうも僕の英語力では完全な読解が難しい。会話を書き起こしたものなので当然ながら文体が会話調で、僕にはなかなか理解が難しいのだ。以下で僕の読み間違いがあれば指摘して欲しい。 さて、冒頭で Joel 氏はこう言っている。 Joel: There's a debate over Test Driven Development... should you have unit tests for everything, that kind of stuff... a lot of people write to me, after reading The Joel Test, to say, "You should have a 13th thing on here: Unit Testing, 100% unit tests
プログラミング一般 DRY原則 YAGNI KISS原則 OAOO UNIX思想 可逆性 曳光弾 直交性 契約による設計 DbC プログラマの三大美徳 PIEの原則 SLAP パフォーマンスチューニングの格言 驚き最小の原則 ボーイスカウトの規則 One Fact in One Place DTSTTCPW 割れた窓の法則 名前可逆性 オブジェクト指向プログラミング デメテルの法則 パルナスの規則 求めるな、命じよ コマンドとクエリ分離原則 オペランドの原則 用語 抽象データ型 サブタイプ ダックタイピン
プログラミング原則一覧 - Strategic Choice (via jun26)
こんにちは！Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング（XP）の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム（頭字語）から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能（
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Practicing YAGNI 原文公開日: 2018/01/17 著者: Jason McCreary 画像は英語記事からの引用です。 しばらく前に私はLaraconでYAGNIの実践についてスピーチしました。このような大きなカンファレンスで大勢の観衆を前にプレゼンしたのは名誉なことでした。以来、私のスピーチに多くの反応や関心が寄せられています。 私のスライドを共有したいという申し出を多くの方からいただきましたが、ほとんどの議論がスライドに対して行われたので、ブログ記事にまとめる方がよいと思えました。スライドをご覧になりたい方は、StreamAConで私のスピーチを視聴できます。 私は自分自身を「探求者」だと思っています。プログラミングの秘訣における聖杯、それさえ手に入れれば即座にスキルアップできるたったひとつの聖杯の探求です
『YAGNI ～ 予想でモノを作るな』
人間には未来の出来事を知ることはできない。だから、せめてできる限りの予想をして未来に備えよう、ということになる。プログラマの仕事でもそうだ。 「次のバージョンアップでこんな機能が要求されてるんだけど」 「そんなこともあろうかと、その仕組みは既に作ってあります」 なんてことになれば、得意な気分になる。予想が当たれば嬉しいのは、ギャンブルもソフトウェア開発も同じだ。 しかし、予想に基づく行動にはリスクが伴う。それもギャンブルと同じである。 以前、私は、あるシステムの内部データを CSV ファイルとして出力するプログラムを作った。その際、将来のバージョンアップで出力するデータ項目が追加されるかもしれないと考えた。そこで、プログラムを直さなくても、「定義ファイル」に項目を追加するだけで、CSV に出力できるようにしておいた（顧客からそんな要望はなかったにも関わらずだ）。 しかしである。その後、実際
概要 生産性について 綺麗に書くことのメリット ハッキーな書き方をする 綺麗なコードとは ボーイスカウトルール YAGNI KISS 単一責任の原則 早計な最適化を控える 命名 曖昧な単語 コメント ドキュメンテーション 非形式的なコメント 状態 直交と非直交 直和型 列挙型 関数 コマンドクエリ分離の原則 定義指向プログラミング ネスト メソッドチェイン マジックナンバー 早期リターン 依存 結合 単純なクラスから複雑なクラスへの依存 コードレビュー まとめ 概要 今回こちらの本を読みました。 読みやすいコードのガイドライン 内容的には、コードの保守性や、可読性を高めることによって、開発スピ…
bliki: Yagni
Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it". Yagni is a way to refer to the XP practice of Simple Design (from the first edition of The
TL;DR: Inheriting from Hash will bite you. ¯\_(ツ)_/¯ This is Yet Another Post about preferring composition over inheritance, but I will try to drive it home with Real World Examples™. I’m not saying “don’t use inheritance”, I am saying “use inheritance conservatively, and when it is appropriate” (I know it’s not very controversial). I think I can confidently say “don’t inherit from String, Hash, o
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
この連載の第1回から第3回までは、ある種の議論の前提を示すために存在する。これは、いくつかの常識を壊し、別の常識を提示するという役割を持っていた。そして、前回（第4回）以降は、その前提の上に立って、実践的なXMLデータベースの使い方に関する話題を扱う。前回は、実践的なノウハウの1つとして「XMLデータモデルによる設計の基礎」について、さまざまなトピックについて説明した。例えば、「XMLデータベース設計における20-80ルール」として、「多種類のデータを一貫して扱う設計の80％は、20％の労力によって得られる」という解釈を説明した。このような観点から、すべてのデータを一貫して扱う唯一のスキーマを記述する試みがうまく機能しない理由を説明した。そして、たった1つのスキーマによって全データを扱おうとせず、例外的なスキーマを受け入れるべきと説明すると同時に、それを受け入れるべきときと、受け入れるべき
週刊Railsウォッチ（20181217）Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか
2018.12.17 週刊Railsウォッチ（20181217）Railsのafter_*系フックは要注意、早すぎるDRYとYAGNI、mruby 2.0リリースほか こんにちは、hachi8833です。先日のRailsdm Day 4ではルームAで終日配信担当だったのでルームBの出し物がわからずじまいです。 各記事冒頭には⚓でパーマリンクを置いてあります: 社内やTwitterでの議論などにどうぞ 「つっつきボイス」はRailsウォッチ公開前ドラフトを社内有志でつっついたときの会話です👄 毎月第一木曜日に「公開つっつき会」を開催しています: お気軽にご応募ください ⚓Rails: 先週の改修（Rails公式ニュースより） ⚓コレクションプロキシのdelete_allがcountを返すようになった PR: Ensure that `delete_all` on collection pr
TL;DR: OutputBuffer subclasses SafeBuffer which forces us to do runtime checks that are probably unnecessary I made a post about YAGNI methods hurting you where I said I would provide two examples, but then I got tired of writing the article so I just did one example. Here is the other example! The previous example demonstrated a memory leak that was introduced because the “footprint” (the number
プログラミング一般 DRY原則 YAGNI KISS原則 OAOO UNIX思想 可逆性 曳光弾 直交性 契約による設計 DbC プログラマの三大美徳 PIEの原則 SLAP パフォーマンスチューニングの格言 驚き最小の原則 ボーイスカウトの規則 One Fact in One Place DTSTTCPW 割れた窓の法則 名前可逆性 オブジェクト指向プログラミング デメテルの法則 パルナスの規則 求めるな、命じよ コマンドとクエリ分離原則 オペランドの原則 用語 抽象データ型 サブタイプ ダックタイピン
プログラミング原則一覧 - Strategic Choice (via jun26)
ソフトウェア開発の分野ではYAGNI(You Ain't Gonna Need It)という表現があります (人によっては「You Aren't Gonna Need It」と書いています)。 「こうなるかも知れない」をドンドン積み上げていって不要に時間を割くべきではないという考え方です。 wikipediaの項目によると不必要な冗長性には以下のような副作用があるそうです。 それによって、別の新しい機能を追加したりテストする時間が削られている 新しい機能にはテスト/デバッグ/ドキュメント/サポートが必要になる 「将来どのような機能が必要になるか」という予測の元に制作されるため、実際に必要な機能が発生したときに予測で作ったものが障害になる可能性がある 実際に必要になるまでは新しい機能を定義したりテストする事は難しい。そして、そのようなものは本当に必要になったときに動作しないことが多い コード
その１ YAGNI（ヤグニ）の原則でいこう
＜戻る STGつくろー！ その１ 「YAGNI（ヤグニ）の原則でいこう！」 ① YAGNIとは？ STGを作るなどという大それた目標を掲げてしまいました。 掲げたからには、本腰と気合を入れて取り組まなければ！と思う反面、いったい何からてをつければいいのか皆目見当もつかないありさま･･･ 「どうして見当がつかないんだろう･･･」 目の前に広がるプログラムの渦。流される私、そして滝が･･･ 「滝･･･そうか！」 半ば強引に、理由がわかりました。そう、私はSTGを作ろうと気張るあまり「ウォーターフォール型」の設計を思い浮かべていたのです。 ウォーターフォール型の設計とは、分析・設計・実装・テスト・運用と滝が落ちるかのように製作工程を進めていく古典的なソフトウェア開発手法です。最初の「分析フェーズ」で実現したいソフトウェアに関するすべての事柄を将来の追加予定を含めて洗い出し、「設計フェーズ」でそれ
アジャイルサムライは良書だけど読む人によっては補足しないと危険かも。 - YAGNI, KISS, Thinking outside the box.
今日のランチ時にアジャイルサムライ in ECナビ社内バーAJITO道場の第1回目が開催された。アジャイルサムライはAmazonが在庫切れで買うのが大変みたいだけどそういう人はPDF版を買えばいいのでソフトウェア開発にたずさわる人はみんな読むといいよ。今日は初回なので第Ⅰ部 「アジャイル入門」についてディスカッションした。あらかじめ下読みしておくようにとスケジュールに書いてあったがざーっと斜め読みしかしてなかったのは内緒だ。 さて、アジャイルサムライが良書なのは間違いないが、読む人によっては誤解されてしまう危険があると思っている。例えば「3つの真実」の「1. プロジェクトの開始時点に すべての要求を集めることはできない」とか「2. 集めたところで、要求はどれも 必ずといっていいほど変わる」はいわゆるウォーターフォール開発で苦渋をなめた人が読めば「うんうんそのとおり、プロジェクトの初期段階で
YAGNI (You ain't gonna need it) [1] は便利な言葉だ。似たような言葉にKISS [2] なるものがあるが、シンプルにしろ！と言われるより、 そんなものいらん！と言われる方が私にはしっくりくる。他人のコードをレビューするときも、「YAGNIの考え方からして、この部分は不要なんじゃない？」という方が「お前のパッチは無駄に複雑だ！」というよりは説得力がある、と思う。 YAGNI が有用な考え方なのは、無用な複雑化を避けられるからだ。premature optimization (早計な最適化）は諸悪の根源、という考え方があるが、私からすると、premature complication （早計な複雑化）はさらにたちが悪い。ソフトウェアは規模が大きくなるにつれ、多かれ少なかれ複雑化は避けられないものだが、複雑化の進行は遅いに越したことはない。 とりわけ、抽象化のレ
改めてセキュリティ対策をやってないのは単なるバグだよねと思ったので、徳丸本こと『体系的に学ぶ 安全なWebアプリケーションの作り方』の社内勉強会を開催することにした。 徳丸本の勉強会はすでに他社と合同で隔週で行っているのだが、そちらに参加できていない人もまだ多数いるので、別で立ち上げてもそこそこ人数集まるだろうという算段だ。 業務時間外にやるので希望者の任意参加なのだが、すでに11人が手を上げている。予想通りとはいえうちのエンジニアはホント学習意欲の高い人が多くて嬉しい。 7月から週1回で全10回くらいでやっていきたいと思う。
YAGNIYou Aren't Going to Need It.それは必要にならない。どういうこと？多分必要になるだろうではなく、本当に必要になったときに必要なモノを作成する。 なんで？あらかじめいろいろな事態にそなえて機能を盛り込んでおいても、結局利用されないことが多い。それどころか余計な複雑性を盛り込むことになる。 『エントロピーの増大はソフトウエアを殺す＠達人プログラマー』この無駄をなくすための指針。変更があったときは、その時に考える。それよりも、シンプルな設計で前へ進もう、ということ。参考XPシンプル＠価値シンプルな設計＠開発プラクティス達人プログラマー―システム開発の職人から名匠への道作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章出版社/メーカー: ピアソンエデュケーション発売日: 2000/11メディア: 単行本購入:
YAGNI exceptions
I'm essentially a believer in You Aren't Gonna Need It – the principle that you should add features to your software – including generality and abstraction – when it becomes clear that you need them, and not before. However, there are some things which really are easier to do earlier than later, and where natural tendencies or a ruthless application of YAGNI might neglect them. This is my collecti
知っておきたい！YAGNIの法則 - Qiita
この記事では具体的なコードについては触れません。 コードを書いていくのに使える法則について紹介します。 また、この記事では「プリンシプル オブ プログラミング」という本を読んだ上で、 自分が特に重要と思った箇所を、備忘録も兼ねて、書いています。 YAGNIとは 早速ですが、タイトルにあるYAGNIとは「You Aren't Going to Need it.」の略であり、 日本語では、「それはきっと必要にならない」という意味になります。 この意味からピンときた方もいるかもしれませんが、 このことをコードを書く上での法則に落とし込むと以下のようなことになります。 コードを書く上で「これが後で必要になりそう」で書いてはいけないという法則です。 あくまで、必要なものは必要になったときに書けばよいという考えで取り組みます。 どんなに正確に予想しようとしたところで、結局のところ予想でしかないので、
[連載：ひがやすを×和田卓人] プログラマー人生を楽しむために知るべき97のこと【恋愛編 2/2】 『YAGNI』を私生活にも応用しよう 2011/09/09公開 << プログラマー人生を楽しむために知るべき97のこと【恋愛編 1/2】 技術屋の「公平さ」は恋の敵!? 和田 ひがさんにも恋愛下手な時代があったんですか？ それは聞きたい。 ひが この話は、和田さんにも、読者にも共感してもらえると思うんだけど、仕事に没頭していて夢中な時ほど、恋愛がどうでもよく思えたりしない？ 和田 僕の場合はほとんどいつもそうだったかもしれない（苦笑）。 ひが 僕は今の勤め先に入社してすぐ、ある金融系の案件を担当することになって。技術のことだけじゃなく、まったく知らなかった金融業界の業務とかも覚えなければいけなかったから楽な仕事ではなかったんだけど、とにかく新しいことを吸収するのが面白くて。どんどん仕事にのめ
![[連載：ひがやすを×和田卓人] プログラマー人生を楽しむために知るべき97のこと【恋愛編 2/2】 『YAGNI』を私生活にも応用しよう - エンジニアtype](https://cdn-ak-scissors.b.st-hatena.com/image/square/d71a43dd04d9ca532dfca2d923d7975cffa5b7dd/height=288;version=1;width=512/https%3A%2F%2Ftype.jp%2Fet%2Ffeature%2Fold_contents%2F2011%2F09%2F6ca82173bcebf2c49fc4c1c6c2f56ce0.jpg)
ユーザー認証のテスト(4) -- YAGNI
前回は、RSpec のスタブ機能を利用して Customer.authenticate メソッドの実装を後回しにしつつ、ユーザー認証が成功するするシナリオについてテストを通しました。 今回は、Customer.authenticate メソッド自体の実装に着手します。 FactoryGirl::Syntax::Methods モジュール 本題に入る前に、テストコードの分量を減らす方法を紹介しておきます。 現在、各所で FactoryGirl.build あるいは FactoryGirl.create というメソッド呼び出しが記述されています。今後も使用する回数は増えるばかりです。 そこで、spec/spec_helper.rb を次のように修正します： # (省略) RSpec.configure do |config| # (省略) config.expect_with :rspec d
世の中にはプログラミングのベストプラクティスとして紹介される原則があります。例えばDRY, KISS, SOLIDなどが挙げられます。 ハコベルのサービスを作ってきた歴史を振り返ってみると、YAGNIの原則に近い意思決定だったなと思うものがありました。その判断もたらした影響を、YAGNIの原則に従うメリットの事例として紹介したいと思います。今回紹介する事例と現在我々が取り組んでいること、両方が物流の効率化に関わるものとなっています。当時の想定と現在の取り組み、その違いと今後の展望についても併せて紹介していきます。 YAGNIとは Wikipediaでは以下のように定義されています。 機能は実際に必要となるまでは追加しないのがよいとする、エクストリーム・プログラミングにおける原則である。 https://ja.wikipedia.org/wiki/YAGNI “You ain’t gonna
受発注・サプライチェーン管理システムとサプライパートナー向けシステムに関する現状や課題などについて、開発を担当しているエンジニアが話す「Rustで負債を解消するために大幅刷新する複雑な業務Webアプリ」。ここで バックエンドエンジニアの松田氏が登壇。Rust製の業務WebアプリケーションをRustでリプレイスした経験について話します。 自己紹介 松田圭紀氏（以下、松田）：キャディ株式会社 バックエンドエンジニアの松田と申します。私からは「Rust製の業務WebアプリケーションをRustでリプレイス」というテーマでお話したいと思います。 まずはじめに自己紹介です。私は1年半ほど前にキャディに入社して、バックエンドエンジニアをしています。主に受発注プロダクトのバックエンドをRustで開発したり、たまにTypeScriptでフロントを書いたりといった仕事をしています。 キャディに入社する前は別の
TDDはYAGNIに矛盾する？ - u_1rohのカタチ Joel Spolskyの意見とコメント欄でのやりとりがどっちも面白かった。 僕のテストの書き方としては、テストファーストではなく、思いつきで処理を実装していくうちに仕様のようなものが見えてきたらテストを書いて保証する、というスタイルが多い。 「仕様のようなもの」というのは、「このメソッドはこういう値を返すべきだ」というような挙動の定義を指す。RSpecが「obj.foobar.should == "barbaz"」のように「should（〜すべき）」といった形式でテストを書かせ、テストをまとめたファイルを「spec（仕様）」と呼ぶのはたぶん偶然ではない。 これらは厳密な意味でのTDDとは違う（ただのユニットテスト論?）かもしれないけれど、とりあえずはこういうスタイルでやってて上手くいってる。 概念や私見はこれくらいにして、実際にど
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
それはYAGNIか? それとも思考停止か?
TDDはYAGNIに矛盾する？ - カタチづくり
YAGNIと拡張性のあいだ - 電通総研 テックブログ
YAGNIを実践する（翻訳）｜TechRacho by BPS株式会社
YAGNIとは コンピュータの人気・最新記事を集めました - はてな
YAGNI methods are killing me | Tenderlove Making
Martin Fowler氏が"Yagni: You Are Not Gonna Need IT"について語る
XMLデータベース設計におけるYAGNI問題（1/4） － ＠IT
YAGNI methods slow us down | Tenderlove Making
年末の大掃除におけるYAGNI(You Ain't Gonna Need It):Geekなぺーじ
YAGNI と premature complication #4
徳丸本の社内勉強会を始める - YAGNI, KISS, Thinking outside the box.
YAGNI - Strategic Choice
[連載：ひがやすを×和田卓人] プログラマー人生を楽しむために知るべき97のこと【恋愛編 2/2】 『YAGNI』を私生活にも応用しよう - エンジニアtype
物流効率化システム開発で学んだYAGNIの原則の効果 | Raksul ENGINEERING
ドメインモデルの変更で踏み切った「プロダクトのリプレイス」 YAGNI・学習コスト削減・テスタビリティ向上を考慮したRust選定
なんかばんざい | TDDはYAGNIと矛盾しない。必要だからテストを書く。