問題を解決するためだけにコードを書く

問題を解決するためだけにコードを書く

  • 当ブログで一番伝えたかったことです

コードを書くのは最終手段

  • コードは必然的に書かなければならない時にのみ書かれるべきです
  • なぜならば、不要なコードは常に単なる複雑さを提供するだけのものだからです
  • バグを生まない最良の手段はコードを書かないことです

そのコードが必要であるかを確認する

  • 書かなくても良いコードを書いていませんか?
  • もしくは、書いたはいいが置き換えされてしまうコードを書いてはいませんか?
  • もしもあなたのコードがこれらを満たすのであれば、仕様や設計、ロードマップの見直しをしましょう
  • 私自身前職で2週間ほど掛けたコードがリリースされないという憂き目に遭いました
  • 原因としては仕様に対する無知と関係者への早期な設計レビューを依頼しなかったことが挙げられます

書かれるべきでないコードとは?

  • 置き換えが予定されているコード
  • 設計の段階でしっかりとヒアリングされずに書かれたコード
  • そもそも設計が為されていないコード
  • また、設計段階でレビューがなされなかったコード
  • 正しく要件を満たすことが出来ないコード
  • 要件を満たしてはいるが、別の関心事が発生した際にとりあえず書かれるコード
  • テストコード等に関しては別の機会に書きたいと思いますので割愛

私の立ち位置

  • エンジニアがすべきことは誰かの問題の解決を図ることです
  • ここでいう問題とは主に以下の二つです
  • 誰かがシステムの不備で困っていること
  • 誰かが猥雑な仕事を余儀なくされて、本質的な問題に取り組めないこと
  • 上記の二点を解決すること、そうあり続けるべく研鑽を積むことが良いエンジニアのあるべき姿だと信じます

よくない対象

  • コードを書く上で向き合うべき対象は困っている人間だと信じます
  • つまり、下記の様なものがコードを書く目的であれば見直しを図るべきです
  • 上司からいわれたので従う、要件とか誰のためかとかは知らない
  • リリーススケジュールが決まっているのでそれを満たす
  • 上記の様なことが発端で生み出された場合は、概ねおぞましいコードを世に放つ要因となりえます
  • これらの問題の共通点は本質的な問題に向き合っていないことです
  • そして、多くの場合においてそれは共有不足から発生しうるものです

伝えたいこと

  • エンジニアの本質は問題解決
  • 誰かが困っていることに向き合おう
  • 困っている誰かに向き合おう
  • 仕様を正しく理解することで説明責任を果たせるのであればコードを書く必要はない
  • あなたがコードモンキーでないなら何のためにコードを書くのかを正しく理解することから始めましょう