【翻訳】テスト駆動開発の定義 - t-wadaのブログ
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
4年後までにソフトウェアテストの70％を生成AIが作り、コードの品質は向上するようになるとの予測、IDC
4年後までにソフトウェアテストの70％を生成AIが作り、コードの品質は向上するようになるとの予測、IDC 調査会社のIDCは、4年後の2028年までに生成AIベースのツールがソフトウェアテストの70%を作成できるようになり、手動テストの必要性が減り、テストのカバレッジが向上することで、ソフトウェアのユーザービリティとコードの品質向上が実現するとの予測を発表しました。 同社によると、生成AIによるテストスクリプトの生成や管理などを含むテスト自動化は日本を除くアジア太平洋地域で特に人気が高まっており、開発者とDevOpsの専門家がこれらの技術を活用することで、ソフトウェア開発全体の自動化をより推進していくことになるとのことです。 また生成AIはレガシーアプリケーションのコードに対するリファクタリングも促進するとしており、2027年までにリファクタリングに関わるコードの変換や開発タスクの50％が
Rust製の高速なwebpack互換バンドラ「Rspack」登場。現時点で5倍から10倍の性能向上
TikTokの開発元で知られるByteDanceのWebインフラチームは、Rust製の高速なwebpack互換バンドラ「Rspack」（発音はɑrespæk、アールエスパックもしくはアールエスペックのように聞こえます）をオープンソースで公開しました。 アイコンは雷光のように素早いカニで、コンパイルの高速性を表しているとのことです。 Hello world! We are from ByteDance. https://t.co/8d7t2qga7o — Rspack (@rspack_dev) March 10, 2023 バンドラとは、複数のJavaScriptやTypeScriptの依存関係などを解決し、コードやフォント、画像などのリソースなどをまとめるバンドルツール（あるいはモジュールバンドラやビルドツールなどとも呼ばれます）です。 多数のライブラリやコンポーネントなどを用いてチーム
単体テストの考え方/使い方|マイナビブックス
単体テストの考え方/使い方 プロジェクトの持続可能な成長を実現するための戦略 著作者名：Vladimir Khorikov 編集者名：須田智之 書籍：4,488円 電子版：4,488円 B5変：416ページ ISBN：978-4-8399-8172-3 発売日：2022年12月28日 内容紹介 質の高いテストを行い、ソフトウェアに価値をもたらそう！ 単体（unit）テストの原則・実践とそのパターン ― プロジェクトの持続可能な成長を実現するための戦略について解説。 優れたテストを実践すれば、ソフトウェアの品質改善とプロジェクトの成長に役立ちます。逆に間違ったテストを行えば、コードを壊し、バグを増やし、時間とコストだけが増えていきます。生産性とソフトウェアの品質を高めるため、優れた"単体テスト"の方法を学ぶことは、多くの開発者とソフトウェア・プロジェクトのために必須といえるでしょう。 本書“
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
人気のJavaScriptバンドルツール「webpack」の開発はなぜ終わり、後継として「Turbopack」の開発が始まったのか。開発者がその理由を語る
人気のJavaScriptバンドルツール「webpack」の開発はなぜ終わり、後継として「Turbopack」の開発が始まったのか。開発者がその理由を語る 複数のJavaScriptやTypeScriptの依存関係などを解決し、コードやフォント、画像などのリソースなどをまとめるバンドルツール（あるいはモジュールバンドラやビルドツールなどとも呼ばれます）は、多数のライブラリやコンポーネントなどを用いてチームで開発するWebアプリケーションの開発には欠かせないツールとなっています。 そのバンドルツールの代表がwebpackです。約4万人のITエンジニアによるアンケート結果が示された「State of JavaScript 2022」でもwebpackはGulpやViteなどを抑えて最も人気のあるバンドルツールとなっています。 参考：「State of JavaScript 2022」公開。利用
Backlogのフロントエンドをもっと楽しく開発したい！Reactでリプレイスしている話 | 株式会社ヌーラボ(Nulab inc.)
こんにちは。Backlog開発チームの砂川です。 現在BacklogではフロントエンドのReact/TypeScriptへのリプレイスを進めています。既に一部の画面（課題検索画面、課題詳細画面）がリプレイスされ、本番環境で稼働しています。 この記事では、Reactへのリプレイスによって素早い機能開発ができる状態を実現しようとしていること、リプレイスしたコードを安心して触れる様にするために導入したものをご紹介します。 本題の前に: 表示速度も大幅に高速化 本題の前に今回のリプレイスによる副産物を紹介しておきます。今回のリプレイスは機能開発を楽にすることが第一目的ですが、リプレイスの過程で一部SPA化もしているため、ユーザーの体験も向上させることができました。 リプレイス前(900ms程度) React版（50ms程度） 課題検索画面と課題詳細画面をSPA化したことによって、この二画面間では、
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT Communications Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
kintone のテストを JUnit 5 に移行した話 - Cybozu Inside Out | サイボウズエンジニアのブログ
こんにちは、kintone 開発チームの @hikoma です。kintone のテストを JUnit 4 から JUnit 5 に移行した話を公開したいと思います。 背景 2017 年に JUnit 5 がリリースされてから約 4 年半、みなさんは既に JUnit 5 を利用していることかと思います。 kintone では JUnit 5 への移行がなかなか進みませんでした。テストのボリュームがそれなりにあり（Java の単体テストが約 6500、REST API のテストが約 4000、Selenium のテストが約 3000）、E2E テストで並列実行やリトライのために JUnit 4 の仕組みを利用していたので、目に見える問題が起きていない状況では優先度も上がりませんでした。 しかし、このような状況ではテストの改善に着手しにくく、持続的な開発のリスクも感じていたため、何度目かの移行
[Rust] モジュールのベストプラクティス
Rust のモジュールシステムは私の知る中でもトップクラスによくできた仕組みだと思います。特にリファクタリングによってモジュールを再構成するときのやりやすさは他の言語では経験できないものです。例えばそれなりの規模の Python プロジェクトを回帰バグを導入せずにモジュール構造のリファクタリングするのは不可能に近いですが、 Rust ではそのような不安を覚えたためしがありません。 Rust のモジュールシステムがどういうものかは、 The book にも書かれていますし、すでに大量のガイドが書かれていると思います。しかし、どのように使うべきかについては意外なほど情報が少なく感じます。 ベストプラクティスというのもおこがましいですが、数年使ってきて Rust のモジュールシステムを使う上でスムーズに感じる方法をまとめておきたいと思います。 Rust のモジュールシステム 本稿の主題はモジュー
![[Rust] モジュールのベストプラクティス](https://cdn-ak-scissors.b.st-hatena.com/image/square/891eeb61cb537942f816adc8c8b2ea1079e47749/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--9-GnInIk--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BRust%25255D%252520%2525E3%252583%2525A2%2525E3%252582%2525B8%2525E3%252583%2525A5%2525E3%252583%2525BC%2525E3%252583%2525AB%2525E3%252581%2525AE%2525E3%252583%252599%2525E3%252582%2525B9%2525E3%252583%252588%2525E3%252583%252597%2525E3%252583%2525A9%2525E3%252582%2525AF%2525E3%252583%252586%2525E3%252582%2525A3%2525E3%252582%2525B9%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3Amsakuta%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EvQUFUWEFKeG5tZ0ZYQlJsZjJpZVh1QWlwOG9LaFdpT2FSczg2dXRzWlcwN3o9czk2LWM%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 本講演では PHP 8.1 をベースにして、誤りを想定してチェックするのではなく、そもそも誤りにくい設計とはどのようなものか、つまり「予防」の観点を軸足に、堅牢なコードを導くための様々な設計のヒントをご紹介します。 Agenda - 型宣言 - 列挙型 - ドメインモデリング - 不変性と等価性 - 完全性 - レイヤーと責務
Linuxカーネルの"依存関係地獄"解消目指す「Fast Kernel Headers」
Steven J. Vaughan-Nichols （Special to ZDNET.com） 翻訳校正： 村上雅章 野崎裕子 2022-01-12 08:30 数十年にわたって修正が加えられ、乱雑さという垢が蓄積されたコードをきれいにするというのは気の弱い人がやる作業ではない。しかし、Linuxのカーネル開発における第一人者であるIngo Molnar氏は自らの持てる力を最大限に傾け、オープンソースのLinuxカーネルに秩序を取り戻そうとしている。 Linuxのソースコードは2020年に2780万行に達した。それ以降もその規模は増大する一方だ。Linuxは、30年が経過している他のソフトウェアプロジェクトと同様に、その長い歴史の中でソースコード中にかなりの量の垢をため込んでいる。Linuxカーネルの上級開発者であるMolnar氏はこの問題を根本的なレベルで解決するための初撃となる数カ月
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
設計を歪める認知バイアス - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的とします。 この記事のゴール 人間の判断を歪めてしまう心理効果「認知バイアス」の存在を知ること。 ソフトウェア設計も、認知バイアスの悪影響を受けてしまうこと。 認知バイアスに振り回されない設計アプローチを身につけること。 認知バイアスとは 先入観や思い込み、偏
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
目についたところをやるか、ロードマップに沿ってやるか - hitode909の日記
ソフトウェアを作っていて、ここの開発体験が悪いのでちょっとリファクタリングしたい、と思ったときにどうするか。 とにかく直してしまう 今後のリファクタリング予定、みたいなロードマップと見比べて、ロードマップに合致してたら直す すぐには手を付けず、今後のリファクタリング予定、みたいなロードマップを粛々と進める とにかく見かけたら完膚なきまでに直す、という人もいると思って、カッとなって直してきました…みたいな言説はよく見る。 一方で、目についた順に手を付けていてもできることには限界があって、全員の意識を統一して、こういう順序でやればうまくいくに違いない、みたいにロードマップを作ったりして段取りをして、同じ方向に向かっていけると、より大きいことができたり、より良い状態になれたりする、ということもあるだろうと思う。 というときに、どれくらいのバランスで、ちょっと直すのか、直さないのか、段取りを定めて
凄腕エンジニアも負ける学生の強さ。『ISUCON11』では勝ち筋をどう見いだす？ - エンジニアtype | 転職type
2021.08.19 スキル ISUCONさくらインターネットLINE パフォーマンスチューニングの成果を競うコンテストとして、エンジニア界隈ですっかり定着した感のある『ISUCON』。今年も8月21日に予選、9月18日に本選の日程でオンライン開催される。 CTOレベルも含めて腕に覚えのある多くの現役エンジニアが参加する同イベントだが、10回目のメモリアル大会となった昨年は、上位3位を学生が独占する衝撃の結果に。ここ数年の学生の勢いは凄まじいものになっている。強さの理由は「社会人と比べて対策に多くの時間を割けるから」というのが通説だが、本当にそれだけなのだろうか。 今年は大会史上初めて出題も学生が行う。『ISUCON』はこのまま若い力に蹂躙されてしまうのだろうか。主催するLINEのDeveloper Relations室 櫛井優介さん、さらに出題者、参加者の両方の立場から関わり続け、『IS
シェルスクリプト リファクタリング ～遅いシェルスクリプトが供養されてたので蘇生して256倍に高速化させました～ - Qiita
はじめに ことの始まりは「シェルスクリプトでツールを作ったけど速度が遅くて使い物にならなかったので供養」というツイートを見たからです。コードを見てみると、実例をあまり見ないシェルスクリプトのリファクタリング例として丁度良い内容と分量だったため記事にいたしました。記事を書くにあたりコードの利用を快く承諾していただいた @Hayao0819 様にはこの場を借りて御礼を申し上げます。 内容は章立てで構成しており、序章で事前調査をし、第一章で一般的なリファクタリング、第二章でパフォーマンスを重視したリファクタリング、終章で少し余談をして締めくくっています。最初はパイプは並列処理されるから速くなるというのは神話（そうとは限らない）についても書いていたのですが流石に長いので分けました。それでも書きたいことを色々書いていたらめちゃくちゃ長くなってしまいましたので読み物として私がどんなことを考えながらリフ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
sudoとsuがRustで書き直される。メモリ安全性向上へ
GitHub - terryyin/lizard: A simple code complexity analyser without caring about the C/C++ header files or Java imports, supports most of the popular languages.
