リーダブルコードを読んで重要だと感じたルールを抜粋 - Qiita
はじめに 業務で開発をしていて、Pull Requestを送るたびに命名について厳しいレビューをもらうので、業務で特に重要だと感じた部分のみまとめてみました! 最初は「動けばいいじゃん！」と思っていたのですが、チーム開発、仕事となるとそうはいきません。 品質も含めて評価されるため、読みやすいコードを書くということは非常に重要です。 レビューで毎回のように 「ちゃんとリーダブルコードを読みましたか？」 と厳しい指摘を受けるので、できるだけその回数を減らしていきたいです。 毎日レビューで厳しい指摘を受けるのは(おそらく上司も仕事のためとしてコードに対しての指摘をしていると思われるが)とても辛いです。 レビューは あくまでもコードの指摘をしているだけ で、自分自身の人間性や仕事に対するダメ出しをもらっているということではない！と思うようにしてます。 とはいえできるだけレビューで受ける指摘は減らし
コードをセルフレビューしてる？〜いまから実務を始める君へ〜 - Qiita
はじめに 「自身のコードを振り返り、実装内容を言語化する習慣はありますか？」 「開発をするとき、動いたからOKと思い、急いでPRを出していませんか？」 また、「コードを書いて要件を満たしているからと、そのまま先輩エンジニアに丸投げレビューを依頼してませんか？」 それは、チーム内の開発コミュニュケーションとして良くないよーーーー 個人開発や、なんちゃってチーム開発（ハッカソン）しかしてきていない私は、セルフレビューの存在や大切さを全く知りませんでした。🥹 この記事では、Draft Pull Requestと、セルフレビューはどういうものかやその大切さを教えます！！！ 以下では、Pull RequestをPRと省略します。 対象読者 長期インターン前に急いでGitHubの復習をしているエンジニア チームに入る前や入りたての駆け出しエンジニア セルフレビューが苦手な若手エンジニア まずは自分の
新卒エンジニアに捧げる！ 新人でも貢献できるコードレビューの方法！ - Qiita
はじめに こんにちは。株式会社Relicのみけたです。 Railsのバックエンドエンジニアとして、弊社自社プロダクトの開発・保守に2年半携わっています。 おかげさまで弊社も規模が順調に拡大し、今年は新卒エンジニアがなんと11人も入社しました！ キャッチアップをしてもらい、互いに切磋琢磨をしながら会社を盛り上げていきたいと思っております。 そこでその一助になればと、「コードレビューで協力したいけれども、そもそもコード読むのむずいし、つまらないし、体質に合わない」というあなたや、「実装しなくちゃいけないから関係する周辺コードを読んだけれども何も分からないし、つらみがすごくて爆発しそう」というあなたに向けて、コードを読む上での方法論をまとめてみました。（Railsを担当するサーバーサイド向け） 何かの参考になれば幸いです。 1. コードが読めない原因を特定しよう 目に前に繰り広がるアフリカの大自
コードレビューするときの観点 - Qiita
コドレビューの観点 コドレビューの観点をまとめてみました。チェックリスト的なものになりますた。 機能性 コードが設計通りの機能を有するか？ データの流れ、取得方法は、設計と一致するか？ データのチェックの漏れはないか？ データの生成、修正、加工は、設計と矛盾がないか？ ループの中で更にSQLなど重い処理を発行するなど、パフォーマンスの懸念はないか？ 必要な場合、国際化の対応しているか？ コネクションやリソースは適切な方法で閉じられているか？ NULLとなる場合や値が取れない場合を考慮しているか？ NULLをある程度許容したコードになっているか？ 読みやすさ 名前の付け方は、共通認識の範囲か？ スタイルガイドにそっているか？ ループ、分岐等の処理記述方法は同じか？ コード設計 パラメータ、プロパティなど正しく機能区別されて実装されているか？ インスタンス等の上書き、重複など考慮されているか？
【要反省】入社してから半年間において先輩からのレビューで指摘されたこと5選 - Qiita
はじめに どうも、こんにちは。もきおです。 未経験から自社開発企業に転職し半年が経ちました。あっという間の半年間でしたがその間色々ありがたいことにレビューをいただきました。なので今回は半年前の入社した自分に送る言葉的な感じでレビューで指摘されたことを書き起こしておきたいと思います。 最後に対策的なとこも記載しているので最後までご覧いただけますと幸いです。ちなみに弊社はRuby、Railsメインで使用しているのでちょくちょくRubyのメソッドとか出てきます。他の言語使用されている方は適当にあしらってもらえればと笑 指摘1: コードちゃんと読んだ？ これは言われることが最も多かった指摘でしたね。何回かこの指摘を受けた時、コードをちゃんと読むってなん何だろう？と疑問に思ったので具体的なポイントを聞いてみました。 分からない箇所を分からないままで読み進めない 想像で決めつけて読み進めない 一つ一つ
新人プログラマをレビューで傷つけないために - Qiita
はじめに この半年くらいで初めて本格的にチーム開発を行い、今では日常的に GitHub の Pull Request を使っています。 チームの方々には、基本的なことから応用的な部分まで様々な観点からレビューをしてもらって、大いに勉強になりました。 ただ、時には「新人にとっては厳しいレビュー」をいただき、1 人で傷つきモチベーションを落とすこともありました。 もちろんそれは悪意のあるものではなくて、新人とレビュワーのスキルのギャップによって意図せず生み出されてしまうものです。 そのような不幸なレビューによって苦しむ新人が減ることを願って、新人を不用意に傷つけてしまう恐れのあるレビューをまとめていきたいと思います。 新人教育の場に少しでも役に立てていただけると嬉しいです。 前提条件 今回の対象とする「新人」は、本格的な開発経験が1年未満の方を想定しています。 個人で少しプログラミングはしてき
WEB+DB PRESS Vol.99の「良いコード」を本気でコードレビューしてみた - give IT a try
はじめに Twitterを見てたら、気になる雑誌の特集を見つけました。 WEB+DB PRESS Vol.99の「Rubyで学ぶ！良いコードって何だろう？」という特集記事です。 WEB+DB PRESS Vol.99 作者: ?橋健一,谷口禎英,井本大登,山崎勝平,大和田純,内村元樹,坂東昌哉,平田敏之,牧大輔,板敷康洋,大?浩崇,穴井宏幸,原口宗悟,久田真寛,ふしはらかん,のざきひろふみ,うらがみ,ひげぽん,池田拓司,はまちや2,竹原,片田雄樹,渋江一晃,WEB+DB PRESS編集部編出版社/メーカー: 技術評論社発売日: 2017/06/24メディア: 大型本この商品を含むブログを見るRuby大好き！きれいなコード大好き！！な僕にとっては、この特集は読まずにはいられません！ 早速買って読んでみました。 お～、なるほど、たしかにいいことが書いてある！ うんうん、そうそう・・・あれ？この
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードレビュー研修