さて。先日のアジャイルラジオの感想です。
まずは共同所有のこと。
正直、ひとのコードを積極的に「さわる」ことはないです。
コードが見れる環境にあるし、コードレビューもするけど、
「直す」「変える」のは抵抗あるな、と思う。
こういうことをすることに対して
あたまにカッコ書きで「（かってに）」や「（ひとの）」って付く気になる。なっている。
いったん分担を決めてしまうと「そのひとのもの」になってしまう。
バグが見つかれば、それは「あの人の」バグとなり、つくった人が直す。
分担にもそれなりの意味はある。
つくったひとが一番理解しているのだから、ということもあれば、
つくったひとの勉強のためにやってもらわないと、というときもある。
結局「共同所有」というのは、単に「コード」の共同所有ということにとどまらず
チームや組織の開発体制や成り立ちそのものを表す言葉なんだ、と思った。
何もかもをシェアできていて、役割を固定化しない、みんながみんなでことに当たる、
「誰のもの」という感覚が究極に希薄になった場なのだろう、と思った。
コードさえもみんなのもの、というのは相当に意識とレベルが高いチームなんだと思うけど、
そして、相当覚悟を持ってとりかからないとつくれない体制だと思ったのだけど、
どうなんだろう？、ＸＰをやってるひとたち。
アジャイルネイティブなひとたちは、どう感じているのだろう？
これでも読んで勉強せんといかんかな。
yasuo.hatenablog.com
で、最後にこんなページの紹介も。
qiita.com
たくさんコードを読みましょう！というお話し。
続いて、コーディング規約のお話し。
IPAさんにはこういうのもありますね。
SEC BOOKS：ESCR Ver.2.0：【改訂版】組込みソフトウェア開発向け コーディング作法ガイド［C言語版］Ver.2.0：IPA 独立行政法人 情報処理推進機構
コーディング規約を「持っている」ことが、品質基準のひとつとして大事にされることもしばしば。
単に読みやすさだけの話じゃなくて、バグになりやすいコードを避ける意図もある。
先のIPAの作法ガイドや静的解析ツールは、それの指標を与えてくれる教科書でもある。
個々のルールに意味があることは十分理解するのだけど、
だけど、どうも「きゅうくつ」なのだ。
それに、みんなのこだわりのポイントがぜんぜんシンクロしない、いつもいつも。
何がそうさせるのか、と思ったのだけど、
結局のところ、コードはその人の「文体」であり「口調」なのだ、ということ。
だから強要・強制（矯正）されるのはつらいのだと思う。
書きものの持つ問題、ということかもしれない。
そう考えると、仕様書の書き方にも同じことが言えるのかも、と思った。
なかなか記述がそろわなくて、書き方を決めたりしないといけないのも
それが「口調」とか「くせ」のようなものだと考えると、なんだかしっくりくる。
だからといって、わかりやすい仕様書が書けないのはダメだと思うけど。
明らかにダメな書きものはあると思うのだけど、
もしかしてそれも主観なのかもしれないなぁ...。
いや、そこは自分を信じよう。こんなのも書いたわけだしな。
