ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 （作業成果物の欠陥と改善の機会を探すレビュー） 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考： あなたのおっしゃるレビューってどのことかし
こんにちは、CX事業本部の夏目です。 先日本屋をうろついていたら、偶然発見した本が非常に良いものを見つけました。 今年の4月に発行された書籍で、ちょっと在庫はこころもとなくなってきてますが、非常に良い本だったので気にせず紹介します。 (一部の書店や honto ではまだ在庫があるようです) シェルスクリプト入門の入門 作品紹介：シェルスクリプト入門の入門 :暗黒通信団 Linux を活用するには様々なコマンドを使いこなすことが重要ですが，それだけではありません．同じような処理を繰り返すならば一括して処理した方が，間違いが少なくなり効率が良くなります． 本書では，ターミナルで様々な処理を一括処理するために記述するシェルスクリプトについて，ポイントを押さえて最小限だけ説明することを目指しています．特に，Linux や macOS などで広く使われている Bash を用いることを考えています．シ
中目黒Waltzがバズってる。 噂だけでもまじ苦手な店主で（行ったことはない。だって怖いもん🥺） いつか炎上するだろうと思っていたが、本当に炎上するもんなんだな〜。 1回こっきり反論して「もう書きません」、みたいな俺様ルール感が 「そこ！！！そういうとこだぞ！！！！！！」と思わずにはいられない。 →こういう人のせいでマーケットが狭まって昔のイキりジャズ喫茶みたいになるというサゲ意見 →こういう店があっても良いというややアゲ意見 どちらも否定しないが、流石にやり方ってものがあるだろ…と思う。 こういうの防止のために、服屋では接客したり「ちわー」って挨拶するのである。 それも怠ってるなら、オンラインショップだけにするか店主は店に立たないほうが良いのである…。 で、長年思ってることだが、目黒・世田谷・裏渋谷系個人ショップの 「（大変ざっくり言うと）カッペを集めて稼ぎ、 時々そのカッペにキレる・
2021-10-17 追加 弊社の Android 採用課題も公開されましたので、そのリンクを追加しました。 2020-05-18 追加 本日から弊社の採用課題がこちらに変更されました。これまではアプリをゼロから作成していただく課題でしたが、今後は既存のコードをリファクタリングしてもらう課題となりました。ただし我々が確認する項目はそれほど大きく変更するわけではありませんので、本記事の内容の多くは引き続き有効です。 ここ数ヶ月は、iOS のエンジニア採用のコードチェックにもよく参加していますので、そろそろ良さそうと思って、ここで私がコードチェックする時に一体何をチェックしているのかを共有し、皆さんの転職活動やキャリア設計に役に立てればと思います。 Disclaimer この記事の内容はあくまで株式会社ゆめみの iOS エンジニア採用のものです。弊社以外の iOS エンジニア採用や、弊社でも
コードレビュー、これまでいろんなプロジェクトで経験して、意外と使われていないノウハウがあったり、風習が違ってつらみがあったりしたので、いろいろまとめてみる。 指摘事項について よくある話 - 駄目コードを憎んで人を憎まず。駄目なのはコードであって人格じゃない - 指摘する人は人格攻撃せずにコードのどこが悪いのかを指摘しましょう - 指摘される人も、言われているのはコードの問題であって人間の問題じゃないので、素直な心で受け止めよう この辺はみんな知ってると思うので略。ぼくが思う大事なルール コードレビューで指摘された内容は、対応必須ではない 理由： 対応必須にすると、「これ言ったらリリースできなくなるよね」みたいな忖度が発生してコメントできない人が出現するから。 絶対ダメとは言わないけど、あまりよくはない、みたいな指摘については、そのときは急ぐからリリースするけど、次回から気をつけるとかがあ
役立つコードレビュー（CR）のコツは、学校では習いません。アルゴリズム、データ構造、プログラム言語の基礎は習っても、確実に役に立つフィードバックを返す方法をじっくりと教えてくれる人はいないでしょう。 コードレビューは優れたソフトウェアを作り出すには欠かせないプロセスです。レビューを通したコードは、そうでないコードよりも 質が高く、バグが少ない 傾向があります。健全なコードレビュー文化には、副次的な利点もあります。たとえば、 バス因子 を押しとどめる、新メンバーのトレーニングに最適なツールになる、など。また、コードレビューは優れた知識共有の手段でもあります。 前提 まずは、この記事のポイントの前提を提示する必要があるでしょう。それは以下のとおりです。 信頼のおける環境で作業をしている。あるいは、あなたとチームは、あなたの信頼性を高めることを目指して作業している。 コードではないシナリオでフィ
ある程度アプリケーションの規模が大きくなってくると、ある変更がどこまでの影響範囲だと思っているのかがコミュニケーションにおいて重要
出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。 専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。 一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。 この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。 このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。 というわけで、技術書の制作における「レビュー」につ
はじめに 先日、以下の記事を書きました。 nihonbuson.hatenadiary.jp その中で、以下のようなリアクションが大きかったです。 JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ "政府の規制によってコードレビューが義務付けされた" コレ自分もそう聞こえたんだけどマジかとビックリした ソースどっかにないすかねぇ #jasst2018/03/09 12:18 b.hatena.ne.jp そこで、カンファレンスの翌々日に、まだ日本にいたJohn Micco氏に急遽会いにいき、質問をぶつけてみました。*1 自分「政府の規制によってコードレビューを義務付けているのは本当か？」 Micco「そうさ。"sarbanes-oxley"によるものだよ。」 sarbanes-oxleyとは何か いわゆる
RAVPowerブランドなどの製品を販売しているマーケットプレイス出品者「Sunvalley Brands Japan」(旧 NBD JAPAN)に購入時の個人情報を悪用されました。 何が起きたのか 先日、RAVPowerブランドのACアダプタ RP-PC017をマーケットプレイス出品者Sunvalley Brands Japanより購入し、以下のレビューを投稿しました。 USB Type-C/USB PDの規格に適合していると考えられるが、手放しではオススメできない RAVPowerブランドのUSB PD対応36W ACアダプタであるRP-PC017のレビューです。なお、このレビューに使用した個体はマーケットプレイス出品者 "NBD JAPAN" より購入しました。 (後略) (カスタマーレビュー - Amazon.co.jp) そしてこのレビューが公開された3日後、Sunvalley
React Native Japan で @besutome 、 @YutamaKotaro と技術書典 3 で技術書を書いたのでその作業内容を記録しようと思う。 出した本はこちら。 PDF 形式で配布している。 おおまかに次の流れで作業した。 原稿を書く + 校正作業 レビュー Re:VIEW 形式への変換 装丁 + 微調整 次で各手順について書いていく。 textlint と Re:VIEW Template は素人が使っても確実に威力を発揮するので強く使用を推奨。 原稿を書く + 校正作業 原稿は markdown で書いて git で管理した。今回は複数人で書いたので github に repo を作ってそこで共有。 原稿を書く際は先に textlint と日本語用のルールをセットアップして、日本語として不自然にならないかチェックしながらやった。非常に有用なので使用をおすすめ。 h
この細川義洋さんの特有のテイストは「物語仕掛けでシステム外注の実情が分かりやすく解説される」ことにあるわけなんですが、この分かりやすさがヤバイ。なぜヤバいのかというと、ヤバいから。 つまり、「おーいお前。システム担当としてベンダー呼んで外注しとけよー」「おかのした」という時点で大地雷。ジョブフロー分かってない奴がシステム組む責任者になって窓口業務でもやろうもんなら、高カロリーの地雷を踏み抜いて天高く舞い上がるなんて日常なわけです。若者よ、無茶しやがって。そういう日常が裁判沙汰となったとき調停委員として出てきていたのが著者の細川さんですから、まあ説得力はあります。 そんなわけで、この本の入り口からして泣けるわけなんですが、理路整然と語られるほど、あるいはシステムとは何なのかを知るほどに、会社全体のジョブフローがどう構成されているのか誰も分かってないということに気づかされます。だからこそ、最初
下に表示されている文字を入力してください 申し訳ありませんが、お客様がロボットでないことを確認させていただく必要があります。最良のかたちでアクセスしていただくために、お使いのブラウザがクッキーを受け入れていることをご確認ください。
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
僕は結城浩さんのことが好きなんだなぁ。彼の書いた「文章を書く心がけ」は自分が執筆をするときにも何度もお世話になった。彼の日記などに時々かいま見える「読者によりよいものを届けよう」という真摯な態度には好感を感じる。以前の僕は宗教と名の付くものが全て嫌いだったのだが、敬虔なクリスチャンである彼の日記を読んでいるうちに、その嫌悪感が軽減した。結局のところ、どんな集団にもいい人もいればわるい人もいるということなんだ。 では、わるい人に対してどう対処するのがよいのか。1601年生まれの哲学者バルタザール・グラシアンはこう言っている。 人の中傷は無視せよ。黙殺で答えることが賢明だ。身の潔白を明かそうとしてペンの力に訴えてはいけない。書かれたものはいつまでも残るから敵を懲らしめるどころかその名を留める手助けをしている。忘却に勝る復讐はない。 なるほどね。400年も経つけども、人間の社会はあんまり変わって
が対比されています。 [0,1,2,...,9]はダサいか？ 本書に対する感想として幾つか見かけたものに、「関数型コードの[0,1,2,...,9]という配列リテラルベタ書きの方が命令型コードよりダサいではないか！」というものがありました（0〜999まで足せと言われたらどうするつもりなのか！）。しかし、まさに0〜999まで足すにはどうしたらいいのだろう、という問いを本書の登場人物自身が問い(p. 45)、配列リテラルではなくrange関数を使って配列[0..999]を生成するコード例が示されます(p. 109)3。ですので、何度も繰り返されるコード例[0,1,2,3,4,5,6,7,8,9].reduce(plus)のダサさは本書にとって本質的なものではありません。 ただ、容易に予想できる反応でもあるので、最初に「配列として与えられたデータ[13, 5, -6, 34, 9, -17, 8
続編というか補足解説:99%のプログラマがIQ145のJKに「ダサい」と言われてしまう理由とは？【その１】「計算機科学のほんとうの基礎」を理解していない。IQ145のJKと同じ事を語るMITの権威とSICPという聖典の権威を借りてマインドコントロールを解いてみよう 『数学ガール』の著者である結城 浩氏に申し上げます。 『関数型プログラミングに目覚めた! IQ145の女子高校生の先輩から受けた特訓5日間』の著者として、『数学ガール』の著者である結城 浩氏に申し上げます。 私は、『数学ガール』を拝読したこともございませんし、貴殿のことも良く存じ上げません。そして貴殿による一方的なTwitterをはじめとする言動に甚だ迷惑しております。 責任ある執筆者、言論人として、書評行為はご自由になさってください。 そして、その場合は責任ある執筆者、言論人として最低水準の矜持、作法を期待します。 書評行為は
WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,
継続的にPHP入門書のセキュリティ問題を確認していますが、今回は「やさしいPHP 第3版」を取り上げ、今どきのPHP入門書のセキュリティ状況を報告したいと思います。 やさしいPHP やさしいシリーズ 単行本 – 2008/2/29 やさしいPHP 第2版 (やさしいシリーズ) 単行本 – 2010/8/28 やさしいPHP 第3版 (「やさしい」シリーズ) 大型本 – 2014/9/26 上記のように、2008年に初版が出版された後2回の改版がありました。 第2版ではクロスサイトスクリプティング(XSS)の説明が追加され、第3版ではXSSに加えSQLインジェクションの説明が追加されました。つまり、初版ではこれらの説明はなかったということです。 第3版におけるSQLインジェクションの対策方法はプレースホルダによるもので、結果として本書にSQLインジェクション脆弱性は見当たりません（パチパチパ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く