Design Docs at Google
One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of
コードレビューにラベルを付けるだけでチームの心理的安全性を高めた話
ハコベルシステム開発部のおおいし (@bicstone) です。普段はフロントエンドエンジニアとして物流DX SaaSプロダクトの開発を行なっています。 この記事ではハコベルの開発チームが心理的安全性の向上を目的に採用した、プルリクエスト (マージリクエスト) コメントにラベルを付ける手法についてご紹介します。 背景 プルリクエストをレビューする時、レビュアーとして上から目線になってしまい相手を傷つけないか緊張したり、ちょっとした確認のつもりで書いたコメントが修正必須と捉えられてしまったりした経験はないでしょうか。 本来、ピアレビューは対等な関係であるはずなのに、レビューする側の方が上になってしまいお互いに恐縮してしまいがちです。「勘だと怪しいけど間違っていたら怖いから言えないな」や、「将来的に辛くなりそうな実装だけどわざわざ指摘するほどでもないな」など荒波を立てずにApproveしてしま
terraformをパースして自動で命名規則等のアラートを出したい！ - Qiita
やりたきこと いちいち命名規則を見に行きたくない tagとかも統一したい s3のloggingルールとかも忘れないように・・・ description書けるやつは忘れずに書きたい！ tfファイルをパースして名前とかを正規表現で引っ掛けるしかない！！ まずローカルでプログラムが動くように！ 以下のサンプルを例にファイルから読み込んでパースできるようにする ohsawa0515/hcl_parse_sample 発生した問題 docker内のGoで以下のようなコードを書いていたのですが。。。 FROM golang:latest WORKDIR /go/src/app RUN go get -u github.com/golang/dep/cmd/dep ADD . . RUN dep ensure CMD ["go", "run", "main.go"] package main impor
書籍執筆でお世話になったツール 〜Re:VIEW, textlint, prh, goemon, GitHub, CircleCI〜 - orangain flavor
「Pythonクローリング&スクレイピング」という書籍を執筆しました。執筆にあたって色々なツール・サービスのお世話になったので、記録を残しておきます。 大まかな流れは、以前の記事に書いたとおりです。ツールの選定は2015年1月頃（textlintとprhは2016年1月頃）に行ったので、現在では状況が変わっているものもあるかもしれません。ご了承ください。 目次 目次 Re:VIEW 採用理由 良いところ 振り返って 作ったものとか textlint 採用理由 良いところ 振り返って 作ったものとか prh 採用理由 良いところ 振り返って goemon 採用理由 良いところ 振り返って GitHub 採用理由 良いところ 振り返って CircleCI 採用理由 良いところ 振り返って まとめ Re:VIEW 原稿の形式は著者の自由とのことでしたので、Re:VIEWで書きました。 Re:VI
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
Presentation Summary “High Performance at Massive Scale: Lessons Learned at Facebook”
Presentation Summary “High Performance at Massive Scale: Lessons Learned at Facebook” Published November 24, 2009 academia , cloud , data center , networking , research , storage 57 Comments Recently, we were fortunate to host Jeff Rothschild, the Vice President of Technology at Facebook, for a visit for the CNS lecture series. Jeff’s talk, “High Performance at Massive Scale: Lessons Learned at F
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
