きのこ本感想 Part5 - What is it, naokirin?

きのこ本

の13〜15の感想を書きます。

基本、この記事の需要はないと信じてます。念のため、読んでいる人がいた際のために注意しておきますが、私はプログラマでは"ない"です。
情報関連についての勉強は完全に独学で、企業でプログラミングをしているわけでもないです。

ですから、この記事についてはそんな私の偏見や妄想想像に基づいて書かれている場合も多いです。ご注意ください。

難しいですね。

レイアウトに語らせるというのは、確かにたまにコードを見ているとそういうコードに出会って「こんなコードが書けるのか…」と感動するのですが、さてそれを自分がやるとなるとどうも難しいですね。

そういうコードを書くためには変数やメソッドの命名の仕方というのは重要なのですが、レイアウトの仕方というのも重要です。
そのことが書いてあるようですね。

エッセイには

と言ったことが書かれています。

最後の部分については短絡的思考の人にこの言葉を与えると「コードの理解ができれば、レイアウトはいらない」といったレイアウトの価値を「小さく」みられそうですが、コードにとってレイアウトは重要な要素だと思います。

もちろんプログラムにとってはさして重要ではないと思います。( Pythonなどのインデントや改行そのものがプログラムに影響するような言語を用いているなどの場合は別として ) プログラムは多少コードレイアウトが変更されても同じ動作をします。

ただしレイアウトの悪い、動けばいいといったコードを書くことは、のちのコストを増大させるのでコードとしては最悪です。( 特に企業などで長期にわたるプロジェクトで個のようなコードを書いた日には、そのプロジェクトとそのプロジェクトに関わる人、そしてその人の将来が心配ですね。 )

この辺りはよいコードに出会うと感じることができるかもしれませんね。一度そのようなコードに出会うと、「自分もこんなコードを書きたい」と思うはずです。「書きたい」と思ったのちには、このエッセイに書いてあるようなことを守っていくべきだと思います。

…思わなくても守りましょう。

コードレビューですね。

とくに複数の人間がいるプロジェクトでは重要なことだと思います。ですが、やり方を間違っていたり、そもそも行っていないことも多いと思います。

まず、スケジュールとしてコードレビューを組み込んでおくことが重要だと思います。
その点はエッセイでも触れられており、毎週決まった曜日に2時間ほどコードレビューの時間を設けるということが書いてあります。

それから、コードレビューを行う際に辛辣な批判は絶対に避けるべき、と書いてあります。コードレビューが建設的であるように心がけ、また楽しいものにした方がよい、というのが著者の主張です。みんな大体そんなものだと思います。

また、上下関係がコードレビューに影響しないようにすべきだと書いてます。これは上下関係でコードレビューに差が出るようでは困るので大切ですね。

実は次に書くことがこのエッセイのコードレビューをよりよく行う際にどうすべきかの一番初めに書いてあることなのですが、レビューを行う際には誤りを見つけることだけでなくコードを「学び」、そして「理解」することが重要だと書かれています。

こういったことができるとコードレビューが無駄な時間になり下がることはないのでしょうね。

コードの論理的検証、最初は何のことかいまいちわかりませんでしたが、関数などを短いセクションに分割してその個々の部分が正しいかを検証することのようですね。

前半にこの検証の行い方について、後半にこの検証を容易にするためのコーディングプラクティスについて書かれています。

この検証を行う際に検証を容易にするコーディングプラクティスは一般に言われているコーディングプラクティスと同じようですね。

基本的には守れていると思いますが、ちゃんと意識して行きたいですね。

コードレイアウト、コードレビュー、そしてコードの論理的検証。
どれも人に見てもらう、見られるということを意識するような内容ですね。

コードを書く際には、コンパイラやインタプリタと言ったツールが見るということと同時に、人が見るものであることも意識すべきですね。