失敗から学ぶ 技術的負債との正しい歩き方 / learn from predecessors
# ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す https://www.youtube.com/watch?v=PSCmjrrbNkg # Howだけ考えると複雑さを導入して仕事が増える https://soudai.hatenablog.com/entry/2020/08/14/101657 # 質とスピード（2020春版） / Quality and Speed 2020 Spring Edition https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition # 判断と決断の違いと決断のコツ https://soudai.hatenablog.com/entry/2022/01/04/151923 # Worse Is Better -
「バグ」と呼ぶのをやめて、名前をつけてあげよう - blog.takuyasuemura.dev
ある日の午後、オフィスでサポートエンジニアとQAが会話していた。 サポートエンジニアは言った。「すべてのバグを直すことなんて不可能だ」。 QAはこう返した。「そんなことはない。バグとはただの考慮漏れだ。バグが市場に出るということは、テストするときになにかのパターンを考慮していなかった。ただそれだけだ。」 「その考えは素朴すぎる。例えば我々のSDKがユーザーの使っている別のサードパーティーのライブラリと相性が悪いことだってあるだろう。こういう組み合わせは無限にある。すべてを考慮することは出来ない。」 QAは更にこう返した。「それは 互換性 という別の問題だ。おれが言っているのは 機能性 に関するものだ。」 サポートエンジニアは尚も言う。「それにしたって、すべてのパターンをテストすることは出来ない。お前はテスターのくせに 全数テストは不可能 だという事実すら知らないのか？」 「わかった。同値分
従来とアジャイルで、品質メトリクスには本質的な違いがあるのではないか - ソフトウェアの品質を学びまくる
ソフトウェア開発における品質のメトリクスについて、新旧2冊の本を比べてみました。 1冊は、『初めて学ぶソフトウェアメトリクス』。 原著『Five Core Metrics: The Intelligence Behind Successful Software Management』（Lawrence H. Putnam、Ware Myers著）は、2003年に出版されています*1。 初めて学ぶソフトウエアメトリクス~プロジェクト見積もりのためのデータの導き方 作者:ローレンス・H・パトナム,ウエア・マイヤーズ日経BPAmazon もう1冊は、『アジャイルメトリクス』。 原著『Agile Metrics in Action: How to measure and improve team performance』（Christopher W. H. Davis著）は、2015年に出版されて
GitHub Flow with GitOpsの導入 - ZOZO TECH BLOG
はじめに こんにちは、計測プラットフォーム開発本部SREブロックの近藤です。普段はZOZOMATやZOZOGLASS、ZOZOFITなどの計測技術に関わるシステムの開発、運用に携わっています。 計測プラットフォーム開発本部では、複数のプロダクトを開発運用していますが、リリース作業はプロダクト単位で行っています。プロダクトによってローンチから数年経過し安定傾向のものもあれば、ローンチしたばかりで機能開発が盛んなものもある状態です。 複数のプロダクトを管理する上では当然の状況ですが、プロダクト単位でリリース作業手順が異なり、手順そのものにも課題がある状態でした。 本記事では、リリース作業で課題となっていた部分の紹介と、それぞれの課題に対する対応策についてご紹介します。 目次 はじめに 目次 現状 課題と対応方針 リリース作業の自動化 リリース作業の自動化をする上での必須条件の確認 自動化が必要
Remote Team Interactions Workbookまとめ
Remote Team Interactions Workbook: Using Team Topologies Patterns for Remote Working Remote Team Interactions Workbookは、 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計を書いたMatthew SkeltonとManuel Paisによるチームトポロジーをリモートワークに適応させることに焦点を当てた本です。 チームトポロジーについては、以下の訳者の方の資料がわかりやすいです。 2020年以降のCOVID-19の大流行は、多くの企業の働き方を変化させ、新たなリモートファーストの世界を到来させました。特にIT業界においては多くの企業がリモートワークに切り替えを行い、この変化は非可逆のものだと感じています。 しかし多くの企業はその変化に適応するのに苦労してい
社内でSREを広めるのに苦戦しているSREsにITIL 4がいい感じっぽいので共有したい
これは SREアドベントカレンダー 2022 - Qiita 2日目のエントリです。 昨日は みのるん☁️（@minorun365）さん の Let's see AWS W-A "Reliability Pillar" from SRE's view でした。 TL; DR SRE的な取り組みを社内で広めていくにあたり、自チームから外への普及に苦戦しているのであれば、ITIL 4が助けになるかもしれません "ITIL" のいいところは、歴史と権威があるところ、ガッツリ言語化されているところで、 "ITIL" の残念なところは、古臭い、柔軟性がなく堅苦しく固定的、実践的かどうかより手続き重視というイメージだった（個人的な印象） ITIL 4について知ったところ「"ITIL" の残念なところ」が払拭された Disclaimer ITIL 4の資格を取得したりはしていません わたし自身が特段IT
Kaigi on Rails 2022 「実践 Rails アソシエーションリファクタリング」で伝えきれなかったこと - ANDPAD Tech Blog
この記事は ANDPAD Advent Calendar 2022 の 8日目の記事です。 リアーキテクティングチームの白土 (@kei_s) です。 最近は、ボーアとアインシュタインに量子を読む - 量子物理学の原理をめぐってという本がとても面白く、ちまちま読んでいます*1。 去る2022年10月21,22日に開催された Kaigi on Rails 2022 で、実践 Rails アソシエーションリファクタリングというタイトルで発表しました。今回の記事では、この発表の補足をしようと思います。 Kaigi on Rails に参加して 本題の前に Kaigi on Rails に参加した感想を書かせてください。 私個人として、対外的に技術コミュニティで発表を行うのがとても久しぶりでした。 オンラインのカンファレンスで発表するのも初めてで緊張しましたが、リハーサル含めて運営チームのサポート
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
ソフトウェアエンジニアリングサバイバルガイド: 廃墟を直す、廃墟を出る、廃墟を壊す、あるいは廃墟に暮らす、廃墟に死す
マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ
事例から学ぶ実例マッピングのやり方 / Example Mapping
【発表資料中のURL】 ※複数ページで出てくる場合は、初出のページ数に掲載 ◆P3 ・Introducing Example Mapping ・【翻訳記事+α】受け入れ基準の設定時などに役立つプラクティス「実例マッピング(Example Mapping)」 ◆P6 ・Continuous Testing in DevOps… ◆P7 ・Shifting left & right in our continuous world ◆P11 ・Ｗモデルとは何か ◆P74 ・The BDD Books - Discovery ・The BDD Books - Discovery (Japanese Edition) ◆P75 ・Keep your scenarios BRIEF ・【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則 ◆P82 ・QAエンジニアが実例マッ
回復性の高いMicroservicesアーキテクチャを支える技術 - Mercari Engineering Blog
メルカリバックエンドエンジニアの@yagi5です。 Mercari Advent Calendar 2018の23日目を担当します。 モノリシックなシステムは、障害が発生するとシステムが全停止してしまうことが一般的です。 しかし、Microservicesアーキテクチャでは様々なテクニックを用いて、サービス全体が停止するような障害に対処することができます。 この記事では、Microservicesにおけるシステムの回復性を高めるための技術について書いていきます。 回復性とは、障害が起こらないことを意味しません。 高い回復性を備えたシステムは、障害が発生するということを前提に、システム全体のダウンを避け、データのロスが回避されるように設計されています。 Microservicesの世界では、システムは自律的に動作する複数のサブシステムによって構成されます。 ひとつのサービスに障害が発生しても
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022
フルスタックエンジニアから「フルサイクルエンジニア」へ。和田卓人氏による「組織に自動テストを根付かせる戦略」（その3）。ソフトウェア品質シンポジウム2022 9月22日と23日の2日間、一般財団法人日本科学技術連盟主催のイベント「ソフトウェア品質シンポジウム2022」がオンラインで開催され、その企画セッションとして行われた和田卓人氏による講演「組織に自動テストを書く文化を根付かせる戦略（2022秋版）が行われました。 講演で、企業の業績はソフトウェアの開発能力に左右されるようになってきていること、その開発能力を高める上で重要なのがコードの「テスト容易性」や「デプロイ独立性」であると和田氏は指摘。その上で、それを実現させるような「自動テストを書く文化」をどうすれば組織に根付かせることができるのか、講演の後半ではこの本質的な議論へと踏み込みます。 本記事は、2時間におよぶこの講演をダイジェスト
アーキテクチャの進化を支える適応度関数の活用 - 10X Product Blog
はじめに こんにちは！ モジュール開発部の yamakazu (@yamarkz) です。 あけましておめでとうございます。2023年もよろしくお願いします。 本記事が新年最初のプロダクトブログになるのですが、何を書こうかとても迷いました。笑 抱負的な何かが無難だと思いつつ、1年先のことまでは見通すことができない。10Xはドラスティックに事業や組織が変わるので、中長期な目線で1つのテーマを説くのは難しいなと。そう色々と考える中で、ちょうど足元で成果が出始めている具体の取り組みを紹介したい！というモチベーションが生まれてきました。 なので今回は、半年先までの将来的な抱負の意図を交えながら、直近の取り組みで手応えを感じ始めている、アーキテクチャ改善のプラクティスを紹介しようと思います。 具体的にはタイトルにもある”適応度関数”と呼ばれるプラクティスで、巷では概念としては認識されているものの、ま
変化に適応するソフトウェアアーキテクチャと組織構造への道程 - クラウドワークス エンジニアブログ
年の瀬ご多端の折、皆様におかれましては本年も大変お世話になりました。crowdworks.jpの開発をしているプロダクト開発部部長兼VPoEの@hihats です。 本記事はクラウドワークスAdvent Calendar 2022 24日目の記事です。 我々の組織ではこれまでも技術的負債解消に取り組んできていましたが、今期（10月）よりさらに人と時間をそこに集中しています。これまでこのブログでも紹介されてきたようにRuby on Railsのモノリスとなっているcrowdworks.jpにおいて、フロントエンドのVue.jsへの移行は今年に入ってから着々と進む中、バックエンドのほうは保守性の低下からどう脱却していくかが手付かずに近い状態でした。 この本丸を攻略するにあたって、闇雲にリファクタリングしていくぞ！では到底うまくいきそうにない。まず「何故やるのか、何をゴールとするのか」の意識あわ
Re: GraphQL Error、下から見るか？横から見るか？｜qsona
上記のトピックについてもう少し突っ込んだ議論をしたい。 背景: GraphQL におけるエラーの表現の手法Web API において、正常系以外の、例外(エラー)的な状況をレスポンスの情報に埋め込みたい場合、REST API では HTTP ステータスコードがよく用いられる。 一方、GraphQL API では、複数のリソースを同時に取得することが前提にあるので、「リソースXはエラーであるがリソースYは正常である」のように Partial Error の状況を表現したいことがままある。そのためステータスコードは不適であることが多い。 また、GraphQL の仕様として、返すデータのトップレベルに data と並列に errors を返すことが出来る。(手法aとする) { "errors": [ { "message": "forbidden", "path": ["x"] } ], "dat
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
freee会計からマイクロサービスを切り出すのに4年かかりました / 4 Years for Carving Out A Micro Service from freee Accounting.
組織の生産性を高める意思決定の構造と方法 / How to do make decision rapidly and effectively
監視せなあかんし、五大紙だけにオオカミってな🐺🐺🐺🐺🐺
「笑顔の合意」のテクニック - 噛み合わない会話と対立を克服するための、エモさを排した実践的なスキルと技法 -
The Stable Team - 機能する安定したチームをつくる - / The Stable Team
