コーディング方針
今週も終わって、明日からまた仕事ですよ。。
みなさん、お疲れ様です！
そして私は明日、明後日でリリース作業です。
というか現在、私はプロジェクトを２つ抱えてます。
そんでもってさらに追加で３つ目のプロジェクトの引き継ぎ中です。
そして、年明けには４つ目が来るんじゃないかと思ってます。
忙しすぎでしょ、おかし。。。いえ、有難うございます。
成長の機会だ！ってことでがんばってる次第です。
と雑談はさておき、
タイトルのコーディング方針について。
あるプロジェクトの改修でパッケージをちょこっといじくってます。
要件整理、
見積り、
設計、
開発、
テスト仕様書作成、
改修に伴う仕様書修正、
手順書作成、
リリース作業
まで一貫して自分がやります。(もちろん、レビュー有ですよ)
まぁ今回はある特定の取り込みデータのみに対して仕分け方法を変えるだけの単純明快な改修です。
ちゃちゃっと1時間くらいで
パッケージの中身にファンクション追加して
whereで絞ったのをupdateみたいな感じで作って上にレビュー依頼を出しました。
「次はサクッとテスト方針決めるかー。」って思ってたのですが、
初心に返される指摘を受けました。
それは。。。
- 今回以外に仕分けを変更したいデータが出たらどうするのか
- 上記点の改修があったあとに追加テストでテスト観点が無駄に増えない為にどう改修したらよいのか
個人的には、
「いや、絞る条件チャカチャカっと追加したらよいだけじゃないか」
と思っていたのですが、
「先読み」と「親切心」が足りなかったみたいです。
例えばシンプルに
update
テーブル名
set
カラムA=1
where
カラムA=0
and
カラムB=xxxx
;
とするよりも
update
テーブル名
set
カラムA=1
where
カラムA=0
and
カラムB in(
xxxx
)
;
としたほうがよいということ。
(そういう細かいところに気づけない自分、技術力低いな)
なぜかというと後者のほうが
もし今後追加で対応が必要になり、
かつ、別の作業者が対応するとなった場合、
可読性が高い。そして、改修行も最少。
もう少し、目の前のことばかりに対応する力だけではなく、
先まで見通した考える力を養えるべきだと感じました。
そのためにはほかに何が予測されるか、自分でどこまで周りを、このシステムのことを考えて動くかがカギです。
以上！
