Architecture Astronauts

当社ではビジョンを実現するために、クラウドやデータエンジニアリング関連の技術教育を全社として進めている。しかし、プログラミングももちろん重要。 当社ではHULFT Seriesをはじめ、多くの製品があることから、C, アセンブラ, Java, C#, Typescript, Go, Pythonなど多岐にわたる。

そんな中、ふと1on1をしているときに気付かされたことがある。言語の違いはあれど、新しくチームに入った人はコードを書いてレビューを出す時に妙な緊張感を抱えているのだ。それは最近入ったという理由だけではなく、レビュー指摘方法や、コードレビューの回数に起因していることがわかった。
レビュー回数が多いということは、２回目のレビュー以降で新たな指摘が追加されている可能性がある。多少は致し方ないがこれが続くと、何を書いたら正解なのかわからないという状況が発生する。それが緊張の要因になっている。

HULFT Squareは日米チームで開発しているので、そのあたりについて感じるギャップを書いてみる。 日本ではオブジェクト指向、デザインパターン、DDD的なアーキテクチャなど多くの手法について稀にすごくこだわりを持つ人がいる。

USメンバーでは全てではないが、コーディング標準に記載がない場合はそういうものにはこだわりが少ないと感じる。彼らはより実践的なコードを好むし、レビュー指摘があった場合は、それがコーディング標準に反映されることを期待する。 一番は誰かの脳内の謎のルールの存在を嫌う。

Joel SpolskyがかつてArchitecture Astronautsと揶揄しているが、過剰な複雑さよりも実用性をUSでは重視しているのだろう。

Don’t Let Architecture Astronauts Scare You

最近話題の雑魚プログラマの件もそうかもしれないが、正論と実用性は非常に難しい議論だが、そこにコーディング標準や、レビューの方法などのプロセス化や一定のマネージメントがそれを救うと考えている。

それはプログラミングを書かない管理職ではなく、スタッフプラスのエンジニアの仕事になるが、その辺りのジョブディスクリプションの未整備も問題なんだと思う。ここは改善して行きたい。