今、社内でとあるプロジェクト(納期間近)に途中参加しましたが、色々関わっていると気になることが多々あります。
そのため、今後の自分への備忘録として残します。
#プログラム開発
命名規則は必ず決めよう
自分が関わるプロジェクトにはなぜか命名規則がありません。
決めておかないと後で見返す時or誰かに引き継ぐ時に説明しづらい。
パスカルケースかキャメルケースかスネークケースくらいは決めて欲しい。
自分は何もなければキャナルケースで書いてます。
メソッド内にコメントをかかない
これプログラムに書かれていて愕然としたんですが。
今でもプログラムを読み取る時は苦痛。
#Region "Method"
private Sub test()
Dim testA AS String
#Region "Test Method"
Method1(testA);
#End Region
End Sub
- 可読性が落ちる。
- コード行数が追えない。
- 読むことが面倒くさくなる
と何もいいことがなかった。メソッド内の説明はせめてコメントで記載してほしい。
人によっては仕様の確認でプログラムを見ることもありますし。
プロジェクト内の独自ルールは簡単でもいいから資料にまとめよう
なお自分は勉強会に呼ばれていないのでプログラムとの会話の中で理解して行きました。一応リーダー的な役割なのでプログラマ向けの勉強会に参加する必要があるかと言われるか疑問ですが、なぜか依頼するプログラマ間で情報共有が怪しいんですよね。
プログラマに依頼する時に説明する際、最低限知っておかなければいけない情報は資料にまとめましょう。
リーダー向け
リーダーをするならプログラマにならない
これは今後の教訓。途中でプログラムの作成をPMから依頼されて作ることになったのですが、自分にはプログラム作りながら他の人にスケジュールを振りながら品質を維持することは無理だと悟った。
リーダーは「他の人への作業の割り振りを行い、一定の品質のものを作り上げる」が求められる役割です。
品質の維持をするためにはプログラマ
やる気がない人、自分がリーダーとして動くにあたり負担になる人には外れてもらう
納期間近で人員の追加が何度か行われました。
自分のチームにも何人か追加されたり、別のチームの作業をやってもらうことがありましたが、やはり合わない人がいました。
いや、別にプログラムが出来る出来ないは関係ないんですよ（出来た方が当然いいです）
ただ、指示や依頼をする際に、自分に負担が来る人にはPMに連絡して外れてもらいました。
基準は色々あると思いますが、その人に仕事を振ることが仕事と思ったら外すことをお勧めします。
プログラマの方も色々思うところがありますが、仕様書を見ない段階から「プログラム作れません」と連絡することはお勧めしません。その瞬間から言われた側は見下します。
常識的な内容から外れたものは必ず初期で潰そう
いきなりですが郵便番号の入力を実装する場合、どのように実装しますか？
自分は動作確認を行う際、
- 半角数字7桁(もしくは「-」を含めた8桁)
- もしくはフリー入力だけど、登録時に上記内容でエラーチェック(最低限ですが)
などでチェックしようとしていました。実際はインバウンド対応も含めるともっとルールは作る必要がありますが。
しかし作ってもらったプログラムを動作確認してみると...
- コントロールによっては8桁以上入力可能
- ほぼなんでも入力可能。全角半角、ひらがななど
- エラーチェックではじいていると思ったらDB登録できた
頭抱えました。
でも他のプログラムを見てみると同じように動いているものも多く...。
相談案件となりましたが、このような実装が事前にあると仕様と言い逃れられる可能性があるため、早いうちに潰しましょう
まとめ
他にも色々突っ込みどころがありますがこの辺りで。
リーダー、プログラマ問わず物事に疑問に思うために色々気にすることをお勧めします。