調べてみた。
凝集度（ぎょうしゅうど、コヒージョン、cohesion）とは、情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。(Wikipediaから引用)
最近、「スーツのはるやま」という紳士服専門店で
「i-Shirt(アイシャツ)」というワイシャツを購入したのですが、
着心地が抜群に良かったので紹介します。
とても良い商品で、おすすめです。
まずは店頭に行って実物を触って、試着して欲しい。
一度着ると、他のワイシャツに戻れなくなるくらい快適です。
今年からAmazonでの取り扱いも始まったみたいです。
・退社前に明日の予定を立てておく
・週初めに1週間分の予定を立てておく
・割込み作業は基本的に明日以降に回す
・20%のバッファをとる
・作業時間の予定/実績を記録する
・5分以内に終わる作業なら、その場でやってしまう
参考ページ
今日は細かい顔パーツ(舌、眉毛、瞳のハイライトなど)を作成しました。
ハイライトが入って前回よりはかわいらしくなってきたと思います。
GWでここまで作成できましたが、まだテキストの1/5程度なので、
燃え尽きずに完成まで頑張っていきたいと思います('ω')ノ
3日かけて、顔の作成まで出来ました。(作業時間は大体10hぐらい)
まだ、目にハイライトがないので、若干怖いです。
これから、細かい顔パーツ(耳、舌など)を作っていきます。
頑張ります！
GWを利用して前々から気になっていた3Dモデリングを始めました。
まずは入門書は以下を購入し、キャラクター1体の作成をゴールとして頑張ります。
やっぱり、かわいいキャラクターを作れたほうが、モチベーション上がるからね！
Blender標準テクニック ローポリキャラクター制作で学ぶ3DCG
タイトルにある「Blender」とはオープンソース3DCGソフトです。
無料で学習資料も豊富なので、このソフトを使うことにしました。
途中で挫折しないといいんですがね...
会社でレビューアとしてコードレビュー(配布形式)をしたんですが、
私が挙げた指摘にいろいろ理由をつけられて、
結局、1つもレビューイがコードを修正してくれなかったので、原因を考えてみる。
① レビューの観点がずれていた？
私の挙げた指摘はコードの可読性に関するものが多かった。
(変数名や定数名をもっと分かりやすくできないか。など)
しかし、レビューアは仕様書どおりに実装されているかどうかを
確認してほしかったのかもしれない？
⇒仕様書通りに実装されているかどうかは、テストでチェックするべきではないのか？
何はともあれ、レビューイに事前確認しておくべきだったかもしれない。
② 指摘の理由づけが十分でなかった？
～が分かりづらいなどの指摘を挙げたが、
理由については詳しくレビュー議事録に記載していなかった。
だから、指摘に納得できずに修正が見送られたのかもしれない。
⇒これは自分で納得できた。次から気を付ける。
③ 指摘内容と修正コストが釣り合わなかった？
コメント文や変数名などを修正する必要性は、
実装ミスなどに比べると低いため、そこだけ直してコミットするのは不要と判断したのかもしれない。
⇒コードの読みやすさも大切だと思うのだけれど...納得できない。
④ だだ単に機嫌が良くなかった？
⇒ただの事故だった可能性。
こればっかりは運がなかったと思うしかない。
コードレビューは本当に難しい。
遠慮なく、思いやりをもって行う必要がある。
参考ページ
