Uczyłem się w CompSci, gdzie przede wszystkim uczyłem się języka Java, ale dowiedziałem się, że moją pasją są systemy, więc zawsze pracowałem po stronie operacyjnej. Przydaje mi się skryptowanie, więc nie szukam strony, która nauczy mnie Ruby, ale coś, co wyjaśni bardziej dogłębnie to, co robicie przez cały dzień. Chcę lepiej zrozumieć kulturę i to, jak trawisz samą liczbę plików w swoich projektach - wartości niematerialne.
Gdybym się dzisiaj dowiedział, że w poniedziałek przeniesiono mnie do zespołu programistów, co chciałbym przeczytać w ten weekend?
culture
builds
methodology
software-engineering
Stephen C.
źródło
źródło
Odpowiedzi:
Ponieważ oznaczyłeś to pytanie jako „kultura”, zakładam, że nie interesuje Cię konkretna aplikacja, ale szersze pytania dotyczące przepływu pracy i zarządzania.
Prawdopodobnie zacznę od „Podręcznika DevOps”; to dobry przegląd różnych rzeczy do rozważenia, bez nurkowania zbyt głęboko.
Często wspominane jest także „Continuous Delivery” Jez Humble; Nie przeczytałem jeszcze dużo, ale obejmuje on koncepcje kontroli źródła i automatyzacji kompilacji.
Jeśli zaczynasz wchodzić w aplikacje na dużą skalę (może to być zbyt duże założenie), inną dobrą książką jest „The Practice of Cloud System Administration” autorstwa Limoncelli i in.
źródło
Zakładam, że nie chodzi o DevOps, ale o proste tworzenie oprogramowania.
Cóż, duża rzecz w prostym rozwoju (bez kąta „DevOps”) jest z pewnością „zwinna”, tj. W przeważającej części SCRUM. Możesz zrobić coś gorszego niż usiąść i przeczytać Agile Manifesto lub podkład na SCRUM lub Kanban, aby uzyskać więcej codziennych zadań, naprawiania błędów i konserwacji.
Poza tym mówienie o „kulturze” w ogóle pochodzi od strony deweloperów, głównie jest rzeczą specyficzną dla DevOps. Tak, mamy także naszych ewangelistów, szczególnie dla nowszych rzeczy, takich jak rubin czy golang, ale nie tak ekstremalnych jak w świecie DevOps / Cloud, gdzie zachodzą rzeczywiste zmiany paradygmatu.
Sam nie popracowałem nad nietrywialnymi aplikacjami rubinowymi. Widzisz, te pliki są nie tylko rozrzucone wokół niefrasobliwie, ale istnieje hierarchia, konwencje i tak dalej. Tak naprawdę nigdy nie musisz mieć wszystkich tych plików w jednym momencie, aby dobrze zaprojektować projekt. Jeśli pracujesz w określonym obszarze, zwykle jest całkiem jasne, gdzie znajdują się odpowiednie pliki, i możesz je łatwo powiększyć. To samo powinno dotyczyć innych nowoczesnych środowisk programistycznych.
W złych aplikacjach jest inaczej, ale wtedy programista właściwie „nie przetrawi” niczego, tylko potyka się przez cały dzień w szaleństwie, dopóki nie odejdzie. ;)
źródło