サイゼントの技術ブログ

2019年9月7日

保守性の高いコードを作成するために心がけるべきこと

ソースコードは作って終わりではなく、その後何年、何十年にもわたって保守開発が行われます。
また、保守開発を行う開発者もその間に入れ替わります。
ソースコードを作る際は、このことを踏まえて高品質・低コストで保守開発ができるようにする必要があります。

難しい話をするとデザインパターンやフレームワークの話になるのですが、今回は新人も含めて最低限心がける必要があることを挙げていきます。

１．適切な変数名やメソッド名を与える

変数名・メソッド名を与える際は、その変数やメソッドが何をするのかわかるような名前にする必要があります。
例えば、「a」や「hoge」といった変数名は不可で、「loopEndFlag」や「commodityCode」といった意味のある変数名にする必要があります。

また、現場毎で命名規則が決められていることも多いので、それに倣った命名をする必要があります。
命名規則を無視すると、他のソースコードとの統一性が失われて読みにくいソースコードになったり、影響分析等のためにキーワードで検索する時に引っかからなくなったりします。

２．適切にコメントを記述する

コメントを入れることで、その箇所で何をしているのかがわかりやすくなります。
しかし、コメントを入れれば良いというものではなく、意味のあるコメントである必要があります。

例えば、

/* iが0～11の間処理する */
for (int i=0;i＜12;i++){
…
}

/* iが0～11の間処理する */

for (int i=0;i＜12;i++){

…

}

といったソースをそのまま日本語にしただけのようなコメントは不可で、

/* 1月～12月の売上高を計算する */
for (int i=0;i＜12;i++){
…
}

/* 1月～12月の売上高を計算する */

for (int i=0;i＜12;i++){

…

}

といった業務的な意味を書く必要があります。

また、ソースコードの先頭には「ソース名」「処理概要」「変更日」「変更概要」「変更者」といった情報を記述するのが一般的です。
メソッドの先頭には「メソッド名」「処理概要」「引数」「戻り値」「出力され得る例外」といった情報を記述するのが一般的です。

コメントの書き方も、現場毎で決まっていることが多いです。

３．分かりやすいロジックを心がける

保守開発の際にソースコードのロジックを読み解くことも多いので、if文のネスト（if文の中のif文）が多すぎる、goto文で制御があちこちに飛ぶ、といったロジックが分かりにくくなるような書き方も避けた方が良いです。
また、if文やfor文等を使う際は、インデント（左側のスペース）を適切に入れて、構造が分かりやすくなるようにした方が良いです。
（インデントの入れ方は各言語の入門書を真似れば良いです）

なお、新人の内はあまり気にする必要はありませんが、使用する文法も入門書に載っているものを中心にした方が無難です。
自分の現場で広まっているなら良いのですが、そうでないのに新しい文法やマイナーな文法を使うと、他の開発者（特に新人）から見て理解しにくくなることがあります。

４．ハードコーディングは原則禁止

ハードコーディングとは、マスタデータをソースコードの中に持たせることです。

例えば、

/* 商品コード（野菜） */
int syohinCodeVegetable = 1;

/* 商品コード（調味料） */
int syohinCodeSpices = 2;
：
：
：

/* 商品コード（野菜） */

int syohinCodeVegetable = 1;

/* 商品コード（調味料） */

int syohinCodeSpices = 2;

：

のような書き方は不可で、商品コードの一覧を持たせたいなら、データベースやファイルに持たせてそこから取得するべきです。

マスタデータは、追加や修正や削除が行われることがあります。
マスタデータをデータベースやファイルに持たせていない場合、追加・修正・削除が行われる度に、ソースコードを修正しコンパイルする必要が出てきて保守工数が増加します。

更に言うと、マスタコード読み込みのような色々なソースコードで使われる処理は、共通処理として別のソースコードに切り出すべきです。
これをしないと、修正する際に修正漏れが発生する可能性が高くなります。
大抵の場合、使うべき共通処理は現場毎やプロジェクト毎で決められているので、それに従う必要があります。

５．仕様書とソースコードを合わせる

仕様書には、ソースコードがどのような意図で作成されているのか、他のソースコードとどのような連携をしているのか、等の設計思想が記載されています。
しかし、仕様書がソースコードと乖離していた場合、仕様書から調査する時に実際の実装を誤って理解してしまいます。そのことにより、保守開発でバグが生まれる原因になります。
それを防ぐために、ソースコードが仕様書から乖離した時は、仕様書もソースコードに合わせて修正するべきです。

いかがでしたでしょうか。

学生時代からコーディングしていたという人は少なからずいらっしゃると思うのですが、今回述べたことは学生時代のコーディングでは習慣として身に付きにくい所だと思います。
（私が新人だった頃もコーディング経験者の同期がいたのですが、その同期が研修で書いたコードを見ると、変数名が「a」とか「b」とかの適当な名前で、ソースコードが読み辛かったのが記憶に残っています）
同じソースコードを担当者を変えながら何年も何十年も保守開発していくのは社会人ならではだと思いますので、保守しやすいソースコードを書く習慣が身に付いていない方は、保守のしやすさを是非意識していただければと思っています。

では、また来週！

2019年8月31日

unix／linux：perlの複数命令を１行のコマンドで実行する（例：文字列のバイト位置走査）

perlはファイル操作や正規表現に優れているスクリプト言語であるため、コマンドライン上でperlを駆使することができれば作業の幅が広がります。
perlの-eオプションによりコマンドライン上で実行可能となり、１つ１つの命令を ; で区切ることで複数命令を記述可能となるため、これを使いこなすことでスクリプトを作らなくともperlの機能を作業に使うことができるようになります。
コマンドを予め作成して本番作業時にコピペしたい場合やオペレーターに作業を依頼する場合等、スクリプトを気軽に作れない場合も少なくないので、そのような場合に効果を発揮します。

以下は、ファイルの中から特定の文字列のバイト位置を走査する例です。
ファイルの先頭で見つかった場合は0、次のバイトで見つかった場合は1、…といった具合で値が返ります。
見つからなかった場合は-1が返ります。
（例えば、改行コード無しのファイルで特定のデータをcutで除外したい時に、除外する位置を確認するのに使えます）

#＞ cat hoge.txt
#＞ abcde
#＞ perl -e 'my $str; my $pos; $str = `cat hoge.txt`; $pos = index($str,"a"); print "$pos\n";'
#＞ 0
#＞

#＞ cat hoge.txt

#＞ abcde

#＞ perl -e 'my $str; my $pos; $str = `cat hoge.txt`; $pos = index($str,"a"); print "$pos\n";'

#＞ 0

#＞

いかがでしたでしょうか。
perlという言語自体は知っている方が多いと思いますが、それをコマンドラインから実行して作業を効率化できる、というのは盲点ではなかったでしょうか。

ちなみに、今回紹介しませんでしたが、perl -eには便利な追加オプションがいくつもあります。
（標準入力（インプット）を１行１行処理、改行の強制付与、等）
「perl ワンライナー」で検索すると参考になるページが出てくるので、更に複雑な操作を行いたい場合は調べてみると良いでしょう。

では、また来週！

2019年8月24日2019年8月24日

実務で良く見かけるループ処理

今回の記事では、実務で良く使われるループ処理のパターンを挙げていきます。

１．二重ループ

ループの内側にループがあるというのは良くあるパターンです。
javaでサンプルを書くと以下のようなパターンです。

public class Main {
    public static void main (String[] args){

        int arraySizeX = 3;
        int arraySizeY = 3;
        int array[][] = new int[arraySizeX][arraySizeY];
        boolean endFlag = false;

        array[0][0] = 1;
        array[0][1] = 2;
        array[0][2] = 3;
        array[1][0] = 4;
        array[1][1] = 5;
        array[1][2] = 6;
        array[2][0] = 7;
        array[2][1] = 8;
        array[2][2] = 9;

        int i = 0;
        while (!endFlag) {
            int j = 0;
            while (!endFlag &amp;&amp; j &lt; arraySizeY) {
                System.out.println(array[i][j]);
                if (array[i][j] == 5) {
                    endFlag = true;
                }
                j++;
            }
            i++;
            if (i == arraySizeX) {
                endFlag = true;
            }
        }

    }
}

public class Main {

public static void main (String[] args){

int arraySizeX = 3;

int arraySizeY = 3;

int array[][] = new int[arraySizeX][arraySizeY];

boolean endFlag = false;

array[0][0] = 1;

array[0][1] = 2;

array[0][2] = 3;

array[1][0] = 4;

array[1][1] = 5;

array[1][2] = 6;

array[2][0] = 7;

array[2][1] = 8;

array[2][2] = 9;

int i = 0;

while (!endFlag) {

int j = 0;

while (!endFlag && j < arraySizeY) {

System.out.println(array[i][j]);

if (array[i][j] == 5) {

endFlag = true;

}

j++;

}

i++;

if (i == arraySizeX) {

endFlag = true;

}

実行結果は

となります。

何をしているのかと言うと、
・２次元配列に格納した値を順番に取り出している
・ただし、5を取り出したらその時点で処理を終了する
ということをしています。
（実務では、１次元目が親項目、２次元目が子項目のことが多いです）

このパターンのループの場合、原則として、内側のループの終了条件は外側のループの終了条件を内包しています。
今回の例で言うと、
・内側のループの終了条件…!endFlag && j < arraySizeY
・外側のループの終了条件…!endFlag
となっています。

このような場合、内側のループにしかない終了条件に着目すると、それぞれのループで何をしているのか把握しやすくなります。
今回の例で言うと、内側のループにしかない終了条件として「j < arraySizeY」があります。
この終了条件に着目することで、内側のループでは２次元目の配列を順番に読んでいる、ということを把握することができます。

２．リトライ処理

タイミングによって失敗する可能性がある処理を行う場合、失敗してもすぐに異常終了しないように、その処理が失敗した際にリトライをかける制御を入れることがあります。
例えば、通信やデータベースアクセス等で良く使われる制御です。

フローチャートで言うと以下のようになります。

「処理が失敗した時だけループを継続する」というロジックになっていたら、このパターンである可能性が高いです。

なお、今回のフローチャートでは省略していますが、無限ループで負荷がかからないように、ループ時にスリープを入れたり、ループ回数を設定したりすることも多いです。

３．先読みRead

レコードの中身を見てループ継続条件を判断する場合は、１レコード目のみループの前に先読みして、２レコード目以降はループの中で読み込む、ということをします。

フローチャートで言うと以下のようになります。
（EOFの場合の処理は省略しています）

派生パターンとしては、コントロールブレイクやマッチング処理があります。
詳しくは以下のページを参照してください。
コントロールブレイク
 マッチング処理

なお、ファイルの場合はReadですが、SQLのカーソルの場合はFetchです。どちらにしても制御としては同じです。

いかがでしたでしょうか。

上記の３つのパターンが出てくるソースコードを分析する機会があったのですが、若手の方が分析に苦労していたので、今回の記事を書こうと思いました。
今回記事にしたことは半ば暗黙知化していることなので、それを文章にすることで少しでも他の技術者の助けになれれば幸いです。

これからも、参考になる情報を記事にしていきたいと思います！

2019年8月17日

O(オーダ)の概念と実務での使い道

今回の記事は、検索アルゴリズムやソートアルゴリズムの性能を評価する際に用いられる「O(オーダ)」の概念についてです。

「O」は情報処理技術者試験ではよく主題されるものの、業務系SE（特定の業務のシステム設計を得意とするSE）には無縁のものに思われがちです。
しかし、業務系SEでも「システム改修によりデータ量が○倍になるが、このバッチ処理は○分以内に終わらせないといけない」という形で性能面を考えた設計が必要になることがあります。
実際に本番と同じ環境・改修後のデータ量を用意してテストができれば良いのですが、それができない場合は本番環境の現状のデータ量・処理時間から改修後の処理時間を見積もる必要があります。
（この見積もりで求められる性能が出ない場合は、性能を向上させるための設計を考える必要が出てきます）
このような見積もりで、「O」という概念が必要になります。

下記に、代表的なアルゴリズムとそのオーダを記載します。

・線形検索

O(N)

・２分検索

O(logN)

・バブルソート、基本選択法、基本挿入法

O(N^2)

・クイックソート、マージソート、ヒープソート

O(NlogN)

ここで、Nはデータ量のことを指し、Oは処理時間のことを指します。
例えば、「O(N^3)」なら、処理時間はデータ量の増加の割合の３乗となります。
データ量が２倍になれば、処理時間は８倍(2^3)となります。

また、情報処理の分野では、logの底は2とされています。
そのため、「logN」とは、「2を何乗したらNになるのか」を指す値となります。
log2は1(2^1=2)、log4なら2(2^2=4)、log1024なら10(2^10=1024)となります。
例えば、２分検索の場合、階層が1深くなれば(処理回数が1回増えれば)２倍のデータを検索できるようになるので、「2^処理回数=データ量」の関係が成り立ち、O(logN)と表記できます。

例として、データ量が４倍になった時の処理時間の増加量を以下に示します。

・線形検索

4倍(N)

・２分検索

2倍(logN)

・バブルソート、基本選択法、基本挿入法

16倍(N^2)

・クイックソート、マージソート、ヒープソート

8倍(NlogN)

なお、実務で処理時間を見積もる際、OSや製品で用意されている検索・ソートアルゴリズムは原則として高速なものが用意されているので、２分検索やクイックソート・マージソート・ヒープソートと同じオーダで計算して良いでしょう。

いかがでしたでしょうか。

情報処理技術者試験で学んだ知識が本当に実務で役に立ったのが個人的に印象的だったので、記事として書きました。
これ以外にも実務で役に立つ知識は少なくないので、単に合格するために試験勉強するのではなく、実務で使える引き出しを増やすために勉強した方が良いと個人的には思っています。

これからも実務で使える/使えたことがあれば、記事として発信していきたいと思います！

2019年8月10日

プログラムによる小数点以下の計算で誤差が生じる原因と対処法２選

プログラムで小数点以下の計算を行う際、誤差が生じることがあります。
金額計算を行う時はこの誤差が即障害に繋がるので、誤差が生じないように実装する必要があります。

今回の記事では、誤差が生じる原因とその対処法を２つ挙げていきたいと思います。

１．浮動小数点型の丸め誤差

丸め誤差とは、小数点以下の数を２進数で表現できない（近似値を使わざるを得ない）ことにより発生する誤差です。
浮動小数点型（javaで言うとfloat型やdouble型）の変数を使用する際に、この問題が発生することがあります。
浮動小数点型を使用すると、例えば「0.3」が「0.29999999…」になったりするので、小数点以下の誤差が許されない場合には浮動小数点型を使用するべきではありません。

最も簡単な対処法は、整数型（javaで言うとint型等）で計算できるように、ファイルやテーブルの数値項目の単位を変えるという対処法です。
例えば、「金額項目は0.01円単位とする」という設計とすれば、「1.01円」を「101」と表すことが可能となり、整数型で計算できるようになります。

また、プログラム言語が任意精度型（javaで言うとBigDecimal型）の変数を用意している場合は、その型を使用することで丸め誤差の発生を防ぐことができます。
なお、COBOLの場合は丸め誤差が発生しないので、COBOLで小数点以下の項目を定義する場合は任意精度型であると考えて良いです。

２．中間結果を格納する領域の桁数不足による切り捨て発生

複数の四則演算を行って最終的な結果を得る際、中間結果を格納するための領域が必要になります。
もちろん、その領域が自分で定義した整数型の変数だったりすると、その時点で切り捨てが発生し、誤差が発生してしまいます。

このようなケースはレビューをすれば一目瞭然なのであまり心配はいらないのですが、問題なのはその中間結果がコンパイラにより暗黙的に用意される場合です。
具体的に言えば、COBOLでCOMPUTE文を使うような場合に問題になります。
基本的には、乗算を除算よりも先に行う、というのが誤差を防ぐための方法になりますが、中間結果の桁数の仕様を把握した上でそのような対処法を採用するのが望ましいです。
中間結果の桁数はコンパイラを用意しているベンダー毎で異なるので、詳しくはベンダーが用意しているマニュアル等で調べる必要があります。

例えば、COMPUTE文の中間領域が小数点以下0桁（コンパイラが暗黙的に設定）、最終結果を格納する領域が小数点以下0桁（プログラマが明示的に定義）である場合、以下のような計算結果になります。

・正しい計算

　　123456円の消費税8%
　→123456円 * 1.08
　→133332.48円
　→133332円
　　（小数点以下切り捨て）

・COMPUTE文で問題のある計算順

　　123456 / 100 * 108
　→1234 * 108
　　（下２桁が意図せず失われる）
　→133272

・COMPUTE文で問題のない計算順

　　123456 * 108 / 100
　→13333248 / 100
　→133332
　　（下２ケタを切り捨てる）

金額計算を行う場合、誤差が生じると重大な障害を生み出しかねません。
小数点以下の計算は特に誤差が生じやすく、上記で述べたことも実際のシステム開発で障害になりやすいポイントです。
多くの場合は、開発者のプログラミングの知識不足により小数点以下の計算の誤差が発生するので、そのような障害を少しでも減らしたいという思いで今回の記事を書きました。

これからも、開発者の役に立てるような記事を書いていきたいと思います！