栞/#devprocess
- 2015年1月
- 2014年12月
- 2014年11月
- 2014年9月
「テストは品質を上げない」
- 2014年8月
「1チーム1アプリケーションになるように、マイクロサービスにアプリケーションを分割することです。 アプリケーションが単機能であり、それに関わっている開発者も数名という状況であれば、マイグレーションはうまく機能することが分かっています。」
「オンプレミスのときはサーバの連続稼働時間を伸ばすことが正しいと思っていました。ですが、長時間稼働したサーバは不安定になり障害の芽を生みます。また、稼働時間が長くなると「動いているサーバは触りたくない」という心理的障壁を生み出し、より良い構成に変えようという気持ちを削ぎます。 これらの理由から長時間稼働したサーバはリスクと見なし、一定時間を超えて稼働しているサーバは新しいサーバに入れ替えています。 Immutable Infrastructure なのでサーバはいつでも破棄できる状態であり、新しいサーバを立ち上げるのも自動化できているので運用の手間は増えません。」
「ポエム駆動開発(ぽえむくどうかいはつ;poem-driven development;PDD) ポエムにより開発を進めるプログラム開発手法のひとつ。初めにポエムを高らか(tkrk)に宣言(ポエムファースト)することで、非機能要求までを広くカバーできるとされ、ビヘイビア駆動開発を補完する手法として注目され始めている。タスク完了後のレトロスペクティブ(振り返り)としてのポエムラストを行い、次の開発サイクルへとフィードバックするアジャイル的側面もある。 全体を総括するtkrkなポエムは、PMBOK(プロジェクトマネジメント知識体系ガイド)で推奨しているプロジェクト憲章との類似が見られるが、情動面に踏み込んだもので、要求仕様ではなく願望仕様の定義を試みるものである。 ポエム、アンサーポエムのやり取りは活発なディスカッションと異なり、意思決定のステークホルダー(利害関係者)を意識しないブレインストーミングに近い形態となる。ただしここで得られるアイデアの利用ライセンス等については整備が必要と懸念の声もある[要出典]。 各開発者が日々記すポエム(デイリーポエム)についてはメンタル面の安定をもたらす副次的効果があるとされる。必ずしもプロジェクトに関連することだけを記す制約があるわけではない。 ・ポエム編集にかける時間の増大 ・ポエム閲覧にかける時間の増大 これらは問題発生あるいはその予兆と言われており、プロジェクトマネージャーが気配りすべき事項となるが、ポエムの内容に深く介入することは、さらなる問題を引き起こす恐れもあり慎重に行なう必要がある。 黙認あるいは「いいのよ」するなど、厳密なプロジェクト管理のスコープ外とするのが望ましい。 開発者のPDD基盤環境としてpplogというサービスがシェアを伸ばしている。 私は何を一生懸命書いているのだ、もうだめだ。 2014/02/06 04:16:41」