そろそろコードレビューそのものの必要性について考えるときがきているのかもしれない - タオルケット体操
技術ブログの方に書くか迷ったのですが、かなりポエムの類な文章になりそうなのでこちらに書きます。 ちょっと前にバズったこちらの記事 medium.com に触発されました。 ちなみにコードレビューに関する話としてはまだ僕が色々と手探りだった3年前にもこんなことを書いていたようです。3年前の自分の考えに触れられるブログって面白いなという気持ちとこいつどんだけ軽率な文章書いてんだよという気持ちが合わさり甘酸っぱい気持ちが生み出されました。 hachibeechan.hateblo.jp 当時と今では日本全体の技術的トレンドも変わっていますし、そもそも僕の所属している会社も違います。今の会社ではGitHubを使っており、コードレビューが当然のフローとして組み込まれています。 そしていま改めて当時のブログを読み返したのですが、びっくりするほどコードレビューに対する僕の考えが変わっていないので、改めて
Reactive Systems と Back Pressure
5. なぜReactiveが必要なのか • さまざまな非同期イベントを扱う機会が増えている。 − GUI − マイクロサービス − ビッグデータ解析 − ノンブロッキングI/O • 複雑になりがちな非同期処理をきれいに書きたい。 → Reactive Programming • 性能がよく、柔軟性・耐障害性の高いシステムをつくりたい。 → Reactive Systems 6. Promise/Futureではダメなのか？ • ReactiveもPromise/Futureも非同期処理を扱うための手段。 • Promise/Futureが主に1回きりのイベントを取り扱うのに対して、 Reactiveではイベントストリームを扱う。 • Promise/Futureの強み − 言語によっては async/await が利用できる。 − 標準で利用できるケースが多い。 • Reactiveの強み
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
