濃縮してお届けしております。
TrendDrivenArchitecture(TDA)。
ふっと思いついたので、書いてみたり。忌むべき習慣です。
Buzzワードに満ちたTDAは妙な訴求力があったりするので、要注意。
チームが少人数かつ、全員がやる気に満ちており、詳細なる調査の結果ならば、問題は起きないでしょう。
チームが大人数かつ、一部でもやる気がなく、雑誌やWebのちょっとした記事を基準にしているのであれば、
それは、熱い時間の始まりを意味します。
最悪なのは、TDAを採用する場合、採用した責任者はとっととトンズラする事です。
もしくは、TDAをプッシュする人間が、プロジェクトの外側に居て、
本質的に彼はステークホルダーでは無い時です。
例えば、OSSなライブラリを採用する時、
プロジェクトの中に一人でも、全てのコードを読んでいる人が居ますか？*1
この余りに単純な質問に対して、Yesと答えられないプロジェクトの多い事多い事。
全てのコードを理解していますか？と、聞いている訳では無いのですが・・・
この質問に対して、回答を濁す様な「アーキテクト風エンジニア」には要注意です。
コンサルタントも同じです。
繰り返します。
あなたがイイと言っているライブラリなりツールなり、ソースコードを全部読んだのですか？
話は少し変わりますが、僕が習慣として行っている事があります。
それは、既に管理されているソースコードの全てを読む事です。
勿論、火事場なのですから、その事自体に工数を割り当ててくれるような事はありません。
サーバを再起動している間の隙間時間。飯を食っている最中の空いた時間。
ほんの少しずつでも、自分の割り当てを越える量の成果物を目にするのです。
自己犠牲的と言えば、その通り。やり方として、色々と問題を孕んでいるのも否めません。
火事場では、状況の苦しさだけを悲観している様では生き残れません。
いつ火が付いたのか？火がついているのに、誤魔化していないか？
知りたい事や、やりたい事は沢山あります。
火種を作った誰かが近くに居ない時、黒い炎が内側に大きくなるのを感じます。
それもまた、楽しみの一つです。
