回答編集履歴
4
追記
test
CHANGED
|
@@ -32,7 +32,7 @@
|
|
|
32
32
|
|
|
33
33
|
どの方法にもデメリットはありますが、例えば、
|
|
34
34
|
|
|
35
|
-
- マイクロアーキテクチャ的な作りにして、強制的に機能の独立性を担保して飛び火しないようにする
|
|
35
|
+
- マイクロアーキテクチャ的な作りにして、強制的に機能の独立性を担保して(問題のあるコードが)飛び火しないようにする
|
|
36
36
|
|
|
37
37
|
- ユニットテストのカバレッジ目標を100%にして（100%にするのはデメリットも大きいですが）テストの作りやすいコードを強制することで、結果としてクソ長いコードを却下する
|
|
38
38
|
|
3
追記
test
CHANGED
|
@@ -58,7 +58,7 @@
|
|
|
58
58
|
|
|
59
59
|
サーバスペックは（質問から想像する限りですが）規模に比べてかなり潤沢に思いますので、
|
|
60
60
|
|
|
61
|
-
選択
|
|
61
|
+
言語選択とは関係無いものと考えて良いです。
|
|
62
62
|
|
|
63
63
|
（それで速度が遅いのはDBにインデックスが正しく貼られていないとか正規化出来てないとかそういうレベルな気がするのですが、その辺ってどうなんでしょうか。）
|
|
64
64
|
|
|
@@ -66,4 +66,6 @@
|
|
|
66
66
|
|
|
67
67
|
その構成でボトルネックになり得るのは1TBのHDD（恐らくSASでは無くSATA？)くらいでしょうから、これをSSDに変えるくらいは考えても良いかもしれませんね。
|
|
68
68
|
|
|
69
|
+
|
|
70
|
+
|
|
69
|
-
教育コストに比べればはるかに安い投資で変更出来るかと思います。
|
|
71
|
+
教育コストに比べればはるかに安い投資で変更 or 追加出来るので、検討すると皆が幸せになれるかもしれません。（保守契約とかの関係で超高くなる場合もあるとは思いますが。）
|
2
表現修正
test
CHANGED
|
@@ -1,3 +1,9 @@
|
|
|
1
|
+
回答
|
|
2
|
+
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
|
|
1
7
|
> また、１メソッドに数百行とか書かれてしまいそうな危険性もある。
|
|
2
8
|
|
|
3
9
|
|
|
@@ -8,15 +14,41 @@
|
|
|
8
14
|
|
|
9
15
|
|
|
10
16
|
|
|
11
|
-
逆に言うと、そ
|
|
17
|
+
逆に言うと、それを含めて教育出来るか、コードレビューで機械的にはじけるようなルールを整備出来ればどの選択肢でも大差ないので、決定権者の好みで選択しちゃっても良いと思います。
|
|
12
18
|
|
|
13
19
|
強いて言うなら、ルールを作りやすい慣れた言語が良いかもしれません。
|
|
14
20
|
|
|
15
21
|
|
|
16
22
|
|
|
23
|
+
アーキテクチャや規約でなんとかする方向性
|
|
24
|
+
|
|
25
|
+
---
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
教育とは別の方向性としては、アーキテクチャや規約で何とかする方向性もあります。
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
どの方法にもデメリットはありますが、例えば、
|
|
34
|
+
|
|
35
|
+
- マイクロアーキテクチャ的な作りにして、強制的に機能の独立性を担保して飛び火しないようにする
|
|
36
|
+
|
|
17
|
-
|
|
37
|
+
- ユニットテストのカバレッジ目標を100%にして（100%にするのはデメリットも大きいですが）テストの作りやすいコードを強制することで、結果としてクソ長いコードを却下する
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
と言った感じで問題コードの生産を抑制する方法を模索し、その方法が実行しやすいかどうかという観点で言語選択をする。
|
|
18
42
|
|
|
19
43
|
(それで数百行のコードを書く人のメンタルがやられたりすることもあるので、とっても難しい問題ではあります。)
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
気になった点
|
|
50
|
+
|
|
51
|
+
---
|
|
20
52
|
|
|
21
53
|
|
|
22
54
|
|
1
追記
test
CHANGED
|
@@ -14,7 +14,9 @@
|
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
もしくは、マイクロアーキテクチャ的な作りにして、強制的に機能の独立性を担保して飛び火しないようにするとかで
|
|
17
|
+
もしくは、マイクロアーキテクチャ的な作りにして、強制的に機能の独立性を担保して飛び火しないようにするとか、ユニットテストのカバレッジ目標を100%にして（100%にするのはデメリットも大きいですが）テストの作りやすいコードを強制するとかそういう具体的な問題コードの生産を抑制する方法を模索する必要があると思います。
|
|
18
|
+
|
|
19
|
+
(それで数百行のコードを書く人のメンタルがやられたりすることもあるので、とっても難しい問題ではあります。)
|
|
18
20
|
|
|
19
21
|
|
|
20
22
|
|