isyumi_netブログ

isyumi_netがプログラミングのこととかを書くブログ

僕が設計だと思うもの

設計について

自分はソフトウェアの設計を担当している。
ところで、会社によって設計という業務の指す範囲が異なると思う。
ただ『設計をしている』というだけでは、自分の持つスキルが伝えられないのではないかと考えた。
そこで、自分が実際にどのような作業をしているのか、そして、どのような考え方をもってその作業に当たっているのかを記そうと思う。
ここで言うソフトウェアの設計とはビジネスの設計やプロジェクトの設計の話ではない。よって、ビジネスモデルや人員配置というような話ではなく、狭い意味のソフトウェアの設計の話だと思ってほしい。

信念

  • 設計通りに作って動かなかったら設計した人が悪い
  • 設計に解釈の余地があったら設計した人が悪い

設計書と称して何を読み取ればいいのかよくわからないポンチ絵を作って満足している人が多いようだ。
しかも、えてしてそのような人は「上流工程」と呼ばれて、その人の仕事の不出来を下位団体に気軽に押し付けられるようだ。
それでは仕事をしたことにならないだろう。
「設計した」というのであれば、そのとおりに作ったら意図したとおりに完璧に動くべきだ。

具体的にやっていること

これを決めている。

  • RDBスキーマ
  • Redisの型
  • サーバーサイドプログラムのモデルの型
  • RESTの型
  • フロントエンドのモデルの型
  • フロントエンドのビューモデルの型
  • フロントエンドのURLと画面の対応
  • IndexedDBの型
  • その他各種DIしなければいけない副作用の型

Redisの型とは、RDBとRESTを見比べて、どんなキャッシュがあれば全てのRESTの処理を現実的な計算量に出来るか考えるということも含む。
RESTの型の中には、各エンドポイントの権限とCDNの設定を含む。
IndexedDBは、WebフロントエンドではなくAndroidアプリやiOSアプリの場合はSQLiteになる。
DIの型というのは、例えば乱数や現在時刻のことだ。

核心の技術

僕は、「ある対象を見ると、その型を正確に言うことが出来る」という特技がある。
例えばこのツイートの型を考える。

f:id:isyumi-net:20200815140256p:plain

まず、アイコンのURLが必要だ。

表示名(日本語の所)とユーザー名(アットマークで始まる所)はそれぞれstringだ。

日付は、「10秒前」「5分前」と言った表記になることがあるので、モデルではDate型だが、ビューモデルではstringである。

また、この日付をクリックするとそのツイートのURLに飛ぶので、TweetIDを整数型で持つ必要がある(言語によってはintに収まらないので注意)。

本文もモデルとビューモデルで異なる。モデルはstringでいい。ビューモデルは改行やハッシュタグやメンションに対応しないといけないので、「通常のテキスト」「ユーザーID」「ハッシュタグ」の代数的データ型の配列の配列が正解のようだ。

その下は画像だ。画像は複数枚上げられるのでimg型のリストである。img型には画像サイズと表示領域から計算したトリミングの情報などを入れておくと画面を作りやすい。

めんどくさくなってきたのでこのくらいにするが、他にもいいね数や引用ツイートや右上のプルダウンメニューの開閉なども型に落とし込んでいける。

僕は複雑なシステムでも短時間で間違えずにこれを全て書き出すことが出来る。
これが僕の核心になる技術だ。
実は結構簡単。

これはなんなのか

要するに、GoF本などで主張されてきた『インターフェースに対してプログラミングする』ということである。
これをシステム全体に適用するということだ。
一つの大きなシステムを各部品に分け、その接合部を事前に全て決めてしまうということだ。

なぜいいのか

こうすることで、各部品が粗結合になり、コードが綺麗になる。
複数人で同時に作業できるようになる。各作業員の仕事は、ある型からある型に変換する純粋関数を書くだけになり、考えることが減る。
何が正解で何が間違いかはっきりするので、テスト駆動開発ができる。
他人の指導もしやすい。

大工さんが家を建てているとしよう。
一人の大工さんが一階を組み立て、もう一人の大工さんが二階を組み立てている。
この時、もし一階の大工さんも二階の大工さんも、それぞれ一階と二階の図面を見ながら作業を進めれば頑丈な家が建つのが理想である。
逆に、一階の大工さんと二階の大工さんが密に設計を相談しながら仕事を進めないといけないなら、手間だし本当に頑丈な家が建ったのか怪しい。
だから、工務に入る前に誰かが設計を確定させておかなければならない。
ソフトウェアの設計も同じである。

何ではないか

例えば、これらは設計の範囲ではないと思う。

もしかしたら一般的にはこういうことの方が設計と呼ばれているかもしれない。
しかし、僕はこういうのは設計とは言わないと思う。
これらは、ベストプラクティスやその会社の慣習が確立していることなので、どちらかといえば設計と言うより日頃の行いの問題だと思う。
また、インターフェースを満たしている限りそこを自由にすげ替えられるということが重要なのであって、そこを決めるのが対して大事な仕事だと思えない。

想定される反論

それはウォーターフォールの考え方だ。我々はアジャイルなのだ

短いサイクルで機能変更を繰り返していくからといって、ある瞬間には実現したい機能要件というのが確定しているはずで、そうであれば設計は出来るはずである。
短いサイクルで設計を更新して、それに合わせて実装も更新すればいいのだ。
短いサイクルで変更されるからと言って設計が出来ないとか設計が不要というのはおかしい話だ。

設計が終わらないと開発できない

それでいいと思う。
熊とワルツをに書いてある。
僕は自分が設計している間、他の人が手空きになることを全く問題だと思っていない。

僕がいるとどうなるか

  • 開発スピードがとても上がる
  • 入出力を整理しやすくなり、セキュリティを高めやすくなる
  • システムを変更したときにおかしくなりにくくなる
  • 少々スキルの低い人が混じっても大丈夫になる

まとめ

だれかお金ください。