アンチパターン、バッド・プラクティスを知ろう
何かを学ぶ際、基本的には「良いもの」を多く持っている、「良いこと」をたくさん行っている人が多い環境に身を置くべきだ。「自分もこうやっていこう」と奮い立たせてもらえる環境を大事にしたい。
一方、「真似たら良くないこと」「やってはいけないこと」という情報も、絶えず収集しておいた方が良い。思い付いても実行してはいけない事柄を把握しておくと、間違ったアドバイスを鵜呑みにしなくなり、自分の方向性を誤らずに済む。
一般に悪いものとされている事柄は、アンチパターンとか、バッド・プラクティスと呼ばれる。「Java におけるアンチパターン」「設計書執筆におけるバッド・プラクティス」など、分野ごとに先人の知見が発信されているので、何かを学ぶ時は「べからず」集も学んでおくと良いだろう。
何かを真似する時に、本当にそれを真似して良いのか調べる癖をつけよう。「誰かに言われたからやった」だけではそうしていい理由にならない。
俗にレガシーシステムとか言われる環境。保守しづらくて仕方ないシステムとはこういうもので、こういうシステムにしないために対策を考えていくことを怠らない。
自社フレームワークとは、得てして「四角い車輪の再発明」になっている。自社フレームワークを作っている程度の組織は、全体的に OSS に関する知見が少なそうだ。
OSS は、自社フレームワークよりも関わる人間が多く、コミュニティが大きい。それだけ皆の知恵が詰まったプログラムなワケだから、少人数のショボい連中が作った自社フレームワークなんて無価値だ。
なぜ、OSSとして公開出来ないのか？ということを改めて考えてみるべき
業務のクリティカルな情報はF/Wに依存すべきではない
文書を書く時に、自分の感覚で毎回同じように書いてしまっていないだろうか。その都度読み手の状況に応じて、どういう書式で書くべきか、どこをどう目立たせると効果的か、などを考えよう。
コピペプログラミングは、ソースコードが汚くなっていくとか、共通化できていないとか、そういう指摘もできるが、根源は成果物に対する説明責任が果たせないことが問題。
その人への信頼だったり、成果物の質が疑われてしまいます。
コードに限らず、自分で作っておきながら自分で仕組みや意図を説明できない成果物を作ってはいけない。
反面教師の事例をたくさん持っておき、「そうならないようにするためにはどうするか」を考え、情報収集していこう。