Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Ordinary Practices
Search
wtnabe
October 19, 2013
Programming
0
340
Ordinary Practices
Kanazawa.rb meetup #14 で話したいつものプラクティスです。分かってる人にとっては当たり前のことだらけです。これと言って何か新しい発見はないと思います。
wtnabe
October 19, 2013
Tweet
Share
More Decks by wtnabe
See All by wtnabe
Ruby de Wasm
wtnabe
0
5
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
9
Decoupled System with Turbo Frame
wtnabe
1
59
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
710
let-me-edit-with-editor
wtnabe
0
270
google-photos-and-storage-and-rclone
wtnabe
0
360
one case of how to begin vuejs
wtnabe
2
400
Kanazawa.rb meetup #56 Coderetreat Intro
wtnabe
0
390
lightweight authenticity of microservices
wtnabe
0
400
Other Decks in Programming
See All in Programming
[PHPカンファレンス沖縄2024]「無理なくできるだけ安全に」テストもないレガシーコードをリファクタリングするテクニック
ikezoemakoto
3
110
[KR] Server Driven Compose With Firebase
skydoves
1
120
M5Stack に色々な M5ユニットをつないで扱う為の新たなアプローチ
gob
0
200
全方位強化 Python 服務可觀測性:以 FastAPI 和 Grafana Stack 為例
blueswen
1
360
RemixとCloudflare Stack におけるFile Upload
ossamoon
1
120
C#および.NETに対する誤解をひも解く
ymd65536
0
220
Делим тесты между QA и разработчиком
mariyasaygina
0
470
CDKを活用した 大規模コンテナ移行 プロジェクトの紹介
yoyoyopg
0
230
GitHub Copilot Workspace で我々のアプリ開発がどう変わるのか?
shuyakinjo
0
850
Cloud Adoption Frameworkにみる組織とクラウド導入戦略(縮小版)
tomokusaba
1
160
いまあるチームにフィットさせる Serverless そして Platform Engineeringへの挑戦 / Serverless Fits the Team You Have and Platform Engineering
seike460
PRO
2
1.2k
実践Dash - 手を抜きながら本気で作るデータApplicationの基本と応用 / Dash for Python and Baseball
shinyorke
2
220
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
23
1.7k
Music & Morning Musume
bryan
46
6.1k
Mobile First: as difficult as doing things right
swwweet
222
8.8k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
7.5k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
41
9.2k
The Language of Interfaces
destraynor
154
24k
Infographics Made Easy
chrislema
239
18k
VelocityConf: Rendering Performance Case Studies
addyosmani
324
23k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
44
2k
Raft: Consensus for Rubyists
vanstee
136
6.6k
The Invisible Side of Design
smashingmag
297
50k
Designing on Purpose - Digital PM Summit 2013
jponch
114
6.9k
Transcript
ぼくのやってる ふつうのこと @wtnabe Kanazawa.rb meetup #14 2013-10-19 (Sat) at DMM.com
Labo Kanazawa
お品書き
ざっくり Web開発のプラクティス 使ってるツール 本当に⼤切なプラクティス
ざっくり TDDとend-to-endテストの話多め 最後の話だけ覚えて、あとは適当に
Web開発のプラクティス1 バージョン管理 Tickets & Milestones deployの⾃動化
Web開発のプラクティス2 開発環境の仮想化と⾃動構築 Test-Driven Development Continuous Integration
使ってるツール1 Subversion ( Mercurial, Git ) Trac Capistrano Vagrant, Chef
使ってるツール2 Jenkins RSpec, SimpleTest, Jasmine, PhantomJS SimpleCov(RCov), PHPCPD, JSHint
Web開発のプラクティス
バージョン管理 全部⼊れる ログがあるので安⼼して忘れられる うまく⾏くかどうか分からない場合も元 に戻せるので安⼼ いわゆる共通ライブラリは別リポジトリ
Tickets & Milestones 〆切をMilestoneの締め⽇にしてタスクを その中に落とし込む 基本的に⼀つのタスク : ⼀つのチケット みんなが分かるようにする 「完了」可能なタスクにする
deployの⾃動化 ⼿作業はミスやブレに繋がる 「fiddlingを避けよ」『Release It !』p112 変なコツをなくす 誰がやっても同じになる
開発環境の仮想化と ⾃動構築 VMのセットアップから⾃動化 デザイナもLinux環境使ってます Win/Macの違いはもうありません
Test-Driven Development
の前に
どちらが本当? コードは触り続けると汚くなる コードは触り続けるときれいになる
どちらも本当
リファクタリング してますか?
リファクタリング “外から⾒えるふるまいを変えずに、ソフトウェ アをわかりやすくし、安いコストで変更できる ようにするために、ソフトウェアの内部構造に 加えられる変更。” 『リファクタリング: Rubyエディション』p76
あなたのコードは安⼼して 変更できますか?
TDD ⻑く使うコード、変更し続けるアプリは リファクタリングが重要 TDDはリファクタリングを最も効率よく ⾏う⽅法の⼀つ
TDD 完璧な⾃動化は⽬指さない カバレッジは場所によって0〜100% 機能の⼀部だけをテストできると捗る テストデータの⾃動⽣成やダブルの活⽤
Continuous Integration うっかりテスト実⾏漏れ防⽌ うっかり環境依存テスト防⽌ 静的解析便利
オススメ導⼊⼿順(案) バージョン管理 / deployの⾃動化 CI end-to-endテスト ユニットテスト
使ってるツール
Subversion 2006年くらいから(それ以前はCVS) Mercurial, Gitも⼀部併⽤ そのうちGitへ⼀本化するつもり
選択基準 当時は各種ツールのサポートがよかった GitのGUIは⻑らく貧弱だった コードホスティング、クラウド側の対応 はGitがイチバン
Trac Python製Issue Tracking System むしろSubversionはTracを使う理由 (CVSでは使えない)
Capistrano Ruby製deployツール 個⼈では2008年〜、組織では2011年〜 これを理由に関係者はRuby必須に 必須に RailsもPHPも
Vagrant, Chef Ruby製VM管理ツール + サーバ設定⾃動 化 開発環境構築の⾃動化と開発環境の統⼀ 「適当にVM作って設定漏れ」をなくす 昔からの⾃前ツールも組み合わせて テストにも絡んできます
Jenkins Continuous Integrationのスタンダード Java trunkを⾃動でテスト/静的解析 deployの記録も取るようにした
RSpec Ruby製テスティングフレームワーク BDDスタイル Ruby 1.8でも動く Railsと合わせて使うノウハウが多い けど、Rubyのコードならなんでもよい
SimpleTest PHP 4/5 両対応のフレームワーク ⾃前pear packaging 最新版はPHP 5⽤ ユニットテストとカバレッジ測定 レガシーなコードにはオススメ
RSpec + Capybara (end-to-end) with rspec-rails for PHP
Vagrant / RSpec + Capybara for PHP 開発環境の統⼀、URL完全⼀致 誰の環境でend-to-endテストを動かし ても同じように動作する
Railsでのノウハウを流⽤
Vagrant / RSpec + Capybara for PHP PHPのバージョンに依らない 「ど真ん中」なのでメンテナンスが放棄 される不安がほぼない
Jasmine JavaScript⽤BDDフレームワーク gemで⼊れられる spec書きやすさのためにCoffeeScriptも テストはブラウザで実⾏ 最近はPhantomJSと組み合わせて
PhantomJS Headless Webkit Browser 2012年からインストールが超簡単に Jasmineと組み合わせてCIに Capybara + Poltergeistでend-to-endに
SimpleCov(RCov) Rubyのカバレッジ測定 ⾃動化はしてません あくまで⽬安の把握にしか使ってません
PHPCPD PHPのコピペチェッカ CIで記録取り
JSHint JavaScriptの静的スタイルチェッカ 設定項⽬ありすぎてうざい ruby wrapper⾃作してrakeで呼んでる wtnabe/jshint4r Node.js不要 対応バージョンが古い><
静的解析や計測 特にいじりにくいコードはコピペ率が⾼ くてカバレッジが低いといった特徴が⾒ えてくる 数値で分かるので⽬標を決めやすい
本当に⼤切なプラクティス
覚えて帰ってください 不易と流⾏ 継続は⼒なり
不易と流⾏ もともと蕉⾵俳諧の理念の⼀つ 変化しない本質的なものの中にも新しい 変化を取り⼊れること。また変化を取り ⼊れ続けることこそが不易の本質。
不易と流⾏ 転じて教育の世界では「変わらないことも変わ ることもどちらも学ぶべき」と語られることが 多い。
例 流⾏ Node.js, Chef, PhantomJS 不易 イベントドリブン、⾮同期、⾃動化
継続は⼒なり
今⽇の話 急にできるようになった ものなどありません
さらに⾔えば
今回の話に新しいものは 特にありません
昔から⾔われていること
昔から やってる⼈はやってること
Travis CI登場から2年 github登場から5年 Rails / Selenium登場から来年で10年 CIのプラクティス登場から15年くらい "Refactoring"から来年で15年 SUnit登場から来年で20年
Ruby誕⽣から20年 WWW誕⽣から23年 DBMS登場から30年以上 オブジェクト指向誕⽣から35年以上
ツールは変わる
背景や⽂化は そう変わらない
より深く 継続的に学ぼう
ツールも知ろう ⽂化も知ろう
やってみよう
それこそを Kanazawa.rbの ⽂化にしよう
ありがとうございました
参考 Release It! 本番⽤ソフトウェア製品の設計とデプロ イのために リファクタリング: Rubyエディション