栞/#devprocess
「テストは品質を上げない」
「1チーム1アプリケーションになるように、マイクロサービスにアプリケーションを分割することです。 アプリケーションが単機能であり、それに関わっている開発者も数名という状況であれば、マイグレーションはうまく機能することが分かっています。」
「オンプレミスのときはサーバの連続稼働時間を伸ばすことが正しいと思っていました。ですが、長時間稼働したサーバは不安定になり障害の芽を生みます。また、稼働時間が長くなると「動いているサーバは触りたくない」という心理的障壁を生み出し、より良い構成に変えようという気持ちを削ぎます。 これらの理由から長時間稼働したサーバはリスクと見なし、一定時間を超えて稼働しているサーバは新しいサーバに入れ替えています。 Immutable Infrastructure なのでサーバはいつでも破棄できる状態であり、新しいサーバを立ち上げるのも自動化できているので運用の手間は増えません。」
「ポエム駆動開発(ぽえむくどうかいはつ;poem-driven development;PDD) ポエムにより開発を進めるプログラム開発手法のひとつ。初めにポエムを高らか(tkrk)に宣言(ポエムファースト)することで、非機能要求までを広くカバーできるとされ、ビヘイビア駆動開発を補完する手法として注目され始めている。タスク完了後のレトロスペクティブ(振り返り)としてのポエムラストを行い、次の開発サイクルへとフィードバックするアジャイル的側面もある。 全体を総括するtkrkなポエムは、PMBOK(プロジェクトマネジメント知識体系ガイド)で推奨しているプロジェクト憲章との類似が見られるが、情動面に踏み込んだもので、要求仕様ではなく願望仕様の定義を試みるものである。 ポエム、アンサーポエムのやり取りは活発なディスカッションと異なり、意思決定のステークホルダー(利害関係者)を意識しないブレインストーミングに近い形態となる。ただしここで得られるアイデアの利用ライセンス等については整備が必要と懸念の声もある[要出典]。 各開発者が日々記すポエム(デイリーポエム)についてはメンタル面の安定をもたらす副次的効果があるとされる。必ずしもプロジェクトに関連することだけを記す制約があるわけではない。 ・ポエム編集にかける時間の増大 ・ポエム閲覧にかける時間の増大 これらは問題発生あるいはその予兆と言われており、プロジェクトマネージャーが気配りすべき事項となるが、ポエムの内容に深く介入することは、さらなる問題を引き起こす恐れもあり慎重に行なう必要がある。 黙認あるいは「いいのよ」するなど、厳密なプロジェクト管理のスコープ外とするのが望ましい。 開発者のPDD基盤環境としてpplogというサービスがシェアを伸ばしている。 私は何を一生懸命書いているのだ、もうだめだ。 2014/02/06 04:16:41」
すぐ消すリリースブランチ、必要に応じてよさそう
「リリース頻度は多ければ多いほうがいいに決まっている。そのためには、技術を尽くして高速化するべきだ。その上で、その結果としてのリリース頻度の向上が、そのままストレートに成果につながらないことが問題である。そしてそれは、マネジメントの問題だ。リリースの自己目的化を問題視するのは、その意味で、視点がズレているように思える。」
「テストファーストのユニットテストは、中間的オブジェクトや間接的で過剰に複雑な構造を生みがちだ。「遅い」ものをすべて避けようとするのがその理由で、データベースやファイルIOなどを避ける。ブラウザを使ってシステム全体をテストするのも避けようとする。結果として、本当に恐ろしく巨大なアーキテクチャが生まれてしまう。サービスオブジェクトやコマンドパターン、さらにひどいものたちが絡み合ったジャングルだ。」
「ぶっちゃけ開発速度はそこまで早くない。どちらかというと作業は丁寧で、守備範囲は広いけど専門範囲は狭い。MTGでは専門分野でないところは事前に下調べしてアイディアをぶつけてくる。そして馬場くんが凄く申し訳無さそうに否定しながら別の提案をしてくるのだけど、それを凄く楽しそうに会話に参加してくる。そして、開発品質や設計、機能の目的や実現方法にめちゃくちゃこだわりがある。作ってみてユーザ検証、作ってみてユーザ検証、を延々繰り返しています。リーンスタートアップってもっと速攻作って検証を繰り返すんじゃないの？と聞いてみたら、これでも開発工程は大分端折ってますよ、的な返答。んー、巷で流行ってるアジャイル開発とかリーンスタートアップとかってやつの意味を僕がちゃんと理解していなかったかも。」