却下できる人が承認することに意味がある - 余白
コードレビューに限らず、いろいろなレビューがいろいろなプロセスに組み込まれている。 だが、レビューにおいて、たとえ内容に瑕疵があっても承認されるなら、そのレビューは単なる形式・儀式に過ぎない。 "何かを保障するためのプロセス"としてのレビューを機能させることを目的とするなら、そこには却下の可能性があることが必要条件だ。 保障: ある状態がそこなわれることのないように、保護し守ること。(https://kotobank.jp/word/%E4%BF%9D%E9%9A%9C-630029) 却下と批判的立場 そのようなレビューにおいて、レビュアーは「これは承認しても大丈夫か」と思考する。 「承認しても大丈夫だ」という確信を得るということは、裏返せば「却下すべき理由がない」という確信を得ることである。 その確信が得られるのは「却下すべき理由を探したが見つからなかった」ときである。 つまりレビュア
読後メモ: 『あなたのチームは、機能してますか？』 - 余白
久々に読後メモを書きます。今回読んだのはパトリック・レンシオーニ著『あなたのチームは、機能してますか？』です。 あなたのチームは、機能してますか？ 作者:パトリック・レンシオーニ発売日: 2003/06/18メディア: 単行本 きっかけ この本のことを知ったのはTwitterで及川卓也さんが好きな本として触れていたから。 と書いたところで、私の好きな「あなたのチームは、機能してますか？」の中のキャスリンはCEOとして着任した会社の経営陣からそのようにまったく思われていなかったことを思い出した。成果はリーダーとしてアサインされた後で作り上げていくことも可能ということだろう。https://t.co/KVMgBpeSvc— 及川卓也 / Takuya Oikawa (@takoratta) 2021年1月18日 THE CULTURE CODEもそうだが、チームを機能させるというトピックにはい
謙遜しないと決めている話 - 余白
僕は誰かに褒められたとき、謙遜しないようにしている。 褒められたら「ありがとうございます」「嬉しいです」「照れます」と、はっきり言葉で喜びを示す。 これを心がけはじめた最初のころは意識的だったけど、最近では意識しなくても自然にそう振る舞えるようになった。 これまで何人かに、「それいいですね」と言われることがあって、そういえばこの自分ルールについてちゃんと言葉にしたことがなかったなと思ってこの記事を書いている。 褒めたいと思ったあなたを否定しない 「謙遜しない」というルールの根幹は、「褒めたいと思ったあなたを否定しない」ということ。 褒めてもらったことが、自分が本当に認められたいことではないときもある。あるいは、何気なくやったことで自分ではそれほど価値を感じていないことのときもある。 それでも、相手が自分を褒めたいと思ったそのことはその人にとって疑いようのない事実である。「そう思った」という
GraphQLとRESTfulについて今日考えてたこと Backend for Usecase/Resourceについて - 余白
DISCLAIMER: これは本当にただのメモ書きで、これがベストプラクティスだとかいう話ではないので、同じようなことを考えてる人いたら今度議論しましょうよ、って程度の話の種。 GraphQLを使うべきスポット、RESTfulが好ましいスポットについて今日ぼんやり考えていて、なんとなく言語化ができる気がするので文字起こししてみる。 Backend for UsecaseとBackend for Resource バックエンドのAPIには2種類あって、 「データ」を構成する「リソース」を提供するもの アプリケーションの「ユースケース」がもつシナリオのなかで登場する「データ」部分を埋めるためのもの を区別することが必要そう、と思っている。 まず前者を Backend for Resource (BFR)と呼ぶことにする。これはわかりやすくて、これはまさしくRESTfulそのもの。 RDBやそう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
