PHPStanで始める継続的静的解析 #phperkaigi /php-static-analysis
モブプログラミングとコードレビュー
特集1では，2人1組になってコードを書くペアプログラミング（ペアプロ）と，チーム一丸となってコードを書くモブプログラミング（モブプロ）について解説します。… この中で、モブプロは モブプログラミングの「モブ」とは群衆のことです。モブプログラミングでは、ペア（2人）ではなく、モブ（チーム全体）でプログラミングを行います。モブの人数は3人から5人くらいを想定しています。ペアプログラミングと同様に、コードを書くだけでなく、すべてをモブで行います。 と説明されています。 私がモブプログラミングという言葉を初めて聞いたのは、現マイクロソフト牛尾氏の以下のブログ投稿だったように思います。
IDE上でコードレビュー完結！Upsourceを使ってみる - Qiita
当記事は Upsourceというツールがあります。 気になる〜〜って思ったときに参加した #phpconfukでサムライズムさんがブース出展していたので、デモを見せてもらいました。 便利そう・・・！ ってことでセットアップしたので、ご紹介です。 Upsourceってなんですか JetBrainsのツールです Code review, team collaboration project analytics Githubみたいなやつ〜 10名までは無料で利用可能！！ Free 10-user plan included (8 users + admin + guest). コミットログ(ブランチツリー) レビュー 他にも・・・ コミット等のアクティビティ分析 レビューのアクティビティ分析 ソースコードの閲覧 権限管理(Hub) など。 どうやって使うんですか サーバーウェアです。 サーバーを
人間らしくコードレビューするには(パート1) | Yakst
自動化することによりあなたはレビュアーとしてより価値のある貢献ができるようになります。importsの順序やソースコードのファイル名の命名規約などの問題を無視できるならば、機能上の誤りや可読性の問題といった、より関心のある問題にフォーカスすることができます。 オーサーもまた自動化の恩恵を受けます。ケアレスミスを見つけるのに1時間浪費することなく、即座に見つけられます。即座にフィードバックを受けられることで、関係のあることがオーサーの頭に残り、これにより学習が容易となり、修正コストが低くなります。それに加え、彼らが初歩的な誤りについて指摘を受ける必要がある場合、あなたから指摘を受けるよりコンピューターから指摘を受けたほうが彼らの自尊心の観点からはるかに気分がよいわけです。 これらの自動チェックはコードレビューのワークフローの中に入れましょう(例えば、Gitのコミット前のフックやGithubの
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 - エンジニアHub｜Webエンジニアのキャリアを考える！
悪いコードを憎んで人を憎まず！ プルリク送付前に心がけたいコードレビューのコミュニケーション術 コードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、現役エンジニア・池田 惇さんの経験とともに考えてみます。 アプリエンジニアの池田 惇（いけだ・じゅん／@jun_ikd）です。 コードレビューとは、エンジニアにとって毎日発生する作業であり、「コードを書く」という行為と等しく重要なタスクの1つです。同時に、ただ漠然と「粗探し」をするだけがレビューの目的ではありません。特に若手のエンジニアにとっては、先達のエンジニアのコードにじっくりと触れ、学びを得て、さらにチームに自分の持つ知識・技術を還元する、大事な機会でもあるのです。 今回はコードレビューを円滑に進め、より学びを促進するために重要な「コードレビュー時のコミュニケーション」について、私自
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
コードレビューで気をつけていること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Chromium Code Review Advent Calendar 2017の25日目の記事です。参入障壁が低かったのでなんとなく書いてみました。興味のある方は充実の本家Chromium Browser Advent Calendar 2017も参照下さい はじめに オープンソースのウェブブラウザ Chromiumでそこそこ長く開発をしてるので、自分や周りの人がコードレビューで心がけていることを書いてみました。良いコードとは何かという話はまた別の長い議論になるのでここではとりあげません。 基本的に、コードレビューはコミュニケーショ
コードレビューを受けるのがつらくなったときは - めるノート
そういうときがよくあります。 コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。 anond.hatelabo.jp さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。 私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？ 刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をま
新卒氏への10年選手からのコードレビューの解説(1) - koicの日記
とある新卒氏へのとある10年選手からのコードレビューの解説をやったりしていた。当然知識にひらきのあるコメントがあったりするもので、そういった解説業やコメントへの質問を一緒に返すのを行なったりすることがある。 その際に、いわゆる CSV アップロードによくある CSV からレコードを作成するようなテストケースについての対話で出たはなし。 境界値テスト CSV アップロードの場合は、青天井の INSERT が起きないようアップロードの上限値を設けることになる。その上限値の境界値テストをやりましょうという話がひとつ目。例えば上限値が 500 件の場合は正常系の 500 件と異常系の 501 件の境界は試験パターンとして考えられる。 スタブ ふたつ目は、レコードの生成には時間が掛かることから上限値を正直に 500 のままだと自動テストの度に、約 500 レコード以上作ることになるためスローテストに
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
プルリクとかレビューについて尊敬できるエンジニアに相談してみた話 - まえとうしろ
誰かと開発することを忘れかけていて、 もぅﾏﾁﾞ無理。。。とりあえずLGTMしょ。。。 となりかけてしまったので、尊敬できるエンジニアである夫に相談してみました。 世の中の正解かは分からないですが、私は参考にしたいと思ったのでまとめます。 レビューの仕方がわからないです！！どこから見たらいいかわからないです！！ プルリクでは「意図」がわかるようにしたほうがいい。 夫が所属しているチームでは下記の内容をプルリクの説明(description)に書いているそうです。 なぜこの変更を入れるのか バグだったらどういう問題があったか、機能だったらこれを入れたら何が改善されるのか(なにが嬉しいの？) 変更概要 変更概要を読むとdiffを見たときに意味がわかるように こういう理由でこういう実装になっている、こういう理由でここは直さなくてもいい、などを書く 関連Issue チケット(issue)へのリンク
iOSエンジニアのコードレビューのための動画キャプチャGif化のTips - Qiita
概要 プルリクエスト(マージリクエスト)を行う時に、変更点を箇条書などで書くと思います。 その時に、画面キャプチャが貼ってあるとレビュワーに内容が伝わり安いですよね。また、動画キャプチャが貼ってあったりすると尚更伝わりやすいです。 ってことで、今回は私が行なっている動画キャプチャをGitLabに貼るまでの(私の知っている限りで)最速の方法を紹介します。 使うツール GIPHY Capture QuickTime Player iPhone実機(Android分からない) or シミュレーター 手順 1.デスクトップにiPhoneの画面を表示する シミュレーターの場合 XcodeでシュミュレーターをRun シュミュレーターをデスクトップに表示させる シミュレータの準備は以上。 実機の場合 実機の場合は少し手間ですが、本物の動きをキャプチャできるというメリットがありますね。 QuickTime
チーム開発とコードレビュー - nozayasu
チーム開発にコードレビューが持たらすものはなんでしょうか？ コード品質の向上 ナレッジの共有 仕様不備の発見 不具合の発見 コードレビューの成果物として、パッとこのようなものを思い浮かべました。 上記のような成果物を得ることは、望ましい姿と言えます。 しかし同時に、自分にとってこれらの成果物=目的ではありません。 あくまでコード品質の向上等は、コードレビューという体験を通して発生した副次的なものです。 コードレビューの目的は、XPのプラクティスにて示されている、コードの共同所有権 (Collective Code Ownership)の実感と熟成であると自分は捉えています。 今回はなぜコードの共同所有権を必要とするか、コードレビューがそれにどう関係するのかを言葉にしておきたいと思います。 コードを通したプロダクトへの貢献 一般的に業務としてコードを書く場合には、コードの総体であるプロダクト
コードレビューの文化を少しずつ改善していった話
#code_kaizen コード改善 #3 で発表したスライドです。 SpeakerDeck: https://speakerdeck.com/yasuhiroki/kodorebiyunowen-hua-woshao-sizutugai-shan-siteitutahua
バグを増やさないためにコードレビューのチェックリストを使う | Yakst
チーム内で良くある間違いなどをチェックリストにし、それをコードレビュー時に使う事で、コード自体のレベルを上げつつコードレビューの品質のばらつきをなくす取り組みについて。Trelloなどを開発するFog Creek社のブログの翻訳。 効果的なコードレビューについて書いた我々のブログ記事の中で、チェックリストを使う事を推奨した。チェックリストを使う事で、レビューが継続的にチーム全体でうまくはたらくようにできる。また、ありがちな問題を見つけたり解決したりするのを確実にする、簡単な方法でもある。 ソフトウェア工学研究所の研究によると、プログラマは15から20の良くある間違いをしてしまいがちだという。そういった間違いをチェックリストに追加しておく事で、問題が起こった時にそれを特定し、確実に駆逐するようにできる。 チェックリスト作りに取り掛かるに当たって、一般的な項目は以下のリストのようになるだろう。
モダンコードレビューとは － コードレビューが変わりつつある？：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
2010年くらいからライトウェイトなコードレビューをその他のレビューと区別してモダンコードレビュー(modern code review)と呼ぶことが増えています。コードレビューのツールを使い、対面での会議を実施せずに完了できることや欠陥の検出だけでなく情報共有も対象になっている点が異なっているようです。 モダンコードレビューの明確な定義やコンセンサスのとれた定義はまだありません。書籍Making Softwareの18章の章タイトルにもModern Code Reviewが使われ、言及されています。Making Softwareの日本語版は2011年、英語版(原典)は2010年に出版されています。18章をご覧になるとわかりますが、レビュー一般に関する言及、レビュー会議を実施する効果に関する言及があります。 2013年にInternational Conference on Softwar
コードレビューを会話しながら行う取り組み - Hatena Developer Blog
こんにちは。アプリケーションエンジニアの id:itchynyです。 今回は、コードレビューを会話しながら行う取り組みについて紹介します。 コードレビューは大事なコミュニケーションの場です。 コードレビューの効用としては、単純なミスがあるコードをリリースしない・プロダクトのコードの品質をよりよくしていく、あるいはその方策を模索するといったことが挙げられます。 こういったことは当然のことですが、なによりもまず、レビューというのは一緒にプロダクトを作っている仲間とのコミュニケーションの場だと思います。 多くの人は、プロダクトのコードをよくしていきたい、読みやすいコードを書きたい、分かりやすいコードで目的の機能を作りたいといった共通の思いを持っていることでしょう。 コードを書いた人の思いを汲み取りながら、共感したり、譲歩したりしながら、よりよい方法を提示していきます。 それでも時には、どういうコ
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - jarulraj/sqlcheck: Automatically identify anti-patterns in SQL queries
