Yoshitaka Kawashima kawasima

アーキテクチャ大全のサンプル

これくらいの実例とともにソリューション選択できるようにしていきたい。

このGraalがすごい

@kawasima

kawasima

GitHub: https://github.com/kawasima
Qiita: https://qiita.com/kawasima
SlideShare: http://www.slideshare.net

アーキテクチャ設計のドキュメンテーション

コンテキスト

アジャイルプロジェクトのアーキテクチャは、別々に記述され定義されなければなりません。すべての意思決定が一度にされるわけでもなく、プロジェクト開始時にすべての意思決定がされてるわけでもありません。

アジャイル手法では、ドキュメンテーションに反対はしませんが、価値のないドキュメンテーションはいけません。チーム自身の助けになるようなドキュメントは価値がありますが、ちゃんと最新化し続けなければなりません。膨大なドキュメントでは、最新化されなくなることでしょう。小さくまとまりのあるドキュメントは少なくとも更新される可能性はありますよね。

また膨大なドキュメントはだれも読みません。たいていの開発者はソースコードサイズの合計よりも(byte的な意味で)大きな仕様書が書かれたプロジェクトを少なくとも1回は経験したことがあるでしょう。開くのにも、読むのにも、更新するのにも、そんなドキュメントは大きすぎます。一口大のピースに分解すれば、すべての関係者にとって消化するのは簡単になりますよね。

プロジェクトが動いている間、追跡するのが難しいことの1つに、ある意思決定の裏に隠された「思い」があります。プロジェクトに新しく参画した人は、それまでに決定されたことに困惑したり、戸惑ったり、喜んだり、怒ったりすることでしょう。理念や因果関係を理解しておかないと、その人は次の2つの選択をすることになります。

こんにちは

Hello World

	import java.time.LocalDateTime;
	import java.time.Month;
	import java.time.ZoneOffset;
	import java.time.zone.ZoneOffsetTransition;
	import java.time.zone.ZoneOffsetTransitionRule;
	import java.time.zone.ZoneRules;
	import java.time.zone.ZoneRulesProvider;
	import java.util.*;

	public class ZoneTokyo2020Register {

	package sandbox;

	import org.junit.Before;
	import org.junit.Test;
	import sun.misc.Unsafe;

	import java.lang.reflect.Constructor;
	import java.lang.reflect.Field;
	import java.lang.reflect.Modifier;
	import java.util.ArrayList;

	{
	"entries": [
	{
	"label": "Struts1",
	"quadrant": "Languages&Frameworks",
	"ring": "ADOPT"
	},
	{
	"label": "Waterfall",
	"quadrant": "Techniques",

	america:
	echo "America"

	great:
	echo "Great"

	again:
	make america great again

	.page-0 *{text-align:center}

	.page-5 h1{font-size:large}.page-5 img{width:85%}

	.page-17 img{width:50%}

	.page-25 *{text-align:center}

	.page-27 img{width:80%}