Hello Worldからはじめるdaily codingのすすめ

会社で尊敬するエンジニアが教えてくれたdaily-codingがプログラミング・コーディングのレベルアップに良さそうでした。

しかし、良いなと思いつつも、自分にはハードルが高くてなかなか踏み出せませんでした。

ハードルを下げる方法が見つかり、なんだかんだ1か月近く続けられたので、その方法を共有したいと思って書きました。

そもそもこの記事で言うdaily-codingってなんだ？

ググったところ明確な定義は見つかりませんでした。

わたしは、会社の人にこういう取り組みをdaily-codingと名付けてやっているよと紹介してもらったため、ここではわたしが会社の人から聞いたdaily-codingの定義を紹介します。

やること

ものすごく雑に言うと言葉通りで毎日コーディングすることです。
ただ、ものすごく時間をかけてやるのではなくイメージとしては1日30分程度でできることをします。

（初回のみ）GitHubのリポジトリをつくる
その日の作業用ディレクトリをつくる（mkdir $(date "+%Y-%m-%d") && cd $_ってコマンドを打って作っています）
その日のコードを書く
その日のコードをコミットする

GitHubにリポジトリを作ることは、必須ではないです。ただ、日々のコミット履歴が見やすいのでオススメです。

なぜdaily codingをやるのか？

調べないでできることを増やす、ソラで書けるコードを増やすことで理解を深める、ということを目的としています。

これは最近読んだ世界一流エンジニアの思考法の生産性の話でもほぼ同じことが書かれていました。

レベル１:何もググらずに即座に実装できるもの。
...
生産性とはいかに「レベル１」を増やすかではないか

引用: 牛尾剛.世界一流エンジニアの思考法.文藝春秋社,p.102-103

詳しくは最後にも書きますが、体感でも理解は深まったし、手は早く動くようになるため、価値があると思っています。

個人的に高かったハードル

会社の人には社内のLTでdaily-codingを紹介してもらいました。

その人は以下のように紹介していました。

できるだけ、エディターによる補完機能やあまり調べなくてもできるようなコードを書く
同じことでもいいから毎日イチから書いてみる
筋トレのようなものであり、継続することが大事

良さそうだと思ってやってみようと思いましたが、その人が実際にやっていることを聞いたときに、ハードルが高く感じました。

まず、おもむろにquick sortを書いてみます
あえて次の日もquick sortを書いてみます
次の日は別の言語でquick sortを書いてみます
その次の日は別のアルゴリズムを書いてみます

実際に書いたコードを公開しているリポジトリも見せてもらいましたが、コメントなどもきっちり書いていてこれと同じことを自分が毎日するには1日に時間がかかりそうでした。

たとえば、quick sortはそこまで難しいアルゴリズムではないと思います。書いたことがある人も多いでしょう。自分も書いたことはあります。
しかし、しばらく書いていなかった自分にとって短時間でquick sortを書くというのはハードルが高いと感じました。

継続できるようにハードルを思いっきり下げる

LTをしてもらって、やったほうがいいなと思いつつなかなか踏み出せなかった日が続きました。
先述の通り毎日quick sortか・・・と思うと、なかなか踏み出せませんでした。
（たぶん、昔自分がquick sortをなかなか理解できず実装もめちゃくちゃ苦労した思い出が強かったのだと思います。）

ある日、daily-codingを紹介してくれた人にどんな感じでしているのですか？って聞いてみると、「仕事終わってお酒飲みながら書いてますよ〜」って言われました。

これをヒントに仮に自分がお酒を飲みながらでもできるようなことってどんなことかな？と考えて見ると、Hello Worldを標準出力するコードならばできるぞ！と思えました。

それまで躊躇していましたが、おもむろにGitHubでリポジトリを作ってはじめることができました。

一日目C言語でHello World

二日目Go言語でHello World

まずは一番慣れている言語でやってみる

最初は一番慣れている言語でやってみると良いと思います。

daily-codingをはじめるのならば、せっかくだし触ったことがない言語の勉強も兼ねてやるぞ！というのもありだとは思います。ただ、そうすると環境構築や基本文法を調べる時間が必要になるため、人によっては取り組むときのハードルが高くなると思います。

自分は最初にはじめたとき、普段使っていないくせにせっかくだからとC言語でhello worldを標準出力するコードを書きました。ただ、かなり久しぶりだったため、そもそも今のPCって開発できる状態だったかな？と調べるところからはじまりました。

たまたま、躓くことなく進められましたが、もし躓いていたらモチベーションが下がって続かなかったかもしれません。

継続できるように、極力コードを書くだけでいいようにはじめるほうがいいと思います。

Hello Worldをいろんな書き方をしてみる

Hello Worldを標準出力するコードを書けたら次はどうするか？

なにかしらのアルゴリズムを書いてみるのにすすんでもいいと思いますが、もしまだそこまではできるかな？と不安があったら、Hello Worldをいろんな書き方で実装してみるのも良いと思います。

たとえばPythonだったら

strings = ["H", "e", "l", "l", "o", " ", "W", "o", "r", "l", "d"]
for s in strings:
    print(s, end="")
else:
    print()

慣れている言語でだとつまらなかったら、新しく触る言語で、基本的な文法や構文のif, for , while, switchなどを使ってHello Worldを書いてみるとか。

ハードルを高くしすぎずに継続するためのポイント

そんな感じでHello Worldをいろんな書き方で書いてみると、だんだんと慣れてきます。次はバブルソートを、その次はクイックソートを、というように、だんだんと難易度を上げてもできるようになりました。

しかし、難易度を急に上げすぎたり、あれもこれもとやりたいことをやって時間がかかったり疲れると、取り組むのがしんどくなったときはありました。（実際、時間的な余裕はあったのにスキップしたことがありました）

ここからは自分がやってみて、取り組むハードルの高さをを保つために役立ったと思えたことを紹介します。

時間を決める

期待する動きをするまでやりきると気持ちいいです。
ただ、毎回そうしていると、自分の中で「daily-codingとはやりきるまで延々とするもの」だと思うようになり、いつのまにかハードルが高くなるかもしれません。
というわけで、時間を決めることをおすすめします。

時間を決める効果は以下もあると考えています。

忙しくてほとんど時間を割けないときでも続けられるようになります
- 個人的には30分とか1時間ぐらいがいいのではないかなと思っています
  - 15分でもいいかもしれないです
時間制限を設けることで今の自分がイメージ通り時間内に終えられる力量があるのか知る機会になります
- 時間内にうまくいかなかったら、なにか理解不足のところがあると気づけます

もし時間になってももうちょっとやりたいなと思ったら、わたしは今のところ以下のようにしています。

もう少しやってみる
- やる気もあって、時間もあるならばその日はやってみるのも良いと思います
TODOコメント書いて次の日のやることにする
- 例：もっと良い変数名をつけたい、その言語らしい書き方をしたい、など

思ったとおりに動かなくても良しとする

自分にとってはハードルが低い目標に設定したけれども、うまく動かないときはあります。また、しばらく触っていなかったために環境構築からはじめることになり、コードを書く時間がなくなってしまうこともあります。

そのときは、割り切って、思ったとおりに動かなくても良しとしましょう。
書きかけでも、実行時エラーがでても、そのままコミットしてしまいましょう。
悔しさやモヤモヤが残るかもしれませんが、次の日もやるモチベーションになります。

また、やろうとしていることが自分にとってハードルが高いのかもしれません。
日をおくことで、どこまでわかっていて、どこまでがわかっているのか、見直す機会になります。

どうしても中途半端な状態で終わりたくないときは、コンパイルが通るか実行できる状態にまでして、意図通り動いているのはここまでだと整理して終えるというのも1つだと思います。

お題を一覧にしておく

今日はなにしようかな？と悩む時間ができやすいと、モチベーションは下がりやすいと思います。そのため、書いてみたい言語と処理をそれぞれ一覧にしておくと、今日は何を書こうかなと迷いにくいです。

サンプル: 書くこと候補の一覧を作っておくと悩まないのでオススメです。

処理と言語2つの項目を作っているのは、組み合わせで多くのパターンを作れるためです。

たとえば以下ならば4 * 6 =24パターンできます。

言語: Python, Go, Rust, TypeScript
処理: Hello World, FizzBuzz, stack, queue, Bubble Sort, Quick Sort

先日書いたコードのお手本を探してその日のお題としてみる

その日のお題に関することでもう1つ。

ある日書いたコードもっとよく書くとしたらどう書けるだろう？と考えるときがあると思います。
書けた！と思ったら、同じ処理をしている他の人のコードを見てみましょう。
ググるか、GitHubを検索すれば出てきます。
そして、完全に同じ内容の人はいないと思います。

違いを確認して

良さそうな書き方をしていたら次の日はそれを取り入れて書いてみる
違いについてわからないことがあれば調べてあらためて書いてみる

と、ちょっと勉強になります。写経するのではなく、一度参考としているコードは画面に移さず、自分で書いてみると本当に理解しているか確認にもなります。

お金はかかりますが、GitHub Copilot Chatで、聞くのも個人的におすすめです。わからないことがあったらすぐに、この部分はどういうこと？って聞けるので。

以下はgo言語でバブルソートを書いたあとに、聞いたときのやりとりです。
このときはスワップの存在を忘れていたことに気づけました。

daily-codingをやってみてどうだったか？

当初の目的は果たせた

基本的なことをソラで書けるようになっていっているというのは、2週間ぐらいで感じます。
とくに久しぶりに書いた言語で書くと顕著に感じます。

Hello Worldから始めましたが、今はある程度ソートアルゴリズムとか書けるようになりました。
かなり前ですが私はソートアルゴリズムを書いたことがあったため、hello worldからはじめるdaily-codingをすれば数週間でアルゴリズム実装をできるようになります！ということは言えません。
ただ、hello worldからなにかしら着実にステップアップできると思っています。

あと、その日、コードを書いていないとムズムズしてくる不思議な感覚がだんだん出るようになりました（会社の人が言っていたとおりだった）。習慣っておもしろいですね。

テストコードを書くようになった

少しずつですが、テストコードを書いてから実装するようになりました。書くのも何回か書くと手慣れてきて、今までは


def main():
    ...

if __name__ == "__main__":
    main()

と書いていたエントリーポイントのところを


class Test(unittest.TestCase):
    def test_xxxx(self):
        param = "xxxx"
        expected = "xxxx"
        actual = xxxx(param)
        self.assertEqual(expected, actual)

if __name__ == "__main__":
    unittest.main()

と書くようになりました。
テストコードを書く癖がついたのと、今日書いたコードはちゃんと動くコードだとある程度自信を持てるようになりました。

なにより楽しい

自分にとってちょっと難しいと思っていたものが少しずつできるようになるため、楽しいです。
自分の興味範囲があらためて見えてくるのも楽しいです。
- 私の場合はコーディングだけではなく、環境構築も気になるんだなと改めて気づけました。
  - 唐突にdockerを使ったC言語のコンパイルできるようにしようとか、パッケージ管理ツールをためしたり。（厳密にはコーディングではないのではないかとセルフツッコミしつつ）

さいごに

最近はじめたdaily-codingですが、これからも続けていきたいと思っています。（続けられるように、ここで表明してちょっと自分にプレッシャーをかけてみる）

daily-codingでなくとも継続的に続けたいことができたときは、まずはめちゃくちゃ難易度をさげて、取り組むハードルを下げる。これは、なにかしら新しいことを継続して取り組むときには役立つと思います。

参考になれば幸いです。