gallu’s blog

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

「わかりやすさ」に潜む罠、あるいは本音

職業プログラマを前提として。
なんだかんだ、やっぱり「誰にでもわかる」ような書き方をすることは大切です。「今は」あなたがメンテナンスをするとしても、いつかはそれを「引き継ぐ」必要があるし、その引き継ぐ人が必ずしも「高スキルである」とは限らないわけですから。
そういったことを考えると「優れた技術力で書かれた難易度の高いコード」よりも「平均的な技術力で書かれたわかりやすくて平坦なコード」のほうがよりよい、ということは、すぐにでも理解できるんじゃないかと思います。
趣味ならいざ知らず、お仕事でプログラムを組むのであれば、できるだけ「難易度の低い、平坦でわかりやすいコード」を書くようにしましょう。





なんてセリフを、まぁ実際わりとよく耳にもしますし、うなずく人も0ではないかと思うのですが。
上述のセリフを噛み砕いてみもふたもなくすると「俺は勉強する気もないし今に固執していたいから、俺がわからないものをとにかく持ち込むな」となります。
端的に毒ぶちこみますと「己(おのれ)の無学さ無思考さ怠惰さを人に押し付けないこと」。はっきり申し上げて、有害以外のなにものでもありません。


さて、ゆっくりと紐解いていきましょう B-p


先に除外事項から。
「シンプルに書けるのに無駄に小難しく複雑に書いた」コードは除外します。ンなもんは「シンプルに書け」で終わるので。
ここで「簡単に書ける?」って疑問を持ったりしたら、是非こちらをどんぞ。シンプルさと簡単さと http://d.hatena.ne.jp/gallu/20100122/p1


では「難易度の高いコード」とは、なんでしょう?
で、それって本当に「業務で必要」なんでしょうか? あるいは本当に「業務では書いちゃいけない」んでしょうか?


とりあえず「難易度が高い」といわれた諸々を、過去n年で言われた記憶から、ほっくりかえしてみましょう。(プロの集う「はず」の現場で、のお話です、念のため)
なんとなく順番に意味があるっぽいけどなんとなくだし雑なのでなんとなく、程度。なので順番はあまり気にしないように。


・状態遷移(オートマトン)、Facadeパターン、Chain of Responsibilityパターン など
・Adapterパターン
・いわゆるFactoryパターン
オブジェクト指向(プログラミング)
・(ブロックモードを指定した)暗号
・関数
三項演算子(ネストしてないやつ:っていうかネストする三項演算子はおいちゃん書かないし
・ビット演算(and/or/xor)
・二進数


…一瞬「ドン引き」しそうな項目もありますが、まぢです。かつ、非常に残念な事に「又聞きではない」んです orz
# 又聞きだと「配列が難しい」って話があったそうな……… orz


とりあえず。「二進数」「ビット演算」あたりで「難しい」言われますと、とりあえずとしては「いいから二種受けて来い」となります。…えと…今だと、基本情報技術者試験、とかってやつなんでしょうか?
三項演算子は…まぁ「見慣れない」ならわかるのですが「難しいから使うな」言われても…
関数は、業務経験が年単位で存在している人から「関数ってなんですか?」ってきかれたことがある orz


暗号については…「ぶろっくもぉどってなんですか?」って聞かれました orz
えと…「暗号に強い、それで飯食ってる」って看板だしてたんですが orz
# ついでに「パディング」もご理解いただけませんでした orz


オブジェクト指向プログラミングを「難しい」っていう論調は、まぁ時々見かけるのですが。
「きちんと学んだ上で」言っている御仁を見たことがないので、アレは多分「ネタないしギャグの類なんだろう」ということで切り捨て。


Factoryパターン以下、いわゆる「4人のギャングたちのお道具群」は、まぁ「名前覚えておけ」とは…とりあえず言わないのですが(覚えておいたほうが圧倒的に会話とか楽だけど、理屈さえしみついていれば、名前程度は失念しても誰かがフォローしてくれますw)。
1年目2年目の初学者ならいざ知らず、相応の年数閲しているエンジニアに「難しい」とか言われても…なんていうか「まいっちんぐ」。
状態遷移あたりになると正直「わからない人」のほうが現場を見ていても多いのですが。でも、ちゃんと説明すれば、少なくとも「30分の講義」を数回&手を動かすで、なんとなくは理解してるよ? なんとなくだから、まだ数回くらいはつまずくんだろうけど、それもまた修行。
ちなみに状態遷移だって「Stateパターン」っていう、れっきとしたGoFの一員(で実装可能)です。


いやまぁ確かに「オブジェクト指向における再利用のためのデザインパターン」は正直読みにくいとは思うけど。
かつ、GoFのパターンって「全部使える」わけじゃなくて、いくつかはおいちゃん的には「え〜?」ってのもあるんだけど。
でも、正直「1〜2年真面目に学んでいれば十分に修得できる」程度のレベルのものを「難しいからわからないから使うな」といわれましても、まぁ正直困惑の一途をたどるわけです。(だれも「レッドドラゴンを熟読して、gccに喧嘩売れるようなコンパイラ作れ」とは言ってないんですし)


で…主題をもう一度、あらためて考察してみましょう。

お仕事でプログラムを組むのであれば、できるだけ「難易度の低い、平坦でわかりやすいコード」を書くようにしましょう


これを、もう少し具体的な文言で噛み砕いてみましょう。あるいは付け足してみましょう。

お仕事でプログラムを組むのであれば、できるだけ「二進数やビット演算や三項演算子や関数やオブジェクト指向デザパタを使わない、難易度の低い、平坦でわかりやすいコード」を書くようにしましょう


さらに、ここに「本音」を少しトッピングしてみましょう。

お仕事でプログラムを組むのであれば、私はこれ以上学習をするつもりもスキルアップをするつもりも、つまりは学習をさせる気もスキルアップをさせる気もないので、できるだけ「二進数やビット演算や三項演算子や関数やオブジェクト指向デザパタを使わない、難易度の低い、平坦でわかりやすいコード」を書くようにしましょう


これは、本当に「是」なんでしょうか?
っていうかその前に…正気ですか?


もちろん。
例えば笑い話としての「簡単なコードなのに、GoFのパターンを18個も盛り込みやがったこのやろう」的なネタに象徴されるとおり。
本来的に「道具の最良の使い方は、使わない事 http://d.hatena.ne.jp/gallu/20091220/p1 」であることは論を待ちません。
ただつまり「必要なところで」「必要なお道具は」きちんと使えるようにする必要があるのです。
で、その気になれば「さまざまな道具を千変万化に使いこなすことができた」上で「今回は使わない」というチョイスが、初めて成り立ち得ると、おいちゃんは思っています。
つまり「出来るけど使わない」境地。間違っても「出来なくてよい」わけではないんです。 http://d.hatena.ne.jp/gallu/20091115/p1


もちろん「そうはいっても出来ない」人も、現場に、一定数いらっしゃるであろうことは想像に難くないっていうかむしろいない現場のほうが想像付かないです。現実は厳しいので。
でも、だからこその「学び育てる」環境なのではないでしょうか?
もうちょっと噛み砕くと、だからこその「下が学び、上が育てる」環境なのではないでしょうか?

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

ソフトウェア職人気質―人を育て、システム開発を成功へと導くための重要キーワード (Professional Computing Series)

  • 作者: ピートマクブリーン,McBreen Pete,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2002/03
  • メディア: 単行本
  • 購入: 4人 クリック: 85回
  • この商品を含むブログ (63件) を見る


んで。
「簡単なコードを」と騒ぐ御仁は、大抵「こしかけちゃった」人です。 http://d.hatena.ne.jp/gallu/20090928/p1
ほんとうに「とりあえず」程度のコードは書けるのですが、そこから先の学習意欲はなくて。
ついでに、だからこそ「教え育て、学び鍛える」なんてのは、するのもされるのもいやで。
そもそもが「質について」理解できていないので、「とりあえず同じ挙動をする」ソフトウェアの中にある「言及する気もうせるほどの質の差異」も「プログラマによって組みあがる速度は何十倍以上も違う」ってことも、まったく理解の外。
むしろ「自分が理解するために、ある程度以上レベルが高いものは積極的につぶしてまわる」くらいの勢いで。
えと…例えばこちらが参考文章。
http://d.hatena.ne.jp/gallu/20061222/p3

「Aクラスの人はAクラスの人を採用したがるが、Bクラスの人はCクラスの人を採用したがる」という格言(一流の人は、一流の仲間を増やして良い仕事をし、かつ自分を伸ばすことを重視するが、二流の人はライバルを作らないように自分より能力が下の人を採用したがる、という意味)

だから、できるだけ「自分がわからないもの」を「みんながわからない」ことにしつつ「みんながわからない"から"だめだ」というふうに詭弁を駆使してみたりするわけです。


技術は本来的に「困ったことがあって、その困ったことを解決するために出来たもの」で。
ゆえにあらゆる技術は「その技術が出来上がるに至ったお困りごととおんなじようなお困りごと」の現場では、相応に有益なものです。
それを「理解し踏まえたうえで」今回はその技術は使わない、ってチョイスならともかく「オレがわからないから知らないからヤダ」は、プロとしていかがなものでしょう?


えと…
ダイの大冒険で、マトリフがポップに言った一言を思わず連想しちゃいますねぇ。

生意気ぬかすなッ!!!
魔法使いの魔法ってのはな 仲間を守るためのものなんだ
無数の呪文と知識をかかえ 皆の危機をはらうのが魔法使いの役目だ
もしおまえがルーラを使えていたら炎上する気球船からたやすく仲間を救えたことがわからんのか!!?

ポップはその後、ルーラも取得し、メドローアさえも覚え、挙句にはカイザーフェニックスをも打ち破りました。
不断の努力があったから、こそ。


あなたが「出来ない」んなら、まず学ぶ。
「あなたは出来るけど他の子が出来ない」んなら、出来ない子を教える。
そうやって、スキルは知識は継承されていくものなのではないんでしょうか?


かててくわえて。
http://d.hatena.ne.jp/tonotonotono/20090303/1236031785

[雑感]考えることを放棄した人々の行うアホ極まりないこと。
人々を教育して「デキル」人材を育てるという難しいことをするよりも、底辺に合わせるっつー無謀なことをして「安定化を計る」と理由をつけてる。


「安定化」それなりに耳に心地よさそうな言葉だけに、前提がとてつもなくアホなことでも、ちょっと考えればわかることでも考えないから心地よい言葉に飛びついちゃうんだな。

「安定」はすると思うのですよ「レベルが低い人」にとって「彼らの安住の地たる」角度では B-p

ドラッガーにいわく「強みを生かせ。弱みに着目するな」とも言います。
できるエンジニアの頭押さえつけて「できないところ」にあわせて、どうやってビジネスするんでしょ?


このあたりを全部踏まえたうえで。
それでもなお「誰にでもわかる、平坦なソースを書け」ってあなたは言えますか? いやまぁ「言える」のであれば、それはそれでいいんじゃないかとは思うのですが。おいちゃんは近寄りたいとすら思えませんがね B-p