勉強会への提案1 - 今日のウェルネス

　先のエントリーは酷いので、もっとまともなことも書いておこう。
　コードレビューを行っていたときの成果をまとめていない問題と、勉強会での有効な時間の使い方を実現するための準備について。提案というか提案の叩き台か(ぇ

コードレビュー

　コードレビューでは、どうしたら良いよ、とか色々意見がでたけれど、全く内容を残せていない。コード自体は直っているけど、何をしたかの議事録が無い。それはもったいないことです。なぜ、残していないかと言えば、何を残すべきか分からないことと、残しやすい環境、アイテムが無かったからと考えます。
　後者については、ホワイトボードにプロジェクターでコードを写して、意見をホワイトボードに書いて写真を撮るのが楽でしょうか。また、事前にソースは渡していたので、エコ推奨に反しますが(エコなのかエゴなのか)印刷して、事前にチェックしたものを渡せれば良かったかもしれません。机にいる時になかなか仕事以外のことはできないのがネックですが。
　で、前者、何を残すべきかについては、自分が思うに、「元々どういう思想で(なくても良い)どういうコードがあって、レビューによって、どこかどうなるのでどうするためにどういうコードにしたか」を残せば良いかと思いました。抽象的ですが言い換えると、

・コードの問題点
　→問題点ができた原因と環境
・コードの改善点
　→どの問題点をどう改善したか。
　→環境をどう解釈すれば間違ったコードが書かずに済んだか。
　　(正しいとか間違いとかは状況によって変わる。なので、環境は明記すべき)
　　
　少なくともどういうコードをどう直したかをとりあえず保存できなかったのは残念でした。モノは忘れることがあるし、自分が忘れずに習得したとしても新しく来た人が同じ失敗を繰り返すことになってしまいます。車輪の再発明を行うのはどうしてそうなったか、他の方法はどうかとか考える上で有用ではありますし、コードを書く経験値をつめますが、仕事(会社?)にとっては無駄な回り道となります。なので、どういうコードをどう直したかを纏めておくことが必要でした。また、原因と結果だけでは理解し難い。経緯や理由を添えてあればコーディングの考え方が分かるので覚えやすいと思います。(歴史の出来事とか何してどうなったかは面白いけど年号が覚えられないとか、数学の公式を覚えても使いどころが分からなかったりね)また、新たな問題に接したときの解決方法を考えるヒントとしても、経緯や理由は必要と思われます。
　次に、保存して溜まったらどうするか。つまり、問題はどう情報をまとめるかということになります。分厚い説明書は読まないものです。必要な情報を見つけ出すことのできる賢い検索エンジンやカテゴリ分け、ランキングが必要になります。これは又次回考えよう。(前段階の保存の仕方をみんなで考えていないし。)

準備

　1週間に1回1時間で行っているので、時間が少ない。だから事前に考えることができることは考えておくべき。そして、皆の考えてきたことも一度目に通しておく必要があります。これは、エントリー「宿題と出すタイミング」でも書きましたが。宿題だけでなく、開発やUMLのことを事前に大体を把握(予習)についてもいえるでしょう。大体で良いと言うのは、ある程度の細かいことは勉強会の意見交換や経験、まとめで体得できると思われるので。それに完璧は無理だし、それを目指すと億劫になりますし。
　それはさておき、その時間とモチベ或いは義務感をどう見出すかが大きな課題であります。毎週、休みの日の時間を割くのもアレだしね。なので、平日にできれば良い。帰ってからは自分のことをしたいので、できれば会社にいる時に。業務が終わって1時間くらいは勉強の為に仕事しても良いという話もあるので、この時間を使うしか無い。大義名分と義務感?を得るために、今は秘密裏にやっている勉強会を認知して貰うことも必要かもしれません。
　若しくは、週2回くらいに回数を増やして、勉強会前の準備会を実施すれば半強制的に時間が取れるので業務との境が曖昧にならないし、事前に準備できているので本番の勉強会に集中することができる。それにある意味同じことを2通りのアプローチで体験できる。また、忙しくてもどちらか一方に参加できれば置いておかれない。(最後に関しては、まとめがちゃんとあれば問題ないのだろうけど)

とりあえず2点。