Edytujesz „Programowanie zwinne”
Z Nonsensopedii, polskiej encyklopedii humoru
Uwaga: Nie jesteś zalogowany. Jeśli wykonasz jakąkolwiek zmianę, Twój adres IP będzie widoczny publicznie. Jeśli zalogujesz się lub utworzysz konto, Twoje zmiany zostaną przypisane do konta, wraz z innymi korzyściami.
Ta edycja może zostać anulowana. Porównaj ukazane poniżej różnice między wersjami, a następnie zapisz zmiany.
Aktualna wersja | Twój tekst | ||
Linia 29: | Linia 29: | ||
Wśród skutków ubocznych metodyki GDD można wymienić między innymi większą podatność członków zespołu na załamanie nerwowe, [[Depresja|depresję]] i ogólną zwiększoną śmiertelność. Należy ją stosować wraz z agresywnymi technikami poszukiwania pracowników w celu zapewnienia stałej ilości programistów w projekcie. |
Wśród skutków ubocznych metodyki GDD można wymienić między innymi większą podatność członków zespołu na załamanie nerwowe, [[Depresja|depresję]] i ogólną zwiększoną śmiertelność. Należy ją stosować wraz z agresywnymi technikami poszukiwania pracowników w celu zapewnienia stałej ilości programistów w projekcie. |
||
[[Plik:Extreme programming in action.jpg|thumb|250px|Lider zespołu SDD musi zadbać o odzież ochronną dla siebie]] |
|||
=== ''Shame Driven Development'' === |
=== ''Shame Driven Development'' === |
||
Metodyka nieco podobna do Guilt Driven Development, ją również można implementować przy pomocy narzędzi automatycznych, ale daje dużo lepsze efekty, gdy robią to ludzie. Podstawowym założeniem jest rezygnacja z jakichkolwiek wymagań przy commitowaniu i [[Scalanie|merge'owaniu]] kodu. Tak, żadnych durnych code review, żadnych unit testów, kod nie musi się nawet kompilować, cała odpowiedzialność spoczywa na programiście. Jeśli w kodzie będą jakieś bugi (a będą), należy delikwenta publicznie wyśmiać i zagonić do roboty. Prekursorem tej metodyki jest twórca Linuksa, [[Linus Torvalds]], oto kilka wypowiedzi mistrza: |
Metodyka nieco podobna do Guilt Driven Development, ją również można implementować przy pomocy narzędzi automatycznych, ale daje dużo lepsze efekty, gdy robią to ludzie. Podstawowym założeniem jest rezygnacja z jakichkolwiek wymagań przy commitowaniu i [[Scalanie|merge'owaniu]] kodu. Tak, żadnych durnych code review, żadnych unit testów, kod nie musi się nawet kompilować, cała odpowiedzialność spoczywa na programiście. Jeśli w kodzie będą jakieś bugi (a będą), należy delikwenta publicznie wyśmiać i zagonić do roboty. Prekursorem tej metodyki jest twórca Linuksa, [[Linus Torvalds]], oto kilka wypowiedzi mistrza: |
||
<br clear="all" /> |
|||
{{Cytat2|''Ten gówniany commit został oznaczony jako „stabilny”, ale coś mi się wydaje, że nawet tego nie skompilowałeś!''<ref>[https://lkml.org/lkml/2013/7/13/132 Źródło]</ref>}} |
{{Cytat2|''Ten gówniany commit został oznaczony jako „stabilny”, ale coś mi się wydaje, że nawet tego nie skompilowałeś!''<ref>[https://lkml.org/lkml/2013/7/13/132 Źródło]</ref>}} |
||
{{Cytat2|''Oczywiście, sugerowałbym też żeby geniusz który myślał, że czytanie danych BAJT PO J{{cenzura3}}YM BAJCIE to dobry pomysł powinien zostać poddany wstecznej aborcji. Kto k{{cenzura3}}a robi tak idiotyczne rzeczy? Jakim cudem nie umarł jako dziecko, skoro prawdopodobnie był zbyt głupi, by znaleźć cycka do ssania?''<ref>[https://lkml.org/lkml/2012/7/6/495 Źródło]</ref>}} |
{{Cytat2|''Oczywiście, sugerowałbym też żeby geniusz który myślał, że czytanie danych BAJT PO J{{cenzura3}}YM BAJCIE to dobry pomysł powinien zostać poddany wstecznej aborcji. Kto k{{cenzura3}}a robi tak idiotyczne rzeczy? Jakim cudem nie umarł jako dziecko, skoro prawdopodobnie był zbyt głupi, by znaleźć cycka do ssania?''<ref>[https://lkml.org/lkml/2012/7/6/495 Źródło]</ref>}} |