サマリ
github に 1年間休まず 草を生やし続けてみて の 気づき について の まとめ。
なぜ、はじめたのか?
自分のIoTのプロジェクトなどを公開はしていたので、githubは、使ってはいました。
しかし、毎日commitを上げるようなものではなく、まとまったお休みの時に、おうちハックなどでscriptやマイコンのソースコード管理に使う程度でした。
自分の公のロールは、アーキテクトではあるがマネージャレベル。プロジェクト全体のアーキテクチャーレベルでの設計議論やその妥当性レビュー、必要に応じて、他のアーキテクトや設計者との議論で、pseudo codeは書くが、商品のコードは書かなくなって久しい。
pseudo codeを書くなどで、codeとは近い距離に常にいたが、もどかしさを感じていた。
それは、現場で、設計の期待の通りに実装がされないことだったり、また、これまでの経験上の期待する進捗で開発が進まないことである。
現場の実力と期待のgapと言ってしまえばその通りなのだが、自分の中で「だったらおまえやってみろよ、背中見せてみろよ」と思い、それをやってみる＝書き始めてみたというのがきっかけである。
気をつけていたこと・気づき
業務が終わってから始める
これは、公私をわけるということ。
しかしながら、公の時間でソフトウェアエンジニアをしつつ、私の時間でも、ソフトウェアエンジニアをするのは、結構大変である。
今はテレワークが主体なので、通勤時間はないが、それまで、業務後は、家族と映画でも見て、一緒にリラックスしていた時間が、コーディングの時間（＝他から見れば業務再び）となる。
そこで、家族にも、自分のやりたいことを説明し、理解して貰った。
オープンな情報のみを活用する
当たり前だが、私の時間での活動なので、社内の情報などを使ってはいけない。
なぜはじめたのか？の経緯から考えれば当然だが、そもそも、やってみせる、ただ言うだけじゃなくて、自分が求めるレベルの実装を自分で作って見せる（＝背中を見せる）のがきっかけなので、当然、0ベースで作り上げる。
(蛇足ながら、最初に背中を見せようかなと思った物は、一度も過去に業務で担当したことのない分野であり、そもそも流用しようにも何もない。)
なお、オープンな情報とは、 1) https://cpprefjp.github.io/ や 2) https://github.com/google/googletest のようなものです。
1)のcpprefは、C++は学生の時から柴田望洋先生で独学はしていたが、折角作るのであれば、新しめのC++の書き方で書きたかったので、そのreferenceとして。
2)は、公では、TDD (Test Driven Development) を推進していたこともあり、test caseをまず書くために、そのフレームワークとして、gtestを使わせて貰った。
オープンにする
きっかけは、背中を見せる、ということでもあり、public projectにするのは勿論、自分の成果物を、ある意味、参考にしてもらえれば、万々歳。permissiveなlicenseにする必要がある。
いろいろなライセンスはあるが、Apache2を選択。
これはそれより前のIoTなどでも個人的にずっとApache2を使っていたため。
始めなければ始まらない
よくあるのは、環境構築して満足してしまうこと。
そうならないように、まず、作ろうと思っている物で、書き始められるところからはじめ、手を動かすところから。
自分のケースではC++だったので、まずはheaderで、ざっくり、class定義から始めた。
また、Makefileだのを書き始めると、その環境構築だけで満足してしまいそうだったので、まずは、clang++ xxx.cppのような形で、直接compileするところから始めた。
そうして、少しずつ手を動かす、をはじめた。
昨日の自分は他人。そして、あえて忘れる
寝る前にコーディングをして、朝、目覚めてから、会社の仕事をして、日々を過ごすと、前日、何を書いていたのか？何をしたら良いのかがわからなくなってくる。
とりわけ、コーディングして、活性化した頭を休めるためにお酒でも飲んで寝ると、より忘れやすくなる。
そこで、全部思いついたことをやりきるのではなく、まずは、TODOをREADME.mdにでも書いて、それをこなしていく、また、codingの締めの後に、TODOを更新(追加含む)する、を日課とした。
* [] Add Parameter Manager
* [] Add ro. (read only) support
* [] Add onChange support
のような形で、WBS的にやろうと思っていることを書き出しておけば、それを見て、context復帰に掛かる時間を短縮し、コーディングに専念できる。
また、寝る前にTODOへの追加で吐き出しをしてしまえば、忘れることができる。
助走も必要
それなりに時間をかけてstudyしないと先に進めないこともある。
連休などに、ある程度集中して、一気に作り上げると、その後に何をしなければいけないのかも結構見通せるようになってくる。
自分は幸いGolden Week前に、この活動を始めたこともあって、まとまった時間をとることもできた。
必ずTest case
何か作るときには、まず、Test caseを作る (TDD: Test Driven Development)を、こころがける。
test caseを書くことで、class/interface designをしているのに等しく、これは、実装レベルでのTODOの作成に等しい。
本題ではないので、詳しくは書かないが、TDDは誰しも、かつ、例外なく、やるべき。
ご褒美も必要
友人にも言われたことだが、自分のオフの時間を使っての活動＝自分の趣味として認識すること。
そうすれば、それは業務ではない。
しかしながらも、業務的なcodingを、やりつづけるのは、それなりのストレスになる。
そこで、自分へのご褒美的なものが重要になる。
別の趣味の時間(私の場合、体を動かすこと)を持つことが重要になる。
また、その趣味に関係するコードを書くのもよいだろう。
Throttling
いくつかのプロジェクトを同時に開発をしていくと、同じ日の中で、複数のprojectで成果があることもある。
githubへの草はやしをある程度続けてくると、やはりつらいときも出てくる。
上のような状況があれば、ネタとして取っておくという大人の対応をしておくのも続ける力になる。
ようは、あんまり根を詰めないこと、時間が取れない、問題が解決しなくてcommitができないときには、documentのメンテナンスだって立派なcommitになる。
旅行
実家への帰省などでは、MBPを持って行くが、一泊二日のソロキャンプに持って行く気はしなかった。
これに関しては、出発前にcommitをpushし、翌日帰ってきてから、また新たにcommitをpushすることで、一泊二日のキャンプであれば、PCを持って行かなくても対応できた。
得たこと・失ったこと
得たこと
- codingの習慣
- codingへの自信
- 自分の別の趣味の効率化 (自分の趣味をboostするためのcodingにより)
- 議論でpseudo codeを書く代わりに、executableなcodeをrefできる
- MacBookPro (何年も使った古いMBPを更新する自分の中の納得材料ができた(笑))
失ったこと
- Gameをする時間(笑)、映画を見る時間
- 近くを見る力 (簡単に言えば、老眼が悪化(笑))
- 多少の睡眠時間
- 家族との時間 (家族には大変感謝)
この一年の活動量
拙作のgit-log-statを利用して、本活動を開始してから、この追記をするまでの活動 (gitでの+と-のlines)をgraph化したものとなる。
Appendix