LINTの重要さから、TDDというスキルから得られるメリットを理解する。

1. LINTから理解するTDD

2. イントロ

3. プログラムは完成する時まで、全容を把握で
きない。

4. プログラムは完成する時まで、全容を把握で
きない。

5. 仕様に従ったユニットテストを通ったプログ
ラムは、仕様通りに動くことが担保される。

6. いくら書き換えても・・・

7. こう書くべきって言うプログラマが
いたらそいつはアマチュア

8. 結論

9. TDDは仕様チェックのLINTを作りながら開発
すること。

10. 身に付ければ、
Notepadでの開発
↓
vscodeでの開発
と同レベルのスキルアップが
可能

11. 色々事実を並べてみる。

12. コンパイルしたプログラムは高確率で動く

13. なぜ?

14. VSCODEで書いたプログラムは高確率でコン
パイルが通る

15. eclipseで書いたプログラムも高確率でコンパ
イルが通る

16. notepadで書いたプログラムも高確率でコン
パイルが通るか?

17. プログラムの品質
VSCODEで書いたプログラム
notepadで書いたプログラム
VSCODEで書いたプログラム
VS
notepadで書いたプログラム
VSCODEで書いたプログラム
※コンパイルが通るかどうか

18. VSCODEで書いたプログラムのコンパイルが
通る確率が高い(よくて同等)

19. なぜか？

20. コンパイルを通す前にエディ
タがエラーを教えてくれるか
ら

21. Notepadは、変数名の誤字すら教えてくれな
い。

22. エディタのエラー消しながらプログラム書け
ば、コンパイルエラーは起きない。

23. コンパイルが通ったプログラムは、それだけ
でそこそこ動くことが保証される。

24. 機能が正しいかはわからないけど・・・

25. じゃあ

26. プログラム書きながら
仕様エラーをチェック
出来たら良くない?

27. 仕様をチェックするLINTを作ろう!

28. でも、仕様はプロジェクトによって違うから
どこにも売ってない・・・

29. じゃあ、仕様をテストするツール作りましょ
う。

30. とりあえず、プログラム書くまえにチェック
ツール作る。

31. これがテストファースト

32. リファクタリング

33. 元の機能を変えずにソースを修正する行為

34. 機能追加

35. 元の機能を変えずにソースに機能を追加する
行為

36. 元の機能を変えずに
ソースを修正する

37. 数値A,B,Cがあった時、A+BをCで割った結果
を返す

38. Public int func(int a ,int b,int c){
return (a+b)/c;
}
数値A,B,Cがあった時、A+BをCで割った結果
を返す

39. Cが0の時計算できない！

40. Cが０の時はa+bを返す仕様を追加

41. Public int func(int a ,int b,int c){
If (c=0) return a+b;
return (a+b)/c;
}
数値A,B,Cがあった時、A+BをCで割った結果
を返す
Cが０の時はA+Bを返す

42. 数値A,B,Cがあった時、A+BをCで割った結果
を返す
これを維持したまま
プログラム修正！

43. 仕様追加はしない→リファクタリング

44. Public int func(int a ,int b,int c){
Int x = a+b;
If (c=0) return x;
return x/c;
}
数値A,B,Cがあった時、A+BをCで割った結果
を返す
Cが０の時はA+Bを返す

45. 数値A,B,Cがあった時、A+BをCで割った結果
を返す
Cが０の時はA+Bを返す
これを維持したまま
プログラム修正！

46. ほぼ新規のソースでも書いた瞬間から、「元
の機能」を意識する

47. プログラムを書くうえで、
「元の機能」
を維持することは必須

48. でも

49. 「元の機能」を維持するのは・・・

50. つらい・・・

51. なぜなら

52. いつ維持できなくなるかわか
らない

53. どうやって維持したらいいか
わからない

54. というか・・・

55. 今維持できているか
すらわからん!

56. じゃあ、コンパイルできないかもって思いま
すか?

57. まともな言語なら(jsとかは除く)

58. まともなエディタなら(notepad除く)

59. コンパイルが通らない不安はない

60. 修正しながらチェックできるから!!

61. 元の機能を維持してることをチェックしなが
ら開発しよう!

62. TDD!!!

63. 実はもう一個逃げ道があります

64. 「元の機能」を維持するのはつらい

65. 「元の機能」って何?

66. いつ決まる?どこにある?設計書?

67. っていうか、作ってる途中に今の機能とか気
にしなければ、そんな不安なくない??

68. じゃあ

69. 作り終わるまでテストしなきゃいいじゃん

70. 出来上がってから、修正するからバグるんだ
よね

71. リファクタリングしなくていいように、最初
から完璧なプログラム書けばいいじゃん

72. 他との整合性?
パーフェクトなソースなんてない?

73. じゃあ

74. それっぽい思想、カッコ良さそうな手法、
過去の(自分だけの)経験を基に、
こうあるべき!
を主張する能力を身に付けよう!

75. アホか・・・

76. プロなら

77. 今の状態がわかる

78. 安全に手直しができる

79. そんな状態をちゃんと作ってから

80. 仕事しよう

81. その為のスキルが

82. TDD!!!

83. でも余計なテストを書く時間はない(泣)

84. 大丈夫

85. 迷いながら書くプログラムは思った以上遅い!

86. 単に、迷わずに作ったプログラムは早いけど

87. 出来上がったものは・・・

88. 思い込みの塊

89. 迷わなくていい状態を整えて書くスピードは
思った以上に早い!

90. TDDは

91. プログラムの
「品質」と「スピード」を
両立させるスキルです!