前置き
ある程度システムエンジニアとして生きていると、人それぞれで自然と芽生えてくる「思考」があると思います。
この思考についてあまり言語化される機会がないので、私個人の思考を記事にしてみました。
後半は技術や概念になりますが、知ってるとまた違うと思ったので書いておきます。
「リファクタリング命」思考
とにかく出てきた仕様を最短で実装して、完了とする人はいませんか？
私はこの手法をどうぶつタワーバトルと呼んでいます。
「降ってくる仕様最速で実装してみたw」
限界が見えますね。
「もうこれ以上仕様を積めない…」
「修正の影響範囲がわからない…」
どうぶつタワーバトルは一度置いたら配置は変えられませんが、システム開発ではリファクタリングできます。
新しい仕様が出てきたら、既存のシステムを多少なり変更して、新しい仕様が綺麗にハマるように変更してあげましょう。
エンジニアの仕事は仕様をコードで積み上げるではなく、組み立てることだと思います。
「コメントの書き方」思考
意味のわからない、意味のない、コメント、コメントアウトはしない。
1.ダイイングメッセージ
// userName = userName.Trim();
このコメントアウトには一体どんな意味が…(消していいの？だめなの？)
理由を一緒に残そう
// TODO ユーザー名の表示仕様が決まり次第コメントを解除する予定
// userName = userName.Trim();
2.小泉進次郎構文、Google翻訳
// userNameから前後の空白を取り除く
userName = userName.Trim();
処理を見ればわかるコメントはしない。
Trim関数の仕様の説明をしてるならTrim関数のコメントにあるべき、
本当に見て欲しいコメントを見てもらえなくなるので、削除しましょう
「副作用絶対許すな」思考
副作用は有害だからなくそう。
プログラミングでいう副作用とは「関数が行う目的の作用に伴って発生する別の作用」
よくやりがちな副作用は、参照型の引数が変化することです。
例えば下記の例
public User? GetUser(UserSearchInfo userSearchInfo)
{
// ここで値が変わっている
userSearchInfo.UserName = userSearchInfo.UserName.Trim();
return db.Users.FirstOrDefault(user => user.Name == userSearchInfo.UserName);
}
この関数は引数に渡したクラスの値が書き変わってしまうので、呼び出し側の後続の処理に影響します。
こういった副作用はバグの温床になるため、絶対にやめましょう。
どうしても副作用が避けられない場合は関数のコメントに残しましょう。
「関数名の付け方」思考
関数名を省略して意図が不明になるのはNG。長くても関数が何をするのかはっきりつけましょう。
これと副作用を徹底しているプロジェクトは関数名だけ見れば動きを把握できるので、開発効率は上がり、不具合頻度は下がります。
たまに関数を呼ぶ側にフォーカスした名前をつける方がいますがやめましょう。
SOLIDの原則
オブジェクト指向で大事な5つの原則の頭文字を取ったものです。
これに関しては思考というより、経験なので、調べて実践して欲しいなと思うくらいです。
ドメイン駆動設計
エリック・エバンスのドメイン駆動設計の中でもモデリング作業を実践して欲しいなと思います。
さらにモデリングの中でも「オブジェクトモデリング」、どのクラスにどの実装を持たせるのが適切かを考える作業ですね。
たまに1つのクラスに送信から受信、時間の管理、文字列の変換…などなど、明らかに責務が多すぎるクラスを見かけたりします。
SOLIDの原則とも深く結びついているのですが、こういった適切な責務に分離できていないクラスは修正に対して弱い側面があります。
これに関しても思考というより、経験なので、調べて実践して欲しいなと思うくらいです。
宣言的プログラミング
これも調べれば色々出てくるので概要だけ触れますが、実施する効果は絶大だと思ってます。
メリットとしてはコードのメンテナンス性が向上します。
やり方は、一度宣言した変数を不変に保つだけです。
変数なのに不変？？
と思ったのぶは調べてみてください。
あとがき
途中から手抜きになってしまった。。
多分もっと伝えたほうがいい情報はあると思うんですが、パッと思い浮かんだものを書いてみました。
私の個人的な意見なので、参考程度にお願いします。