プログラマーに求められるデザイン脳

「デザイン」じゃなくて「デザイン脳」です。いわゆる「Webデザインもできなきゃね」という話ではなく、

普段のプログラミングの中でも、Webデザインと同じような脳みそを使うことがある

というお話。

プログラマー (エンジニア) は、一般的な先入観として「計算能力」...というか、ここでのニュアンスとしては、

「パズルを解く能力」(言葉が見つからなかった...)

が必要と思われることはあっても、あまり「デザイン能力」が必要だとは思われてないように思えます。

「動きを実現する選択肢(かたち)が一つしかない」とかであれば、もはやデザイン性はあまり関係ないかもしれませんが、昨今は特に、動きを実現するための選択肢は増えているので、プログラマーも「デザイン脳」を、意識して鍛えていく必要があるだろうと考えています。

様々な場面があると思いますが、ここでは大きく五つ挙げてみたいなと。

1. 命名デザイン
2. 構造デザイン
3. コメントデザイン
4. DBデザイン
5. アーキテクチャデザイン

1. 命名デザイン: メソッド名、変数名など

最初に、あまりに当たり前でありながらいつまでも問題を抱える領域、「名前付け」です。これもれっきとしたデザインです。

だからこそ、いつでも問題を抱えるのでしょうと。

どれだけ構造が良くても、簡単にプログラムを負債に変身させることができるのが「名前」です。

一般に、わりと苦手なプログラマーも多く、「規約を設けてあまり考えなくてもいいようにする」ことが多いです。

それはそれで、プログラマーの "頭CPU" の節約という意義はありますが、デザインすべきところで "逃げよう" とするのもよくありません。なぜなら規約作り自体がとても難度の高いデザインであり、完璧な規約というものは存在しないからです。(規約というのは複雑なケースバイケースに対応できない)

非常に個人差の激しいところですし、正解がないから人によって変わるからなお難しい。

ひとつ、大きなコツを挙げるとすれば、これです:

名前を付けようとしているものだけを見て、その名前を付けることはできない。

つまり、

"周りの名前" や "全体の中の位置付け" を把握して、初めてその名前を付けられる。

名前って識別子ですから、極端な話、一つしかないのであれば、(例えば、システムの中にクラスが一つしかなかったら...)名前を付ける必要もあまりないかもしれません。たくさんあるから名前を付けて識別したいわけで。

単純に統一性という面もあるし、統一性よりも優先する特殊な要件があったとしても、やはり周りの名前の付け方に影響はされるはずです。

この基本を忘れて「こうだ!ああだ!」と言ってても、何も良い名前は思い付かないし、それが良い名前なのか悪い名前なのかの判断もできません。

// 任せられるディベロッパー、七つの姿勢
http://d.hatena.ne.jp/jflute/20170405/reliableseven

の「その四: 全体を把握しようとする」の姿勢がない人に、名前付けを任せることはできないわけです。

2. 構造デザイン: クラス構造、メソッドシグネチャなど

ここは説明するまでもないところかもしれませんね。

別に、ひとつのクラスでベタッと書いても動くは動くわけですが、でもそうしないのは...そのソースコードに触れる人が "コードのかたち" で効率が下がる、という問題を抱えるので、その問題を軽減するためのデザインが必要なのです。

ここでも大きなコツが一つ。

人のことを考えないと構造デザインはできません。

人がそれを見て解釈する、人がそこに後から手を加える、だからデザインが必要なのです。
つまり、

人のことを考えて初めて、良いクラスやメソッドを考えることができる。

プログラマーは、実は人のことをよーく考える職業でした。先入観と違いませんか?

そしてそれは、そんな簡単なことではありません。

jfluteも、オープンソース活動(DBFlute)の中で、数え切れないほどクラスをリファクタリングしたり、メソッドのかたちを変えたりを繰り返してきました。こうだとこう、ああだとこう、DBFluteユーザーのこと未来の自分のこと、いっぱいいっぱい想像して四苦八苦しました。他のツールのソースコードもたくさん読んできました。本も色々とたくさん読んで理論も学びましたが、その実践があってこそ活かせるものでありました。

そこまでやって、ようやっと見えてくるものがあるなぁと、「修練には非常に時間を費やすものである」というのを実感しています。

そりゃそうなのです。「これは知識ではなくデザイン力である」打ち方がわかればホームラン打てるわけじゃないのと全く同じ。

3. コメントデザイン: JavaDoc, DBコメントなど

JavaDocってどう書けばいいですか?」
「DBコメントってどんなこと書けばいいですか?」
相談されることがよくあります。

ある程度は、JavaDocなら @param, @return など、そういうのに沿って書けばってのはありますが...そこに何を書くか?フリーテキスト欄に何を書くか?やはりレールに乗らずに思考しないといけない部分はあります。さらに、こんなこと書こう、あんなこと書こう、という方法論的なものはある程度はあります。

ただ、究極は...

何が書いてあったら読む人が嬉しいのか?を考えないと良いものは書けない。

なぜなら、JavaDocやDBコメントなどは、完全にコンピューターのためのものでないので。

凝った方法論があったとしても、その気持ちのない人が書いたものは、どこかで歪を生む可能性があります。ケースバイケースに対応できないから。

マニュアル通りに振る舞ってさえいれば、ゲストが喜ぶ接客ができるでしょうか?

// オートマティックおうむ返しコメントより背景や理由を
http://d.hatena.ne.jp/jflute/20180625/repeatablecomment

4. DBデザイン

要は、DB設計です。DBデザインと言えます。どんなテーブルにするか?どんなカラムにするか?どんなリレーションシップにするか?どんな制約を付けるか?

これまたたくさんの選択肢がありますよね。ある程度の規約やポリシーなどはありますが、すべてが自動的に決まるものではありません。

さらには、DBは(基本的に)振舞いを持ちませんから、なおさらごまかしも効きづらい領域でありながら、かつ、あとからの修正がやりづらいものです。DBの負債は、プログラムの負債に比べて、リアルに「3倍つらい」です。

また、

DB以外の領域のことも考えてデザインしないと、DB自体も良いものにはならない

と言えます。

DBはシステムの中の大事な大事な根幹です。ゆえにDBが周りのレイヤに与える影響というのは大きいので、DB以外のことも考慮しないと良いDBとは言えません。

もの(データ)が散らかっていますから、部屋(DB)のどこにどうしまいますか?

5. アーキテクチャデザイン

アーキテクチャは、「ビジネス要件の実現」と「ディベロッパーの住処」のトレードオフに悩む領域です。

むかし、こんなブログを書きました。

// アーキテクトのちから
http://d.hatena.ne.jp/jflute/20150113/architect

全体最適が求められるので、局所の議論で決めてもいけないし、長く生き続けるものなので、いまの議論で決めてもいけないし。

システムはどんどん複雑化していますから、アーキテクチャに対する高い意識が、各々のディベロッパーにも求められている時代でしょう。

どこに台所があって、
どこに柱があって、
どこに階段があったら、
住みやすく長持ちする家になるでしょうか?

とにかくバランス感覚

どの領域にしても...

"とある要件" と "別の方向性のとある要件" との「ちょうどいい」を探す作業と言えます。

どこかしらでトレードオフが発生するわけです。それは二方向だけとは限らず、三方向四方向になることも。論理的でも感覚的でも、そのバランスを取る作業、これがプログラマーにも求められるのです。

これは非常に疲れる作業です。そして、経験と分析、習得が必要な作業です。

「バランス感覚」というスキルは確実に存在します。

バランス感覚ってどう鍛えるの?

「そこから逃げないこと」

まずはそこだと思います。

非常に疲れますし、本来多くのプログラマーにとって、あまり得意な領域ではない(と思われる)ので、ベテランプログラマーであっても、安易なデザインを出してしまう人がいるように思います。プログラマーにそういうスキルが求められていること、それをしっかりと知ること。その認識すらない人もいるかもしれないから。

「どうして、そういうメソッド名にしたの?」
「どうして、そういうクラス構造にしたの?」
「どうして、そういうコメントを書いたの?」
「どうして、そういうテーブルにしたの?」
「どうして、そういうフレームワークにしたの?」

こういう質問にされたときに、大正解じゃなくてもいいから、真正面向いて答えられるか?

そのスタートラインに立ちさえすれば、スキルアップ自体が得意なプログラマーですから、おのずとどうすれば鍛えられるのかわかってくるでしょう。

考え抜かれたデザイン

別に立派なデザインじゃなきゃいけないわけじゃないです。jfluteもそんなものは出せません。一番良いものじゃなくてもいい。

考え抜かれたデザインは、何かしら問題にしっかり向き合ったものになってる

と思います。

DBFluteで新しい機能を追加するとき、そのメソッド名や機能の提供の仕方を決めるのに、(普段の生活はしながら) 二、三日かけることがあります。

いろいろなことを考えて想定して想像して妄想して、電車の中でもお風呂の中でも布団の中でも、悩んで悩んで最後に決めます。当然、時間の制約があることもあるので、その時間制約も考慮した上での結論を出そうとします。

もともとプログラマー、考えることは得意なはずですから、その考える力を、ちょっと違った角度に使っていけばいい。「もの作り」は「ちょうどいい」を探す旅のようなもの。

それが「デザイン脳」の始まりです。