コードレビューが激変している - RAKUS Developers Blog | ラクス エンジニアブログ
こんにちは、フロントエンド推進課の水野です。 普段はWebフロントエンド領域を中心に、商材開発や技術支援、開発改善に携わっています。 自動化・標準化、開発プロセスの変遷に関心があり、作るものだけではなくその過程や運用設計を意識して取り組んでいます。 note.com 最近、自分の中でコードレビューのやり方が変わったなと感じています。 GitHub CopilotやClaude Codeのようなツールが当たり前になり、構文エラーやコーディング規約のチェック、命名規則の統一のような作業はほぼ自動化できてしまいます。 成果物の出てくるスピードと規模感も桁違いで、レビューだけで1日が溶ける日もたまにあります。 その中で、改めて「自分は何をレビューすればいいんだろう」「コード以外に見るべきものはなんだろう」と考えることが増えました。 個人的にコードレビューや開発現場に関する話が好きで、ブームが再燃し
2025_7_25_吉祥寺_設計ナイト_ADR運用におけるデータ利活用の考え方.pptx
なぜそのDDDは効果が薄いのか？名ばかりDX案件での経験を踏まえて培った他の思考を交えた現代風？のDDD
NULLが支えるSQLの安定性──静かに失敗を受け止める仕組み｜コグラフ株式会社 データアナリティクス事業部
こんにちは。コグラフ株式会社データアナリティクス事業部の塩見です。 SQLの世界でNULLはしばしば悪者にされがちな存在です。 「比較できなくてややこしい」 「意図しない結果になる」 「できれば使いたくない」 確かに、NULLが原因で思わぬ挙動に悩まされた経験のある人は多いでしょう。ですが、今回はあえてこのNULLを全力でほめてみたいと思います。なぜなら、NULLは失敗を安全に伝えるための、とてもよくできた仕組みだからです。 エラーにならない失敗──関数は黙ってNULLを返すたとえば、次のようなSQLを考えてみてください。 SELECT name, LENGTH(nickname) AS nick_len FROM users;nicknameがNULLだった場合、LENGTH(nickname)はどうなるでしょうか？ クラッシュする？ エラーになる？ 0が返る？ → 正解は、NULLが返
「YouTubeを作れ」って言われたら、どうする？
「YouTubeを作れ」って言われたら、どうする？Youtubeって実は24億人以上が使ってるらしいんだけど、そのユーザー数を抱えるアプリを設計しなさいって言われたら… どうする？リクエストのさばき方とか、低レイテンシーの実現とか、めちゃくちゃ考えることあるよね… そんな“誰もが使うレベルのアプリ”を、どう設計するか その考え方が、ホワイトボード形式で丁寧に解説されてる神動画がこれ👇 ・負荷分散どうする？ ・CDNっていつ使う？ ・DB設計どうなってる？ みたいな内容が、視覚的にめっちゃ分かりやすく学べる！
フロントエンドの段階的モダナイズ、のための自走設計 (株式会社スタディスト様)
株式会社スタディスト様の依頼で、フロントエンド傭兵として、Rails 内の巨大SPA の段階的なモダナイズの提案を行った事例紹介です。 いつもはパフォーマンス視点で仕事にかかるのですが、今回はマクロな設計視点でソースコードを読んでいきます。一旦は中期ゴールを提案しつつ、その作業の必要性を通して、なぜその変更が必要なのかという解説をしていきました。 コスパが良い部分からやりたいですね。でもコスパ感覚は人それぞれです。あくまでフロントエンド専門家の自分が優先度付けるなら、という観点でやっていきます。 今回の仕事にあたっていくつかの技術的な課題を取り上げますが、それはスタディスト様に問題があるという話ではありません。むしろ問題を修正しようという意思が強く、実際1ヶ月の期間中にいくつかの修正をマージすることもできています。 以下、敬称略。注意点として、今回の内容は中の人達が見返すための記述が多いの
その汚いコード、いつどこで整頓するの？"Tidy First?"を読んで解決した話 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Tidy First? Kent Beckさんの本「Tidy First? -個人で実践する経験主義的ソフトウェア設計」の日本語訳版が出たので読んで色々と感想を交えながら整理してみました。 翻訳版が2024/12/25に販売された いつどこでコードを改善・整頓すれば良いのかを記述した本 3部作の1作目で、本作は"個人"に焦点を当てている 内容整理目的でいくつか気になったポイントを抜粋しつつ、自分で咀嚼し言い換えたり、感想・意見を交えて整理しています。きちん正しく理解するためには本書をぜひ一読することをオススメします。 Tidy Firs
2024年末にデザインパターンについて考える - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Futureアドベントカレンダーの3日目のエントリーです。昨日は@yamat2667さんのFlutterの記事でした。 デザインパターンというと、普段のプログラミングから一歩踏み込んで設計力を上げたい人が履修すべきコンテンツのように思われているようなツイートなりを見かけます。オブジェクト指向言語全般に使える知識だ、とか、開発者同士のコミュニケーションに使えるぞ、とか、コードの質が上がるぞ、とか。 一方で、パターンを詰め込もうとすると逆にコード量が増えて、パターン由来の変なクラス名が増えたりして、設計が歪むぞ、というのも当初から言われてき
「良いコードとは何か」で消耗するのはもうやめよう - DMM Developers Blog
これはなに？ こんにちは、DMM.comのミノ駆動です。 プラットフォーム開発本部 Developer Productivity Group 横断チームにて、 プラットフォームの設計品質向上に取り組んでいます。 さて、ネット上ではソフトウェア開発における「良いコードとは何か」をめぐって、 いろんな意見が交錯したり、 ときには激論を呼んだりします。 収拾がつかないこともしばしばです。 この記事は、良いコードを考えるうえでの要素を整理し、 建設的な議論を助けることを目的とします。 これはなに？ この記事の理解目標 良いコードをめぐる議論 議論1: 何をもって良いコードなのか 議論2: 良いコードはどうやったら書けるのか 議論3: 「綺麗なコード（良いコード） vs 動くコード」問題 議論改善のために提案します 提案1: ソフトウェア品質特性の観点でコードの良し悪しを判断しよう 提案2: 原理原
アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その１【背景編】：ULIDに移行する話 - OLTA TECH BLOG
◇ アノキミモノガタリその壱 はじめに ULIDを採用した背景 整数型自動採番に関する思惑 ULID到来のきっかけ まとめ IDシリーズ記事の一覧 ◇ アノキミモノガタリその壱 アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。 君の名は、01FZG96YPZK4SANAG1ZM5T2K9Z、忘れないその目。 令和4年4月1日、ミッドナイトの零時23分、55秒の999ミリ秒、 キミと、出会えた。 君の名は、01FZG96YPZK4SANAG1ZM5T2K9Z、忘れないその一目惚れ。 なんと可愛らしく、愛しいその目、忘れられない。 はじめに こんにちは、転生したら相変わらずエンジニアだった OLTA（オルタ）プロダクトグループ研究開発チームのタイトルの前置きがとにかく長い B.です。 INVOYカードの開発を担当しています。 今回、UUID＊1
マスタリングAPIアーキテクチャ
この10年の間に、ソフトウェア開発を行う方法は大きく変容しました。作業に依存関係が生じるモノリシックなアーキテクチャから、APIによるマイクロサービスアーキテクチャが主役となりつつあります。一度構築すれば終わりではなく、変化とスピード、生産性の向上に対応するため、APIの設計、構築、運用、変更に関するニーズはますます高まっています。 本書は、モダンなAPI駆動型アーキテクチャについて解説する書籍です。既存のモノリシックアーキテクチャから、どのようにAPI駆動型のシステムへ発展させていくかを、カンファレンスシステムを例に、具体的なケーススタディを通してわかりやすく解説しています。REST APIの基礎から、最適な設計、構築、運用、バージョン管理、およびテスト方法まで、API設計と改善の全体像をしっかり学ぶことができます。また、APIゲートウェイ、サービスメッシュなどの技術を用いて、外部トラフ
【React】なぜコンポーネントの中でコンポーネントを作るのは良くないのか？
こんにちは、ダイニーの Feature team でソフトウェアエンジニアをしている @ta21cos です。 最近は新規事業である決済関連の機能の開発をメインに行なっています。 ダイニーにおける Feature team は機能にフォーカスした開発・運用を行っているチームです。最近は複数の事業毎に Unit として分かれて開発を進めています。 本日は、普段の開発で実際にあった Pull Request のレビューコメントから得た学びについて紹介します。 Dialog を実装しよう React を使ってある Dialog を作成するため、以下のようなコードを書きました（コードは簡略化しています）。 // useSample ファイル // 内部でロジックと Dialog を同時に定義している hook const Dialog = memo<{ progress: number, ...
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
CSS設計とは何だったのか？と、コンポーネント環境との関わり
HubSpotやCSS設計に明るい半田のウェブサイトです。 ウェブサイトの本質は情報を伝えることですので、それを言い訳にデザインは全体的に工事中です。 みんな大好き、あるいは大嫌いなCSS設計。そんな言葉が生まれてから久しく、JavaScriptフレームワーク（以後JSフレームワーク）を始めとする技術が提供するスコープ付きのコンポーネント環境の登場によって、そのなりを潜めている気がしなくもない。 そんなCSS設計とは何だったのか、をちょっと小難しく振り返ってみます。 なお本記事では、区別のためCSS設計が「再利用可能なパーツ」とみなす単位を（あるいは慣習的に）「モジュール」、JSフレームワークにより提供される単位を「コンポーネント」と呼びます。 CSS設計が行っていたこと 「CSS設計」と聞くと Block__Element–Modifier という形式の長ったらしいクラス名を付けることだ
俺が悪かった。素直に間違いを認めるから、もうサービスクラスとか作るのは止めてくれ - Qiita
class HogehogeService # Hogehogeはモデル名まんま def process(hogehoge, option_a: nil, option_b: nil, option_c: false) history = hogehoge.histories.last unless hogehoge.active? hogehoge.histories.last.update(state: :cancel) return error_message end case hogehoge.kind when "type_a" # ... when "type_b" # ... end ActiveRecord::Base.transaction do history.save! history.create_foobars end end end 何が酷いって、機能が何なのか
詳細設計の書き方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに システム開発において詳細設計という工程があります。 プログラマーはこの詳細設計を確認しながら開発を行うことになります。そのため詳細設計ではシステムの構造や仕様、動作などを細かく定義することが必要になります。 詳細設計を行うことでシステム開発の方向性が明確になり、コーディングやテストをスムーズに行うことができます。 詳細設計の成果物としてはクラス図やシーケンス図、画面設計書やデータベース設計書などがあり、システムの動きや機能を具体的に表現するものです。 今回は詳細設計を作成する機会があったので、詳細設計の書き方についてまとめたい
ソフトウェアに関わる人が知っておくといいかもしれない法則10個
「チームトポロジー」や「エンジニアリングマネージャーのしごと」「スクラム実践者が知るべき97のこと」の著者や翻訳者などで知られる吉羽龍太郎氏が、「ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション）」という興味深いポストをX（旧Twitter）で公開しています。 ソフトウェアに関わる人が知っておくといいかもしれない法則10個（勝手セレクション） コンウェイの法則 パレートの法則 グッドハートの法則 パーキンソンの法則 ブルックスの法則 リトルの法則 ピーターの法則 ハインリッヒの法則 ピーク・エンドの法則 ホフスタッターの法則 — Ryutaro YOSHIBA (@ryuzee) January 23, 2024 これらの法則の多くは経験則だったりもしますが、いずれにせよ知っておくと上司の説得に役立ったり、ソフトウェアの開発現場でチームの運営に役立ったり、物
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトウェア開発の複雑さに立ち向かう
アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud
https://web.archive.org/web/20160308080311/http://www.databaseanswers.org/data_models/
Next.jsの考え方
