パスワードを忘れた? アカウント作成
13546657 journal
日記

kenketsuの日記: きちんと作る 1

日記 by kenketsu

またくだらないことを長文で書いてしまった。ただの気晴らしなので、以下は読まなくても可。

今いるPJのソースコードを読んでいると閉口することが多い。超短納期で構築したとは言え、それはないだろうというレベルで読みづらい。コーディングルールがなかったり、コーディングをリードする人がいなかったのだから当然の結果と言える。

まあ、動くものを作ることができなければそもそもPJとして失敗なのだし、最低限の義務は果たしているとは言える。でも、ダメなコードを書いた人のフォローのため、明日は休出する人達がいて、しかも、そのダメな人の担当部分を作り直すためとあれば本末転倒だ(自分は先週休出したので、今週は出なくていいとのお達しあり)。

何故ダメなソースコードになるか。自分が見てきた中だと、担当部分の全体見通しがないか不十分なままとりあえず部分的に実装し始めて、最終的にグダグダになるパターンが一番多い。お試しで部分的に書いたソースコードを最後まで捨てられないパターン。そこに他機能からのロジックのコピペと担当者の低スキルさが加わると、スパゲティさがさらに加速する。

コーディングをただの作業として捉えて、仕様を何の工夫も一ひねりもせずに実装するのが自分の仕事なのだという意識が、いわゆるコーダーさんには多いのだろうか。そうでない人がたくさんいるのは知っているけれど、自分の経験では意識が高い人の方が珍しいと感じている。

別に、コーディング時には高度なテクニックをガンガン使えというわけじゃない。平易に、素直に書いてもらえればそれでいい。あとから別の人が保守する前提ならなおさらだ。でも、その平易さがコピペの積み重なりだと、何を考えてそういうソースコードを書こうと思ったのか、逆に知りたい。

エディタ画面が、意図をすぐに理解しかねるコピペで作ったロジックで真っ黒に埋め尽くされていたり、インデントがとんでもなく深くなっていたり、ifのブロックがひたすら長かったり、elseのブロックが他とほとんど違わないソースコードをコミットしてくるのは何故だろう。もしかすると、彼自身も変だと思っているけれど対処するためのスキル・ノウハウがないのか?

自分は、自分で作ったシステムを作りっぱなしの状態で手放した経験が最近まではほとんどなくて、自分で面倒を見ながら最期を看取るのが普通だった。だから、「仕様どおりに作りました、これで自分の責任は果たしました、後は任せました、ではさようなら」とは絶対にできなくて、どうしても自分自身とメンバーのコーディングスキルを上げなければならなかった。そういう立場の違いもあるのかもしれない。

でもさ、プログラムやシステムは要求や仕様はどうあれコーディングしたとおりにしか動かないのだし、それを自分が作るとなれば、ちゃんと動くように、きれいに、簡潔に、分かりやすく作りたいとは思わないのかな? 変に作ると困るのは未来の自分だったり別の人だったりユーザーだったりするのだし、「きちんと作る」のがプログラマーとしての責任や職業的倫理観と言う奴じゃないかな?

自分の場合は、実装すべき仕様を最小限のコーディング量で実現しつつ、同時にロジックの平易さを追求するのを楽しく感じる。これはパズルゲームをしている感覚に近くて、自分は最適解に近付けるために無駄な所をそぎ落とす作業が楽しいと感じるタイプなのだと思う。でも、皆が皆そうではないし、仕事でやっているものにこんな視点を持つことができる人は少ないのも知ってはいる。納期に追われているのならなおさら。

それにしても、コーディング上の改善指摘をすると反発的な反応をされるのはなぜだろう。こちらからの伝え方が駄目な割合も高かろう。コミュ力が低いのは自覚している。でも彼らの反応を見ていると、自身で作ったものを否定されたという感覚なのだろうか。

自分も昔は反発していたけれども、指摘の意図を理解した後は、むしろありがたいと思うようになっていった。その積み重ねで今の自分がいて、他人にも同じようにコーディングを考える人になってもらいたいのだけれど、高い納得感を相手に持たせながら伝えるのがなかなか難しい。言葉の壁がある場合は特に。

駄目なソースコードを書く人は、きれいなソースコードを読んだことがないのかもしれないし、そういうものや概念がこの世に存在するということを知らないのかもしれない。他人が書いたソースコードの意図を汲んで読むという経験がないのかもしれない。

でも、ダメなソースコードを書く人が保守作業などで、思わず閉口したくなるような他人のダメなソースコードに遭遇した時、どう感じるのかは興味深い。自分のことを棚に上げて怒り出すのか、仕方がないと諦めるのか、そもそも何も感じないのか、何かしらの反省をして自身のスタイルを変える努力を始めるか。最後者になるように、上手く導いたり動機付けしてあげたいのだけれどね。

あとは…ソースコードレビューをすることになっていても、形式的なものでは意味がないし、いわゆる障害是正処置のためのコーディング規約だと、コーディングを逆に阻害するものも多い。COBOLや古いC向けのバッドノウハウをJavaやC#に適用されてもねぇ…。それにレビュワーのコーディングスキルや、何よりコミュニケーションスキルが低くては意味がないから、体制もきちんとしないと。

さて、また訳が分からなくなってきたところでもう切り上げよう。相変わらず何が言いたいのかよくわからないな。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2018年03月11日 23時05分 (#3374556)
    綺麗なソースコード書こうとしてドツボにはまったことある人。
    だって終わりが無いし、世代によって最適解が変わってくるんだもん。
    もちろんそれ以前の人がいるのは分かっている。
    とりあえず規約があれば頑張って守るので、事前に用意しておいてほしい。
typodupeerror

身近な人の偉大さは半減する -- あるアレゲ人

読み込み中...