サクラチェッカー ｜ ステマ やらせ サクラ評価 口コミが丸わかりサクラチェッカーはステマ/サクラ評価を見抜くサービスで、 2019年10月にサクラレビューでクローズアップ現代、 2023年7月にAIレビューでNHKニュース７ など多数のTV・新聞等で紹介されています。 私自身はレビュー・口コミ機能の開発に15年以上携わっている大手IT企業の40代SEです。
レビュー文化の会社で、楽に生きられる思考法 - ビープラウド社長のブログ
「コードを憎んで人を憎まず」 コードレビュー時のレビュアー（レビューする側）の考え方（レビュー時に人格攻撃にならない、感じられないように気をつけるなど）として、良く使われる言葉です。 一方で、レビュイー（レビューを受ける側）はどのように考えればよいでしょうか。 マシンやプログラムからエラーメッセージが出ることを「怒られる」と言ったりします。 実際には、マシンやプログラムはエラーを伝えているだけで「怒っている」わけではありません。 しかし、マシンが出すエラーメッセージは無機質なので怒られているように感じることから「怒られた」と言うようになったのでしょう。 このように同じエラーメッセージでも、人の捉え方によって（エラーを）親切に伝えてくれているのか、怒っているのかが変わってきます。 怒られてる・責められてると感じた場合の人の反応 Slackやチケットなど文字のコミュニケーションも無機質になりが
「おまえは今までレビューしたプルリクの数をおぼえているのか？」 - pixiv inside
こんにちは、kanaです。社内ではpixivというサービスでPHPとTypeScriptとVim scriptを書く仕事をしています。今日はpixivの開発におけるコードレビューの話をします。 問題 pixivは昨年でサービス開始から10周年を迎えました。サービス開始当初と比較すると山のように新しい機能や画面が増えています。なのでpixivのコードベースは巨大です。PHPファイルだけでも5000個以上あります。 kana@pixiv ~/pixiv (2) [master] ^-^)/> git ls-files '*.php' | wc -l 5555 これだけの数のファイルを全て把握するのは無理です。なので、各々の開発者が自由にコードを書いて混沌にならないよう、設計方針を始めとして各種コーディング規約が整備されており、秩序を保っています。 とはいえ誰もが常に完璧なコードを書けるわけでは
技術書のレビューの経験則
出版される前の本の内容は、通常は著者や編集者に代表される「制作サイド」の人間にしか読まれない。 専門性の高い本であれば査読とか監修といったプロセスを有識者にお願いすることはあるけど、そうしたお願いをするときには有償だったりカバーや袖に名前を出したりすることが多いので、これも「制作サイド」の一部とみなしていいだろう。 一方、基本的に無償で、完成した書籍の献本と謝辞への掲載くらいを前提に、あくまでもベストエフォートで発行前の本の内容を見てくださいというお願いを第三者にすることもある。 この場合の第三者というのは、制作中の書籍の想定読者だったり、出版後の書籍を対象読者へ紹介してくれそうな立場の人だったりする。 このようなプロセスを制作に取り入れる習慣は、とくにここ数年のIT系の出版社ではめずらしくなくて、界隈では「レビュー」などと呼ばれている。 というわけで、技術書の制作における「レビュー」につ
SI開発のレビュー文化を変えよう - 室長のひとりごち
ジョイ・インクを読んでいるんですが…ちょうどこの辺り。 これまで経験してきた中でこれは参考になるかもしれないと思って書いているエントリの中のプラクティスがこの本に散りばめられている感じがしないでもないのです。 ジョイ・インクでは組織として回しているところもあるので洗練度合いは濃淡があるのは当然としても、プロジェクトマネージャやマネージャをそれなりに経験しているとエンジニアはだいたい同じようなことを考えるのだなぁ、と思うのです。 SI開発でレビューをする理由（PMの立場で） SI開発のかったるさの一つにアウトプットの品質検証があると思うのです。でも、プロジェクトマネージャの立場だと工程毎にプロジェクトの品質要求レベルを満たしていることが次工程に突入できるクライテリアになるから現場に任せたとは言えないし、リリース後に明らかに工程毎に出さなければならない不良はその工程で出しておかないと契約形態に
「速」を落とさないコードレビュー
Forkwell Meetup #3 https://forkwell.connpass.com/event/48147/
自分の言葉で書かれたコミットメッセージが好き
誰にも質問されていないけど回答すると、ぼく個人としては「レビュー指摘事項を反映」的なコミットメッセージにはやんわり否定派で、どうしてそう変更すべきと思ったのかを自分の言葉で書く方がベターと思っています。 — juné29💩公式アカウント (@june29) January 11, 2017 140文字には納まらないな、と思ったのでちゃんとエッセイを書く人間になろう！ たとえばぼくがレビューを担当させてもらって「ここはAの方がよいと思いました」とコメントしたとして、そのときに「レビューで指摘された箇所を修正」というメッセージ付きのコミットが追加されたとする。そのあとぼくが思い直して「いや、他の箇所も考慮すると、やっぱりBの方がよさそうです」とコメントしたとする。また「レビューで指摘された箇所を修正」というコミットが追加される。 こういうやりとりだと、「レビュー」というプロセスというよりは「
よりよい機能をより早く届けるためにGit/GitHubを使いこなす10の方法 - Qiita
この記事は freee Engineers Advent Calendarの6日目です。 こんにちは。freee株式会社でアプリエンジニアをしている @kompiroです。主に会計freeeの開発に携わっています。 僕には「よりよい機能を、より早くユーザーに届けたい」という信念があります。今日はよりよい機能を、より早くユーザーに届けるためのGit/GitHubを活用する10の方法と題してGitやGitHubの便利な使い方や日々のTipsをお届けします。1 PRのレビュー完了までの時間を最速にするための工夫 freeeではGitHub上でレビューをしながら開発を進めています。レビューをするのもされるのも、うまく進めないと結構時間がかかります。もちろんコードをより良くする作業に時間を割いているのであれば時間がかかるのも致し方ないです。しかし、進め方による問題でも数日〜数週間デプロイが延期されれ
あなたのおっしゃるレビューってどのことかしら？ - Qiita
ソフトウェアのレビュー ソフトウェアの開発において、レビューが品質の確保をするために有効であることは私達は直感的、経験的に理解しています。 人は間違いを犯しますし、間違った本人よりも他人のほうが誤りを見つけ易いものです。 ここまでは、認識を共通できるものでしょう。 しかし、レビューと一言で言った場合に、その実態にかなりのギャップが生じます。 ある人にとっては、気の合う同僚とコーヒーでも飲みながら成果物をチェックしてもらう事かもしれません。 しかし、別の人にとっては会議室で衆目の前で細かい所を吊るし上げられる苦行のことかもしれません。 ある人にとっては、口で簡単に説明するだけかもしれませんし、メールやツールでコメントを書くだけかもしれません。 しかし、別の人にとっては、準備の為に大量の資料を作り、終わった後にも大量の報告書を書く事かもしれません。 プロジェクトを初めて、レビューといった場合、
チームでコードを書き始めた後、「どうやらレビューってやつをした方が良いらしい」くらいの若手に向けた資料です。
code_review_basics.md コードレビューの基本 一番大事な事 ソースコードはプロジェクトの共同所有物である 誰かだけが触れるコードを無くす 自分だけが持っているコードを無くす 自分だけが触っている時間を短くする コードレビューで大事な事 コードレビューは... 相互学習型のプロセスである メンバが成長することが大事 相互学習とは レビュアーとレビュイーが、お互い学び合うこと 考え方を共有すること 質問することで学ぼう 一番できる誰かだけが教えるのではない 知識や経験の少ない人が何に躓いているのか学ぼう メンバの成長 同じミスをチーム内で繰り返さないことが成長 ミスを繰り返さないために 本人の問題にしない 明日はわが身 仕事の正しい手順を覚えよう 道具の正しい使い方を覚えよう コードレビューの心構え 伝えることが大事 改善するまでがレビュー レビューにコストをかけ過ぎない
コードレビューについて - camlspotter’s blog
このところ立て続けにコードレビューについて話をする機会があったので 私が経験した最高のレビュー体制を簡単にまとめておこうと思います。 利点 何故必要か 何が嬉しいのか コスト うまく回すためには何が必要か 細かい運営方法 はっきり言って当たり前の事しか書きません。 私も当時は当たり前のことだと思っていましたから、特に気にもしていなかったのです。 ただ見聞するところによると、これをちゃんとやっているところはとても少ないようです。 ウォールストリート系のファンドでもろくにレビューしてないとかどういうことなんでしょう。 だから時々会社が吹っ飛ぶんですね… 結局は、ああだ、こうだ各論を言っても、ちゃんとやれるのか、それ一点に尽きてしまう話なのですが… 利点 レビューを何のためにするか、それはまず第一に自分達の書いているコードに潜在するバグによる損失をできるだけ少なくすることでしょう。 型システムや
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IDEA * IDEA