「インタプリタの気持ちになってコードやエラーを読む」テクニック。

自己暗示ひとつで、脳のコードへの親和性は意外に変わる。

文系脳のままではコードは解釈できぬ。そう、Rubyでもない限りね。

特にエラーコードのような機械語的なあいつらを読む時は、脳のスイッチを切り替えるのだ。

自分をインタプリタだと思い込め。お前はインタプリタになるのだ。

インタプリタの好物は機械語的なコード群だ

大好物。食えば食うほど満足する。いくら食べても太らない。ただただ美味いだけだ。

そんなイメージで。

 

ミニマリストなエンジニア

コードベースを少しでも前に進めたい

リファクタリング、各種ライブラリのバージョンアップ、TODOコメントの消化、管理されていないprovisioningの手入れ、テストが出来ていない実装へのテスト追加、などなど。

いつでも前に進めるように、コードベースを前進させておきたい。

ただ綺麗なだけではなく、前に進みやすいコードベース。

1週間でどれぐらいのことが出来るだろう。

少しずつ少しずつではあるが、乱雑なコードベースを整えていく。暇を見つけて芝生を刈るように。

クリーンな開発環境を担保することに、僕はモチベーションを持つことが出来る。

私生活でもミニマリストだし、エンジニアとしてもミニマリストだと思う。

ミニマリズムは「やりたいことをやるためにシンプルさを保つ技術」だから。

たとえばgitに慣れてしまってから、gitの初心者向け記事を書くのは難しい

自分が何が分からなかったかを忘れてしまっている。

やはり記事というのは「今、分からない時」に書くべきだ。ホットなうちに。

分からないことは恥じゃないが役に立つ

 

レビューでは、コードに書かれているかを指摘するよりも、何が書かれていないかを指摘する方が難しい。

見えない部分に実装は隠れている。そんな場合もある。

どうやってコードを理解すれば良いか、どうやって実装理解をすれば良いかというのは、エンジニアの永遠の課題である。

Githubでの具体的な話

差分だけではなく、気になったら元のファイル全体もViewで見てみよう。

まずはそんなごく基本的な話から。

PRのdescriptionを丁寧に書くことと、コードを分かりやすく書くことの共通点は、どちらも「人に伝える」というところ。

どちらも本質的に同じ行為だと思う。

ただ、PRのdescriptionが読まれる寿命は短く、コードの寿命は長いだけだ。

 

エンジニアに大事なのは、キャッチアップ。つまり何にでも興味を持って顔を突っ込む好奇心。

格好良く言えば「キャッチアップ」。

でも本当のところ、子供心というか、知らずにはいられない好奇心のようなものだが、一番大事なのかもしれない。

 

勉強のネタに迷ったときのために「勉強ネタのデフォルト」を用意しておこう。Qiitaのタグページとか。

たとえばRuby を使ってる人なら qiita.com/tags/ruby をブックマークしておくとか。

自分で何も思い付かない時の「避難場所」を用意しておくと良いかもしれない。