ソフトウェアエンジニアが品質保証を学んでわかったこと / What software engineers have learned about quality assurance
![既存のAndroidアプリをリファクタリングしていく話](https://cdn-ak-scissors.b.st-hatena.com/image/square/9d2f66e3e37a00a9b82dcc314f38420289849523/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Ff8530c9d2e7743fa9fd1830f6ed12806%2Fslide_0.jpg%3F6532376)
さて、 Node.js のエラーハンドリングは難しいと言われてますが、 2016年現在、つまりNodeの v4 とか v6 が主流になり、 Promise が基本的な処理として採用されている状況ではどうでしょうか。ちょっと考えてみます。 一応これの補足です。 qiita.com TL;DR 未だに難しい。ただし、 Promise で改善されている。async-await や zone まで来たらかなり楽になる。 あと、 unhandledRejection が uncaughtException よりも酷いことにならないので、大分マシになっている。 Node.js のエラーハンドリングの難しさ まず JavaScript には同期と非同期のエラーハンドリングのやり方があります。前者は所謂 try-catch による方法、後者は callback を使って第一引数で実現する方法や emit(
プロダクトマネージャー Incrementsの「ソフトウェア開発をよくすることで世界の進化を加速させる」という企業ミッションを実現するために、技術者に対しての情報共有サービスの提供をエンジニアや他スタッフとともに進める。 IncrementsではエンジニアとともにQiitaやQiita:Teamを開発するプロダクトマネージャを募集します。 責任 マーケット状況の分析などを通じて、製品要求を製品要求仕様書(PRD:Product Requirements Document)と呼ばれる文書として整理する。 エンジニアやデザイナーなどから構成されるプロジェクトメンバーとともに製品のビジョンやロードマップ、戦略、チームのOKR (Objectives and Key Results)を決定する。 製品に対して機能やデザイン、実装技術などの提案を行い、必要に応じて実験を行うなどして、その妥当性の検証
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く