コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab
3つのコミュニケーションパターン 会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。 コーチング： 「答え」は相手の中にある 相手の話を聞く/問いかける/人となりを認める ティーチング： 「答え」はこちらにある 知識ややり方を教える/相手が理解してないことを説明する フィードバック： 成長を促すために、周りからどう見えているか、思われているかを伝える ポイントは 「いつもティーチングで自分が思うことばかり言ってしまってないか？アプローチには種類があることを認識し、適切に使い分けていこう」 という話でした。 これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか？」と思ったのです。 レビューにおけるティーチングとコーチング ティーチング ティーチングはいわゆる「指摘」です。 プルリク
コードレビューするのが怖いと思っていたエンジニアが半年間コードレビューを経験して思った 10 のこと - きょくちょ日記 -THERE'S ONLY MAKE!-
これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした！ それは、今からちょうど半年前のこと。 海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。 開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう！」と提案があり、それから本格的にコードレビューをやり始めることになりました。 早いもので、あれから半年が過ぎました。 今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。 教育関連に興味がある方や組織の成長を考え
他人の書いたコードに挑もう – Part 1 | POSTD
この記事では、他人が書いたコードを扱うための練習法を一から説明します。目標は、 Spyder Python IDE という今まで触ったこともないプロジェクトのコードに任意の変更を加え、途中で行き詰ることなく、目的達成に必要な情報 のみ 習得することです。ここでは、勘や実験的な手段、そしてプロの現場で養った洞察力を武器に問題に対処する方法を学びます。形式ばったレッスンのように、苦痛を感じることはないでしょう。満足感や挫折、葛藤を味わいながらプロジェクトを進め、最終的には（なんとか動く程度の）パッチを完成させ、大規模で不慣れなコードベースに機能を追加します。 プログラミングを学んでいる人は皆、あらゆる種類のプログラムで大量のコードを書いています。それは、問題集に載っているアルゴリズムを実装するにせよ、ウェブサイトの構築やビデオゲームの作成をするにせよ同じです。ところがプロのソフトウェアエンジニ
デキるプログラマだけが知っているコードレビュー7つの秘訣
SonicGarden Study #11で放送された資料から一部スライドを抜いたものになります。 http://sonicgarden.doorkeeper.jp/events/13229 ----- 優れたプログラマだけが優れたソースコードを書くことができます。 では優れたプログラマになるにはどうすれば良いでしょうか。 自分の書いたコードを、優れたプログラマに指摘してもらうことが一番の近道です。それがコードレビューです。たった一人でコードレビューも受けずに、ただ書き続けてもクソコードはクソコードのままなのです。 そこで今回は、良いコードが書けるプログラマになるための、コードレビューを上手に実践する秘訣を話します。Read less
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
