Czy mam zły pomysł na inżynierię oprogramowania? [Zamknięte]

Mam pytanie, które podniosła moja ostatnia praca (raczej stażysta).

Po prostu w kontekście - mam 21 lat i ukończyłem drugi rok studiów, zanim miałem około 2 lata doświadczenia w pracy sys admin / QA i zasadniczo mogę powiedzieć, że widziałem, jak różne są Działały sektory IT. Pośpiesz się do teraźniejszości, a oto ja ląduję na stażu w jednej z najważniejszych instytucji badawczych w Wielkiej Brytanii.

Muszę stworzyć narzędzia wewnętrzne za pomocą różnych technologii - głównie AWS / Java / Bash - otrzymujesz obraz. Wszystko jest w porządku, wykonuję swoją pracę ALE nie jestem szczęśliwy. Dlaczego tak jest - skoro mam pracować w sprawie ad hoc. To jest tworzenie rzeczy szybko, bez poświęcania czasu na projektowanie. Mój kierownik wyraźnie stwierdził, że spodziewano się, że „pośpieszymy się” przez pojawiające się problemy, a my zasadniczo. W rezultacie okazało się, że trzeba było przerobić i przeprojektować i nadal nie są one idealne. Jeśli chodzi o testowanie - ogranicz go do minimum, dopóki wygląda na to, że działa, jest w porządku.

Czy jestem winny nie zgadzać się z tym sposobem prowadzenia pracy? Czy źle jest myśleć o systemie jako całości, a następnie skupić się na różnych komponentach i zobaczyć, w jaki sposób mogą ze sobą współpracować, aby wyzerować różne „kluczowe punkty”, które mogą okazać się problematyczne w przyszłości? Czy przestępstwem jest chęć wykonywania dobrej pracy, a nie „szybkiej pracy”? Czy błędem lub niewłaściwym podejściem jest badanie struktur danych mających zastosowanie do problemu, abyś mógł wybrać najlepszy w zależności od konkretnego zestawu problemów? O ile dobrze rozumiem, bit „Inżynieria” w „Inżynierii oprogramowania” ma dokładnie z tym związek - zbadać domenę problemów i znaleźć przemyślane rozwiązanie, a następnie udoskonalić w razie potrzeby?

Byłem na rozmowie w biurze Arm w Wielkiej Brytanii i pokazali mi swój pokój SCRUM i wyglądało na to, że mieli całkiem niezły pomysł na zarządzanie swoim projektem - mieli zaległości, mieli mierniki, jak długo każdy problem może zająć do rozwiązania - zwykłe rzeczy dla SCRUM - zupełnie inne niż sposób działania „tutaj”

Czy ogólnie pomyślałem o branży oprogramowania? Chciałbym usłyszeć twoją opinię na ten temat. Mam na myśli, że „weszłam” w tworzenie oprogramowania wyłącznie dlatego, że chcę tworzyć rzeczy - proste i proste, ale chcę tworzyć rzeczy wysokiej jakości. Chcę zobaczyć, jak moje oprogramowanie jest używane w różnych scenariuszach, chcę, aby było ono kuloodporne - czy nie jest to siłą napędową wszystkich inżynierów oprogramowania? Myślę, że każdy może być programistą / programistą, po prostu ucząc się składni, ale dla mnie prawdziwa zabawa zaczyna się wtedy, gdy trzeba wymyślić projekt, który można wykonać w prawdziwym świecie.

Zwykle wykonywałem swoje zadania na uniwersytecie, po prostu patrząc na nie i bezpośrednio rozpoczynając kodowanie. Mogłem łatwo uzyskać oceny powyżej 75% i nigdy tak naprawdę nie doceniałem modułu „cyklu życia oprogramowania”. Ale teraz, kiedy zobaczyłem w prawdziwym świecie, jak źle jest pracować bez żadnego formalnego procesu i frustracji związanej z sytuacją, w której nie wiesz, czy wymagania zmienią się jutro (och, czy powiedziałem, że nie nie masz jasno zdefiniowanej analizy wymagań?)

Naprawdę lubię wierzyć, że właśnie osiągnąłem pozycję, w której niektórzy ludzie potrzebowali po prostu małpy kodowej, aby wykonać swoją brudną robotę, a tak nie jest w przypadku całego świata oprogramowania.

Sprawienie, by oprogramowanie nadawało się do ponownego użycia i było odporne na pociski, nie jest motorem inżynierii oprogramowania. Inżynieria polega na optymalnym rozwiązywaniu problemów ze świata rzeczywistego w ramach rzeczywistych ograniczeń . Większość inżynierów wolałaby pracować na Ferrari - ale kombi potrzebuje tyle samo inżynierii, a powód, dla którego kombi nie działa tak dobrze (pod pewnymi względami), wynika z trudniejszych ograniczeń projektowych, a nie z powodu gorszej inżynierii .

Kiedy mówisz, że chcesz wykonać „dobrą robotę”, a nie „szybką robotę”, większość inżynierów tak robi, ale czasem częścią tego, co określa dobrą, jest szybkość jej wykonania. Dlatego niewłaściwe jest uważanie „dobrych” i „szybkich” za przeciwstawne wybory. Albo pomyśleć, że wykonujesz złą pracę lub jesteś „małpą kodową”, która wykonuje najlepszą możliwą pracę w dostępnym czasie.

Oczywiście jest całkiem możliwe, że proces ten nie jest optymalny i lepiej by go było z nieco większym projektem z góry. Test kwasu byłby taki: czy obecny sposób robienia rzeczy stwarza więcej problemów niż rozwiązuje dla użytkowników , czy tylko denerwuje programistów, którzy muszą tak pracować? Jeśli faktycznie powoduje to problemy dla użytkowników, częścią twojego zadania jest próba wykazania, że ​​tak jest, i próba przekonania ludzi do nieco bardziej kontrolowanego procesu.

Właściwie to mi to przeszkadza. Jesteś zawodem, w którym opracowujesz narzędzia dla naukowców, prawda. Jednak powiedziano ci, aby przyspieszyć działanie tych programów i sprawić, by działały minimalnie. Niespodzianka niespodzianka. Jest to po prostu typowe podejście badacza do programowania z złotówką przekazaną rzeczywistemu programistowi.

Głównym problemem jest tutaj to, że w szczególności brak testów może budzić wątpliwości etyczne, jeśli narzędzia mają ważny cel. Jeśli nie masz pewności, czy oprogramowanie ma wady, ponieważ ogranicza się do minimalnego czasu testowania, oznacza to, że ŻADEN nie ponosi odpowiedzialności za warunki pracy oprogramowania, a Atlas wzrusza ramionami.

Zatrzymajmy się jednak na chwilę. Jakie narzędzia opracowujesz? Jeśli tworzysz oprogramowanie, które modeluje dane, istnieje tutaj duży dylemat etyczny . W niektórych sytuacjach badania naukowe prowadzą do decyzji, które wpływają na wiele osób na dużą skalę.

Załóżmy na chwilę, kontrowersyjny temat zmian klimatu spowodowanych przez człowieka. Powiedzmy, że umieścili te same standardy w oprogramowaniu do modelowania, którego używają, aby dojść do wniosków, które mają dzisiaj. Temat ma duży wpływ na to, jak właściwie podchodzimy do zarządzania środowiskiem i polityką międzynarodową.

Czy nie jest etyczne dopilnowanie, aby oprogramowanie do modelowania nie miało większych problemów z przewidywaniami?

Cały problem nie polega na tym, że gazy cieplarniane ogrzewają ziemię. Problem polega na tym, czy wynikiem netto efektów sprzężenia zwrotnego jest przyspieszający wzrost temperatury, który po przekroczeniu progu nie byłby już odwracalny.

Gdyby wspomniane wzmocnienie miało miejsce, dowód wyniku netto byłby marginalny, prawdopodobnie w zakresie błędu.

Tak więc niewielkie błędy w obliczeniach, a nawet metodologia polegająca na przechowywaniu i wyszukiwaniu danych na zapleczu, mogą spowodować albo zignorowanie poważnego problemu środowiskowego z jednej strony awarii, albo politykę międzynarodową, która wpływa na wiele osób (niszczy miejsca pracy, niszczy emerytury itp.) ) na inne.

Tak, masz rację. Nie obchodzi mnie, jakie jest tempo badań ... Jeśli badacze chcą polegać na narzędziach programowych do zarządzania danymi i wykonywania dla nich obliczeń, muszą nauczyć się czekać na oprogramowanie wykonane poprawnie. W przeciwnym razie oprogramowanie stanie się punktem krytycznym w ich teoriach, za które nie ponoszą odpowiedzialności, co prowadzi do nadużyć etycznych.

Nie masz złego pojęcia na temat inżynierii oprogramowania. Brakuje jednak bardzo ważnego aspektu: jest to branża usługowa. Niektórzy z nas pracują nad produktem od lat i przechodzą proces projektowania, a następnie wiele iteracji, zanim pojawi się w wersji 1. Inni muszą wyprodukować coś w ciągu 3 godzin. To zależy od tego, komu służysz i jaki jest cel.

Jeśli możesz stworzyć aplikację w ciągu 3 godzin (lub dni), która robi to, co powinna robić, po co poświęcać jej więcej czasu na projektowanie z góry? Po prostu marnujesz pieniądze. Marnowanie pieniędzy to ogólnie nie dobry pomysł ™.

Jak już powiedzieli inni, dużą część inżynierii oprogramowania stanowią „zewnętrzne ograniczenia”. na przykład. Czas, budżet, obsługa, wsparcie, zaspokajanie irracjonalnych wymagań idiotycznych itp.

Wielu z nas (łącznie ze mną) zajmuje się programowaniem, myśląc, że chodzi o samo programowanie - kodowanie pięknych i eleganckich programów w próżni (lub przynajmniej w próżni względnej). To rzadko jest. Mogą się do tego zbliżać rzadkie prace akademickie lub prace badawczo-rozwojowe, ale w przeważającej części przeważająca większość prac programistycznych jest podobna. Zwłaszcza w fazie konserwacji - która zwykle stanowi ponad 90% czasu życia produktu - oraz codziennej rutyny większości stałych programów komercyjnych.

Przez długi czas miałem wewnętrzny konflikt na ten temat, który często sprawiał, że byłem niezadowolony z mojej pracy (i jest to część tego, co ostatecznie doprowadziło do wypalenia w zeszłym roku). Zawsze czułem, że praca jest do bani, jeśli nie chodzi tylko o stworzenie pięknego kodu i poświęcenie czasu na to, aby zrobić to właściwie. Ale tak naprawdę jest to rzeczywistość - a niektórzy ludzie rozwijają się dzięki pracy zorientowanej na usługi. To sprawia, że ​​czują się pragmatyczni i przydatni. Nawet jeśli rzeczywiste aspekty projektu związane z „czystą inżynierią oprogramowania” stają się stosunkowo szybkie i niechlujne.

W każdym razie dobrze, że teraz to kwestionujesz. Jest to jedna z tych rzeczy, których tak naprawdę nigdy właściwie nie wyjaśniają w szkole. Firmy uwielbiają udawać, że przestrzegają bardzo dobrych praktyk inżynierskich, nawet jeśli nie. Wskazówka: większość nie.

Wszystko, co powiedziało, różni się. Niektóre firmy (głównie te, dla których oprogramowanie jest ich główną działalnością oraz te, które pracują nad oprogramowaniem o kluczowym znaczeniu dla bezpieczeństwa, takim jak sprzęt medyczny), przestrzegają bardzo surowego procesu inżynieryjnego. Ale ogólnie rzecz biorąc, tak, powiem ci teraz, że większość komercyjnego oprogramowania jest stosunkowo niechlujna. Zwykle jest to jakiś formalny proces, ale przestrzeganie go prawie zawsze zajmuje miejsce w reakcji na opinie klientów i inne naciski komercyjne. Nie jest to tak naprawdę „niechlujstwo” per se, to po prostu pragmatyczna użyteczność. Sztuka polega na tym, aby znaleźć swoją niszę i spojrzeć na rolę z punktu widzenia świadczonej usługi, a nie na to, jak fajny jest aspekt „czystego programowania”.

EDYCJA : Wydaje mi się, że w mojej wstępnej ocenie mogłem brzmieć zbyt jednostronnie. Chciałbym dodać, że często pojawiają się również prawdziwe problemy ze zbyt niedbałością i brakiem dobrego procesu - do tego stopnia, że ​​doprowadza to projekt do zadłużenia technicznego i jest w rzeczywistości niekorzystny dla biznesu. Ale zobaczenie tego przychodzi z doświadczeniem. Początkowy punkt nadal jest w gruncie rzeczy zasadniczy: większość komercyjnego oprogramowania działa dzisiaj nie tak ściśle zorientowana inżynieryjnie, jak by to mogło być purystom.

Cóż za wspaniałe pytanie! Czasami możesz zrobić coś cennego, będąc szybkim . Zazwyczaj dzieje się tak w laboratorium badawczym, w którym im szybciej dowiemy się tego, czego nie wiemy, tym lepiej. Tworzone oprogramowanie istnieje tylko po to, by odpowiadać na pytania. To „wyrzuć kod”. Dotyczy to również startupów, które nie wiedzą, czego naprawdę chcą klienci. Ponadto, kiedy pierwszy raz coś zrobisz, będzie to gówno. Przeczytaj mityczny miesiąc człowieka .

Czasami możesz zrobić coś cennego, będąc dobrym . Zazwyczaj dzieje się tak w przypadku oprogramowania owiniętego folią termokurczliwą, takiego jak Adobe Photoshop. Badanie zostało już przeprowadzone lata temu, a teraz pytanie brzmi, jak dodać listę funkcji, których oczekują klienci, w sposób, który nie wprowadza błędów. Jest to kwestia architektury, projektowania i testowania, testowania, testowania. Sam kod jest tym, co cenne, a nie tym, czego się z niego uczysz.

Jeśli nie jesteś zadowolony z badań (robienie czegoś pierwszego, uczenie się nowych rzeczy, o których nikt wcześniej nie wiedział), spróbuj oprogramowania owiniętego w folię. W twoim wieku powinieneś spróbować jak największej liczby rzeczy. Podejmij ryzyko! Nauczysz się dużo i na dłuższą metę będzie ci lepiej.

Myślę, że zauważyłeś bardzo wcześnie w swojej karierze, że robienie rzeczy szybko, bez odpowiedniego projektu lub odpowiedniego testowania, zwykle wraca, by cię ugryźć. Oczywiście nie podoba ci się to i masz dobry powód, aby tego nie robić. To niedorzeczne, gdy trzeba „spieszyć się z problemami”, zwłaszcza jeśli trzeba je później odwiedzić, gdy początkowe rozwiązania są nieprawidłowe lub niekompletne. Możesz rozwiązać problemy tylko wtedy, gdy je całkowicie zrozumiesz, a to wymaga czasu i starannego planowania.

Proponuję wam poinformować przełożonych, że ci to przeszkadza, i zaproponować im lepsze podejście do wykonywania pracy. Jeśli nie zgadzają się i chcą, abyś dalej „spieszył się” ze swoją pracą, zacznę szukać pracy gdzie indziej. Nie ma sensu robić rzeczy w sposób niezgodny z własnymi standardami, a tym bardziej standardem jakości oprogramowania, jakiego oczekuje branża.

Oto moja rada oparta na moich doświadczeniach, mam 20 lat i obecnie odbywam staż w dużej instytucji finansowej w Wielkiej Brytanii i miałam te same odczucia, co kilka miesięcy temu. Zauważyłam, że być może wynika to z natury praca, którą wykonujesz.

Rozumiem przez to, że powiedziałeś:

„Muszę stworzyć narzędzia wewnętrzne za pomocą różnych technologii - głównie AWS / Java / Bash”

Musiałem także stworzyć wewnętrzne narzędzia, które pomogą w zarządzaniu i automatyzacji niektórych procesów, a faktem jest, że w szybkim środowisku „małe” rzeczy muszą być szybko wdrożone. Nie miałem luksusu stosowania większości inżynierii oprogramowania lub algorytmów i zasad struktury danych, których nauczyłem się na drugim roku, ponieważ działająca wersja narzędzia była potrzebna w ciągu kilku tygodni. Byłem bardzo sfrustrowany tym, ale tak było nie wszystko złe, ponieważ nauczyłem się pisać lepiej czytelny kod.

Musiałem być cierpliwy i niedawno przeniosłem się do nowego zespołu, który pracuje nad nową iteracją wbudowanego systemu używanego przez użytkowników 10K + i mogę zapewnić, że aspekt inżynierii oprogramowania jest traktowany bardzo poważnie. Powiedziano mi, że zyskam kontakt z całym cyklem życia oprogramowania, od wychwytywania / analizy wymagań, aż do wdrożenia i testowania. Wierzę, że zdobędę to doświadczenie, ponieważ nie pracuję na wewnętrznych narzędziach, ale że pracuję na pełnym systemie z dużą bazą użytkowników.

Polecam cierpliwość, dokończ tworzenie narzędzi i wykonuj przy tym bardzo dobrą pracę, aby Twoi przełożeni zyskali większe zaufanie do Ciebie i powierzyli Ci trudniejsze zadania, które będą wymagały zastosowania zasad inżynierii oprogramowania. Zdobądź dodatkową wiedzę, wykonując dodatkowe lektury i zastosuj tę wiedzę do tego, co obecnie robisz. Pamiętam, jak splądrowałem całą bibliotekę książek elektronicznych w firmie tylko po to, by poszerzyć moją wiedzę, ohhahah, ze wszystkich przeczytanych książek czułem, że skuteczna java była naprawdę dobra książka, która bardzo mi pomogła.

Po prostu uzbrój się w cierpliwość, zainwestuj dużo w swoją wiedzę i zastosuj ją tam, gdzie to możliwe. Jeśli wykonujesz bardzo dobrą robotę, ktoś wkrótce to zauważy.

Zgadzam się, że sposób, w jaki działa twoja obecna praca, jest nieoptymalny, tak. Jeśli jednak chcesz powiedzieć, że to w ogóle nie działa, nie zgadzam się z tobą, ponieważ istnieją różne wyniki, a instytucja wciąż istnieje.

Moje główne pytanie do Ciebie brzmi: w jakim stopniu masz do czynienia z pożarami, które wymagają natychmiastowych rozwiązań wykonanych szybko, podobnie jak udzielanie pierwszej pomocy pacjentowi medycznemu, w porównaniu z wnioskami, które można skonfigurować jako projekty i obsługiwać na znacznie inną skalę, podobnie jak pacjent medyczny konieczność zaplanowania testów i różnych procedur, które nie są konieczne do wykonania natychmiast, ale w najbliższym czasie.

Poświęcenie czasu na dobre wykonanie pracy zależy nieco od dojrzałości organizacji, a także od tego, jak ważne jest, aby coś zrobić dobrze, a nie jak twierdzić.

Pytanie o badanie struktur danych brzmi, jak długo chcą to robić. Jeśli chcesz poświęcić dekadę na zbadanie struktury danych, która różni się od poszukiwania kilku godzin. Chociaż mogę docenić chęć uzyskania najlepszej odpowiedzi, jest coś, co można powiedzieć o zmniejszeniu zysków po spędzeniu czasu na problemie, np. Czy możesz spędzić godziny na szukaniu rozwiązania FizzBuzz, ponieważ możesz spróbować rozwiązać go w różnych językach na różnego rodzaju sprzęt, aby zoptymalizować szybkość jego działania.

Chociaż badanie może być ważne, ważne jest również, aby coś dostarczyć. Jeśli czegoś nie dostarczysz, jak naprawdę jesteś dobry? Duct Tape Programmer byłby bardziej przykładem na załatwienie sprawy tutaj.

Scrum to specyficzna metodologia, którą prawdopodobnie możesz spróbować zastosować w swoim obecnym miejscu pracy. Nie sądzę jednak, że Scrum jest srebrną kulą. W jakich okolicznościach projekty w ramach Scrum i Agile mogą zawieść? byłby post na blogu na ten temat, który może być interesujący.

Domyślam się, że nie widzisz, jak nieformalne są procesy w twoim obecnym miejscu i że trawa jest niezwykle zielona po drugiej stronie, gdzie istnieje formalna metodologia. Choć może tam być lepiej, niektórzy ludzie wolą to, co masz teraz, z ogromną swobodą bycia kowbojem .

Myślę, że twoja sytuacja jest nadal w skali świata rzeczywistego, a mniejszy nacisk kładziony jest na jakość. Twoje preferencje są na drugim końcu prawdziwego świata. Specyfikacje się zmieniają, pokonajcie to. Rzeczy muszą być zrobione.

Zastanów się, jak zidentyfikować tego rodzaju firmy, kiedy ubiegasz się o następną pracę. Niewiele miejsc ma model biznesowy, w którym mogą sobie pozwolić na to, że programiści będą analizować swoje projekty na zawsze (nawet profesorowie muszą uczyć). Klienci rzadko płacą, jeśli twoja praca nie opuści deski do wymazywania na sucho. Nienawidzę patrzeć, jak doprowadzasz się do szaleństwa na tak wczesnym etapie kariery.