いっぺんにやるのしんどひ

おいらはソフトウェアの機能追加を担っています。

弊現場では年に２度程度のリリースをおこなっていて、その手順はざっくりいうと

　①改修要求の一覧表を作る

　②改修要求の一覧表にそって改修手順を決める

　③改修の実施

　④テストの実施

たぶんどこにでもあるやり方だと思うのですが、この①の表が結構なボリュームになることがあります。改修要求が多いと、改修前アプリとの関係のみならず改修要求間の整合性を保つことも必要になってきます。

（↓青線のみならず赤線のところもケアする必要が）

おいらみたく脳の容量がトリ以下な生き物にはこれがきつい。全部の要求がきっちり頭に入らないと整合性を取るにはどうすればよかとね？という考えにはなってこない。

脳の容量を強化してくれるカードリッジは売ってませんかね？

我が家のモバイル

＜過去＞

　おいら・親族AともSoftbankのガラケーを所有

　　※おいらは関西デジタルホン時代からのガラケー持ちである。

　母にもSoftbankのガラケーを持たせたが、これはおいら・親族Aとの通話無料が目的である。

が、時代はスマホである。今はこうなっている

＜現状＞

　おいら

　　Softbankのガラケー

　　IIJmioのiPhone6 (SMS付きSIM)

　母

　　Softbankのガラケー

　親族A

　　Softbankのガラケー

　　docomoのiPhone6(音声SIM)

母をスマホに移行させそこなったために、母の無料通話相手である親族A・おいらともガラケーを手放せないのである。

しかしながら今は音声通話とてLINEで無料でできる時代。さっさと母にスマホを持たせてしまおうともくろんでいる。

母のガラケーをどうすべきか検討。ついでにおいらのガラケーもそろそろ物理的に限界がきているので終了させたい。

①おいらのガラケーの電話番号をiPhone6に移したい

②おかんのガラケーの電話番号をオカンのスマホに移したい

③料金はできるだけお安く

今日のお仕事

コードレビューの資料作成。

自分が修正したコードを切り抜いてメソッド単位のExcelの様式に貼り付ける。

担当した修正がメソッドの小規模修正で済むなら楽なのだが、世の中そんなに甘くはない。メソッドをたくさん追加してしまうと、この様式をいくつも作る羽目に。

罰ゲームみたいな様式つくりが終わったら、あとはレビュワーさんの仕事。

おいらもレビュワーになることがあるのだが、修正部分だけを見せられても正直困る。部分見てもあんまりわからん。結局現物のコード引っ張り出してメソッド全体を読みながら修正が妥当か判断することになる。

「修正コード」いらなくね？

ぬるりこわい

よく見たらなんともなかったのだけどぱっと見はnull怖いってこと。
↓のコード

    class nanka
    {
        public int value { get; set; }

        public void proc()
        {
            //なんかする
        }
    }

    class myclass
    {
        private nanka nanka_;

        //いっぱいメソッドある

        //このproc3はいろんなところから呼び出されているが
        private void proc3()
        {
            nanka_.proc();
        }
    }

proc3で使用しているnanka_が初期化されている(=nullでない)確証を得るべくproc3の呼び出し経路を全部逆回しで確認するはめに。
ぬるり（他言語ではぬるぽ）怖いんだからー。

バグ直した。

バグ修正の依頼があったのでコネコネとさばく。

今日のバグはこんなの。

「文字列をnバイトで切断する処理にて全角文字の真ん中をぶったぎってしまう」

"ABCDEあい"を8バイトで切る処理にて"ABCDEあ"ここまでで7バイト。"い"をつけると9バイトになるのでやめて半角スペース補充で終了させておくのが本来の要求だが、”い"の文字コードの前半部分がまでくっつけてくれているというバグ。

データベースの都合で文字列をバイト単位で切断する必要があるのですが、弊現場では極めてまれな扱いのために当初の開発担当者は慣れておらずにバグを出してしまったもよう。５年ほどバレなかったためにバグ出した当人は逃げおおせたが後任のおいらが対応することになりました。

こういうしょうもないバグは修正が楽しい。修正するメソッドについて以下のユニットテストを書く。

・切断対象文字列がちょうどnバイト("ABCDEFGH")

・切断対象文字列がnバイト未満("ABCDEFG")

・切断対象文字列が空文字("")

・切断対象文字列がnバイト超かつ切断箇所が全角文字の真ん中ではない("ABCDEFGHI")

・切断対象文字列がnバイト超かつ切断箇所が全角文字の真ん中("ABCDEFGHあ")

で、ユニットテストを実行して最後のだけ×になることを確認してメソッドをいじくりまわしつつユニットテストを実行。全部〇になればOK。すばらしい。ユニットテスト万歳。

追記　元のコードこんな感じ。

private static string NewMethod1(string org,int n)
{
  var enc = System.Text.Encoding.GetEncoding("Shift_JIS");
  var a = enc.GetBytes(org).Take(n).ToArray();
  return enc.GetString(a);
}

あ、サロゲートペアとか言いっこなしで。

ちょっと吐き出したいだけ

弊現場では型付きDataSetを使っております。

DBからデータを読み込む処理を実行すると、読み込まれたデータが型付きDataSet、型付きDataTableに入ります。

あとは型付きDataTableのrowsから必要なデータを取得するだけ。

素直です。型付きなのでIntellisenseが効きます。楽です。ありがたいです。

ここまではたぶんごくごく普通のことなのでしょう。ここからが弊現場ならではのこと。

弊現場の型付きDataTableの全カラムがstring型になっているのです。DB上の型が何であれ読み込まれた時点でstringになってしまうのです。DB設計時に型を決めたはずなのに読み込みで全部無視。読み込んで使うに当たっては自分で変換をかける必要ががが。

rowを読み込んだあとにやたらとConvert.To*があるのが正直うっとうしい。何の目的があってこんなことしたのだ？難読化か？

まぢうっとうしい。

新規開発でない現場は前任者が作ったコードの出来に左右される。

おいらもけっして出来のいいコーダーではないんですが、可能な限り後続に迷惑かけたくないなと。

VisualStudio2010→VisualStudio2017

(以下VisualStudioはVSと略す)

手元にあるVS2010のソリューションをVS2017で開いてみた。

世代はだいぶ違うが下位互換ぐらいはあるだろうとおもったらビルドが通らない。

原因を探りに探ったら、識別子に全角の[・]を使っていたところでエラーCS1056が出ているとのこと。

コード分析かけてCS1056出ている箇所をVS2010に戻って[リファクター]→[名前の変更]で名前を変更していこう。

ただちょっと気になるのは該当箇所がプロパティ名だった場合。

①双方向Bindingでプロパティ名を文字列で指定するコードがあるがこれは追従してくれないので別途文字列検索が必要。

②VSのデザイン画面でBindingの設定をしている場合、追従してくれるのだろうか？（未確認）