#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
Według mnie występujemy jako zespół czy jako firma, która utrzymuje tą dokumentację i jak on zgłasza problem, to my wewnętrznie powinniśmy mieć takie procedury, które wiedzą, kto jest ownerem i żeby ten feedback trafił tam, gdzie trzeba. Zresztą my coś takiego mamy, że zgłasza ktoś feedback i wiemy, kto jest odpowiedzialny za jaki dokument i jest routing robiony do odpowiedniej osoby z tym taskiem, a jeśli nie, to tam się pytamy itd. Więc mamy procedurę na przypisywanie. Ale na zewnątrz, czy ta informacja jest potrzebna? Nie wydaje mi się. No właśnie, może być albo może nie być. Jeżeli ktoś jest sławnym takim jakimś ekspertem, nie? Na przykład jak jest świat frontendu i Reacta i jak się tam pojawi Dan Abramow i coś powie na jakiejś konferencji, no to wszyscy share'ują na Slacku linka, nie? Jakbym na przykład czytał sobie dokumentację do Reacta i jakiś artykuł byłby podpisany, że to Dan Abramow go napisał, no to bym zwrócił uwagę bardziej na ten artykuł, nie?
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