Upskilling「デザイン」じゃなくて「デザイン脳」です。普段のプログラミングの中でも、Webデザインと同じような脳みそを使うことがあるというお話。「パズルを解く能力」(言葉が見つからなかった...)が必要と思われることはあっても、あまり「デザイン能力」が必要だとは思われてないように思えます。「動きを実現する選択肢(かたち)が一つしかない」とかであれば、もはやデザイン性はあまり関係ないかもしれませんが、昨今は特に、動きを実現するための選択肢は増えているので、プログラマーも「デザイン脳」を、意識して鍛えていく必要があるだろうと考えています。様々な場面があると思いますが、ここでは大きく五つ挙げてみたいなと。メソッド名、変数名など最初に、あまりに当たり前でありながらいつまでも問題を抱える領域、「名前付け」です。これもれっきとしたデザインです。いつでも問題を抱えるのでしょうと。どれだけ構造が良くても、簡単にプログラムを負債に変身させることができるのが「名前」です。一般に、わりと苦手なプログラマーも多く、「規約を設けてあまり考えなくてもいいようにする」ことが多いです。するのもよくありません。規約作り自体がとても難度の高いデザインであり、完璧な規約というものは存在しないからです。(規約というのは複雑なケースバイケースに対応できない)非常に個人差の激しいところですし、正解がないから人によって変わるからなお難しい。ひとつ、大きなコツを挙げるとすれば、これです:名前を付けようとしているものだけを見て、その名前を付けることはできない。把握して、初めてその名前を付けられる。名前って識別子ですから、極端な話、一つしかないのであれば、(例えば、システムの中にクラスが一つしかなかったら...)名前を付ける必要もあまりないかもしれません。あるから名前を付けて識別したいわけで。単純に統一性という面もあるし、統一性よりも優先する特殊な要件があったとしても、やはり周りの名前の付け方に影響はされるはずです。この基本を忘れて「こうだ!ああだ!」と言ってても、何も良い名前は思い付かないし、それが良い名前なのか悪い名前なのかの判断もできません。全体を把握しようとする」の姿勢がない人に、名前付けを任せることはできないわけです。クラス構造、メソッドシグネチャなどここは説明するまでもないところかもしれませんね。効率が下がる、という問題を抱えるので、その問題を軽減するためのデザインが必要なのです。ここでも大きなコツが一つ。人のことを考えないと構造デザインはできません。人がそれを見て解釈する、人がそこに後から手を加える、だからデザインが必要なのです。人のことを考えて初めて、良いクラスやメソッドを考えることができる。プログラマーは、実は人のことをよーく考える職業でした。先入観と違いませんか?そしてそれは、そんな簡単なことではありません。jfluteも、オープンソース活動(DBFlute)の中で、数え切れないほどクラスをリファクタリングしたり、メソッドのかたちを変えたりを繰り返してきました。DBFluteユーザーのこと未来の自分のこと、いっぱいいっぱい想像して四苦八苦しました。他のツールのソースコードもたくさん読んできました。本も色々とたくさん読んで理論も学びましたが、その実践があってこそ活かせるものでありました。そこまでやって、ようやっと見えてくるものがあるなぁと、「修練には非常に時間を費やすものである」というのを実感しています。「これは知識ではなくデザイン力である」打ち方がわかればホームラン打てるわけじゃないのと全く同じ。相談されることがよくあります。いうのに沿って書けばってのはありますが...そこに何を書くか?フリーテキスト欄に何を書くか?やはりレールに乗らずに思考しないといけない部分はあります。こんなこと書こう、あんなこと書こう、という方法論的なものはある程度はあります。究極は...何が書いてあったら読む人が嬉しいのか?を考えないと良いものは書けない。JavaDocやDBコメントなどは、完全にコンピューターのためのものでないので。凝った方法論があったとしても、その気持ちのない人が書いたものは、どこかで歪を生む可能性があります。ケースバイケースに対応できないから。DBデザイン要は、DB設計です。DBデザインと言えます。どんなテーブルにするか?どんなカラムにするか?どんなリレーションシップにするか?どんな制約を付けるか?これまたたくさんの選択肢がありますよね。ある程度の規約やポリシーなどはありますが、すべてが自動的に決まるものではありません。DBは(基本的に)振舞いを持ちませんから、なおさらごまかしも効きづらい領域でありながら、かつ、あとからの修正がやりづらいものです。DBの負債は、プログラムの負債に比べて、リアルに「3倍つらい」です。DB以外の領域のことも考えてデザインしないと、DB自体も良いものにはならないと言えます。DBはシステムの中の大事な大事な根幹です。ゆえにDBが周りのレイヤに与える影響というのは大きいので、DB以外のことも考慮しないと良いDBとは言えません。アーキテクチャデザインアーキテクチャは、「ビジネス要件の実現」と「ディベロッパーの住処」のトレードオフに悩む領域です。むかし、こんなブログを書きました。アーキテクトのちからhttp://d.hatena.ne.jp/jflute/20150113/architect全体最適が求められるので、局所の議論で決めてもいけないし、長く生き続けるものなので、いまの議論で決めてもいけないし。システムはどんどん複雑化していますから、アーキテクチャに対する高い意識が、各々のディベロッパーにも求められている時代でしょう。「ちょうどいい」を探す作業と言えます。どこかしらでトレードオフが発生するわけです。それは二方向だけとは限らず、三方向四方向になることも。論理的でも感覚的でも、そのバランスを取る作業、これがプログラマーにも求められるのです。これは非常に疲れる作業です。経験と分析、習得が必要な作業です。「バランス感覚」というスキルは確実に存在します。バランス感覚ってどう鍛えるの?「そこから逃げないこと」まずはそこだと思います。非常に疲れますし、本来多くのプログラマーにとって、あまり得意な領域ではない(と思われる)ので、ベテランプログラマーであっても、安易なデザインを出してしまう人がいるように思います。プログラマーにそういうスキルが求められていること、それをしっかりと知ること。その認識すらない人もいるかもしれないから。「どうして、そういうフレームワークにしたの?」こういう質問にされたときに、大正解じゃなくてもいいから、真正面向いて答えられるか?そのスタートラインに立ちさえすれば、スキルアップ自体が得意なプログラマーですから、おのずとどうすれば鍛えられるのかわかってくるでしょう。考え抜かれたデザイン別に立派なデザインじゃなきゃいけないわけじゃないです。jfluteもそんなものは出せません。良いものじゃなくてもいい。考え抜かれたデザインは、何かしら問題にしっかり向き合ったものになってると思います。二、三日かけることがあります。いろいろなことを考えて想定して想像して妄想して、電車の中でもお風呂の中でも布団の中でも、悩んで悩んで最後に決めます。時間の制約があることもあるので、その時間制約も考慮した上での結論を出そうとします。プログラマー、考えることは得意なはずですから、その考える力を、ちょっと違った角度に使っていけばいい。「もの作り」は「ちょうどいい」を探す旅のようなもの。それが「デザイン脳」の始まりです。Introのリリースです。Releasedあけましておめでとうございます。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。