Pomyślcie sobie gdy idziecie do lekarza i strasznie was coś boli. Macie wizytę, doktor bada i opukuje i finał finałów: chcielibyście dostać informacje że lekarz nie wie i zaleca wizytę u specjalisty, czy lepiej żebyście dostali witaminę C, podczas gdy np. wasze oko wygląda jak u osób zarażonych wirusem H1Z1? Ja wybieram opcje 1. Oszczędzam swój czas, swoją nadzieję że to co dostałem mnie wyleczy i oszczędzam reputację lekarza u którego byłem, bo na pewno wrażeniami z leczenia podzielę się z innymi.
Ostatnio powiedziałem: “nie wiem, nie mogę tego zrobić, to jest poza moim poziomem wiedzy” – i wiecie co, świat się nie skończył. Zadanie dotyczyło wyznaczania jakichś standardów technicznych w miejscu gdzie pracuje. Oczywiście mogłem dorzucić swoje trzy grosze, ale pomyślałem że lepiej nie wtykać nosa tam gdzie nie mam nic mądrego do powiedzenia. Gdybym się wymądrzał, mówił rzeczy które mogą nie mieć sensu, kręcił, etc. wtedy robota którą miałem dostarczyć byłaby nie fajna. Standardy, które wyznaczyłem byłyby nie fajne. wrażenia innych po przeczytaniu standardów byłyby nie fajne.
Jasne, każdy z nas chciałbym zrobić coś ciekawego i ważnego – ja też. Czasami jednak przychodzi moment, że coś mnie (nas wszystkich) przerasta. Możemy wtedy zrobić dwie rzeczy: wziąć na siebie odpowiedzialność i spierdolić sprawę śpiewająco; budżet, czas, reputacja, nerwy, zdrowie, co tam jeszcze można. Lub! Lub zagrać w otwarte karty: nie dam rady, potrzebuje kogoś innego do pomocy, albo w ogóle się na tym nie znam, musicie znaleźć kogoś innego.
Sami zgadnijcie która postawa jest bardzie pro.
Następnym razem postaram się bardziej technicznie napisać.
filozoficznie
Posłuchaj klienta
Jeśli klient chce statycznego HTML za kilka minut, nie dostarczaj mu dynamicznego kodu, z pętlami, partialami czy różnymi warstwami za godzinę – za późno.
Jeśli klient chce Abyś wygenerował te notatki w kontrolerze za kilka minut – nie produkuj repozytorium, nie zaprzęgaj dependency injection za godzinę – za późno.
Jeśli klient chce edycji tylko swoich wpisów i możliwości edytowania tylko tytułu czy tekstu, to dostarcz tylko tyle, nie podmieniaj całego modelu – za późno, źle i za dużo.
Pamiętaj, lepiej mieć coś co spełnia wymagania klienta powoli, niż coś co nie spełnia ich szybko.
Posłuchaj swojego klienta, zapytaj jeśli czegoś nie rozumiesz, zaproponuj jeśli uważasz że coś może być zrobione lepiej. Ale pamiętaj, że to jego biznes i to on wie jak robić na tym pieniądze.
Continous Code Retreat
Byliście kiedyś na CodeRetreat? Bardzo fajna impreza, której ideą jest pisanie kodu w możliwe najlepszy sposób. Na koniec dnia nie trzeba dostarczyć produktu, przede wszystkim trzeba poznać nowe sposoby na rozwiązywanie tego samego problemu. Oczywiście w trakcie trwania imprezy, żeby nie było za nudno, mistrz ceremonii rzuca pod nogi kolejne kłody: krótkie metody, brak ifów, brak czegoś innego, itp-itd, fajna sprawa która powoduje, że uczestnik ciągle poszukuje, a przez to poznaje nowe różne rozwiązania. Często okazuje się, że ograniczenia które były wprowadzana, wymuszały chwilę rozmyślenia jak napisać kawałek kodu inaczej, a to powodowało dużo lepszy kod. Do czego zmierzam? Otóż po pierwsze primo, już za nie długo odbędzie się kolejna już edycja Global Day of Coderetreat we Wrocławiu, po drugie primo: takie ograniczenia z code retreat można wprowadzić sobie w życie także w pracy w normalnym projekcie. Otóż na każde rozpoczęcie sprintu lub tygodnia, można ustalić reguły: np. w tym tygodniu decydujemy się, że metody nie mogą przekroczyć np. siedmiu linijek, albo nie używamy typów prostych, wersja dla profesjonalnych graczy: nie używamy if’ów, etc. Dlaczego? W ten oto prosty sposób, możemy nie jako wymusić na swoich kolegach pisanie lepszego kodu, nie trzeba im wtedy mówić, o SOLID, czy dobrych praktykach, czy czymś innym, po prostu ustalacie wspólnie, że to i tamto i przez tydzień macie taką “grę”, potem retrospekcja i nowe reguły, nowe doświadczenia, nowy tydzień i nowe reguły i znowu retrospekcja – aż wszyscy zrozumieją jak pisać dobrze. Tym sposobem i sprint przyjemniejszy i kod lepszy. Takie moje luźne myśli na kolejny tydzień.
.net developers days – myśli zebrane
Tym razem udałem się do warszawy na konferencje .net developers days i zrobiłem sobie słit focie ze Scottem – yey! yey! yey!
Wiem, mam zamknięte oczy (smuteczek) Ale! Ze Scottem!!! Mam jeszcze jedno, ale tak niewyraźne, że nie uwierzycie że to ja.
A teraz część z myśli, które zebrałem słuchając różnych wykładów i rozmyślając też o różnych rzeczach podczas słuchania:
Nie mieszać klas które służą do czystego przechowywania danych oraz tych, które na nich operują. Powinno to ułatwić skalowalność systemu, utrzymanie systemu, jest też spora szansa na to że system stanie się mniej stanowy, a przez to mniej awaryjny.
Value objects z DDD to fajna sprawa, nawet jeśli nie korzysta się z pełnego dobrodziejstwa które oferuje ddd, to warto wprowadzić przynajmniej część. Duża zaletą jest to że string który może się kryć z User.Firstname oraz User.Address i który normalnie możemy ze sobą porównać, nagle stanie się nie porównywalny ponieważ stringa ukryjemy w klasie UserAddress, a stringa odpowiedzialnego za Firstname ukryjemy w klasie UserFirstname i pomimo tego że w środku są to stringi, to dla kompilatora będą to dwie zupełnie inne typy, przez co nie da się ich ze sobą porównać. Dodatkową zaletą jest to, że podczas definiowania parametrów metody, czytelniej będzie czytać foo(UserFirstname name, UserAddress address){…} niż foo(string name, string address){…}
Dostając projekt, wymagania, nowego klienta, etc możemy się wkurzać na wiele rzeczy, naprawdę wiele. Ale warto sobie zdać posiedzieć przez chwilę i pomyśleć. Znaleźć wszystkie rzeczy, które są dla nas/was/mnie denerwujące, następnie podzielić je na dwie grupy: 1-mogę to zmienić, 2- nie mogę tego zmienić. I teraz wszystkie dwójeczki lądują w kuble, skoro nie można tego zmienić, to się trzeba przyzwyczaić. A wszystkie 1 lądują na naszej tapecie i robimy tak, żeby było lepiej. Do dwójeczek nigdy nie wracamy i godzimy się z losem jaki nas/was/mnie spotkał. Podobną myśl powiedział mi kiedyś znajomy, nie przejmuj się rzeczami na które nie masz wpływu – świetnie działa.
Wszyscy jesteśmy ludźmi i musimy się pogodzić z tym, że czasem coś nam nie wyjdzie – musimy się z tym pogodzić. Nie warto zakładać, że wszystko co robimy skończy się spektakularnym sukcesem i nie każdy z nas skończy tak jak Marek Zuckerberg czy inne Grycanki. Czasem słońce, czasem deszcze – takie jest życie.
Wszyscy jesteśmy ludźmi i musimy się pogodzić z tym, że czasem coś nam nie wyjdzie – musimy się z tym pogodzić. Nie warto zakładać, że wszystko co robimy skończy się spektakularnym sukcesem i nie każdy z nas skończy tak jak Marek Zuckerberg czy inne Grycanki. Czasem słońce, czasem deszcze – takie jest życie.
Jeśli prowadzicie retrospekcje, gdzie programiści mogą się spotkać i porozmawiać o tym co się udało, co było dobre, co się sprawdza, ale i to co się nie udało, co złe, co się nie sprawdza (patrz punkt poprzedni). To samo dotyczy menadżerów projektu, oni także mają swoje przemyślenia (tak tak, oni też myślą). Jeśli macie takie spotkania, to może warto aby podzielić się decyzjami, przemyśleniami, ustaleniami, próbami, sukcesami i porażkami z resztą ludzi którzy z wami pracują w firmie. W ten sposób, może udało by się ustrzec przed najczęstszymi błędami, może decyzje które podejmujecie na nowy sprint okażą się nie najlepsze, ponieważ inny zespół już próbował, a może dostaniecie wskazówki na co warto zwrócić uwagę próbując nowego rozwiązania. Dzielenie się wiedzą jest sexi!
Input w obiekcie na poziomie konstruktora – ? Co ja miałem na myśli? Walidacja? Zagadka – stawiam że tak. Jak sobie przypomnę to dopiszę.
Breakstorming – fajna pomysł nie tylko dla testerów. Pracujecie w zespole? Spotkajcie się od czasu do czasu, ale nie za rzadko i zróbcie sobie code review, gdzie główną ideą jest zepsucie kodu innego kolegi; na zasadzie: pacz Stefan, jak wyślę takie parametry i wystąpi taki warunek, to twój serwis rzuca wyjątkiem. Można wymyślać najbardziej złośliwe ścieżki, najmniej prawdopodobne do spełnienia, etc. Chodzi o możliwie najefektywniejsze wysadzenie jeźdźca z siodła
Breakstorming – fajna pomysł nie tylko dla testerów. Pracujecie w zespole? Spotkajcie się od czasu do czasu, ale nie za rzadko i zróbcie sobie code review, gdzie główną ideą jest zepsucie kodu innego kolegi; na zasadzie: pacz Stefan, jak wyślę takie parametry i wystąpi taki warunek, to twój serwis rzuca wyjątkiem. Można wymyślać najbardziej złośliwe ścieżki, najmniej prawdopodobne do spełnienia, etc. Chodzi o możliwie najefektywniejsze wysadzenie jeźdźca z siodła
Aplikacje webowe powinny być w stanie “zadziałać” bez połączenia z serwerem. Tak! Chodzi oczywiście o aplikację którą mamy już u nas, lub o taką która zaciąga statyczne html plus javascript, natomiast mięsko kryje się gdzieś głęboko na serwerach. Wtedy zamiast rzucania magicznymi kodami błędów, użytkownik powinien być w przyjazny sposób poinformowany, że nie da rady teraz wykonać tego trudnego zadania. Ale może popatrzeć na nasz spinner czy coś, który mówi: wiemy że nie działa i walczymy, próbuj dalej.
Nie ładować konfiguracji podczas wykonywania kodu – już spieszę ze szczegółami. Chodzi o przypadek, gdy ustawienia miałby być ładowane przez samą metodę podczas wykonywania kodu. Czyli mogłoby dojść do sytuacji, że metoda foo(“jarek”, “wrocław”){…} raz wykona logikę_1 a raz wykona logikę_2, ponieważ pomiędzy poszczególnymi wywołaniami metod, plik z konfiguracją został zmieniony i teraz zachowuję się inaczej. Prowadzi to do niespójności w aplikacji. Konfiguracja powinna być zaczytana raz na początku działania aplikacji i tyle. Aby zmienić ustawienia, należy wykonać restart aplikacji.
Nie ładować konfiguracji podczas wykonywania kodu – już spieszę ze szczegółami. Chodzi o przypadek, gdy ustawienia miałby być ładowane przez samą metodę podczas wykonywania kodu. Czyli mogłoby dojść do sytuacji, że metoda foo(“jarek”, “wrocław”){…} raz wykona logikę_1 a raz wykona logikę_2, ponieważ pomiędzy poszczególnymi wywołaniami metod, plik z konfiguracją został zmieniony i teraz zachowuję się inaczej. Prowadzi to do niespójności w aplikacji. Konfiguracja powinna być zaczytana raz na początku działania aplikacji i tyle. Aby zmienić ustawienia, należy wykonać restart aplikacji.
Dlannybecon – nie mam pojęcia co napisałem na kartce ^.^
Robiąc sobie zdjęcie ze Scottem :):):):) patrz na górze, doszły mnie słuchy, że przygotowywane są learniing box dla nowego asp i mvc na poziomie novice, regular, master – i powinny być oficjalnie dostępne w styczniu 2016 roku. Mają umożliwić samokształcenie jak i przygotowanie sesji dla innych ludzi. Wersje novice są chyba na mva. Nie szukałem więc nie posiadam linka.
Robiąc sobie zdjęcie ze Scottem :):):):) patrz na górze, doszły mnie słuchy, że przygotowywane są learniing box dla nowego asp i mvc na poziomie novice, regular, master – i powinny być oficjalnie dostępne w styczniu 2016 roku. Mają umożliwić samokształcenie jak i przygotowanie sesji dla innych ludzi. Wersje novice są chyba na mva. Nie szukałem więc nie posiadam linka.
Klasycznie czekam na komentarze lub nie zgody z moim rozumowaniem. Chętnie przyznam się do błędu jeśli taki popełniłem.
ps.
Poznałem fajny podcast:
Konferencja DevDay – moje złote myśli wyniesione
Byłem na DevDay2015!
Prezentacje były i można oglądać, albo będzie można wkrótce. Część ludzi spotkała się z ogromną ilością swoich fanów, inni leczyli kaca, inni słuchali i starali się coś z tego wyciągnąć. Jako że nie zapiłem, to starałem się coś mądrego usłyszeć, poniżej materiał zebrany i w mojej interpretacji:
Decyzje które podejmujesz podczas wybierania frameworka, biblioteki, pracownika, czy czegokolwiek innego powinieneś przemyśleć pod kątem, nie tylko rozwiązania, które przyniesie, a raczej odpowiedzialności, jaka zostanie na ciebie zrzucona. To nie wszystko, gdy znajdziesz rozwiązanie idealnie pasuje do twojego problemu, znajdź inne narzędzie które też rozwiąże ten problem i porównaj zady i walety obu. Upewnij się że ciężar wybranego przez ciebie rozwiązania jest akceptowalny. Jeśli chcesz być dobrym strategiem, architektem, rekruterem, pomyśl jakie problemy sprawi świeżo wybierana technologia i znajdź kolejne rozwiązanie tego problemu – uwaga na rekurencję.
TL;DR; decyzje które podejmujesz to nie tylko rozwiązanie, ale przede wszystkim konsekwencje
Każdy kod który tworzysz, nie zależnie czy jest to metoda, klasa, projekt, czy wszystko powinien być tak duży/mały aby rozwiązywał jeden i tylko jeden problem. Wiadomo SRP i takie. Ale jest jeszcze jedno spostrzeżenie: ten mały kod rozwiąże twój problem i fajnie, ale jeśli coś będzie z nim nie tak, wtedy kod psuć tylko tą jedną małą rzecz – nic więcej. SRP FTW! Ma ktoś taki tatuaż?
TL;DR; mały kod, małe projekty, małe serwisu. Jeśli będzie fakup, to rozwali tylko małą część twojej aplikacji lub systemu.
Wunderlist taka rozbudowana aplikacja todo – architektura opiera się o kilka(naście) technologi, każda klasa jest osobnym serwisem, komunikacja po http/rest. Rozwiązanie daje mega skalowalność, łatwo jest serwisy aktualizować, zmienić i wszystko. Całkiem interesujące podejście do całkiem sporego projektu. Bardzo mnie kusi bliższe poznanie jak to się robi, jak się z tym żyje i pracuje. Sama idea do mnie bardzo przemawia.
Poza tym, pogadałem i napiłem się piwa ze takie osobnikami jak Chris Heilmann,Scott Allen czy Chad Fowler – co też daje fajne wrażenia, że takie ważne osoby też piją piwo i też są ludźmi – kto by pomyślał. Oprócz nich poznałem kilka nowych osób, czy też dopoznałem innych.