質問編集履歴
5
パフォーマンスの意味について「性能」という意味になるように明記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
とある技術系ブログっぽいところで、とある人の意見で「パフォーマンスが遅くなることをわかっていてその技術を採用することはプロとして失格」というのを見たことがあります。でも、実際はパフォーマンスと生産性はトレードオフの関係になっていて、必ずしも実行速度最速を選ぶことが最適とは限らないと思っています。
|
|
1
|
+
とある技術系ブログっぽいところで、とある人の意見で「パフォーマンス(性能)が遅くなることをわかっていてその技術を採用することはプロとして失格」というのを見たことがあります。でも、実際はパフォーマンス(性能)と生産性はトレードオフの関係になっていて、必ずしも実行速度最速を選ぶことが最適とは限らないと思っています。
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
@@ -20,7 +20,7 @@
|
|
|
20
20
|
|
|
21
21
|
|
|
22
22
|
|
|
23
|
-
そこで、質問です。実際に作るときに、どこまでパフォーマンスを求めるべきなのでしょうか？たとえば、とある新サービスのWebシステムを作るにあたって、
|
|
23
|
+
そこで、質問です。実際に作るときに、どこまでパフォーマンス(性能)を求めるべきなのでしょうか？たとえば、とある新サービスのWebシステムを作るにあたって、
|
|
24
24
|
|
|
25
25
|
|
|
26
26
|
|
4
技術系担当者の立場について明確にした
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -52,7 +52,7 @@
|
|
|
52
52
|
|
|
53
53
|
|
|
54
54
|
|
|
55
|
-
予算を超えてでもSにすべきか、予算内でなるべく最高にすべくAにすべきか、仕様さえ満たすのだから、経費削減のためにBをすべきか、実際流行るかどうかわからないため、とりあえず作ってから考えるためにCでやっちゃうかです。なお、ただのプログラマーの立場では無く、プランを選ぶ顧客や経営者の立場、または、そのような人に意見を述べる技術系担当者の立場であるという想定でお答えください。また、見積もりはあくまで想定であり、実際に作ったら想定以上になることもあり得ます。そういった、リスクも込みでお考えください。
|
|
55
|
+
予算を超えてでもSにすべきか、予算内でなるべく最高にすべくAにすべきか、仕様さえ満たすのだから、経費削減のためにBをすべきか、実際流行るかどうかわからないため、とりあえず作ってから考えるためにCでやっちゃうかです。なお、ただのプログラマーの立場では無く、プランを選ぶ顧客や経営者の立場、または、そのような人への意思決定に影響を与える形で意見を述べるまたは決定権を与えられた技術系担当者の立場(CIOまたは実質的なCIOである立場、外部からの場合はコンサルやSIerのような立場)であるという想定でお答えください。また、見積もりはあくまで想定であり、実際に作ったら想定以上になることもあり得ます。そういった、リスクも込みでお考えください。
|
|
56
56
|
|
|
57
57
|
|
|
58
58
|
|
3
比較としては意味があるが、数値自体には意味が無いと言うこと
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -76,4 +76,4 @@
|
|
|
76
76
|
|
|
77
77
|
* 想定や見積もりについて
|
|
78
78
|
|
|
79
|
-
あくまで例だと思ってください。工数や秒数とかは適当ですので深い意味はありません。状況としては、これから企画として立ち上げ予算取りや仕様決めをする段階だと思ってください。想定平均応答時間と想定工数も確定した物では無く、最初にこれぐらいだといいなーと思ったぐらいの値です。Sプランの工数もCプランの平均応答時間も戦略的には許容できる範囲内という感じです。実際はサーバの台数やスペックだとか、保守・運用やソフトウェア(OSやDB等)の料金とかそういうのも総合的に判断する必要がありますが、話を簡単にするために、そういった物を省いています。
|
|
79
|
+
あくまで例だと思ってください。工数や秒数とかは適当ですので、大きさの比較以外に深い意味はありません。状況としては、これから企画として立ち上げ予算取りや仕様決めをする段階だと思ってください。想定平均応答時間と想定工数も確定した物では無く、最初にこれぐらいだといいなーと思ったぐらいの値です。Sプランの工数もCプランの平均応答時間も戦略的には許容できる範囲内という感じです。実際はサーバの台数やスペックだとか、保守・運用やソフトウェア(OSやDB等)の料金とかそういうのも総合的に判断する必要がありますが、話を簡単にするために、そういった物を省いています。
|
2
数ヶ月も前じゃ無かった・・・あんまり言うと特定されるから控えよう
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -72,7 +72,7 @@
|
|
|
72
72
|
|
|
73
73
|
状況としては「○○はパフォーマンスが悪い、パフォーマンスが悪い技術を使うのはレベルが低い素人、なので、○○を使うのは素人」という感じの発言です。記事全体としては、[コレ](http://qiita.com/raccy/items/5358a94da7913717008d)に相当するような内容なので、皆さんにお教えするような価値はありません。
|
|
74
74
|
|
|
75
|
-
ただ、ここ
|
|
75
|
+
ただ、ここ２〜3ヶ月ほどパフォーマンスの良さ/悪さについて考えさせられたきっかけであり、そこからこの質問に繋がった事でもあるので、最初に記述させていただきました。
|
|
76
76
|
|
|
77
77
|
* 想定や見積もりについて
|
|
78
78
|
|
1
補足を追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -53,3 +53,27 @@
|
|
|
53
53
|
|
|
54
54
|
|
|
55
55
|
予算を超えてでもSにすべきか、予算内でなるべく最高にすべくAにすべきか、仕様さえ満たすのだから、経費削減のためにBをすべきか、実際流行るかどうかわからないため、とりあえず作ってから考えるためにCでやっちゃうかです。なお、ただのプログラマーの立場では無く、プランを選ぶ顧客や経営者の立場、または、そのような人に意見を述べる技術系担当者の立場であるという想定でお答えください。また、見積もりはあくまで想定であり、実際に作ったら想定以上になることもあり得ます。そういった、リスクも込みでお考えください。
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
---
|
|
60
|
+
|
|
61
|
+
【補足】
|
|
62
|
+
|
|
63
|
+
|
|
64
|
+
|
|
65
|
+
皆さん共通の疑問点などを補足します。
|
|
66
|
+
|
|
67
|
+
|
|
68
|
+
|
|
69
|
+
* 「プロ失格」について
|
|
70
|
+
|
|
71
|
+
荒れている記事がさらに荒れる事になりますので、出典は明記しません。また、一字一句同じというわけでは無く、そのようなニュアンスだったと言うことです。ですので、ググっても引っかかりません。
|
|
72
|
+
|
|
73
|
+
状況としては「○○はパフォーマンスが悪い、パフォーマンスが悪い技術を使うのはレベルが低い素人、なので、○○を使うのは素人」という感じの発言です。記事全体としては、[コレ](http://qiita.com/raccy/items/5358a94da7913717008d)に相当するような内容なので、皆さんにお教えするような価値はありません。
|
|
74
|
+
|
|
75
|
+
ただ、ここ数ヶ月ほどパフォーマンスの良さ/悪さについて考えさせられたきっかけであり、そこからこの質問に繋がった事でもあるので、最初に記述させていただきました。
|
|
76
|
+
|
|
77
|
+
* 想定や見積もりについて
|
|
78
|
+
|
|
79
|
+
あくまで例だと思ってください。工数や秒数とかは適当ですので深い意味はありません。状況としては、これから企画として立ち上げ予算取りや仕様決めをする段階だと思ってください。想定平均応答時間と想定工数も確定した物では無く、最初にこれぐらいだといいなーと思ったぐらいの値です。Sプランの工数もCプランの平均応答時間も戦略的には許容できる範囲内という感じです。実際はサーバの台数やスペックだとか、保守・運用やソフトウェア(OSやDB等)の料金とかそういうのも総合的に判断する必要がありますが、話を簡単にするために、そういった物を省いています。
|