質問編集履歴

5

追記

2019/01/14 19:09

投稿

kaggle
kaggle

スコア17

test CHANGED
File without changes
test CHANGED
@@ -22,7 +22,7 @@
22
22
 
23
23
  変更や拡張を見越したコードは書くべきでは無いと考えました。
24
24
 
25
- 保険などのシステムと同様の考えで、可能性がある以上、そのリスクに応じた変更や拡張を見越したコードを書くと言うコストを払った場合、
25
+ 保険などのシステムと同様の考えで、今後の変更や、拡張が生じてくる可能性がある以上、そのリスクに応じた変更や拡張を見越したコードを書くと言うコストを払った場合、
26
26
 
27
27
  総合的に結果がよくなることが多いと考えるからです。
28
28
 

4

追記

2019/01/14 19:08

投稿

kaggle
kaggle

スコア17

test CHANGED
File without changes
test CHANGED
@@ -22,6 +22,10 @@
22
22
 
23
23
  変更や拡張を見越したコードは書くべきでは無いと考えました。
24
24
 
25
+ 保険などのシステムと同様の考えで、可能性がある以上、そのリスクに応じた変更や拡張を見越したコードを書くと言うコストを払った場合、
26
+
27
+ 総合的に結果がよくなることが多いと考えるからです。
28
+
25
29
 
26
30
 
27
31
  改めて如何でしょうか。

3

追記

2019/01/14 19:08

投稿

kaggle
kaggle

スコア17

test CHANGED
File without changes
test CHANGED
@@ -10,4 +10,26 @@
10
10
 
11
11
 
12
12
 
13
+ **[追記]**
14
+
15
+ 皆さんの回答をみて、再度検討しましたところ、
16
+
17
+ **今後の変更や、拡張が生じてくる可能性があると決まっている**以上、
18
+
19
+ その期待値が高ければ高いほど、より変更や拡張を見越したコードを書くべきだと考えました。
20
+
21
+ 一方、例えば、一回のリリースで終了のシステムであり、要件定義で変更や拡張を見越したコードを要求されていないと決まっている場合、
22
+
23
+ 変更や拡張を見越したコードは書くべきでは無いと考えました。
24
+
25
+
26
+
27
+ 改めて如何でしょうか。
28
+
29
+
30
+
31
+
32
+
33
+
34
+
13
35
  よろしくお願い致します。

2

わかりやすいタイトルにした

2019/01/14 18:47

投稿

kaggle
kaggle

スコア17

test CHANGED
@@ -1 +1 @@
1
- KISS(Keep It Simple,Stupid)やYAGNI(You Aren't Going to Need it.)の原則は、変更や拡張性を無視したコードになか。
1
+ KISS(Keep It Simple,Stupid)やYAGNI(You Aren't Going to Need it.)の原則は、変更や拡張性を無視したコードを意味するか。
test CHANGED
File without changes

1

タイポ

2019/01/13 13:42

投稿

kaggle
kaggle

スコア17

test CHANGED
File without changes
test CHANGED
@@ -2,7 +2,7 @@
2
2
 
3
3
  今必要なコードをだけを書けばいいと言う人がいます。
4
4
 
5
- 今後の変更や、拡張が生じてくる可能性はクライン次第で、
5
+ 今後の変更や、拡張が生じてくる可能性はクライ次第で、
6
6
 
7
7
  あるとも言えるが、決まっていないと言う条件下であるとき、
8
8