国民宿舎はらぺこ 大浴場

• 中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場

職場からなので簡潔にｗ

1. 「変数のスコープは狭いほど良い」と妄信する
2. 「同じロジックのコードを2度以上書くな」と妄信する
3. 「プログラミング言語を極めるのが大切」と妄信する

変数でもメソッド名でもクラス名でも言えることだが、単純に「スコープは狭いほどよい」という方針でプログラムすると、逆に保守性も可読性も悪いプログラムができあがることがけっこうある。

同じようなパターンがプログラムの複数箇所に現れる場合、それらを抽象化して一つの共通ロジックへのパラメータ渡しとして実装し、それを複数箇所から呼び出すように実装すると、プログラムコード量が小さくなり、保守性が良くなったような気がするので、未熟なプログラマが、なんでもかんでも共通ルーチン化しまくって、非常に保守性の悪いプログラムにしてしまうことがある。

レベルの高いエンジニアは、同じロジックのコードが複数箇所に現れている方が、適切な判断の結果であることはけっこうあるということをよく知っている。

とりあえずこの、最初の二つ。個人的な経験においては、この二つでそれほど困ったことになったということって、実はあんまりない。それは、多分、おいらの個人的な仕事経験において、こういうことで困るほど、周囲の方々に能力的に拙い方が多くいらっさるような現場に、お世話になっていたということが、まったくと言っていいほど無かったからなんだと思う。

そういう意味ではおいらはこれまで非常に幸運なんだけれども、反面、そういう意味での不幸な状況というのは、個人的には異常事態なんじゃないか、とも思う。

とりあえず、シンボルのスコープは必要以上に大きくなりすぎないように気をつけようとか、安易なコピペはなるべく避けよう、といった指針は、作業効率を考慮した場合において、逆の指針にしておくより明らかに安全であるはずだ。もちろん、「無理に」スコープを狭くしようとしたり、「無理に」抽象化しようとしたりさえしなければね。逆に言えば、無理のないスコープの限定の仕方、無理のない抽象化の方策が考えつくのであれば、多くの場合、これはやるに越したことはない。初心者の方がこういう部分でトライ＆エラーに躍起になるのは、おいらが上司なら応援したいところだし、それが原因でスケジュールに多少の支障をきたしたとしても、かばってあげたいと思う。各人の戦力を考慮し、そういう部分も織り込んだ上でスケジュールを組むのが、多分最も正しい。

セオリーとされる物事に対して、「必要以上に○○すべきじゃない」と言ってしまうのは、その○○に技術的な難しさを感じる「未熟な」プログラマーに、妥協の余地を与えてしまいかねない。プログラマーとして、技術者として先輩風を吹かせたいのであれば、そう言う部分については政治的な考慮がもう少しあってもいいんじゃないかなぁ、とは思った。

一方で、この件に関して大きく対立する意見を表明されている方がいらっしゃるんだけれども、

• ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな転職日記

まず，実際には多くのフレームワークやライブラリを用意するだけで事足りる場合が多い．独自の言語仕様を制作するのは『車輪の再発明』でしかなく，作られた言語は一般的に普及した言語に比べより未熟で質が悪いことが多い．開発者にとってアプリのデバッグだけでなく言語のデバッグも同時に行うことは非常に大きな負担となる．なにより似て非なる二つの言語を覚えることは単なる時間の浪費だ．よほど大きなメリットがない限り，独自仕様『粗悪』言語の出番はない．

プログラミング経験がほとんどない初心者に毛が生えた人が，このように主張する事が多い．特に抽象の取り扱いは開発者の素質に大きく依存するらしいので，素質のない人がこういう結論に至るのは驚くに値しない．自分のプログラミングテクニックの未熟さを棚に上げて，抽象に責任転嫁することがないよう注意しよう．

ひじょーに Java 屋さんらしい意見だなぁとか思った。いや、厭味とかではなくて。世の中にはこういう技術者さんも確実に必要だと思う。

でも、「おいらは今 Lua でプログラムを書いているはずなのに、言語仕様には存在しない MVC モデルに躍起になっている…」なぁんて環境での開発を1年間ほど経験させていただいたりしたおいらとしては、言語拡張にも近い現場ルールの適用程度の「自由度」も楽しめないプログラミングというのも面白くないなぁとか思ってしまうしｗ、単に抽象化と言ってしまうよりもアクロバティックなテクニック (演算子オーバーロードとか TMP とかｗ) も、「正しく」活用できるところでは活用したいよなぁとか思う人なのでｗ、そういう意味では若干相容れないかなぁ、とか、ちょっと悲しいことを言ってみたりもするわけなのですよ。

よーするに論を決してしまうならば、言語仕様的にも設計テクニック、セオリー的にも間違っていない事柄について、知識も向上心も無い人たちを前提とした職場づくりというのは、下策なんじゃねーの? ということ。自分たちが現場において要求すべき技術レベルというのをある程度高めに設定したうえで、そういったレベルでの開発についていけない方々に、無理に仕事をお任せする必要もないんじゃないかなぁ。厳しいことを言うようだけれども。

もちろん、現場はそうせざるを得ないんだと断末魔を上げたい気持ちもよく分かる。そんな優秀な人を雇い入れるお金もない。でも、安全で住み心地の良い街に住みたいなら税を高くして福祉に金を賭けろ、って言う議論があるのと同様、モチベーションを維持しつつ気持ちよく仕事をしていきたいならば、経営者が従業員に金をかけるべきなのは至極当然なんだよね。本来そうやって技術に明るい技術者を育てたいなら、積極的に技術に明るい人間を雇い入れ、根っこから技術に特化した風土を社内に培っていかなきゃならないんじゃないかな。それが、技術で食っていく会社の、経営者の責任だと、おいらは思うわけですよ。

せめて、PHP で「関数の引数以外の場所での参照渡しは禁止」みたいな、あるいは値の型でモンゴリアン、じゃなかった、ハンガリアンの強制とか、そういう、優秀な人々の生産性を抑制するようなルール作りは、廃絶していくべきなんじゃあないかなぁ。