よくある議論...
A「コミュニケーションスキルをつけていけないとね」
B「なに!? プログラミングスキルは要らないってのか!?
プログラムが書けないやつなんてなんたらかんたら...」
A「いやいや、誰もプログラミングスキルが
要らないなんて言ってないから」
...
A「マネジメントが大事だ！」
B「技術の方が大事だ！」
A「早いタイピングが大事だ！」
B「じっくり考えて書くことが大事だ！」
...
ぼくがいろいろな議論を聞いてる上で、いつも言う言葉、
いやいや、両方だいじなんです。
なぜか A or B
どっちか？という議論になりがちなのは、世の常でしょうか？少なくとも、プログラミングの世界では、「どっちか？」に決めたがる人が多いように思えます。
そんなにプログラミング、というか、システム開発って、簡単なのでしょうか？ぼくは、つらいつらいシステム開発の現場をたくさん見てきました。
プログラミング力あふれたメンバーのプロジェクト...
コミュニケーション力あふれたメンバーのプロジェクト...
どちらも苦戦していましたよ。
マネジメントが充実しているプロジェクト...
技術やツールが充実しているプロジェクト...
どちらも苦戦していましたよ。
両方ともハイレベルでうまくコラボしてこそ、難しい問題が解決するのではないでしょうか？
どっちか？なんて言っている暇はない
その中で、バランスを整えることはあります。
そのときに A が足りてなければ A が大切になる。逆に B が足りてなければ B が大切になる。逆になれば逆が大切になる。ただ、それだけ。どっちか？って、恒久的に決まるものではない。
また、A を大切にしている組織、もしくは、B を大切にしている組織、そういうポリシーが明確にあるならわかりやすい。でも、大抵は A が 100 で B が 0 でいいということではない。割合の話。
バランスがたいせつ
バランスは非常に重要。だから、ときに「なになにが大事」と言うことはあります。
しかし、それに対して、逆側の主張が敏感に反応することがよくあります。恐らく自己防衛的な反射に近いもの。
なので人は、多くの場合、前置きを置いてから話します。
「B も大事なんだけど...」
まあ、A が足りてなくてバランスが悪いから、A が大事なんだよ、という説明は心がけるべきでしょう。そのバランスを議論すること自体も大事。
ただ、わかりきっていて省略することもあるでしょう。twitterなら文字数が制限されているから、あれこれ前置きも書きづらいでしょう。そもそもあれこれ前置きしてたら、シンプルさを失って伝える力が弱まるでしょう。
難しいところですね。
コメントを書くのか書かないのか？
昔からずっと思っていたことでしたが、ふと話題になったことで、このエントリを書こうと思いました。
「コメントが要らないくらい、わかりやすいコードを書こう」
「わかりやすいコメントを書こう」
この二つは、矛盾して相反した思想に思えるかもしれません。ですが、jflute はそう思っていません。
両方だいじなんです。
コメントが要らないくらいわかりやすいコードを意識してコーディングするのはとても大切です。クラス名やメソッド名、変数名などの工夫、ロジックの最適化やプログラム構造をリファクタリング、そのために思考のスピード、そして手のスピード、限られた時間の中なので必要になってきます。
また、方法論を学んだり、自分で考えていくことも大切。プログラマーとしては、いかに速く仕上げていくか、追求し続けていく運命にあると言えます。
一方で、すべてのロジックが、自然言語なしでプログラミングだけで語れるか？それは現実問題なかなか難しいこと。プログラミング言語の表現の限界もあれば、スキルの限界、すべてのプログラマーが100年の経験を持っているわけではありません。すべてのプログラマーが成長段階でプログラムを書いているのです。
そして、なんといっても、やはり限られた時間、コメントが要らないくらいわかりやすいコードに仕上げるのに時間が二倍かかるのであれば、そこはささっとコメントで補完をして、別のところに時間をかけるほういいという場面もあるでしょう。
そのとき、しっかりとしたコメントを書けるスキルが必要です。意外に難しいものです。書くのに時間をかけたら本末転倒だし、自然言語ならぜったいわかりやすくなるか？っていったらそうではないから。また、プログラミングのメインスキルではないから、個人差は非常に大きい。なので...コメントを書くための方法論「も」大事なのです。
また、事業会社だと仕様書をあまり作らないため、なんでこういう動きをさせているのか？ってのが、コメント書いておかないと100%わからない、ということもあります。詳細設計書なんてないし、人も入れ替わる可能性も高い。「背景や意図」を伝えるコメントが重宝されます。要は、どういうスタイルの開発なのか？によってもそこは大きく変わってくるでしょう。
メンテナンスする人からすれば、どうしてもコメントないと絶対にわからないだろう、というときは、もう遠慮なく自然言語に頼って、そのコードのストーリーを書いておいて欲しい、というのが願いであったりするでしょう。
コメントを書いたら負け？
どっちでもいいですが、バランスはどこへ？もし、そうなのでれば負けたときは潔く書きましょう。負けたら負けたで殿の仕事がその後を左右しますよ。
理想の話は夢の中でするしかありません。仕事のプログラミングなら、なおさら。またまた逆に、コメントをすっ飛ばして、スピードを求めることだってあります。
そもそも「どっちか？」でプログラミングが済むなら、おそらくそれはあまりおもしろくないものでしょう。その矛盾をものようなものを抱えて、
バランスを見極めてコーディングしていかないといけないくらい難しいから、単なる道具とは思えない魅力があるのでしょう。
そういえば、こんなエントリも書いたことがありました。
// 一つの問題に対する解決法は単一とは限らない
http://d.hatena.ne.jp/jflute/20110215/solutions
