プログラミングで気をつけていること
はじめに
プログラミングには「正解」があるようで、実際には状況ごとの判断の連続だ。
言語やフレームワークが変わっても、長く使えるコードを書くために共通して気をつけていることがいくつかある。
本記事では、日々の開発の中で自分が意識しているポイントを整理してみる。
1. 「動く」よりも「なぜ動くか」を意識する
実装が完了すると、つい次のタスクに進みたくなる。
しかし、以下の問いに答えられない状態は危険だと感じている。
- なぜこの実装で要件を満たしているのか
- どこまでが前提条件なのか
- どこが壊れやすいポイントなのか
動作確認できた＝理解できたではない。
「説明できるかどうか」を、自分の中で一つの基準にしている。
2. 名前を雑に付けない
変数名・関数名・コンポーネント名は、コード上の「文章」だ。
datalisttemphandleSomething
こうした名前は、書いている瞬間は楽だが、後から読むとほぼ情報を持たない。
名前を付けるときは、
- それは何か
- なぜ存在するのか
- どの責務を持つのか
を最低限表現できているかを意識する。
命名に迷う場合は、設計自体が曖昧なことが多い。
3. 将来を読みすぎない
「将来拡張できるように」と考えすぎた結果、
- 使われない抽象化
- 複雑なインターフェース
- 誰も触れない汎用クラス
が生まれることがある。
意識しているのは、
今わかっている要件に、正直に応える設計か？
将来の変更に強いコードとは、
「最初から複雑なコード」ではなく、変更しやすいシンプルなコードだと思っている。
4. コードは必ず「読まれる前提」で書く
コードの読者は、未来の自分か、チームメンバーだ。
- この処理は一目で意図が伝わるか
- コメントがなくても読めるか
- ファイルの責務は明確か
レビューで説明が必要になるコードは、
多くの場合、コード自体に改善余地がある。
5. 「書いたあと」に一度立ち止まる
実装が終わった直後に、必ず一度こう問い直す。
- このコード、明日見ても理解できるか？
- 行数や責務は適切か？
- 今ここに置くべきロジックか？
数分立ち止まるだけで、
不要な条件分岐や重複処理に気づくことが多い。
おわりに
プログラミングで気をつけていることは、
特別なテクニックというよりも姿勢や考え方に近い。
- なぜそう書いたのかを説明できるか
- 誰かが読んだときに迷わないか
- 将来の自分を困らせないか
コードは書いた瞬間よりも、
読まれ、直される時間のほうが長い。
だからこそ、「今だけ」ではなく「少し先」を意識して書き続けたい。