美意識

| コメント(0) | トラックバック(0)

Twitterやっちゃうとブログ書かなくなるといいますが
いやホント全くその通り。

普段思ったことをその場その場で吐き出しちゃうので
たまにはブログでも書こうかなーと思って編集画面を開くも
あれ、やっぱし書くことないな……ってなっちゃうんすね。

今日はサッカーのおかげで職場が早々に捌けて
私もうまうまとそれにのっかって早く帰ることができたので
折角この時間のあるときに何か書いてみようかなと。

タイトル「美意識」。

といっても、ビューチホーなアレとかナルシーなソレとかじゃなく
今回私が考察…妄想してみたのは
私の職業分野でいうコードに関するお話。

ここでいうコードというのはプログラムのことです。
コードといってもケーブルとかCメジャーセブンスとかじゃなく…
あ、もういいですか。そうですか。

あーつまり、コンピュータプログラミングにおける
美というものの追求について、ですね。

ところで、まだ本題に入ってないのにいきなり余談ですが、
私は昔、某ゲーム系専門学校のプログラミングの講師に
採用されかかったことがあります。

あれは私がフリーになる約1年前の話。
当時、私が社員だった会社のブラックっぷりにほとほと疲れて
いろいろ転職活動してる中の選択肢のひとつだったわけですが
ほぼ採用が決まった段になって蹴ってしまいました。

理由はぶっちゃけ薄い給料だったんですが
今にして思えば、そうでなくても蹴ったのは正解だったかなと。
学校にも私にも、お互いにとってね。

正直、当時の私は
人に教えられるほどプログラムに熟練してなかったと思う。
まぁ、教えながら自ら成長するという例もよくありますけどね。

ただ、ことプログラムということになると、
間違った概念や知識を若者に植えこんでしまうというのは
やはりそれほど小さくない罪だろうと思うわけです。

それから1年後にフリーに転身してから今に至るまで
1つの会社にとどまらずいろんな会社でいろんな言語に触れながら
それこそいろんな人の書いたソースを見てきました。

ソースといっても、とんかつとかウスターとかタルタルとか…
あ、もういいですか。そうですか。

ソースというのはソースコードのこと。
コンパイルする前のテキストのことですよ。要はコードです。

中にはなんでそうするのか納得いかないコードもあれば、
そういうやり方もあるのかとひどく感心するコードもあったりで
書く人の考え方や性格なんかもコードの中に見えたりして
それはそれで面白い経験ができたと思っておるわけです。

そんな中で、これはキレイだ!これはふつくしいッ!

などと思えるコードというのもいくつかあり
それらの共通点は何だと一言で形容できないもののありますが
きっと確実にいえるだろうことがひとつある。

それは“単純”であること。

そう、シンプル・イズ・ベスト。 SIMPLE IS BEST!!!
(大事なことなので2回…)

全く同じ要件を実現するコードでも、
よりステップが少ない、より階層が少ない、よりシンプルな方法で
実現されているものの方が「キレイだ」と思える。

これはコードに限らず全ての論理でいえることで、
同じことができるなら、より少ない手順でやれるものの方に
多くの場合選択の価値があるという考え方です。

オッカムの剃刀ですね。
数学や物理学なんかも同じ論理で、より単純な方が真理だとされる。

…という観点で見てですね、
逆に「これは酷い」と思えるコードもやっぱり同程度にあるわけで
やれif文の分岐をこれでもかと幾重にも重ねてみたり、
段々畑かと突っ込みたくなるほど何ブロックも奥まってみたり…

それはそれで見た目に面白くて、ビジュアルでは絶景なんですが
きっとコードとしてはいただけないわけです。

あまりやると一体どれがどの終了ブロックかわからなくなったり、
途中で登場する変数のスコープがどこまでか判別しづらかったり
全く同じ処理が同じブロック内に2度3度コピペされてたり…

まぁとにかく、そんなバグの温床になるようなコードが山盛りで
そんなものが実運用で稼働してるとかいう日常がある。

これ書いたのどう見てもプログラマじゃないだろ!
普段ExcelやWord使ってるアドミニが片手間に書いたんじゃないの?
とか思えるようなシロモノが割りと多いという現実。

もちろん、そんなコードばかりというわけじゃないですけどね。
少なからずそういうコードを見る度に、これホントにプロの仕事?
とか思っちゃうわけですよ。

偉そうですね。私。

ええ、私もそんなにキレイなコードを書けてる自信はないですが
少なくとも自分なりに最適化しようという努力はしてるわけです。

目指すところはシンプルさ。

if else if else if else if ... なんて続く分岐の嵐は
switch にした方が見た目にもキレイだし可読性も上がるでしょう。

もちろん、言語によってはそれが使えない場合もあったり
規約縛りがあったり処理速度が落ちたりすることもあって、
そういうやむを得ない理由なり、if文の方が良いといえる理由なり
何かポリシーがあってのことであれば、それも是だと思います。

例えば、大抵の言語で文字列はswitchの条件に使えないので
そういうのはif else をつなげるしかない。それはわかります。

あと、現実は理想通りまるくキレイにおさまることばかりじゃなく、
後からお客の要求で仕様変更や機能追加を強いられたりとか、
致命的な設計ミスがわかってそう書き直さざるをえなかったりとか、
なるべく影響範囲を狭くするために後付コードにしてあるとか、
カスタムメイクだとそういう事情が多いというのもわかります。

ただ、そういう理由もなしで結果的に実現出来れば良しの精神で
ダダ打ちされたコードというのは、美しくないだけでなく
それを書いた本人さえ誤読しやすく、後でメンテする人とかなおさら…
ってことになってくるわけですよ。

全く考えた後がないコードというのは、大体ぱっと見でわかる。

そういうのを見て何も疑問に感じない人というのは、
きっとプログラマよりも他に向く仕事が何かあるんじゃないのかな?
っていってあげたくなる衝動に駆られるのです。

偉そうですね。私。

ホント、ごめんください。
でもここは私のブログなので、ここでくらい好き勝手書かせてクダサイ。

といっても、これ以上書くことも無くなってきたんですが。

要は、コードを書いた後、もしそれを考える時間の余裕があるなら
たった今書いたそのコードはもっとシンプルにできないだろうか?
と考えて欲しいということです。是非とも。

多分、私が今プログラミングの講師になったら、
下手な自前ポリシーは変化するので(それは学んだ!)押し殺しつつ
とりあえず「シンプル・イズ・ベスト」だけは教えると思う。

これは多分、コーディングに限らない美意識という気がします。

今さらそんなことを思ったって話ですが、
考えてみれば、これってわりと枯れた常識だったりしますよね。


よし、久々に書いたぞ。

トラックバック(0)

トラックバックURL: http://sphere42.mlexp.com/mt5/mt-tb.cgi/2880

コメントする

2018年2月

        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28      

アーカイブ

Powered by Movable Type 5.2.10
MLEXP.サイト内を検索
Loading