釣りキチプログラマー翔平の備忘録 
はじめに
この記事では、
僕の10年間現場でソフトウェア設計してきた経験、
書籍・勉強会などを通じて学習した内容、
などを言語化して、
もし新人プログラマー時代の自分にソフトウェア設計について伝えるとしたら？？
というテーマでまとめてみました。
プログラマー歴も10年目に入り、
後輩プログラマーの教育も最近では依頼されることも多くなってきたので、
改めて自分が、
現場で大切にしている考え方や、
注意しているポイントについて言語化してみたので、
自分の後輩や新人プログラマーの方々の参考になればと思います。
ソフトウェア設計はなぜ必要？？どうすればスキルが身につく？？
ソフトウェア設計について具体的な内容に入る前に、
そもそもソフトウェア設計は何のために必要で、
ソフトウェア設計が疎かになるとどうなってしまうのか？？
について知っておく必要があると僕は考えています。
それが、モチベーションになり、
スキルを磨くための行動にも繋がるのだと思います。
こちらの記事や動画にまとめたのでご覧ください。
ソフトウェア設計の必要性と設計スキルの磨き方
ソフトウェア設計のきほん
ここからは
普段自分が現場で意識している
ソフトウェア設計の基本的な考え方を紹介していきます。
命名の重要性
メソッド・クラス・パッケージなどなど、
何かに命名する場面は現場では非常に頻繁に発生します。
ソフトウェア設計と関係ないでしょと思われるかもしれませんが。。。
僕は新人プログラマーがソフトウェア設計を学ぶ
最初のステップとして、
命名がなぜ重要で、
命名が適当だとどうなってしまうのかを
知ることから始めるのがいいと考えています。
それらを理解した上で、普段の業務の中では、
目的に特化した狭い意味での命名をする訓練を行うことが、
ソフトウェア設計のスキルアップのための最初の基礎練習には最適かなと考えています。
詳細はこちらの記事にまとめたのでご覧ください。
命名と小さく分けることの関係と重要性〜ソフトウェア設計のきほん〜
業務で扱う値の範囲を正確に表現する
業務で取り扱う値はInteger、String、Date型などよりも
ほとんどの場合狭い範囲になります。
業務で取り扱うべき値の範囲を
ソフトウェアでも表現することで
何が得られるのか？？
逆に、
表現しない場合どのような危険があるのか？？
について知っておくと良いです。
命名と同じく重要ですが、
そこまで高度で複雑な設計スキルを必要とする訳ではなく、
新人プログラマーでも明日からすぐ意識したり、
取り入れられると思います。
詳細はこちらの記事にまとめたのでご覧ください。
業務で扱う値の範囲を正確に表現する〜ソフトウェア設計のきほん〜
分岐を丁寧に扱う
多くの現場では
ソフトウェアを保守開発し続ける必要があります。
分岐は丁寧に扱わなければ
ソフトウェアはすぐに保守しずらく、
変更が危険なものになってしまいます。
現場では
とにかく動けば良いではなく、
当たり前に動かし続け、
素早く機能追加し続けることが求められます。
特に分岐を書くときには注意が必要です。
詳細はこちらの記事にまとめたのでご覧ください
分岐を丁寧に扱う理由とその方法〜ソフトウェア設計のきほん〜
公開かそれとも隠蔽か
クラスやメソッド、関数はどこをどのように公開すべきか、
逆に複雑な内部構造はどのように隠すべきかを慎重に考える必要があります。
例えるなら、
身の回りの電化製品のようにスイッチひとつで
(内部の複雑な電子回路などの仕組みを知らなくても)
ご飯が炊けたり、お湯を沸かせたり。
身の回りの電化製品のように、
ソフトウェア設計も公開と隠蔽を適切に行う必要があります。
詳細はこちらの記事をご覧ください。
公開かそれとも隠蔽か〜ソフトウェア設計のきほん〜
まとめるか分割か
クラスやメソッド、関数はどこまでを1まとまりとして作るか、
どこから分割するかについて慎重に考える必要があります。
複数の概念や関心事を1まとまりとしてコードを作ると、
どのような事態になるのか？？
どのようにすれば適切に分割できるのか？？
このあたりについて記事にまとめたのでご覧ください。
まとめるか分割か〜ソフトウェア設計のきほん〜
中途半端なモノの状態や動作は許容しない！！
使う側が誤用できないように、
中途半端に間違った使い方ができないように、
クラスやメソッド、関数を作るのは重要です。
使う側が誤用できる余地があると、
最悪データベースを壊すような事態にも繋がり
ダメージが大きくなります。
どのように中途半端なモノの状態や動作を防ぐのか？？
をまとめたのでご覧ください。
中途半端なモノの状態や動作をなくす〜ソフトウェア設計のきほん〜
変更はできる限りさせない！！
変更を許容すると、
どこでどう変更されるか？？
を常に気にする必要があります。
不変にすることで、
不変のモノを使う側は
変更の可能性を気にせず安全にシンプルに
利用できます。
変更を許容した場合の危険性と
不変にする方法と不変の効果について
まとめたのでご覧ください。
変更はできる限りさせない〜ソフトウェア設計のきほん〜
リファクタリングを体験しながらソフトウェア設計を体験する
ソフトウェア設計について実際に見たり聞いたりするだけでは、
自分の身にはなりません。
ここからは実際に、
仕様変更に弱いソフトウェア設計を見て、
可能であれば
自分で考えてリファクタリングして
仕様変更をしながら体験しながら自分の身にしていきましょう。
お題作成中・・・
