Sider ReviewAs announced in a blog post, we've shut down Sider Review service. If you have any inquiries, send an e-mail to support@sider.review Note: we'll close the e-mail address after February 10, 2023.
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
Swift のコードレビューで気をつけていること - jarinosuke blog
Swift での iOS アプリ開発 徐々にですが、でも確実に色々な場面で Swift のコードを見る機会が増えてきたことを実感します。 iOS の設計思想など大枠の部分では Objective-C での知見は生きてきます。 しかし Swift の言語仕様についても知っておかないと ついつい低きに流れて Objective-C ぽい Swift になってしまいがちです。 Swift のコードレビュー そこで Swift らしく Swift の良さを活かしたコードにするためにコードレビューの話になるわけです。 iOS 開発全般におけるコードレビューについては以下のブログにまとまっているので省きます。 iOSアプリケーション開発のコードレビューで気をつけていること - ninjinkun's diary また本記事を書くにあたって Swift コードレビューを調べていて良いものがまとまっていた
コードレビューのツールについての調査 - Qiita
このドキュメントはコードレビューを支援するツールについての調査を行った結果を記述する。 ツールの紹介 Redmine Code Review プラグイン Redmineのプラグインとして動作する。 http://www.r-labs.org/projects/1/wiki/Code_Review インストール方法 通常のRedmineのプラグインと同様 使用方法 リポジトリ―でコミット済みのリビジョンの差分を取り、レビュー用のコメントを記述する。 作成したレビューはプロジェクトのコードレビュータブで一覧として表示される。 記述したレビューはチケットとして登録される。 そして、レビューで作成したチケットはリポジトリから返信とステータスの遷移が行える。 Trac Peer Review Plugin Tracのプラグインとして動作する。 http://trac-hacks.org/wiki/P
コードレビューをする話を新卒研修で話しました。 - パルカワ2
今いる会社には、新卒研修で座学と呼ばれるものがあって、先輩エンジニアがある程度好き勝手に話したいことを1時間ほど話す時間があります。 そんな最高の学習環境である座学で、コードレビューについて話してきました。 テーマは、 https://github.com/kenchan/keynote-theme を使いました。 内容についての補足 iOSとか出来ないので、そのあたりの説明が出来ない 最近コードレビュー全くしてない 相手によってはLGTM画像が嫌いな場合がある TPOがあるよね コンテキストが違う人にいきなりはキビシイ 海外の人にアニメ画像は使わないほうがよさそう 英語だと横向きの顔文字とかよく見る ;P 美女LGTM画像は会社で使ったことない スライド作る時に気をつけたこと 6個のステップ、3つの目的とか個数を言うようにした。 新卒氏たちに今やるべき事を認識してもらう 新卒氏たちにも出
初めてコードレビューされる人のためのpull requestとcommitの作り方 - Qiita
pull requestの作り方について 作業途中でもpull request作ったほうがいい。 作業途中だと分かるようにwantedlyだと、[WIP]とかタイトルの最初につけてる タイトルに書くこと 作業の内容が分かるタイトル descriptionに書くこと WHY WHATを必ず書く Viewに変更がある場合は、スクリーンショットを貼る 関連のissueやpull reqeustへのリンクがあれば書く コードだけで分かりにくい箇所の説明(できるだけコードだけで分かるほうがいいけど) イメージは、初めてpull requestを見る人がmergeする上で必要な判断ができる情報があること。 どの作業をしているか、残っているか分かるように、マークダウンでチェックリスト作る git commitの方法について 僕自身まだまだcommitの単位は汚いので、今の僕レベルで気をつけていることを書
PHP 5.4.4から==の挙動が一段と難しくなりました - hnwの日記
PHPの==は両辺を適当に型キャストしてから比較するような演算子です。この型キャストの規則は難解すぎる上にドキュメントも不十分なため、PHPプログラマでも完璧に理解している人はほとんど居ないくらいの印象です。バグの原因になりかねないため、なるべく==を使わないようにしているPHPプログラマも多いはずです。 ところで、この==演算子の挙動がPHP 5.4.4から変更されていることはあまり知られていません。本稿ではこの内容を紹介します。 Bug #54547 の騒動 まずはこの仕様変更の経緯を紹介します。 2年ほど昔、Hacker Newsで2^63付近の整数に対応する文字列をPHPで比較したときの挙動がおかしいというスレッドが盛り上がったことがありました。具体的には、PHPでは「'9223372036854775807' == '9223372036854775808'」がtrueになるとい
Go コードのレビュー時によくされるコメント - GRACEFULEXIT
CodeReviewComments から Go コードのレビュー時によくされるコメントについて。 gofmt gofmt またはそのスーパーセットである goimports を実行すること。goimports は gofmt に加えて import 行の修正も行う。 コメント文 http://golang.org/doc/effective_go.html#commentary を参照。宣言に対するコメントは少し冗長に見えるかもしれないけど完全な文にする。そうすれば godoc できれいに整形される。次のように説明するものの名前から始めピリオドで終える。 // A Request represents a request to run a command. type Request struct { ... // Encode writes the JSON encoding of re
取っ掛かりを網羅したUNIX入門書 L'eclat des jours(2014-03-23)
_ Dart アスキーの鈴木さんからプログラミング言語Dartを頂いた。 また新しい言語か、と思いながらパラパラ見てみると、なんか雰囲気が良いので少しまじめに読んでみた。 JavaScriptとJavaとC#の良いとこどりと書いてあるが、特徴は次のところだろう。 ・関数の記述はC#やJavaのラムダ式のように楽ちん。例）(x, y) => x * y ・EclipseベースのIDEが最初から用意されている ・型名の明示が可能（finalのような修飾子もあるし、リストとマップにはジェネリクスも利用できる）なので、型チェックを最初からされるのが好きな開発者でもOK（TODO:varで宣言した変数に限り、JavaScript並の自動型変換がある（便利ではあるけど諸刃の剣なのでそこを宣言で制御できるのなら良いと思った）かどうかは、ぱらぱら読んだだけだとわからなかった） ・クラスベースだが、必ずしも
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
