Skip to content

Instantly share code, notes, and snippets.

@asufana

asufana/開発環境について.md

Last active December 14, 2015 03:02
Show Gist options
  • Save asufana/373bf67da4c5522eee95 to your computer and use it in GitHub Desktop.
Save asufana/373bf67da4c5522eee95 to your computer and use it in GitHub Desktop.
Download ZIP
開発環境について
Raw
開発環境について.md

開発環境について

2015/04版

Webシステム開発環境について概要を記述する

  • 情報システム部門として社内業務システムを内製している
  • 言語はJava

システム構成

  • アプリケーションはPlayで直接公開している。Appサーバ・Webサーバは未使用
  • Webサーバ・APIサーバ・DBサーバは各１台構成
  • APIサーバ上にMavenサーバを立てて、ローカルライブラリ配布に利用
  • 本番データはBackupサーバ経由で開発者端末にコピーできる

サービス構成

  • アプリケーションはWeb系とAPI系で大別できる
  • HTTPリクエストを受けて、Web系はHTMLを、API系はJSONを返却する
  • API系は、社内システムに対してそれぞれ用意してある
  • Web系は、複数のAPIを利用してアプリケーションを構成する
  • Web系の中にはAPI用のインターフェースを持つものもある（価格表システムほか）

課題

  • APIのオーケストラレーション的なミドルウェアが欲しい
  • APIのダウンをWebに伝搬させたくない、キャッシュのコントロール、クライアントライブラリの自動生成など

サーバ構成

  • 2012年に選定した構成がそのまま踏襲されている
  • とは言えそれほど課題があるわけではない
  • Infrastructure as a codeするほどの背景もない

デプロイ

  • Jenkins & Jenkins slave 構成
  • Playコマンド＋シェルスクリプトでビルドスクリプトを用意
  • DBマイグレーションは、Play機能を利用
  • デプロイは各プロジェクト担当者が実施

課題

  • BlueGreenデプロイ環境の整備（サービスの無停止）

認証と認可

認証

  • ユーザ認証：　　OpenAM認証連携
  • システム認証：　OAuth認証

認可

  • ユーザ認可：　　SSOポータルからのアプリ利用申請、および各アプリ内個別制御

その他

  • アクセス制御：　ソースIPアドレス制御

開発言語

  • 2012/04以前はPerl、2012/04からJava6、2014/12からJava8
  • 部門の言語はJavaのみ（ViewのJS、デプロイグルーのShellなどは除く）

Java8いいよ

  • 言語自体に制約がある方がチーム開発には良いと考えている
  • 不当な制約は黒魔術で解決もできる（Lombok）
  • より表現力高く書けるようになった（ラムダ式）

フレームワーク

PlayFramework1.2.5.4 + Java8パッチ

  • フルスタックなWAF
  • 足回りはNettyでノンブロッキング
  • ステートレスでホットスワップで黒魔術（ByteCode操作）
  • ServletAPIに準拠しない（http://goo.gl/P96c8）

ORM

  • JPA（Hibernate）なので、テーブルとクラスが１対１のシンプルな関係
  • Playのクラスエンハンサが、JPA#entityManagerを密結合してくれる（＝DAO）

Playいいよ

  • とにかく基本機能がそろっているのがいい、ビジネスロジックだけに集中すればいい
  • 拡張機構も充分（プラグインシステム・クラスエンハンスシステム）
  • 最近は自分で選定したミドルウェアをグルーコードで繋ぐWAFもあるけど懐疑的（どっかでグルーな手当しないといけないんじゃね？）
  • SpringやStrutsと比べてソース規模もそんなに大きくないので、なんかあったら自分たちでどうにか出来るっしょ

ローカルライブラリ

  • すべてPlay基底クラス、あるいはPlayプラグインとして開発
  • 社内Mavenサーバあるので、普通にJarでもいいんだけどね
  • これからは汎用的なライブラリを増やしていきたいなー (დ☣‿☣)

業務スタイル

  • 業務時間：09:00 ~ 18:30
  • 残業禁止：なかなか帰らないので1830になったら皆に嫌がらせをする
  • 在宅勤務：週2回のリモートワークを試行中
  • 定例業務：毎日09:30からコードレビュー、週１勉強会

課題

  • 納期管理ができていない（残業禁止・在宅勤務などとペアで行う必要がある）

リモートワーク

  • Sqwiggleでプレゼンス管理
  • 開発者同士の確認もSqwiggleのチャットが主
  • ややこしい話はSqwiggleビデオチャットかSkype（チャット上に履歴が残らない問題あり）
  • デイリーレビューはSkypeのスクリーン共有で

Sqwiggle

開発の進め方

  1. ドメインエキスパートと課題について会話し、クラス図・状態遷移図を作成
  2. モデル＋単体テスト実装
  3. シナリオテストで処理の流れを確認
  4. モデルのぎこちない部分を、1 ~ 3 を繰り返して精度を上げていく
  5. 画面を作成してドメインエキスパートと確認

以前は、5.の前段階としてモックやプロトタイプを使ってユーザ要件を深く確認しようとしていたが、あまり効果的でなかったため最近は行っていない。

デイリー・コードレビュー

  • ひよこーどのチェック
  • コーディングルールの確認
  • ディスカッションの場

課題

  • プロジェクトの進捗状況確認も合わせて行っており、第三者には関係のない情報が多い
  • 前日差分からは読み取れないクラス構成などは、デイリーレビューで指摘することが難しい

不定期・コードレビュー

  • 不定期に実施
  • クラス図・状態遷移図の確認
  • クラス構成・責務・配置の確認

課題

  • コメントをコード上に直接記述しているが、チケットした方が管理しやすい
  • ただしチケットを起こすのが手間という問題がある

勉強会

  • 2012年から不定期に開催し、2013年から毎週実施
  • テクニカルなことよりも、普遍的な技術寄り（DDD、モデリング、リファクタなど）
  • 最近は持ち回り度が上がってきた

課題

  • 勉強会に参加せずとも後日内容把握できるよう、アウトプットを整備する
  • 持ち回り度を上げる
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment