「Software development topics I've changed my mind on after 6 years in the industry」という興味深い記事が盛り上がっていたので、自分の感想を少々書いて見ようと思います。
自分の感想の前に参考までに意訳を掲載しますが、正確には原文を参照してもらえると幸いです。
記事の意訳
考えが変わったもの
かつての私であれば反論したであろうが今は信じていること
- 経験のレベルが様々な人からなるチームで働く時には、型付言語の方が良い
- スタンドアップは、新人を見守るのに実に有益である
- スプリントレトロスペクティブは、本当に進路を修正するためであり、かつ、「アジャイル」「スクラムマスター」とかいうやつが行う時間の無駄遣いのためでない限り、やる意味がある
- ソフトウェアアーキテクチャーは、おそらく他の何よりも重要である。良い抽象化のクソ実装は、コードベースにとって、実質的には害にならない。ダメな抽象化やレイヤーの欠落は、全てをゴミにしてしまう
- Javaは言語としてそんなに悪くない
- クレバーなコードは普通、良いコードではない。明快さが他のどんなことにも勝る
- どんなパラダイムにおいてもダメなコードは書かれる
- いわゆる「ベストプラクティス」は、状況によるし、幅広く適用可能ではない。盲目的に従うのはバカである。
- 必要もないのにスケーラブルなシステムを設計するのはダメなエンジニアである
- 静的解析は役に立つ
- DRYは、一つの限定的な問題の予防にまつわるものであって、それ自体が最終目的ではない
- 一般的に、RDBMS > NoSql
- 関数型プログラミングは、ツールの一つであって、万能薬ではない
途中で取り上げたもの
- YAGNI、SOLID、DRY。この順序で。
- 鉛筆と紙は、とても良いプログラミングツールである
- 現実的であるために綺麗であることを諦めるのは通常は良い判断である
- テクノロジーをさらに追加するのが良い判断であることは稀である
- 顧客と直接話すことは、常に、問題についてより多くのことをより少ない時間でより正確に明らかにする
- 「スケーラブル」という言葉は、ソフトウェアエンジニアの精神に異常をきたす不思議な力がある。その言葉を発するだけで、エンジニアを狂乱状態にさせることがある。理不尽な行為もこの言葉を使うと正当化される
- 「エンジニア」と呼ばれているにも関わらず、ほとんどの判断は、支えとなる分析やデータや数値を持たないカルトである
- 100を超える面接を実施した後で：面接は全くうまくいかない。さらに、面接をどう改善すべきか全然分からない
昔からの考えで変わっていないもの
- コードスタイルやlintルールなど細かいことを強調する人は変な奴である
- コードカバレッジは全くもってコードの品質と関係がない
- モノリスはほとんどの状況でかなり良い
- TDD原理主義者は、最悪である。彼らのか細くてちっちゃな心は他のワークフローの存在を処理することができない
自分の感想
Javaは言語としてそんなに悪くない
昔と比べるとJava自体も変わったし、Javaを扱うツールやIDEも進化したなぁと思う。 テクノロジーの選定は、視点を広げて、開発環境やエコシステム、ワークフローを含めて考えるようにしたい。
面接は全くうまくいかない。さらに、面接をどう改善すべきか全然分からない
面接を改善するのではなく、インターンや筆記テスト、課題制作などを課すことで、面接で審査すべきことを極力減らすのが良いと思う。
現実的であるために綺麗であることを諦めるのは通常は良い判断である
綺麗さにこだわってしまうのが自分の悪い性癖なので、気をつけたい。
YAGNI、SOLID、DRY。この順序で。
最近、新卒エンジニア教育で教えるようになった。新卒エンジニアの皆さんは割と頑張ってYAGNIに反した物作りをしてしまう傾向にあると思うが、YAGNIとDRYは新人の間に浸透させることが出来たと思う。SOLIDは、多分Sしか理解してもらえていないと思うけど、新人さんには最先端の技術よりもこういう基本的な考えをまずは身に付けてもらいたいと思います。
どんなパラダイムにおいてもダメなコードは書かれる
所属している組織でよくあることだが、使いこなせていないフレームワークで書かれたくそコードの保守がしんどくなってくると、フレームワークが古いことが問題の原因であるとされて、新しいフレームワークへの移行が行われる。
当然、開発者の基本的なスキルが上がっていないわけで、新しいフレームワークを使いこなせるわけでもなく、くそコードがもう一度生産される結果になっている。
くそコードから脱却するには、テクノロジーのせいにするのではなく、ちゃんとしたコードを書ける人を採用したり、教育することが重要だと思う。
あと、こういう系の話は昔読んだソフトウエア開発 55の真実と10のウソという本に調査結果も交えてよくまとめられていたので、組織的な判断をお偉いさんとする場でスッと出せるように読み直しておきたい。
