#ronsakucasual DBの論理削除についてひたすら共有する 論理削除 Casual Talks #1 にいってきたまとめ - もぐめぽろぐ
名前 とりあえず削除フラグ 目的 エンドユーザから見るとデータがないことにしたいけど、実際のデータは消したくない 削除したデータを検索したい データを消さずにログに残したい 誤った操作をなかったことにしたい、直ぐに元に戻したい アンチパターン 例えばis_deletedというカラムがtrueの場合は削除されているとみなす メリット update文ならデータが簡単に元に戻せる気がするのでなんとなく安心 -> 俺のupdate文でなんとかなる！！ 起こること SELECTするときには常にWHERE句が追加で必要になり、コードが削除フラグだらけになる 全員テーブル設計に精通してるわけではないので、テーブルによって削除フラグの有無があったりした場合、認識の齟齬を生みやすい 例えばrubyでdefault_scopeを用いて、よかれとおもってコードレベルでデフォルトを変えたらバグがたくさん出てくる
スクラムアンチパターン：ゴリラ a.k.a. スーパースター｜Takahiro Ito
スクラムアンチパターンシリーズの第２弾ということで、また私が経験したスクラムのアンチパターン「ゴリラ a.k.a. スーパースター」について軽く説明していこうと思う。 ゴリラとはゴリラとは、開発チームの中にいる声の大きいメンバーで、自身の技術や経験において自信がありそれがチーム内での声の大きさに直結しているパターンである。また、周りのメンバーもゴリラのスキルについては認めているケースが多い。 ゴリラがいるとどういう問題がおきるか。まず第１にゴリラの存在はチームのコミュニケーションフローを限定してしまう。具体的な例をいくつかあげよう。まず開発チームでのコミュニケーションは、ゴリラの言うことが絶対的、という空気になってしまう。ゴリラに対して誰も反論をせず、ゴリラはより自分の意見が正しいという思い込みが強くなり、この流れは加速する。結果、開発周りの意思決定がゴリラ中心となり、開発チームもそれに頼
スクラムを失敗させる51のアンチパターン - Qiita
スクラムは基本的にはスクラムガイドに背くことで失敗しやすくなります。 そんな中でもよくあるアンチパターンと一言解説をまとめました。 スクラムマスター(SM)の失敗 SMがDevを兼任する スクラムマスターの仕事はそうなくならない どちらかの作業が片方の作業のボトルネックになる Devとしての作業量が不安定でベロシティを計画のために利用しづらくなる SMがPOを兼任する POとSMはそれぞれの責任に関する作業のみでボトルネックになりやすい 時にはPOの立場（プロダクト寄りの視点）とSMの立場（チーム寄りの視点）がコンフリクトを起こすこともある SMがチームに奉仕していない サーバント・リーダーシップがない SMはチームが抱えるあらゆる障壁の解消に努める（全部自分でやらずとも周りと話をするなど） SMがチームをマイクロマネジメントしている マイクロマネジメントは自己組織化につながらない チーム
コードレビューにおけるレビュアー側のアンチパターン
tl;drコードレビューが上手く回って無くてチームが疲弊して辛かったよレビュアーの言い方を変えるだけで大体解決するよ立場とかで例外を許さず、みんながレビューしてレビューされると良いよはじめにあるプロジェクトでGitHubのPRベースでのコードレビューを導入をしました。いかんせんチーム開発が初めてレベルの新人さんが多く、何かと苦労しました。特にレビュイーに対して不効率な指摘はそのまま指示の不明確さに繋がり、チーム全体の開発生産性を下げるので、レビュアーはレビュイー以上に気を使う必要があると感じました。下手をすると、レビュイーのメンタルが弱って闇堕ちするので、チームメンバーの最も大人な人がメンタルケアしたりします。大人な人は大体がリーダー格なので、その人の時間が奪われると何かと開発現場が疲弊しちゃいますね。コードレビューってそんなに難しいものだっけと思ったりもしますが、反省の意味も込めて実際に
「なんちゃってアジャイル」15のアンチパターン | Biblichor - scent of classics
ユーザーメリットを早期に実現するため、迅速かつ適応的にソフトウェア開発を行う「アジャイル開発」。 うまく実施できれば素晴らしい力を発揮するのだが、ややもすると「なんちゃってアジャイル」に陥ってしまうことも…。 過去のプロジェクトの経験から、プロジェクト進行のなかで陥りがちな「なんちゃってアジャイル」の罠と、それを引き起こすカンチガイの原因についてまとめてみた。 チーム環境 "なんちゃってスクラム"編 「アジャイル開発」に必須なのが、チームメンバーが協働で目標に向かうための環境づくり。 以下のことが起きていたら要注意。 1. プロジェクトの目標があいまい プロジェクトの目標について、プロダクトオーナーとスクラムマスターで言っていることが違う場合は要注意。 2. リリース時期が決まっていない プロジェクトのリリース時期が決まっていない場合や、簡単に変更になる場合は要注意。 ずるずると「リリース
PHPカンファレンス2016でRDBアンチパターンの話してきた #phpcon2016
全国のそーだいふぁんのみなさん、お久しぶりです。 1ヶ月ほど更新がなかったのですが私は元気です。 表題の通り、PHPカンファレンス2016に遊びに行ってきたのでそのご報告です。 当日のスライドはこちら 今回はRDBアンチパターンということで以下の内容を話して来ました。 またスライドだけでは言葉足らずなので補足記事書きました。 下のリンクで補足記事に行けます 強すぎる依存 隠された状態 ロックの功罪 スライドだけでは説明しきれないのでぜひ動画を見てほしいです PHP Conference 2016 Track2 のyoutubeみつけた。RDBアンチパターンの動画が見たい方はこちら！ >> https://t.co/HuEGceG9sB — そーだい＠初代ALF (@soudai1025) 2016年11月4日 それと当日のTwitterまとめ DBの寿命はアプリよりも長い！DBを救える英雄
ORMは不快なアンチパターン | To Be Decided
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
Selenium Antipatterns
http://seleniumjp.connpass.com/event/24206/ 第3回日本Seleniumユーザーコミュニティ勉強会の資料です。 Seleniumのアンチパターンについてです。Read less
PostgreSQLアンチパターン
37. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 38. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users ON users.id = blog.user_id AND users.delete_flag = 0 WHERE blog.delete_flag = 0 ユーザの削除フラグを見る 39. 積み重なるWHERE句 -- 有効なアカウントのブログを取ってきたい場合 SELECT * FROM blog INNER JOIN users
ORM anti-pattern series
We as developers tend to apply the same techniques to solve every problem thrown at us. We learn a new design pattern and all of a sudden that pattern is all...We as developers tend to apply the same techniques to solve every problem thrown at us. We learn a new design pattern and all of a sudden that pattern is all over our codebase. We find a new way of writing code and we apply it wherever we c
Codeigniterでwebアプリをつくる時にやらかしちゃった5つのアンチパターン｜リレーションデザイン研究所
気づいたら、私が「CakePHP」ではなく「CodeIgniter」を選んだ３つの理由を書いてから早1年。ということは、Codeigniterを使い出してから1年経ってました。本当、時間が流れるのは早い・・・。 そこで、この1年間にやらかしちゃったアンチパターン（そして、リファクタリングに無駄に時間をかけてしまった）を5つご紹介します。 １．Modelでデータ処理をしない（sql関連のみにしちゃう） 最初、Modelはデータベースと接続するソケット的イメージをしていました。そうなるとどうなるかというと、例えば生徒の「名簿」と「成績」を取得する時に、Modelを以下のように用意して、それをControllerでforeachで回してくっつける、みたいなことをしちゃうのです。 モデル [php] function 名簿(){ $sql = "SELECT * FROM 名簿"; $query
TddAntiPatterns - TDD のアンチパターン
TddAntiPatterns - TDD のアンチパターン 目次 この文書について TDD のアンチパターン TDD アンチパターン・カタログ 嘘つき。 (The Liar) セットアップ過多 (Excessive Setup) 巨人 (The Giant) モック酔い (The Mockery) 検査官 (The Inspector) 太っ腹な残り物 (Generous Leftovers) 地元の英雄 (Local Hero) 小姑 (The Nitpicker) 秘密のキャッチ (The Secret Catcher) ペテン師 (The Dodger) 大声 (The Loudmouth) はらぺこキャッチ (The Greedy Catcher) 序列屋 (The Sequencer) 隠れ依存 (Hidden Dependency) 点呼 (The Enumerator)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Service-Based Antipatterns
SQLアンチパターン 幻の第26章「とりあえず削除フラグ」
MySQLアンチパターン
RDBアンチパターン // Speaker Deck
新入社員向け MySQL 研修その 7 My MySQL アンチパターン
James Carr
ORM anti-patterns - Part 1: Active Record
Getting Testy: Anti-Patterns