タグ

developmentとreviewとprogrammingに関するjune29のブックマーク (4)

  • そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操

    技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて

    そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
    june29
    june29 2018/01/28
    「コードレビューの必要性」というよりは「レビュー対象」について考え直そう、という問題意識に読めた。実装がやり直しになっちゃう件は設計をレビューしたら防げる。コード以外もレビューしよう。
  • コードレビューにおけるレビュアー側のアンチパターン

    tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に

    コードレビューにおけるレビュアー側のアンチパターン
    june29
    june29 2018/01/04
    独力で仕上げるのが難しいような内容なら、独力でがんばってからレビューに出すよりペアプロするなどした方がよさそう / ぼくは「レビュー」と「修正指示」は完全に別のものとして認識している
  • コードレビューの高まった言葉 - 職質アンチパターン

    ブログ間違った,普段こういう事はこっちに書いてます. http://moznion.hatenadiary.com 最近自分がコードレビューで使いがち,あるいは表立って使ってないんだけど内心評す時に使う言葉が色々とあり,まとめてみることとした.参考にしない方が良いと思う. 左は言葉,右は説明. 屈強 - コードが力強い時に使う.例えば長い一枚スクリプトとか,コメントが一切ないバッチ処理とか.やや批判的な意味合いで使うことが多い. マッチョ - 屈強と同じ文脈で使いがち 屈強だけどしなやか - 屈強だけどしなやかな時に使う.好意的な屈強さと言える. モノリス - 長大なトランザクションスクリプト見た時とかに使う.やや批判的. 言い訳ないですか - 後で直していくぞ! というメンタルの時に書かれたコードのコメントが案外少ない時に使う言葉.言い訳は無いよりあった方が良い.実際には「もうちょっと言

    コードレビューの高まった言葉 - 職質アンチパターン
    june29
    june29 2016/08/04
    エントリの冒頭から言い訳が書いてあって体現者という感じでしなやかさを感じた。
  • 1