タグ検索の該当結果が少ないため、タイトル検索結果を表示しています。
こんにちは！Xイノベーション本部プロダクトイノベーションセンターの米久保 剛です。 弊社のテックブログ上では今回が初めての記事執筆となります。アーキテクチャ設計やアプリケーション設計の話を中心に、不定期に情報発信していきたいと考えています。 YAGNI原則 YAGNI原則をご存知でしょうか。 エクストリーム・プログラミング（XP）の重要な原則の一つであるこの原則は、You Ain't Gonna Need Itのアクロニム（頭字語）から命名されています。日本語にすると「どうせ要らないって」というニュアンスでしょうか。推測に基づいて余計な機能を作り込んだところで将来実際に使われる可能性は低く、時間と労力を無駄にするばかりかコードの複雑化などのリスクさえあります。ですから、現時点でわかっている要件をちょうど満たすだけの機能を実装すべきであるとYAGNI原則は主張します。 YAGNI原則は機能（
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
世の中にはプログラミングのベストプラクティスとして紹介される原則があります。例えば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でフロントを書いたりといった仕事をしています。 キャディに入社する前は別の
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
YAGNIと拡張性のあいだ - 電通総研 テックブログ
物流効率化システム開発で学んだYAGNIの原則の効果 | Raksul ENGINEERING
ドメインモデルの変更で踏み切った「プロダクトのリプレイス」 YAGNI・学習コスト削減・テスタビリティ向上を考慮したRust選定
oyazimirai.hatenadiary.jp
arisa0.st.coresv.net
news.yahoo.co.jp
togetter.com
www.maruhan.co.jp
ameblo.jp/akitakata-shiseinet