地域密着型エリア広告配信リクルートの地域密着型広告ドコイク?アドネットワーク Ads by ドコイク?[無料でホームページを作成] [通報・削除依頼]
[無料でホームページを作成] [通報・削除依頼]

チーム開発方法

 ここでは、他者のとの共同開発に必要な技術を記述する。
--------------------------------------------------------------------------------
■ 分散型のバージョン管理システム
・ GitHub: https://github.com/
・ Bitbucket: https://bitbucket.org/
  https://www.atlassian.com/ja/software/bitbucket/overview, http://ja.wikipedia.org/wiki/Bitbucket, http://webbingstudio.com/weblog/internet/entry-651.html
・ gitlab:https://about.gitlab.com/
・ GitBucket:https://github.com/takezoe/gitbucket

■ 学習
・ サルでも分かるGit入門: http://www.backlog.jp/git-guide/
・ Pro Git: http://progit-ja.github.io/
・ Gitを使いこなすための20のコマンド: http://sourceforge.jp/magazine/09/03/16/0831212
※ UNIX/Linux/Macの場合は man git でマニュアルを読むことができる。

■ テキストファイルでの差分の取り方
・ git diff
・ svn diff
・ TortoiseGit: http://code.google.com/p/tortoisegit/
・ TortoiseSVN: http://tortoisesvn.net/
・ SourceTree: http://www.sourcetreeapp.com/ 

■ ドキュメント作成ソフト
・ Markdown:  
・ Textile:
・ reStructuredText:

■ 外部ライブラリ
・ Apache Commons:
・ ImageMagick:
・ Mechanize:

■ ブランチ戦略
・ gtihub-flow:
・ git-flow:
※ Pull Request はリポジトリ間だけではなく、同一リポジトリ内のブランチ間だけでも送ることができます。[1]

■ データベースイマグレーションツール
・ Migration (Ruby on Rails)
・ south (Django)
・ Migrations Plugin (Cake PHP)
・ Evolution (Play Framework)
Java
・ Flyway
・ Liquibase
・ dbdeploy

■ 依存関係の管理
◇ JVM系言語(リポジトリしてMavenリポジトリを参照する)
・ Apache Ant ( + Apache ivy)
・ Maven
・ sbt
・ Gradle
◇ Mavenリポジトリ
・ Maven セントラルリポジトリ
・ Sonatype (セントラルリポジトリのミラー)
◇ スクリプト系 (リポジトリとツールは同一)
・ CPAN
・ PyPl
・ RubyGems
・ npm

■ 世の中には「うまくいかない、終わらない」(=チャレンジングな)プロジェクトが(多数)存在します。[1]
理由
・ 目標(建前と本音)が間違っている
・ 見積もり(実験計画)が不正確(蛸壺化し、上が事務化したため、適した実験手法を各段階で現場レベルの知識で選択できていない)で納期(プロジェクト期間と実験計画のフロー)が異常に短く(原因結果を追求できず)、(各実験におけるプロフェッショナル)要員が(予算不足で)不足している
・ プロジェクトの終わりが定義されていない(最終目標やフローはあるが実際には逆さになっても実現できない)
・ メンバーのモチベーションが(壁が多すぎて失敗続きで)上がらず進捗しない
・ (開催期日だけが決められて形だけの会議で時間が取られ)プロジェクトの見える化ができていない
・ タスクの整理、進捗の管理、情報(要求仕様の建前と本音)の共有などができていない(特に前任者の仕事を引き継ぐ場合は後任者に情報を容易に受け渡せるようにできているかは大切にして欲しい。前任者の仕事を調べるだけで多大な苦労と時間を要し、上司からも文句を言われる状況は間違っている)
※ 買い手市場なのは分かりますが、必要な学術的知識を与えているかも先任者や上司は気を配るべきです。

■ チケット管理システム
◇ メリット
・ 「何をしなければいけないのか」というタスクの定義
・ 「誰がするのか」という担当者のアサイン
・ 「いつまでにするのか」という期限の管理
・ 「今どうなっているのか、作業中なのか、完了したのか」というステータスの管理
◇ システム(バグ管理システム、お客様からの問い合わせ管理、他部署への作業依頼管理)
・ Redmine
・ GitHub
・ Trac
・ Kanon
・ Bugzilla
・ Mantis
・ Backlog (10ユーザー、1プロジェクトまで無料)
・ YouTRACK (10ユーザーまで無償)
・ JIRA (商用)
・ Pivotal Tracker

■ インテグレーション = 以下のビルドとテストを行うプロセス [1]
・ すべてのソースコードを1ヶ所に集める
・ 依存するライブラリなどにパスを通す
・ 必要な場合はコンパイルする
・ データベースの構築とデータのロードを行う
・ 必要に応じてミドルウェアの設定や起動を行う
・ 単体テストと結合テスト、ユーザ受け入れテストなどを実施する

■ ビルドツール
・ Maven
・ Ant
・ Gradle
・ make
・ SCons
・ Rake

■ テストを書くためのフレームワーク
◇ テスト駆動開発(TDD)系フレームワーク
・ JUnit
・ TestNG
◇ 振る舞い駆動開発(BDD)系フレームワーク
・ RSpec (Ruby)
・ Cucumber
・ Jasmine (Javascript)
・ Specs2 (Scala)

■ CIツール
・ Jenkins
・ TravisCI

■ ガバレッジ計測ツール
・ Jacoco
・ Cobertura
・ Scct
・ SimpleCov
・ Rcov

■ 静的解析 (Jenkinsで利用可能)
・ Checkstyle
・ PMD
・ Findbugs
■ 動的型付け言語
・ JSLint (JavaScript)

■ 手作業のデプロイで便利なツール
・ Tera Term
・ RLogin
・ ClusterSSH/ Parallelssh/ Clusterlt

Java系言語(Scala, Groovy, JRubyなど)のOSSライブラリ: http://search.maven.org/
Mavenのpom.xml に依存関係を書く。<dependencies>
◇ Mavenの構成
・ pom.xml: プロジェクトのビルド定義
・ src/main/japa: アプリケーショコード
・ src/main/resources: アプリケーションのリソース
・ src/main/webapp: EWB-INFやJSPファイルなどのWeb関連ファイル
・ src/test/japa: テストコード
・ src/test/resources: テストでのみ使うリソース
・ target: Classやjar、テスト結果などの成果物

参考文献
[1] 池田尚史ら著、『チーム開発 実践入門』、技術評論社
[2] 「そもそもGitって何?」: http://blog.sixapart.jp/2014-03/mttips-02-what-is-git.html 
[3] 「チーム開発実践入門」勉強会: http://www.slideshare.net/yuishikawa/2014-0428-teamdevelopment
--------------------------------------------------------------------------------
「どこでも自動化」 「デイリービルドは君の友達」

池田尚史ら著、『チーム開発 実践入門』、技術評論社
 今までデプロイのすべてを手動で行っていた環境からすべてを自動化に変えようとする際に、何から手をつければよいかという質問を受けたことがあります。それに対する回答は「協力者と出資者を見つけろ」です。
 デプロイの自動化は開発者からQAチーム、そしてインフラチームの横串一環で達成できる成果物です。デプロイの自動化を進めると何がどう良くなるのかを根気よく説得し、チーム一丸となって目指してください。
 またそれを目指すうえでは、新しい環境やそれに費やす時間が必要です。出資者、会社であれば経営層に対してもデプロイの自動化について説得するようにしましょう。あなたの会社ではリソースが十分に余っていて、Googleの20%ルールのような研究時間が与えられているのであれば、説得する前に自動化に必要な作業を進めてしまい、動くものを持ってデモすることで説得してみましょう。価値を頻繁に届けることができれば、少なからず会社にとっても良い影響が出てくるはずです。
 チーム内に非協力的なメンバーがいた場合には、最初は面倒臭がって決められたルールを守らないかもしれませんが、根気よく自動化を推進してください。少しずつデプロイの自動化がチーム全体に、そして会社全体に浸透し始めたときにはそれがなくてはならない存在になっているでしょう。
 旧来からのデプロイには職人芸を求められていましたが、自動化がきちんと回り始めればこの職人芸は必要ありません。今までの職人も自動化環境をメンテナンスすることによって、夜はきちんと睡眠がとれて、休日を、プライベートをエンジョイできるようになるでしょう。会社にとっても、エンジニアを幸せにするデプロイの自動化をやらない手はないはずです。
--------------------------------------------------------------------------------
アクセス数
ページビュー数