【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1～2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文： www.industrialempathy.com 関連書籍： Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安：11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
【8/10 スタート】連載：「メルカリShops」プレオープンまでの開発の裏側 | メルカリエンジニアリング
こんにちは！ソウゾウのSoftware Engineerの@napoliです。先日、7月21日にメルカリグループの新規事業「メルカリShops」がプレオープンされました。 開発・企画を担うソウゾウが設立されたのは2021年1月28日。それから嵐のように過ぎさった約半年間の開発の裏側を、約２週間に渡って毎日公開していきます！ メルカリShopsとは？ 「"売り買い"の楽しみを、より広げる」、というコンセプトのもと、ものづくりをしている事業者の皆さまと、メルカリのお客さまをつなぐサービスです。 開発はソウゾウという、メルカリグループの中で独立した組織で行われました。全体のシステムもメルカリのメインのシステムからは独立したかたちで構成されており、メルカリグループとしての技術基盤を活かしつつ、さまざま技術的なチャレンジが積極的に行われています。 執筆するエンジニアとテーマは以下の公開表をご覧くださ
DocBaseのフロントエンド改修をどのように進めたか
こんにちは、クレイの阪本です。 もともと外部委託パートナーとしてクレイ案件のお手伝いをしていましたが、気づけば中の人となっていました。 よろしくお願いいたします。 先日、DocBaseはフロントエンド構成を Backbone.js+Coffeescript から React.js+TypeScript へ移行しました。大改修です。 どれくらい大きな変更だったかというと、10万行(2500ファイル)もの変更が行われ、それまでRubyだったはずのリポジトリ代表言語がTypeScriptに替わってしまったほどでした。 なお、2021/3/31のリリースでリニューアルすべてが終了したわけではありません。今後、機能拡張やUI改善をしやすくするための足がかりという位置づけです。 安全にリリースするためテスト期間を多めに取ったこともあり、期間としては1年ほどかかってしまいました。 今回はどのようにリニュ
アジャイル領域へのスキル変革の指針 アジャイル開発の進め方
ITSS+ ／ アジャイル領域へのスキル変革の指針 2020年2月 アジャイル領域へのスキル変革の指針 アジャイル開発の進め方 All Rights Reserved Copyright© IPA 2018-2020 ITSS+ ／ アジャイル領域へのスキル変革の指針 はじめに All Rights Reserved Copyright© IPA 2018-2020 • 本書は、アジャイル開発のプロセス、アジャイル開発 チームにおけるメンバーの役割、および必要なスキル について解説しています。 • アジャイル開発には複数のアプローチ（スクラムやXP など）があります。本書では、代表的な手法である スクラムを例にして、その特徴を解説しています。 • アジャイル開発の進め方には厳格な決まりごとや規 範はありません。本書で説明（例示）する進め方、 メンバーの役割（ロール）など、実際のソフトウェア
Discover Design Better
Bring design and development closer together to improve collaboration, reduce friction, and innovate faster. Get the book Best practices for better design Design Better provides unprecedented access to the insights that power the world’s best design teams.
実装を引き受ける前に詰めておくべきWebフロントエンドの想定漏れチェックシート - Qiita
リキッドレイアウトのように幅が常に変動するレイアウトのデザインは、動かないカンプからは実際の挙動が読み取れず、デザイナーの意図が汲み取りきれないことが多い。また、複雑化するアニメーションの実装においても、カンプだけではコミュニケーションに不備が生まれてしまう。ほかにも、CMSを使った案件ではデザインカンプと実際のデータの間に齟齬がある可能性もある。 実装効率を高めてスケジュール通りに仕事を終わらせるには、とにかく事前に仕様を固めることが大事だ。ワイヤーフレームやデザインの途中の段階からなるべくデザイナーとコミュニケーションを重ね、想定外の要件が発生しないように気をつけるべきだろう。 この記事では、デザイナーやフロントエンドエンジニアが見落としがちなWebフロントエンドの課題について列挙していく。 ホバー表現を後から指示される ツッコミ 後から仕様追加されると困るから先に決めて! メモ 最近
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
LINEサービスの管理画面でUIを標準化するには？
https://github.com/azu/large-scale-javascript/blob/master/refs.md