質問する技術何が良くなかったのか？

teratailに質問して回答がつかなかった質問が2つあります。

上記の質問はなぜ回答がつかなかったのか、どのように質問していれば回答がついたのか。
今後のために、よろしければご指摘をいただけませんでしょうか。

kazto

2018/04/27 02:20

タグはメタな内容なので、「teratail」がいいと思います。

退会済みユーザー

2018/04/27 02:25

ご指摘ありがとうございます、修正いたしました。

行動規範の内容に同意します

回答7件

回答者の負担が大きいからかと。
リンク先を見ましたが「回答したくなる質問ではない」と見て感じました。

ここは基本的に
「したいことがあってこう書いたが思っている動作と違う」
みたいな内容が簡潔で「ここが違うよ！」と言えるので向いていると思います。

「AのコードがいいかBのコードがいいかはたまたそれ以外か」のような質問や
「私の理解があっているのか」みたいな質問は回答者にとっては割とどうでもいいです。そんなものは自分で調べるべきかと。

投稿2018/04/27 02:21

sousuke

総合スコア3828

TSの方、回答してみました。

回答したモチベーションは、TypeScriptの質問に回答してみたい！というものでした。

当該質問は、読むのが少し大変でした。
理由として考えられるのは、

序盤に、回答者にとっていらない情報が多め
前提条件、もっと減らしたいところです。前提条件最初の注釈は気持ちは分かるのですが、ちょっとノイズです。これは「背景」という項を立てて、最後にかいてはどうでしょう。またSentryとか言ってしまうと、「TypeScriptかつSentry」な人じゃないと見たくなくなります。自分のピンポイントな目的に絞って質問した方が読みやすそうです。
結局どうしたいかが読み取りづらかったです
動けばいいのか、作法を知りたいのか、etc...。「3つのうちどれがいいですか」といっても、観点がなかったので。作法を知りたいのであれば、コードも文もより簡潔に、かつ比較しやすいよう似た形に並べたほうが良いです。参照元のコピペになっていて、本質と異なるノイズが多く感じました。(sayHelloとかいらないんですよね？)

という感じです。

偉そうな文になっているところあるかと思いますが、ご容赦いただきたく存じます。

投稿2018/04/27 05:07

退会済みユーザー

総合スコア0

退会済みユーザー

2018/05/02 07:24

jjj_aaa様　TypeScriptへのご回答ありがとうございました。おかげさまでTSの仕様について知ることもでき大変ためになりました。

行動規範の内容に同意します

私にはこう見えましたという点しか答えられませんが、何人か回答があればそれなりのものになると思い回答します。

問いが明確でない。
なんとなく直してとお願いしているんだけどどこを気にしているのかわからない。

情報が多すぎる。
かなりそのままのコードが乗っているので、腕まくりしないと回答できない。回答者は私も含め酔っぱらって話し相手を求めているおっさんよりましな程度の人が多い印象です。もう少し単純化させた方が良いと思います。

回答しても他の人が見ない
趣味でやっていることなので、純粋にコードの書き方のテクニックであれば喜びますし、ピンポイントの質問であれば、”これに応えられる俺すげぇ”といった感じで回答ができます。質問者だけに回答するのであればお仕事と同じだと感じます。

投稿2018/04/27 02:52

iwamoto_takaaki

総合スコア2883

退会済みユーザー

2018/04/27 09:11

呼びましたか？

iwamoto_takaaki

2018/04/27 09:31

luckerさんは、飲みながら書いていることもあるんでしたっけ・・・酔っ払いまでいっちゃうとさすがにまずいかと思いますが、自分の回答も後で読み返すと正気ではない場合があり反省しております。（オブジェクト指向とかDB設計あたりが感情的になる傾向が・・・）

行動規範の内容に同意します

内容が専門的で回答できる方がいらっしゃらない
ソースコード全貼りは、コードレビューの手間がしんどいので回答したがらない

今回の場合、上記の2点が該当するかな、という印象です。

どう改善したらいいか、は、難しいですね。。。
内容が専門的なのはどうしようもないですし、全貼りじゃなく一部だったら意味が通じなくなるでしょうし。

投稿2018/04/27 02:19

kazto

総合スコア7196

m.ts10806

2018/04/27 02:25 編集

私は1つ目の質問に対して答えられる技術を持っているわけではないですがザッと読んだ感じ無責任で申し訳ないですが「そこまでできてるなら割とすぐに自分で解決できそう」と感じました。

dodox86

2018/04/27 02:56

「HMACを使用したWeb API認証」に関して私もかなり限定的な技術トピックに思われ、答えられる方はそうはいらっしゃらないだろうなと感じました。参照されていたサイトの記事も英語なので、同じQ&AサイトでもStackoverflowならあるいは、と思いました。

退会済みユーザー

2018/05/02 07:25

dodox86様　確かに英語で質問を行った方がよさそうですね。StackOverFlowとQuoraを使用してみようと思います。

行動規範の内容に同意します

TypeScriptでカスタムエラークラスを作成する方法について
HMACを使用したWeb API認証

2点とも回答できる技術レベルがなかったからです！

HMACの方は秘密鍵を送る点が違いますが、パット見た感じは仮想通貨の取引所のAPI認証とほぼ同じ事をやっているように見えました。
あと「レビュー」という言葉にはレビュアーの責任がどうしても発生するので、気楽に回答しずらいのではと。

投稿2018/04/27 03:08

umyu

総合スコア5846

ベストアンサー

改善点

JavaScript - TypeScriptでカスタムエラークラスを作成する方法について(114258)｜teratail

上記スレで改善できる点は下記の通り。

質問の見通しが悪いと思いました。
(Typoraのようなアウトライン表示できるmarkdownエディタなら一定の合理性がありますが、teratailでは読みにくくて仕方ありません。)
「前提条件」が多すぎると思いました。他の方がコードを書く上で不要な情報は極力排除すべきと思います。べき論であれば、メリット/デメリットで事実が伝われば十分です。

以上を踏まえた質問文案を下記に示します。

質問文案

質問

TypeScriptでカスタムエラーの3つの実装方法を記載しました。
自分ならXXXなのでこれを選ぶ、あるいはもっといい方法があるというようなご意見をいただきたいです。

コード

TypeScript
1/**
2 * (1) Errorをimplementsするクラスを作成する
3 * @url https://books.google.co.jp/books?id=8m5qBgAAQBAJ&lpg=PP1&dq=isbn%3A4798139807&hl=ja&pg=PA195#v=onepage&q=ApplicationError&f=false
4 */
5class ApplicationError implements Error {
6    public name = 'ApplicationError';
7
8    constructor(public message: string, public code: ApplicationErrorCode) { }
9
10    toString() {
11        return `${this.name}: ${this.message}`;
12    }
13}
14
15/**
16 * (2) Errorをextendsするクラスを作成する
17 * @url https://github.com/Microsoft/TypeScript-wiki/blob/master/Breaking-Changes.md#extending-built-ins-like-error-array-and-map-may-no-longer-work
18 */
19class FooError extends Error {
20    constructor(m: string) {
21        super(m);
22
23        // Set the prototype explicitly.
24        Object.setPrototypeOf(this, FooError.prototype);
25    }
26
27    sayHello() {
28        return "hello " + this.message;
29    }
30}
31
32/**
33 * (3) Errorをカスタムするのではなく,throwをカスタムしてすべてErrorを使用する
34 * @url https://www.htmlhifive.com/
35 */
36
37/**
38 * フレームワークエラーを発生させます。
39 *
40 * @private
41 * @param code {Number} エラーコード
42 * @param msgParam {Any[]} フォーマットパラメータ
43 * @param detail {Any} 追加のデータ(内容はAPIごとに異なる)
44 */
45function throwFwError(code, msgParam, detail) {
46
47        .....
48
49    if (code) {
50        e.code = code;
51    }
52    if (detail) {
53        e.detail = detail;
54    }
55
56    throw e;
57}

各手法のメリット/デメリット

Errorをimplementsするクラスを作成する
Errorをextendsするクラスを作成する

Errorをextendsするクラスを作成する

手法	メリット	デメリット
1	アプリケーションの例外とJSの例外が分別できる( ネイティブのError 型は聖域として扱い、この種の例外を決してスローしないようにしよう。カスタム例外をApplicationError クラスのサブクラスとして作成すれば、本当に例外的な状況においてコードの外側で使用するためにError型を取っておくことができる。)	スタックトレースが取れない。子クラスを作るたびにnameを書かないといけない(何らかの方法で解決できるのかもしれないが自分は分からない)
2	スタックトレースが取れる	`Object.setPrototypeOf` を忘れたり誤ったりすると`instance instanceof FooError`がfalseになる。 TypeScript, Javascriptの仕様変更によって壊れる可能性が1より高い(実際にTypeScript2.1で壊れた)
3	全てのエラーはErrorなのでインターフェースが統一されている。 codeがenumであればdiscriminated unionsによって型の推論ができる。	TypeScriptだとグローバルのError型定義を拡張しなければならない。使用する側が気を付けなければならない。

前提条件

Javascript(TypeScript)では極力例外を投げるのは避けるべきとは思っている
サポート対象ブラウザはChrome,FireFox,Safariの最新版のみ。デバイスはPC, タブレット, スマートフォン。
TypeScriptを使用したSPA. ソースコード50000行ほど、ファイル数680 今後2倍くらいになりそう
フロントエンド監視にはSentryを使用している
JavascriptのErrorを拡張して,エラー種別の判別とSentryでのバグトラッキングに活かしたい(エラーコードを設けたり、エラー種別によってエラーハンドリングを変えたり)

(※ここはどう省略すべきか不明な為、オリジナルのままです。)

Re: u28epGUsk さん

投稿2018/04/29 15:13