2024年6月29日 Findy 開発生産性カンファレンス2024 Closing Keynote https://dev-productivity-con.findy-code.io/2024
![開発生産性の観点から考える自動テスト(2024/06版) / Automated Test Knowledge from Savanna 202406 Findy dev-prod-con edition](https://cdn-ak-scissors.b.st-hatena.com/image/square/4f5217e5033da62b74622a24df4e70976df33c96/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff110ebc4047245d0a95e264a5879dc56%2Fslide_0.jpg%3F30819588)
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先?(前編) ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90%以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
JJUG CCC 2024 Spring 複雑な業務ロジックに立ち向かうための実践技法 【初級編】 ①値の種類 ②範囲型 ③階段型 【中級編】 ④状態遷移 ⑤入出金履歴と残高 ⑥未来在庫 【上級編】 ⑦セット演算 ⑧割合と端数 ⑨決定表 ⑩経路探索
MP3ファイルをダウンロード 内容紹介 twadaさんをゲストに、テスト駆動開発(TDD)、TDDに関するよくある誤解などを語っていただいたエピソードです。 出演者 話したネタ 【翻訳】テスト駆動開発の定義 自動テストとテスト駆動開発、その全体像 保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 テスト駆動開発とは何だったのか? テスト駆動開発と同じレイヤの手法はある? テスト駆動開発と品質保証との関連は? TDD Boot Camp 2020 Online #1 基調講演/ライブコーディング テスト駆動開発に関するよくある誤解 アジャイル開発との類似点(みんな丸い) IPAの試験での誤解 今回のブログを書いた(翻訳した)ことによる懸念 サバンナ便り ~ソフトウェア開発の荒野を生き抜く~ 記事一覧 書籍レビュワー募集フォーム
このブログエントリでは、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発(TDD: Test-Driven Development)の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化(Semantic Diffusion)とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私(和田)はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
こんにちは、今回からコラムを書かせていただく和田(t_wada)と申します。 現代のソフトウェア開発の対象領域は、広く複雑で不確実なものになりました。この連載では、自動テスト(Automated Test)に関わるトピックを中心に、ソフトウェア開発の荒野を生き抜いていくためのプログラミングやソフトウェアエンジニアリングの考え方を書いていきたいと考えています。 初回のテーマは、学習や調査が目的のテストコードを書くテクニック「学習用テスト」(Learning Test)です。では、よろしくお願いします。 二兎を追わない プログラミングのコツに、「一度に2つ以上のものを相手にしないこと」があります。 未知の技術を使って問題を解決するコードを書こうとするとき、私たちは2つのものと同時に戦うことになります。未知の技術そのものと、その技術を使った問題解決の2つです。2つ以上のものを同時に取り扱おう
昨年NewsPicks さんに取り上げてもらって最近動画が公開されました。そこでもお話させてもらっていることなのですが、アメリカで働きはじめると日本人からすると「納期が無い」感覚が物凄く衝撃的だった。 最近、納期が無いことと生産性について頭の中で整理がついてきたのでシェアしておこうと思う。ちなみに、動画も含めて、私の発言は私の体験と意見であり、所属会社には全く関係が無いことを改めてお断りしておきます。 日米納期の感覚の違い アメリカで働いていると、日本人からすると納期がほとんどないという感じを受ける。もちろん納期があるものもあるが「本当に必要なもの」に限られる。例えば、大きなカンファレンスで何かの製品を発表するとかそんなのだと納期はもちろんある。そうでなれけばほとんど無いという感覚だ。私の所属会社だけではなく、北米の他の会社の人も同じような感覚らしいので文化によるものだと思う。 常に納期が
はじめに Event Sourcing を何となく理解するための記事です。 CRUD を用いた State Sourcing と比較しながら説明していきます。 State Sourcing vs Event Sourcing まず、State Sourcing と Event Soucing がそれぞれどのようなものかを挙げていきます。 State Sourcing 状態を中心に考える設計手法 現在の状態を永続化するのが一般的 CRUD(Create / Read / Update / Delete) を使って状態を変化させることが多い Event Sourcing アプリケーションの状態に対するすべての変化を一連のイベントで表現する設計手法 e.g.) 銀行の入出金履歴 イベントとは、過去に起こった出来事である An event is something that has happene
テストの学習へようこそ! コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 このコースでは、ウェブ用のテストの概要と探索について説明します。 このコースで学習する内容は次のとおりです。 テストの基礎 自動テストと手動テスト テストを実施する場所と方法 ベスト プラクティス 何をテストすべきか、誰に責任があるのか、目的そのものとしてではなく、目的を達成するために手段をテストすることを検討する方法など、テストの理念。 このコースには、学習に役立つ簡潔で実用的なサンプルコードも含まれています。 コースのスコープには、Node.js などの環境で実行される、フロントエンドの JavaScript とドキュメント モデル、バックエンドでのライブラリ テストが含まれます。テストの経験はありませんが、JavaScript の基礎知識と Node.js などに関する経験が必
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ~Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版(Gihyo Digital Publishing、Amazon Kindle)をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
ChatGPT がアプリケーションに最初に組み込まれたのは GitHub Copilot かもしれません。ここでは、ChatGPT そのものと、GitHub Copilot の双方を使って、アプリケーション開発を爆速させ、品質を少しでも向上させ。そして、Developer の皆さんのスキルを上げていくための入り口として、機能の概要を取り上げます。 内容: - Promptだけで出来るコト: 業務で使うために抑えておくべきポイント。データ・変換・抽出 - PromptのEngineeringへの適用: 企画から要件定義、設計、実装、デプロイも。 - 開発の生産性と品質をあげるための戦略: Prompt自身の現在の能力、チーム開発に向けて サンプルのPrompt: https://github.com/dahatake/ChatGPT-Prompt-Sample-Japanese/tree/m
はじめに プロジェクトマネジメントの仕事をする際に、お客さんに提案ベースの要件定義や設計をする機会が増えてきたので、私の経験に基づいて基本設計の具体的なプロセスや考え方について、整理していきます。 以前投稿した記事の続きですが、未読でもこの記事を理解できるようになっています。 この記事の対象者 基本設計の思考プロセスを学びたい人 ビジネスサイドの要件をエンジニアサイドのシステムに落とし込む流れを学びたい人 ビジネスサイドとエンジニアサイドのコミュニケーション能力を向上させたい人 具体的な事例を通して基本設計を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要です 自分の経験に基づいた内容を言語化しています プロジェクト規模は10名から20名のシステム開発を想定しています(大規模なプロジェクトを想定していません) システム開発の全体像 今回は下記
こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG(ツナグ)の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継
11/25から3/4の100日間かけてエリック・エヴァンスのドメイン駆動設計を完読しました! ソフトウェア開発の複雑さに立ち向かうための方法に「ドメイン駆動設計」があります。 エリック・エヴァンスのドメイン駆動設計(以降、エヴァンス本)は発売から20年・日本語訳発売から10年経っても読まれていて、ドメイン駆動設計の原著であり、多くのエンジニアが名著という一冊です。 その分厚さや内容が難しそうというイメージからずっと積んだままになっていている人も多いのではないでしょうか。 エリック・エヴァンスのドメイン駆動設計 作者:Eric Evans翔泳社Amazon 私もそんな一人で、ドメイン駆動設計をなんとなく知った風に過ごしていましたが、ドメイン駆動設計に関する勉強会への参加をきっかけにエヴァンス本と向き合い、知ったこと・学んだことを毎日1ページにまとめてツイートする活動を始めました。 100日間
はじめに 最近プロジェクトマネジメント関連の仕事をする機会が増え、(駆け出しですが)要件定義や設計関連の業務もするようになったので、私の経験を基に要件定義の具体的なプロセスや考え方について、まとめていきます。 この記事の対象者 要件定義の基本や思考プロセスを学びたい人 エンジニアからプロジェクトマネジメントをやりたい人 ビジネスサイドとエンジニアサイドのコミニュケーション能力を向上させたい人 具体的な事例を通して要件定義を学びたい人 前提 紹介する内容はあくまで一例であり、プロジェクトやチームの状況に応じて調整が必要 あくまで自分(駆け出しPM)の経験に基づいた内容を言語化しています プロジェクト規模は10名〜20名のWebアプリ開発を想定しています システム開発の全体像 一般的なシステム開発のプロジェクトは下記のフェーズで進んでいきます。 ※ コンサルの領域だと要件定義の前に企画構想とい
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く