デザインパターンはアンチパターンなのか

Gakuです( ゚Д゚)

最近、Go言語でシステムを一本作成し、「家宝は寝て待て!」状態でしたので、時間を持て余しておりました。
そこであまりにも暇だったので、GoFのデザインパターン23手を組んでみました。
それがこれです。
[blogcard url=”https://github.com/gaku3601/study-golang-design-pattern”][/blogcard]

Go言語が未熟なため、いろいろ試行錯誤が見えると思いますがあしからず。

さて、度々エンジニアの会話であがる「デザインパターンはアンチパターンであるか」問題ですが、少し考察してみたいと思います。

デザインパターンがアンチパターンであると主張する人の理由

1.最近の言語・フレームワークを使えば「デザインパターン」は必要がない

このように主張する人はいます。

確かにitaratorパターンなどはjavaであれば拡張for文、C#であればforeach文です。
itaratorパターンを理解せずとも、使用することが可能です。
また、FactoryMethodパターンでのDB接続なんかも(厳密にはFactoryMethodが使われているかは定かでないが、僕自身ならこのパターンを使用すると思うので)、フレームワーク上に組み込まれていれば「使用方法」を知っているだけで組むことができるはずです。

余程「大企業」でもない限り、各会社で「オレオレフレームワーク」を作成することはないと思われますし、業務を行う上ではこの主張は正しいと考えます。

2.わざわざ「デザインパターン」を勉強せずとも、普段の書き方で「デザインパターン」の何パターンかは実装している

このように主張する人はいます。

確かに、僕が今まで見てきた数少ない「業務システム」ですが、必ずと言って良いほどFacadeパターンが使われていました。
まぁ、オブジェクト指向を齧った人であれば自ずとFacadeパターンになると思うのですが、一応主張通り「デザインパターンを知らずともデザインパターンで実装している」という主張は正しいです。

業務を行う上ではこの主張は正しいと考えます。

3.デザインパターンで組んでいるコードは読めない人もいる

このように主張する人がいます。

確かに、デザインパターンと言わず、interfaceやabstractを使用し抽象度を上げるとコードを辿れなくなるため「いきなりコードが消失する」感覚に陥るはずです。
「システムはチームで開発するものです」「よって、プログラミング初心者でも読めるコードを心がけるべき」

業務を行う上ではこの主張は正しいと考えます。

反論

いや、まぁ、いいんだけどさ。

「それでいいの?」

って感じるわけですよ。
1の主張であれば「俺フレームワークなんて作らないし、今後も作る予定ないので。いいっす(*´Д`)」
そんな感じ。

2なんて典型的な「思考停止」している主張だし。
「Facadeパターン」しか使用してないってことは、それはデザインパターン23手の中の1手、つまり5%以下しか知らないわけだし。
良くそれで「デザインパターンの何パターンかは勉強せずとも書いている」と言えたものだなと。。。

極めつけは3ですよ。

「はい。3です!」

この主張する人は「デザインパターン」という言葉さえ知らない人が多いです。
読めないってwそれオブジェクト指向でさえ書いてねぇからw

おわりに

いろいろ書いてきましたが、確かに「デザインパターン」は古い技術であり、最近の関数型言語等々には合致しない点も多いかと思います。
ただ、今回Go言語で23手組んでみてGo言語での記述パターンの見通しが良くなったというか、気持ちよく書けるようになったのは事実です。

プログラミングにおいて
「書いてて気持ちいかどうか」
というのは非常に大切な要素だと思うので、結構鬼畜でしたが23手組んで良かったと思ってます。

デザインパターンをアンチ視する人もいることは事実です。
その際は「郷にいては郷に従え」精神でひっそり暮らします。

書籍「アジャイルサムライ」を読んだ所感

Gakuです。

巷で話題の「アジャイルサムライ」を遅ればせながら読破したので、その所感を書かせて頂ければと思います。
[blogcard url=”https://www.amazon.co.jp/dp/4274068560/ref=cm_sw_r_tw_dp_x_ILFBybRKQSXZM”][/blogcard]

結局のところアジャイルって何よ?

かねてからこのことが疑問でした。
一種のバズワードかと思っていましたが、本書ではアジャイルのことをこう述べられています。

・イテレーション毎に成果が出ているか
・改善のために日々努力をしているか
→これらを満たしているプロジェクトは全て「アジャイル」

ふむ。なるほどわからん!

イテレーション毎に成果が出ているか

「アジャイル」ではイテレーションと呼ばれる小さな開発工程を反復して開発を進めていきます。
ウォーターフォールでの開発では途中でプロトタイプを顧客に見せることはあっても、完成版を見せるのは全ての機能が実装してからです。
しかし、「アジャイル」ではイテレーションを「1週間~2週間」のスパンで設定し、その間で都度、完成版を顧客に見てもらうということを行います。

こうすることで「顧客からのフィードバックを瞬時に頂くことが可能」となり、方向性を見失わないようすることが可能です。
また、完成版を開示するので、真実を隠すことができない点が一番の違いになります。

ウォーターフォール開発を従事していた際に思ったことは「真実を隠す人があまりにも多すぎる」という点です。
例えば、進捗に遅れが発生していたとしても、顧客にその状況を知られてたくないがため(進捗遅れが露呈すると始末書の作成を迫られ、さらに工数が圧迫するため[日本の悪しき習慣])に、「プロジェクトは順調である」と発言する行為です。

「アジャイル」では完成版を2週間単位で顧客に見てもらう必要があるので、プロジェクトのありのままを伝える必要が出てきます。
辛いという意見もあるかと思いますが、真実を隠して良いことなど何もないので、「アジャイル」は理にかなっていると感じます。

改善のために日々努力をしているか

PMやPLの上流工程だけではなく、下流のプログラマなども自ら責任を持ち「改善のために日々努力する」ことを「アジャイル」では求められます。
(本を読んでいると「明確な役割分けは存在しない」的なことが記述されていたので、そもそも「アジャイル」には上とか下とか言う概念は存在しないのかもしれません。)

たまに「見積もり精度が甘すぎたためにプロジェクトが失敗したんだ!」的なことを言う人がいますが、「アジャイル」ではそれは完全にお門違いです。
見積もり段階にその発言をしたメンバーが居たのであれば、何故その際に声を大きくして「見積もり」について言及しなかったのでしょうか。

その段階で見積もりフェーズがクリアしているのであれば、そのメンバーも一度は頷き承認したはずです。
全てのプロジェクト関係者が「改善のために日々努力する」ことを行っているのであれば、そのようなことを発言することなんて出来るはずがありません。
そんなことを言う前に目の前にある課題に対して「改善のために日々努力する」ことの方がよっぽど大切であると感じます。
(まぁ、見積もりなんて変わって当然の心構えでみんな居ようぜw とも書かれてました。)

アジャイル開発のメリット

結局のところ「アジャイルの最大のメリットは?」と聞かれたら、僕なら「アジャイルサムライ」の中で使われている言葉で

「顧客の期待をマネジメントするために有効な開発手法である」
と答えます。

ウォーターフォール開発では、プロダクトを見せるのは完成した時になるので、簡単なものでも3ヶ月、長いものであれば数年後に顧客に見てもらうということになります。
そのようになってしまうと、顧客は「正常にプロジェクトが進んでいるのか」「投資としては妥当なものだったのか」という点を完成までの数年、ヤキモキした気持ちで見守ることとなってしまいます。
その点「アジャイル」は数週間単位でその都度の完成版を顧客に見てもらうということを行いますので、「顧客の信頼を勝ち得やすい」と感じました。

この点以外にも「アジャイル」のメリットは「アジャイルサムライ」に詳しく掲載されているので、興味のある方は参照頂ければと思います。

おわりに

日本の考え方ではまだまだ普及するのが難しい点が多いとも思える「アジャイル」ですが、僕としてはこの「アジャイルサムライ」という書籍をプロダクト制作者だけでなく、様々なプロダクト制作に関わる人に読んで頂きたい書籍であると思いました。
ただ、「アジャイル」にするためには、エンジニアスキルも多分に必要になってくるので、きたる「アジャイル開発文化」に備えてもっと勉強しないといけないと感じた一冊でもありました。

正直な感想、「アジャイル開発が浸透すると、世の大半のエンジニアが技術不足で死んじゃいます。」
今の僕のスキルでは余裕で死んじゃいます。
ただ、それが世界では普通と考えると、現状の日本企業のエンジニア力というのが如何に衰退しているかが見えてきた一冊でもありました。

システム構築屋から見る豊洲新市場問題

Gakuです。
久しぶりの投稿です。

仕事辞めてから暇で暇で仕方ないので、お昼のワイドショーを見まくっているのですが、豊洲新市場の欠陥問題がどんどん浮彫になっていますね。
そんな中、建築とシステム構築の炎上プロセスって同じなんだろうな~って感じたので、その所感をまとめたいと思います。

まずは豊洲新市場の問題点のおさらい

良くテレビでは「盛土されてない問題」ばかり取り上げられていますが、それ以外に様々な問題が上がっています。

・塩水禁止
・マグロが切れない
・側面が開くトラック未対応
・ヘアピンカーブ問題
...etc

とまぁ、いろんな問題があります。
詳しくは下記の記事を参照ください。
[blogcard url=”http://netgeek.biz/archives/81240″][/blogcard]
[blogcard url=”http://spinout-kj.com/shintoyosusijo-kekkan-4254/”][/blogcard]

ちなみに、総事業費は5800億円で東京スカイツリーは650億円なので桁違いなことがわかります。

システム構築屋がこの問題を見て思うこと

建築とシステム構築の開発手法は同様のもの(ウォーターフォール手法)が使用されており、システム構築屋から見た問題点はここじゃね?ってのをまとめてみます。

エンドユーザー?何それ?

豊洲新市場欠陥問題の登場人物は下記の三者で考えます。

・東京都・中央卸売市場(発注者)
・建設業者(受注者)
・漁業関係者(エンドユーザー)

発注段階

何を建設するにしろ、まず建設業者に発注を出さなければいけません。
発注は主にトップ層で行われるので漁業関係者は蚊帳の外の傍観者です。
【発注段階の図】
1
と、まぁこんな感じですね。
システム開発の場でも、既存システムの問題点はエンドユーザーから上がってきますが、作る作らないは経営層が判断することなので、末端のシステム使用者は「え?作んの?」っといきなりプロジェクトが発足することがほとんどです。

要件定義段階

建設業者は建設の発注を頂いたら期限付きで要件のヒアリングを行います。
【要件定義段階の図】
2
この要件定義段階は本当に重要な工程です。ここで期間を削減したりすると図のような状況になります。
重要な点は東京都・中央卸市場の発注者があまり漁業関係のニーズを把握していない点です。
もし、ここで期間を長くとって隅々まで問題点、ならびに漁業関係者のニーズを拾い上げていたとしたらここまでの問題にはならなかったかもしれません。
システム開発でもこのような場面が良くあり、そういったプロジェクトは破たんの道しか存在しません。
要件定義の段階では、建設業者は漁業関係者のニーズや現築地市場のことは何一つわかっていません。
この工程で「建設業者が全部やってくれるし、頑張ってくれな~」っと気楽に東京都・中央卸市場の方たちは考えていたのではないでしょうか。

設計工程

さて、要件定義段階があいまいな結果に終わりました。
「なんとなくいけるんじゃね?」な雰囲気でプロジェクトが遂行されていきます。
建設業者は要件定義工程で得た要件の内容から具体的な設計を起こしていきます。
そして完成した設計を元に御見積結果を提出します。
こんな感じで。
3
はい。御見積なんてこんなもんです。
50階構想ビルの建設をこの会社は過去に何度か建設した実績があったとしましょう。
御見積は過去の実績を元に算出するため、新しく50階構想ビルを建設するといったことであるならば、正確な御見積を算出することが可能です。

しかし、市場の建設は初めてのことだったのでしょう。
そういった場合、何もわかりませんので安全工数と題し算出した御見積*2倍とかで御見積を顧客に提示します。
もし、プロジェクトが破たんした時にどうとでも修正できる金額は欲しいですからね。
(また、顧客が価格交渉をすることも踏まえ2.5倍ぐらいで出しているかも知れませんね。)
そうやって、どんどん御見積金額が膨らみ顧客へ提示します。
4

はい。設計後の御見積結果を見ても発注者なんてこんなもんです。
何も考えずにはんこぽ~んです。
全てがあいまいなままプロジェクトが遂行していきます。
東京都・中央卸市場は金額が高額なせいか建設業者を信頼しきっており、かつ、建設業者は「東京都・中央卸市場が言った要望は全て入れた!」の精神ですので、問題点なんて上がってくるわけがありません。
このプロジェクトで漁業関係者のことを考えている人なんて誰もいないのです。
もし、この時に東京都・中央卸市場の関係者が少しでも漁業関係者にヒアリングする期間があればこのような結末にはならなかったかもしれませんね。
まぁ、建設業者が事細かく設計内容を説明するわけでもないですし(事細かく説明して突っ込まれるの面倒ですからね。)、東京都・中央卸市場の関係者が問題を把握しろ!っていうのは横暴な気もしますが。。。

建築工程

晴れて設計もOKを頂けましたし建設業者は実際に施設を建設していきます。
この時、豊洲新市場建設事業は長期間の建設事業ですので、東京都・中央卸市場に安心してもらうために中間報告を逐次提出します。
その際、問題が多発するわけです。
5

はい。東京都・中央卸市場はこの機に及んでも毎回要望を出してくるわけです。
実際の建築物を見て、東京都・中央卸市場は不安になったのでしょうね。
漁業関係者に「こんな風になってるんだけど大丈夫?」とやっと聞きだしたのはいいのですが、この時点ではすでに遅しです。
設計が完成しているので、一つの施設を変更するのに多大な金額が必要になってきます。(一つの施設の設計変更で他の施設の設計も見直さないといけませんからね。)
まぁ、建設業者もクライアントが「必要」と言っているものは無視できませんからね。
できる限り設計を見直し建設を進めていきます。
その心境に付け込んで、お金に糸目の無い東京都・中央卸市場は言ったのでしょう。
「盛土とかもったいなくね?地下空間有効活用しようや(ドや!)」
こんな感じで盛土もなくなったのでしょう。

建設工程時点で設計の見直しをすることは想定していないので、いろんなところで問題が発生します。
問題点を建設業者は報告はしますが、何も考えていない東京都・中央卸市場は「お、そんなんでええんちゃうか」でプロジェクトが進んでいくわけです。
地獄絵図ですね。。。これが豊洲新市場欠陥問題の顛末だと考えています。

おわりに

まぁ、あくまで想像の話ですし、僕も豊洲新市場のことを詳しく調べたわけではないので、本当のことはわかりません。
ちょっと前に地元の建築業者の社長さんと飲む機会があり、いろいろお話を聞かせて頂いたのですが、
「どうしてこうも高い金額を払ったのに使いにくいシステムになるのか見当もつかない。今までに2度も作り直したが、本当に使いづらい。今回は期間も伸ばしたのにもっと使いづらくなった」
と話していらしたのを聞いて、この記事を書こうと思いました。
今回は豊洲新市場の件で炎上プロセスについて解説しましたが、これはシステム開発でも同じです。
システムを外注しようと思っている経営者の方に、少しでもプロジェクトの進め方の心構えを考えて頂ければ幸いに思います。
SIerに救いを。。。

rubyでデザインパターンのtemplateパターン試してみた

Gakuです。
rubyでtemplateパターン記述する場合どうしたら良いのだろうと思い、勉強した備忘録を残します。
(※エセtempleteパターンです。)
うん。rubyやめたくなった。

実装

題材はなんでもいいやと思ったので「声優」と「平社員」の場合の飲みの場での動作を記述してみました。
まずは抽象クラス

#動物の人間を作る
module Animal
  class Human
    #飲み会の動作を実装
    def drinking_party
      puts "--歌って--"
      sing
      puts "--しゃべって--"
      talk
      puts "--飲む--"
      drink
    end

    def sing
      puts "---"
    end

    def talk
      puts "---"
    end

    def drink
      puts "---"
    end
  end
end

歌って、しゃべって、飲む動作だけを記述します。

【具象クラス】
声優の飲み会での振る舞いを記述します。

require './animal.rb'

class FemaleVoiceActor < Animal::Human
  def sing
    puts "かわいい声で歌い"
  end

  def talk
    puts "かわいい喋り方でアニメキャラを彷彿させ"
  end

  def drink
    puts "かわいい飲み方で誘惑する"
  end
end

抽象クラスを継承して、各メソッドをオーバーライドしてあげる。
ついでに同じように平社員の飲み会での振る舞いも記述します。

require './animal.rb'

class LowlyEmployee < Animal::Human
  def sing
    puts "上司とかぶらないように歌の選曲をし、受けを狙った歌声で歌い"
  end

  def talk
    puts "上司に気をつかいながらしゃべり"
  end

  def drink
    puts "下座で飲まず幹事を務める"
  end
end

世知辛い世の中っす( ;´Д`)

最後に適当にこれらを呼び出すます。

require './animal.rb'
require './FemaleVoiceActor.rb'
require './LowlyEmployee.rb'

#女性声優の飲み会
puts "【女性声優の場合】"
voiceActor = FemaleVoiceActor.new()
voiceActor.drinking_party

#平社員の飲み会
puts "【大企業平社員の場合】"
lowlyEmployee = LowlyEmployee.new()
lowlyEmployee.drinking_party

実行結果はこんな感じ

[vagrant@vagrant-centos65 template]$ ruby main.rb
【女性声優の場合】
--歌って--
かわいい声で歌い
--しゃべって--
かわいい喋り方でアニメキャラを彷彿させ
--飲む--
かわいい飲み方で誘惑する
【大企業平社員の場合】
--歌って--
上司とかぶらないように歌の選曲をし、受けを狙った歌声で歌い
--しゃべって--
上司に気をつかいながらしゃべり
--飲む--
下座で飲まず幹事を務める

まとめ

完全なるエセtemplateパターンです。
rubyにはabstractがないようなので、強制オーバライド制約を付けれません。(やり方あるけどめんどくせぇ)
うん。rubyでデザパタ使わなくても良いよ〜ってことなのかな?
わかんねぇっす。かっちりしたの書きたかったらjavaかC#とかそこらへん触れってことだな( ;´Д`)

カチンと来たのでデザインパターン勉強まとめ(メモ程度)その4

最後になります。

パターン

Stateパターン

状態に応じて返答する際に使える。
状態変化はif文でやっちゃうと追加の時に対応できないので、stateパターン使えばどんだけでも追加、削除対応できる。

Flyweightパターン

リソース関係で困ったときに見とけ。
シングルトンの進化版。
複数になった感じ。

Proxyパターン

代理人をたてて、そいつのまかせる。
分からないとこだけ代理人じゃなく本人がやる。

Commandパターン

処理手順を記述するクラスと、処理する部品を記述するクラスを別々に記述。
コマンドをメインで呼び出すことで処理手順ばらばらにできるを実現するパターン。
めっちゃ好き。使える。

Interpreterパターン

構文木の解析実行パターン。
動詞となる部分が複数回出てくる場合まとめることができるので、使いまわしできるよね?
って感じで使いまわしする感じ。

おわりに

とりあえず、おわった。
あとは書籍2冊読み込む。あと手を動かせば大丈夫だろう。

参考文献

http://www.techscore.com/tech/DesignPattern/index.html/

カチンと来たのでデザインパターン勉強まとめ(メモ程度)その3

その3です。
GoFがGod of Fourに感じてきた。

パターン

Decoratorパターン

メソッドの拡張パターン。
バニラアイスクラスにトッピングとしてカシューナッツを加える時などに有効。
あくまでメソッドの拡張。メソッドを新たに加えるといったことはない。

Visitorパターン

なんかいろんなところで依存している気がする。
あんま使わない気がするのでいったんスルー。
あとで勉強する。

ChainofResponsibilityパターン

「責任者」を「鎖状」につないでおき、「いずれかの段階」で、「誰か」が処理をすることを表現するようなパターンです。

Facadeパターン

既に使っている気がする。
窓口を設定して、その人に聞く。聞いたら帰ってくる。ただそれだけのパターン

Mediatorパターン

仲裁人パターン。複数のクラスの状態を把握し、何をするか決定するパターン。
ボタンAとボタンBが押された時を把握し、何かするといった時に使えそう。

Observerパターン

状態の変化に応じて通知を受けるパターン。
自分の考えでは、ダウンロード処理して終わった時に通知ぃいい!
ってなるのに使うパターン?

Mementoパターン

Memento パターンでは、必要な情報のみを保持しておき、必要なデータのみを復元することを考えます。
tempをつくって保持するだけの簡単なパターン。

おわりに

あと5パターン。明日早起きできれば明日で終わらしたい。

参考文献

http://www.techscore.com/tech/DesignPattern/index.html/

カチンと来たのでデザインパターン勉強まとめ(メモ程度)その2

その2です。
Compositeパターンまでです。

パターン

Builderパターン

作業過程は同じだが、素材を変えたいといった時に使えるパターン。
塩水の%を砂糖水でやりたい時などに有効。
結構強そう。

AbstractFactoryパターン

例えば、何も考えずに実装していると、車のタイヤに自転車のタイヤを使用してしまう可能性がある。
そういった場合の事故を防ぐために、使うものを定義し事故を防ぐのがこのパターン。

Bridgeパターン

機能追加部分と実際の実装部分を切り分けることができる。
小さい機能をいっぱい作る時に有効っぽい。

Strategyパターン

アルゴリズム実装と実際の実装を分離し、煩雑にならないようにするパターン。
これ使ったらBuilderは使えなさそう。

Compositeパターン

ポリモーフィズムの典型的パターン。
例えば、ファイルとフォルダがあり同じように削除したい場合、
ファイルとフォルダを同一視し削除を楽にすると覚えておけばOK。

おわりに

土曜日も勉強してればよかった。
StrategyパターンとBuilderパターンは使えると思ったので積極的に使っていこうと思います。

参考文献

http://www.techscore.com/tech/DesignPattern/index.html/

カチンと来たのでデザインパターン勉強まとめ(メモ程度)

Gakuさん、偉大なる4人のギャングが作った神の定石を習う。
会社で「デザインパターン知らないなんて小学生までだよねww」っと煽られてカチンと来たので、久しぶりにVSダウンロードしてC#で勉強してみました。
とりあえず6パターン。
教材は結城先生のデザインパターン入門+TechScore[デザインパターン]
結城先生はこの本の他に「数学ガール」の著者でもある人。世の中すげ~人はすげ~な~と思いつつ読んでました。

パターン

Iteratorパターン

現在の言語にはeachとかforeachとかあるので使用する機会はほぼなし。
知識だけ持ってるだけでOK?

Adapterパターン

責任を負うことができない太郎、花子の尻にひかれる。俺みたいやなって。
Adapterパターンはそのままでは使えないメソッドなどで、ひとつかましてあげることで使えるようにするパターン。
.NetのNativeライブラリとかを使用する際、アダプター作って使用するみたいなことができる。

TemplateMethodパターン

テンプレートを定め(abstract)それを継承して使うだけの簡単なパターン。
ファクトリーメソッドパターンの前知識みたいなもの。

FactoryMethodパターン

インスタンス生成をサブクラスに任せる。あとはテンプレートメソッド

Singletonパターン

コンストラクタをprivate staticにして外部からnewできないようにする。
インスタントは1つしか生成しないことを保証するパターン。

Prototype パターン

同じインスタンスをいっぱい作るときに使うパターン。
ちょっとずつ違うインスタンスをいっぱい作るのにも使える。

おわりに

今日はここまで。全23パターン。なかなか骨が折れる。
ただ、神の考えに触れている気がしてすごい楽しいのは確か。あとは実務で使えるだけの発想を鍛えるために使う努力をしないとって感じです。

参考文献

http://www.techscore.com/tech/DesignPattern/index.html/