  |
はてなキーワード: プログラミングテクニックとは
たまにいるけど、あっ、こいつ頭悪いな。と思う
彼らはプログラミング言語を書くほどスキルがアップすると信じており、
こういうタイプはある程度いったところで成長が止まる
仕事でプログラミングをする上では、アクロバティックなプログラミングテクニックなどほぼ不要であり、
大抵は平々凡々、素直に考えれば誰でもこう作るというロジックの構築能力が求められる
人と差が付くのは、プログラミング能力とは、他人が読んでもわかりやすい可読性である
コメントや資料を残さないエンジニアは、先天的に可読性に関する感受性が欠落しており、
向いてない仕事を続けられるとお互い不幸であるからさっさと転職するべきだと思う
しかもこの手のタイプは手だけはやたらと動くので、ゴミコードを量産してプロジェクト全体を汚染する可能性が非常に高い
もはや悪性のガンと言っても過言ではあるまい
一刻も早く切除しなければ宿主を死に至らしめることだろう
これ読んでも関数型分からないけど、入り口の前あたりに立つために
プログラマとしての引き出しが増える。
って書くと「そんなもんどんなプログラミングテクニックだって一緒だわ」って言われそうだけど、でもそうとしか言い様がない。
とりあえず、オブジェクト指向と同じで、プログラムを構造化して、複数のレイヤーに切り分けて部品化していくテクニックだとは言える。
ただオブジェクト指向とは大分切り口が違う。何ていうか、割と直交する切り口でプログラムの構造を切り分けていく。
なので、関数型とオブジェクト指向と両方憶えるだけで、大分切り口の引き出しが増える。
オブジェクト指向と関数型両方憶えると、プログラマとしての引き出し増やすのに効率が良い、って思えば良いかも。
オブジェクト指向は、プログラムの各部品を「あれの中のこれの中のそれの中にあるあれ」みたいな感じで組み合わせる。
部品が更に細かい別の各部品で構成されていて、それぞれの部品が噛み合わさって、複雑な一つのプログラムを構成するような切り方。
関数型言語は、プログラムの部品を「あれをした物にこれをした物にそれをした物にあれをする」みたいな感じで組み合わせる。
もっというとプログラム全体を簡単に記述するできるDSLがあって、そのDSLを簡単に実装するためのDSLがあって、DSLの入れ子構造で一番小さい部品はシンプルな関数、みたいな切り方。
ケースバイケース。
ではあるんだけれど、シンプルな部品を大量に組み合わせて構成するのがしっくりくるならオブジェクトで、部品数が少ないんだけど一個一個が複雑な動作する構成にしっくりくるのが関数型……かも？
関数型言語たる条件として「関数が第一級オブジェクト」ってのがあるんだけど、関数が第一級オブジェクトだとイミュータブルなデータを素直に扱える。
で、イミュータブルなデータ構造使うと色々便利、ってことで実例として一番出てくるという。
関数型言語のエポックメイキング的な言語が三つくらいあって、元祖のLispとその流れ汲んだMLとMLの一種で関数型をある種の到達点に持っていったHaskellって感じ(独断と偏見)。
で、このうちのMLって奴が、プログラミング言語に型システムがついてるんじゃなくて、型システムにプログラミング言語がついてきた存在だったりする。
型で色々やるために生まれたわけで、まぁなんというかそもそも型と密接な関係にあって、Haskellもその流れを汲んでて、こいつが超有名になった、って感じ。
おかげさまで、型使って色々やったりする方法が日々考えられているわけです、静的型付関数型の世界では。
関数型言語ではよく「関数と関数を引き取って、合成した関数を返す関数」みたいなのが使われるんだけど、関数と関数の合成って、それ合成された関数がもともと引数として与えられていた関数憶えてないと無理やん？ 自分自身の構成部品憶えてられないわけだから。
クロージャあると憶えててくれるわけですよ。
そんな感じで高階関数を実用的なレベルで使うのには大体必須と言う。
関数型言語はDSLを作りまくる言語みたいに書いたけど、モナドはちょっと複雑なDSLを簡単に作らせてくれる仕組みだと思っとけば良い。
まず純粋の定義だけど「全ての関数は同じ引数を与えられた際、必ず同じ値を返す」ってことで、これがいわゆる副作用がないって状態だ。
で、これって逆に言えば「プログラム内である関数に対して、絶対に同じ引数を与えさえしなければ、その関数がどんな値を返したところで、事実上純粋だと言えてしまう」ってことでもある。
本末転倒感があるんだけど、HaskellではIOモナドという仕組みと特別なmain関数を使って「呼び出すたびに絶対に違う引数を自動的に関数に与えてくれる仕組み」を実現していて、こいつを使って入出力する。
うん……凄い本末転倒。ちなみにこの自動的に与えられる引数はRealWorldって名前がついていて、要は「刻一刻と変わり続け絶対に同じ状況にならない現実世界の状態を引数に取っちまっているようなもんだからしょうがないだろ？」的な感じ。
うーん、たとえば、だ。
C言語のプログラミングテクニックを論議する場において「C言語でスマートポインタ実装だろ」とか「com使って別言語のガーベージコレクション利用」とか言ってる場に、プログラムのプの字も知らないやつが現れて「メモリって何？」とか基本的なことを聞かれても「そもそもそのレベルで論議に参加すんなよ」あるいは「自分で勉強すりゃ判るだろ」になるだろ。
あるいは丁寧な人はメモリとポインタについて講義するかも知れない。ただ、C言語のポインタってそれだけで書籍が出るぐらい、判らない人には判らないもので。
結局、こんな場所で「教えてくれ」なんていうやる気無いやつが理解できるとも思えない。
入門書読めばついていける程度のレベルの内容なんだし、そのくせここで解説もとめるのはちょっとなぁと思うんだが。
◆日本でしか生きていけないと将来破滅するリスクがあるので、世界中どこでも生きていける戦略のご紹介
日本依存症は、国家依存症の一種であり、会社依存症とよく似ています。
会社依存症とは、ある特定の会社でしか通用しないスキルばかり蓄積して、他の会社では通用しない人材になってしまう病気です。
会社依存症にかかると、その会社の経営が悪化して、どんどん待遇が悪くなり、給料を下げられ、「このままここにいても、少しもいいことがないまま年を取っていくだけ」という状況になっても、ひたすらその会社にしがみつくしかなくなります。
また、会社の都合で延々とつまらない仕事をさせられたり、いまいち納得のいかない降格や減給をされても、なかなか拒否しにくくなります。
上司や同僚と相性が合わず、人間関係がこじれてギスギスした雰囲気になり、毎日会社へ行くのが憂鬱になっても、そこに居続けるしかありません。
なぜなら、その会社を辞めると、ほかに行くところがなくなり、路頭に迷ってしまうからです。
このため、このことがよく分かっているエンジニアなどは、その会社の独自製品や独自環境でしか通用しないスキルしかたまらないような仕事をできるだけ避けるようにします。
そして、「広く普及しており、かつ中長期的に需要があり、供給が不足ぎみで、かつ陳腐化しにくいスキル」を戦略的に蓄積します。
たとえば、以下のようなものが考えられます。
・要求分析、要求仕様定義、システムアーキテクチャ設計、RDBスキーマ設計、サーバの負荷分散設計、各種サーバのパフォーマンス解析・チューニング、デザインパターン、マルチスレッドプログラミング、システム管理、ネットワーク管理
・マネージメント、プロデューサ・デザイナ・経営者・営業・顧客との交渉スキルや連係プレースキル
・普遍性の高いコンピュータサイエンスの基礎
・Unix、RDB、正規表現、Java、Perl、TCP/IP、.NET、C#
日本にはたくさんの会社があり、それぞれが浮き沈みを繰り返しています。
いまいる会社が今後もずっと浮いたままだという保証はありません。
一つの会社に依存しきると、その会社が沈むとき自分まで一緒に沈んでしまい、酷い目に会います。
いまいる会社が沈みそうになったら早めに別の会社へ移れるように準備しておくべきではないでしょうか。
国家に対しても同じことが言えます。
政府は全ての国民を幸せにするような政策を実行するべきですが、必ずそれに成功するとは限りません。
ときに間違った政策を行い、多くの犠牲者を出すこともあります。しかも、その犠牲者を救済するための政策が実行されないこともあります。
もっと最悪なことに、間違った政策で、国全体が沈んでしまうようなことすらあります。
もちろん、そうならないように、われわれは選挙で正しい政策を実行してくれる政治家に投票すべきですが、常に正しい政策を実行してくれる政治家が自分の選挙区から立候補してくれるとは限らず、自分以外の人々が常に正しい政策を実行してくれる政治家に投票してくれるとも限らないというのが、世の中の現実です。
だから、どんなに自分が正しい政治行動を取っていても、おかしな政策が実行され、自分の将来が危うくなるリスクは常に存在します。
たとえば、金持ちばかりが得をし、平均的な労働者が搾取される最悪の格差社会になってしまうかもしれません。
あるいは逆に、今後スキルアップし、キャリアアップし、実力を身につけて高い年収をゲットしようと思っているのに、高額所得者の所得税が大増税されて、酷い搾取に苦しむようになるかも知れません。
あるいは、少子化対策で、実質的に独身税をかけられたのと同じような状態になり、結婚するつもりも子供を作るつもりもない人たちの生活の質がかなり落ちるかも知れません。
あるいは、国の医療システムが疲弊しまくって、まともな医療サービスを受けられなくなるかも知れません。あるいは、まともな治療を受けようとしたら、恐ろしく高い料金を徴収されるようになってしまうかもしれません。
あるいは、地方格差を埋めるため、都市部の住民を徹底的に搾取し、地方にじゃんじゃんばらまくような政治が行われるかもしれません。そうすると、田舎に住む人間の暮らしはよくなるかもしれませんが、今後も都市に住み続けるつもりの人間の暮らしの質が大きく低下するかも知れません。
あるいは、非正規雇用を減らし正社員を増やすという名目で、おかしな規制がかけられ、予期せぬ副作用が出て逆に多くの人が職を失うことになるかも知れません。余波で、自分まで失職するかもしれません。残された正社員の自分に酷いしわ寄せが来るかも知れません。
労働者保護や消費者保護という名目で、過剰に企業の手足を縛るような規制がかけられて、企業の活動が阻害されて経済が悪化したり、企業がどんどん日本から逃げ出すかも知れません。雇用が減り、治安が悪化し、日本が住みにくい国になるかも知れません。
要するに、投資において、全ての資産を一点がけするのが危険な投資戦略であるように、自分の生活基盤となる国家を一カ所だけに限定してしまうのも、極めて危険な賭なのです。
この国にずっと住み続けるのが一番賢い戦略でした。
しかし状況は変わりました。
いまや日本よりも豊かな国や都市がどんどん生まれつつあります。
日本などよりも、はるかに先行きの明るい国や都市がたくさんあります。
本来、この惑星には、たくさんの国家があり、それぞれ浮き沈みを繰り返しています。
いまいる国家が、今後もずっと浮いたままだという保証はありません。
一つの国家に依存しすぎると、その国家が沈んでいくとき、酷い目に会います。
いまいる国家が沈みそうになったら、早めに別の国家に移れるように、準備しておくべきではないでしょうか。*1
こういうことを言うと、「おまえに愛国心はないのか？」と言い出す人間が時々いますが、依存症と愛国心とは別の話です。
これは、結婚において、夫を愛していることと、夫に依存することが異なるのと同じことです。
経済的にも精神的にも自立していることと、夫を愛することは両立します。
夫婦仲は冷め切っていて、夫の暴力に怯えながら暮らしているにもかかわらず、夫に経済的に依存しているためにガマンし続けているような状態は、とても健全だとは言えません。
むしろ、特定の国にまったく依存していないにもかかわらず、その国を愛し、その国に貢献することこそ、純粋に打算抜きの愛国的な行為なのではないでしょうか。
そもそも、「いろんな異性とつきあってみて、そのなかから最高のパートナーを見つけ出して結婚する」というのは、少しもおかしなことではありません。
「1人の異性しか知らず、最初につきあった異性と一生添い遂げなければならない」というのはいかにも古めかしい道徳観念です。これは国家についても同じことです。たまたま日本に生まれたからと言って、日本と一生添い遂げなければならないということはありません。
むしろ、さまざまな国に住んでみて、そのなかから、自分にいちばんあった国に落ち着き、添い遂げる、という人生も十分にありなのではないでしょうか。
日本以外で暮らしたことのない人々の中には、日本だけが世界で唯一暮らしやすい場所で、日本以外には暮らしやすい場所などないと信じて疑わない人もときどきいるようですが、そんなことは決してありません。
むしろ、日本よりもはるかに、晴天の日が多く、気候が温暖で、からっとさわやかで、毎日気持ちよく暮らせる国や地域がたくさんあります。
食べ物も美味しく、人々も気持ちよく、街の各種施設も充実しており、遊び場所もたくさんある快適な都市は世界中にたくさんあります。
どんなところでも、けっこう住めば都なのです。
また、日本以外の国は治安が悪くて暮らしにくいという偏見を持っている人もいますが、どんな国でも、きちんとした安全対策を講じ、危険な地域に近寄らないようにすれば、それなりに安全に快適にくらせるものです。
それに、どうせネット環境さえあれば、世界中どこでも、twitterやtumblrやmixiで遊べるし、ブログのコメント欄でクネクネすることもできるし、2ちゃんでだらだら過ごすことも出来るし、エロ画像をダウンロードすることもできるし、はてブで脊髄反射的なコメントを付けることもできるし、はてなスターを連打しまくって顰蹙をかうこともできるのです。
「わたしは(この国に生まれたというより)この惑星に生まれたのだ」という感覚を持ちながら生きるというのは、広々とした感じがして、なかなか気持ちの良いものです。
せっかくこの美しい惑星に生まれたのに、日本という小さな小さな島国に引きこもったまま一生を終えるのは、じつにもったいないことではないかと思えてきます。
●依存症からの脱出は難しい
ギャンブル依存症、アルコール依存症、買い物依存症、恋愛依存症、セックス依存症、たいていの○○依存症は、そこから抜け出すのに苦労するように、日本依存症も、一度それにかかると、そこから抜け出すのにかなり苦労します。
また、タバコ依存症から抜け出すために、さまざまな方法があるように、日本依存症から抜け出すにも、さまざまな方法があります。
日本依存症から抜け出す一番効果的な方法は、実は、英語力をアップすることではなく、日本の外でも安定した収入源を得られるようにすることです。(もちろん、最低限の英語力は必要ですが)
これに一番効果的なのが、資産運用で暮らせるようにすることです。
利回りのよい債権や株式に自分の資産を分散投資し、運用することは、どこの国に居住していてもできます。
日本の国債や株式で資産を運用していたとしても、日本に住んでいなければ運用できないということはありません。世界中どこに住んでいても、日本の国債や株式で資産運用することは可能です。
それどころか、そもそも、日本の国債や日本の株式で資産を運用しなければならないということはありません。
むしろ、全資産を円ベースに一点がけしてしまうと、今後円安が進んだときに、自分の資産が大きく目減りしてしまうというリスクを抱え込むことになります。
資産は、全世界に分散投資しておいた方が安全だし、世界全体の経済は、多少の波はあるものの、中長期的にはつねに成長し続けているので、正しくポートフォリオを組んで、世界中に分散投資しておけば、それほどひどいことにはなりません。
だから、いったん資産運用で暮らせるだけの資産を蓄積してしまえば、日本依存症からの脱却はかなり容易になります。
ここで、「日本がキャピタルゲイン課税の大増税を行ったら、資産運用では暮らしていけなくなるのではないか？」という疑問がわく人もいるでしょうが、そうでもありません。
まず、税金の徴収には、属人主義と属地主義の二つの方式があります。
日本は属地主義なので、自分が居住している国や地域に税金を納めることになっています。
このため、日本でキャピタルゲイン課税の大増税が行われたとしても、海外で暮らしている限り、影響を被ることはありません。*2
現在、属人主義を採用しているのは、アメリカとフィリピンぐらいなもので、極めて例外的なケースです。
ですから、今後日本が属人主義に変更するリスクは、とても低いと思われます。
また、万一、日本が属人主義に切り換えたとしても、ある程度の資産を持つ人間に国籍を与えてくれる国は、けっこうあります。
日本が属人主義に切り換え、さらにきわめて重いキャピタルゲイン課税をかけてきたら、単に国籍を切り換えればいいことです。
ただ、問題は、資産運用で暮らせるようになるほどの資産を蓄積することが難しい、ということです。
そのため、当面は、収入の全てを資産運用だけで稼ぎ出すのではなく、収入の一部だけでも資産運用で稼ぎ出すような状態を目指してみてはどうでしょうか。
そうすると、日本がヤバくなったので、脱出して海外で職を得たのはいいが、最初のうちはまだ英語にも不慣れで、十分な収入を得られないというようなケースでも対応できます。
たとえば、前述のUnix、Web、RDB、Java、Perl、.NET、C#など、世界中に普及している技術の場合、そのスキルを身につけることで、日本依存から抜け出すことができます。
また、これらに関連する要求仕様定義、オブジェクト設計技術、デザインパターンを適切に使いこなしたクラス設計、プロジェクトマネージメント、スケジュール管理なども、特定の国家に依存しないスキルです。
これらのスキルを身につけたITエンジニアは、さまざまな国で職を得ることが出来ます。
実際、ボクの知り合いでも海外で働いているプログラマーがいます。
むしろ、日本よりも快適に働いているようです。
もちろん、これらの技術は、会社依存症から脱却するための技術としても有効で、きわめて安全性の高い技術だと言えます。
これらの標準的なITスキルは、このように、会社や国家を超越して有効ですが、それ以上に驚きなのは、かなりの長い時間をも超越する力を持っているということです。
たとえば、unixの基本アーキテクチャはボクが知っているだけでも十数年、ほとんど変わってません。マルチスレッドプログラミングやデザインパターンも十数年前に身につけたスキルは、かなりの部分、いまでもそのまま役に立ちます。はるか昔に覚えた、クロージャや再帰を使ったさまざまなプログラミングテクニックも、RDBのスキーマ設計のスキルも、ほとんどが、いまだに現役です。
TCP、UDP、IP、HTTP、SMTP、POPなどのプロトコル類もいまだに基本はほとんど変わりません。新しく登場した.NETやC#にしても、過去にマスターしたスキルにほんのちょっと上積みしたぐらいのわずかな薄皮でしかなく、いままで蓄積した基本スキルはそのまま通用します。Haskellのような関数型言語ですら、似たようなコンセプトのプログラミングアーキテクチャは昔からあり、十数年前にマスターした技術の延長線上でなんなくマスターできます。
このように、長期的に安定した技術やスキルを選んで身につけるようにすれば、会社、国家、時間を超えて、安定した収入源を確保できるのです。
ただ、注意しなければならないのは人材の需給バランスです。とくに、インドや旧共産圏からのプログラマの大量供給は要注意です。
一方で、ヨーロッパ、BRICs、VISTAなど、世界中で急速に経済が発達しており、ITエンジニアの需要が今後も全世界的に巨大化し続けるのは確実です。
ここでのポイントは、下級エンジニアや中級エンジニアは、需要はそれほど拡大しそうにないのに、供給は膨大になると思われるので、リスクが大きいということです。
つまり、下級エンジニアや中級エンジニアの場合、海外に行くと、日本にいたとき以上に悲惨になる可能性があります。安易に日本から出て行くべきではないでしょう。
一方で、上級エンジニアは技術分野にもよりますが、今後、世界中で爆発的に需要が拡大することが見込まれていますが、供給が不足する可能性は十分に考えられます。
従って、自分が今後上級エンジニアになる可能性があると考えている人たちは、この戦略に沿って日本依存症から脱却しておいたほうが良い可能性が高いです。
あと、もう一つ考慮すべき点は、上級エンジニアになるような人は生産性が高いため、今後、高額所得者になる可能性があるということです。
今後、この機運の盛り上がりに押されて、高額所得者を狙い打ちする形で大増税が行われ、酷い搾取の対象にされるリスクもあります。
このリスクに対する保険という意味でも、早めに日本依存症を治療し、いつでも仕事と生活の場を海外に移せるようにしておいた方が安全かもしれません。
日本人が海外で暮らしてみると、さまざまな小さなニッチビジネスのチャンスに気がつくことがあります。
たとえば、日本にはあって当たり前なのに、その国にはない商品やサービス。
それは、日本のやり方を現地方式にアレンジすれば、それなりに繁盛する商売ができるかもしれません。
あるいは逆に、その国のおもしろい商品やサービスで、アレンジすれば日本でもウケそうなもの。
もしくは、現地の安い人件費を利用して、何かを作らせ、日本に持ち込むというパターンもあるでしょう。
実際、ネパールに小さな工場をもっていて、そこで自分のデザインした服を作らせ、日本に輸入して販売しているという女性に会ったことがあります。
こういうビジネスのネタをみつけたとき、スモールビジネスを興すスキルを持っていると、そのチャンスを活かして、その国で商売をはじめることができたりします。
とくに、最近急速に豊かになったアジアの国々では、日本がかなりブランドになっています。
とくに富裕層は、日本のさまざまな質の高い品々やサービスを求め、日本の産物に信仰のようなものを抱いています。
これをうまく利用することで、いろいろなニッチビジネスを作り出すことができるかもしれません。
スモールビジネスのスキルとは、小さな会社向けのマーケティング、マネージメント、経理などのスキルです。
たとえば、どんな小さなビジネスでも、どんな商品を、どんな顧客に売るのか、そのために、商品にはどのような魅力がなければならないのか、顧客は、どういう理由でその商品にお金を払うのか、どのようにして利益が出る構造になっているのか、などのビジネスモデルを組み立てなければなりません。
そして、いざ、ビジネスプランが出来たら、場合によっては人を雇い、契約を結び、信頼関係を作り上げ、法律に則って取引しなければなりません。関係者全員が気分良く仕事できるように、win-winの構造を作り出す必要があります。
また、さまざまな法律を調べ、その法律に則ってビジネスを運営する必要があります。
さらに、会社を設立し、会計ソフトで帳簿を付け、経理と資金の管理をする必要があります。
また、予算計画を立て、融資なり出資なりで資金を調達する必要もあります。
こういう小さなビジネスを最小限の規模ではじめてみて、いざ、顧客の反応が上々だったら、しだいに規模を拡大していけばいいのです。
思ったより反応が悪ければ、早期に撤退するか、あるいは、やり方を変えて再度トライしてみたりすればいいでしょう。
そして、スモールビジネスの醍醐味は、たまたま大ヒットしたときのうまみです。
日本のサラリーマンの頂点とも言える、上場企業の社長の年収でも、たかだか4000万円にしかなりません。
これに比べ、スモールビジネスをヒットさせた場合、実質的に年収1億円を優に越えてしまうということは、それほど珍しくないのです。
実際、ぼくの知り合いにもそういう人がいます。
「たかが自営業」とばかにできるようなもんでもないのです。
自営業は、あたると凄いんです。
どのようなモデルで日本依存を脱却するのであれ、共通して必要な Permalink | 記事への反応(0) | 22:10
あれは私がまだ大学助手をしていたころだから3年ほど前のことだと思う。
私の勤めていた大学(情報系)では「プログラミング研究会」みたいなサークル活動が行われていて
プログラミングの講義を受け持っていた私はそのサークルにちょくちょく顔を見せるようになっていた。
そこにはとびっきりかわいい女子学生が一人いたのだけれど、その子はゲームが大好きで
「自分でもゲームが作りたい」と一念発起してゲームコンテストに作品を出品することになった。
しかし、彼女はプログラミングの講義(Java)を1年くらい受けているものの、
本格的なモノを作った経験がなく、ひとりでは行き詰まりをみせているようだった。
彼女はひとりでいることが多く、パソコンに向かって黙々とプログラムを書いているのをよく見かけた。
それを気にかけていた私はたまに彼女をランチに誘うようになり、彼女の方もしだいに私に打ち解けてきた。
私たちはだんだんと仲良くなっていった。私は彼女のキュートな笑顔に魅了されていった。
ある日、彼女が私のもとにやってきて、もじもじと顔を赤らめながら上目づかいにこう言った。
「先生、頼みごとがあるんですけど・・・」
「なんだい？」
これから恋の話が始まるのを期待したあなたは別のページを読んだ方がいいかもしれない。
これから始まるのはプログラミングの話だ。
その日から毎日のように彼女は私にメッセンジャーでプログラミングの相談を投げかけてきた。
彼女は大変優秀で、私の教えるプログラミングテクニックをみるみる吸収していった。
私は彼女の才能に驚き、彼女が将来優秀なプログラマになるであろうことを確信した。
しかし、ときおり彼女が優秀であるがゆえの面白い逆行現象が起こったのだった。
ある日、私は彼女がメモリを意識してプログラミングをしていないことに気づいた。
Java ではメモリを意識する場面というのは少ないが、まったく無いわけではない。
私は彼女にプログラムがメモリを無駄に使っているということを指摘した。
しかし、よく聞いてみると、彼女はメモリ＝ハードディスクくらいの感覚しか持っていないことがわかった。
驚かないでほしい。
私の経験上、情報学部の学生の半分以上がメモリとハードディスクの区別がついていない。
それを知っている私は落胆することもなく、落ち着いて彼女にメモリの説明をすることができた。
彼女は私の説明を聞き「よくわかりました」と、とびきりキュートな笑顔を見せた。
しかし、翌日、彼女の書いたコードを見てがく然とした。コードが次のように変更されていたのである。
for (int i = 0; i < MAXHOGE; i++) {
doSomething(i);
}
for (int i = 0; i < MAXFUGA; i++) {
doSomething2(i);
}
↓
int i;
for (i = 0; i < MAXHOGE; i++) {
doSomething(i);
}
for (i = 0; i < MAXFUGA; i++) {
doSomething2(i);
}
彼女はこのコードを私に見せながら、相変わらずのキュートな笑顔でこう言った。
「このほうが使うメモリが少ないですよね！」
ゲームコンテストの締め切りが近くなってきて、実際彼女はよく頑張っていたのだが、
どうしても間に合いそうになかったので、私もコード書きを手伝うことになった。
とある部分を書いていたとき、重複したコードを見つけたので Template Method パターンを使って書き直した。
Template Method パターンというのが何かというと、同じことをするコードがいくつもの場所でばらばらに書かれないように
一つのクラスにだけ書いて、それを継承して使いまわすという手法(デザインパターンの一つ)だ。
私はこの手法を彼女に教えようとは思わなかった。
なぜなら、彼女は継承だとか委譲だとかポリモーフィズムとかがよくわかってないのだ。
驚かないでほしい。
私の経験上、情報学部の学生の99%が、その、ポリホーなんとかが分かってない。
しかし、彼女はそれに気づいていた。
彼女は私のコードを自分で解析し、新たなる発見を独力でしていた。
重複したコードがあればそれを徹底して継承で解決しようとしている。
そう、差分プログラミングだ。
差分プログラミングの正式な定義は知らないが、彼女は IS-A 関係のない継承を使ってしらみつぶしに
重複コードを書き直していた。
そのコードを見せながら、天使のような笑顔で彼女はこう言った。
「こうするとコードの量が減りますよね！」
私がこの文章で言いたいことは、知の高速道路を渡ってきた若い優秀なプログラマは
ときおり妙な退行現象を起こすということだ。
それは普通の道を通ってきた古い世代にとっては実にみょうちきりんなことに思えるかもしれない。
しかし、それは彼らなりに理由があってのことであり、馬鹿だからやってるわけではない。
彼らは優秀であるがゆえにそういったことを起こすのだ。
そして彼らは優秀であるがゆえに、自分が間違っていることを理解するのも速い。
もし、あなたのまわりで若いプログラマが逆行現象を起こすのに遭遇したとしても、
どうか暖かく見守ってほしい。
上で紹介した2件に関しては、彼女にはそのあと説明をして理解を得ることができた。
しかし我々はそれで油断してはならない。
いつか彼女はその可愛らしい顔をにっこりとほほ笑ませながらこう言うかもしれないのだ。
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？
d:id:fromdusktildawn:20081026さんは「共通化とか抽象化ができるようになった中途半端に優秀な』人を対象にしているのに対して、d:id:JavaBlack:20081026さんは『ちょっと齧っただけの素人』を対象（元記事に対してかもしれない）にしているので、適用対象のレベルがそれぞれ違う気もするけど。
d:id:JavaBlack:20081026さんの記事に対するブクマコメントの幾つかやトラックバック先において、『Java屋らしい』との書き込みがあるけれど、具体的に『Java屋らしい』とはどんなことを指すのでしょう？
当方嫌われ者のエンタープライズ開発withJavaな人間ですが、Javaがよく使われるエンタープライズ向け開発などを行っていると、プログラミングは企業入ってから覚えました、っていう人の方がマジョリティだから、こういう“プログラミングのセオリー”のようなものは知る機会がないと言っていい。よほどいい先輩に当たらないと、こういうことすら教えてくれないことの方が多い。
プログラマなら自分で調べて当然、という意見もあるだろうけど、上記“マジョリティ”の彼らは、自宅でコーディングなんてするはずがないし、早くコーディングなんて卒業したい、と考えている人種。
そんな人たちは、こういうことを『知らない』し、『知ろう』とも思っていない。
そういう現場にとっては、
とある程度型にはめて指導することは、とりあえず『最低限のレベル』を守るためには有効だと思うのだけれど。まぁ元記事では『中途半端に優秀な』とわざわざ断っているから、こういうことを最低限知っていて、杓子定規になんでもかんでも共通化したりローカル変数ばっかり使っている人に対しての進言なんだろうとは思いますが。
『Java屋らしい』とは、Javaが静的型付け言語だけに、なんでもかんでも「こうしなければいけない、ならない」と断定してしまう点を指して『堅い（硬い？）』ことを言っているのでしょうか？
あと、『Java屋は長ーいメソッド名が見やすいと感じるらしい』というコメントについては、Java屋がCOBOLerに対して、
なんて書くのは冗長だよなー。とか、xx区分みたいな項目が横並びに何十項目もあるRDBなんて作るんじゃねぇ、とか思う心理と似たようなものなんでしょうか。
そもそもJavaがこんなにdisられるようになったそもそもの理由も知りたい。
教えてLLな人。