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

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

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

プログラミング

背景

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

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

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

 

 原因分析

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

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

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

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

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

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

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

 

今後の対策

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

まとめ

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

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

 

参考ページ

qiita.com

postd.cc

2017年にやりたいこと

その他

今週のお題「2017年にやりたいこと」

 

あけましておめでとうございます。

 

2016年を振り返ってみると、

Linuxを触ったり、単体テストをやってみたり、コードのリファクタをしたりしていました。(全て仕事での話)

仕事外でプログラミングとかはほとんどしてなかった気がしますね…

2017年はもっとプライベートでもコードを書くようにしたいです。

 

前置きはさておき、2017年に私がやりたいと思っていることは以下の３つです。

ゲームを作成・リリースする

昔から、ゲーム作成には興味があったのですが、全然できていないので、今年こそ挑戦したいと思います。

最低でもAndroidで1つでいいからアプリを作成して公開したいです。

今はゲーム作成のハードルも昔と比べて、下がっていると思うので、なんとか今年中に達成したいです。

英語を読めるようになる

面白そうなゲームがあるのに、日本語対応していないためにプレイできないのはとても勿体無い。

てことで英語を読めるようになりたいです。

まずは日本語対応していないゲームを購入して、辞書を引きながら少しずつ覚えていきたいと思います。

IT分野の守備範囲を広げる

将来のためにもある程度、仕事に無関係のIT事情にもアンテナを張って、面白そうなものは習得していきたいと思います。

仕事では主に組み込み系の開発を行うことが多いので、WEB系やクライアントアプリなどの知識も身に着けていきたいと思っています。

 

あとは最近気になっている株式投資とかも機会があればやってみたいと思っています。(1週間後には興味が薄れているかもしれませんが)

もちろん、ブログ更新もこまめにやっていけたらいいと思っています。

 

今年もよろしくお願い致します！

プログラミングの楽しさについて

プログラミング

最近、仕事でコードを書いていても
あまりモチベーションが保てず、 楽しめていないと感じている。

大学でプログラミングしてたときは
そこそこ楽しみながらやってた気がするんだけど・・・

自分のやる気の維持のため、
世間のプログラマの人はどのようにして
モチベーションを維持しながら仕事をしているのか調べてみた。

デキルプログラマとは

エンジニアのモチベーションを下げる方法

モチベーションが低下しているときは筋トレ

管理の効率化よりもプログラマのモチベーションを大切にしている理由

モチベMAX！思わずプログラミングがしたくなるおすすめ映画7選

Webサービスプログラマのための自己マネジメント術

やる気が出ない？！スキルアップのモチベーションが下がった時に見直したいたった一つのこと

なんか記事を検索していろいろ見てると
だんだんやる気が出てきた気がする。

単純ですいませんね。

テーブル処理ってどうなんだろう

プログラミング

仕事でコードを書いていると以下のようなコードを見かける

bool initalize(){
    bool success;

    success = initalizeAAA();
    if(!success){
        return false;
    }

    success = initalizeBBB();
    if(!success){
        return false;
    }

    success = initalizeCCC();
    if(!success){
        return false;
    }

    //...モジュールの初期化関数の呼び出しが続く

    return true;
}

上記のような各モジュールの初期化関数をひとまとめにした関数は
新規にモジュールが増えるたびに関数呼び出しが追加され、
戻り値の判定が増えていくため、サイクロマチック複雑度が
増大して静的解析で警告が出ることがある。

このコードを先輩がリファクタしていたのだが
その結果、以下のようなコードになった。

typedef bool (initFunc)(void);

bool initalize(){
    initFunc funcTable[] = {initalizeAAA,
                            initalizeBBB,
                            initalizeCCC ...};
    int funcTableSize = sizeof(funcTable) / sizeof(funcTable[0]);

    // 初期化関数をループで呼び出す
    for(i = 0; i < funcTableSize; i++){
        if( funcTable[i]() == false ){
            return false;
        }
    }

    return true;
}

上記のようなコードはテーブル処理(テーブルジャンプ？)というらしく
case分が大量にあるルーチンなどを簡略化する際に割と使われる方法らしい。

コードの可読性が下がっているような気がするので
個人的にはあまり好きになれないが
コード量の削減、モジュールの拡張性向上にはかなり有用らしい。

参考URL
テーブル処理の鬼と化せ！
[C/C++]テーブルジャンプ

ポモドーロ・テクニックがいい感じ

プログラミング

最近、会社でポモドーロテクニックを使いながら

仕事を進めているのですが、結構いい感じなので感想を書きたいと思います

ポモドーロ・テクニックとは

集中して仕事をこなすために、25分毎に時間を区切って仕事をする時間管理術。Francesco Cirillo氏が1992年、自身の勉強効率を上げるために考案した。

 

手順

1. 25分を1ポモドーロとし、やるべきタスクを1ポモドーロ刻み（25分毎）に分ける。
2. 25分間は、他の事は一切やらず、タスクに集中する
3. 25分経てば、5分間の休憩を入れる
4. 4ポモドーロ毎（2時間毎）に30分程の長い休憩をとる
5. 後は上記を繰り返す

 

良かった点1：休憩を取りながら作業を進めることができる

→25分経ったら強制的に5分休憩するルールなので
気持ちをリフレッシュしながら1日の作業を進めることができる
今までは一日中パソコンに張り付いてひたすらバグの原因を調べるとかしていた
⇒集中力をキープしながら1日の作業を進めることができる

 

良かった点2：割り込み作業に惑わされなくなる

→作業中に内部割込み*1や外部割込み*2が入っても作業に集中できる
メールや口頭で振られた作業は余程の緊急な作業でない以外
タスクリストにメモして別のポモドーロ中に作業する
⇒様々な割込み作業に追い回され「あれ？今何やってたんだっけ」という状態を防止できる

 

良かった点3：やっている作業について振り返る時間ができる

→作業を進めて分からないところ、行き詰っているところが見つかれば
ポモドーロ後に有識者にヒアリングする
⇒進捗が困難な作業にハマり、時間が浪費されるのを回避できる

 

本も出版されているので是非どうぞ

アジャイルな時間管理術 ポモドーロテクニック入門

アジャイルな時間管理術 ポモドーロテクニック入門

 

 

*1:自分自身の脳からの割込み
あるコマンドについて調べたい、コーヒーを注ぎに行きたい、トイレに行きたいなど

*2:第三者からの割込み
メールでの作業依頼、口頭での作業依頼、不明点の質問など

自宅のWindows7にVMwareでCentOS6.7を立ち上げる

プログラミング

背景

現在、会社の開発業務でLinuxを触っています。
会社だけでなく自宅でもLinuxを使ってみたい。
ということで今回は、自宅PCでもLinuxを扱えるようにするために、
仮想マシンを立ち上げることにしました。

主題

CentOS6.7はこちらから
http://www.ftp.ne.jp/Linux/packages/CentOS/6.7/isos/x86_64/

環境構築に関しては以下のページを参考にしました
「VMware Player + CentOS」
http://akabeko.me/blog/2012/01/vmware-player-centos-2/

同じ手順で問題なく、環境を構築することができました。 f:id:tyarennzi:20160117190428p:plain

まとめ

これで自宅でもLinuxカーネルのソースをいじったりできます！

上記のサイトのように画面1枚ごと丁寧に解説している
ページは本当にありがたい。記事の投稿者に感謝です。

仮想マシンについてまとめ

プログラミング

仮想マシンとは？

最近vmwareを使ってWindowsPC上でLinuxを立ち上げている
新しくPCを買わずに別のOSが使えるのでとても便利！
しかし、なぜ別のOSが起動できるのかなど仮想環境の仕組みは
全然分かっていなかったのでこれを機に調べてまとめておこうと思います

「ホストOS型」と「ハイパーバイザー型」

いろいろ調べてみるとどうやら仮想化にも2つの方式があるらしい

  • ホストOS型
    1つの物理的なPC上に仮想マシンを立ち上げる
    例えば、winPC上にLinuxPCを立ち上げる
    物理マシン上のOSはホストOS、仮想マシン上のOSはゲストOSと言われるらしい
    ホストOSが落ちると、ゲストOSも落ちる

  • ハイパーバイザー型
    OSと物理マシンの間をハイパーバイザが取り持つ
    各OSがホストOSを介さずに直接、物理HWと通信できるので
    ホストOS型より処理速度は速い
    起動されている各OSは独立しているため、連鎖してOSが落ちることはない

「完全仮想化」と「準仮想化」

さらに走らせるOSも2通りあるみたい

  • 完全仮想化
    OSのカーネルをそのまま動作させる
    クロス開発ではこっちの方がポーティングするときにも
    ある程度は安心できそう

  • 準仮想化
    仮想マシン用に最適化したOSカーネルを動作させる
    完全仮想化に比べ、オーバーヘッドなどが減少するため実行速度は向上するらしい


改めて考えてみると、HWの処理をSWで再現するってすごいと思った



参考にさせて頂いたページ
「仮想化入門」
"http://www.plathome.co.jp/solution/virtualserver/introduction/02.html"
「エンジニアなら知っておきたい仮想マシンのしくみ」
"http://gihyo.jp/dev/serial/01/vm_work/0001?page=2"