ユルくてスマートな開発言語Alinous-Coreと労働単価の戦い
筆者は今、野望を燃やしています。
それは、「ゆるくてもスマートに結果が出せる開発現場」の実現です。今の時代、技術者の労働単価がどんどん下がっているような気がしていますが、それに対して対抗しなくてはいけません。
確かに、上流工程であれば、逆に高い単価でも働けるとは思いますが、筆者の会社の場合には、上流から下流までできなくてはいけないので、下流工程のコストダウンとの戦いは必須です。
そして、今後は、お金面だけでなく、自由な環境で仕事をするために、「コミュニケーションの取り方」が重要になるということから、コミュニケーションの取り方の中心をドキュメントにしていきたいと考えています。
なぜならば、そうすることで、最低限の時間と場所の拘束で快適に働くことができるからです。そのために、越えなくてはいけないハードルをどんどんクリアしていかなくてはなりません。
とかいいつつ、最近、やりたい放題を目指しています。
■開発現場で「めんどくさい」ドキュメントとその理由
ドキュメントを書くにあたって、「仕様書」や「運用設計書」「概念設計書」「基本設計書」などは、筆者の場合はわりと集中して、あまり「面倒だなあ」と思うこともなく書くことができます。
しかし、「テーブル設計書」や「画面遷移図」などに関しては、正直なところ、「面倒くさいなあ」と思ってしまいます。
なぜ、面倒に感じるかを考えると、それは、前者の場合は、ドキュメントを作ることが本当の目的であるのに対し、後者はそうではなく、後付であって、本来のプログラムやデータベースを設計するのにあたり、そのドキュメントを作る人が必要としていないからではないかと筆者は考えます。
しかし、このドキュメントは、成果物となるシステムを途中から入ってきた人が見る場合には非常に便利なもので、弊社のようにパッケージベンダとしての活動をメインにしているところにとっては、とても重要かつ、必要なものです。
■どちらが「正」かが問題になるドキュメントが厄介
また、どちらが「正」であるかが問題になることも、厄介な理由の1つです。
実際の開発では、動くプログラムが最終的な目的となる成果物なので、動いているシステムの状態が「正」となります。
ですから、これが変わったときには、それに合わせるようにドキュメントも変えなくてはいけないのですが、これが面倒な作業です。
とくに、テーブル設計書や画面遷移などのドキュメントは、必死に考えて単体レベルでテストをし、成功して疲れたタイミングで書かなくてはいけないので、タイミングも悪すぎで嫌な印象がぬぐい取れません。
■究極の開発現場でのドキュメントは、「ソース解析＆自動生成」
そんななか、筆者は、言語だけでなく、Eclipse上で動作する開発環境も作ったので、その知識を利用していろいろと自動生成でexcelのテーブル設計図を出したりすることを考えています。
Alinous-Coreのコンパイラを開発したので、実は、次のような情報は手に取るようにコントロールできます。
- DDL文に書いてある情報
- DDL文やその中のカラム定義と周辺コメントの関連付け
- どのテーブルがどのプログラムファイルで呼び出されたか
- どのテーブルとどのテーブルがJOINされたか
- どのテーブルのレコードがどのタイミングで更新されているか
- どのテーブルをどのタイミングでロックしているか
これらの情報はとても便利です。
■DDLと付加情報でテーブル設計をキャッチアップ
特にDDLを書いて、そこにコメントを入れておけば、あとは、自動でExcelのテーブル定義書が出てきたらとても便利です。この機能は実現しましたが、かなり、単純作業が減りました。
また、今後の目標として、付加情報として、どのテーブルとJOINされているかが分かれば、かなり使われ方が分かって、他にどのテーブルを見ればよいか見当が付きます。
■困ったバグには、更新タイミングを把握
システムを開発して、バグが出たが原因が分からないときには、どこでテーブルが更新されているかの一覧が分かれば、その周辺を見ることで、バグの原因を突き止めるのにかなり助かります。
また、テーブル設計を変えた場合や、他の部分に影響があるようなプログラムを変更した場合などに、どの部分に影響するかの目安となれば、テスト設計の参考にもなります。
一度開発したシステムを、また、機能追加をして保守をするような場合にも、このような機能があるととても便利です。
■デッドロックの追跡をする
デッドロックは、プログラムの設計をし、開発をしているとよく起きる不具合です。
特に、弊社の場合は、物流系のシステムを開発しているので行ロックなどのロック機構を必要最低限でしっかりかけることがとても重要になってきます。
そのようなときによくあるのが、「たすき掛け」といわれるデッドロックを誘発するプログラミングパターンがあります。
このパターンはAというテーブルとBというテーブルを、片方のロジックはA→Bの順にどちらも解放せずにロックし、もう片方はB→Aの順にロックすることで発生します。解決法は、両方とも同じ順番にロックをすることでデッドロックが起きなくなります。
テーブルがロックされる順番をトランザクションごとに把握できれば、デッドロックが起きる場所を一目で特定できます。
このほかにもいろいろとありますが、それは、開発の進行具合を見ながら順々に開発方法とセットで解説していこうと思います。
やはり、こういう自分の作った言語を実務で使う機会を自分でつくれたのはよいことなので、野望を持ってAlinous-Coreをどんどん全体的に良いものにしていこうと思います。