blog

日常・技術のことを記録する

設計って最初にぜったいやらなきゃだめ？

技術その他

個人開発で無理やり設計書っぽいものつくろうとして(plantUMLとか使ってかっこつけたかった)、メンターにそんなんいらんよって言われた話メモ
モデル図はぜったい必要？コード構造の設計はどうしたら上達するか？などなど

設計はかならずしも必要ではない。

家を建てるのにいろんな設計あるでしょ？
柱どこに建てるとか、電線はどこを通すとか。
それぞれ別々の設計の粒度があって、具象的な設計は抽象的な設計の上でやられるもの。
アーキテクチャはプログラムの設計において一番抽象度の高い部分になる。
じゃあハムスターの家を大工が作るのに、詳細な設計を必要とするかと言われればNoだし、ハムスターの家をうまく設計できたら住宅の設計も上手くなるのか、と言われればそれもNoだ。
規模が大きければ大きくなるほど、抽象度の高い設計が重要になるし必要になる。
モデル図はその抽象度の高い設計をするもの。
だから小さいものを作るのに無理やり設計しなきゃ！と思ってモデル図書いたりアーキテクチャに当てはめたりしてもあまり上達はしない。
少なくとも１人月くらいかかるものを作っていかないとね。

モデル図（ダイアグラム）が必要なときはどんなとき

モデル図とは、あくまで自分の考えをアウトプットするためのもの。
設計の抽象度によって流動的に変わるものだから、こういうシーンではこれが正解というパターンは存在しない。
オーディエンスがいるなら一般的な図を使うし、
いなければオレオレモデルを使えばよし。

つまり、モデル図を作成すべきシーンは
・自分の構想を洗い出したいときに好きな図を使う
・クライアントに求められた時に指定された図を使う

アーキテクチャってなーに

優れたコード設計の共通要素を一般化したもの。
10000000000000行のプログラムをどう分割してどういう責務にわけて、どのようにグループ化するか、という考えがアーキテクチャ。
膨大なプロダクトが綺麗に見えるのはアーキテクチャ

デザインパターンってなーに

コードの書き方のお決まりパターンのこと。
コードが綺麗に見えるのはデザパタ。

実装するときの心得

アーキテクチャから逸脱しないように実装する。
コード構成の基本的な考え方を踏襲すれば、酷いコードにはならない。

コード構造の設計を上達するためには？（応用編）

プログラムのアーキテクチャを覚えて、同じものを複数のアーキテクチャで書いてみる。
これはプログラミング言語の勉強でも同じで、新しい言語を覚える時は過去作ったものと同じ動作をするものを新しい言語で書いてみること。
アーキテクチャや言語の勉強でこれやると、選択によって変わった部分＝選択によって受けられる恩恵だったりデメリット、になるから、作るものによって適切な言語を選んだり、アーキテクチャを選定出来るようになって、設計が上手くなる。
アーキテクチャを完璧に踏襲すればプログラマの設計は、言語の選択、アーキテクチャの選択、フレームワークの選択、デザインパターンの選択、ライブラリの選択、プロトコルの選択でといった、「何を使うか」に絞られていって、「どういう構造にするか」という設計が入る余地はデータ構造(RDBかKVSか、ファイル保持かDBかなど)のみになる。

感じたこと

構想を洗い出したい、アウトプットしたい、って感じたときにはじめて作ればいいのね。
必要性も感じてないのに、最初から無理やり設計なんてしなくていいってことか。
ちょっとテクニックに走ろうとしてしまいがち～。反省反省(･o･)💦