#56 Tech Writer robi inżynierię oprogramowania, czyli dobre praktyki prosto od Google
Inżynieria oprogramowania to coś więcej niż programowanie. To tworzenie kodu z myślą o jego utrzymaniu w kontekście czasu, zasobów i skali. Taka szersza perspektywa wymusza na nas stosowanie pewnych zachowań, procesów i narzędzi.Firma Google stworzyła praktyczny przewodnik opisujący te zagadnienia, który według nas jest wartościową lekturą dla osób pracujących w branży wytwarzania oprogramowania. Rozmawiamy o tym co znajdziecie w książce "Software Engineering at Google", które fragmenty były dla nas najciekawsze i jakie przemyślenia mieliśmy po jej przeczytaniu.Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).Informacje dodatkowe: "Software Engineering at Google", Titus Winters, Tom Manshreck, Hyrum Wright: https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ Hyrum's Law: https://www.hyrumslaw.com/ "Bus factor", Wikipedia: https://en.wikipedia.org/wiki/Bus_factor "POIT #203: Kariera pokolenia Z w branży IT", Porozmawiajmy o IT: https://porozmawiajmyoit.pl/poit-203-kariera-pokolenia-z-w-branzy-it/ "Shift-left testing, czyli wczesne testowanie": https://testerzy.pl/baza-wiedzy/shift-left-testing-czyli-wczesne-testowanie "Code review", Wikipedia: https://en.wikipedia.org/wiki/Code_review "Tech Writer koduje w Pythonie. Przewodnik szybkiego startu", Michał Skowron: https://techwriterkoduje.pl/python/teoria "Guard Clause": https://deviq.com/design-patterns/guard-clause
I mamy sobie tam, wiesz, co jakiś czas ten backlog przeglądać, mamy decydować o priorytetach i w ogóle mamy pilnować, żeby był porządek, tak? I to jest jakby odpowiedzialność całego zespołu, a nie konkretnej osoby. Nie ma lidera od Jiry, tak? I zauważasz problem, że to nie działa. Buglog jest przeglądany bardzo rzadko, tikety nie są update'owane, nie tworzy się historyjek na każdą zmianę, a powinno się ją łączyć jakby z tymi commit'ami, które lecą do repozytorium. No i zaczyna się robić mały chaos, tak? Czyli nie ma takiego na bieżąco update'owania statusów, nie do końca wszyscy wiedzą co robią, nie ma takiego jasnego podziału tasków i tak dalej. No to wiele jakichś tam negatywnych skutków. No i teraz nie ma osoby, która powinna się z założenia tym zająć, bo nie ma osoby Jira Owner na przykład, nie? Albo Jira Leader. I ty zauważasz problem i sam wychodzisz przez szereg i mówisz, słuchajcie,
Pokazano wszystkie 1 dopasowanie. Transkrypcja generowana automatycznie i niesprawdzana ręcznie — może zawierać błędy.
Redaktor przywituje się z gościem i Paweł Kowaluk przedstawia się jako ekspert od inżynierii oprogramowania w Google po przeczytaniu książki Software Engineering at Google.
Paweł opisuje książkę Software Engineering at Google, jej struktura i wartość dla inżynierów oprogramowania oraz osób z praktyką w różnych firmach.
Paweł omawia konцепcje takie jak clever i prawo Hyruma, które ilustrują różnice między programowaniem a inżynierią oprogramowania.
Paweł omawia kultury i procesy opisane w książce, takie jak geniusz jako mit i dzielenie się pracą.
Paweł omawia koncepcję equity i jej znaczenie w budowie zespół z różnorodnością.
Paweł omawia koncepcję Servant Leader i antypaterny w prowadzeniu zespołu, podkreślając ważne praktyki menedżerskie.
Paweł podsumowuje swoje doświadczenia i refleksje na podstawie omawianych w książce koncepcji.
Rozdział skupia się na znaczeniu dokumentacji w oprogramowaniu, analizując różne aspekty jej tworzenia, takie jak review, ownership, analogie z programowaniem i konsekwencje na skalę firmy. Podkreślana jest wartość dokumentacji dla użytkowników i pracowników.
Rozmowa zakończa się podsumowaniem kluczowych punktów i poleceniami do czytania książki. Podkreślana jest wartość praktyk zado<main> dokumentacji i procesów w oprogramowaniu, nawet dla osób niezwiązanych bezpośrednio z kodowaniem.
Rozdziały i streszczenia generowane automatycznie. Pełna transkrypcja nie jest publikowana — wyszukaj frazę, aby zobaczyć dopasowane fragmenty.
Kliknij, aby znaleźć fragmenty, w których pada.
Inżynieria oprogramowania to coś więcej niż programowanie. To tworzenie kodu z myślą o jego utrzymaniu w kontekście czasu, zasobów i skali. Taka szersza perspektywa wymusza na nas stosowanie pewnych zachowań, procesów i narzędzi.
Firma Google stworzyła praktyczny przewodnik opisujący te zagadnienia, który według nas jest wartościową lekturą dla osób pracujących w branży wytwarzania oprogramowania. Rozmawiamy o tym co znajdziecie w książce "Software Engineering at Google", które fragmenty były dla nas najciekawsze i jakie przemyślenia mieliśmy po jej przeczytaniu.
Dźwięki wykorzystane w audycji pochodzą z kolekcji "107 Free Retro Game Sounds" dostępnej na stronie https://dominik-braun.net, udostępnianej na podstawie licencji Creative Commons license CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).
Informacje dodatkowe:
"Software Engineering at Google", Titus Winters, Tom Manshreck, Hyrum Wright: https://www.oreilly.com/library/view/software-engineering-at/9781492082781/ Hyrum's Law: https://www.hyrumslaw.com/ "Bus factor", Wikipedia: https://en.wikipedia.org/wiki/Bus_factor "POIT #203: Kariera pokolenia Z w branży IT", Porozmawiajmy o IT: https://porozmawiajmyoit.pl/poit-203-kariera-pokolenia-z-w-branzy-it/ "Shift-left testing, czyli wczesne testowanie": https://testerzy.pl/baza-wiedzy/shift-left-testing-czyli-wczesne-testowanie "Code review", Wikipedia: https://en.wikipedia.org/wiki/Code_review "Tech Writer koduje w Pythonie. Przewodnik szybkiego startu", Michał Skowron: https://techwriterkoduje.pl/python/teoria "Guard Clause": https://deviq.com/design-patterns/guard-clause