#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
Dobra sprawa, dobre podejście. Ta część tej książki, która mówi właśnie o kulturze i organizacji była dla mnie najciekawsza, bo dalsze części, które mówią o procesach takich konkretnych jakichś i o narzędziach może były mniej odkrywcze trochę z mojego punktu widzenia. Wydaje mi się, że dużo rzeczy, które tam są opisane Weszły do takiej ogólnej praktyki np. używanie Source Control, używanie CI-CD, Static Analyzers, jakichś tam linterów, jakiś Code Conventions itd. To wszystko wydaje się już być na tyle praktyką ugruntowaną, że większość zespołów tego używa. Natomiast jeżeli to nie jest dla kogoś oczywiste, no to może to być też ciekawe dla Was. Z takich rzeczy związanych z automatyzacją i narzędziami, no to ja bym tutaj wyciągnął takie rzeczy, które są już powiedzmy może i powszechnie znane, ale warto o nich pamiętać, czyli Shift Left na przykład, czyli przesuwanie tego wyłapywania błędów jak najwcześniej w procesie.
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