principles post fixed

Author: maciej-nowak

_drafts/2019-10-07-solid.md

@@ -190,7 +190,7 @@ class NotesView() {
 
     fun init() {
         notes.add(AudioNote("audio", "description", File("audio.mp3"), "transcription"))
-        notes.add(VideoNote("video", "description", File("video.mp4"), File("subtitlex.txt")))
+        notes.add(VideoNote("video", "description", File("video.mp4"), File("subtitles.txt")))
         notes.add(TextNote("text", "description", "content"))
     }
 
@@ -252,7 +252,7 @@ class NotesView() {
 
     fun init() {
         notes.add(AudioNote("audio", "description", File("audio.mp3"), "transcription"))
-        notes.add(VideoNote("video", "description", File("video.mp4"), File("subtitlex.txt")))
+        notes.add(VideoNote("video", "description", File("video.mp4"), File("subtitles.txt")))
     }
 
     fun playNote(index: Int) {

_drafts/2019-10-28-kiss.md

@@ -32,7 +32,7 @@ class NumberManager(private var number: Int) {
     }
 }
 
-class numbermanager(private var mNumber: Int) {
+class number_manager(private var mNumber: Int) {
 
     companion object {
         const val oneHundred = 100
@@ -182,6 +182,37 @@ object OrderUtilsFixed {
 }
 {% endhighlight %}
 
+## YAGNI
+Reguła `YAGNI` (`You Ain't Gonna Need`) mówi o tym, aby w momencie tworzenia kodu umieszczać w nim tylko to co jest lub będzie na pewno potrzebne. Zastosowanie reguły po części realizuje zasadę `KISS`, tzn. niepotrzebny i nieużywany kod mógłby utrudnić zrozumienie projektu. Istnieje spora szansa, że nieużywane fragmenty i funkcjonalności, które powstają przy okazji realizacji innych zadań w przyszłości mogą być zupełnie niepotrzebne lub wymagania zmienią się na tyle, że wymuszą zmianę implementacji. W związku z czym pisanie kodu na przyszłość (np. zestawu funkcji walidacyjnych) może okazać się stratą czasu. Biorąc pod uwagę zasady `KISS` i `YAGNI` należy zastanowić się nad bilansem zysków i strat dla wprowadzania rozwiązań uniwersalnych bez istnienia żadnych alternatywnych typów w momencie tworzenia.
+
+{% highlight kotlin %}
+object Validator {
+
+    //at this moment there is only need to valid password and email
+    //for register and login purpose
+    
+    fun isPasswordValid(password: String): Boolean {
+        val pattern = Pattern.compile("^(?=.*[A-Z])(?=.*[a-z])(?=.*[0-9]).{6,}$")
+        val matcher = pattern.matcher(password)
+        return matcher.matches()
+    }
+
+    fun isEmailValid(email: String): Boolean {
+        val pattern = Pattern.compile("^.+@.+\\..+$")
+        val matcher = pattern.matcher(email)
+        return matcher.matches()
+    }
+
+    //don't make polish phone number validator, it costs time to create regex
+    //there is no need to use it in app at this moment
+    fun isPhoneNumberValid(number: String): Boolean {
+        val pattern = Pattern.compile("(?<!\\w)(\\(?(\\+|00)?48\\)?)?[ -]?\\d{3}[ -]?\\d{3}[ -]?\\d{3}(?!\\w)")
+        val matcher = pattern.matcher(number)
+        return matcher.matches()
+    }
+}
+{% endhighlight %}
+
 ## Testowanie
 Dobra praktyką w metodyce testów jest testowanie jak najmniejszej jednostki. W trakcie tworzenia przypadków testów dąży się do uproszczenia problemów do zadań atomowych. Im mniejsze i prostsze metody testowe tym lepiej dla jakości testów. 
 
@@ -240,35 +271,4 @@ class ValidatorTestFixed {
 {% endhighlight %}
 
 ## Dokumentacja
-Dokumentacja projektowa również powinna być tworzona w taki sposób, aby była zrozumiała dla potencjalnych odbiorców. Na jej podstawie programista powinien być zdolny do zastosowania funkcjonalności i ewentualnego rozszerzenia projektu. Niewątpliwie dobrze i prosto napisany interfejs znacznie ułatwia tworzenie zrozumiałej dokumentacji.
-
-## YAGNI
-Reguła `YAGNI` (`You Ain't Gonna Need`) mówi o tym, aby w momencie tworzenia kodu umieszczać w nim tylko to co jest lub będzie na pewno potrzebne. Zastosowanie reguły po części realizuje zasadę `KISS`, tzn. niepotrzebny i nieużywany kod mógłby utrudnić zrozumienie projektu. Istnieje spora szansa, że nieużywane fragmenty i funkcjonalności, które powstają przy okazji realizacji innych zadań w przyszłości mogą być zupełnie niepotrzebne lub wymagania zmienią się na tyle, że wymuszą zmianę implementacji. W związku z czym pisanie kodu na przyszłość (np. zestawu funkcji walidacyjnych) może okazać się stratą czasu. Biorąc pod uwagę zasady `KISS` i `YAGNI` należy zastanowić się nad bilansem zysków i strat dla wprowadzania rozwiązań uniwersalnych bez istnienia żadnych alternatywnych typów w momencie tworzenia.
-
-{% highlight kotlin %}
-object Validator {
-
-    //at this moment there is only need to valid password and email
-    //for register and login purpose
-    
-    fun isPasswordValid(password: String): Boolean {
-        val pattern = Pattern.compile("^(?=.*[A-Z])(?=.*[a-z])(?=.*[0-9]).{6,}$")
-        val matcher = pattern.matcher(password)
-        return matcher.matches()
-    }
-
-    fun isEmailValid(email: String): Boolean {
-        val pattern = Pattern.compile("^.+@.+\\..+$")
-        val matcher = pattern.matcher(email)
-        return matcher.matches()
-    }
-
-    //don't make polish phone number validator, it costs time to create regex
-    //there is no need to use it in app at this moment
-    fun isPhoneNumberValid(number: String): Boolean {
-        val pattern = Pattern.compile("(?<!\\w)(\\(?(\\+|00)?48\\)?)?[ -]?\\d{3}[ -]?\\d{3}[ -]?\\d{3}(?!\\w)")
-        val matcher = pattern.matcher(number)
-        return matcher.matches()
-    }
-}
-{% endhighlight %}
+Dokumentacja projektowa również powinna być tworzona w taki sposób, aby była zrozumiała dla potencjalnych odbiorców. Na jej podstawie programista powinien być zdolny do zastosowania funkcjonalności i ewentualnego rozszerzenia projektu. Niewątpliwie dobrze i prosto napisany interfejs znacznie ułatwia tworzenie zrozumiałej dokumentacji.