経済産業省は11月22日、システム開発時に使う設計書・仕様書などの「作業生産物」のレビュー工程についてJIS規格を制定したと発表した。仕様書などの見直し方や観点などを規格化し、ソフトウェアの品質向上や開発の効率化を促す。
「JIS X 20246」は、設計書・仕様書の見直し作業を「計画作業」「レビューの立ち上げ」「個々人のレビュー」「要検討項目の共有および分析」「修正作業および報告作業」の順に整理し、実行するべきタスクや手順を規定するもの。システム開発や試験、保守などの場面で作るあらゆる仕様書に適用可能。
レビューの曖昧さをなくすため、「目的」「役割」などのレビューの観点10種、「執筆者確認」「同僚との机上確認」などのレビュー手法9種を定めた。JIS制定により、組織や個人のノウハウに依存することなく一定水準のレビューができるようになり、ソフトウェアなどの制作物の品質向上につながるとしている。
JIS規格制定の背景について経済産業省は「ソフトウェアは社会活動から日常生活まで広く活用されており、トラブル発生時の影響が大きいため、今まで以上の品質と、品質に対する説明責任が求められている」と説明している。
⇧「JISX20246」を参照するには、「日本産業標準調査会（JISC：Japanese Industrial Standards Committee）」に利用者登録しないと駄目みたいですね...一応、利用者登録は日本国内で活動する
- 事業所に所属する人
- 個人
であれば、可能であるということみたいです。
こういうノウハウは誰でも閲覧できるような仕組みにしてくれても良い気がしますが、著作権保護の観点から制限を設けてるようです。
今回は、「Spring Boot」の「複数プロジェクト」の連携などについて調べてみました。
レッツトライ～。
「マルチモジュールプロジェクト（Multi Module Project）」の構造には「nested」と「flat」の2パターンあるらしいが、「flat」は非推奨になるらしい...
なんか、「Spring Boot」に限らないけど、大規模な開発になってくると、複数「プロジェクト」を連携するってのが一般的らしい。
「Spring Boot」の公式のドキュメントによると、
⇧「マルチモジュールプロジェクト（Multi Module Project）」と呼ぶらしい。
で、「ビルドツール」によって、「マルチモジュールプロジェクト（Multi Module Project）」の構造を「nested」にできるか「flat」にできるか、あるいはどちらもできるのか、対応が異なってくるらしい。
まぁ、経緯は分からないのだけど、
In this series of posts, we will see various ways to implement multi module, hierarchical / parent-child projects using gradle. To provide a working example, this application implements a simple spring boot based rest like service.
This series:
Maven multi module example
Gradle multi project (module) example – Type I (nested)
Gradle multi project (module) example – Type II (flat)
https://idodevjobs.wordpress.com/2017/02/25/gradle-multi-module-example-type-ii-flat/
⇧ 上記サイト様によりますと、「ビルドツール」として「Gradle」を利用している場合は、「nested」「flat」の両方ができるということらしい。
ただ、「Gradle」の最新（current）のAPIドキュメント（バージョン 7.3時点）を確認したところ、
⇧ 何と言うことでしょう...
「flat」な構造の「マルチモジュールプロジェクト（Multi Module Project）」を実現するメソッド「includeFlat」について「Depricated（非推奨）」の文言があり、『Using a flat project structure is discouraged.』という説明で『「flat」な構造を利用することは、お勧めできません』とありますと。
何故に、「flat」な構造が非推奨になってしまうのかは分からないのですが、今後、新規開発の案件で、「マルチモジュールプロジェクト（Multi Module Project）」を導入することになった場合は、「nested」となっていくような感じでしょうかね...
2022年3月13日（日）追記：↓ ここから
なんか、二転三転してる感があるんですが、
Non-hierarchical project layouts
Gradle 7.1 deprecated project layouts where subprojects were located outside of the project root. However, based on community feedback we decided to roll back in Gradle 7.4 and removed the deprecation. As a consequence, the Settings.includeFlat() method is deprecated in Gradle 7.1, 7.2, and 7.3 only.
https://docs.gradle.org/current/userguide/upgrading_version_7.html
⇧ コミュニティの声を反映して、deprecatedを取りやめたらしい。
まぁ、そもそもとして、deprecatedにしようとしてたことの方が意味分からんかったというか、理解できんかったのだけど、徒に現場を混乱させないで欲しいかな...
2022年3月13日（日）追記：↑ ここまで
Graldeで提供してるサンプルが動くか確認してみる
Gradleの公式のドキュメントで、
As software projects grow, it is common to organize large systems into components that are connected following a certain software architecture. Usually, it makes sense to also organize the artifacts (source code etc.) that make up the software in repositories and folder structures that reflect component boundaries and architecture. If Gradle is used to build such a software system, it can help you to perform this organisation and enforce boundaries between components.
https://docs.gradle.org/current/userguide/structuring_software_products.html
You can look at Gradle as a modelling tool for your software: It allows you to describe the coarse grained structure and architecture of your software in a model written in Gradle’s DSLs. The build tool Gradle can then interpret this model to build the software.
https://docs.gradle.org/current/userguide/structuring_software_products.html
⇧ プロジェクトが肥大化してきた際に、対処できるのが「Gradle」ということらしく、
An Example
How you architect your software and how you divide it into components depends on what you are building. There is no one-fits-all solution. Hence, Gradle does not enforce a particular structure on you, but rather offers the tools to model your individual setup.
https://docs.gradle.org/current/userguide/structuring_software_products.html
You can download the full sample to explore, build and run it.
https://docs.gradle.org/current/userguide/structuring_software_products.html
⇧「the full sample」のリンク先のページで、サンプルが公開されてるらしいので、ページに行ってみて、「Groovy DSL」ボタンを押下してダウンロード。
で、「Eclipse」でインポートすれば良さ気らしい。
とりあえず、zip形式に圧縮されているので、「展開（解凍）」しておきます。インストールしてた「7-zip」で「展開（解凍）」してますが、標準の「展開」機能でもいけるかと。
「展開（解凍）」されました。
そしたらば、「Eclipse」を起動して、「ファイル(F)」>「インポート(I)...」を選択。
「参照」で、先ほど「展開（解凍）」しておいたものを指定して、「次へ(N)>」を押下。
特に何も変えておらず、デフォルトの状態で「次へ(N)>」を押下。
「完了(F)」を押下。
インポートに結構時間がかかります。
で、エラー。
説明 リソース パス ロケーション タイプ The supplied phased action failed with an exception. Could not create task ':android-app:app:assembleRelease'. Could not create task ':android-app:app:lintVitalRelease'. SDK location not found. Define location with an ANDROID_SDK_ROOT environment variable or by setting the sdk. dir path in your project's local properties file at 'C:\Users\Toshinobu\Downloads\sample_structuring_software_projects-groovy-dsl\android-app\local.properties'. sample_structuring_software_projects-groovy-dsl 行 0 Gradle Error Marker
⇧「Android」系のプロジェクトで、「Gradle」のタスクが作れないということらしい。
とりあえず、以下のファイルで「Android」系のプロジェクトの部分をコメントアウトしてみる。
■/sample_structuring_software_projects-groovy-dsl/settings.gradle
// This is an empty umbrella build including all the component builds.
// This build is not necessarily needed. The component builds work independently.
includeBuild('platforms')
includeBuild('build-logic')
includeBuild('aggregation')
includeBuild('user-feature')
includeBuild('admin-feature')
includeBuild('server-application')
//includeBuild('android-app')
■/sample_structuring_software_projects-groovy-dsl/build-logic/settings.gradle
dependencyResolutionManagement {
repositories {
gradlePluginPortal()
google()
}
}
includeBuild('../platforms')
rootProject.name = 'build-logic'
include('commons')
include('java-library')
include('kotlin-library')
//include('android-application')
include('spring-boot-application')
include('report-aggregation')
⇧ 奇しくも、両ファイルとも、13行目という、西洋では忌み嫌われる数字を表してるのが何とも言えませんな...
で、「Eclipse」の「Gradle タスク」で実行してみると、
何か、ビルドが失敗してしまいますと...
コマンドプロンプトからだと、
いつまで経っても、96%の状態で進まないのだけど、「Spring Boot」内蔵の「Apache Tomcat」は動いてる状態らしいので、試しに、ブラウザで「http://localhost:8080」にアクセスすると、gradleのリリース一覧が表示されましたと。
「http://localhost:8080/admin」にアクセスすると、「/sample_structuring_software_projects-groovy-dsl/server-application/app/src/main/java/com/example/myproduct/server/MyProductAdminController.java」経由で「/sample_structuring_software_projects-groovy-dsl/server-application/app/src/main/resources/templates/admin.html」が表示されましたと。
バージョンを入力して、「Submit」ボタンを押下後、「http://localhost:8080/」にアクセスすると、
バージョンがマッチしない場合は、何も表示されない模様。
もう一回「http://localhost:8080/admin」にアクセスし、バージョンのレンジを変えて、「Submit」ボタン押下後、「http://localhost:8080/」にアクセスすると、
今度は、バージョンとリンクの一覧が表示されました。
コマンドプロンプト上で「Ctrlキー」+「C」を押下で、「Spring Boot」内蔵の「Apache Tomcat」を停止で。
とりあえず、「Eclipse」の「Gradle タスク」からの実行が失敗するので、微妙ですが、「マルチモジュールプロジェクト（Multi Module Project）」が動いたということで。
ただ、「Gradle」だと「multiple components」って言ったり、「Spring Boot」だと「multi module」って言ったりで、用語が統一されてないから、いまいち同じ意味合いで捉えてよいのかが分かりかねるというね...
まぁ、結局、公式のサンプルが、「統合開発環境（IDE：Integrated Development Environment）」のほうだと動かない気がするんだけど、「Eclipse」以外だと動くんかな？
毎度、モヤモヤ感が半端ない...
今回はこのへんで。
