小さな CL
小さな CL どうして小さな CL を書くのか？ 小さくシンプルな CL には以下のような利点があります。 速くレビューできる。レビュアーにとって、小さな CL をレビューするための 5 分間を数回確保するほうが、一度の大きな CL をレビューするための 30 分をまとめて確保するよりも容易です。 隅々までレビューできる。変更が大規模だとあっちこっちに詳細なコメントを大量に書かねばならず、レビュアーと作成者がストレスを感じやすくなります。ときには重要な点を見落としたり省略したりしてしまうこともあります。 バグが混入する可能性が減る。変更箇所が少なければ、開発者もレビュアーも CL の影響範囲が予測しやすく、バグが混入したかどうかを見分けやすくなります。 CL が却下されても無駄になる作業が少ない。巨大な CL を書いてからレビュアーに全体的な方向性が間違っていると言われると、多くの作業が無
レビューする人も、される人も知っておきたい！開発プロセスごとのレビュー観点チェックリスト - Qiita
この記事はモチベーションクラウドシリーズのアドベントカレンダー7日目の記事です。 こんにちは。リンクアンドモチベーション、モチベーションクラウド開発チームの江上です。 モチベーションクラウドの開発チームは、新卒メンバーも多数参加していることもあり、開発プロセスを細かめに定義しています。その開発プロセスにおいてそれぞれに、「レビュー観点チェックリスト」を作成しているので、それを公開していきたいと思います。 全てのチームで有効とはいかないものの、何かの気付きになればいいなと思います。また、「こういう観点もあるよね」というFBは大歓迎ですのでぜひよろしくお願いします。 開発プロセスの定義 現状の開発プロセス 現在モチベーションクラウドの開発チームは以下のようなプロセスを前提にして動いています。 関係者レビューは実際には実装のレビューに近しいですが、実装レビューはコードレビューと紐付けたいので、あ
ER図レビューの３つのポイント - 設計者の発言
前回記事で、業務システム開発の上流工程でDB設計がないがしろにされるケースがあると指摘したが、よほど低レベルな職場でない限り、今では上流工程でのER図の作成が標準化されるようになっている。 ところが、そのER図がまるでショボいにも関わらずレビューで承認されるケースがあとを絶たない。理由は単純で、ER図があるかどうかだけがチェックされて、内容レベルの検証がなされていないためだ。それはとりもなおさず、DB設計を的確にレビューできる技術者がいないためでもある。 ER図を見れば、プロジェクトが成功するかどうかまではわからないかもしれないが、「デスマーチ化するかどうか」はわかる。それほど便利な図面が提出されながらレビュワーのスキルが足りないのでは、設計標準の持ち腐れというものだ。 そこで、ER図を効果的にレビューするためのポイントを紹介したい。構成的な心地よさがあるか、キー構成が単純すぎないか、創意
A2-4
1 KKD（勘、経験、度胸）も使いよう。 一歩進んだレビュアーになるために。 ～ レビュー眼 ～ 1 ㈱日立システムアンドサービス 角口 勝隆 （JaSST Kansai 実行委員） ・(株)日立システムアンドサービスで、主にパッケー ジソフト および ソリューションサービスの品質保 証業務に従事。（職種は、いわゆるＱＡ） ・優れたレビュアーの「ヒラメキ」は何故おこるのか、 そのノウハウを他人へ伝授することはできないのか 検討を始め、JaSST Kansai実行委員会内でブラッシュ アップを受けて、今回の発表に至る。 2 自己紹介 ・心得 ・観点、着目点 ・思考法（発想法） ◆「レビュー眼」とは 3 ここでは、 優れたレビュアーの持つ秘訣(ﾉｳﾊｳ)を 「 「 「 「レビュー レビュー レビュー レビュー眼 眼 眼 眼」 」 」 」と称し、 その内容について、考察します。 ◆「レビュー眼」
レビュー方法を勉強してみよう
3. 今日の勉強会のネライ • レビューの手順を知り、 レビュースキルアップや各種※の品質向上に 役⽴ててもらいたい （ ※仕様書／設計方法／テスト方法・・・） 3 4. 目次 • １．ワーク①：とりあえずレビューしてみる！ • ２．レビューとは〜１章〜 • ３．レビューの進め方〜２章〜 • 〜休憩〜 • ４．ワーク②：レビュー前にやることを考えてみる • ５．ワーク③：またまたレビューしてみる 4
レビューを行う際の3つのポイント（１）～視点～
[事務所TOP] [コラム一覧へ] ポイント：レビューを行う視点、要件確定レビュー、曖昧の排除、デザインレビュー、基本仕様の展開、コードレビュー、ソースコードの検査 レビューを行う際の3つのポイント（１）～視点～ レビューを行う際の3つのポイントとは ビューをうまく行うために考えるべきポイントは3つあると考えています。 これはレビュー研修の最初に必ず話ことで、一つは「視点」、一つは「技法」、一つは「意識」です。 コラムを三回に分けて、それぞれを考えてみたいと思います。 最初は、レビューを行う「視点」について考えてみます。 「視点」とは、プロジェクトや設計、コードそのものにある「よくある落とし穴」を見つけるポイントのことです。 レビューを行う際に、どんなところに落とし穴があるのかが分かると早期のリスクの発見、対策の合意に至ることができます。 要件確定、設計（デザイン）、コードでのレビューを例
Markdown記法+Git+md2review+ReVIEWで原稿・ドキュメント管理 - プログラマでありたい
来年は、インプットあたりのアウトプットの増加を目指しています。具体的なアウトプットとしては、ブログを書くこともその1つですし、公開・非公開を問わずに効率的にドキュメントを書いていくこともあります。その中で効率的にドキュメントを書くには、バージョン管理を含めドキュメントを管理する仕組みが必須だと思います。以前、原稿を書いていた時は、Git+MS Wordで書いていました。版管理出来るという点では良いのですが、Wordということで執筆出来る端末も限定され、またフォーマット変更もしづらいので改善を考えていました。 そんな中で、IT系の物書きの人たちの間でReVIEW良いよという話を何度も聞いたので試してみようと思いました。一方で、記述のデファクトは今後はMarkDown基本になると思うのでそちらもマスターしたいと考えています。Twitterで何気なく呟いたら、@masawadaさんにmd2rev
【書籍制作ワークフロー】ReVIEW 入門 #09 – config.yml について | DevelopersIO
config.yml - ePUB 生成向けの設定ファイル ReVIEWからePUBを生成するにあたって、様々な設定を定義するのがconfig.ymlというファイルです。ePUBのファイル名はもちろんのこと、奥付に表示される著者情報や表紙に使用するHTMLや画像ファイルなど一通りの事をここでまとめて定義するというわけです。 書名・言語 パラメータ 例 説明 bookname
【書籍制作ワークフロー】ReVIEW 入門 #08 – 前付・後付 | DevelopersIO
Webページと違って、書籍と呼ばれるものには一般的に前付と後付というものが含まれています。前付まえつきとは、『はじめに』や『まえがき』といった本文に入る前の導入口という役割を担った文章を指します。プログラミングの技術書には必ずと言ってよいほど想定する読者層や書籍の構成や表記に関する解説が冒頭に書かれています。エッセイ本においても、プロローグといった類の文章が冒頭にあります。そして本文の後には『おまけ』や『付録』といった追加コンテンツが来たりします。『あとがき』なんかもそうですね。これらを後付あとつきといいます。 ReVIEWにもこれら前付・後付を本文とは別に定義、管理する機能が備わっています。今回はその使い方を学ぶとします。 事前知識 - 本文ファイルの管理方法 そもそもの前提として、本文用のReVIEWファイルがどのように管理されているのかを把握しておく必要があります。例えばch01.r
【書籍制作ワークフロー】ReVIEW 入門 #07 – ReVIEW 記法 (その他) | DevelopersIO
前回、前々回と、ReVIEWの基本的な記法を学びました。今回はやや特殊な、しかし覚えておくといざというときに使える記法について学ぶとします。 ReVIEW 記法 - 生データ行 ReVIEW は予め定められた記法で書くことで対象となる HTML 要素に変換されるわけですが、この ReVIEW の範囲を超えた特別な要素を組みたい場合があります。その際は以下のように記述することで実現ができます。 //raw[|html|<div class="wrapper">\n<div class="contents">\n<p class="comment">特別なコンテンツです。特別なコンテンツです。</p>\n</div>\n</div>] HTML <div class="wrapper"> <div class="contents"> <p class="comment">特別なコンテンツです。
【書籍制作ワークフロー】ReVIEW 入門 #06 – ReVIEW 記法 (インライン) | DevelopersIO
前回に引き続き、ReVIEW 記法について学んでいきます。今回はインラインの記法と HTML での出力結果を学んでいくとします。 ReVIEW 記法 - インライン 段落中の任意の文字に対して特別な文法を付与することが出来ます。 ソースコードリストを参照 対象となるソースコードリストの連番文字列に変換されます //list[list][リストのサンプル]{ int main(int argc, char **argv) { puts("OK"); return 0; } //} ..は@<list>{list}をみてください。 HTML <p class="caption">リスト1.1: リストのサンプル</p> <pre class="list">int main(int argc, char **argv) { puts("OK"); return 0; } </pre> </div
【書籍制作ワークフロー】ReVIEW 入門 #05 – ReVIEW 記法 (ブロック) | DevelopersIO
前回までで ReVIEW 環境の構築と実際に ePUB と PDF を生成してみることで、全体の大まかな流れを攫ってみました。今回からは ReVIEW 記法について学んでみるとします。 ReVIEW 記法について ReVIEW の記法は ASCII の EWB をベースにしており、そこに RD や Wiki のエッセンスを取り入れた独自の物となっております。慣れるまで多少戸惑うところもありますが、これといって複雑なところは無いので、Wiki や Markdown に触れたことのある方であれば、大した時間もかからずにすんなりと習得できるかと思います。 ここでは ReVIEW で記述されたテキストがどのような HTML に変換されるのかを並べて紹介します。 段落
【書籍制作ワークフロー】ReVIEW 入門 #04 – PDF を生成してみる | DevelopersIO
前回アッサリと ePUB の生成に成功しました。今回も同じようなノリで PDF の生成をやってみるとします。 PDF を生成してみる こちらも ePUB と同じく、以下のコマンド一発を実行するだけで OK です。 bundle exec review-pdfmaker config.yml compiling preface.tex compiling ch01.tex compiling ch02.tex sh: extractbb: command not found sh: extractbb: command not found ・・・ と思ったら壮大にエラーが出ました。 どうやらReVIEW から PDF を生成するには TeX 環境を用意しなくてはならないようです。ググってみましたが、どうも TeX 関連はまとまりに欠けた情報ばかりで戸惑いましたが、最終的に以下に紹介する方法で
【書籍制作ワークフロー】ReVIEW 入門 #03 – ePUBを生成してみる | DevelopersIO
前回までの記事で ReVIEW 環境の構築手順を学びました。今回はまだ ReVIEW の詳しい記法や仕組みは置いておいて、まずはコンパイルして実際に ePUB と PDF を生成してみるとします。 細けえ話は後だ、後。 ReVIEW プロジェクトの作成 ePUB や PDF を作成するということもあり、ReVIEW プロジェクトには単一のテキストファイルだけでなく幾つかまとまったファイル群が必要になります。それらが全て頭に入っていれば良いのですが、最初なので既存のサンプルプロジェクトをダウンロードするところから始めるとします。 サンプルプロジェクトをダウンロード 以下のリポジトリにサンプルプロジェクトがあるので、こちらを拝借するとします。 https://github.com/takahashim/review-sample-book git clone もしくは Download ZIP
【書籍制作ワークフロー】ReVIEW 入門 #02 – テキストエディタにシンタックスハイライトを (Sublime Text & CotEditor) | DevelopersIO
ReVIEW 記法でマークアップするテキストファイルは.reという拡張子です。似ているとはいえ、Markdown や Wiki のそれとは記法が異なるので、コレ用のシンタックスハイライトと入力補完が欲しいところです。 そんな訳で、手持ちのテキストエディタがSublime Text とCotEditor なので、この2つにそれぞれ導入してみます。 Sublime Text 用の ReVIEW プラグインをインストール 1) パッケージコントロールをインストール Sublime Text を導入したばかりという方でまだコレを入れていない方は、早々にインストールしてください。（※要・再起動） Package Control Installation 2) Package Control : Add Repository を選択 ⌘ + Shift + pと入力してCommand Paletteを
【書籍制作ワークフロー】ReVIEW 入門 #01 – ReVIEW をインストール | DevelopersIO
そんな訳で、ReVIEW を使って簡単な電子書籍を作成するまでのフローを学んでみることにします。 はじめに - ReVIEW って何？ ざっくばらんに言えば、テキストマークアップ型の原稿フォーマットです。Markdown や Wiki のような ReVIEW 記法でテキストファイルを作成し、それらを ePUB だけでなく PDF(LaTeX)、XHTML、XML といったマルチフォーマットに出力可能なフレームワークです。 Microsoft Word や Adobe InDesign では単一フォーマットでの出力が基本であるうえ、著者が一人であればまだしも、複数人で一つの書籍を書くとなるとレイアウトや書式の統一を図るのがなかなか難しかったりする訳です。これはコンテンツ（文章や画像）とレイアウトという異なる要素が混在していることが主な原因です。 これに対し ReVIEW は、コンテンツを R
ReVIEWとは？開発に役立つ使い方、トレンド記事やtips - Qiita
ReVIEWに関する情報が集まっています。現在155件の記事があります。また64人のユーザーがReVIEWタグをフォローしています。
ReVIEWチートシートを作りました - ひつじのにっき
ReVIEWの記法は統一されていないところもありすべて覚えるのは大変なので作りました。 A4に印刷するか壁紙やプレビュー表示でみながら使っていただけると。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
レビュー方法を実践してみよう20150201