怠惰なおいらは、飽きない。 ― 2008年10月16日 02時14分02秒
例によって例のごとく、呑んで帰って布団に潜ったら目が覚めてしまって寝付けなくなってしまった。こんな時はブログでも書くに限る。
最近の自分の行動を振り返って、思うことがあったので、そのことを書こうと思う。愚者は経験に学ぶ。
おいらは昔から、何か一つのことに夢中になり出すと、他のことはそっちのけで、そればかりに時間を割き続けるという癖があったように思う。小学校の頃はファミコンに夢中になる時期があり、中学生の頃は PC-8001mk2 というマイコンの BASIC でゲームを作ることばかりに夢中になり、高校では FM-TOWNS の内蔵音源で音楽を作ることばかりに夢中になり、大学では MIDI 音源で DTM に夢中になった。かと思えば、卒業研究のために Visual C++ に触れるようになって以降は C++ でのプログラミングに夢中になったし、その流れで今の業界にもすんなり入れて、運良く出向した先の職場でプログラミングに勤しむことが出来るようになった。
去年一年間も、久しぶりの C++ での開発と言うこともあって、かなり良い感じでのめり込めたように思う。OPTiM のみなさん、元気ですか? サブプライムの煽りで経営が傾いたりしていませんか? 余計なお世話ですかそうですか。うちはそもそも経営成り立ってすらいないですが (苦笑)。
近頃はというと、蓄えが無くなってしまったために急遽入れてもらったお仕事がテストの仕事で、それも当初は自動テストの環境構築から関わらせてもらえるような話だった筈なんだけど、気がつきゃ開発途上段階のマニュアルテストに明け暮れる日々。大事な仕事だとは分かっちゃいるんだけど、いまいちノりきれないまま、惰性で日々を送っている状態。
こういう状態が実は一番良くなくて、他のことで気を紛らわそうにも、何もする気がなくなってしまうばかり。言い訳してないで家で出来ること、個人的な開発でも進めていれば良いんだけど、通勤時間 1時間半は伊達ではなく、早く帰っても晩飯作って風呂入ればあとは寝るしかない時間になってしまう。例によって出勤時間にあんまり厳しくない職場なので、朝も遅くなりがちになり、PC つけてもはてブのホッテントリにあがる記事を読んでは一喜一憂しつつ下らないコメントを並べる日々。時間があってもそれを有効に使おうという気になれないまま、なんとなーく、DS の電源を入れ、マリオカートとか始めてしまう。そんな日々が、ここ数ヶ月、続いている。
はてブにせよ、DS にせよ、一つ一つの時間の使い方について、なかなか飽きがこないのだ。数ヶ月単位で同じゲームばっかりやってれば飽きそうなものなんだが、これがなかなか飽きない。糞生意気な髭の配管工どもがおいら (そいつはいつだって猿だ) の行く手を阻む度、遠く後方からタイミングを見定めたかのように雷やらトゲゾーやらを飛ばしてくる度、おいらの中の狂気や加虐心が沸々と…まぁよーするにムキになるわけである。むっきー。
せっかく DS-10 とか買ったのに、あんまり曲とか作れてない。激しく良くない。
おいらが物事に飽きが来にくい性格をうまく活用すれば、時折とても生産的な結果を導くことが出来ることも、自分では理解しているつもりなんだけど、いまいちそういう方向に繋がっていないように思う。もっとも、飽きが来にくいと言っても、大きな成果を上げるうえでは決して長い期間というわけでもなかったりする。おいらが作るものが割と中途半端にできかけのまま放置されるケースが多いのはこの辺に起因しているように感じる。で、放置している間何をやっているのかと言えば、大抵ゲームとかマンガとかそっち方面の、あんまり生産的でないことに時間を費やしていることが多いのだ。
目標や期限を決めても、簡単に破ってしまうことが多い。多分、自分を追い込むことに成功していないんだと思う。それに、追い込めばうまくいくと考える方が、多分甘いと思う。そういう問題ではないのだ。
とりあえず今の自分に必要なことは、やるべき事がなんなのかを今一度整理してみることだと思う。とりあえず喫緊では会社の決算をやってしまわないとまずい。かなりまずいｗ いや笑い事じゃないか。来週にでも一日休みを入れて、税務署に行ってこないとなぁ。
今の仕事は 10月一杯で終了なので、それまでに、それ以降にやるべき事の準備をしておきたいと思う。とりあえず、夢中のベクトルを切り替えることが先決だ。
とりあえずはてブと DS は、しばらく封印かなぁ…。
「妄信」とやらがプログラムを「複雑」にするという迷信 ― 2008年10月27日 16時04分38秒
職場からなので簡潔にｗ
- 「変数のスコープは狭いほど良い」と妄信する
- 「同じロジックのコードを2度以上書くな」と妄信する
- 「プログラミング言語を極めるのが大切」と妄信する
変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。
同じようなパターンがプログラムの複数箇所に現れる場合、それらを抽象化して一つの共通ロジックへのパラメータ渡しとして実装し、それを複数箇所から呼び出すように実装すると、プログラムコード量が小さくなり、保守性が良くなったような気がするので、未熟なプログラマが、なんでもかんでも共通ルーチン化しまくって、非常に保守性の悪いプログラムにしてしまうことがある。
レベルの高いエンジニアは、同じロジックのコードが複数箇所に現れている方が、適切な判断の結果であることはけっこうあるということをよく知っている。
とりあえずこの、最初の二つ。個人的な経験においては、この二つでそれほど困ったことになったということって、実はあんまりない。それは、多分、おいらの個人的な仕事経験において、こういうことで困るほど、周囲の方々に能力的に拙い方が多くいらっさるような現場に、お世話になっていたということが、まったくと言っていいほど無かったからなんだと思う。
そういう意味ではおいらはこれまで非常に幸運なんだけれども、反面、そういう意味での不幸な状況というのは、個人的には異常事態なんじゃないか、とも思う。
とりあえず、シンボルのスコープは必要以上に大きくなりすぎないように気をつけようとか、安易なコピペはなるべく避けよう、といった指針は、作業効率を考慮した場合において、逆の指針にしておくより明らかに安全であるはずだ。もちろん、「無理に」スコープを狭くしようとしたり、「無理に」抽象化しようとしたりさえしなければね。逆に言えば、無理のないスコープの限定の仕方、無理のない抽象化の方策が考えつくのであれば、多くの場合、これはやるに越したことはない。初心者の方がこういう部分でトライ＆エラーに躍起になるのは、おいらが上司なら応援したいところだし、それが原因でスケジュールに多少の支障をきたしたとしても、かばってあげたいと思う。各人の戦力を考慮し、そういう部分も織り込んだ上でスケジュールを組むのが、多分最も正しい。
セオリーとされる物事に対して、「必要以上に○○すべきじゃない」と言ってしまうのは、その○○に技術的な難しさを感じる「未熟な」プログラマーに、妥協の余地を与えてしまいかねない。プログラマーとして、技術者として先輩風を吹かせたいのであれば、そう言う部分については政治的な考慮がもう少しあってもいいんじゃないかなぁ、とは思った。
一方で、この件に関して大きく対立する意見を表明されている方がいらっしゃるんだけれども、
まず，実際には多くのフレームワークやライブラリを用意するだけで事足りる場合が多い．独自の言語仕様を制作するのは『車輪の再発明』でしかなく，作られた言語は一般的に普及した言語に比べより未熟で質が悪いことが多い．開発者にとってアプリのデバッグだけでなく言語のデバッグも同時に行うことは非常に大きな負担となる．なにより似て非なる二つの言語を覚えることは単なる時間の浪費だ．よほど大きなメリットがない限り，独自仕様『粗悪』言語の出番はない．
プログラミング経験がほとんどない初心者に毛が生えた人が，このように主張する事が多い．特に抽象の取り扱いは開発者の素質に大きく依存するらしいので，素質のない人がこういう結論に至るのは驚くに値しない．自分のプログラミングテクニックの未熟さを棚に上げて，抽象に責任転嫁することがないよう注意しよう．
ひじょーに Java 屋さんらしい意見だなぁとか思った。いや、厭味とかではなくて。世の中にはこういう技術者さんも確実に必要だと思う。
でも、「おいらは今 Lua でプログラムを書いているはずなのに、言語仕様には存在しない MVC モデルに躍起になっている…」なぁんて環境での開発を1年間ほど経験させていただいたりしたおいらとしては、言語拡張にも近い現場ルールの適用程度の「自由度」も楽しめないプログラミングというのも面白くないなぁとか思ってしまうしｗ、単に抽象化と言ってしまうよりもアクロバティックなテクニック (演算子オーバーロードとか TMP とかｗ) も、「正しく」活用できるところでは活用したいよなぁとか思う人なのでｗ、そういう意味では若干相容れないかなぁ、とか、ちょっと悲しいことを言ってみたりもするわけなのですよ。
よーするに論を決してしまうならば、言語仕様的にも設計テクニック、セオリー的にも間違っていない事柄について、知識も向上心も無い人たちを前提とした職場づくりというのは、下策なんじゃねーの? ということ。自分たちが現場において要求すべき技術レベルというのをある程度高めに設定したうえで、そういったレベルでの開発についていけない方々に、無理に仕事をお任せする必要もないんじゃないかなぁ。厳しいことを言うようだけれども。
もちろん、現場はそうせざるを得ないんだと断末魔を上げたい気持ちもよく分かる。そんな優秀な人を雇い入れるお金もない。でも、安全で住み心地の良い街に住みたいなら税を高くして福祉に金を賭けろ、って言う議論があるのと同様、モチベーションを維持しつつ気持ちよく仕事をしていきたいならば、経営者が従業員に金をかけるべきなのは至極当然なんだよね。本来そうやって技術に明るい技術者を育てたいなら、積極的に技術に明るい人間を雇い入れ、根っこから技術に特化した風土を社内に培っていかなきゃならないんじゃないかな。それが、技術で食っていく会社の、経営者の責任だと、おいらは思うわけですよ。
せめて、PHP で「関数の引数以外の場所での参照渡しは禁止」みたいな、あるいは値の型でモンゴリアン、じゃなかった、ハンガリアンの強制とか、そういう、優秀な人々の生産性を抑制するようなルール作りは、廃絶していくべきなんじゃあないかなぁ。
最近のコメント