生き様153. 汚くてもいいからまず書く!
本当は話したくないプログラマ事情
実は、今回のネタは初心者~中堅プログラマには「助かる」内容となる一方で、
ベテランプログラマからは「余計なことを言うな!」と言われる内容になります。
自分自身の首を締めることにもなるでしょう……。
コメント欄にも、ベテランプログラマの恨みの声がたくさん届くことが予想されます。
それでも、今回取り上げないわけにはいかないのです!
下手の考え休むに似たり
特に初心者プログラマに多くみられる事象ですが、
「どんなコードを書けば良いか判らなくて手が止まる」
ということがあります。
残念ですが、そんなことを何時間考えても、答えは出ません。
考えて悩んで停止している時間があるなら、1行でもコードを書くべきです。
「いや、その書くコードが判らない」という話です。
これに対して、僕はこう答えています。
「その時思いついた、一番汚いコードで書く」と
手を止めて悩んでるよりも、汚くても良いから処理を書きましょう。
書くべきことが判らないなら、仕様書を確認しましょう。
そのコードは、命名規則に沿ってなくても、コーディング規約に反していてもOKです。
まず、コンパイルが通って、思った通りに動くところを目指すのです。
どうでしょうか。これならできそうですよね?
「書いてから考える」方法
ベテランプログラマであるならこそ、まず手を動かす重要性を知っています。
頭の中にあるコードは、所詮頭の中にあるだけの、曖昧なものです。
実際に記述し、動くようになるまで、正しいのかも、良い方法なのかも、解りません。
「もっといい方法があるかもしれない」
この問題は、多くのプログラマが向き合う、永遠の課題です。
2種類処理のイメージがあるなら、2種類の処理を書きましょう。
つまり、動く状態にして比較をするのです。
動かない状態で比較をしようとしても、具体的な指標は得られません。
机上の空論を捏ねること程、無駄な時間はありません。
より良いコードを追い求める場合も、前述の通りまず動くものになってからです。
その上で、動作を担保しつつ、よりキレイで、効率的なコードを探し求めます。
命名規則を見直したり、コーディング規約に合わせるのも、この探求の中で行います。
「コードは書いた時点で古くて汚いもので、より良い新しいコードがあるはず」
この探求を、僕はこう表現しています。
本来の意味の拡大解釈にはなりますが「小さなリファクタリング」とも呼んでいます。
もちろん、時間は有限です。
いつまでも、より良いコードを追い求めているわけには行きません。
どこかのタイミングで、コミットしたものを、プッシュしてマージする必要があります。
ですが、その前にできることをしましょう。
コードを一発書きする必要はないのですから。
「自己レビュー」を当たり前にする
「自分の書いたコードを二度と見たくない」という人達は一定数居ます。
僕もその中の1人です。
数学のテストの答案とか絶対に見直ししなかったタイプです。
しかし、現実的な作業として、コードは何度も見直します。
手癖で一度書いて、規約に沿うようにもう一度見直して、更に全体で見直す。
習慣として、最低2回はコードを見直しています。修正するかは別にして。
これは、一種の「自己レビュー」です。
もちろん、これまた厳密な意味での「自己レビュー」ではありません。
ですが、自分自身が他人に見せても恥ずかしくないコードであるのか。
他人に解る様にコードを書いているか、という点は強く意識して改善しています。
「自己レビュー」という言葉に、高いハードルを感じている人も多いでしょう。
ですので、このぐらいの内容からチャレンジしてみる、という事です。
このサイクルに慣れてきたら、更に見直す項目を増やしましょう。
例えば、レビューを受けた際によく出る指摘事項をメモしておいて、見直す際のセルフチェックリストを作るのも良いでしょう。
よく出る指摘事項は、自分が忘れやすい箇所です。
チェックリスト等、見える状態にして確認できる様にすることが大事です。
手を止めるベテランプログラマ
時々、仕事中にぼーっとしているベテランプログラマの姿を見かけます。
焦点の合わない眼で虚空を眺めていたり、寝ているかの様に俯いています。
声を掛けると大体揃って「今、コードを考えていた」と言います。
白栁自身も、経験があることです。
一間サボっている様に見えますが、その実は「何も考えていません」。
居眠りしていることも……たまにあります。白栁は(※個人の感想です)。
ベテランプログラマであるならこそ、手を動かす重要性を体験しています。
考えるときこそ、実際に手を動かします。
頭の中でコーディングする時は、手元に動かせる環境が無いときだけです。
(よく、道端で歩きながら脳内コーディングをしています)
手を止めて、ボーっとしているからと言って、必ずしもサボっている訳ではありません。
実は、別の目的があるのですが……。
その話は、いつかどこかで改めてしましょう。
今回のまとめ+α
- 考える時ほど、手を動かそう
- まずは「その時思いついた、一番汚いコードで書く」こと
- 「コードは書いた時点で古くて汚いもので、より良い新しいコードがあるはず」
- 自己レビューの習慣を作る
- どこかで妥協する
今回お話した内容を、もっとブラッシュアップした言葉が存在するそうです。
【Make it Work. Make it Right. Make it Fast】
白栁流に訳するなら
【まず動くものを作る。次に明確にする。そして高速化する。】でしょうか。
英語のドキュメントですが、こちらに記載があります。
テスト駆動開発を前提として書かれている文章ですが、海外コミュニティのプログラマ達が検討したものです。
多くの先人が悩んだポイントだからこそ、この様な言葉も残っているのだと、考えています。
以上!
お知らせ:登壇イベント宣伝
今回の記事の一部を、5分のLTとしてこちらのオンラインイベントで発表します。
株式会社ラクス様 主催 「リファクタリングLT 〜毎日こつこつちょっとずつ〜 」
日時:2022年7月28日 19:00~
イベントURL(connpass):https://rakus.connpass.com/event/250579/
まだ参加枠は受付中ですので、白栁の発表やテーマ自体に興味のある方はどうぞ。
コメント
nyuge1631
"Make it First." -> "Make it Fast." ですね。
エンジニアカウンセラー白栁隆司
To:nyuge1631 さん
ご指摘ありがとうございます。
その通りですので、修正させて頂きました。
技術進歩が早いのでずっと初心者
まずは紙に手書きでフローチャートを書いて、次に紙に手書きでコードを書いてから、コンピュータにコードを入力していた時代からのプログラマーです。
残念ながら「余計なことを言うな!」と言えるところがなく、概ね賛同できる内容でしたので、ベテランの仲間入りはできていなさそうです^^;
あえて強めに言っておられるのかもしれませんが、手が止まっていても考えて悩む時間も無駄ではないと思っています。
考える力が養われるかもしれません。
【まず動くものを作る。次に明確にする。そして高速化する。】については
想定した条件の下で動くものは比較的簡単に作成できるようになると思いますが、想定外の条件の下で動いてしまうと不具合や脆弱性となりますので、【次に明確にする。】では品質も意識して、汚くてもいいから不具合ゼロを目指したいですね。
エンジニアカウンセラー白栁隆司
To:技術進歩が早いのでずっと初心者 さん
コメントありがとうございます。
フローチャートや手書きコードを経験している大ベテランの方に太鼓判を押して頂けて、嬉しい限りです。
もちろん、手を止めてる時間も大事です。
その辺りのベテランの時間の使い方は、また別のコラムで書こうと思っていますので、その際は是非目を通して頂けたら嬉しいです。
【まず動くものを作る。次に明確にする。そして高速化する。】は、TDDの文脈の中で語られている言葉ですので、品質に関しては先に準備されているテスト部分で担保されている(もしくはテストを同様に書きながら担保してく)ということなのでしょう。