アンチパターン、バッド・プラクティスを知ろう

アンチパターン―ソフトウェア危篤患者の救出

ＩＴアーキテクトのやってはいけない 設計、メソドロジ、実装・テスト、運用、セキュリティのアンチパターン (日経BPムック)

44のアンチパターンに学ぶDBシステム (DB Magazine SELECTION)

SQLアンチパターン

何かを学ぶ際、基本的には「良いもの」を多く持っている、「良いこと」をたくさん行っている人が多い環境に身を置くべきだ。「自分もこうやっていこう」と奮い立たせてもらえる環境を大事にしたい。

一方、「真似たら良くないこと」「やってはいけないこと」という情報も、絶えず収集しておいた方が良い。思い付いても実行してはいけない事柄を把握しておくと、間違ったアドバイスを鵜呑みにしなくなり、自分の方向性を誤らずに済む。

一般に悪いものとされている事柄は、アンチパターンとか、バッド・プラクティスと呼ばれる。「Java におけるアンチパターン」「設計書執筆におけるバッド・プラクティス」など、分野ごとに先人の知見が発信されているので、何かを学ぶ時は「べからず」集も学んでおくと良いだろう。

• 参考：真似をする前にバッドプラクティスかどうかを調べてみよう - Qiita

何かを真似する時に、本当にそれを真似して良いのか調べる癖をつけよう。「誰かに言われたからやった」だけではそうしていい理由にならない。

• 参考：保守開発に開発者として入って困ることのまとめ（実体験） - Qiita

俗にレガシーシステムとか言われる環境。保守しづらくて仕方ないシステムとはこういうもので、こういうシステムにしないために対策を考えていくことを怠らない。

• 参考：自社フレームワークで開発していますという案件を地雷と思ういくつかの理由 - Qiita

自社フレームワークとは、得てして「四角い車輪の再発明」になっている。自社フレームワークを作っている程度の組織は、全体的に OSS に関する知見が少なそうだ。

OSS は、自社フレームワークよりも関わる人間が多く、コミュニティが大きい。それだけ皆の知恵が詰まったプログラムなワケだから、少人数のショボい連中が作った自社フレームワークなんて無価値だ。

なぜ、OSSとして公開出来ないのか？ということを改めて考えてみるべき

業務のクリティカルな情報はF/Wに依存すべきではない

• 参考：ドキュメント作成時のあるあるアンチパターン20 - Qiita

文書を書く時に、自分の感覚で毎回同じように書いてしまっていないだろうか。その都度読み手の状況に応じて、どういう書式で書くべきか、どこをどう目立たせると効果的か、などを考えよう。

• 参考：コピペプログラミングの本当のダメな理由 - Qiita

コピペプログラミングは、ソースコードが汚くなっていくとか、共通化できていないとか、そういう指摘もできるが、根源は成果物に対する説明責任が果たせないことが問題。

その人への信頼だったり、成果物の質が疑われてしまいます。

コードに限らず、自分で作っておきながら自分で仕組みや意図を説明できない成果物を作ってはいけない。

---

反面教師の事例をたくさん持っておき、「そうならないようにするためにはどうするか」を考え、情報収集していこう。

SQLアンチパターン [ ビル・カーウィン ]

44のアンチパターンに学ぶDBシステム （DB　magazine　selection） [ 小田圭二 ]

ITアーキテクトのやってはいけない 設計、メソドロジ、実装・テスト、運用、セキュリティのアンチパターン (日経BPムック) [Nov 17、 2009] 日経SYSTEMS9784822229924【中古】