はてなブックマーク

当初はちょっとしたSOLID批判のつもりが、「藪を突ついて蛇を出して」しまったのですが、物事はそこから具体的で目に見えるものへと発展しました。仮に、近頃はSOLID原則が役に立たなくなっているのだとしたら、何に置き換えればよいのでしょう？　あらゆるソフトウェアに通用する原則はあるのでしょうか？　そもそも「原則」とは何を意味するのでしょう？ 私は「仕事がたのしくなるソフトウェアならではの特性や性質がある」ということを確信しています。コードでそのような質が高まれば高まるほど、仕事もどんどんたのしくなります。しかし、何事もトレードオフですから、自分の置かれている状況をつねに考慮する必要があります。 そうした特性はたくさん存在しており、互いに重なりや関連がありますし、説明の仕方もさまざまです。ここでは私がコードで気にかけている要素を強く支えていると思える5つを選びました。選ぶ数はこれぐらいが丁度良

「変更容易性の高いソフトウェアによるアジリティの獲得」というDXの本質がソフトウェアエンジニア以外には伝わってない感じなんだな

A list of online resouces relating to "『Team Topologies』" in Japanese. order by created_on DESC.

Webサイト：https://www.ninja-testing.com/ （初出スライドより借用） 咳によって提唱された受け入れテスト実行スタイルのプラクティス。 2004年のJaSSTとXP祭りで最初に発表された。 毎日、ストーリーの受け入れテストを実行する。TDDの受け入れテスト版。(ATDD) 忍者式の直接の由来はタケカワユキヒデの単語の勉強法から。 参考：https://twitter.com/m_seki/status/508957718531416064 初出：http://www.jasst.jp/archives/jasst04/pdf/A7ah.pdf 解説：http://www.druby.org/summer10x.pdf 手動で実施する ストーリーのゴールをテストで記述 作ったらテストで確認する 受け入れ試験を全部やりなおして壊れてないことを確認 ペアテスト スト

本書は、"Jonathan Rasmusson. Competing with Unicorns: How the World's Best Companies Ship Software and Work Differently. The Pragmatic Programmers, LLC, 2019. 978-1-68050-723-2"の全訳です。著者の訳書は『アジャイルサムライ』（オーム社、2010年）、『初めての自動テスト』（オライリー・ジャパン、2016年）に続く3作目です。 本文中では明示されていませんが、本書の対象読者について、著者は出版後のインタビュー記事で次のように語っています。「業務としてソフトウェアデリバリーに関わっている人たち（開発者、テスター、デザイナー、マネージャーなど）なら誰でもだけど、本当の対象読者は経営リーダーを始めとした、チームをプロダクトやソフトウ

QRC: Quick Reference Card だそう。このQRCは『Team Topologies』公式サイトの Community Materials — Team Topologies でも紹介されている。

WelcomeVisitors / Discord / 執筆者募集中 / 西郷真理子 / 「データ」についての Alan Kay とRich Hickey のやりとり / Patterns in Architecture / Alistair Cockburn / スプリントゴール / 『コーチングアジャイルチームス』 / 高江洲 睦 / 細澤あゆみ / 『Tidy First?』 / 『パタン・