Categories
Agile

進化的アーキテクチャの読書会

Agile459のイベントで8月から「進化的アーキテクチャ」の読書会が始まりました。 1回目は1章と2章の最初の部分まで。 1章は概要の説明という感じで、ここだけでは何かを理解できるものではなさそう。適応度関数 Fitness Function とは何だろうというモヤモヤした雰囲気でした。 ここで、本と並行してウェブ上の情報を探してみました。 とっかかりは本書の手引きとなるウェブサイト。 Building Evolutionary Architectures 例えば、進化的UIを構築するための microfrontends pattern を説明するプレゼンテーションや Fitness Functions を分類するための各種ツールなど。 それと Fitness Function Katas という「カタ」が紹介されています。この「カタ」を見ていくのも良さそうに思いました。 以下、一部を抜粋。 Avoid Complex Code 新卒やインターンを雇った際のコードレビューなど、長すぎるメソッドや特定のクラスに依存、結合度の問題。 Break On Upgrade バージョンを X + 1 にアップグレードした際に、バックポートした機能は影響を及ぼさない(無効)になること。 Degrade Gracefully サイトの利用が増加した際に、極端なパフォーマンスの低下を起こさないこと。DevOps。 Doc Sync With API 例えば外部のベンダーがオーダー状況をAPIで確認する場合など、新たな機能を追加した時点でAPIのドキュメントが古くなってしまう。ドキュメントは現在のコードとマッチしていないといけない。 などなど。 これまで TDD のイベントなどでコードベースのリファクタリングを学んできましたが、このような適応度関数を見てみると、システム全体のアーキテクチャをベースとして適応度関数を用いてリファクタリングができる状態を維持することを一つの目的としているように思いました。 次回の読書会はこちらです。ご興味があればお気軽にご参加ください。 参考記事 Netflix / Chaosmonkey カオスエンジニアリングの原則

Categories
Agile

pytestでTDD

Test Driven Development with pytest を拝読してのメモ書き。 unittestはクラスから書く必要があるが、pytestはfunctionで書き始めることができる。 TDDとは 失敗するテストを書く テストを通すコードを書く 必要に応じてリファクタリング Red-Green-Refactor サイクル。 なぜTDDを用いるか テストを書くには入力と出力を知っている必要がある。TDDはコーディングを始める前にアプリのインターフェースについて考えることを強制する。強制する、というときつい感じですが、何が与えられて何を出力すれば良いかをシンプルに整理するきっかけになる感じ。 コードベースでの自信につながる。新たな変更がシステムを壊したとしても、容易に修復できる。 あらゆるバグをなくすことはできなくても、少なくすることは可能。バグ対応する際にテストを書けば安心につながる。 ドキュメンテーションとして使える。フィーチャーの入出力をテストで表現することで、そのコードのインターフェースがどのように使われるかを知ることができる。 コードカバレッジ pytest-cov がポピュラー(らしい)。 コードカバレッジが高いというのは、バグがないということではなくて、想定されるあらゆるシナリオについてテストされているかどうか、という指標。 インテグレーションテスト ユニットテストは個々のモジュールの振る舞いが期待通りに動作することの確認。一方、インテグレーションテストはモジュールを束ねて、期待通りに動作するかを確認する。 インテグレーションテストは個々のコンポーネントのテストが通るまで失敗(fail)する。インテグレーションが成功(pass)すれば、ユーザーの要求に合うように作られたと判断できる。 Prime Numbersの実装例 ※省略 Inventoryの実装例 ※省略 まとめ ユニットテストは個々のモジュールが期待通りに振る舞うことを確保する。インテグレーションテストはモジュールの集合(いわばコンポーネント)が相互的に期待通りに動作することを確保する。 (実装例の中にあった)fixtures や parameterized functions は要件に合わせて素早くテストケースを対応させることができる。

Categories
Agile

TDDは 過大評価されてる?

“Test Driven Development is overrated” という記事を拝読してのメモ書き。 “TDDは過大評価されてる” と言われて残念に思ったのと同時に、TDDが都市伝説化していると感じた。(ことからこの記事にまとめたとのこと) TDDのアイディアは Kent Beck によって作られた。“Test Driven Development” written in 2003 小さな落ちるテストを書く テストを通す機能を実装する リファクタリング “Red, Green, Refactor” でもTDDがあまり実践されていない現実。 QAの部署がテストを書いている モックとかスタブとかとても手間がかかる 利益がない 遅い いや、デベロッパーは次のことに責任を持って取り組んで欲しい。 ニーズに対して正しい技術を用いる 理解しやすく テストしやすく 拡張性を持たせ シンプルに ユニットテストの土台の上でサービスやUIが成り立っていると考えれば、利用者からのフィードバックループの増加に役立つし、メインゴールとしてのDevOpsにもつながる。 主な二つの利益。 テストで定義した通りにコードが動くこと どのようにコードを書いていくかを考えて明記すること コードとその機能に自信を持つことで、チーム全体として速く回せるようになる。

Categories
Agile programming

phpのテスト環境 – Windows

メモ書き程度で恐縮ですが。 ローカル環境の場合 レシピ– Windows10– PHP-7.4.x– phpunit– Git for Windows– VS Code https://windows.php.net/download/ここからNon Thread Safeのzipファイルをダウンロードして展開し、C:\php へ配置。 環境変数(システム -> 詳細設定 -> 環境変数)を開いてユーザーもしくはシステムの環境変数:PATH に C:\php を追加。 合わせて git の環境も整えておく。 https://gitforwindows.org/利用環境に合わせてインストーラーをダウンロードして実行。 ssh でgitに接続するための鍵(秘密鍵、公開鍵)を生成。※詳しい記事がいろいろ見つかると思うので省略します。 鍵のセットが生成できたら、githubのウェブサイトを開いて、SSH and GPG keys に公開鍵id_rsa.pub を登録します。 そして phpunit のセットアップ。https://github.com/tddbc/php_phpunit作業用のフォルダを用意して、 VS Code で php_phpunit フォルダをワークスペースに追加。VS Code内のターミナルを開く。ここで「規定のシェルの選択」からGit Bash C:\Program Files\Git\bin\bash.exe を選びます。すでにPowerShell が開いている場合はターミナルを閉じて開き直すなど。 ここで phpunit をインストールするには、openssl とmbstring が必要になるので、C:\php\php.ini-development をC:\php\php.ini にコピーするなどして編集。 上の2行を有効にしておきます。 あとは tddbc/php_phpunit のセットアップにしたがって、VS Code のターミナルで、 curl -sS https://getcomposer.org/installer | php php composer.phar install ./vendor/bin/phpunit 上記を実行してテストが通ればOKです。 WSL+Ubuntu環境の場合 php-7.2 は入っていたので、ssh-keygenなどでssh接続環境を整えて、上記の場合と同様に git clone で tddbcのリポジトリからプロジェクトファイルを ubuntu の作業フォルダに複製します。 としたところ ext-dom と ext-mbstring が足りない模様。 として、あらためて、 しばらく時間がかかりますが、インストール完了。 これでサンプルソースのテストが通りました。そして、VS Codeからの編集ですが、ウインドウ左下の ><のアイコンをクリックして Remote-WSL: New Window を開けばファイルの編集、ターミナル操作ともにOKでした。

Categories
Agile

XP本読書会最後のふりかえりのふりかえり

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 エクストリームの純度 アジャイルでもそうですが、ドキュメントを書かないことの言い訳に使われることがありますね。でもそれ以前にコミュニケーションの問題があるかもしれませんし、様々なスナップショットを大量に生産したところで時間のロスばかりであまり役に立つものではない。頑張ったことの証拠としてカサ増しにはなるかもしれませんが、それよりは成果物の品質や価値を高める方が大切。その上で必要とされるドキュメントがあれば用意するのは当然。 と言いつつ、このAgile459の中でも打ち合わせのために事前にドキュメントを用意したりしていますが、それも個人が思うままにかなりの時間を割いて作ったりしているので、そのあたり、せっかくXPとか学んでいるわりに実践が伴っていなかったり、コミュニケーションが足りなかったりしています。コミュニティの運営にもこの学びを活かさないといけませんね。 オフショア開発 オフショアには権限の不均衡が伴う とあるように、身の回りで聞くオフショアとかニアショアの案件はコストの話にしかなっていなくて、本に書かれているようなコミュニケーションとかリスペクト、単一のコードベースとは異質なもののような気がします。そうではなくて、マルチサイト(拠点の違い)をどう活かすか。メリットとしては例えば多様性と時差でしょうか。ライフスタイルの違い、物事の捉え方の違いを開発や成果物に活かす。あるいは時差を活用してうまく連携することでまさにエクストリームな開発を進めるなど。 結論 最近、働き方が問われていますが、まさにこのXPの原則そしてプラクティスがこれからの働き方に役立つと思います。 今回、ふと思いついてAdvent calendarで勢いでXP本読書会をふりかえってみましたが、読み返すたびにあらたな気づきがあります。すぐに忘れているということもありますが、また折をみてXP本をふりかえってみたいと思います。

Categories
Agile

XP本読書会15,16回目のふりかえりのふりかえり

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 XP本読書会15回目と16回目からいくつかピックアップ。 ロゼッタストーン プロジェクトが停止する前に、ビルドやテスト、システムを理解するためのガイドのようなものを書いておく。まぁ、停止する前というのもいつかわからないので、プロジェクト開始に合わせて準備して、随時更新しておくのが良さそう。 解決策の複雑さ Agile459のコミュニティの中で「リファクタリング」が話題にあがることがわりとあります。なかなか日常の仕事の中でリファクタリングに時間をかけるのが難しいとか、その成果を説明するのが難しいとか。あるいは、一旦リリースしたものについて、具体的な予算のないところで手間(工数)をかけることができないとか。ですが、そういった気がかりがあるなら実践して前に進んだ方が良いですし、経費なのか投資なのかという判断が必要ならそういう協力者を見つけておく(15章)のが良さそうです。 継続的にデリバリーする中で、少しずつ複雑さを削り取っていく と考えると、間違いなくメンテナンス性とか開発効率につながるわけで、変更に柔軟に対応できると考えればオープンにしてアピールすべき点とも思います。逆に、リファクタリングをしないで、複雑な状態のまま変更が求められるとなると、負担が増すばかりで、変更に対しても言い訳が先に立ってしまうような気がします。取引先も含めてお互いに気持ちよく仕事を進めるには大切な要素と思います。 また、次のセクションに出てくるトレーサビリティを考えると、こまめにリリースしておくことで、仮に大きな問題が見つかっても対応しやすいですね。これが長期間にわたってしまうと、何をどこまで戻すとか、その場合の影響範囲とか、考えるだけでもストレスになりそうです。 インタビュー ペアプログラミングであり、チーム開発なのでそれができないとなるとXPの導入は難しいということ。それと、一部見過ごしていたのですが、見積もり当初は要件を隠しておいて、後からすべてのフィーチャーを要求される、というリスクもあるんですね。ここはやはり顧客との信頼関係ができていないと難しいですね。 全員が品質に責任を持つ 何か問題があると、伝言ゲームのように芋づる式に個人の責任が問われて対応するのが当たり前のような場面が多かったような気がします。それだとリスク管理ができていないわけで、やはりチームでコードを共有してテストも自動化することが大切。チーム全員で責任を共有して、自信を持ってプロダクトをリリース。チーム内のモチベーションにもつながります。

Categories
Agile

時間、設計、パターン – XP本読書会14回目のふりかえりのふりかえり

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 この回のログを読んで気になった部分をピックアップ。 時間の重要性 ソフトウェアはレバレッジゲームだ Wikipediaによると、レバレッジの言葉は「てこ(lever)」が由来なんですね。テコの原理か。なるほど。 だけどわりとそうなっていないケースが多いのが残念だなぁと思いました。というのは、毎回引き合いがあるたびに1から開発して納めて、しばらくして似たような案件があっても、また最初から作り直しているような。まぁ作り直すのは良いとしても、そこから横に展開するというか、汎用的にしてみるとか、可能性はありそうだけど、努力が足りないのか、営業力?、具体的なニーズの把握?もしかすると、安易に取りかかってしまうのが問題かもしれません。その先にどうありたいか、とかの見通しなど。 XPの戦略は「常に設計する」 この考え方が大切と思いました。要件を確認して詳細まで設計しても、そこから実装を進めていくうちに設計の問題が見えてきたり、要件も変わってきたりするので、それが判明した時点で設計の見直しが常に行えるようにする。となると、ドキュメントがボトルネックになったりするので、最低限必要なものにするとか、オンラインで共有して更新可能にしておくとか、テストコードで仕様がある程度表現されていれば、テストコードのメンテナンスで対応できる部分もあったりとか。長期に渡ったり、規模が大きかったりすると、どうしてもあれこれドキュメントを増やしてしまったりしますが、成果物の品質がよくて、説明しなくても使えるようなものになっていれば、それほどドキュメントに頼ることもないのかなぁと。何というか、ドキュメントを作ることは本来の目的ではないですよね。例えば、管理のために必要、と言われれば、では何のために管理をするのでしょう。管理すること自体がボトルネックになっていて、生産性や品質を下げる要因かもしれません。それよりは、常に設計できる環境にすることで、生産性がグッと向上して品質も上がれば、それこそさっきのレバレッジゲームに乗れる状況が作り出せるかもしれません。 こうした設計の改善が共通してたどり着く先が、パターン 重複は悪、パターン と言われても、なかなか重複が取りきれなかったり。このあたり、チーム内でノウハウがあって、スマートに対応できれば良いのですが、場合によってはノウハウがあまりなかったり、学ぶ機会が少なかったり、ということもあると思います。例えばコミュニティで相談してみて勉強会、という可能性もあるかもしれません。先日開催したGDCRの中で、オブジェクト指向設計についての解説があったのですが、それを理解するまでの余裕がなかったのが残念。このようにふりかえってみると、あれもこれもまだまだ学ぶことが山積みです。

Categories
Agile

XP本読書会13回目のふりかえりのふりかえり

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。 スコープの管理 ここ数年は契約の関係でスコープの調整ができるようになってきましたが、過去に関わった仕事で、スコープが調整されるケースはあまりなかったように思います。やるべき課題とスケジュールが決まっていて、とはいってもスケジュールどおりにはなかなか進まず、スコープは固定されたまま、あるいは開発の過程で次第に膨らむケースが多かったかもしれません。 数年前、あるプロジェクトに途中からお手伝いで参加しました。当初、担当の方に話を聞いてみるとあれこれ進んでいなくて、そのため取引先に状況を説明するのが難しそうな雰囲気。そこで、そのプロジェクトの中でほぼ手付かずの項目があって、ちょうど切り出すのに適当な規模だったので、その部分だけ急遽手伝ってある程度進めて、その成果物と合わせてとにかく状況をオープンにしましょうと提案。 すると、成果物の部分が取引先から予想外に良い評価をもらえたようで、それが信用に繋がってプロジェクトがうまく回り出したことがありました。そこからプロジェクトの風通しが良くなり、少しずつ成果物を積み上げていって落ち着いたようです。 いろいろ難しい状況があると思いますが、クローズにしてごまかしたところで疑心暗鬼になってお互いに不信感が募るばかりなので、とにかくオープンにして少しでも成果を出して一部分でも評価してもらえれば、そこからなんとか前に進み出すんじゃないかと思います。 テスト:早めに、こまめに、自動化 あとでまとめてテストしようとすると、テスト自体にとてもコストがかかるのと、どうしても欠陥が残ってしまうということ。さらに欠陥を取り除こうとしてもコストが増えるばかり。逆に、こまめにテストを実施していれば、欠陥も起こりにくいしそれほどコストもかからない。あと、プログラマー目線でのテストと、顧客目線でのテストによるダブルチェックが重要というお話。ダブルチェックといっても、テストの工程を分けるんじゃなくて、まとめてテストできるように自動化が必要、という感じでしょうか。