You Aren't Going to Need It 「今必要のあることだけをやれ」という意味.
XPのシンプルな設計における原則
Ｑ：PMBOKガイド第6版によれば，プロジェクト・マネジャー，プログラム・マネジャー，ポートフォリオ・マネジャー，プロジェクトマネジメント・オフィス(PMO)は，それぞれ他と異なる役割を担っている。PMOの役割は Ａ：プロジェクトに関連するガバナンス・プロセスを標準化し，資源，方法論，ツール及び技法の共有を促進する。[参 令和元年度 秋期 応用情報技術者試験 午前 問51] Ｑ：プロジェクトタイムマネジメントＡ：納期通りにプロジェクトを完了させるために、下記のプロセスで実施する取り組みのこと。【プロセス】・アクティビティ定義 ： 作業を洗い出して、定義する。・アクティビティ順序設定 ： 効率的…
はじめに 「プリンシプルオブプログラミング」の「2.3 YAGNI」を読みました。 プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則 [ 上田勲 ]価格：2420円（税込、送料無料) (2021/2/12時点)楽天で購入 YAGNI とは「You Aren't Going to Need It.」の略で、「多分必要になるだろう」で現状は不要なコードを書いてはいけないという原則です。 コーディング原則として語られることが多いですが、ソフトウェアの機能についても同じことが言え、つい先日実務でこの YAGNI 原則に則って上手く対応できたなと思えたことがあったので忘…
その抽象化、本当に必要ですか/YAGNI？ 無駄に凝集度を下げてシンプルさを失ってませんか/KISS？ 抽象化と疎結合 抽象への依存は疎結合を促進する。 origin 一体: AB step1 分離: A---B step2 抽象化: A-inter & inter-B => A.bind(B) 一体化してるやつを切り出し. 例えば関数にして切り出し. 切り出し部分にインターフェース定義 + 注入 「抽象に依存」しているので好きな具象を注入 (依存性の注入) できる. インターフェースだけを繋ぎにして両側が独立. AをA'にしても、BをB'にしてもOK. 両者を疎結合 (低い結合度、loose…
www.oreilly.co.jp 結構前に買って積んでたんですが、業務でアーキテクチャについて考える機会があって、そういえばまだ読んでなかったなと思って、ひとまず一気に目を通しました。最後のリファレンス的な手法紹介以外は結構サクサク読めて、それも意外でした。アーキテクチャの書籍というと、どうしても文面からも重厚感が漏れてくることがあって、警戒していたんですがそれは見事に裏切られました。つまり、とてもよい本でした。設計という作業に「魔法」を求めていた自分には、パラダイムの変換を迫られた、いい機会になりましたね。 この本が新しいのは読みやすさもそうですが、複数の意味での「軽さ」だと感じました。ア…
WEBサイト制作・WEBシステム開発で設計をせずにコードを作成してしまうと、仕様の変更に追従できなかったり影響範囲がわからず保守できない、もしくは不具合の多いWEBサイト・WEBシステムになってしまうことがあります。 しかし、設計・開発にもベストプラクティスが存在します。 ベストプラクティスに従うことで、仕様の変更に柔軟に対応できる保守性の高いWEBサイト・WEBシステムをつくることができます。 この記事では、コードを作成する際に意識すべきとよく言われる代表的な原則について紹介します。 SOLID SOLIDとはオブジェクト指向プログラミングでソフトウェアを設計・開発する際に守るべき原則です。…
おはようございます。 昨日の新規感染者は全国で３５３８人で、そのうち東京８６８人、神奈川３８５人、埼玉２５６人、千葉３３９人、愛知１６４人、大阪３４６人、兵庫１６１人、京都８９人、福岡１５９人、沖縄６３人、北海道１１１人などとなっています。クラスターが発生し感染が急拡大している沖縄・宮古島では、自衛隊の看護官らが派遣されるなど医療体制が危機的状態にあります。大都市では感染者数が減少傾向にありますが、地方では感染者は少ないもののクラスターが発生し感染者が増えれば医療に与える影響は都市部の比ではなく大きくなります。まだまだ全国的に予断を許しません。 政府は、依然大都市での医療体制が厳しい状況にある…
「Software development topics I've changed my mind on after 6 years in the industry」という興味深い記事が盛り上がっていたので、自分の感想を少々書いて見ようと思います。 自分の感想の前に参考までに意訳を掲載しますが、正確には原文を参照してもらえると幸いです。 記事の意訳 考えが変わったもの かつての私であれば反論したであろうが今は信じていること 経験のレベルが様々な人からなるチームで働く時には、型付言語の方が良い スタンドアップは、新人を見守るのに実に有益である スプリントレトロスペクティブは、本当に進路を修正する…
大学で画像処理やら言語処理でC言語とかPerlをちょい書くくらいだった自分にとってプログラミングなんて大してさわるもんでもなく、今みたいに簡単にとっかかれる環境もなかったし、プログラマーやり始めた当初は大変ひどい目にあった。 仕事で数年使って少しずつプログラミングができるようになってきたあたりで、周りにUNIX原則だのYAGNIだの言ってる人がちらほら出始めていてそんときこの本あったら色々幸せだったなあと。 プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則作者:上田勲発売日: 2017/04/27メディア: Kindle版 3年目までに身につけたいそうで…
まぁつまり「気にしないところ」も少なからずあるのですが。 「規約がある所では、書いてある範囲で規約を重視しましょう / 書いてない規約は"既存のコード"に出来るだけあわせましょう」とかいう最低限のお話とか、さらにもっと最低限未満のお話として「syntax errorとか脆弱性あるコードとか書いてくんなボケ*1とかあるのですが。その辺は押さえた上で、じゃぁおいちゃんが「何を気にしていて」「それはなんでなの？」ってのを、自分自身の内面の整理を兼ねて書いてみようかなぁ、と。多分、おいちゃんが一番気にするのは・YAGNI(You Aren't Going to Need it.)：それ、要らないよね？…
業務の振り返り 細かいところは公開できないので簡単に。 1月、小さい案件だけど顧客に近い立場で技術をリード。インフラ～バックエンドまで見れるスキルは役に立った。 2-4月、別チームのヘルプ、アーキテクチャは固まっていて、個別の機能開発、API開発やインフラの改善タスクがメインだった。素早く細かく対応して、チームに貢献はできたが、技術的な難易度は高くないので個人的にはまぁまぁの満足度。 5-12月、技術を中心にサーバレスで難易度が高い機能の設計、開発をやらせてもらった。サーバレスかつ技術的な難易度が高い案件でアーキ的なポジションをやらせてもらったのはとても良かった。個人のスキルで切り開いていく点…
この記事は TDD Advent Calndar の 20 日目の記事です。1 日遅れました。すいません。 記事を書くことになったきっかけ こんなツイートをしたら 一周（？）まわって、TDDって一体何だったんだっけ？っていうのを考えている。— ベーシック焼肉 (@a_suenami) 2020年12月6日 見つかってしまいました！ その考えのアウトプットをお待ちしてます！whttps://t.co/fIFVAkuitQ— broccoli (@nihonbuson) 2020年12月6日 というわけで、最近考えてることを書きます。 何が開発を駆動するのか TDD は日本語では「テスト駆動開発」…
PE部PE課の礒です。毎日寒くても心は実家のこたつの中です。 今回私が視聴したセッションはこちらです。 「Best practices for securing your serverless applications」 私はよくサーバーレスアプリケーションを作るのですが、動画を視聴してみて今まで実践できていなかったベストプラクティスを学ぶことができました。 (特に「トレードオフを考える」の内容が勉強になりました！) 本記事では、そんなこちらのセッションの概要を紹介させていただきます。 是非、上記リンクから実際にご覧ください。 アジェンダ サーバーレスアプリケーション VS 従来のモノリシック…
この記事は エムスリーAdvent Calendar 2020の16日目の記事です。 エムスリーエンジニアリンググループの関根（@sekikatsu36）です。 2020年4月よりエムスリーへ参加し、主にSRE業務を担当しています。 エムスリーでは数百のマイクロサービスを開発・運用していますが、マイクロサービスは1つの処理の流れを追跡すること（トレーサビリティ）が難しく、トラブル時の原因特定にコストがかかるという課題があります。 その解決策として分散トレーシングに着目し、GCPのCloudTraceを主要サービスへ導入することを進めてきました。 ここではその活動を通じて得た知見を雑多にご紹介し…
2020年12月7日 『DMM.com を支えるデータ駆動戦略』（石垣 雅人 著，松本 勇気 監修，マイナビ，2020年9月26日）を読了。 アジャイル開発の基本は「プロダクト開発において確実なものなど存在しない。失敗することが前提」という考えのもと，「小さく早く作ってリリースする」ことを大事にしています。「なぜその機能が必要なのか」を考えた上で，いかにプロダクトにおける最小限の機能を構築して，すばやく市場へ投入できるか。そこからユーザーの反応を見て学習し，再度最適化された機能を提供できるか，といった方法が主流になって広がり始まりました。 私はこの考え方が大好きです。（p. 4） 私もこの考え…
この本を読む前の自分へ 君がなんとなく知ってることが，ちゃんと根拠ありで説明されているよ 読んだり聞いたりしてもすぐ忘れちゃう君には第３章が有用だと思う 色々な「知的生産術」が紹介されているけど，筆者も言ってるように好きなところから始めればいいと思う やっぱり繰り返しとかアウトプットとかが大切らしいよ 以下メモ はじめに 知的生産とは何か 知識を用いて価値を生み出すこと プログラミンや執筆 本に書いてあることを知っている程度では弱い 本に書いてあることを咀嚼して自分が直面している課題を解決することが大切 「 情報収集・モデル化・検証」の繰り返しを通して学ぶ 情報収拾: コードリーディング，写経…
www.slideshare.net
ja.wikipedia.org
yamamotoyama.tumblr.com
u-1roh.hatenadiary.org
techracho.bpsinc.jp
ameblo.jp
d.hatena.ne.jp
martinfowler.com
techracho.bpsinc.jp
