回答編集履歴
3
微修正
answer
CHANGED
|
@@ -67,7 +67,7 @@
|
|
|
67
67
|
- 資産 → **テスト**を書くなどして、プログラム全体を使いやすくしていく
|
|
68
68
|
- 負債 → **その場しのぎ**の修正を繰り返し、全体が分からなくなっていく
|
|
69
69
|
|
|
70
|
-
テスト、ロギング、例外処理、UML、ドキュメント……などを書く。
|
|
70
|
+
解説：テスト、ロギング、例外処理、UML、ドキュメント……などを書く。
|
|
71
71
|
これらは手間は掛かりますが、プログラムを使いやすく、資産化していきます。
|
|
72
72
|
|
|
73
73
|
一方、動けばいいやと**場当たり的な修正を繰り返す**だけだと、
|
2
リファクタリングの部分を微修正
answer
CHANGED
|
@@ -36,7 +36,7 @@
|
|
|
36
36
|
また、仕様を理解する点において、**英語**と**数学**は大きな武器です。
|
|
37
37
|
たとえば流行の機械学習でも、このふたつが理解する武器になるでしょう。
|
|
38
38
|
|
|
39
|
-
英語と数学は、最新のプログラム言語やフレームワークよりも、
|
|
39
|
+
英語と数学は、最新のプログラム言語やフレームワーク（FW）よりも、
|
|
40
40
|
陳腐化が確実に遅いです。おそらく**一生使える**技術でしょう。
|
|
41
41
|
|
|
42
42
|
一方、言語やFWはひどいときには、流行した来年には、もうオワコンになっている。
|
|
@@ -57,6 +57,7 @@
|
|
|
57
57
|
|
|
58
58
|
この『リファクタリング』を最近読み直したら、実装の書き方にとどまらず、
|
|
59
59
|
設計的にもドメインモデリングしていることに気づき、あらためて感心しました。
|
|
60
|
+
OOPで書くとどういうコードになるのか、という良いサンプルでもあります。
|
|
60
61
|
|
|
61
62
|
また、Javaでは、「**デザインパターン**」の本も良いと思います。
|
|
62
63
|
|
1
用語の微修正
answer
CHANGED
|
@@ -28,7 +28,7 @@
|
|
|
28
28
|
**バグ**は仕様とコードの差から生じます。
|
|
29
29
|
|
|
30
30
|
だから、**仕様とコードを対応させる**必要があります。
|
|
31
|
-
最近普及してきたDDDなども、コードを
|
|
31
|
+
最近普及してきたDDDなども、コードをドメインの言葉に合わせていく技法です。
|
|
32
32
|
|
|
33
33
|
仕様の理解には、自分の専門分野の知識、**業務知識**が大事です。
|
|
34
34
|
典型的なのはたとえば、会計の知識や統計の知識とかがそうです。
|
|
@@ -99,11 +99,11 @@
|
|
|
99
99
|
まとめると上記が、典型的な**技術的負債を溜め込むアンチパターン**です。
|
|
100
100
|
|
|
101
101
|
逆に今回、技術的資産にした方は、どれも**イニシャルコスト**が高いものです。
|
|
102
|
-
英語や数学が典型的ですが、学習コストが掛かります。
|
|
102
|
+
英語や数学が典型的ですが、学習コストが掛かります。オブジェクト指向も難しい。
|
|
103
103
|
初期コストが高いと避けがちなので、ずっと身につかないままという場合も多い。
|
|
104
104
|
|
|
105
105
|
だから、**「継続は力なり」**で、筋の良いやり方がたとえ難しくても、
|
|
106
106
|
たとえ忙しくてできない期間があっても、細く長く続けて学んでいくことが重要になります。
|
|
107
107
|
|
|
108
108
|
一日や二日では効果を実感できなくても、一年や二年も経つと大差になります。
|
|
109
|
-
結論をまとめると、**「急がば回れ」**、**「ウサギとカメ」**
|
|
109
|
+
結論をまとめると、**「急がば回れ」**、**「ウサギとカメ」**です。昔からの真理。
|