CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
保守性の高いソフトウェア開発のTips集
保守性の高いソフトウェアの開発に役立つ様々なTipsを書いた。 特定の言語にとらわれずあらゆる場面で役立つことを集めた。
午前中に読み始めたら午後には設計が上達してしまった！ - 『Tidy First?』を読んだ - Mitsuyuki.Shiiba
私の目標は、読者が午前中に本書を読み始めたら、午後には設計が上達していることだ。 本当にそのとおりだった。読んでる途中で既に自分の設計に対する考えが良い方向に変わってると感じた。とても良かった。おすすめです。 『Tidy First?』 をいただいて読んだ。昨日（2024年12月25日）発売。英語版が2023年11月28日発売だから、たった1年で日本語版が出たということだな。うれしい！はやい！ありがたい！ ソフトウェア設計に焦点を当てたシリーズの最初の1冊ということで、サブタイトルに「個人で実践する経験主義的ソフトウェア設計」とあるように、1人でできる種類のソフトウェア設計について書かれている。続刊ではチームについての話になる予定のようで、それも今から楽しみ。 2周読んだ なんとなく2周読もうと思ってそうした。 1周目は細かい部分は気にせずにざーっと1,2時間くらいで読んだ。全体的にどうい
はじめに 当記事を開いてくださりありがとうございます。私は表題の通り、私は一般にメガベンチャーと呼ばれる自社開発企業で機械学習エンジニアとして勤務しはじめてからわずか半年で、鬱を発症し退職することになったものです。この会社は待遇も良く、社風としても労働者思いのとても素晴らしい会社であったと私自身振り返って思います。 そんな会社に運よく入社することができた私ですが、わずか半年で「鬱状態」と心療内科から診断を受け休職し、会社制度により退職することになりました。「え？そんなに素晴らしい環境なのにメンタル弱すぎでは？」と思われる方もいらっしゃることでしょう。返す言葉が全くありません。おっしゃる通りです。 しかし同時に、「何故鬱になったの？」と思われる方もいらっしゃるのではないでしょうか。本記事ではこの点について鬱を発症した本人の目線から「どうしてそんなことが起きてしまったのか」という点について考察
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
2022-12-21 技術的負債の返済から改善する開発者体験 - Techmee vol.5 https://timeedev.connpass.com/event/268296/ 動画 https://youtu.be/tQ3BGgnvMwQ
株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
2021/04/10開催 Developer eXperience Day 2021 「クソコード動画『Userクラス』で考える技術的負債解消の観点」の解説資料です。 https://dxd2021.cto-a.org/program/time-table/b-3 クソコード動画はこちら …
このブログエントリでは、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent BeckがTDDの定義を改めて明確化した文章を、許可を得たうえで翻訳し、訳者の考察を沿えています。 きっかけ 2023年の年末、テスト駆動開発（TDD: Test-Driven Development）の考案者Kent Beckは、substackにTDDに関するポストを連投して論戦を繰り広げていました。TDDはその誕生から20年以上が経ち、その間に「意味の希薄化」が発生して議論が噛み合わなくなっていました。意味の希薄化（Semantic Diffusion）とは、新しく作り出された用語が広まる際に本来の意味や定義が弱まって伝わる現象です。 私（和田）はTDDと関わりの深いキャリアを歩んできました。Kent Beckの著書『テスト駆動開発』の翻訳者であることもあり、TDDの正
質とスピード（2022春版、質疑応答用資料付き） / Quality and Speed 2022 Spring Edition
質とスピード（2022春版、質疑応答用資料付き）
ソフトウェア設計についてtwada技術顧問と話してみた 〜 A Philosophy of Software Design をベースに 〜 - NTT docomo Business Engineers' Blog
はじめに スタンフォード大学の John Ousterhout 教授が執筆された “A Philosophy of Software Design”(以下 APoSD と略す) という書籍をご存じでしょうか？ 書籍のタイトルを直訳すると、「ソフトウェア設計の哲学」となります。書籍の内容はまさに、ソフトウェア設計について扱っています。 本書籍をベースに、「A Philosophy of Software Design を30分でざっと理解する」というお題で社内ランチ勉強会が開催されました。本記事執筆者である岩瀬(@iwashi86)が発表者であり、勉強会資料は以下のとおりです。 スライド P.4 に記載したとおり、本書籍は John Ousterhout 教授の意見が強く反映されており、ソフトウェアエンジニアであれば、議論を呼ぶ箇所があります。実際、勉強会の実況Slackでは、「これはどうな
設計を歪める認知バイアス - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、5日目の記事です。 これはなに？ ソフトウェア開発において、設計をないがしろにすると、低凝集密結合な構造に陥り、変更容易性が低下してしまいます。 設計スキルを高め、あるべき構造を設計する……これで解決できるに越したことはありません。 しかし、認知バイアスと呼ばれる心理効果により判断を誤り、良くない設計をしてしまうことが往々にしてあります。 本記事は、設計を歪めてしまう認知バイアスを理解し、設計判断の精度向上を促すことを目的と
変化に強いテーブル設計の勘所 / Table design that is resistant to changes
# DBリファクタリングの勘所と所感 - https://soudai.hatenablog.com/entry/2017/12/27/080000 # アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - https://agilejourney.uzab…
「設計」で大事なのはこれだった！半年間で40本レビューして分かった 5つのポイント - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
予防に勝る防御なし - 堅牢なコードを導く様々な設計のヒント / Growing Reliable Code PHPerKaigi 2022
PHPerKaigi 2022 2022/04/10 10:40〜 Track A レギュラートーク（40分） PHP はバージョンを追う毎に型宣言、例外、表明、列挙型などの機能が大幅に強化され、堅牢なコードを書くための機能が充実してきました。それらの機能はどう使うと効果的なのでしょうか。 …
Rustで作るテトリス風ゲーム入門
本書では落ち物パズルゲームとして有名なテトリス風ゲームの開発を通してRust言語を学ぶことを目的としています。 テトリスを知らない方でも問題なく読み進めることができます。 先ずは理解しやすいコードでシンプルな落ちものパズルゲームを実装し、後にリファクタリングや機能追加、自動化をしていく流れで構成されています。 テトリスにも様々な種類がありますが本書ではCUIでワールドルールを参考にして完成を目指します。
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。 コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1 4つの基準と優先順位のガイドライン 状態 > 結合 > 複雑性 > コード量 私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。 コードがよりステートレスになるなら、結合を増やすこともいとわない 結
（この話は最初Twitterに書こうと思ったけど、長くなるのでブログに書くことにしました） 僕はRSpecやMinitestでテストを書くのは得意ですが、常にテストファースト（TDD）で開発するとは限りません。 今業務でやってるタスクはこんなふうに進めてます。 雑に動くものを作る ↓ 見た目をきれいにする＆機能を作り込む ↓ テストを書く ↓ リファクタリングする この順番で開発する理由を以下に述べます。 雑に動くものを最初に作る理由 最初は見た目とか、異常系とか、細かい仕様とかを無視して、正常系が一通り動くものを作ります。 これはこれから作ろうとしているものの認識が合っているかどうかをPO（プロダクトオーナー）に確認するためです。 実際に動く画面を見せると「こんな感じでOK」とか「ここはこういうふうにしたい」というフィードバックをもらうことができます。 また、開発者としてもコードを書きな
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
目次 1.はじめに 2.VSCodeの拡張機能紹介 3.コーディングのポイント 4.よく使われる英単語一覧 5.エラーとの向き合い方 6.テストで動作確認 7.検索の極意 8.公式ドキュメントに慣れる 9.リファクタリングでさらに読みやすく 10.資料作成で気をつけること 11.Gitで管理 12.よく使うLinuxコマンド一覧 13.仕事の進め方 14.プログラム以外で意識するところ 15.初心者こそ読んで欲しい本 16.まとめ 1. はじめに プログラミングは現代のデジタル社会において重要なスキルです。 AIがコードを書いてくれる時代ですが、それでも人の手によるプログラミングはいまだに必要です。それはAIが完璧なコードを書いてくれるわけではないからです。 この記事では、プログラミングの世界に新たに足を踏み入れた皆さんを全力でサポートします。 VSCodeの便利な拡張機能から始まり、コー
こんにちは、リファクタリングが大好きなミノ駆動です。 これは、私が執筆した『良いコード/悪いコードで学ぶ設計入門 ―保守しやすい 成長し続けるコードの書き方』について紹介する記事です。 2022年4月30日発売です（ほぼ同日に電子書籍版も出ます）。 AmazonなどECサイトで、すでに多くの予約が入っており、ヨドバシ.comでは一時期予約終了になったほどです。おかげさまで初版部数が2倍になりました。 ■どんな本？皆さんはプログラミングでバグを埋め込みたいですか？ロジック修正が上手くいかず、ヒィヒィ言いながら長時間残業したいですか？イヤに決まってますよね。ところが現実には、 何度もバグを埋め込んでしまう ロジックを読み解くのに時間がかかる やっとロジック修正しても、全然違う箇所がバグ化してしまう ……ほとんど誰もが体験しているのではないでしょうか。 でも、こうした状況をなんとかしたいと思って
弊社では2019年3月ごろから「無人化システム」の駆逐を進めています。本記事ではこの取り組みを、組織マネジメントとエンジニアリングの側面から紹介します。 恐怖の無人化システム 「無人化システム」は社内の独自用語なので、まずは言葉の意味から説明します。 無人化とはなにか 無人化の前に属人化について触れておきましょう。weblio辞書から属人化について引用します[1]。 ある業務を特定の人が担当し、その人にしかやり方が分からない状態になることを意味する表現。 無人化は属人化の進化系です。無人化とは「属人化していた業務の担当者がいなくなってしまい、誰にもやり方が分からない状態になること」と定義できます。誰がどう見てもダメな状態ですね。 無人化システムとはなにか システム運用が属人化し、かつその運用者が退職するとシステムが無人化します。我々の会社ではこのようなシステムを『無人化システム』と呼んでい
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編）
技術的負債を抱えたレガシーコード。変なメソッド名と入り組んだロジック、リファクタリングするならどちらが先？（前編） ソフトウェアの品質をテーマに研究をしている名古屋大学 森崎研究室は、ソフトウェアの技術的負債をなんらかの形で数値化する手法の研究の一環として、コードの読みにくさの原因となる要因などを分析した研究結果を発表するイベントをオンラインで開催しました。 今回発表された研究では、技術的負債を抱えたレガシーコードのリファクタリングで取り除かれた問題の90％以上が、メソッド名と実際の関数の動作が一致していない、あるいは関数名とコメントが矛盾しているなどの「命名的問題」、もしくは複雑で読みにくい多数の条件分岐や深いネストなどを抱えた「構造的問題」のいずれかであるという先行研究があることを踏まえ、どちらを優先してリファクタリングすると保守性や可読性が高くなるかを調査しています。 具体的には、命
リファクタリングをする際にソースコードの設計からはじめてはいけない - MonotaRO Tech Blog
どうも、レコメンド商品のシステム開発をしている野川と申します。 私は、2021年にモノタロウに新卒入社し、2022年5月からレコメンド商品の開発に関わり始めました。 モノタロウのレコメンド商品は、下の図の①～④の流れでクライアントサイドで表示しています。大部分の処理はJavaScriptで構成しており、UIもそのHTML部分をjQuery(JavaScript)で作成しています。 図：レコメンド商品表の流れ 入社当時私は、ソフトウェアエンジニアとして、「可読性の低いコードは駆逐するべきだ」「読みやすいコードだけが正義である」「理解しやすいシステムだけが皆を幸せにする」と心の底から考えていました。加えて、「なぜ先輩たちは可読性の低いコードを放置して平気なのか？」と疑問を持つこともしばしばありました。 レコメンド商品周りのコードはまさに可読性の低いコードベースとなっていたため、当事者となった私
class: center, middle # map / filter などの<br>高階関数よりも<br>古典的な for文の方が<br>読みやすいと感じる<br>あなたへ BuriKaigi 2025 2025/02/01<br> @gakuzzzz --- class: left, top ## 自己紹介 * 中村 学/Manabu NAKAMURA * Twitter: [@gakuzzzz](https://twitter.com/gakuzzzz) * [Tech to Value Co.,Ltd.](https://www.t2v.jp/) CEO * [Alp, Inc.](https://thealp.co.jp/) Tech Lead --- class: left, top ## はじめに 昨今のメジャーなプログラミング言語では、 `map` や `filter`
コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。
Software Design連載 2021年9月号 「テストが無い」からの脱却 - MonotaRO Tech Blog
こんにちは、鈴木です。 「テストが無い」状態を脱却しました。 「いつの時代かよ！」と突っ込まれるかもしれませんが、モノタロウは創業から 20 年ほど EC をやっています。昨日書いたコードも、15 年前に書いたコードも、元気にビジネスを支えています。 本記事ではモノタロウの EC を支える API の話をします。「テストが無い」状態がスタートラインでした。そこから、CI を導入して、ローカル開発環境の整備して、テストコードを書いて、リリースマネジメントを導入しました。 目新しいことは書きません。長寿の大規模システムであっても、愚直に数年取り組むことで、「前進できる！」「変えられる！」という実例を書きます。 ※本記事の初出は、 Software Design2021年9月号「Pythonモダン化計画（第2回）」になります。第1回の記事は「Software Design連載 2021年8月号
人気のJavaScriptバンドルツール「webpack」の開発はなぜ終わり、後継として「Turbopack」の開発が始まったのか。開発者がその理由を語る
人気のJavaScriptバンドルツール「webpack」の開発はなぜ終わり、後継として「Turbopack」の開発が始まったのか。開発者がその理由を語る 複数のJavaScriptやTypeScriptの依存関係などを解決し、コードやフォント、画像などのリソースなどをまとめるバンドルツール（あるいはモジュールバンドラやビルドツールなどとも呼ばれます）は、多数のライブラリやコンポーネントなどを用いてチームで開発するWebアプリケーションの開発には欠かせないツールとなっています。 そのバンドルツールの代表がwebpackです。約4万人のITエンジニアによるアンケート結果が示された「State of JavaScript 2022」でもwebpackはGulpやViteなどを抑えて最も人気のあるバンドルツールとなっています。 参考：「State of JavaScript 2022」公開。利用
はじめに チーム開発でシェルスクリプト（特にBash Script)を書く際に守るべきルールをまとめます。 シェルスクリプトのコードレビューをする際等にお役立てください。 スクリプト名 -区切りの小文字英数字（いわゆるkebab-case）をつける。拡張子は.sh. これは特に理由があるわけではないので_区切りでもよいし、チーム内にzshやfish等の他Shell愛好家がいる場合は拡張子は.bashでも良い。どちらにせよチーム内では統一しておかないと混乱の元となる。 改行コード LFを使用する。CRLFだと動作しないので書く際に間違うことはないが、Windows上のgitのautocrlf設定によってはご丁寧にCRLFでチェックアウトされてしまう。 避けるためにはgit config --global core.autocrlf inputとするか、.gitattributesをレポジトリ
はじめに この記事は レガシーコード改善ガイド: 保守開発のためのリファクタリング を参考に手を動かしてみて、ある程度自分の中で体系的にまとまった知識のアウトプットです。 この記事で扱う内容 この記事で扱うのは主にレガシーコードで単体テストを書く際のハードルになりがちな 依存関係の排除 に関する手法を紹介します。 この記事を読んだ後に、 『この観点を持っておけば単体テストをスムーズに書いていけそう！』 『今までモック使ってたけど意外とモック使わなくても書けるね！』 となったらいいな、と思います。 ちなみに、今まであんまりテスト書いたことないよーて人は以下の記事など参考にして一度やってみてください。 もくじ テスト駆動不具合修正 or リファクタリング手順 なぜテストが書けないのか 依存関係を排除できればテストは書ける 依存関係を排除するためのカギになる考え方 書けない単体テストがなくなる２
実録レガシーコード改善 / Working with Legacy Code: the True Record
2024/01/15(月) 12:00 〜 13:00 t-wadaさんが後世に残したい、実録レガシーコード改善 https://findy.connpass.com/event/304101/ テストコードが無いコードを引き継いだところからはじまる、実際に2018年に行った受託開発案件のエ…
長年運用されてきたモノリシックアプリケーションをコンテナ化しようとするとどんな問題に遭遇するか？ / SRE NEXT 2022
2022年5月15日(日)に開催されたSRE NEXT 2022 Day 2の登壇資料です。 ▼SRE NEXT 2022オフィシャルサイト https://sre-next.dev/2022/ ▼発表の概要 https://sre-next.dev/2022/schedule#jp20
t_wadaさんと「単体テストの使い方/考え方」の疑問点についてディスカッションしました - DeNA Testing Blog
こんにちは、SWETグループの田熊です。 現在SWETグループでは書籍「単体テストの使い方/考え方」の輪読会を実施しています。 輪読会ではメンバー同士で活発に意見が交わされていますが、著者の主張に疑問を感じる箇所もあり、一度グループ外の方とも意見を交換したいと考えていました。 そこで、t_wadaさんをお招きし「単体テストの使い方/考え方」についてディスカッションする機会を設けました。 本記事では、SWETメンバーとt_wadaさんとのやりとりを紹介したいと思います。 ディスカッションの流れ ディスカッションは事前にSWETグループのメンバーが書籍を読んで疑問に感じたテーマを挙げてもらい、t_wadaさんの意見を聞くという流れで行いました。 今回は次のテーマについて話をしました。 「退行に対する保護」があるテストとはなにか 「リファクタリングへの耐性」のトレードオフはあるのか 統合テストの
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より 今回、Software Design 2022年3月号 第2特集「そろそろはじめるテスト駆動開発 JavaScriptでテストファーストに挑戦」の第1章「保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像」を本サイトに掲載します。第2章以降については、本誌『Software Design 2022年3月号』電子版（Gihyo Digital Publishing、Amazon Kindle）をご購読いただければ幸いです。 第1章では、混同されることの多い自動テスト関係の概念を、自動テスト、テストファースト、テスト駆動開発の3つの段階に分け、それぞれの効果や注意点を説明します。ソフ
本記事は、Atit氏による「34 JavaScript Optimization Techniques to Know in 2021」（2021年1月3日公開）の和訳を、著者の許可を得て掲載しているものです。 2021年に知っておきたいJavaScript最適化技術34選 最新の省略テクニック、コツ、秘訣で、JavaScriptコードを最適化する。 開発者の生活というのは常に新しいことを学ぶことで、その変化についていくことは決して難しいことではありません。私は、フロントエンド開発者として知っておく必要のある省略形や機能など、JavaScriptのすべてのベストプラクティスを紹介して、2021年の生活をより快適にしたいと考えています。 JavaScript開発に長く携わっている人でも、コードを追加しなくても問題解決できるような最新機能を知らないこともあるかもしれません。ここで紹介するものは
リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～で発表した資料です。 【発表資料中のURL】 ※複数…
この記事は クラウドワークスアドベントカレンダー2020 8日目の記事です。 概要 こんにちは、クソコードを爆殺リファクタリングするのが大好きなミノ駆動です。 今回は単一責任原則の話です。 単一責任原則はSOLID原則のひとつとして有名で、2020年のオブジェクト指向カンファレンスのアンケートでも、SOLID原則の中で最も人気がありました。 皆さんは単一責任原則を遵守した設計をしていますか。 どんな構造が単一責任設計で、一方どんな構造が単一責任でない設計か、明確に意識していますか。説明できますでしょうか。 ところで「単一責任原則とはなんぞや」について、少なくとも私の観測範囲では、概念的な話にとどまっているものが多く、コードレベルで具体的に説明しているものは少ないように感じます。 そうした状況からか、単一責任原則の解釈が人によって違っていたりしているように感じます。 本記事は、今一度単一責任
こんにちは、開発チームのアーキテクトをやっている竹野（@Altech）です。先日、新人研修でソフトウェアの設計について話す機会がありました。 ソフトウェアの設計というのは関連する領域が広いため、どうしても断片的な理解になりがちです。そこで、早い段階で全体像を感じてもらうために、ソフトウェア設計の Why と How と What を1時間でまとめて話すというちょっと意欲的なコンセプトで研修を行いました。今回は、その内容を記事にしました。 この研修のねらいはじめにソフトウェアの設計について書かれた情報は世の中に多いですが、その情報の多くは How であり、それだけを読んで適切に使うことが難しいと感じています。その直接的な理由は、How に対しての What、How / What に対しての Why が語られることが少ないからです。 ただ、How だけを知っていると、それは本当に問題を解決して
恥の多い生涯を送って来ました。 システムを開発していると、本当に多くの恥が生まれます。たとえば、こんな恥です。 テーブルの名前を付けミスったりは日常茶飯事。私が付けた変な名前が、自社の営業どころか他社のユーザーにまで浸透してたりもする。例えば、唐突に商品マスタに出てくる「グルーピングタグ」というカラムとか。（まじで意味不明） いま商品マスタと呼ばれているマスタの物理名が「kiosk_pricings」とか。日本語でおｋ。kiosk_pricings.grouping_tagってなんだよ。 「pricing」テーブルにはpriceカラムがあるが、全てのレコードで0になっていて、システムでは一切使っていないとか。（そのうち消したい） システムで使われている"正解"はkiosk_pricings.priceでした〜。 親子関係を間違えた事もある。チケットと決済の親子関係を入れ替えたりもした。 ま
テストの自動化とテスト駆動開発
組織としてテスト自動化に取り組むべき理由と、手段としてのテスト駆動開発を紹介する講演資料です。以下のような内容です。 ねらい： ・主に顧客向けの業務システム(B2B)を開発している、 ・プロジェクトベース、ウォーターフォールプロセスが主流の開発現場や運用保守の現場にいる、 ・マネージャーのか…
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
![[2025年10月3日] Sora2は多分何かを壊してしまった (週刊AI)](https://cdn-ak-scissors.b.st-hatena.com/image/square/6ac11c8f05a1f1a0367828587ba7333e645b7dc1/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--Iu-XyGDa--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255B2025%2525E5%2525B9%2525B410%2525E6%25259C%2525883%2525E6%252597%2525A5%25255D%252520Sora2%2525E3%252581%2525AF%2525E5%2525A4%25259A%2525E5%252588%252586%2525E4%2525BD%252595%2525E3%252581%25258B%2525E3%252582%252592%2525E5%2525A3%25258A%2525E3%252581%252597%2525E3%252581%2525A6%2525E3%252581%252597%2525E3%252581%2525BE%2525E3%252581%2525A3%2525E3%252581%25259F%252520%252528%2525E9%252580%2525B1%2525E5%252588%25258AAI%252529%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_34%3AKai%252Cx_220%252Cy_108%2Fbo_3px_solid_rgb%3Ad6e3ed%252Cg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzE0MTRiZmIwZWQuanBlZw%3D%3D%252Cr_20%252Cw_90%252Cx_92%252Cy_102%2Fco_rgb%3A6e7b85%252Cg_south_west%252Cl_text%3Anotosansjp-medium.otf_30%3ACareNet%252520Engineers%252Cx_220%252Cy_160%2Fbo_4px_solid_white%252Cg_south_west%252Ch_50%252Cl_fetch%3AaHR0cHM6Ly9saDMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL2EvQUVkRlRwN0luX0J2ajYyMjVsbTRVWXczSjhQODgwRTdhSFF6YXZqcmJHN1E9czk2LWM%3D%252Cr_max%252Cw_50%252Cx_139%252Cy_84%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png%3F_a%3DBACAGSGT)
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
コードレビューの目的と考え方 - osa_k’s diary
自社開発メガベンチャーをわずか半年で鬱退職した雑魚エンジニアの話｜Janne
良いコードとは何か - エンジニア新卒研修 スライド公開
クソコード動画「Userクラス」で考える技術的負債解消の観点
【翻訳】テスト駆動開発の定義 - t-wadaのブログ
状態、結合、複雑性、コード量の順に最適化する - valid,invalid
雑に作って、それから作り込んで、最後にテストを書く「テストラスト」開発 - give IT a try
pixivのブックマークに関する負荷対策をしました - pixiv inside
【11万文字越え】プログラミング初心者に贈る即戦力ガイド - Qiita
『良いコード/悪いコードで学ぶ設計入門 』を出版します｜ミノ駆動
「無人化システム」を駆逐する組織マネジメントとエンジニアリング
map / filter などの高階関数よりも古典的な for文の方が読みやすいと感じるあなたへ
何年も前に書かれたソースコードを読むときの頭の中 - Mitsuyuki.Shiiba
Bash Scriptの作法 - Qiita
たった２つのステップを意識するだけで書けない単体テストがほぼなくなる - Qiita
保守しやすく変化に強いソフトウェアを支える柱 自動テストとテスト駆動開発、その全体像 ～Software Design 2022年3月号「そろそろはじめるテスト駆動開発」より | gihyo.jp
2021年に知っておきたいJavaScript最適化技術34選 - Qiita
テストコードにはテストの意図を込めよう #vstat
単一責任原則で無責任な多目的クラスを爆殺する - Qiita
ソフトウェア設計の Why & What & How | Wantedly Engineer Blog
どうやって技術的負債の雪だるまを生み出し、それを返済してきたか - 5年半越しの設計論
note.com/wasemenblog
www.saikyo-jump.com
gourmet.watch.impress.co.jp
news.denfaminicogamer.jp
www.jimin.jp
www.facebook.com