めんどくさがりダイアリー

へっぽこプログラマの備忘録

モジュール凝集度の話

調べてみた。

定義

凝集度(ぎょうしゅうど、コヒージョン、cohesion)とは、情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。(Wikipediaから引用)

分類

  1. 機能的凝集
    一番良い。モジュールは1つの機能を実行する。
    機能を一言で説明できる。単一データを参照する
  2. 逐次的凝集
    モジュールは2つ以上の機能を実行する。
    実行順序に必然性がある。単一データを参照する
  3. 通信的凝集
    モジュールは2つ以上の機能を実行する。
    実行順序に必然性はない。単一データを参照する
  4. 手順的凝集
    一筆書き。ただ処理を並べただけ。複数のデータを参照する
  5. 一時的凝集
    あるタイミングで必要な処理をまとめたもの(初期化処理やエラー処理)
    複数のデータを参照する
  6. 論理的凝集
    if文/switch文で場合分けするもの。フラグで場合分けするもの。
  7. 偶発的凝集
    一番悪い。関連性のない処理を並べただけ。

備考

  • 逐次的凝集と通信的凝集と手順的凝集のコードの見た目は一緒。
    単一データを参照するかどうか、実行される機能に関連性があるかどうかで分類分けされる

参照

はるやまのアイシャツがとても良い

最近、「スーツのはるやま」という紳士服専門店で
「i-Shirt(アイシャツ)」というワイシャツを購入したのですが、
着心地が抜群に良かったので紹介します。

f:id:tyarennzi:20170531215008j:plain

こんな人におすすめ

  • せっかく買うなら「ちょっといいもの」が欲しい。
  • アイロンをかけなくてもシワがつかないやつが欲しい。
  • 着やすく、動きやすいシャツが欲しい。
  • 細身のシャツが欲しい。

良いところ

  • ストレッチがきいていて、動きやすい
    → テロテロな手触りで、素材も非常にやわらかい。
    腕を動かすのがとても楽。
  • ノーアイロンでシワなし
    → 手間なしでピシッと決まる。めんどくさがりにはありがたい。
  • クーポンでお得に買える
    スマホアプリでクーポンがつかえてお得。
    1000円引きは当たり前。たまに半額もある。

気になるところ

  • 首の後ろにタグがついていて、気になる。かゆい。
    1週間で慣れて、気にならなくなりましたが...

f:id:tyarennzi:20170531201330j:plain

まとめ

とても良い商品で、おすすめです。
まずは店頭に行って実物を触って、試着して欲しい。
一度着ると、他のワイシャツに戻れなくなるくらい快適です。

今年からAmazonでの取り扱いも始まったみたいです。 

タスク管理についてメモ

・退社前に明日の予定を立てておく

・週初めに1週間分の予定を立てておく

・割込み作業は基本的に明日以降に回す

・20%のバッファをとる

・作業時間の予定/実績を記録する

・5分以内に終わる作業なら、その場でやってしまう

 

参考ページ

仕事の効率化を実現するタスク管理の5つの秘訣 | オクゴエ!

タスク管理のためのタスク分解術とおすすめのタスク管理方法

Blender進捗報告2

今日は細かい顔パーツ(舌、眉毛、瞳のハイライトなど)を作成しました。

ハイライトが入って前回よりはかわいらしくなってきたと思います。

f:id:tyarennzi:20170507225617p:plain

GWでここまで作成できましたが、まだテキストの1/5程度なので、

燃え尽きずに完成まで頑張っていきたいと思います('ω')ノ

広告を非表示にする

Blender進捗報告1

3日かけて、顔の作成まで出来ました。(作業時間は大体10hぐらい)

f:id:tyarennzi:20170502231357p:plain

まだ、目にハイライトがないので、若干怖いです。

これから、細かい顔パーツ(耳、舌など)を作っていきます。

頑張ります!

広告を非表示にする

Blender始めました

GWを利用して前々から気になっていた3Dモデリングを始めました。

まずは入門書は以下を購入し、キャラクター1体の作成をゴールとして頑張ります。

 やっぱり、かわいいキャラクターを作れたほうが、モチベーション上がるからね!

 

タイトルにある「Blender」とはオープンソース3DCGソフトです。

無料で学習資料も豊富なので、このソフトを使うことにしました。

blender.jp

 

途中で挫折しないといいんですがね...

広告を非表示にする

ソースコードレビューをする際に気を付けること

背景

会社でレビューアとしてコードレビュー(配布形式)をしたんですが、

私が挙げた指摘にいろいろ理由をつけられて、

結局、1つもレビューイがコードを修正してくれなかったので、原因を考えてみる。

 

 原因分析

① レビューの観点がずれていた?

私の挙げた指摘はコードの可読性に関するものが多かった。

(変数名や定数名をもっと分かりやすくできないか。など)

しかし、レビューアは仕様書どおりに実装されているかどうかを
確認してほしかったのかもしれない?

⇒仕様書通りに実装されているかどうかは、テストでチェックするべきではないのか?

何はともあれ、レビューイに事前確認しておくべきだったかもしれない。

 

② 指摘の理由づけが十分でなかった?

~が分かりづらいなどの指摘を挙げたが、

理由については詳しくレビュー議事録に記載していなかった。

だから、指摘に納得できずに修正が見送られたのかもしれない。

⇒これは自分で納得できた。次から気を付ける。

 

③ 指摘内容と修正コストが釣り合わなかった?

コメント文や変数名などを修正する必要性は、

実装ミスなどに比べると低いため、そこだけ直してコミットするのは不要と判断したのかもしれない。

⇒コードの読みやすさも大切だと思うのだけれど...納得できない。

 

④ だだ単に機嫌が良くなかった?

  1. なにか嫌なことがあり、感情的になっていた。
  2. 開発者としての自尊心を傷つけられたと思った。
  3. 年下から指摘されて、イラっときた。など

⇒ただの事故だった可能性。

こればっかりは運がなかったと思うしかない。

 

今後の対策

  1. レビューする前にどこを重点的に見てほしいのか、
    どういった観点で見てほしいのかレビューイに聞く
    (仕様書通りかどうか/可読性は低くないか/コードのパフォーマンスは低くないかなど)
  2. 挙げた指摘には必ず理由を記載する
    (~は誤読可能性があります。~は仕様書と乖離があるように読み取れます。など)
  3. レビュー報告は朝一で挙げる
    (前日にレビューしておき、疲労が少ないであろう午前中に報告し、事故を減らす)

まとめ

コードレビューは本当に難しい。

遠慮なく、思いやりをもって行う必要がある。

 

参考ページ

qiita.com

postd.cc