これは何

オワコン大手SIerに学ぶアンチパターン - Qiitaを読んで、SIer勤務の身として自分が関わっているプロジェクトはどんな感じなのか、ちょっと書いてみようと思ったものです。

昼休みに一気に書き上げたので足りていない部分はある。

バージョン管理

今のプロジェクトはSubversionを使っています。 Gitはちゃんと学ぶ時間を取らないと事故が起きてしまうので（実際に経験）避けています。

画面設計書やバッチ設計書、帳票設計書等はお客様へのレビューの関係上、どうしてもExcelになってしまいます。これは変えたいなとは思うものの、お客様とのやり取りを考えるとじゃあ何がいいのか、となったときに適切な代案が思い浮かびません。

Wordだと表が組みにくかったり、シートを分けて記述内容を変えたりということが出来ないのもExcelになってしまう要因です。

テーブル設計に関してはA5:SQL Mk-2 - フリーの汎用SQL開発ツール/ER図ツール .. 松原正和で生成できるER図を使っています。いざとなったら、イメージ図にエクスポート出来る機能もあるので重宝しています。

社内用語に関しては、お客様が使っている用語をそのままというところがあるので慣れないと難しい、というのはその通りです。用語集も最初はまとめていても、開発終盤になるとメンテナンスされなくなることもしばしば…。

画面設計に関しては、今のプロジェクトも含めてUIは余りかっこいいものになっていません。デザインをちゃんと学びたいとは思うのですが…。

画面の内部設計やバッチ設計については、一応それなりの設計になるように頑張ったので美しくはないけどスパゲッティでもないと思う。

テーブル名／カラム名がローマ字なのにはちゃんとした理由があって、作るシステムで使われている用語を英語にするのが難しいというのが第一理由です。英語にしようと思えば出来なくもないのだけど、英語の候補にも複数出てきてどれを選択するのが適切なのかわからなかったり、スペルが難解だったりします。

そうなると、無理に英語にするよりローマ字にしたほうがまだパッと見て読めるのでローマ字を選択します。～日付とか～日時などの簡単なものは英語表記にするので、ローマ字と英語が混ざってしまうこともありますが、可読性を優先しています。

テーブルやカラム名の略称については、Oracleだとテーブル名やカラム名に30文字制限があってフルで入れるとどうしても削らないといけなくなり短くしてしまうという背景もあると思われます。

テーブル名やカラム名に制限がないときは略称は使わないように心がけています。とはいえ、丁寧に全部入れるととても長くなってしまうときは、一部分をカットすることもありますが…。

カラムの型については、適切なものを選択するようにしていますが、元システムのデータだったり、データ構成に関しては日付項目なんだけどchar(8)を選択、等妥協してしまう場合もあります。出来るだけ妥協しないように努めてはいますが…。

テーブルのカラム数は出来るだけ減らして、適切な単位で分割するように心がけています。

変数はテーブルのカラム名と合わせるルールにしたので、変な変数名はかなり減らせているはずです。ハードコードも出来るだけ避けるようにコードレビューはしましたが、一回しか現れない値がどうしても残ってしまいました。

コードフォーマッタは環境構築の手順書の中に入れたので、マニュアルを読み飛ばさなければ保存時にある程度フォーマットしてくれるようにしました。たまに設定漏れする人はいるので、見つけたら設定するように指導しています。

メソッドの行数は…業務ロジックもあるのでなかなか難しいところです。今日の自分の分割方法と昨日の自分の分割方法にも違いが出てしまうくらい、自分の中でも明確なルールが定まっていないので自分もまだまだ勉強が必要です。