コード品質特性を悪化させるには - 覚えたら書く
プログラムのより良い設計を支える中心的概念としてコード品質特性があります。これに点数付けした場合に、悪い点をとるためにはどうすればいいかについて書きました。 以下内容のベースはJavaです そもそもコード品質特性とは ここでは、以下をコード品質特性としてとりあげます 凝集度（cohesion） 疎結合（loose coupling） 重複無し（zero duplication） カプセル化（encapsulation） テスト容易性（testability） 可読性（readablity） 各々の項目で悪い点を取るためにはどうすればいいか以下の各項目を参考にしてください 凝集度（cohesion） 基本的に、凝集度は高い方が良いと言われます。凝集度を低くするためには、クラスやパッケージの責務を増やせばよいです。そのためには以下に従うと良いでしょう。 1クラスを大きくする 1クラスが大きけれ
齢30を越えてようやく気づいたWebエンジニアの勉強に関するベストプラクティス - おうさまのみみはロバのみみ
…を書こうと思っていた矢先に↓が投稿された。 しかもぼくが書こうとした内容よりも理論付けられていたり、充実した内容だったり、深掘りされてたりして非常に良いのでこれ読めばだいたい終わるし書かなくていいじゃんね！ってなった。 完。 employment.en-japan.com これを読んだあとで「あーこんな良いエントリあるならぼく書かなくてもいんじゃね？っていうかぼくも知らない内容書かれてて充実度で完敗だし書く必要性無くね？？」とか思って書かないでおこうかと思っていたのだけども 別にぼくが似たようなことを書いてもPV数やまとまっている内容の充実差で件のエントリに微々たる影響を及ぼすこともなかろう、あと単純に書いて頭の中を整理しておこうと思い直したので今書いてる。 タイトルは元々の主旨なのだけどそれは↑を読めば満足できると思うのでこのエントリはそこからちょっと外れているものを書いておこうと思う
続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが！ 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン６：操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE） 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する（UPDATE） この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある： 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する（UPDATE）→
一日8時間、60日間ペアプロしてみて思った日常ペアプロのコツ. 一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミン… | by Naohiro Oogatta | Medium
一日だいたい8時間、今日まであわせて60営業日くらい、固定ペアのペアプログラミングで新規アプリのクライアントからサーバまで開発してみました。チームにエンジニアがちょうど二人だったので。 もはや日常がペアプロです。ペアプロ以外でやってるのは簡単なバグ修正やちょっとした環境整備で、あとはすべて二人で開発しています。ちなみにまだまだ続いています。狂気です。 いい大人が二人集まって狂気を選ぶことになったわけは、成果も出てないしまだ書けません。でも今って、ペアプロやモブプロがブームだって聞きました。それじゃあアホみたいにやってる人間としては黙ってられないです。基本的なことはおいといて、とりあえずこれだけはってつくづく思ったのとか、ペアプロを有意義に長く続けるコツをまとめてみました。 （ちゃんとした話は ペアプログラミングの5W1HとFAQ / 5W1H and FAQ of Pair Program
コーディングに対する考え方を変える6つのプログラミングパラダイム | POSTD
私は時折、コーディングに対する考え方を変えさせられるような、従来と非常に異なるプログラミング言語に出会います。本記事では、その中でも特に気に入っている発見をいくつかご紹介したいと思います。 これは、先賢による「関数型プログラミングは世界を変える！」的な投稿ではありません。本記事で挙げるのは、もっと「知る人ぞ知る」的なリストです。多くの読者の方にとって、以下の言語やパラダイムは聞いたことのないものが大半だと思いますので、私が経験したように、これらの新しい概念を学ぶ楽しさを感じていただければ幸いです。 注：私は以下の言語の多くに関して最低限の経験しかありません。その発想に引き込まれたのであって、専門的知識は持ち合わせていないため、訂正すべき点や誤りがあればどうぞご指摘ください。また、本記事で取り上げていない新しいパラダイムや概念に出会った方は、ぜひお知らせください。 最新情報：本記事が r/p
ユースケースによるアスペクト指向(Laravel編) - Qiita
この記事は株式会社アイスタイルアドベントカレンダーの18日目の記事です。 弊社ではPHPをメインで利用しています。 一部のプロジェクトでは表題のアスペクト指向を用いて開発しています。 アスペクトのおさらい 横断的関心の分離をする技術で、アスペクト(AOP)はオブジェクト指向プログラミング (OOP)を補完する技術の一つです。 AOPはポイントカットとアドバイスを利用して定義を行います（AspectJ）。 ポイントカット 後述するアドバイスがどのような条件で実行するかを定義するものです。 例えば、 Hogeクラスのfugaメソッドが実行される時 Hogeクラスの全てのメソッドが実行される時 Hogeクラスのメソッドのうち、setというプレフィックスが付いてるものが実行される時 などがあります（ジョイントポイント）。 言語やライブラリによって定義されているものなどがありますので、 それぞれのラ
要するに DI って何なのという話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
友人から「しんぺいさん DI について書いてほしい」みたいな話をだいぶ前からされてたんだけど書く気力ずっとなかった。でも仕事の気分転換にちょっとずつ書いたやつがいい量まとまったので公開するです。たいしたことは書いてないっていうか知ってるひとにはあたりまえのことしか書いてない。サンプルコードはわたしの趣味で Scala で書いてあるが、Java が読めればなんとなく読めると思います。 DI ってなに Dependency Injection、日本語で言えば依存性の注入です。おしまい。 で記事を終えてもいいんだけど、そもそも依存性とはなんなのか、それを注入するとはどういうことなのか、なぜ DI が必要となるのかみたいな話をこれからします。 そもそも依存性ってなあに 例を出します。入力された文字列をもとにおみくじをひいて、その結果を twitter に投稿するプログラムにしましょう。 まずは普通
スタープログラマの幻影 - megamouthの葬列
最近久々に「スタープログラマ」という言葉を聞いた。 そういえば、私の中にもかつてそういう存在がいたなあ、と思い出した。 あえて定義することもないが、スタープログラマとは、先進的なOSSプロダクツを実装し、ブログなどでプログラミングを堂々と論じ、できれば単著の一つも書いているような人たちといったところである。 話の都合上、具体的な名前を出すが、高林哲氏、higepon氏、新山祐介氏などが、私にとってのスタープログラマであったし、少し時代を戻すとεπιστημη氏であるとか、賛否両論だとは思うが、やねうらお氏などの名前が挙げられるかもしれない。 スタープログラマというのは、駆け出しのプログラマやプログラム学習者にとっての目標であり、先輩であり、嫉妬の対象でもある。 彼らの言葉は絶対で、疑う余地もないことであり、私はそのプログラミングに対する思想を無条件に受け入れたし、彼らが使っているエディタや
例外、エラー、異常、そして - Qiita
「例外」「エラー」「異常」あたりの言葉が、言語仕様や設計の中で人によって微妙にずれた使い方されてるから、 「Expected だが Accept されないケース」を表す別の言葉が欲しい。 — Jxck (@Jxck_) 2016年8月31日 @Jxck_ 本来こう分類されて、 1. Expected/Accepted 2. Expected/UnAccepted 3. UnExpected 2, 3 をどう呼ぶかあたりで、例外, エラー, 異常などの言葉が入り乱れてて、それが広義の例外処理が誤解される原因だと思ってる — Jxck (@Jxck_) 2016年8月31日 Expected and Accepted Expected but Unaccepted Unexpected
契約による設計と名前による型づけ, およびオブジェクトの不変性 - 貳佰伍拾陸夜日記
契約による設計と名前による型づけ 最近, 社内で契約による設計の話が雑談として何度か出ていて, id:hakobe932さんが社内勉強会で紹介していたり, id:shiba_yu36さんがWEB+DB PRESSでSmart::Argsで制約をチェックする記事を書いていたり, 活発な議論になっている. インスタンスのファクトリメソッドとオプショナルな型を組み合わせると事前・事後条件を満たすことが保証できて, id:hakobe932さんの資料で言うところの「要求型」と「保護型」の区別も明確になってよいという話を書こうかとおもっていた. (これはそのうち別で書く.) とはいえ, こんな話はもう言っている人がいるだろうと思ってちょっと調べていて, どういう語句で調べたらいいか考えていた. インスタンスの型からそれを生成したファクトリメソッドが特定できて, それによって事前・事後条件が保証される
CQRSの和訳
DDDとCQRSについて DDD (Domain Driven Design = ドメイン駆動設計)が世間に知られるようになってきましたが、今度はDDDをさらにスケーラビリティにするCQRS (Command Query Responsibility Segregation = コマンドクエリ責務分離)が出てきました。 DDD提唱者の英語本の和訳版「エリック・エヴァンスのドメイン駆動設計」がAmazonにありますが、非常に分厚く高価です。概要をまとめた資料が「Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 - InfoQ」から入手できます。 CQRSはデータベース設計とイベントソーシングも含めた壮大なWebアプリケーションのアーキテクチャですが、日本語の資料がまだ少ないです。CQRSを適用したアプリケーションを構築できるインフラがWindows Az
契約による設計から見た例外 - Qiita
正しさは相対的な概念である。 Bertrand Meyer [1] Bertrand Meyer氏は「契約による設計」という概念から例外を導出し、例外の必要性をエレガントに説明しています。また、彼の説明に則れば今までの議論と比べて例外をいくぶんか形式的に扱えるようになります。契約による設計を学ぶ前に、プログラムの正しさについてもう一度考えてみましょう。 プログラムの正しさ あるプログラムが正しいかどうかを判定するにはどのようにすれば良いでしょうか。最も簡単な方法は、あるプログラムの正しさを形式的に定義する事です。より直接的に言えば、あるプログラムの正しさを簡単な論理式で表現します。その論理式が真ならばそのプログラムは正しい。偽ならばそのプログラムは正しくありません。 これだけだと関数の戻り値を検査すれば良いだけのようにも聞こえます。しかし、そう簡単な話ではありません。純粋でない言語の場合、
とある契約の備忘目録。契約による設計(Design by Contract)で信頼性の高いソフトウェアを構築しよう。 - Bug Catharsis
「より堅牢で正確性の高いソフトウェアを作りたいぜ！」と願う.NETデベロッパーお待ちかねの、 契約による設計(DbC)をサポートするCode Contractsが.NET Framework4より利用できるようになります。 C#をベースとして契約による設計をサポートする「Spec#」を利用するという方法もありますが、 学習負担を軽減するためにと、マイクロソフトは言語を意識しなくても開発者が利用できるように、 Code Contractsとして.NET Frameworkで契約をサポートしてくれました。 これは、オブジェクト指向および、オブジェクト指向プログラミングが大好きな.NET開発者にとって、とても良い知らせです。 わたしも待ち望んでいたうちのひとりです。ありがとうマイクロソフト！！という気持ちでいっぱいです。 VisualStudio2010が4月12日（米国）にローンチされることが
契約による設計の紹介
プロジェクト新規参入者のリードタイム短縮の観点から見る、品質の高いコードとアーキテクチャを保つメリット
契約による設計の紹介 - Hatena Developer Blog
こんにちは、チーフエンジニアの id:hakobe932 です。 はてなでは毎週、社内技術勉強会を開催しています。先週の勉強会では現在開催中のはてなインターン2016の参加者のみなさんもインターン生も参加して、いっしょに技術交流を行いました。 このエントリでは、そこで発表した、契約による設計の紹介をしたスライドを公開します。 契約による設計はBertrand Meyer氏によるオブジェクト指向入門*1という書籍で紹介されている考え方です。 オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) 作者: バートランド・メイヤー,酒匂寛出版社/メーカー: 翔泳社発売日: 2007/01/10メディア: 単行本（ソフトカバー）購入: 11人 クリック: 307回この商品を含むブログ (130件) を見る 契約による設計で
サービスクラスについては僕も悪かったと思っているけど、それでもCQSは実現したいんだ - Qiita
このエントリは Ruby on Rails Advent Calendar 15 日目です。（遅くなってすいません） 同時に 14 日目のじょーかーさんのエントリへのアンサーエントリでもあります。 （まあ、じょーかーさんがこの Advent Calendar に登録したときに、タイトルから内容を推察してこれを書くことを決めましたが、実際のところ、あまりアンサーにもカウンターにもなってないし、全然関係ない内容と言えないこともないので、まあサービスクラスについては僕も推奨したことがあるし、僕も反省してるんですよ程度に読んでもらえると幸いです。） まずはじめにごめんなさい 3 年くらい前に僕は Rails にサービスクラスというものを導入するといいことがあるよと書いたのだけど、それからいくつもの Rails アプリケーションを見たり、実際に自分で開発したりして、うーんって思うことも増えてきたので
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
似非サービスクラスの殺し方 / #ginzarb
GitHub - oro8oro/nomnoml-design-patterns
達人プログラマーとわたし/PragProg and Me
