みなさんは「割れ窓理論」をご存知でしょうか? 元々は犯罪学の分野で提唱された次のような理論です。 建物の窓が壊れているのを放置すると、誰も注意を払っていないという象徴になり、やがて他の窓もまもなく全て壊される Wikipedia 一見するとソースコードの扱いとは関係のないように見えますが、大規模なプロジェクトや、他チームから巻き取った案件のソースコードを思い起こしてみてください。 以下のような状況に心当たりはないでしょうか? 数千行ある中に一行だけコーティング規約違反を見つけたが、修正コミットを打つのが面倒なので放置した 他者のソースをレビューした際に、コメント文の誤字を見つけたが、細かいやつだと思われたくないので指摘しなかった 多くの人が心当たりがあるのではないでしょうか。プログラムの動作上は問題がないため、コーディング規約違反やコメント文の誤字脱字などは放置されてしまうことが往々にしてあるかと思います。 割れ窓理論的に考えるとこれは良くない兆候です。その小さな綻びを放置すると、ソースコードの品質に対する意識が低いという象徴になり、やがて重大なバグを引き起こしてしまう可能性があるのです。 犯罪学における割れ窓理論は批判的な意見も多く見受けられますが、ことソースコードの品質という点に関していうと、割れ窓理論は十分に現実に即しているのではないかと思います。理論や可能性の問題ではなく、これは十分に起こりうる問題なのです。 実際問題、私が携わったプロジェクトでも、ある時点からPEP8(pythonのコーディング規約)違反のソースコードが増え始め、試験の頃には目を疑うような品質の物が出来上がっていたことがありました。これも初めからソースコードの品質が悪かったわけではなく、Gitのヒストリーでみてみると、本当にある時点からソースコードの品質低下が発生していたのです。 小さな問題を放置することは、チーム内の品質に対する意識低下につながり、その結果、十分に自己レビューもできていないソースを平気でプルリクするような悪しき環境が生まれてしまうのです。 一度このような環境ができて仕舞えば、それを元に戻すのは非常に労力がかかります。人間の意識はエントロピーのもので、混沌とした状態から統制の取れた状態にするには大きなエネルギーが必要となってしまうのです。 小さなミスを修正するために態々コミットを打ったり、レビュー指摘・再レビュー依頼のやりとりをすることが億劫だというのも勿論分かります。ですが、チーム内でのソースコード品質に対する意識を高く保つためには、例え小さな過ちであったとしても、見つけたらなるべく早く指摘・修正するべきなのです。

クラス図(UML)まとめ&Excelでのサンプル図

クラス設計で作成するクラス図(UML)について自分なりにまとめてみました。
初めて設計に携わる新人・若手の方向けに分かりやすく書いたつもりです。
excelでの書き方サンプル(テンプレート)も用意したので是非使ってみてください。

オブジェクト指向がよく分からないのでいろいろ調べた自分用のメモです。 目次 オブジェクト指向の意味(wikipedia) オブジェクト指向とは? オブジェクト指向で何が嬉しいのか? オブジェクト指向の3大要素 オブジェクト指向の5原則(SOLID原則) 1.オブジェクト指向の意味(wikipedia) オブジェクト指向(オブジェクトしこう)とは、オブジェクト同士の相互作用として、システムの振る舞いをとらえる考え方である。英語の object-oriented (直訳は、「対象物志向の」「目的重視の」という意味の形容詞) の日本語訳である。 オブジェクト指向 – Wikipedia わかったような、分からないような。データ指向設計と比べてみるとなんとなく分かるような気もしますが、オブジェクト指向で何が嬉しいのかはまだ掴めないです。そもそもオブジェクトとはなんなのでしょうか? 2.オブジェクト指向とは? オブジェクトという単語を日本語に訳すとするとカタカナ表記の”モノ”がフィーリング的には一番近いでしょうか。クラスも関数も構造体も、プログラミングの世界では全てオブジェクトという扱いになるみたいです。ただ、このオブジェクトという言葉で分かりにくいのは、設計図であるクラスも実体であるインスタンスも、全部が全部オブジェクトという扱いになってしまうと言うところでしょうか。 このことを踏まえると、オブジェクト指向の「オブジェクト同士の繋がりに重点をおく」と言う考え方も若干しっくりくるような気もします。 手続き型プログラミングが処理の順番をベースにプログラムを考えると言う点と対比させると、オブジェクト指向プログラミングは処理を行うモノをベースにプログラムを考えると言うことなのでしょう。 3.オブジェクト指向で何が嬉しいのか? とりあえずオブジェクト指向がなんぞや、と言うことは掴めた気がします。でもオブジェクト指向にすると何が嬉しいのでしょうか?一般的には、再利用性が高まってコード量が減るとか、保守性が高まるとか言われていますね。 4.オブジェクト指向の3大要素 一般的に言われているオブジェクト指向の3要素には以下の三つがあります。①カプセル化:内部の処理を外に漏らさない②継承:ある機能を元に別の機能を作ることができる③ポリモーフィズム:状況によって動作を変えることができる ①はオブジェクト指向は関係ないですね。カプセル化はプログラミング共通のルール的な側面がありますし。 ②は共通化という考え方になるのでしょうか。確かに共通の何かを作っておいてそれを再利用するようにしておけばコード量を減らすことはできそうですね。ですが、共通部分に変更が入った時に悲劇がおきそうです。事前の設計が大事なんでしょうね。 ③は関数の引数が変わるみたいなものじゃないんですかね。なんか特別な意味があるのでしょうか?? オブジェクト指向の5原則(SOLID原則) SOLID原則と呼ばれるオブジェクト指向設計の5原則は以下の原則からなります。 ①SRP(単一責任の原則)・一つのオブジェクトには一つの責任しか持たせててはいけません。 →データ管理クラスを作ってDBとファイルの両方を管理させるのはダメってことですね。でも、DB管理クラスとファイル管理クラスを作って、それをラップするデータ管理クラスを作るのはありなんでしょうか…? ②OCP(オープン・クローズドの原則)・修正に対して閉じ、拡張に対しては開いていなければいけません。 →クラスに何か追加する場合に既存部分に手が入らないように追加できるような設計になっていないとダメってことですね。 ③LSP(リスコフの置換原則)・サブクラスはスーパークラスで置換可能でなければなりません。 →確かに使う側からしたらスーパークラス使えるならサブクラスも使えると思いたいですよね。サブクラスはスーパークラスよりも引数の条件が緩く、戻り値の条件が厳しければ置換可能と言えるらしいです。 ④ISP(インタフェース分離の原則)・インターフェイスは使い方にあった細粒度の単位で作成しなければなりません。 →使わない実装に依存するのは避けましょうってことですね。 ⑤DIP(依存関係逆転の原則)・依存関係はインターフェイスにもたせましょう。 →外側とやりとりするルールさえ決めておけば内部実装の変更には柔軟だぜ、的なイメージですかね。APIとかOSI参照モデルみたいですね。 オブジェクト指向に出てくるクラスとは?…