コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
そうだ、ラクスルを作り直そう！ - RAKSUL TechBlog
10月からラクスルにジョインさせていただいた水島です。 新参者ですが、宜しくお願いいたします。 さて、入社して間もなくCTOの肝いりでスタートした 「Raksul Platform Project」 のプロマネを拝命したため、今日はその全体感の話をしたいと思います。 なにをするのか 「スタートアップあるある」だなんて言わないでください。 ラクスルをフルスクラッチで作り直そうとしています。 でもそれはあくまで手段です。 目的は、 技術負債と思われている部分を根本的に解消して開発しやすい状態にする（エンジニアを幸せに） システムに柔軟性を持たせて経営戦略の選択肢が増えている状態にする（経営を幸せに） の大きく2つです。 特に前者の「エンジニアを幸せに」という目的に対する経営陣の温度感が不思議と高いのはポジティブに感じています。短期的な投資対効果とかではなく、「ものづくり」を大切にする会社になる
開発現場に根強く残る8個のバグレポートアンチパターン - Qiita
ex-mixi Advent Calendar 2017 - Qiita 9日目をいただいた @kkakizaki です。 株式会社ミクシィの在籍期間は2008年から2016年までで、 QAマネージャーとして、次々に巻き起こる品質保証上の課題を何とかするお仕事をしていました。 現在は株式会社サイバードにて、同じく品質保証部門の長として、 品質保証だけではない様々な課題解決に勤しんでおります。 折角の ex-mixi なので、今回は この記事 の続きです。 前回の記事は2012年に書かれたものですが、 現在も繊細なエンジニア達が死にやすい状況に変わりはなく、 影響の大きな死因の1つとして「イケてないバグレポート」が存在しています。 BTS にイケてないバグレポートが増殖してしまう現場の方は、 この記事をテスターに叩きつけてやってください。 アンチパターンその1：敬語 テスト業務が受発注関係で
SQL アンチパターン （Bill Karwin,和田卓人,和田省二,児島修 オライリージャパン） - サポンテ 勉強ノート
SQLアンチパターン 作者:Bill KarwinオライリージャパンAmazon 免責 この本を読んだことがない人が、このノートから本の内容を脳内に展開することはできません。見出し部分は Amazon などで「目次」の内容として公開されている範囲にとどまります。 この本を買うかどうか悩んでいる人は是非購入しましょう。これは価値のある本です。 本の紹介 SQL つまり RDBMS を使ったアプリケーション開発や運用の中で遭遇する「アンチパターン」についてまとめられている本です。出版年を見ると歴史が古いことがわかりますが、Amazon で見ると最近も非常に人気があるロングセラーであることがわかります。読んでみると、それは確かに納得のいくものでした。 アンチパターン、つまり「やらない方がよい手法」を集めたものですが＿＿多くの人が共感してくれると思いますが＿＿よくやってしまう手法でもありました。な
あっと驚かせるJavaプログラミング(をやめよう） - Qiita
はじめに 驚き最小の原則（法則）という言葉があります。 Wikipediaの記事を引用すると http://ja.wikipedia.org/wiki/%E9%A9%9A%E3%81%8D%E6%9C%80%E5%B0%8F%E3%81%AE%E5%8E%9F%E5%89%87 ユーザインタフェースやプログラミング言語の設計および人間工学において、インタフェースの2つの要素が互いに矛盾あるいは不明瞭だったときに、その動作としては人間のユーザやプログラマが最も自然に思える（驚きが少ない）ものを選択すべきだとする考え方である。 要するに、使うときに「おやっ？」という驚きが少ないほうが良いプログラムであるといえます1。 この記事では敢えて驚きの多いプログラムの書き方を紹介します。驚きの多いプログラムを読むとどんな気分になるか、実際に体験してみてください。もちろん、本当は驚きが少ないプログラムを書
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
