Czy ja jestem dziwna że lubię projektować kod?

Piszę właśnie mały kawałek, ogólnie wiem o co mi w nim chodzi, przetwarzanie pliku xml z w miarę ustrukturyzowanymi danymi, w których coś chcę automatycznie pozmieniać.
Piszę w języku, który jest bardzo dobry do przetwarzania plików tekstowych, czyli PHP (zaraz będzie hejt) ale podobną metodę stosuję też w innych przypadkach, w innych językach:
Najpierw tworzę obramowanie kodu - klasy, metody i pola w tych klasach, nie wypełniając ich treścią, tylko sygnaturki ze znaczącymi nazwami, typami zmiennych, rodzajem zwracanej wartości i komentarzami TODO. Na razie nie pisze ciał wszystkich funkcji, tylko kawałki, i w trakcie przemyśliwania zmieniam przygotowane obramowanie żeby było jak najporządniejsze. Czuję się jakbym w matematyce upraszczała skomplikowany wzór wyciągając przed nawias i mam z tego radochę. Oczywiście można tak robić wtedy jak się ma normalną presję czasową, a nie zap* że nie ma czasu taczek załadować (24 Polecam wszystkim książkę Ho... )
Czy ja jestem dziwna , czy Wy też tak macie?

Też to lubię, ale czasy gdzie pisało się kod z przyjemności i miało jednego taska na sprint bez potrzeby spowiedzi na daily już minęły.

Też to lubię. Nawet mam za to płącone, nawet jeśli wymaga to długoczasowego researchu. Finalnie firma dostaje rozwiązanie dostosowane do swoich potrzeb, może sobie je modyfikować. Jest szybkie i można je skalować. Przy okazji człowiek nabiera dużo doświadczenia, bo żeby zakończyć projekt, to trzeba dotknąć różnych rozwiązań i przetestować je z aktualnymi danymi. Część z nich trzeba odrzucić, ale zostają w cache'u głowy i czasem się do nich wraca w innych projektach.

Miang napisał(a):

Najpierw tworzę obramowanie kodu - klasy, metody i pola w tych klasach, nie wypełniając ich treścią, tylko sygnaturki ze znaczącymi nazwami, typami zmiennych, rodzajem zwracanej wartości i komentarzami TODO. Na razie nie pisze ciał wszystkich funkcji, tylko kawałki, i w trakcie przemyśliwania zmieniam przygotowane obramowanie żeby było jak najporządniejsze. Czuję się jakbym w matematyce upraszczała skomplikowany wzór wyciągając przed nawias i mam z tego radochę. Oczywiście można tak robić wtedy jak się ma normalną presję czasową, a nie zap* że nie ma czasu taczek załadować (24 Polecam wszystkim książkę Ho... )

Trochę to brzmi jak London School of TDD. Zamysł wydaje się ten sam, tylko że to jakby bieda wersja, bo nie ma testów. Czyli projektujesz te kształty i obramowanie "na czuja", zamiast z feedbackiem.

Ja np. lubię naprawiać bugi w moim edytorze i najwięcej mi to frajdy sprawia, oczywiście jak idzie to w miarę szybko :P Projektować tak średnio lubię, ale cieszę sie gdy jest postęp pracy :-)

To co piszesz to jest plan jakim chcę się kierować. W praktyce jednak jestem niecierpliwy, szukam dopaminy którą mi daje zielony test (lub rozwiązanie co da się jakkolwiek przeklikać), bo bez tego emocjonalnie nie czuję żadnego progresu.

Ok, tylko wiesz - czymś innym jest pisanie dla siebie - dla przyjemności, w wolnym czasie - kiedy możesz się bawić kodem, eksperymentować, testować różne warianty i różne sposoby i kiedy nie masz ograniczeń czasowych, a czymś innym kiedy to robisz w ramach pracy - gdy klient czeka na działającą aplikację, kiedy trzeba wykonać zadania i jechać z kolejnym tematem, bo inny zespół jest zblokowany póki Ty nie napiszesz swojego kawałka.

To trochę jak z trzymaniem w garażu Poloneza albo Syrenki i grzebanie sobie w nim w wolnym czasie. Super zabawa. Ale jakbyś tak samo podchodził(a) do pracy jako mechanik to szybko padniesz z głodu.

Jednym z największych problemów branży IT (jeszcze przed okresem boomu, bootcampami i braniem wszystkich z łapanki) było to, że było to hermetyczne środowisko dla pasjonatów. I ta granica między pasją/hobby a pracą się zacierała. Raczej nikt pracujący np. w sklepie nie traktuje tego jako hobby. Jakby kasjer z Lidla powiedział, że ma w piwnicy replikę kasy sklepowej i często tam wieczorem idzie, siada przy niej i nabija na kasę przetwory, które także trzyma w piwnicy - wszyscy by go uznali za wariata. Raczej w takiej pracy kończysz o godzinie 18, zmieniasz ciuchy, idziesz do domu i żyjesz swoim prywatnym życiem. Ale w IT to działa(działało?) inaczej - siedzisz przed ekranem w ciągu dnia i klepiesz kod jako pracownik, a po godzinach robisz z grubsza to samo - tylko jako pasjonat prowadzący jakieś własne projekty. Brakowało tego rozróżnienia na życie prywatne i służbowe (teraz modne hasło life-work balance) i przez ten brak granic można było oczekiwać od programistów więcej niż 8h etatu - bo przecież Oni/Wy to lubicie robić.

Sa generalnie dwa podejscia bottom-up i to co opisujesz czyli top-down. Wybor zalezy od tego na ile dobrze masz ustrukturyzowany problem. Jak wiesz oc i jak, zrobisz sensowny szkielet zapuscisz na to AIa to powinien nawet w miare sensownie miesko dopisac. AI jest beznadziejny do architektury ale kod pisze przyzwoicie. IMHO to projektowanei to jest ta trudniejsza czesc.

Ja zazwyczaj robie cos co jest dla mnie nowe, wiec ide od dolu, starajac sie jak najprosciej i jak najmniejszym wysilkiem osiagnac dzialajacy efekt. A pozniej ewentualnie, optymalizacja, clanup etc.

btw to co robisz brzmi jak XSLT :P

WhiteLightning napisał(a):

Wybor zalezy od tego na ile dobrze masz ustrukturyzowany problem.

No nie prawda. Zarówno outside-in jak i inside-out działają tak samo dobrze nie ważne czy masz ustrukturyzowany czy nieustrukturyzowany problem. Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Różnice pojawiają się: jak podatne jest to na refactor, jak uwidacznia niepoprawne integracje modułów, jak bardzo jest przywiązane do struktury, jak bardzo skłania do łamania YAGNI, etc.

Riddle napisał(a):

Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Nie wyobrażam sobie takiego podejścia w przypadkach, gdy nie wiem jak coś napisać. Przykładowo mam stworzyć serwer HTTP w Java EE albo piszę swoją pierwszą grę w Unity. W takich podejściach tak czy owak skończy się na jakimś tutorialu/templacie z którym będę eksperymentował

Riddle napisał(a):

No nie prawda. (...)

Wydaje mi się że jak pierwszy raz wkładasz ręce w konkretny biznes, to ciężko coś zaprojektować mimo wszystko. Ale może po prostu za cienki jestem :)

Riddle napisał(a):

WhiteLightning napisał(a):

Wybor zalezy od tego na ile dobrze masz ustrukturyzowany problem.

No nie prawda. Zarówno outside-in jak i inside-out działają tak samo dobrze nie ważne czy masz ustrukturyzowany czy nieustrukturyzowany problem. Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Różnice pojawiają się: jak podatne jest to na refactor, jak uwidacznia niepoprawne integracje modułów, jak bardzo jest przywiązane do struktury, jak bardzo skłania do łamania YAGNI, etc.

Srubokretem tez da sie gwozdzie przybijac ale mlotkiem latwiej. Nie zgodze sie z Toba, moje doswiadczenie jest inne. To by mialo sens tylko przy absolutnie czystym starcie, dzisiaj zawsze skladasz rozwiazanie z klockow, idac od dalo masz szybsza walidacje, co dziala, co nie, widzisz gdzie pojawiaja sie problemy do zaadresowania itp. Od gory mozesz isc jak robisz kolejny raz cos podobnego i wiesz co gdzie jak itp.

Też lubię niskopoziomowe tematy, optymalizacje, projektowanie i różnego rodzaju łamigłówki i problemy, ale nie płacą za to co się lubi, a jak samemu chce się zrobić szybko coś konkretnego i liczy się wynik a nie proces to niestety zazwyczaj optymalnie jest po prostu bezmózgowo pójść za tym co wypluje AI. Więc mogę stracić parę godzin / dni na projektowaniu czegoś lepszego ale to już nie to samo jak wiem że AI może zrobić coś porównywalnego w dużo krótszym czasie i nikt nawet nie doceni mojego wkładu, a nawet stwierdzi że straciłem czas. Okazji do projektowania czegoś samemu jest coraz mniej, już bardziej tylko do rozruszania szarych komórek jako zabawa sama w sobie, ale nie chcę mówić dzieciom "tatuś nie może się teraz pobawić bo robi overengineering czegoś co już działa".

Miang napisał(a):

Piszę właśnie mały kawałek, ogólnie wiem o co mi w nim chodzi, przetwarzanie pliku xml z w miarę ustrukturyzowanymi danymi, w których coś chcę automatycznie pozmieniać.

brzmi jak coś co AI by ukończyło w czasie w którym pisałaś tego posta

Miang napisał(a):

Piszę w języku, który jest bardzo dobry do przetwarzania plików tekstowych, czyli PHP (zaraz będzie hejt)

są lepsze języki do tego celu, powiedziałbym nawet że PHP to jeden z gorszych języków do tego; zastanów się szczerze czy piszesz w nim dlatego że jest "bardzo dobry do tego celu" czy dlatego że jedyny jaki dobrze znasz i nie chce ci się uczyć czegoś nowego?

Miang napisał(a):

Najpierw tworzę (...) sygnaturki ze znaczącymi nazwami, typami zmiennych, rodzajem zwracanej wartości

wybrałaś dynamicznie typowany język żeby tracić dodatkowo czas na opisywanie przyjmowanych i zwracanych typów?

A ja wam zazdroszczę, że potraficie programować Miałem Atari 65XE trchę basic-a umiem i TurboPascal-a chyba 6.0 bo o ile dobrze pamiętam 7.0 wyszło jakeś programowanie obiektowe i nie zdążyłem tego ogarnąć, praca dom rodzina
...edit... no i VBA

WhiteLightning napisał(a):

Riddle napisał(a):

WhiteLightning napisał(a):

Wybor zalezy od tego na ile dobrze masz ustrukturyzowany problem.

No nie prawda. Zarówno outside-in jak i inside-out działają tak samo dobrze nie ważne czy masz ustrukturyzowany czy nieustrukturyzowany problem. Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Różnice pojawiają się: jak podatne jest to na refactor, jak uwidacznia niepoprawne integracje modułów, jak bardzo jest przywiązane do struktury, jak bardzo skłania do łamania YAGNI, etc.

Srubokretem tez da sie gwozdzie przybijac ale mlotkiem latwiej. Nie zgodze sie z Toba, moje doswiadczenie jest inne. To by mialo sens tylko przy absolutnie czystym starcie, dzisiaj zawsze skladasz rozwiazanie z klockow, idac od dalo masz szybsza walidacje, co dziala, co nie, widzisz gdzie pojawiaja sie problemy do zaadresowania itp. Od gory mozesz isc jak robisz kolejny raz cos podobnego i wiesz co gdzie jak itp.

Tworząc aplikację outside-in również wykonujesz szybką walidację, również widać co działa a co nie, i również widzisz gdzie pojawiają się problemy. Przecież piszesz failujący test który potem przechodzi, więc widać że dostarczony kawałek działa tak jak powinien.

Jeśli masz jakiś konkretny przykład aplikacji w której Ci to nie pykło, to zapodaj przykład.

slsy napisał(a):

Riddle napisał(a):

Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Nie wyobrażam sobie takiego podejścia w przypadkach, gdy nie wiem jak coś napisać. Przykładowo mam stworzyć serwer HTTP w Java EE albo piszę swoją pierwszą grę w Unity. W takich podejściach tak czy owak skończy się na jakimś tutorialu/templacie z którym będę eksperymentował

Proszę bardzo, zacznij od tutorialu albo dokumentacji, żeby zebrać wiedzę. Nie mówię że pierwsza rzecz która masz zrobić w projekcie to test.

Ale @Miang mówiła że pisze kod na początku. Zauważyłem że jej sposób designu jest podobny do LondonTdd, i chciałem zasugerować że skoro już pisze kod, to siłą rzeczy musi wiedzieć coś. Chociaż żeby napisać ten pierwszy kawałek kodu. I to wystarczy żeby napisać test.

Riddle napisał(a):

WhiteLightning napisał(a):

Riddle napisał(a):

WhiteLightning napisał(a):

Wybor zalezy od tego na ile dobrze masz ustrukturyzowany problem.

No nie prawda. Zarówno outside-in jak i inside-out działają tak samo dobrze nie ważne czy masz ustrukturyzowany czy nieustrukturyzowany problem. Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Różnice pojawiają się: jak podatne jest to na refactor, jak uwidacznia niepoprawne integracje modułów, jak bardzo jest przywiązane do struktury, jak bardzo skłania do łamania YAGNI, etc.

Srubokretem tez da sie gwozdzie przybijac ale mlotkiem latwiej. Nie zgodze sie z Toba, moje doswiadczenie jest inne. To by mialo sens tylko przy absolutnie czystym starcie, dzisiaj zawsze skladasz rozwiazanie z klockow, idac od dalo masz szybsza walidacje, co dziala, co nie, widzisz gdzie pojawiaja sie problemy do zaadresowania itp. Od gory mozesz isc jak robisz kolejny raz cos podobnego i wiesz co gdzie jak itp.

Tworząc aplikację outside-in również wykonujesz szybką walidację, również widać co działa a co nie, i również widzisz gdzie pojawiają się problemy. Przecież piszesz failujący test który potem przechodzi, więc widać że dostarczony kawałek działa tak jak powinien.

Jeśli masz jakiś konkretny przykład aplikacji w której Ci to nie pykło, to zapodaj przykład.

Musisz wpiac usluge przez api, gdzie to api jest krzywe, zle opisane, zle udokumentowane itp. i wtedy tak naprawde musisz zrobic reverse engineering jak to zadziala, co zwroci, co mozna puscic sync/async itp. wiec wtedy robisz robote od prostego skryptu, w ktorym rozpoznajesz co i jak dziala a pozniej i dobudowujesz reszte. W przeciwnym przypadku zrobisz sobie cale srodowisko, prjekt, klasy, interfejsy, obiekty, mapowania itp. tylko sie okaze ze to sie nie spina z rzeczywistoscia.

WhiteLightning napisał(a):

Riddle napisał(a):

WhiteLightning napisał(a):

Riddle napisał(a):

WhiteLightning napisał(a):

Wybor zalezy od tego na ile dobrze masz ustrukturyzowany problem.

No nie prawda. Zarówno outside-in jak i inside-out działają tak samo dobrze nie ważne czy masz ustrukturyzowany czy nieustrukturyzowany problem. Można korzystać z obu, nawet jeśli piszesz aplikacje o której nie masz zielonego pojęcia.

Różnice pojawiają się: jak podatne jest to na refactor, jak uwidacznia niepoprawne integracje modułów, jak bardzo jest przywiązane do struktury, jak bardzo skłania do łamania YAGNI, etc.

Srubokretem tez da sie gwozdzie przybijac ale mlotkiem latwiej. Nie zgodze sie z Toba, moje doswiadczenie jest inne. To by mialo sens tylko przy absolutnie czystym starcie, dzisiaj zawsze skladasz rozwiazanie z klockow, idac od dalo masz szybsza walidacje, co dziala, co nie, widzisz gdzie pojawiaja sie problemy do zaadresowania itp. Od gory mozesz isc jak robisz kolejny raz cos podobnego i wiesz co gdzie jak itp.

Tworząc aplikację outside-in również wykonujesz szybką walidację, również widać co działa a co nie, i również widzisz gdzie pojawiają się problemy. Przecież piszesz failujący test który potem przechodzi, więc widać że dostarczony kawałek działa tak jak powinien.

Jeśli masz jakiś konkretny przykład aplikacji w której Ci to nie pykło, to zapodaj przykład.

Musisz wpiac usluge przez api, gdzie to api jest krzywe, zle opisane, zle udokumentowane itp. i wtedy tak naprawde musisz zrobic reverse engineering jak to zadziala, co zwroci, co mozna puscic sync/async itp. wiec wtedy robisz robote od prostego skryptu, w ktorym rozpoznajesz co i jak dziala a pozniej i dobudowujesz reszte. W przeciwnym przypadku zrobisz sobie cale srodowisko, prjekt, klasy, interfejsy, obiekty, mapowania itp. tylko sie okaze ze to sie nie spina z rzeczywistoscia.

Powtórzę to co napisałeś, żebyśmy się dobrze rozumieli, i dopowiem coś czego Ty nie dopowiedziałeś żebyśmy byli na tej samej stronie. Jeśli coś źle zrozumiałem to mnie popraw.

• Tworzymy aplikację, która ma robić coś użytecznego dla jego użytkownika, coś czego może użyć żeby sobie ułatwić życie. Za pewne jakiś problem statement, typu "chciałbym sprawdzić kurs wymiany walut EUR-USD" czy coś takiego. Zgadzamy się?
• Oceniamy, że jednym ze sposób na dostarczenie tego, będzie skorzystanie z zewewnętrznej usługi. Zgadzamy się? (Czyli już dochodzą dodatkowe komplikacje).
• Nie jesteśmy do końca pewni czy ta zewnętrzna usługa na pewno rozwiązuje nasz problem, O to Ci chodziło?
• Nie jesteśmy do końca w stanie przewidzieć ograniczeń które na nas nałoży, możliwe że zwróci dane z mniejszą/większą granularnością, w sposób w trudny do przewidzenia, i trudny do nałożenia na to odpowiedniej abstrakcji zanim się to pozna. O to Ci chodzi?
• Widzisz potencjalne ryzyko w tym, że zaczynanie od zaklepania takich interfejsów, nie znając contraintów jest ryzykowne i się nie opłaci. Zgadzamy sie? (Ja tutaj z tym też się zgadzam)
• Widzisz sens w tym żeby zrobić spike, żeby nauczyć się obsługiwać to API, i zaleczasz że warto od tego zaczać. Zgadzamy się? (Jak coś to z tym też się zgadzam).

Zgadzam się że "lepiej zacząć od czegoś co jest ryzykowne (jak to API), niż od czegoś co jest pewniejsze (jak wysokopoziomowa struktura)", ale to nie jest to samo co "lepiej zrobić inside-out niż outside-in".

• London school of TDD (tzw. mockist) polega na sterowaniu testami problem statementu od zewnątrz do środka, przy założeniu że wewnętrzne moduły (nie biorąc pod uwagę 3rd party) się dostarczą koniecznie zachowanie (co jest bardzo pewne).
• Chicago school of TDD (tzw. classist) polega na sterowaniu testami problem statementu od środka do zewnątrz, przy założeniu że odizolowane klocki w połaczeniu się zepną w sensowną całość (bo jest pewne tak pół na pół).

Możesz nie znać tego API w ogóle, możesz nie wiedzieć jak działa, możesz zrobić spike'a, i wszystkie te rzeczy które opisałem. Wszystko to możesz zrobić zarówno z outside-in tdd oraz inside-out tdd i to będzie działać w porządku.

Natomiast to że dodajesz do tego dodatkową komplikację, którą jest zewnętrzne API które może się będzie nadawało może nie, to jest rzecz odrębna od tych podejść; i tak czy tak pewnie należałoby ją wykonać jako pierwszą. Więc jak chcesz, to zrób spike'a, zwaliduj api i możesz jechać outside-in normalnie. To nie jest tak że jak chcesz stosowac LondonTdd to pierwsze co musisz zrobić to narysować wysokopoglądowy schemat (który najpewniej się okaże nieprawdziwy).

Popatrz na to od drugiej strony, ta aplikacja którą tworzysz, ona za pewne musi mieć jakąś logikę żeby być użytecznym (gdyby nie miała logiki to byłaby tylko głupim wrapperem na to API i wtedy nie ma sensu jakby jej tworzyć nawet, ktoś może po prostu użyć API). Więc pokryć testami akceptacyjnymi już na starcie możesz tą logikę którą chcesz. Nawet jakby to miało być sdk albo gui, to wtedy testy akceptacyjne pokrywają część sdk albo cześć gui. One będą użyteczne tak długo, jak projekt będzie utrzymywany. Nawet jak API się okaże że się nie nadaje całkowicie do tego celu, to powstałe testy i tak są użyteczne, bo najmniej konieczne będzie znalezienie innego API które spełnia potrzebe.

Jedyny case w którym te testy by się "nie opłaciły", to gdyby się miało okazać że API się nie nadaje do użytku i projekt jest zakończony, tylko tak jak mówiłem - wtedy nie znaczenia czy to jest inside-out czy outside-in, bo tak czy tak możesz zrobić spike'a żeby to ogarnąć.

@Riddle cos w tym stylu. Zeby moc budowac z klockow musisz je miec. Pytanie czy nie rozbijamy sie tutaj o kwestie nazewnictwa, dla Ciebie rozgryzienie interfejsu to bedzie spike, dla kogos innego POC, a dla mnie kawalek systemu ktory byc moze przerobie, dopasuje itp. ale ostatecznie gdzies zostanie wpiety wiec to jest budowanie od szczegolu. Czy daloby sie rozplanowac strukture od gory ? Pewnie tak, ale pracowalem kiedys w scislym waterfallu i to bylo straszne.

Ew. moze cos posredniego, jak dwie ekipy robia tory od dwoch stron :P Z jednej strony tworzysz sobie komponenty, z drugiej jarzmo do ktorego je wrzucisz i uzyjesz.

obscurity napisał(a):

Też lubię niskopoziomowe tematy, optymalizacje, projektowanie i różnego rodzaju łamigłówki i problemy, ale nie płacą za to co się lubi, a jak samemu chce się zrobić szybko coś konkretnego i liczy się wynik a nie proces to niestety zazwyczaj optymalnie jest po prostu bezmózgowo pójść za tym co wypluje AI. Więc mogę stracić parę godzin / dni na projektowaniu czegoś lepszego ale to już nie to samo jak wiem że AI może zrobić coś porównywalnego w dużo krótszym czasie i nikt nawet nie doceni mojego wkładu, a nawet stwierdzi że straciłem czas. Okazji do projektowania czegoś samemu jest coraz mniej, już bardziej tylko do rozruszania szarych komórek jako zabawa sama w sobie, ale nie chcę mówić dzieciom "tatuś nie może się teraz pobawić bo robi overengineering czegoś co już działa".

Miang napisał(a):

Piszę właśnie mały kawałek, ogólnie wiem o co mi w nim chodzi, przetwarzanie pliku xml z w miarę ustrukturyzowanymi danymi, w których coś chcę automatycznie pozmieniać.

brzmi jak coś co AI by ukończyło w czasie w którym pisałaś tego posta

tak, bo LLM to jest J.A.R.V.I.S który sam z siebie zgadanie co ma napisać ;)

Miang napisał(a):

Piszę w języku, który jest bardzo dobry do przetwarzania plików tekstowych, czyli PHP (zaraz będzie hejt)

są lepsze języki do tego celu, powiedziałbym nawet że PHP to jeden z gorszych języków do tego; zastanów się szczerze czy piszesz w nim dlatego że jest "bardzo dobry do tego celu" czy dlatego że jedyny jaki dobrze znasz i nie chce ci się uczyć czegoś nowego?

znaczy miałam użyć C albo Delphi. No bo javascript znam słabo. Chyba że może SQL albo R ?
zastanów się szczerze czy znasz PHP, na tyle żeby krytykować używanie go do czegoś innego niż CRUDy w Symfony

Miang napisał(a):

Najpierw tworzę (...) sygnaturki ze znaczącymi nazwami, typami zmiennych, rodzajem zwracanej wartości

wybrałaś dynamicznie typowany język żeby tracić dodatkowo czas na opisywanie przyjmowanych i zwracanych typów?

tak coś mi się wydaje że była tu niedawno jakaś podobna dyskusja tylko chodziło chyba o Pythona

WhiteLightning napisał(a):

@Riddle cos w tym stylu. Zeby moc budowac z klockow musisz je miec.

Pytanie czy nie rozbijamy sie tutaj o kwestie nazewnictwa, dla Ciebie rozgryzienie interfejsu to bedzie spike, dla kogos innego POC, a dla mnie kawalek systemu ktory byc moze przerobie, dopasuje itp. ale ostatecznie gdzies zostanie wpiety wiec to jest budowanie od szczegolu. Czy daloby sie rozplanowac strukture od gory ? Pewnie tak, ale pracowalem kiedys w scislym waterfallu i to bylo straszne.

Ew. moze cos posredniego, jak dwie ekipy robia tory od dwoch stron :P Z jednej strony tworzysz sobie komponenty, z drugiej jarzmo do ktorego je wrzucisz i uzyjesz.

Myślę, że mogą wyciągnąć ostrożnie wniosek że masz zaszczepioną mylną wizję nt tego co to znaczy "outside-in". Albo pewnie było tak jak mówiłeś, pracowałeś w waterfallu który ktoś nazwał że jest outside-in (a pewnie nie było), i to było dla Ciebie tak okropne doświadczenie (i wcale się nie dziwię) że nie chcesz ryzykować że spotka Cię coś podobnego znowu - wiem, ja miałbym tak samo.

Tylko że outside-in-tdd nie ma nic wspólnego z waterfallem. Outside-in to też jest zwinne podejście. Wymaga nie polegania na niepewnych rzeczach, nie wymaga wcześniejszej analizy (jak się robi w waterfallu), pracuje się w małych krokach, ciagle dostarcza działające kawałki, aplikacja jest używalna w zasadzie od początku pracy nad nią, i od razu wykazuje że spełnia obiecaną wartość. Nowo odkrywane informacje wpływają na design aplikacji która jest ciągle dopasowywana do warunków, również te wysokopoziomowe struktury które są sterowane testami.

Więc od razu mogę zdementować mit, "outside-in" to nie waterfall Aczkolwiek! @WhiteLightning rozumiem Cię że niektóre korpo pracują w waterfallu, i będą wciskać kit że niby robią outside-in; ale z tego co mówisz to to najpewniej była ściema.

Przyczepię się tylko do tego ale ostatecznie gdzies zostanie wpiety wiec to jest budowanie od szczegolu.. Szczegółu w jakim sensie? Bo to API w Twoim przykłądzie zdaje się być kluczową decyzją, więc pod tym względem szczegółem na pewno nie jest. W kontekście TDD jest to zewnętrzna zależność, więc też szczegółem nie jest. Więc według jakiej definicji to jest szczegół? Chyba tylko w takim że jakis bieda-guru-corpo-cwaniak źle zrozumiał outside-in i wpadł na genialny pomysł że kontrolery i ui to "ogół" a to co w serwisach to "szczegół", ale to jest debilny pomysł.

Miang napisał(a):

Piszę właśnie mały kawałek, ogólnie wiem o co mi w nim chodzi, przetwarzanie pliku xml z w miarę ustrukturyzowanymi danymi, w których coś chcę automatycznie pozmieniać.
Piszę w języku, który jest bardzo dobry do przetwarzania plików tekstowych, czyli PHP (zaraz będzie hejt) ale podobną metodę stosuję też w innych przypadkach, w innych językach:
Najpierw tworzę obramowanie kodu - klasy, metody i pola w tych klasach, nie wypełniając ich treścią, tylko sygnaturki ze znaczącymi nazwami, typami zmiennych, rodzajem zwracanej wartości i komentarzami TODO. Na razie nie pisze ciał wszystkich funkcji, tylko kawałki, i w trakcie przemyśliwania zmieniam przygotowane obramowanie żeby było jak najporządniejsze. Czuję się jakbym w matematyce upraszczała skomplikowany wzór wyciągając przed nawias i mam z tego radochę. Oczywiście można tak robić wtedy jak się ma normalną presję czasową, a nie zap* że nie ma czasu taczek załadować (24 Polecam wszystkim książkę Ho... )
Czy ja jestem dziwna , czy Wy też tak macie?

Jak dla mnie na pewno nie jest dziwne, a wręcz jest to książkowe podejście - widziałem je dosłownie w książkach o programowaniu, także w takich dla początkujących. Pisanie klas i metod bez implementacji to jest przecież projektowanie interfejsu pomiędzy klasami wewnątz Twojego programu, a projektowanie (i czasem dokumentowanie) interfejsów jest normalne, a na pewno na większą skalę jest normalne, a Ty tylko robisz to na mniejszą. Twoje podejście przypomina też metodę kolejnych uściśleń towarzyszącą idei programowania strukturalnego. Metoda kolejnych uściśleń jest opisana od strony 129 książki "Projektowanie niezawodnego oprogramowania", Glenford J. Myers, polskie wydanie WNT 1980.

Mi się zdarza rysować schematy blokowe mniej oczywistych algorytmów i wolę to od szkicowania algorytmu w kodzie i (dłuższego) debugowania.

Czasami przychodziła mi do głowy myśl, że samo projektowanie bez pisania żadnego kodu to lenistwo, kiedy moim zadaniem jest napisać kod, ale jednocześnie mam same doświadczenia, że dobrze by było, gdybym jeszcze więcej czasu poświęcił na przemyślenia przez kodowaniem.

szczegółów Wam nie podam bo to jednak jest zlecenie dla klienta, ale właśnie poprawiam jeden kawałek, bo w trakcie działania wyszło że podane założenia nie do końca były prawdziwe. To że ładnie sobie przebieg programu podzieliłam na funkcje, znacznie mi ułatwia poprawkę. To jest agile w praktyce , a nie żadne scrumy