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

「デザイン」じゃなくて「デザイン脳」です。いわゆる「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で新しい機能を追加するとき、そのメソッド名や機能の提供の仕方を決めるのに、(普段の生活はしながら) 二、三日かけることがあります。

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

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

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