質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
Go Codereview Comments
原文 目次 go fmt Comment Sentences Contexts Copying Crypt Rand Declaring Empty Slices Doc Comments Don’t Panic Error Strings Examples Goroutine Lifetimes Handle Errors Imports Import Blank Import Dot In-Band Errors Indent Error Flow Initialisms Interfaces Line Length Mixed Caps Named Result Parameters Naked Returns Package Comments Package Names Pass Values Receiver Names Receiver Type Synchronous Fun
StackOverflowからのコピペをやめろ。今すぐにだ。 - Qiita
Original article:https://dev.to/dotnetsafer/rip-copy-and-paste-from-stackoverflow-trojan-source-solution-4p8f その昔コピペできない文章というものがありました。 実際は単にフォントを変えているだけというものですが、人間の目に見える文字と実際の文字が異なることを利用した攻撃の一種と見ることもできます。 さて、最近になって似たような攻撃に関する論文が公開されました。 人間には見えない文字を織り交ぜることによって、一見問題ないコードが実は脆弱になってしまうというものです。 ただ論文は堅苦しいうえに長くて読むのがつらいので、具体的に何がどうなのかよくわかりません。 平易に解説している記事があったので紹介してみます。 以下はDotnetsafer( Twitter / GitHub / Web
On Code Review
TL;DRCode review should probably always be your top priority, and you should figure out the best way to work it into your event loop.Make your code review requests a pleasure to read.I wrote this in March 2014 when I was managing the User Lookup Service team at Twitter, to codify our theory of and approach to code review, and to try to establish some basic best practices. It’s not intended to tell
コードレビューの目的と考え方 - osa_k’s diary
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高（大きな損失を生む問題・後からの修正が困難な問題） 優先度中 優先度低（システムに大きな影響を与えない問題・後からの修正が容易な問題） レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
commit をどう分割すべきか 〜コードレビューの観点から〜
普段の開発の中で git の commit の単位に気を遣っている人もいると思うんですが、どういう単位で commit すべきかみたいな話をあまり見かけない気がします。自分自身 GitHub の Pull Request（以降 PR）ベースのチーム開発を何年か経験してみて、「こうすると良さそう」というものが見えてきた気がするのでまとめてみました。 なお、小さい単位で PR を出す方針にしている場合は、以降の内容に出てくる commit を適宜 PR で読み替えてもらうと良いかもしれません。 そもそも commit の単位に気を遣った方が良いのか？ コードレビューを行う場合など、他者がコードを読む場合はある程度気を遣った方が良いと思っています。理由は次のとおりです。 コードレビューにおいてレビュアーのレビュー時間が短縮できる コードレビューの精度が上がる 変更の経緯を追いやすい 自分にとって
メンバーに恨まれそうな3つのコードレビュー施策を徹底したら、逆にメンバーが爆速で成長した話 - Qiita
ある程度経験を積んだレビュワーがやりがちな失敗は、 指摘しやすいコーディング規約違反だけ指摘している というもの。 コードレビューで指摘するべき欠陥とは、必ずしも規約違反だけではなく、 仕様考慮もれや機能的なバグ、非機能的なセキュリティやパフォーマンス上の問題点も含まれる。 一つ関数に対して複数の視点でソースチェックをしないといけないが、 人間は同時に複数のことは考えられない。 そこでどうすればいいかと情報をあさっていたところ、 われらがIPAがセキュアプログラミング講座というWEBページで、 四回に分けてレビューすることを提唱していた。 １回目はどこに何があるか、 ２回目は可読性が確保されているか、規約にのっとっているか ３回目は機能性 ４回目はセキュリティ といった具合である。 IPAの講座では４回目はセキュリティに限定しているが、 担当していたプロダクトは、非機能面はセキュリティはも
より良いコードレビューをするために気をつけていること | メルカリエンジニアリング
Merpay Advent Calendar 2019 の22日目は、メルペイスマート払いチーム/Backend Engineer の @oinume がお送りします。今日はコードレビューについて自分が普段から実践していることを書いてみたいと思います。 はじめに 世の中にはコードレビューをする時の観点については数多く共有されていますが、より良いコードレビューをするためにはどうするのが良いか、というHOWについてのノウハウはあまりシェアされていないような気がしています。そのため、今日は自分なりに心がけているコードレビューのやり方と、ついでに気をつけている観点について書きたいと思います。 Slackを閉じる (これが本当に一番大事だと思っているので最初に持ってきたのですが)私は極端に集中力がないため、SlackのDesktop通知が来るとついついそれが気になって見てしまいます。コードレビューの
［速報］「Amazon CodeGuru」発表。機械学習したコンピュータが自動でコードレビュー、問題あるコードや実行の遅い部分などを指摘。AWS re:Invent 2019
Amazon Web Services（AWS）は、米ラスベガスで開催中の年次イベント「AWS re:Invent 2019」の基調講演で、機械学習を用いて自動的にコンピュータがコードレビューをしてくれる「Amazon CodeGuru」を発表しました。 Amazon CodeGuruのコードレビュー機能は、Amazon自身のこれまでの大量のコードと、GitHubで公開されているポピュラーな1万のオープンソースソフトウェアのコードを基に機械学習のトレーニングを行ったモデルを用いて、対象となるコードを解析。 GitHubやCodeCommitのプルリクエストと連係し、問題があるとされた個所には人間に読める形式でコメントをしてくれるというもの。 並列処理や脆弱性の問題あるコードを指摘 例えばAWSにおけるベストプラクティスのコードから外れているものや、並列処理における問題などの指摘。
Google Engineering Practices Documentation
Google Engineering Practices Documentation Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practices that we have developed over time. It is possible that open source projects or other organizations would benefit from this knowledge, so we work to make it available publicly when possibl
言葉をどう受け取るかは人それぞれ、かつ、多様ということを学んだ話 - 覚書
はじめに 最初に言っておきますが、とくにスカっと結論が出るような話ではないです。 昨日ふと「行為の否定」を「人格の否定」と捉える人がどれだけの割合でいるのか、人格の否定ととらえた場合はどういう感情が湧くのだろうか、ということに興味があってtwitterでアンケートを取ってみました。 わたしはソフトウェア開発に携わっていて、かつ、フォロワーも同業が多いだろうということで、コードレビュー*1を題材にしました。 コードレビューで「このコードはこういう理由で駄目です」と言われたらどう思うか。ここで理由は妥当なもの(仕様を守っていないなど)であり、かつ、口調や優しくも厳しくもないニュートラルなものとする。わたしは「感情に変化は無い」かな— sat (@satoru_takeuchi) 2019年3月20日 「50-60人くらい答えてくれたら面白いな～」と思っていたのですが、最終的には3705人もの人
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
Explaining Code using ASCII Art – Embedded in Academia
People tend to be visual: we use pictures to understand problems. Mainstream programming languages, on the other hand, operate in an almost completely different kind of abstract space, leaving a big gap between programs and pictures. This piece is about pictures drawn using a text character set and then embedded in source code. I love these! The other day I asked around on Twitter for more example
はじめてのBillGレビューのこと - The Joel on Software Translation Project
Joel Spolsky / 青木靖 訳 2006年6月16日 金曜 かつてExcelは名もないまったく無様なプログラミング言語を持っていた。私たちはそれを「Excelマクロ」と呼んでいた。はなはだ機能不全なプログラミング言語で、変数もなく(値はワークシートのセルに入れる必要があった)、サブルーチンもなく、つまるところ、ほとんど保守不能なものだった。「Goto」みたいな先進的な機能も持っていたが、ラベルは実質不可視だった。 それがまっとうなものに見えていた唯一の理由は、Lotusのマクロに比べたらずっとましということだった。Lotusマクロはワークシートのセルに長々と入れられたキーストロークの並び以外の何物でもなかった。 1991年6月17日、私はMicrosoftのExcelチームで働きはじめた。私の肩書きは「プログラムマネージャ」だった。私にはこのマクロの問題を解決する方法を作り出すこ
コードレビューのクオリティとスピード，とくにスピードについて，それとコミュニケーションについて - hitode909の日記
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて，どちらかに偏ってはいけなく，どちらもキープしないといけない．すごく雑に*1とらえると， クオリティ→正しく動き，不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる． コードレビューでは，不具合を見つけて直してもらったり，動きはしてもコードの可読性に問題があって直してもらったりと，クオリティに目を向けられがちだと思う． ところで，コードレビューとスピードの関わりについて考えてみる．スピードのためにできることはいくつかあり， 早く読み始める→他のことやってても手を止めて読み始めたり，1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか，リリース直前に正しく動かないことが分かったら大きな手
Code ownership and software quality
Author: Michaela Greiler Collective code ownership has been advocated as a best practice [1]. Is it always? Several studies have shown that code ownership has an impact on software quality. This article outlines code ownership and its impact on quality and shows the results of two studies we performed at Microsoft investigating this topic. What is code ownership? In a traditional sense, ownership
GitHub新機能「required review」の使い方 - Qiita
GitHubに新しく「required review」という機能が追加されました。この機能を利用すると、変更が承認されない限りはプルリクエストをマージできないようにする、といったプルリクエストの運用が可能になります。これまでのように、上がってきた差分にコメントを付けるだけでなく、修正を要求したり承認するフローがプルリクエストのレビュー機能として提供されているのが特徴です。masterブランチや、マージにフックしてCIでのビルドやデプロイが実行されるようなブランチに対しては厳格な運用が行えるため、部分的に取り入れるメリットは大きそうです。 GitHubから公式のリリースノートは発表されていますが、日本語での資料がなかったため翻訳してみました。原文に忠実であることよりも翻訳文の読みやすさを意識したため、意訳も多いですが、ぜひご一読ください。 ↓↓↓以下翻訳文↓↓↓ プルリクエストのレビューコメ
わけわかんないレビュー会こそスキルアップの場 - jfluteの日記
特に若者、レビュー会のとき何をしていますか？ ... 「いや、レビューしてますよぅ」 そうですか... ホントに？ なんかメールチェックしてたりしませんか？ メール返してたりしませんか？ 自分の仕事やってたりしてませんか？ Twitter見てたりしませんか？ まんが読んでたりしませんか？ ... いやべつにそれがダメだと言いたいのではありません。 そんな月並みのこと書いてもしょうがない。 ダラダラしたレビュー会であまりに退屈だから、 三国志60巻を会議室に持ち込んで読み切るとか、 したくなる気持ちわかります。 レビュー会はレビューワーが考える時間も必要だから、 なんだか間が空きがちですしね。シーン...って。 レビュー会を開催する方は、 そういう人が出てこないようにファシリテートしていく 必要がありますし、そのために色々と選択肢はありますが、 今日はそういうことを書きたいわけじゃないです。
既存コードの甘い匂い (悪意なきチグハグコードの誕生) - jfluteの日記
まえがき 前提として、しっかりとコーディング規約やコーディング手順などが整備されている現場ではあまり関係ないかもしれません。 そういうのを整備して実践していことが難しい現場、スタートアップからインクリメンタル開発を経て、成長していくサービスを長期間作り上げていく事業会社が主なターゲットの話かもしれません。 既存コードに if 文がありました さて、あなたが開発現場に途中から参画しました。すでに A と B という別の人が作った画面があります。 あなたは C を作ります。C は A と B と似ています。 「さあ、作ってください」 と言われました。どうしますか？ ... まあ、普通に考えたら、A と B を参考に作りますよね。ここに甘い匂いがします。 A と B には、とある定型の if 文による制御がありました。C では一見、要らなそうに見えますが複雑でよくわからない。 C でも if 文
コードの品質を維持したまま開発スピードを上げる | POSTD
高品質のコードベースは、反復作業やコラボレーション、メンテナンスを簡単にすることで、長期的な開発のスピードを上げてくれます。Quoraではベースコードの品質は重要だと考えます。 高品質のコードを維持することは利点がありますが、その反面かなりのオーバーヘッドが発生し、実際の開発のサイクルに時間が掛かってしまいます。このオーバーヘッドと利点の折り合いを付けるのは難しい問題です。この場合、2つの選択肢しかないように思えます。低品質でコードスピードが速いか、もしくは高品質でスピードが遅いか。スタートアップは素早い開発サイクルに最適化しているので、多くの人は低品質で進めたほうがいいと思っています。 このジレンマは解消できます。ツールやプロセスを工夫することで、コードベースの品質を維持したままスピードを速めることができるのです。この投稿では、コードの品質に関しての私たちの考えや、2つの世界を共存させる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
