「根拠のあるコード」を常に書くようにする。レビューで問い詰めてコードの根拠をはっきりさせる。経験上、大体これぐらいしかない。根拠がはっきりしていれば、他とは違うクラスの設計をしても良い。そのクラスの責務はそのシステムで初めて発生したものかも知れない。他の実装と合わせる必要はない。オブジェクト指向の原点に立ち返って、「このクラスの責務は何だろうか?このメソッドはこのクラスの責務を超えてはいないか?」と自問して、「この処理はこのクラスがするのはおかしい。別の名前のクラスがやるべきだ」と感じたら、堂々と新しいクラスを作ればいい。いうパターンの名前は今いじっているシステムには無い?でも散々考えた挙句、あなたはその名前がふさわしいと思ったんでしょ?根拠があるんでしょ?だったら堂々とレビューに出せばいい。FooServiceでピッタリハマる訳じゃない。新しいことをやるとレビュアーに突っ込まれる?根拠を堂々と述べればいい。それが出来ないならきちんと設計ができていない。自信が無ければ作業中でも他の人にクラス設計をレビューしてもらえばいい。実装に手一杯で設計まで手が回らない、なんて言うケースもたまに見かけるけど、それでも設計には時間をかけるべきだし、設計に時間がかかるんならチケットを切る段階でそれを見越して見積もりを立ててスケジュールを切ればいい。それくらい設計フェーズは大事だ。ここを疎かにすると後の人が泣く事になり、いずれ自分も泣く羽目になる。必要ならば新しいことをする勇気を出して欲しい、といつも思う。確かに新しいことは怖い。他と同じような感じで何となくコードを書いて飯を食ってたらいつまでもスキルは上がらない。仮にそれをやって他から突っ込まれても、きちんと根拠を説明して議論することもエンジニアにとっては重要なスキルだと思う。自分が知る限り、説明が下手なエンジニアに良いエンジニアはいない。優秀になればなるほど完結な言葉で端的に説明できる人が多い。議論好きである必要はないけど、きちんと自分の頭で考えて、「これがベストだ!」と思える設計・実装をして、それを周囲に認めてもらいながらものを作り続けられるようにしたい。(1)検索リンクGitHubseri::diary::graduate_schoolseri::diary::competitive_programmingはてなブログをはじめよう!serihiroさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。