デザイン入門の補足 〜「分かりやすい」を作るために〜
この記事は農工大 Advent Calendar 2024のためのものです。
こちらが本編です。先にこちらをお読みください。
本来「読みやすいプログラムについて」の記事を出すはずだったのですが、執筆してみると「リーダブルコードを読め！」という内容になってしまったので、急遽変更しました。
アドベントカレンダーでは（当然デザインの話ではなく）技術系の話をしろという話だったので、文章による補足をすることでなんとかします。
デザインに入門しよう
hr.icon
一般的に「デザイン」と言うと、絵画・建築・彫刻・工芸のような創作物の表現・アイディアのことを指す語であると思いますが、Wikipediaにもある通り、実際にはもっと抽象的に「何かを効果的に伝える・目的を達成するためのアイディア」という解釈をするのが現代的です。 中国語では「設計」と書くようですが、日本語としてもこの語が最も和訳として適切な気がします。
ただ、日本語的には設計と書いてしまうと、デザインに含まれる「造形」「装飾」のようなニュアンスが薄れてしまいますね。もちろん、デザインにとってこれらも重要な要素です
で、なぜこのような話をしたかというと
「何かを効果的に伝える・目的を達成するためのアイディア」
これって技術者がやりたいこと・実装したいものそのものじゃないですか？
実際、私はプログラミングとデザインの両方の勉強をしていますが、親和性をかなり感じています。
「分かりやすい」はパターン化されている
hr.icon
「デザインは生まれつきのセンスが必要だ」と思われがちです。
確かに「装飾」というニュアンスで言うとそうだと思います。僕もスライドのデコレーションを考えるのはかなり苦手分野です。ただ、「設計」というニュアンスで言えば、座学でかなり養うことができます。
例えば、スライド3章目の「デザインの4要素」の話です。「強弱・反復・余白・整列が大事だよ〜」というのを知っているだけで、ずいぶん良いスライドを作ることができるようになると思います。（練習は必要だとは思いますが……）
さらに、ここの章で理解してほしいこととして「人間が分かりやすい・見やすいと思うことは、結構パターン化できる」という事実です。
この事実を知ってもらって、その「パターン」をきちんと言語化する癖をつけれれば、相当センスが身につくと思います。
自分で言語化できない場合は、デザイン本を読んだりすると、ヒントが載っていたりします。
逆に、よく知られた「分かりやすい」のパターンを破ると、勘違いを生むことがあるということも覚えておくと良いです。
コーディングに活かそう
hr.icon
さて、「読みやすいプログラムについて」の話をします。
プログラムも創作物の一部です。デザインの考え方が適用できます。
特に自分はデザインの4要素で言うと「反復」の考え方が重要だと考えています。
すごく典型的な例ですが、
code: (cpp)
for (int i = 0; i < n; i++) {
// 1
}
for (int i = 0; i < n; i++) {
// 2
}
for (int i = 0; i < n; i++)
{
// 3
}
こんな感じで、同じプログラム中で波括弧の改行位置がなのに異なっていると、良くないよねって話があると思います。
これをデザイン的な側面から解釈すると、これまでと違う目線の移動のさせ方をさせられるから読みづらいという見た目的な問題はもちろんなのですが、それ以上に「今まで for はずっと同じ書き方をしていたのに、3 で急に違う書き方をしている。これは何かこれまでと違った何かをしているに違いない」という思考が無意識的にも発生してしまうことが問題だと気づけます。
このような、どうでも良い思考・ストレスを与えるコードはなるべく減らすように努力するべきです。そのために、チームで開発するようなプロジェクトでは、コーディング規約を定めることで、どうでも良い部分は統一（反復）してしまうのです。波括弧の位置なんて正直どうでも良いからこそ、どうでも良いという事実をコード上で表現するためにコーディング規約という（面倒な）ルールを作ってパターン化してしまうのです。
見た目がロジックの分かりやすさを生む
hr.icon
ちょっと文脈から逸れますが、ついでに主張したいので書きます。
code: code-1 (cpp)
for (int i = 0; i < a.size(); i++) {
for (int j = a.size() - 1; j > i; j--) {
}
}
}
code: code-2 (cpp)
for (int currentPassIndex = 0; currentPassIndex < inputArrayForSorting.size(); currentPassIndex++) {
for (int comparisonElementIndex = inputArrayForSorting.size() - 1; comparisonElementIndex > currentPassIndex; comparisonElementIndex--) {
}
}
}
どちらのコードもバブルソートの実装です。
下のコードの方が、 全ての変数名が説明的で一見分かりやすそうですが、実際のところ上のコードの方が分かりやすくないですか？（んぐ.iconもしかしたら例がよくなくて共感を得られないかも…（））
基本的にはプログラムにはロジックを書くわけですから、変数名は説明的である方がわかりやすいです。
「コメントアウトの必要がなくなるような変数名をつけるべき」とはよく言われます。
ただ、一部例外があると思っていて、それが上述の例です。
コンピュータに効率的なロジックを伝える以上、自然言語的に説明するのがなかなか厄介な場合もあると思います。そういう時に無理に変数名を長くしてしまうと、ロジックを目で追いにくくなってしまいます。
コードを一つのデザイン物だと捉えたとき、この現象面白いなーって思っています。
時に、短い変数名をつける勇気もあったほうがいいかもしれません。
「普段、長い変数名をつけているのに、その規則を破って短い変数名を使っている」ことで、「ロジックに集中した方がいいんだな」ということを暗に伝えることもできますね。
終わりに
hr.icon
もうちょっと書かないとデザインとプログラミングの親和性について伝えられなさそうですが、自分としてもまだ言葉にまとめきれてないので、一旦この記事はここで締めます。
明日からの記事もよろしくお願いします〜