[D.....x]

Pracuje w korporacji bo #java, chciałbym się zapytać o jedną rzecz. Jak rozgraniczacie sztukę pisania umiejętnego kodu, ładnego, przejrzystego wraz z krótkim czasu deadline. Podam przykład.

Zgodnie ze sztuką developmentu, aby kod był napisany po "bożemu" zajęłoby to nam miesiąc, jednak wtedy spóźnilibyśmy się z oddaniem produktu na czas. Jest opcja napisania tego po łepkach, wraz z testami w 2 tygodnie i oddanie produktu na czas. Co wybieracie?

[S.....k]

@Dajlaxx: Po bożemu ale mniej funkcjonalności. Menedżerowie nie rozumieją że pisanie po łebkach mści się po wielu miesiącach i obwiniają o to potem programistów.

[D.....x]

@Scharnvirk: Co w przypadku, gdy chodzi dokładnie o jedną funkcjonalność/feature?

[globalbus]

@Dajlaxx: korpo robi dla siebie, czy to jest outsourcing?
Jak robi dla siebie, to trzeba organizować co jakiś czas refaktor, by posprzątać śmieci po developmencie.
W przypadku drugim, po zaakceptowaniu przez klienta nic się nie zmienia, choćby miało się wiedzę, że to p--------e :)

[Ostrzewtlumie]

@Dajlaxx: niestety ale jak deadliny sa sztywno ustalone z klientem to nie da sie robic perfekcyjnie(w sumie nigdy sie nie da, zawsze cos mozna lepiej :P). No i tez w sumie menedzerom zalezy na jak najwiekszym hajsie czyli lepiej oddac szybciej i zaczac kolejny task, niz rzezbic dokladnie jeden. W sumei to wszystko zalezy gdzie sie trafi, u mnie nie ma takiego parcia, a zawsze mozna dogadac sie z menago

[D.....x]

@globalbus: dla siebie

[S.....k]

@Dajlaxx: Wydzielić jako możliwie niezależny element który będzie można potem łatwo podmienić, zaznaczyć menedżerowi że w tym czasie nie da się rozwiązania zrobić docelowego i dostaną demko. Niech zostanie w słowie pisanym (mail, etc) że zostało tak klepnięte.

[Smevios]

@Dajlaxx: aktywnie uczestniczyć przy określaniu deadline (tak aby estymaty zawierały czas na to, by to zrobić dobrze). Wtedy nie ma wyboru "dobry kod" czy "kod na czas".

[globalbus]

@Dajlaxx: są okresy, gdzie produkuje się taśmowo feature'y, a potem są lżejsze, gdzie można poupychać utrzymaniowe zadania (w tym sprzątanie). Jeśli jest nonstop zapieprz od miesięcy, to zmień firmę...

Dodatkowo, polecam postawić gdzieś w organizacji serwer SonarQube, dodać pluginy od findbugs, podpiąć pod IDE i budowanie paczek.
Chroni to trochę przed wypychaniem ewidentnego syfu i estymuje ile zajmie jego sprzątanie.

[filozof900]

@Dajlaxx: kod musi być zawsze poprawny. jeżeli masz deadline i wiesz, że się nie zmieścisz, idz do managera i powiedz mu o tym jak najszybciej. nie pytaj go, czy ma być na szybko i byle jak czy dobrze, po prostu powiedz, ze nie bedziesz w stanie tego zrobic w takim czasie. to co tworzysz jest pozniej podpisane twoim imieniem wiec rob to dobrze

[cochese]

aktywnie uczestniczyć przy określaniu deadline

@Smevios: Czasami deadline przychodzi "skądś" i nie jest negocjowalny. Wyścig z konkurencją, kara za niedotrzymanie umowy z inną firmą, spełnienie wymagań prawnych itp. Takie przyczyny zdarzają się wszędzie, ale w korporacjach często wychodzą na wierzch zbyt późno, żeby cokolwiek sensownego z nimi zrobić.

[cochese]

sztukę pisania umiejętnego kodu, ładnego, przejrzystego wraz z krótkim czasu deadline

@Dajlaxx: Pracę do wykonania podzielcie na najmniejsze sensowne kawałki. Pracujcie w cyklach testy-kod-refaktoring albo kod-testy-refaktoring jeżeli nie macie doświadczenia w TDD. Skróćcie te cykle do minimum. Dzięki temu refaktoring, który zrobicie w poniedziałek, zacznie przynosić zyski już w środę, bo następne zmiany łatwiej będzie nałożyć na czysty kod. To powinno przyspieszyć pracę na późniejszych etapach na tyle, że macie

[cochese]

Co w przypadku, gdy chodzi dokładnie o jedną funkcjonalność/feature?

@Dajlaxx: Ciężko mówić o czysto teoretycznym przypadku. W praktyce prawie każdy feature można rozbić na mniejsze. Czasem można wydzielić przypadek optymistyczny (który pozwala na jakieś-tam korzystanie z softu) i przypadki brzegowe (które zdarzają się rzadziej, więc ich obsługę można dodać po tygodniu bez dużego ryzyka). Czasami można powydzielać rzeczy poza samym meritum, typu wygodną konfigurację, dopracowany interfejs, lepszą wydajność przy dużym

[cochese]

To że coś się zrobi na odwal oznacza kilka godzin oszczędności teraz a kilkanaście godzin pracy później.

@LazyInitializationException: @Dajlaxx: Co więcej: gdy zejdzie się z jakości tylko po to, żeby dotrzymać terminów, to drobny błąd znaleziony ostatniego dnia przed deadlinem może być tak trudny do naprawienia z powodu bagna w kodzie, że termin i tak będzie zawalony. Generalnie cięcie na jakości to chodzenie po polu minowym: nigdy nie