ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

ホーム > コミュニティ > PC、インターネット > システムエンジニアの部屋 > ソフトウェア設計のあるべき姿

ログインして参加する

このコミュニティに参加するにはログインが必要です。

ソフトウェア設計のあるべき姿

ソフトウェア設計のあるべき姿 2016年11月24日 11:01
mixiユーザーmixiユーザー
ソフトウェア設計については例えばドメイン駆動設計(DDD)のような方法論が知られていますが、
実際の開発においては
設計段階で整理された理想形はほとんどの場合、改めて実装上MVCフレームワークのような別の設計手法にすり合わせる必要があり、
そこで生まれた奇妙な歪みが、実装のシンプルさ、可読性、再利用性、メンテナンス性を下げる原因になっているような気がします。

例えば、汎用性のないメソッドはMVC上のどこで定義するべきであるかという場面で、
ある規約の上ではそれはモデルに記述すべきとされ、また別の規約の下ではコントローラ、
あるいは汎用性がなくてもライブラリ化すべきだとなったりする。

ビジネスロジックのシンプルさを保つために、複雑化した粒度の細かい具体的な演算を
どこかに外だしするという時に、その巻き取り先をどう配置すべきでしょうか。

このような必ずしも明確でない揺らぎは、メンバー間のコードの粒度や整理の仕方の整合性を奪ってしまい、
あるべき姿が見えないために読解やメンテのコストを上げて開発プロジェクトの無秩序さに影響を及ぼしているように思えます。

これは一言でいえば外部設計と内部設計の間で思想の食い違いが起きているところに原因の発端が
あるように思えるのですが、
なぜ、上流工程では実装上のフレームワークの設計思想との整合が議論されることが少ないのでしょうか。

コメント(27件)

[1]2016年11月24日 12:10
null安全かどうかみたいな議論が紛糾しているらしいと聞いたけど、それってようするにオブジェクト指向言語が危険なんだよって事じゃないか。C++じゃないCには、nullというものがそもそもない。
[2]2016年11月24日 12:14
ポインタのほうがnullよりも危険だし、
null安全かどうかを議論するのは、そもそも根本的には、ポインタの危険性の問題を高級言語が
どのようにカバーしきれなかったかの
バグの問題なのかもしれないみたいに思いますけれども
[3]2016年11月24日 12:15
Cにnullってなかったっけ?
あったような気がしたけど。。遠い昔だからうろ覚えだけど。

あ、お久しぶりです。
[4]2016年11月24日 12:41
>>[3]

どうもです。
調べてみたらありました。
でたらめですみません。

ぬるぽの印象から、
データ構造の中に変数や関数を持つオブジェクト指向言語特有の問題だと勝手に飛躍して考えてしまっていました。
(基本データ型しかなければ問題は起きえないのかなと)
[5]2016年11月24日 12:53
>>[4]

了解です。

ところで、表題の件ですが、自分はライブラリ派かなあ。責務の問題として、専門ロジックは外出しにするのがいい印象。
DB使う時とかなんかにモデルに専門ロジック渡すケースとかもあるんでしょうけどねー。。特殊条件のデータ取得の時とかは特に。でもモデルさんにはあまり複雑なことはさせたくないかな。ラッパーかまして編集やまとめくらいなら考えられるけど。
[6]2016年11月24日 13:11
>>[5]

なるほどそうなんですね。
自分はDBと関わる部分しかモデルに書かないという感覚でいたので
直近の仕事で
DBと関わらないロジックまでモデルとして組むという作法に直面してウーンと思ったりしました。

ただ、その作法にも一貫性はあって
他の部分も含めてそれはそれで潔い形になるようでもあり、
それを正として抵抗なく受け入れる事さえできれば可読性は高いのだろうなとも思いました。

粒度の細かい部分はおっしゃるようにライブラリのほうに整理するのがいいんだろうなと
最終的には思いました。

書籍なんかにでてるようなコードは大体どれも似通った作法で書かれるわりに
実務で遭遇するコードはどれもそれぞれ同じ言語とは思えないほど違いがあって
設計思想そのものが
それぞれの言語ごとにすり合わされてくれるといいのになあとか思ったりしました。

ある種のフレームワークが強制してくる縛りが
そういう役割を果たそうとしているのかもしれませんが
なぜそうすべきなのかを納得できる説明もありつつの縛りであればそういうのでもいいかなと思えたりしている昨今です
[7]2016年11月24日 18:50
モデルを広義に論理データのエンティティみたいな扱いにして、エンティティの属性を算出させるためのロジックをモデル(エンティティ)に持たせるって線なら、そこまでおかしな設計とは思わないかも。
癖が強めの設計とは思うかも知れないけど。

個人的な感想。
[8]2016年11月24日 18:57
>>[7]

なるほどそうなんですね。
ムーン。
[9]2016年11月24日 19:06
あ、細かい思想とかあんまり知らないで言っているので、話半分で聞いてくださいね。

けっこう自分の感覚で言っています。汗
[10]2016年11月25日 02:30
>>[9]

どんなんでもそうだけど、
やっぱり高尚なドキュメントも結構だけど
シンプルでストレートな感覚で分かる
変に時間のかかる理屈っぽさはなるべく排するってほうが
いいような気はする。

それでどうやって合意を確認しあえるかは
なかなか難しいけど
単純なほうがいいものを複雑にしなくてもいいですよねー。往々にして
[11]2016年11月25日 09:00
>>[10]

それはその通りだと思います。
でも次に来るのは、どういうプログラム構成で整理していくかってことなんですよね。表題に戻るけど。

シンプルでストレートで分かりやすい整理だったら、ぶっちゃけなんでもいいっちゃなんでもいいんですよね。
[12]2016年11月25日 11:52
>>[11]

そうですよね。例えばMVCでいくぞーとなった時、
MVCでいくことを決めただけでは、例えばまだそれぞれのControllerを
何単位で分けるかみたいな粒度の部分が
決まっていないのでそれぞれメンバ間でちょっとずつ整合性がとれなくなるかもしれず
粒度の細かさとかは
こういう感覚でやるぞー
みたいなことがなんとなく共有されているといいのかなーと。
[13]2016年11月25日 12:41
しかし、みずほ案件っていまだに終わっとらんのですかぬ。
それだけ業務が複雑なのかもしれないけれど
複雑な業務を複雑なままシステム化するのではなく
システム化する前の作業を効率化した上で
さらにシステム化する上でのシンプル化も挟んで、
その上で実装すりゃいいんではないですかぬ。

そういう風になってるんでしょうかぬ。
[14]2016年11月25日 12:46
正直、みんな長引いてむずかしくこじれたほうが、
その案件で長く食えることになって関係者も、みずほのシステム担当者も、内心メリットあるよね。
みずほの非システム担当者、そしてみずほの利用顧客が割を食うだけの話になっている。
実はそういうわけなんだけど、これは
みずほさんに限らずどのような会社の業務であっても同じようなことが言える。
システム化などするな、IT化などやめてしまえ、いらんことしてカネもっていくな、
という目線で見られながらやっているのではないかと思うけど、そう思われて当然のことしかやってないという。

斜に構えると、そうなる。
[15]2016年11月25日 13:37
メシだけ食える不毛な案件なんて、誰も受けたくないと思うけどね。。
やだよ怒号と恫喝がはびこる殺伐とした現場なんか。

経験的に、殺伐とした現場ほど独身者が多いよ。そりゃ結婚する気にもならんでしょうしね、気持ち的に。
伸びやかな現場の方が成婚率も高いですしね。長くエンジニアやる気なら、そういうのが必要だと思う。
[16]2016年11月25日 14:06
>>[15]

なるほどなるほど。
確かに、既婚者の割りあいで見ると色々比較できますね。
平均年齢とかも。
[17]2016年11月25日 14:23
なんかこう
とんでもなく高難度な案件になればなるほどスキルを求められていて
スキルが高まるんじゃないかという気がするにもかかわらず
実はその高難度の原因は
極めてスキルの欠けたメンバーだけでやろうとしてあらゆる種類の間違いでむずかしくなり
失敗にむかっていくということが多いんだろうか。

すごいスキルのメンバーが集まっていると、
何もかもが瞬時にエレガントに片付いて、優雅に麗らか、気品と風格あふれる品質になって定時に帰れるのかな
[18]2016年11月25日 16:18
自分は自分が定時で帰るに必要そうなスキル身につけることにしか関心持たないから、それくらいならある程度は自力でなんとか身につくと思う。

華麗で優雅なシステム開発の現場があったとしても、定時で帰れるようにするのは基本的に自分だしね。。
[19]2016年11月25日 16:32
フムフム。なるほど。

自分が思うに、

超人的なスキルをもっていてサーカス団みたいに不可能を可能にする現場だけではなくて、

すげーしょうもない大したことない案件を
宇宙開発プロジェクトかなにかのように大げさに誇張して超大変でカネかかりますと主張して
すごい予算をゲットしてしまえば

なにかスキルなくても
やることないし納期も何年も先なんで毎日定時で帰れる、
みたいなことになるんじゃないかなーとか
[20]2016年11月25日 16:35
↑その時に必要なスキルとしては、誰にもサッパリわからない難解不可思議なお経ににたドキュメントとか
大変ありがたい肩書をもったタレント級のトークスキルの芸人とか
きわめて融通の利かない制度とかだな、と思う。

そういうもので、すごい納期と予算を、反論の糸口をみつけられないようなケムに巻き巻き
[21]2016年11月25日 16:50
いかにして新しい造語を生み出し続けるかということ
いかにして値下げ交渉がむずかしい複雑怪奇な見積もりを出すかということ
いかにして納期を伸ばす必要があることを反論の隙の無いパワフルな言葉で主張できるかということ
この辺のテクノロジーを探求するのが
SI産業だ!
[22]2016年11月25日 16:56
それは、横からやっすいSIerがかっさらっていくパターンだと思うんだ。。
[23]2016年11月25日 17:13
そのとき、いかにしてシステムを死守するか

その時の切り札として

駆使されている言語が、 COBOL!!
[24]2016年11月25日 17:27
コボルがポジティブ。

コボルポジティブ。
ポジティブコボル。
[25]2016年11月25日 17:36
[26]2016年11月25日 18:07
[27]2016年11月27日 17:37
Kotlinという言語が、Javaのスーパーセットみたいでいいらしいと。
実際に使われ始めている感じなんでせうかね

ログインすると、みんなのコメントがもっと見れるよ

コメントを書く (*の項目は入力必須)

システムエンジニアの部屋のメンバーはこんなコミュニティにも参加しています

メンバーが参加している他のコミュニティを自動的に算出して表示しています。星印の数は、共通して参加しているメンバーが多いほど増えます。

システムエンジニアの部屋

人気コミュニティランキング