メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
コードレビュー虎の巻 - Qiita
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
私が（iOS エンジニアの）採用でコードチェックする時何を見ているのか - Qiita
2021-10-17 追加 弊社の Android 採用課題も公開されましたので、そのリンクを追加しました。 2020-05-18 追加 本日から弊社の採用課題がこちらに変更されました。これまではアプリをゼロから作成していただく課題でしたが、今後は既存のコードをリファクタリングしてもらう課題となりました。ただし我々が確認する項目はそれほど大きく変更するわけではありませんので、本記事の内容の多くは引き続き有効です。 ここ数ヶ月は、iOS のエンジニア採用のコードチェックにもよく参加していますので、そろそろ良さそうと思って、ここで私がコードチェックする時に一体何をチェックしているのかを共有し、皆さんの転職活動やキャリア設計に役に立てればと思います。 Disclaimer この記事の内容はあくまで株式会社ゆめみの iOS エンジニア採用のものです。弊社以外の iOS エンジニア採用や、弊社でも
コードレビュー ありがちな問題への対処例 - Crieit
コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ
役立つコードレビュー 8つのヒント | POSTD
役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ
今日の自習タイム - hitode909の日記
VSCodeでPerlのアウトラインを作るのをやっていた．左下のOUTLINEってコーナーを出すための活動． 最低限は動くけど，構文解析しているわけではなくて，粗悪な正規表現で見ている．sub {があると，名前が{になってしまう．ほかのエディタ用のPerlのプラグインなどから，もうちょっとほどよい正規表現を借りてきたら精度上がりそう． /\b(package|sub)\b +([^ ;\n]+)/g; もうちょっと進むと，language-serverを作ることになると思う．perlのプロセスを裏で動かしておいて，JSON-RPCで投げ付けていくと，シンボル列が返ってくる，みたいな． 参考になったのはこのへん https://github.com/Gimly/vscode-fortran/blob/229cddce53a2ea0b93032619efeef26376cd0d2c/src/d
アメリカでは政府がコードレビューを義務付けている #JaSST - ブロッコリーのブログ
はじめに 先日、以下の記事を書きました。 nihonbuson.hatenadiary.jp その中で、以下のようなリアクションが大きかったです。 JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ "政府の規制によってコードレビューが義務付けされた" コレ自分もそう聞こえたんだけどマジかとビックリした ソースどっかにないすかねぇ #jasst2018/03/09 12:18 b.hatena.ne.jp そこで、カンファレンスの翌々日に、まだ日本にいたJohn Micco氏に急遽会いにいき、質問をぶつけてみました。*1 自分「政府の規制によってコードレビューを義務付けているのは本当か？」 Micco「そうさ。"sarbanes-oxley"によるものだよ。」 sarbanes-oxleyとは何か いわゆる
Visual Studio Code の日本語問題まとめ - Qiita
この記事は、Visual Studio Code 本体や使用されているライブラリで、発生する日本語 (CJK関係) の問題と対応策をまとめたものです。 この記事にはまとめませんが、CJK 特有の問題は完全に放置されているわけではなく、むしろ対処された問題のほうが多いことに注意してください。 バックスペース問題 概要 macOS において、バックスペース入力時に backspace (U+0008) 制御文字が別に紛れ込む。 初期設定で制御文字を確認できないため、気づかないうちに markdown-preview 等での文字化け、この制御文字を含むテキストの提出を行ってしまう。 原因 chromium による問題 714771 (解決済み) が原因。Electron の #9173 で v.1.7.2 に解決が期待されたが、Visual Studio Code が使用する 3.0.13 現在
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
SEゼミ2015 - リーダブルコード勉強会を開催 - 2015-06-08 - ククログ
2015-06-06にプログラミングが好きな学生のためのリーダブルコード勉強会を開催しました。この勉強会について、内容を作った立場からどうしてこのような内容にしたのかについて紹介します。また、今回の内容の課題と今後の解決案についてもまとめます。 基本的な流れは昨年開催したリーダブルコード勉強会と同じで次の通りです。 概要説明（「既存のコードからリーダブルなコードを発見する」を体験するよ！） 課題実装開始（各自リーダブルなコードで書く） コードチェンジ チェンジしたコードをベースに継続して課題を実装（リーダブルなコードを探しながらリーダブルなコードで書く） コードをチェンジ（交換）して実装を継続することで「強制的に他の人の書いたコードを読む機会を作る」ことがポイントです。 詳細な流れに興味のある方はGitHubのclear-code/sezemi-2015の中に資料があるので、自由に活用して
下から目線のコードレビュー - steps to phantasien
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
コードレビューに費やす時間を短くする - クックパッド開発者ブログ
はじめに こんにちは、広告事業部の芳賀（@func09）です。普段はクックパッドの広告配信周りや純広告・タイアップ広告などの商品開発を行っています。 私が広告事業領域の仕事をするようになって、そろそろ１年になるのですが、初めはエンジニア以外の人（営業、編集、広告入稿、レポート、メール配信、などなど様々な担当者がいます）と業務をすることが多くてコミュニケーションが上手くいかず業務がスムーズに進まないことがありました。 当たり前のことではありますが、エンジニアにしかわからない言葉は使わないとか、できるだけ相手の業務を理解し相手の考え方や視点に立って話すなど、ちょっと工夫することで、長引きがちなMTGや相談がすんなり終わったり、お互い良い気分で終わることが多くなって、費用対効果が高いなと感じています。 一方でエンジニア同士のコミュニケーションでも時間がかかってコストが高いと感じることがあります。
Rubyのgemのソースコードを効率的に読む方法 - ブログのおんがえし
いきなり読み始めてもよいのですが、事前に軽く準備しておくと読みやすくなります。 読みたいソースコードをダウンロード bundle install --path vendor/bundle 検索用のインデックスを貼る 読む bgm.rbを例に説明します。 読みたいソースコードをダウンロード hitode909/bgm $ git clone git@github.com:hitode909/bgm.git $ cd bgm bundle install --path vendor/bundle $ bundle install --path vendor/bundle . . Installing json 1.8.2 Installing multi_xml 0.5.5 Installing httparty 0.13.3 Installing itunes-search-api 0.1.
コードレビューについて - (define -ayalog '())
普段お仕事している中で何故かコードレビューをしている時間がわりとあって、暇さえあれば(暇がなくても)コードレビューしている。 そんな中でどういうところを見たらいいのか、あるいは見るべきなのかというのが自分の中である程度蓄積された気がするので書いてみる。あと最後に普段考えていることを少し書いた。 前提 現在の僕の参加しているプロジェクトはこんな感じ Rails プロジェクト( AngularJS 使ったりしている) Git 使ってる( Pull Request ベースの開発で以下が merge 条件) 2 人以上に approve される テストが通ること(継続的インテグレーションの実施) 静的コード解析は導入している( Rubocop, jshint, pre-commit など ) テストのカバレッジは計測していない(月一くらいで測ってるらしいんだけど、だからどうっていう話はない) プ
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
auto_restart - Earthquakeをメモリ解放のために一定時間で再起動するプラグインを書いた - babie, you're my home
あの日見たソフトウェアの能力を僕はまだ知らない。(名前は知ってた) 皆さん、Twitterクライアントは何をお使いでしょうか？私は最近Earthquakeというターミナルで動くクライアントを使い始めたところです。いや、数年前からあったんですけど、あの大地震の記憶も冷めやらぬときにツイートが回ってたもんですから、てっきりTwitterで地震速報を受け取れるソフトだと勘違いしてました。 Earthquakeの良いところ 使い始めた感想ですが、今までのTwitterクライアントで通常時のメモリ使用量が格段に少ない(38MB!弊社調べ)とこが気に入りました。 そして、このソフトウェア、Rubyで書かれているのですが、言語内DSLが素晴らしいです。壮絶技巧な黒魔術もなく平易に書かれているので、Rubyの入門用ソースコードリーディングにも最適です(全部は読んでないですが、多分)。綺麗。 また、プラグイ
ackを捨てて、より高速なag(The Silver Searcher)に切り替えた - Glide Note
Geoff’s site: The Silver Searcher: Better than Ack ggreer/the_silver_searcher · GitHub パターン検索にはackを利用していて、通常利用時には特に不満は無かったんですが、 ファイル数が多いディレクトリだと遅かったので、もっと他の方法が無いかと調べていたら ackの3〜5倍速いというThe Silver Searcherというものが あったので導入。 The Silver Searcherの特徴 公式に書いてあるThe Silver Searcherの特徴 ackの3〜5倍高速 .gitignore、.hgignoreに記載されているものを検索対象から除外 検索対象から除外したいファイルは.agignoreに記載 agというコマンド名で、ackと比べてコマンドが短い(33%減!) なぜ高速なのかは https
Ruby/Railsのコードを読むにはroccoとrdefsが便利：Rails Hub情報局：エンジニアライフ
新年明けましておめでとうございます。今年こそRuby/Railsをやってみようという人もいるかと思います。ここではRubyのコードを読むのに便利なツールを2つほどご紹介したいと思います。 ドキュメント生成ツールのRD、RDoc、SDoc ソースコードに埋め込んだコメントを、そのままドキュメントとして抽出するツールがRubyにはいろいろあります。いちばん古くからあるのは、RD（Ruby Document Format）と呼ばれるもので、Markdownなどと同様に構造を記述できます。 現在、Rubyに標準添付されているのはRDocです。RubyのソースコードからHTML＋CSS＋JavaScriptを吐き出して、ブラウザで閲覧しやすくしてれます。もう1つ、RDocに似たものにSDocがあります。Sはsearchableのことで、ブラウザ上でクラスやメソッド名をインクリメンタル検索できるのが特
『ケーブル』と『コード』の話 : シリコンハウスへようこそ
2009年12月08日 『ケーブル』と『コード』の話 一口に『電線』と言いましても、様々な種類の電線があるモノです。 よく聞く言い方として『ケーブル』『コード』『ワイヤー』と、判るような判らないような横文字がございます。 本日は割と質問の多い『ケーブル』と『コード』の違いについて見てみたいと思います。 まずは定義のハッキリした『ケーブル』から見ていきましょう。 『ケーブル』とは、導体に絶縁を施した絶縁電線を、更にシースで保護したモノの総称です。 『同軸ケーブル』『シールドケーブル』などを想像していただけると判りやすいかと思います。 いずれも絶縁された導体を複数本まとめたりシールドを巻いたりした上にシースを被せ、1本の電線としています。 中には電話用のケーブルや、LANケーブルのように複数の電線をまとめただけのモノもあります。 また、特殊な例としてネオン管用ケーブルのように、ポリエチレンの絶
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
