システム開発のアンチパターン

システム開発をする上でやってはいけないことがいくつかあると思う

開発過程での御法度

• ファイルの紛失
• デグレーション（先祖返り）

コーディングでの御法度

• 同一処理の分散
• 変更対応範囲の拡大

テストでの御法度

• 未実施

しかし、これらはどこかしらで今も行われていると言う現実もある

その原因は

開発過程

ファイルの紛失

• 共有ドライブでの管理での操作ミス

** 間違って消す、上書き、バックアップフォルダの間違い等で行方不明などによって引き起こされる これに関してはバージョン管理ツール(gitなど)でほぼ解決できる内容だが、使わない現場も多い 紛失等による修正コストと運用のための学習コストとの比較をすれば明らかに学習コストの方が低いはずと言うのが説得のポイントになる まずは、ファイルが無くなってもすぐに復旧できると言うところから説得していくしかなさそう

デグレーション(デグレ)

フォルダで管理しているが別々に作業していた人が誤って上書きする、古い物をバックアップから戻すなどで引き起こされる これもバージョン管理ツールで解決可能だが、これについては運用ルールも正しくないと同じ事が起こる 今まで見た中では、

• 共有フォルダとバージョン管理ツールの平行運用 → 共有フォルダでの管理はどれが最新なのか、正しく日付等が管理されているかという問題で人的ミスが原因で起こる このデメリットをそのまま持ってきてしまってるので意味がない

• コミットのタイミングがレビュー後でないとできない → 最終成果物しか管理されないため途中経過でのデグレの発生リスクはそのままとなり、デグレが発生しても最悪気づくのはレビュー時になる

• ブランチの使用禁止(競合が発生するため) 上記コミットのタイミングのためブランチを使わない方針は少なくない

対策としては、競合しても簡単にマージできますアピールかな…

コーディング

コーディングでのアンチパターンは既に設計段階から始まります。

• 共通化するもの、しないものの振り分け、処理パターンの洗い出しなどが不十分の場合

• コーディング規約が曖昧な場合

• そもそもアーキテクチャがおかしい場合

従来から行われている共通化の方法としては、共通関数を作る、それぞれの処理から呼び出すが一般的でした。 オブジェクト指向になって親クラスで共通処理をして、個別のメソッドは抽象クラスにして、それぞれの子で実装するが一般的になるでしょう。 DIを放り込んでおくなど、コーディング量を少なくすることが目的です。

しかし、中には昔ながらのコーディングが好きな人もいて、1ファイル1処理主義の方も未だに存在します(そろそろ絶滅したかな？)。 こういう人の説得が一番厄介ですが、根気よく共通化のメリットを説明しましょう。

共通関数呼び出しに行く人はまだ理解してくれることが多く、テンプレートパターンのように理解しやすいところから順序立てて説明していけば納得してくれることが多いようです。

ドキュメントとの整合性

設計書を書いてコードを書いて、誤りがあったらどちらを修正するかというと、どちらかというとコードから直す方が現実には多いです。 そのためドキュメントの修正が後回しになり、時には修正されずコードとの整合性が取られなくなることも多いです。 この際、ドキュメントを作らずRedmineのチケットなどで管理してドキュメント代わりにするところもあるようです。

しかし、まだドキュメントを作成するところの方が多いのは事実なのでこれは、なるべく忘れないうちにすぐに反映するしかないです。 そのためには、ドキュメントは極力簡略化することではないかと思います。 それから、コード一覧とか、画面項目一覧などは、一覧から画面HTMLの生成できるツールにするなど工夫することで作るメリットも生まれます。 ドキュメントを面倒な書き物にせずに便利なツールにすることでみんなが書きたくなる工夫も必要かな。

オンコード主義

接続情報の設定値や使用するSQLをソース上に記述するプロジェクトもありますが、これらはただの値であるためコンパイルは問題なく通ります。 しかし、それを検出するのは最悪テストの段階なのでそこまで検出できないことがよくあります。

設定値の場合は環境によって変わるものもあるのでソースを入れ換えなければならない場面も出てきます。 propertyファイルやxmlなどで管理しておくことで外部ファイルにできるのでそのようにしましょう。 環境で変化するものはgradleにちょっと書くだけで自動切り替えができます。 使ってない場合はそれぞれの環境用にファイルを用意してbuild.xmlやMakefileにコピーを配置する記述を追加して切り替える方法もあります。

自動テストを使わない

画面の入力項目が多いものなどは動作確認だけでも入力に時間をとられます。 入力項目入れるべき値が正しいかという観点もあるので正しいテストを行うためにも自動化は必要です。 JUnit、TestNGのようなメソッドを直接検査するツールとSeleniumような画面の動作を自動実行するツールがあるので用途に応じて使い分けましょう。 そして、テストは１度では終わらないということを管理者に認識してもらうことが導入許可への第一歩になります。

まとめ

システム開発は一人でするものではないため、設計書の書き方、コードの書き方、テストの方法などのルールを決めて行います。 そのため、規模が大きくなるほど、整合性を取ることが難しくなるためあまり、変わったことをせず従来どおりの方式を取ることが多くなります。 方式の決定は自分ではどうしようもないことも多いので、それに従うしかありませんが、ツールが無くてもバッチなどはテストプログラムを作成することもできます。

工数とのバランスを取りながら工夫していけると制約のある中でも効率をあげる方法はあると思います。

Ubuntu 17.4 Zesty Zapus 4/13リリース

ZestyZapus/ReleaseSchedule - Ubuntu Wiki

ZestyZapus/ReleaseNotes - Ubuntu Wiki

ここでベータ版が落とせます

今日はなにを書くか

ネタが出てこなかった

あるにはあるけどなんかつまらんなと言うのと、昔Swing使ってゲーム作った事とかだったっけど今さらSwingというのも

まだ、やろうとしていることは残ってるので

• [ ] Zabbixのインストールとか
• [ ] 中途半端に終わってるPostgresqlの続きとか
• [ ] タスク管理の話とか
• [] ブログでの数式の書き方とか

SQL最適化(3)

これ書いてなかったなというので追加

SORT CANCEL

例えばORDER BYで項目をソートする場合に、インデックスを使用するとインデックスの検索によってソートがかかるので、ORDER BYでのソートを取りやめて効率化します。

これがどういうときに有効利用できるかというと、LIMIT句で取得件数を制限する場合、ソートがかかっていれば必要な件数取得した時点で検索を終了します(LIMIT SCAN)。

SORT CANCELが働く場合と言うのは * SORT CANCEL BY INDEX 上で書いたとおりです

• SORT CANCEL BY JOIN ORDER BYで指定している項目が結合条件に使用されている場合にORDER BYのソートをキャンセルします

• SORT CANCEL BY DISTINCT ORDER BYで指定している項目がDISTINCT処理でソートされる場合にORDER BYのソートをキャンセルします

• SORT CANCEL BY GROUPING ORDER BYに含まれる列がすべてグループ化処理によってソートされる場合にORDER BYのソート処理をキャンセルします

つまり、何かの処理でGROUP BYでソートしようとしていた項目に対するソートが働けば改めてソートをしないということです

SQL最適化実践編

このタイトルで書いてたんですが、操作ミスで下書き保存されてないままブラウザ落として消えてしまいました(泣)

今回はスマホからダイジェスト版で

実例で使うRDBMSはどれがいいか 商用製品 * OracleDatabase(無料のEnterprize版もある) * HiRDB(日立) * DB2(IBM) * SQLserver(Microsoft)

OSS * postgresql * mysql

実際の環境はdocker-composeで入れよう 1. qiitaから持ってくる 1. container_nameでエラー 1. 使えないらしいのでnameに変更 1. サービス名に記号が使えない 1. 変えてみて実行 1. dockerにゴミが残ってて実行できない 1. Postgres関連のコンテナをstop、kill、rm

こんな感じです 結論はDB設定まで行けてないというオチでした

追記

つなげなかった理由はこれです

VMで放置しっ放しのpostgresqlが邪魔してました

相対性理論と機械学習

最近何かやらんといかんなと思って何がいいかなというので、そろそろ（ちょっと遅いかも）機械学習の事も知っておかないと思っていろいろと調べてみた（実際には今年の初めくらいからやってたりするのですが）

そうしたら、20年ぶりに再会した事があってちょっと驚いた

テンソルフロー(テンサーフロー,Tensor flow)というAIフレームワークの名前ですが、テンソルは運動量とか場の理論などで使われていて、学生時代にやった相対性理論でも使ってました

逆にカーナビ *1 でも作らない限りまた出会うこと無いかなと思っていた物に再会してちょっと感動

テンソル解析で求めた行列成分の偏微分は勾配の求め方とまったく同じ 空間の歪みと確率の分布が同じような概念で求められるんだなといったおもしろさを感じた

今日はこの辺で

この後、その数学的なつながりとかも書いていきたいな

当時読んでた相対性理論の本（もう中古しかないのか…） www.amazon.co.jp

当時読んでたテンソルの本 www.amazon.co.jp

Deep Learningの本（こちらでEbook Storeで電子版を購入すると安く手に入れられます） www.oreilly.co.jp

*1:カーナビは人工衛星からの電波を受信するため、人工衛星の時計と地上の時計の違いを相対論的なずれも計算しないと大幅にずれてしまいます

SQLのパフォーマンスを最適化するために(2)

つづきです

前回分はこちらになります SQLのパフォーマンスを最適化するために - 技術関連の覚書

インデックスを使えなくする検索条件

インデックスを作っても使えなくなる事があるので気をつけて避けるようにしましょう 得に何も書かない場合はITEM1をインデックス項目とします

複合検索条件をORで結ぶ

SELECT
  ITEM1
FROM
  TABLE1
WHERE
  (ITEM1=? AND ITEM2='000') OR (ITEM1=? AND ITEM2='111')

この場合、UNIONやUNION ALLにする方がよいようです

SELECT
  ITEM1
FROM
  TABLE1
WHERE
  ITEM1=? AND ITEM2='000'
UNION
SELECT
  ITEM1
FROM
  TABLE1
WHERE

ITEM1=? AND ITEM2='111'

違う項目をORで結ぶ

SELECT
  ITEM1
FROM
  TABLE1
WHERE
  (ITEM1=? OR ITEM2='000') AND ITEM3=?

この場合は (ITEM1=? AND ITEM3=?) OR (ITEM2=‘000’ AND ITEM3=?) に分解できます

インデックス項目に対するOR

SELECT
  ITEM1
FROM
  TABLE1
WHERE
  (ITEM1='000' OR ITEM1='001' OR ITEM1='002') AND ITEM3=?

同一項目をOR検索する場合はINに置き換えられるのでINを使う

ITEM1 IN ('000', '001', '002')

INを使った副問合せ

SELECT
  ITEM1
FROM
  TABLE1
WHERE
  ITEM1 IN (SELECT ITEM1 FROM TABLE2 WHERE ITEM1>'002')

これはFROM句でJOINさせた方がいいようです

SELECT
  ITEM1
FROM
  TABLE1 T1
INNER JOIN TABLE2 T2 ON
  T1.ITEM1 = T2.ITEM2
WHERE
  T2.ITEM1>'002'

SQL関数を使う

関数を使うとインデックスが適用できなくなるので代用できる物があれば避ける 例) LEFT関数で前方一致をLIKEでの前方一致にする ITEM1=LEFT() 　　↓ LIKE 'X%'

項目同士で文字列結合したものとの比較

ITEM1 || ITEM2='AAA000' 　　　　　↓ ANDで結合しましょう

インデックスを使う優先順位

ランキングは以下のとおりです

1. =で比較するPK

2. =で比較するインデックス

3. LIKEでの前方一致

4. INでの比較

5. BETWEENでの範囲検索*1

6. 不等号(>,>=,<,<=)での比較

7. GROUP BYかORDER BYの列にあるインデックス

副問合せの検索方法

何となく、結合と似たところがあります 副問合せは作業表を作るのでこれがパフォーマンスを低下させる原因になる場合があります

NESTED LOOPS WORKTABLE SUBQ

外のSQLから1件検索ごとに副問合せのSQLを検索してワークテーブルを作ります

WORKTABLE ATS SUBQ

インデックスを使って副問合せを検索する方法です

WORKTABLE SUBQ

副問合せの選択式の値を求めて作業表を作って、外を実行して1件検索して副問合せの結果を問い合わせます

HASH SUBQ

あらかじめ副問合せ結果からハッシュ表を作成しておいて，外側の問合せを1行取り出すごとに外側の問合せの値をハッシングして，ハッシュ表と突き合わせをする方式です。

NESTED LOOPS ROW VALUE

副問合せのインデクスを使用して，外側の問合せの結果との条件を評価します

3つ（だけ？）くらい中途半端な状態ですが、出かける時間がきてしまうので続きはWEBで(ここだろと言うツッコミ)

*1:A >= x AND A <= y と言う検索の場合はBETWEENに内部的に展開されます