はじめに 最初に言っておきますが、とくにスカっと結論が出るような話ではないです。 昨日ふと「行為の否定」を「人格の否定」と捉える人がどれだけの割合でいるのか、人格の否定ととらえた場合はどういう感情が湧くのだろうか、ということに興味があってtwitterでアンケートを取ってみました。 わたしはソフトウェア開発に携わっていて、かつ、フォロワーも同業が多いだろうということで、コードレビュー*1を題材にしました。 コードレビューで「このコードはこういう理由で駄目です」と言われたらどう思うか。ここで理由は妥当なもの(仕様を守っていないなど)であり、かつ、口調や優しくも厳しくもないニュートラルなものとする。わたしは「感情に変化は無い」かな— sat (@satoru_takeuchi) 2019年3月20日 「50-60人くらい答えてくれたら面白いな～」と思っていたのですが、最終的には3705人もの人
デザイン批評や伝え方のセミナーやワークショップはもちろん、関連記事も幾つか書いています。しかし、だからといって完璧なデザインの会話ができているわけではありません。デザインという言葉の捉え方を合わせるのに苦労することもあれば、いつの間にか話が脱線してしまうことも少なくありません。 書籍などで知識を得ることはできますが、知識があれば必ずうまく実践できるとは限りません。たとえ自分自身に高いスキルがあったとしても、周りを巻き込まなければコミュニケーションは成立しません。セミナーやワークショップを受講された方から「私は理解できたが、周りにどう言えば良いか分からない」という感想をいただくことがあります。デザインについて語るのに難儀している状態だと、建設的な会話を促すのは至難の業です。 記事やプレゼン資料を社内共有するのもひとつですが、スルーされてしまう場合もありますし、いざ会議の場になると忘れてしまう
2014年に新卒向けに発表した資料が未だに評判がよい。間違ったことは言ってないと思うし、新卒向けに話したので新卒にとってまだ良い資料なのだろう ただ資料を作ってから5年が経ち、働いてる会社も変わって僕自身は少し違うコードレビューをするようになってきた。言ってしまえば、今はがんばってない。いや、がんばってないって言うと悪く受け取られそうなのだけど、ちょうどいい塩梅のがんばらなさがよいと思っている。前やっていたようにコミットを全部見ることはなく、今は「後戻りしにくいことを見つけること」にコードレビューの目的を絞っている。 後戻りしにくいとは、例えば設計の話で設計は決めてしまうとコードを大きく書き直す必要があって大変。だから、そこはよく話してから実装していくし指摘される。 逆に言えば後戻りできるならそれで良くて細かい指摘はしない。実際、コードを書いてるときにこうしたほうがよいなと思ったら直すし、
コードレビュー、好きですか？ エンジニアリンググループの山口です。 クラウド電子カルテ「エムスリーデジカル」を開発しています。 今回は、チームに根ざしている『褒め文化』についてお話しします。 ※この記事は、エムスリー Advent Calendar 2018 13日目の記事です。 『褒め文化』とは 簡単に言えば、コードレビューで褒める文化です。 コメントに対してコメントしている様子 とても簡単です。 とても簡単なのですが、前職(SIer)ではこういった経験が全く無かったため*1、join直後は（良い意味で）驚いたのが印象に残っています。 とにかく褒める けっこう安易に安直に褒められますし、褒めます。 アカウント名は一部加工 思ったことを素直にコメントにしてしまいます。 褒め文化の効用 ここからは「※個人の感想です」になってしまいますが、こうした褒め文化は、レビュア・レビュイどちらの立場でも
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
同僚が社内グループに『みんなではじめるデザイン批評』を読んだ感想を書いていて、それが良かったのとそういえばこんなことあったなと思い出したので読んだ感想がてら書きます。 みんなではじめるデザイン批評―目的達成のためのコラボレーション&コミュニケーション改善ガイド 作者: アーロン・イリザリー,アダム・コナー,長谷川恭久,安藤貴子出版社/メーカー: ビー・エヌ・エヌ新社発売日: 2016/05/26メディア: 単行本（ソフトカバー）この商品を含むブログ (1件) を見る 命ずるな、尋ねよ 『みんなではじめるデザイン批評』を読んでからデザイナーとの会話だけではなくエンジニア同士でコードレビューをする時にも「まず、意図を尋ねる」ことに気をつけるようになった。 「自分だったらこうするのにな (だから、こうすべき)」と思ってもそのまま脳直で出すのではなく、なにか事情があるのかもしれないと思い「こうなっ
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
そういうときがよくあります。 コードレビューがある会社は今が初めてだけど、きっとこれから先もコードレビューがある限りは、なくならない気持ちなんだと思います。 だから、そんなときに振り返れるようなものを残しておきます。 「コードレビュー つらい」でググってみると、はてな匿名ダイアリーのこんな記事が見つかりました。 anond.hatelabo.jp さすがに、ここまでヒドいケースを経験したことはないし異常だと思ったけれど、以下のくだりは自分の胸にすごく刺さりました。 私はプログラマに向いていないんじゃないかと思う。よいプロダクトを作る上で強い言葉を交えた議論が必要不可欠ならば、それに強いストレスを感じてしまう私はプログラマとして適正がないのでは？ 刺さったのですが、それでも自分はここでやっていかなくちゃならないと思っているので、つらくなったときにいつでも読み返せるよう、見つけた記事・資料をま
『議論パターン』 (Discussion Patterns) ～不毛な議論を避け、実り有る議論とするために～ はじめに ～「パターン」について～ ソフトウェア開発では、よく「パターン」という言葉が使用される。 「定石(じょうせき)」のような意味である。こうすればうまく行く、という問題解決の典型的な例をカタログ形式で収集し、纏(まと)めたものである。 「デザイン (設計) パターン」、「アーキテクチャ (構造) パターン」、「アナリシス (分析) パターン」等の種類が有り、総称して「ソフトウェア パターン」等と呼ばれる。 「アンチパターン」という言葉もある。こちらは逆に、こうしたらうまく行かない、という典型的な例を集めたものである。 「パターン」という概念は別にソフトウェア開発に特化したものではない。「ソフトウェア パターン」自体、元々建築の方に有った方法を持って来たものである。様々
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/Read less
下に表示されている文字を入力してください 申し訳ありませんが、お客様がロボットでないことを確認させていただく必要があります。最良のかたちでアクセスしていただくために、お使いのブラウザがクッキーを受け入れていることをご確認ください。
登壇してからかなり時間が経ちましたが書きます。 11月22日にドリコムさん主催の若手エンジニアLT大会で登壇させていただきました。 きっかけ 社内で@june29さんから声をかけていただき、登壇経験もなかったのでチャンスだと思い若手エンジニアLT大会に参加することを決めました。 内容 僕は、学生時代にコードレビューという文化が存在しなかったので、社会人になって初めてコードレビューというものを行いました。コードレビューをやってもらったり、やったりした中で感じたことを発表しました。 感想 各社の若手の皆さんはどうやって会社に技術貢献してきたかや入社して何をやってきたかなどを発表していました。 すべての発表においてレベルが高く、ポジティブな意味で自分ももっと頑張らないとなと思いました。 とても緊張しましたが参加してとてもよかったと思います。 あと、ドリコムさんのオフィスがめちゃくちゃお洒落でした
これは pepabo Advent Calendar 2016 - Qiita の14日目の記事です。 昨日は id:Fendo181 さんの 日報サービス「DuPo」を作った話でした！ それは、今からちょうど半年前のこと。 海の香りと共に暑い夏がやってくる ... 甘酸っぱい青春が再び来るのではないかと予感させる ... そんな季節でした。 開発チーム内で行っていたスプリントレトロスペクティブの時間に、チームメンバーから「そろそろコードレビューをやってみよう！」と提案があり、それから本格的にコードレビューをやり始めることになりました。 早いもので、あれから半年が過ぎました。 今宵は年の瀬ということもあり、ふりかえりを目的として半年間コードレビューを積み重ねたことで僕の中で起きた考えの変化や感じたことについて 10 個書き出してみることにしました。 教育関連に興味がある方や組織の成長を考え
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
お題「エンジニア立ち居振舞い」 自分は重箱の隅をつつかないというのを意識してる。 重箱の隅をつつく問題はコードレビューの現場でよく聞く。レビューの場で所詮「書き方レベル」の指摘が横行してしまうというやつ。 誰しも綺麗なコードを追求したい気持ちはあると思うし、自分もそうなんだけど、あまり良くないなと思ってやらない事にしてる。理由は3つ。 時間の無駄 指摘される側の精神衛生上よくない そもそも意味ない 細かい指摘でも修正してマージするまでには結構時間がかかる。コードを直し、手元でビルド・動作確認し、pushしてCIを回し、「修正しました」と報告し、LGTMが付いてやっとマージできる。このプロセスが日に何度も発生すると確実に時間を食ってしまうし、Nitsな内容を何度も何度も受けると精神的にも疲弊してしまう。それで生産性が下がってしまえばもっと大きな問題になる。 こうした指摘をしたくなる時、「コー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く