【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
デバッグ情報の歩き方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? #はじめに すごーい！きみはでばっぐじょーほーがよめるフレンズなんだね！ （雑な挨拶） 実行時に解釈するスクリプト言語ではなく、ソースコードをコンパイルしてマシン語バイナリを作るコンパイル言語では、プログラムを実行する時に出たバグを解析するのに、ソースコードとの突き合わせ作業が必要になります。とはいえIDEやエディタの拡張機能を使っていれば、ユーザはほとんど何も気にすることなく、プログラムのソースコード上のある行番号で実行を止めたり、その時の変数の値を調べたりすることが出来るでしょう。 この記事では、そうした技術の裏側にあるデバッグ情報
Documenting Architecture Decisions
Context Architecture for agile projects has to be described and defined differently. Not all decisions will be made at once, nor will all of them be done when the project begins. Agile methods are not opposed to documentation, only to valueless documentation. Documents that assist the team itself can have value, but only if they are kept up to date. Large documents are never kept up to date. Small
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書くテクニック - $shibayu36->blog;
blog.shibayu36.org 上の記事が思ったより読まれていたので、自分がこの基準を満たせるようにやっているテクニックも箇条書きで書いておく。 PullRequestを作ったら必ず自分でコードレビューをする コードを書いているとき、その一部一部はこれで完璧と思ってるけど、実は全体を見直すと分かりにくかったりする 1日寝てから見直す 1日経つとちょっと忘れて新鮮な気持ちで見れる 1週間後にもう一回見てみる 1週間くらい経つともうだいぶ忘れて、穴が見えてくる 穴があったら別PullRequestで直す もう一度同じところを担当することがあればチャンス。自分でもこれどういうことだっけってググり始めたら基準を満たせていない 自分が全く関わっていない部分のところを触りだしたらかなりチャンス。本当にまっさらな頭で基準を満たすか見れる。他人がやったことだからとか思わずにちゃんとその時に直す やっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
