元ネタはこちら。
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント
http://d.hatena.ne.jp/fromdusktildawn/20081026/p1
ああ先に。
ここは極論を楽しむ劇場です。プロフィールページをよく読んで、真に受けたり鵜呑みしたりしないように気をつけてご鑑賞ください。
という部分については「意図的に」オミットしています。
横にあるプロフィールを「誰もが見てる」とは限らんでしょ？
っつか。「わ〜いこいつネタに釣られたよゲラ」で、書いてる人は楽しいかもしれませんが。
それを真に受けて痛い目に遭う技術者とか現場の事を考えると、私はこれを「ジョークである」ではとても流せません。
他人に害をなし傷付ける冗談を笑えるほど、私は○○(字数制限なし。お好きな言葉を入れてくださいませ)ではないつもりなので。
で、本題。
「変数のスコープは狭いほど良い」と妄信する
………妄信？
変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。
えと………クラス名にスコープ？ ファイルスコープのイメージかしらん？ 名前空間のことかしらん？
メソッド名にスコープは…アクセス修飾子のイメージかしらん？
なにやら初手から「クソも味噌も一緒」に見えてしまうのですが気のせいでしょうか？
で。全然違う粒度のものをひっくるめて「保守性も可読性も悪い」とか言われても…なんともはや。
ちなみに「変数のスコープ」に限定して話をすると。スコープが広がるとデバッグで苦労するからって一点を個人的には最重要視してます。
自分が使ってる変数が「よそでなんか意図とは違う角度で書き換えられる」と厄介でしょ？
実際、「あちこちから頻繁にアクセスするようなオブジェクトやメソッド」は、スコープをぐっと広くしてしまった方が(場合によってはグローバル変数やグローバル関数にしてしまった方が)、いちいちパラメータ渡しのバケツリレーをせずに、オブジェクトや機能を使うことができ、プログラムの可読性も保守性もずっと向上することがけっこうある。
ない。
この手の甘い言葉にまどわされてglobalやらSingletonパターンやらを使い始め、それが徐々に甘くぬるく浸透して大惨事と化したソースをいったいどれだけか見せられたことか orz
基本的に「globalが欲しい」という発言の根底にあるのは「“データの流れ”の設計のミス」でしかないので。
バグをglobalというパテで塗り固めずに、ちゃんと設計バグを潰してください、と私は言います。
「同じロジックのコードを2度以上書くな」と妄信する
まず第一に。「同じロジックのコードを2度以上書くな」ではない。「同じ意味を持つコードを2度以上書くな」である。
具体例。
有るところで「消費税５％を算出する」コードがある。別の場所で「倉庫使用手数料５％を算出する」コードがある。
小数点以下の端数処理が一緒である事を考えると、上述は当然ながら「同じロジック」になる。
これらは共通化しうるや否や。答えは明確に否。
理由は…割愛していいですよね？ 必要なら後で別エントリーで書いてみますが。
で。第一のケースは明らかに「共通ではないものを共通化してる」だけ以上fin。
んなものは適切なコメント書いときゃすむ話。
第二のケースは「勉強しましょう」以上。「直感的な理解が出来ない」のは純粋にあなたのスキル不足です。
第三のケースはより憂慮されうる問題。とはいえ「直近的な開発速度が速い」としても、その後の修正、似たようなものの使い回し、その他中長期視野を加味した場合「なおコピペが優位」という状況にはタダの一度たりとてお目にかかった事がない。
第四のケースへの回答は一言で片付く。「共通化は二回目」。共通化「しそう」な部分を切り出す必要はかならずしもないが、それは「コピペしてよい」とはまったく違う。コピペしようと思う瞬間に共通化する必要が、大抵の場合には、ある。
第五のケースは正直考慮するつもりはない。業界の衰退と未熟化を、私は望んでいないので。社内の体制云々いうなら、未熟者に合わせるんじゃなくて教育とか考えてください。
ちなみに…抽象化と共通化が奇妙に入り交じってまったりとした中にも混沌とした気配が感じられるのは気のせい？
えと…例えばね。「他人様のサーバ上での開発で手持ちのフレームワークのごく一部(debug_utilクラスとか)の１メソッドだけを、テストプログラム上でとりあえずちょっと使いたい」なんてケースの時は、１ミリ秒たりとも迷わずにコピペしますよ？
というくらいの「例外」ってのは存在し得ますがね。でもそれくらいだと思う。
「プログラミング言語を極めるのが大切」と妄信する
んと…「プログラム言語を極めずにプログラミングが極められる」ならtrue。なので、理論値としては「ありえる」。
ただ、現実問題としては「いくつかの言語はある程度習熟しておきましょう」が現実解。
っつか「プログラム言語を極めずにプログラミングを極められるのか」って部分で、方法が一欠片たりとも思いつきません*1。
もちろんそも大前提として「極めるってなに？ っていうか人類に可能なものなの？」という疑問が常につきまとうってのはいうまでもなく。
実際には、サーバ設定、ネットワーク、データベース、パフォーマンス設計、セキュリティ設計に関するスキルは、プログラミング言語の知識に負けず劣らず重要だ。
-中略-
さらに、要求仕様を実装仕様に落とし込むスキル、あるいは、実装の都合と顧客の都合を最大限に満たすような落としどころを洞察するスキルなど、より優れた美しいアーキテクチャ設計をするのに、単なるプログラミング言語のスキルよりもはるかに重要なスキルはたくさんある。
もちろんそれらは重要だ。ただ、それらと同じくらいにプログラミングスキルは重要だし、そのために「いくつかの言語を極める」のもまた重要。ちなみに「複数言語をやる事」も同じくらいに重要*2。
で、得手不得手は各個人あれど(＆それはやむを得ないのですが)、それぞれのスキルの「どれがより重要か」というのは、あまり意味がない。なぜなら「どれもが重要な一つのピース」だから。
何て言うのか…傍点的雑感。
スキルが低い上に勉強する気がない子が「僕勉強したくないからいいじゃん今のままで」っていうときの言い訳でよくこの手の文脈に似た台詞を耳にするなぁ。
ちなみに、よそのBlogで気になった事を少し。
http://d.hatena.ne.jp/kidotaka/20081027/1225080072
必要になったらその都度覚えればいい。
必要になったのに調べないのがいけない。
えと…「必要である事が認識できない可能性」や「必要ではあるのだが選択肢が出せない可能性」などがあるので。
とりあえず現時点における自分の認識で「無意味だ」「無関係だ」と思うものでも、ある程度手広くアンテナを広げた方がいいと個人的には思います。
http://d.hatena.ne.jp/wiseler/20081028/p1
というか、私はあまり詳しくないのですが、計算論的に考えればそれらを一緒くたに扱えることは自明であって、決して
識別子と，変数／メソッド／クラスは別物だし，変数とメソッドとクラスはプログラミングする上でそれぞれ大きく異なるものだ．グローバル変数とグローバル定数でさえも大きく異なる．*4
あー，ひょっとしたらこの人は「囓っただけの素人」じゃなくて，単なる「スーツ(笑)」の人なのかな．ならば凄く納得．全然プログラミングを理解してないわけだ．
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな転職日記という発言は出てこないように思えるのですがどうなのでしょうか。
えと…多分「会話の粒度」についての認識不足なのだろうと思われます。
わかりやすいケースとして。例えばHTTPがあります(過去に実際にあった会話を元にしています orz )。
曰く「HTTPは１往復ぶちきりの紙芝居だというけど、TCP/IPはちゃんと接続が保てるものなのだから、で、HTTPはTCP/IP上でやってるのだから、それはおかしい」。
で。
その辺の粒度(とかレイヤーとか)を理解していないと思われる文章を書いているから「ああ素人さんなんだろうなぁ」と、少なくとも私は感じてます。
http://d.hatena.ne.jp/tarotarorg/20081028/1225199603
開発毎に明確にコーディング標準を決めて、みんなでルールに従えばいいんじゃないのか？
変数のスコープとか、同じコードを何回書くかとか、正しい答えなんてないんじゃないのか？
とりあえず、これだけは言える。
万が一開発の真っ最中にこんな論争が始まったらやってらんねぇ
えと…否定することは出来ないんだけど。
正直、ある意味においてもっとも「哀しい内容」であったのは事実。
結局のところ。
あちこち、過去のエントリーでも書きまくってますが。守破離、という考え方が、存在します。
http://d.hatena.ne.jp/gallu/20060309/p1
http://d.hatena.ne.jp/gallu/20060928/p1
規矩(きく)作法 守りつくして 破るとも 離るるとても 本(もと)を忘るな
これに尽きます。
破っても離れても結構です。
でも。あなたは規矩作法をきちんと理解していますか？ 理解した上で、本を忘れないように配慮しながら破ってますか？
