「プロジェクト標準」の正しい作り方／伝え方 | ウルシステムズ株式会社
プロジェクト標準とは、開発者が作業を迷わず進めるための規則です。開発者の作業を束縛するものでもありますが、複数の人が集まって作業を進める以上、何らかのルールを適用することは避けられません。今回は、プロジェクトの進行をスムーズにし、かつ開発者から得られるプロジェクト標準の作り方と、その伝え方について解説します。作成した標準を実際に利用する現場にとって分かりやすいメリットを盛り込むことが重要です。 あなたのプロジェクトに「標準」はありますか？前々回はアーキテクチャの重要性を、前回はJ2EEアプリケーションにおける1 つのソフトウェア／アプリケーションアーキテクチャの例として「軽量Java」を解説しました。システムアーキテクチャ、あるいはその下位概念としてのソフトウェア／アプリケーションアーキテクチャが、システムの作り全体に影響するものであることをご理解いただけたと思います。アーキテクチャは、設
やってはいけないJavaプログラミング | ウルシステムズ株式会社
1．これだけはやってはいけない 製品としてプログラムを記述する場合に「決して」やってはいけないのは、ソフトウエアに対する要求仕様を満たさないこと、つまり製品にバグを残すことです（注1）。仕様としてなにがどこまで定義されているかは、それぞれのプロジェクトによって異なるでしょう。シビアな場面では、メソッドの応答速度や使用メモリ量を定義することもあります。そこまでは掘り下げずに、画面仕様書とファイル仕様書、データベース仕様書だけで、「ボタンAが押されると、ファイルBに記述された設定にしたがってユーザの入力値を演算し、データベースのこのテーブルにこういう行を挿入、画面のこの個所に○○というメッセージを表示する」といった条件のみを定義することもあります。 いずれの場合でも、仕様を最終的にブレークダウンした結果である個々のプログラム、ソースコードが、これを満たしていることが最低限の完成条件となります。
DIコンテナの本当の使いどころ | ウルシステムズ株式会社
DI の自由度は諸刃の剣 近ごろ、「実プロジェクトでDIコンテナ（注1）を導入している」という話をちらほら耳にするようになりました。それと同時に、「DIコンテナを使ったプロジェクトが大変なことになっている」という話も耳にするようになりました。DIの魅力を十分に享受して低コスト、高品質を実現しているプロジェクトがある一方で「DIを導入してみたのはいいのだけれど、DIの設定ファイルが大きくなりすぎて管理しきれない」「DIを使っているのに、テスタビリティが全然向上していない」など苦労しているプロジェクトもあるようです。この差はいったいどこから来るのでしょうか。 DIは、EJBなどと比べると比較的取っ付きやすい技術ではありますが、ほかの技術同様、誤った使い方では十分に力を発揮できません。DIコンテナは非常に単純明快な技術ではありますが、そのシンプルさ故に自由度が高くさまざまな使い方ができます。その
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
