アーキテクチャカンファレンス２０２４ 発表資料
コードレビューする時、自分がどんなことに気を付けているか (本当は気をつけたいか)みたいなポイントをまとめてみた。 コードレビューの目的 プロダクトの品質を担保するため 人は基本的にミスをするもの 1人で考えたものより、2人、3人集まって考えたものの方が良いことが多い 知識をチーム内でシェアするため チームでコードに関する知識を常に共有し続けることで、「この機能はAさんしか知らない」といった属人化問題を防ぐ Aさんが有休取った時に限って障害が起きたりするんですよね。分かります 他の人が書いたコードを読み、さらに分からないことは質問できる、素晴らしい学びの場だと捉える 責任をチーム内でシェアするため 何か問題が起きた時に関連するコードを書いた人間だけが責められるようなことは決してあってはならない レビュー時 (又はそのコードがデプロイされるまで)に問題に気づけなかったチーム全体の責任なので、
「すべてのライフサイクルモデルの祖は、ウォーターフォールモデルである」とは、スティーブ・マコネルの言葉だ1。また、ソフトウェア開発ライフサイクル（SDLC）に関するGitHubの文書では、広く採用された最初のSDLCがウォーターフォールモデルであるとされている2。 そこに、ウォーターフォールを学ぶことに対する価値がある。それは、スクラムを導入し、アジャイルソフトウェア開発を実践する組織にも言えることだろう。いや、そうであるからこそだ。どんなソフトウェア開発プロセスモデルであろうと、ウォーターフォールから派生したり、何らかの影響を受けていると考えられる。したがって、ウォーターフォールへの理解から、自分達がやっていることの本質を見いだせるのではないだろうか。 ウォーターフォールなんて誰でも知っていると思うかもしれないが、そうとも限らない。確かにウォーターフォール未経験のソフトウェア開発者は少な
この記事では、「アジャイルはウォーターフォール時代の何を反省するのか」「アジャイルで何が改善するのか」について、個人的な考えを説明します 極端なことを言っている部分はあるので、誤解している箇所や異論があれば、やさしくコメントで教えていただければ幸いです 言いたいこと 「ウォーターフォール＝諸悪の根源」というのは誤解で、問題は請負契約にある 請負契約で「顧客の真の要望が実現されない」のは当然、インセンティブ設計がおかしい 日本版のアジャイルソフトウェア開発宣言には「外注よりも内製を」と書くべき 競争に勝つためには内製化は進む(でも内製化はとても難しい) ベンダーへ「君はアジャイルをやるか迷える立場じゃないよ」 目次 用語 ウォーターフォールは本当に諸悪の根源か？ 「ウォーターフォール＝諸悪の根源」という誤解 問題の原因は請負契約 なぜ請負契約は失敗しやすいのか？ ベンダーは「システム開発だけ
TOPインタビューアジャイルの基本「動くものを速く届ける」を愚直に守る。それを実現するための開発プロセスの工夫とは【UPSIDER VPoP 森大祐】 アジャイルの基本「動くものを速く届ける」を愚直に守る。それを実現するための開発プロセスの工夫とは【UPSIDER VPoP 森大祐】 2024年11月6日 株式会社UPSIDER VPoP 森 大祐 株式会社UPSIDER VPoP。新卒で株式会社ワークスアプリケーションズに入社後、会計システムを中心として、大手企業のERP、業務システムの開発をリード。いくつかのキャリアを経て、PKSHAグループにて複数のAI SaaSを立ち上げ、それらのプロダクト企画統括を務める。2023年に入社した株式会社UPSIDERではVPoPを務める。 X Notion 法人向けクレジットカード「UPSIDER」をはじめとする金融サービスを提供する、株式会社UP
アジャイル型でアプリ開発を進めたところ、完成に至らなかったことについて、ベンダの不完全履行、プロジェクトマネジメント義務違反等が主張されたが、いずれも否定された事例。 事案の概要 eスポーツ事業の企画・運営等を行う原告（Ｘ）は、ゲーマー向けソーシャルアプリの開発を構想し、開発ベンダである被告（Ｙ）との間で、平成28年8月18日に、ゲームに参加する人をマッチングし、参加者同士がコミュニティを形成するソーシャルメディア機能を有するソフトウェア（本件ソフトウェア）を開発する契約（本件契約）を締結した。対価の額合計は、2450万円。その支払は1000万円、1000万円、450万円の3回にわけて行われることとされ、最後の450万円は、納品物を納入後に支払うこととなっていた。 本件契約の締結前には、Ｘは、検収に合格しなかったら、支払済みの代金を返金する条項を設けることを求めたが、Ｙは「返金を想定してお
NE株でJavaを書いている谷口(@taniguhey)です。 弊社では、EC一元管理システムである「ネクストエンジン」以外にもいくつかサービスを展開しており、2024年1月にβ版をリリースした「encer mall」（エンサーモール）という仕入れと卸のマーケットプレイスがあります。 8月1日にこれらの2つのサービスを連携するアプリ「encer mall連携 for 卸会員」をリリースしましたので、この記事は「encer mall連携 for 卸会員」（以下、連携アプリ）の開発の裏側を語る記事になります。 大きな泥団子から抜け出すための軽量DDD 軽量DDDを持ち込むにあたって気をつけたこと について書いていきます。 あえて軽量DDDを採用した話 ここでいう軽量DDDとは、ドメイン駆動設計における"戦術的設計"と呼ばれる部分のことです。 ドメイン駆動設計は"戦略的設計"の部分も併せて行うこ
1つのIssueが大きくなると1 Pull Requestで大量の差分が発生します。 そうなるとレビュワーに負担がかかり、コンフリクトの可能性も高まり、コードレビューを効率よく進めることができません。 このINVEST原則を守ることでチームはより効果的に作業を進め、柔軟に対応して開発を進めることができます。 Git Flow Git Flowは5種類(main, hotfix, release, develop, feature)のブランチを運用するブランチ戦略です。 2010年に提唱された有名なブランチ戦略です。 オンラインサービスのように継続的デリバリーするコードを想定して作られた戦略ではないです。 main ブランチ 常にリリースできる状態を保つ hotfix, develop へ切り出す このブランチへの直pushはNG hotfix ブランチ バグ修正など緊急時に対応するためのブ
なぜ依存を注入するのか DIの原理・原則とパターン 著者: Steven van Deursen, Mark Seemann 訳者: 須田智之 表紙には.NETやC#の文字はないのですが、前の版は"Dependency Injection in .NET"で.NETを前提した本のようでした。 ただ、はじめにで 本書では、.NETとC#を用いて、依存注入に関する用語や指針を包括的に紹介し、描写しているのですが、本書の価値が.NETの外の世界にも届くことを望んでいます。 とありました。 RustのDIでなにか活かせる教えを期待して、読んでみました。 第1部 依存注入 (Dependency Injection: DI) の役割第1章 依存注入 (Dependency Injection: DI) の基本: 依存注入とは何なのか? なぜ使うのか? どのように使うのか?まず、保守容易性(maint
皆さんは 「カバレッジが高ければ、ソースコードの品質が高い」という誤解 をしていませんか？少なくとも私は今までテストカバレッジ100%を追求していました。「C0/C1カバレッジ100%」がユニットテストの完了条件として含まれているプロジェクトも多いかと思います。 本稿では、「カバレッジが高ければ、ソースコードの品質が高い」という命題がなぜ誤っているのかを論理的に証明し、カバレッジを計測する本当の目的、そして推奨されるカバレッジの目標値について紹介したいと思います。 「カバレッジが高ければ、ソースコードの品質が高い」はなぜ間違っているのか？ カバレッジを計測する本当の目的 バグを潜在させてしまう恐怖のテストケース・アンチパターン カバレッジの目標値は100%にするべきではない カバレッジの目標値は何%にするべきなのか？ （テストカバレッジの種類については『ホワイトボックステストにおけるカバレ
オーバーエンジニアリングしてしまうという悩みがあって困っている、そのうち必要になるのではないかという気持ちになって無駄に抽象化して頑健にしてしまう。じゃあ素朴にやればいいのかというと、例えばDBスキーマみたいな要素は素朴になってはならないという難しさもある— Windymelt💀(めるくん)🚀❤️🔥 (@windymelt) 2024年9月12日 上のツイートを見かけたので、自分は何を心がけているか書いてみる。 結論 プロダクト方針的に起こりそうな未来を想像する 想像した未来が起こったとして、どのような実装になりうるかをざっくり考える その上で、その未来が起こったときに「詰む」ことがなさそうな一番シンプルな設計にする 前提: あらゆる未来の変更に強い抽象化はない 設計を考えていて複数案を出すと、結局トレードオフが存在することがわかる。案Aを選択すると、こっちの未来には対応しやすいが
はじめに こんにちは。コンシューマ事業部バックエンドエンジニアの高橋です。 今回は食事メニュー検索機能にOpenSearchを導入したことについて、お話しさせて頂こうと思います。 あすけんメニュー検索画面 なぜ導入しようと思ったのか あるデイリースクラムにて「『”水羊羹 とらや”』では検索できるのに、『”水ようかん とらや” 』では検索できない」という指摘がでてきました。確かにそれはユーザーにとって検索できない理由がわからず、ユーザビリティが低いと感じました。また、以前から「探したい食品がなかなか検索でヒットしない」という改善要望もありました。それらが今回の導入のきっかけです。 以前のメニュー検索 以前の検索ではデータベースに対しSQLの部分一致検索を行っていました。 OpenSearchで検索を行える状態にするためにはデータベースからOpenSearchへデータを同期する必要があり、また
個人的には、ゲームエンジンを書く仕事がなくなった これはデカいと思うんだよな ゲームエンジンって職人芸的なところがあった Unityとか、Unrealとか、物理エンジンもBox2DとかBulletとか、当然昔はなかったので、みんな自前で書いてたはず 例えば、スーパーマリオの物理挙動とか衝突判定は当たり前だけど自前で書いてたはず でも、今はブロック崩しさえUnityとかUnrealに含まれてる物理エンジンで剛体力学使って書けちゃう なんかそういうの無駄な計算力だよなと思うけど、まあ書けちゃう、動いちゃう たしか、チュートリアルかなんかにもあったはず 昔はゲーム作るときって、リードプログラマーが1人いて、他も数人で、少人数で職人芸的に作ってたわけだよ 全て自前でやらなければいけないから、簡易的なものを作るにしても、一応大学でやった物理を再度勉強したりするわけだ 剛体力学とか、流体力学とか、材料
こちらはAI・機械学習チームブログリレー8日目の記事です。前回のブログは高田さんの「AI・機械学習チームで学んだ開発技法で趣味の通知系ツールを量産した」でした！ www.m3tech.blog エムスリーエンジニアリンググループ AI・機械学習チームでソフトウェアエンジニアをしている中村(po3rin) です。 「レビュー依頼の優先度」といえば自分の作業とレビューのどちらを優先するかという意味での「優先度」の印象ですが、今回は複数あるレビュー依頼の中で、どのレビューから見ていくかという意味での「優先度」の話をします。 レビューの優先度を考えていく中で、「これは自動化したら面白いのではないか」と思い立ち、レビューの優先度をスコアリングするツールを作ったので、その経緯を簡単に紹介していきます。 レビューの優先度の再考 先に見るべきレビュー依頼の観点 急ぎ系のマージリクエスト メンションされてか
一定以上の規模のプロジェクトでは、開発プロセス設計において、テックリードなど有識者による横断的なテクニカルレビューをどうするかが課題になります。 そこでは、次の課題への対応が求められます。 レビューのレバレッジ性の確保。少数のレビューアの影響力を全体に発揮させる。 レビューのピンポイント性の確保。多数の業務作業の中で、有識者の力が求められる作業に集中してレビューを設ける。 このレビューのレバレッジ性・ピンポイント性の確保のためには、開発プロセス設計において、レビューのレバレッジポイント（少ないリソースで大きな影響を発揮できるポイント）を設け、そのレバレッジポイントにレビュー工程を確保するアプローチが有効になります。 レビューのレバレッジポイント レビューの代表的なレバレッジポイントに以下があります。有識者によるテクニカルレビューの力を引き出したい場合、これらに対しレビュー工程を設けるのが、
『手を動かしてわかるクリーンアーキテクチャ 』の第二章の冒頭に登場する話題に共感したので紹介。 従来の多層アーキテクチャでは、データベースを中心にアプリケーションの 開発が行なわれます。この場合、Web 層はドメイン層に依存し、ドメイン層は 永続化層、つまり、データベースに依存することになります。そうなると、す べてのものは永続化層上に構築されることになり、その結果、いくつかの要因 が絡まり合って、問題が起きやすくなります。 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 20p 手を動かしてわかるクリーンアーキテクチャ ヘキサゴナルアーキテクチャによるクリーンなアプリケーション開発 作者:Tom Hombergs,須田 智之インプレスAmazon 著者によれば、機能開発をデータベース中心に設計すると、ドメイン層と永続化層の密結合が
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは。サーバエンジニアのnsym-mです。普段はGoでバックエンドの開発などをしています。 最近テストに関する書籍や記事などを色々読み漁ったので、現時点での自分のテストについての考え方を備忘録として残しておきます。 今回の話はWebフロントエンドやiOS/Androidなどでも適用できる汎用的な考え方として記載していますが、ベースの文脈はバックエンド開発になりますのでそのつもりで読んでいただけますと幸いです なお、本記事では主にGoogle、『単体テストの考え方/使い方』、@t_wadaさんの発表されている考え方（いわゆる古典学派
読んでよかった book.mynavi.jp 評判通りよかった そっかーなるほどなぁ。面白いなぁ。と思うことがいろいろあった とはいえ、著者の主張全てに同意というわけではなく「著者はそう考えるんだな。自分は違う考えだな」と考えさせられる部分もいくつかあった 苦手な部分もあった 古典学派とロンドン学派に分けて話を展開しているのはあまり好きじゃないなと思いながら読んだ 定理やマトリクスに当てはめて話を展開する部分があって、いくつかは無理やりだったり話をややこしくしていたりするように自分は感じた。そういう部分は苦手だなぁと思いながら読んだ というのが全体の感想。内容はとてもよかったし、苦手な部分もそれはそれで考えさせられたので、読んでよかった。ってことでパラパラめくりながらメモを書いていこう あらためて意識したい2本 「第4章 良い単体テストを構成する4本の柱」の中の2本が、当たり前のことではあ
システムプラットフォームチームで SRE をしている id:masayoshi です。 この記事は、はてなの SRE が毎月交代で書いている SRE 連載の7月号です。先月は id:chaya2z さんの AWS ECS で実行するバッチ処理を Cluster Auto Scaling を使ってコスト最適化する でした。 今月は、社内で最近始めたSREへの研修についてお伝えします。 SREの研修 SREの研修は新卒入社のSREや、中途採用でインフラエンジニアやアプリケーションエンジニアからSREにジョブチェンジした方を対象に実施しています。 SREの研修は主に以下の2つに分かれます。 SREの原理原則やSLI/SLOに関する研修 インフラ構築、運用、CI/CD環境の構築に関する研修 基本的にはどちらも受けてもらうことになりますが、受講者の経験によってはどちらかだけになることもあります。 ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
