コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
便利なWeb開発向けツールまとめ｜かずたか
※こちらの記事が「先月もっとも多く読まれたノート」の一つに入りました。ありがとうございます！ こんにちは。Kazutaka Shimizuです。 フリーランスとしてPM、エンジニアをやっています。 元々はWebマーケティングのコンサルタントをやっていましたが、独学でWeb開発を勉強してプロダクトを作って起業しました。 最近は創業した会社を離れ、フリーランスとして活動したり、プログラミングを独学した経験をこちらのツイッターで発信しています。 ✔︎この記事の内容 実務、学習のため問わず、Web制作をするに当たって便利なツールと使いかたをご紹介します3年ほど独学でWebサービスを作り運用したり、フリーランスとしてお客さまのサイトを作る中で、様々なツールを見つけました。 初心者の方ほどこうした作業効率が上がるツールを知っていた方がいいと思うのですが、周りにエンジニアがいないため情報が流れてこなかっ
伝わりやすい不具合報告の書き方 #Zaim｜akatsuki174
はじめにこんにちは。Zaim で iOS エンジニアをしている @akatsuki174 です。 バグ報告ってどんな情報をどこまで渡せばいいのかの加減がうまくつかめず、意外と難しいですよね。会話の往復が増えると、タイムロスしたり、ちょっと険悪なムードになりかねません。 そこで、いちエンジニアの立場から「こんな風に言ってもらえると嬉しいよ！」という話をしようかと思います。ただ、あくまでもこれは一例です。プラットフォーム、会社などによっては別のことを伝えた方がいい場面もあるかと思うので、「こんな記事あったんだけれど、うちではどんなコミュニケーションが最適なんだろう？」と社内に問いかけてみてください。 絶対に伝えてほしいこと発生環境 具体的に言うと OS、OS のバージョン、ブラウザの種類、ブラウザのバージョン、スマホの機種、アプリのバージョン、実行環境（本番/ステージング etc）などがこれに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
