Czy można napisać oprogramowanie, które nie wymaga ciągłej modyfikacji?

23

Napisałem dużo oprogramowania w wielu różnych językach, a także „napisałem” sprzęt do użytku z FPGA przy użyciu Verilog i VHDL.

Lubię pisać sprzęt bardziej niż oprogramowanie i myślę, że jednym z głównych powodów jest to, że można pisać sprzęt, który jest „zrobiony” i nigdy nie wymaga modyfikacji: definiujesz interfejsy i funkcjonalność, piszesz stanowisko testowe , zaimplementuj moduł sprzętowy, a następnie przetestuj go za pomocą symulatora. Następnie możesz polegać na tym module sprzętowym jako bloku konstrukcyjnym, aby stworzyć coś większego i lepszego: jeśli chcesz dodać funkcję do tego modułu, możesz utworzyć drugi moduł i tam dodać funkcjonalność. Nigdy nie wyrzucasz oryginalnego modułu, ponieważ działa dobrze i nadal może być przydatny.

Jedną z moich głównych frustracji związanych z oprogramowaniem jest to, że nigdy nie jest ono „gotowe”. Zawsze można dodać inną funkcję. Często po dodaniu funkcji wprowadza błąd w innym miejscu, który wcześniej działał dobrze. Nie dzieje się tak w przypadku sprzętu, dopóki interfejsy nie zostaną naruszone.

Żeby było jasne, nie zalecam budowania jednej wersji czegoś z listą funkcji i to wszystko na zawsze: jestem za iteracjami i wieloma wydaniami z czasem, aby dodać nowe funkcje. Po prostu nie chcę naciskać kodu po lewej stronie i znaleźć błędu po prawej stronie, a wydaje się, że dzieje się tak po dodaniu nowej funkcji.

Czy można napisać oprogramowanie w podobny sposób, w jaki „sprzęt” jest zapisywany? Czy istnieje dobra metodologia tworzenia oprogramowania, która pozwala zawsze robić postępy i umożliwia dodawanie nowych funkcji bez konieczności przepisywania istniejącego kodu i wprowadzania nowych błędów?

Nathan Farrington
źródło
8
Wygląda na to, że opisujesz OCP
Oded
Te rzeczy z otwartymi i zamkniętymi zasadami wyglądają świetnie! Czy ktoś wykorzystał to z powodzeniem?
Nathan Farrington,
2
@NathanFarrington: Większość wzorców projektowych (zgodnie z opisem GOF ) jest zgodna z OCP. Przykładem może być wzorzec metody szablonu .
Spoike,
2
@NathanFarrington Zasada otwartego zamknięcia jest powszechną zasadą stosowaną przez programistów przy projektowaniu oprogramowania.
Jesper
1
Wyobrażam sobie, że wiele programów, z których korzystamy dzisiaj, jest tworzonych przy użyciu fragmentów, które są kopiami do kodu napisanego 20 lat temu.
Mallow

Odpowiedzi:

16

Może ma to coś wspólnego z dobrze zdefiniowanymi interfejsami i testami, takimi jak sprzęt?

Dokładnie moje myśli!

Dobrze zaprojektowane moduły z przejrzystymi interfejsami są zasadniczo idealne. Pomyśl o czymś takim jak Stringklasa Java. Jest to program komputerowy, ale ma krystalicznie czysty interfejs. Nie ma w nim żadnych znanych błędów. Doskonale robi to, co powinien. Jasne, został gruntownie przetestowany w ciągu ostatnich 15 lat, a ponieważ praktycznie wszystkie programy używają Strings jako podstawowych elementów składowych, każdy błąd w nim zostanie szybko zauważony. Wszelkie „dziwactwa” - nie tylko błędy, ale szczegóły konstrukcyjne, o których warto wiedzieć - takie jak te opisane tutaj http://www.jwz.org/doc/java.html są już dobrze znane i dlatego można je wziąć pod uwagę konto.

Błędne oprogramowanie jest częściowo kwestią kulturową: ludzie są przyzwyczajeni do błędnego oprogramowania, a w przeciwieństwie do sprzętu, oprogramowanie można zwykle łatwo później naprawić, więc nie musi ono początkowo być doskonalone (lub nigdy, ponieważ hej, musimy teraz wysłać, naprawmy w następnej wersji). Ale w dużej mierze jest to prawdziwy problem ze złożonością: złożoność oprogramowania stale rośnie od około 50 lat, ale ludzki mózg jest taki sam. Kiedy rosnące trudności w osiągnięciu doskonałości i rosnąca łatwość naprawiania rzeczy później (szybkie, automatyczne kompilacje, dystrybucja internetowa) łączą się z presją harmonogramu i brakiem dyscypliny, wynik jest taki, jaki jest.

Czy istnieje dobra metodologia tworzenia oprogramowania, która pozwala zawsze robić postępy i umożliwia dodawanie nowych funkcji bez konieczności przepisywania istniejącego kodu i wprowadzania nowych błędów?

Prawdopodobnie nie ma srebrnej kuli, ale dobre połączenie najlepszych praktyk, w tym między innymi:

  • Proste, autonomiczne moduły. Innymi słowy, niskie sprzężenie i wysoka kohezja.
  • Niezmienność. Szczególnie ważne przy rosnącej współbieżności.

Warto zauważyć, że oba punkty mają na celu zmniejszenie złożoności. To jest kluczowy punkt. Entropia zawsze ma tendencję wzrostową i jeśli nie będziemy z tym walczyć, wkrótce utoniemy w złożoności. Interesujące jest również to, że w ciągu ostatnich kilku lat języki programowania ewoluowały w kierunku zachęcania, a nawet egzekwowania wyżej wymienionych praktyk. Szczególnie wzrost liczby języków funkcjonalnych jest taki: czyste funkcje zawsze zwracają tę samą wartość dla tego samego wejścia, nie ma w nich żadnego stanu . Następnie po prostu komponujesz czyste funkcje, które przyjmują i zwracają niezmienne wartości , i ograniczasz nieuchronną zmienność do małych, dobrze określonych miejsc, zamiast rozprzestrzeniać je dookoła. Sprawdź to: http://clojure.org/state

Joonas Pulakka
źródło
1
jwz nie do końca zgadza się, że klasa String jest wolna od błędów - jwz.org/doc/java.html
1
Może działać zgodnie z planem, więc pytanie brzmi, czy projekt bazowy jest zepsuty. Zgadzam się jednak, że String jest bardzo niezawodną klasą.
1
Doskonała odpowiedź. Teraz koduję prawie wyłącznie w języku Python i próbuję wykorzystać funkcjonalne konstrukcje programowania. Tak, myślę, że masz rację, że niezmienność jest kluczem. Gdy pierwszy raz tworzę moduł oprogramowania, nawet jeśli go testuję, prawdopodobnie zepsułem interfejs, a może ponosi niewłaściwą odpowiedzialność lub zbyt wiele. Robię więc drugi moduł i zostawiam pierwszy w spokoju! Nadal mogę korzystać z pierwszego modułu w przyszłości, jeśli chcę, ale nigdy go nie zmieniam, ponieważ chociaż nie jest doskonały, działa. Tak więc języki funkcjonalne z niezmiennością mogą pomóc tak, jak sugerujesz.
Nathan Farrington
1
@JoonasPulakka: Tak, jeśli w jednym wierszu jest podsumowanie oprogramowania, może to być „zawsze inny błąd”. :-) I myślę, że to jeden z punktów Nathana.
Ross Patterson
1
Joonas, wygrywasz. Zacząłem uczyć się Clojure. Wygląda to na najlepszy sposób, aby programowanie znów było zabawne.
Nathan Farrington,
9

Różnica polega na tym, o ile łatwiej i taniej jest modyfikować oprogramowanie w porównaniu ze sprzętem. Gdyby sprzęt był tak łatwy i tani w modyfikacji i wysyłaniu do klientów, zrobiliby to.

Myślę, że gdybym mógł podsumować moje źle sformułowane pytanie, byłoby to coś w stylu „jak mogę mieć więcej zabawy z pisaniem oprogramowania, nie wprowadzając błędów do działającego kodu i zawsze robiąc postępy?” Może ma to coś wspólnego z dobrze zdefiniowanymi interfejsami i testami, takimi jak sprzęt?

Zdecydowanie powinieneś sprawdzić rozwój oparty na testach .

RCE
źródło
Wiele odpowiedzi na moje pytanie wydaje się zawierać folklor. Czy koniecznie łatwiej jest znaleźć i naprawić błędy oprogramowania niż zaprojektować je od samego początku? Ile kosztuje modyfikacja oprogramowania? Prawdopodobnie nikt tak naprawdę nie wie. Jeśli chodzi o rozwój oparty na testach, sensowne jest testowanie oprogramowania, które można ponownie wykorzystać. Oprogramowanie staje się wtedy faktycznym budulcem, a nie kulą błota. Ale nie ma sensu testować oprogramowania, jeśli ma się to zmienić jutro. Myślę, że zastanawiałem się, czy rzeczywiście możemy tworzyć oprogramowanie z elementów składowych, a nie z błota.
Nathan Farrington,
1
@NathanFarrington: Uważam, że istnieje ogromna różnica w sposobie tworzenia specyfikacji sprzętu / oprogramowania. Większość producentów sprzętu ma najprawdopodobniej lepsze specyfikacje tego, co robią, niż programista, którego klient może tylko powiedzieć „Chcę program, który to robi!” Jest prawie pewne, że uzyskasz nowe funkcje, a co nie.
RCE
Pewnie, jeśli jest wiele zmian, niektóre testy mogą również wymagać zmiany, ale to nie jest tak, że zmiany oprogramowania z edytora tekstu na serwer WWW. Twoja funkcja „nowego dokumentu” nadal tworzy nową funkcję, a jej testy powinny być nadal ważne.
RCE
Zwrócił pan uwagę na inną kluczową zasadę: im lepsze są specyfikacje, tym mniej zmian jest wymaganych na drodze. Ale nie o to mi chodziło w moim pytaniu, ponieważ możesz dodawać funkcje do sprzętu przed jego wykonaniem, tak jak w przypadku oprogramowania. Myślę, że OCP była prawdziwą odpowiedzią, niestety jest to komentarz, więc nie mogę zaznaczyć tego jako odpowiedzi. Kolejnym punktem było zawsze robić postępy i myślę, że TDD może temu pomóc, zapewniając testy regresji.
Nathan Farrington,
Zmiana oprogramowania wydaje się łatwiejsza i tańsza niż sprzęt, ale czy to naprawdę? Tak, mogę dokonać zmiany i niemal natychmiast stworzyć nową kompilację jednym naciśnięciem palca. Jednak kompilacja nadal musi przejść weryfikację / kontrolę jakości. Jaki był koszt alternatywny? Co bym zrobił zamiast naprawić ten błąd? Co zrobiliby QA, gdyby nie musieli ponownie sprawdzać poprawności oprogramowania. Czy odrzucono różne projekty, aby wprowadzić tę poprawkę na rynek? Istnieje wiele „ukrytych” kosztów, o których ludzie nie myślą. Może to być łatwiejsze, ale niekoniecznie tańsze.
Pemdas,
6

Skomentuję niektóre z twoich uwag, mając nadzieję, że uzyskasz odpowiedź od tych komentarzy.

Jedną z moich głównych frustracji związanych z oprogramowaniem jest to, że nigdy nie jest ono „gotowe”.

Wynika to z faktu, że specyfikacja rozwiązania jest niekompletna lub dlatego, że plan dostarczenia ulepszeń nie jest dokładny. Może się to zdarzyć w przypadku dowolnego oprogramowania projektu, sprzętu lub dowolnego innego.

Czy istnieje dobra metodologia tworzenia oprogramowania, która pozwala zawsze robić postępy i umożliwia dodawanie nowych funkcji bez konieczności przepisywania istniejącego kodu i wprowadzania nowych błędów?

Oczywiście tworzenie niezależnych modułów powinno znacznie zmniejszyć zależność. Należy to wziąć pod uwagę podczas projektowania oprogramowania. Musisz wziąć pod uwagę oddzielenie problemów, warstw, poziomów, obiektów kontrolera, interfejsów itp.

„jak mogę mieć więcej zabawy z pisaniem oprogramowania, nie wprowadzając błędów do działającego kodu i zawsze robiąc postępy?”

1 - Dokładnie zrozum wymagania. Być może trzeba rozważyć zamknięcie wymagań przed projektowaniem. Jeśli wykonasz iteracyjny rozwój, nie ma takiej możliwości. Niektóre metodologie zachęcają do tego, ale osobiście uważam, że nie jest to dobre dla wszystkich typów projektów. Budowanie oprogramowania na solidnych wymaganiach pozwala na lepsze projektowanie.

2-Spraw, aby użytkownik zrozumiał tę filozofię długiego rybitwy.

3-Planowe wdrożenie ostrożnie

4-Design przed kodem.

5-W razie potrzeby użyj ogólnego projektu.

6-Użyj prototypów jako narzędzia do potwierdzania projektu.

Bez szans
źródło
To są doskonałe porady. Podsumowując moje przemyślenia do tego momentu: (1) uczyń wydania DUŻĄ OFERTĘ i wykonaj wiele testów i kontroli jakości przed wydaniem, (2) uczyń moduły DUŻĄ OFERTĄ i upewnij się, że mają dobrze zdefiniowane udokumentowane interfejsy z testami dla tych interfejsy i stwierdzenia, aby sprawdzić, czy interfejs został naruszony, a po „zwolnieniu” modułu nigdy nie jest modyfikowany (OCP).
Nathan Farrington,
4

Jak ludzie zwykle bardzo szybko zwracają uwagę, jedną z zalet oprogramowania jest to, że jego wymiana w porównaniu ze sprzętem powinna być łatwa i stosunkowo tania. Jest to szczególnie ważne, gdy późno zdasz sobie sprawę, że masz coś zasadniczo nie tak. Zrób to samo ze sprzętem, a stracisz milion dolarów, więc, jak powiedziałeś, używasz symulatorów itp. I testujesz na nim bazingę. Wydaje mi się, że w tym przypadku paradygmat zawodzi, gdy przechodzisz na oprogramowanie.

Wejdź do głowy przeciętnego programisty, a to, co masz, to bardzo zajęta osoba z niewiarygodnie krótkim terminem. Jego menedżer twierdzi, że można zostawić kilka błędów, ponieważ zawsze można to naprawić później. Testy są często przemyślane, ale nawet w scenariuszu opartym na testach testy są utrzymywane na minimalnym poziomie, a kod jest zapisywany na minimum testów, a często są stosowane skróty, aby można było pominąć wiele przypadków granicznych. System może być dokładnie testowany jednostkowo, ale rzadko jest rygorystycznie testowany jako całość, a równie rzadko w dużym stopniu testowany pod obciążeniem. Dodaj do tego, że piszesz oprogramowanie od zera, a istnieje niewielka szansa na symulację oprogramowania, zanim zdecydujesz się go napisać, głównie dlatego, że rzadko piszemy oprogramowanie z tego samego rodzaju drobnoziarnistych elementów konstrukcyjnych, które można znaleźć w sprzęcie.

Powrót do pytania PO. Czy potrafisz zdefiniować system bloków konstrukcyjnych, z których będzie czerpać całe oprogramowanie? Możliwie. Czy byłoby to bardzo opłacalne? Prawdopodobnie nie, ponieważ zanim zaczniesz opracowywać wystarczająco solidny system komponentów, testów i innych akcesoriów, aby wesprzeć ten ideałsystem programowania, przekonasz się, że konkurencja pokonałaby cię już na rynku, a co gorsza, z punktu widzenia przeciętnego programisty prawdopodobnie znalazłbyś styl programowania typu „ciasteczka”, który jest bardzo ograniczający i bardziej prawdopodobne nudny. Osobiście pracuję nad interfejsem API, w którym większość kodu modułu została dopracowana i ujednolicona tak całkowicie, że teraz wszystko, co robię, to wygenerowanie szablonu kodu i wypełnienie pustych pól. Większość czasu spędzam na pisaniu prostego kodu złącza i jak najszybszym wyciągnięciu modułów z drzwi. Poważnie odrętwia umysł. Jest bardzo mało okazji do zrobienia więcej niż tylko kodowania tego samego rodzaju rzeczy w kółko, więc kiedy pojawia się kolejna szansa na projekt, podskakuję na okazję, by móc zrobić WSZYSTKO.

Jak więc uzyskać wysokiej jakości i dobrze przemyślane oprogramowanie, a jednocześnie czerpać z tego przyjemność? Wierzę, że sprowadza się to do wyboru narzędzi i metodologii. Dla mnie odpowiedzią było zastosowanie dobrego API BDD, ponieważ pozwoliło mi to na stworzenie bardzo łatwego do odczytania, ale bardzo szczegółowego kodu. Potrafię zbudować zestaw testów z minimalnej liczby metod wielokrotnego użytku i opisać je w języku specyfikacji. W ten sposób zbliżam się do bardziej złożonego podejścia programistycznego, z wyjątkiem tego, że jestem odpowiedzialny za projektowanie i sprawdzanie bloków konstrukcyjnych. Ponadto dane wyjściowe testu wskazują dokładną część testu, w której występuje awaria, dzięki czemu nie muszę zgadywać, czy awarie występują w konfiguracji, czy w stwierdzeniu.

Pomaga także dostosowanie metodologii. Jestem wielkim zwolennikiem stosowania zasad Lean Development i łączenia ich z wieloma innymi technikami i zasadami, o których ruch Agile walczy od wielu lat. Po wyeliminowaniu większości marnotrawnych praktyk, które uważałem za tak frustrujące, bardzo pomogłem uczynić rozwój przyjemniejszym. Nadal mam problem z tym, że czasami - ale mam nadzieję, że niezbyt często - błędy pojawią się w moim kodzie, ale teraz mam więcej czasu i jeszcze więcej motywacji, by spędzać więcej czasu na pisaniu solidniejszych testów i dążeniu do 100 % pokrycia testowego. Co więcej, naprawdę fajnie jest widzieć te wszystkie zielone światła, które pojawiają się pod koniec mojego dnia,

S.Robins
źródło
Jestem ciekawy, że piszesz, że testowanie jest ważne, ale także odrętwiałe.
Nathan Farrington,
@NathanFarrington Dzięki za zwrócenie na to uwagi. Chodziło mi o pozytywne rozmawianie o testowaniu, ale myślałem o tym, pisząc coś innego, więc w tym akapicie było zupełnie źle! Poprawiłem, aby pasował do faktycznego punktu, który próbowałem oświetlić!
S.Robins,
3

Jedną z moich głównych frustracji związanych z oprogramowaniem jest to, że nigdy nie jest ono „gotowe”. Zawsze można dodać inną funkcję.

Jeśli to Cię frustruje, rozważ inną karierę. Poważnie.

Punkt oprogramowania jest aby móc dodać funkcje. Głównym powodem wynalezienia „oprogramowania” było przede wszystkim umożliwienie dodania funkcji.

Często po dodaniu funkcji wprowadza błąd w innym miejscu, który wcześniej działał dobrze.

To problem z kontrolą jakości.

Nie dzieje się tak w przypadku sprzętu, dopóki interfejsy nie zostaną naruszone.

Dotyczy to również oprogramowania.

Czy istnieje dobra metodologia tworzenia oprogramowania, która pozwala zawsze robić postępy i umożliwia dodawanie nowych funkcji bez konieczności przepisywania istniejącego kodu i wprowadzania nowych błędów?

Tak. Musisz przećwiczyć Zapewnienie Jakości.

S.Lott
źródło
1
Nawiasem mówiąc, nie próbuję trollować i może nie jestem przygotowany na oprogramowanie. Mówisz jednak, że „celem oprogramowania jest możliwość dodawania funkcji”. Czy to naprawdę von Neumann wynalazł oprogramowanie, które jest w stanie zbudować komputer, który mógłby obliczyć więcej niż jedną funkcję matematyczną bez konieczności ponownego wprowadzania jednostek logicznych i arytmetycznych. Jestem ciekawy, skąd bierze się ta filozofia funkcji oprogramowania. Sprzęt ma funkcje, ale celem sprzętu nie jest dodawanie funkcji.
Nathan Farrington,
Zakładam, że przez Quality Assurance masz na myśli testowanie. Tak, moja intuicja mówi, że do wytworzenia wysokiej jakości oprogramowania wymagane są szeroko zakrojone testy. Ale myślę, że wykracza poza to. W sprzęcie moduł może zawierać błąd. Ale po dodaniu nowego sprzętu nie wprowadza nowych błędów do istniejącego modułu sprzętowego. W końcu wszystkie błędy we wszystkich modułach można znaleźć i naprawić. Ale w oprogramowaniu często kod jest zmieniany (moduły są zmieniane) zamiast dodawany, co może wprowadzać błędy. Chyba szukałem metodologii tworzenia oprogramowania, która byłaby czysto addytywna.
Nathan Farrington
Mam teraz bardziej inteligentny komentarz do twojej odpowiedzi. Powodem, dla którego zwróciłem uwagę na to, że oprogramowanie nigdy nie było „zrobione”, jest prawdopodobnie to, że zawsze stosowałem bardzo luźne podejście do wydań. Jedna nowa funkcja to kolejna wersja, bez testów regresji i bardzo małej ilości kontroli jakości. Gdyby wydania były DUŻĄ OFERTĄ, założę się, że moje niedociągnięcia związane z tym, że oprogramowanie nigdy nie zostało zrobione, zniknęłyby.
Nathan Farrington
@NathanFarrington: Turing wynalazł oprogramowanie do łamania ciągle zmieniających się kodów Enigmy. „przez Quality Assurance masz na myśli testowanie”. Fałszywe. Mam na myśli Zapewnienie Jakości - każdy aspekt rozwoju powinien mieć standardy jakości, które należy spełnić. Testowanie jest jednym (ograniczonym) sposobem oceny jakości jednego rodzaju artefaktu. „kod został zmieniony ... co może wprowadzać błędy”. Poprawny. Jest to błąd zapewnienia jakości - nie jest nieodłączną cechą oprogramowania.
S.Lott,
Zdecydowanie zrywamy temat. Według tego linku Toss's Colossus nie był uniwersalny (w sensie komputerowym) i nie korzystał z zapisanych programów (oprogramowania).
Nathan Farrington,
2

Czy można napisać oprogramowanie w podobny sposób, w jaki „sprzęt” jest zapisywany? Czy istnieje dobra metodologia tworzenia oprogramowania, która pozwala zawsze robić postępy i umożliwia dodawanie nowych funkcji bez konieczności przepisywania istniejącego kodu i wprowadzania nowych błędów?

Polecam przyjrzeć się „ formalnym metodom ” weryfikacji poprawności projektów i oprogramowania. Narzędzia symulatora używane do projektowania sprzętu próbują zrobić coś blisko. Nie wierzę, że narzędzia metod formalnych są w tej chwili blisko przydatne w przemyśle, a jedynymi branżami, które mają silną motywację do bycia wolnymi od wad, są awionika i medycyna (co ciekawe, FDA wyraźnie stwierdza, że ​​„oprogramowanie jest inne ze sprzętu ”pod tym linkiem). Ponadto, jeśli programujesz z Verilog / VHDL, to trzymasz się logiki binarnej. To drastycznie zmniejsza złożoność. Nie będzie sprzętu równoważnego z problemem Y2K.

Dużym problemem jest to, że rzeczy są złożone. Nie można wyeliminować złożoności, można ją jedynie przenosić.

Tangurena
źródło
1

możliwe jest napisanie sprzętu, który jest „zrobiony” i nigdy nie musi być modyfikowany: definiujesz interfejsy i funkcjonalność, piszesz stanowisko testowe, wdrażasz moduł sprzętowy, a następnie testujesz go za pomocą symulatora. Następnie możesz polegać na tym module sprzętowym jako bloku konstrukcyjnym, aby stworzyć coś większego i lepszego: jeśli chcesz dodać funkcję do tego modułu, możesz utworzyć drugi moduł i tam dodać funkcjonalność. Nigdy nie wyrzucasz oryginalnego modułu, ponieważ działa dobrze i nadal może być przydatny.

W świecie oprogramowania nazywamy ten „moduł” biblioteką i używamy go w ten sam sposób. Wiele bibliotek jest zbudowanych do tego stopnia, że ​​działają dobrze, a następnie siedzą zadowoleni, wykonując swoje zadania bez zmian, dopóki coś ważnego nie doprowadzi do następnej wersji. Pomyśl o nich jak o oprogramowaniu z żywicą epoksydową :-)

Jedną z moich głównych frustracji związanych z oprogramowaniem jest to, że nigdy nie jest ono „gotowe”. Zawsze można dodać inną funkcję. Często po dodaniu funkcji wprowadza błąd w innym miejscu, który wcześniej działał dobrze. Nie dzieje się tak w przypadku sprzętu, dopóki interfejsy nie zostaną naruszone.

Bzdury. Być może jesteś osobiście lepszy od wielu innych „nie-lutowniczych” osób „sprzętowych”, ale widziałem wiele złych konstrukcji obwodów, wadliwych układów ( np . Słynny problem Intel „f00f”), ale to nie mówić do pola jako całości. A ponieważ sztuczne wyroby stają się „bardziej miękkie”, problemom trudniej jest zapobiec.

Czy można napisać oprogramowanie w podobny sposób, w jaki „sprzęt” jest zapisywany? Czy istnieje dobra metodologia tworzenia oprogramowania, która pozwala zawsze robić postępy i umożliwia dodawanie nowych funkcji bez konieczności przepisywania istniejącego kodu i wprowadzania nowych błędów?

Tak. Po prostu nie używamy tych metod zbyt często. Są zwykle bardzo drogie w obsłudze, a większość programistów nie lubi pracy w ramach swoich ograniczeń. Ale kiedy zaangażowane jest życie ludzkie, na przykład: tak, staramy się nie zabijać użytkowników.

Ostatni punkt: oprogramowanie ma inny model finansowy niż sprzęt, nawet zaprogramowany sprzęt. Większość oprogramowania niebędącego konsumentem, a także niektóre oprogramowanie konsumenckie, jest sprzedawana w sposób zachęcający do zmian. Gdy powiesz firmie: „Zapłać nam teraz 10 000 USD plus 18% rocznie”, możesz zasadniczo odsprzedać produkt co kilka lat. Ale aby uzasadnić tę opłatę, musisz dać klientowi pożądane zmiany. Hmm ... myśląc o krzywej starzenia się sprzętu Apple, być może to wcale nie jest różnica - sprzęt sprawia, że naprawdę go kupujesz!

Ross Patterson
źródło
Nigdy nie mówiłem, że jestem lepszy niż ktokolwiek. ;-) Gdy sprzęt ma błąd, staje się nowością. Kiedy oprogramowanie ma błąd, czekaj, oprogramowanie zawsze ma błędy. Z jakich metod nie korzystamy, ponieważ są zbyt drogie i nie są zabawne?
Nathan Farrington
0

jak mogę mieć więcej zabawy z pisaniem oprogramowania, nie wprowadzając błędów do działającego kodu i zawsze robiąc postępy?

Chciałbym znaleźć ostateczną odpowiedź na twoje pytanie. Ale w rzeczywistości nie ma łatwego sposobu, aby to zrobić, dlatego ekstremalne techniki programowania i TDD stają się tak popularne. Musisz zaakceptować zmianę, ponieważ to się stanie. Nie wiem, czy to jest zabawniejsze w ten sposób, ale na pewno o wiele mniej stresujące ;-)

http://en.wikipedia.org/wiki/Extreme_Programming

Kiedy wchodzisz w interakcje ze sprzętem, sprzęt potrzebuje wartości x i to wszystko (teoretycznie), ale kiedy dzisiaj wchodzisz w interakcje z ludźmi, potrzebują x, a jutro mogą potrzebować y itp. Tak to jest, zmieniają się wymagania biznesowe i ludzi . Ponieważ Persons! = Maszyny, więc kod, który NIGDY się nie zmienia przez większość czasu, nie jest możliwy.

Również, jak powiedziałem w mojej poprzedniej / usuniętej odpowiedzi, staraj się unikać zmian, które nie są ważne, zmuszając ludzi do myślenia przed rozpoczęciem kodowania. Zaangażuj użytkowników bardziej w podejmowanie decyzji itp. Wyjaśnij koszty zmian, planuj więcej itp. To nie są „sposoby kodowania”, to sposoby „nie kodowania”, ponieważ przy większej liczbie wymagań będzie mniej zmian i więcej zabawy.

H27studio
źródło
1
Dobra odpowiedź. Zrobiłem programowanie ekstremalne. Wydaje się być dokładnym przeciwieństwem tego, czego szukałem, gdzie cały kierunek projektu może zmieniać się co tydzień w zależności od kaprysu klienta. Nie jestem przeciwny wydaniom iteracyjnym, po prostu nie chcę, aby druga wersja zawierała błędy, które nie były obecne w pierwszej wersji. I masz rację, że projekt z przodu może zaoszczędzić wysiłek na dłuższą metę.
Nathan Farrington,
Jak zawsze mówię, najlepszym kodem jest brak kodu. :-)
H27studio
0

Czy można napisać oprogramowanie w podobny sposób?

Tak to jest. Bądź tak ostrożny, jakbyś tworzył sprzęt, przetestuj wszystko, co możesz, a twoje oprogramowanie będzie podobnej jakości.

a propos, nie słyszałeś o błędach HW? Znacznie bardziej nieprzyjemny niż jakikolwiek błąd SW i trudniejszy do naprawienia (nie tylko aktualizacja oprogramowania)

BЈовић
źródło
1
Tak, sprzęt ma również błędy, nawet dojrzały, dobrze przetestowany sprzęt, taki jak procesory. Dobry sprzęt został zaprojektowany tak, aby można było naprawić błędy sprzętowe w oprogramowaniu! Powodem mojego pierwotnego pytania jest to, że napisałem dużo oprogramowania, ale zawsze denerwowało mnie, jak łatwo jest wprowadzać błędy i jak bałaganił cały system. Jestem typową osobą, więc metodologia opracowywania sprzętu zawsze wydawała mi się bardziej naturalna. Może to mieć również związek z zakresem.
Nathan Farrington
1
@NathanFarrington Oprogramowanie jest zwykle bardziej złożone niż sprzęt. Sprzęt jest testowany dokładniej. SW może się zmieniać łatwiej, dlatego ludzie nie zwracają tak dużej uwagi.
BЈовић
0

Chciałbym również zauważyć, że błędy oprogramowania w sprzęcie często zabijają ludzi. Dlatego dokłada się starań, aby dokładnie określić wymagania i dokładnie je przetestować. Te wymagania nie muszą się zmieniać, dopóki nie zmieni się sprzęt. A ponieważ nowy sprzęt może wymagać przepisania, podejrzewam, że cruft też się tak bardzo nie gromadzi.

Z drugiej strony wymagania biznesowe stale się zmieniają, czasem trudno jest wprowadzić jedno wymaganie do produkcji, zanim poprosi się o zmianę. Czasami musiałem zmieniać wymagania wiele razy, zanim dotarł do produkcji. Jest to wynikiem kilku rzeczy. Po pierwsze, interesariusz projektu po stronie biznesowej jest często mniej zainteresowany spędzeniem czasu na dokładnym zdefiniowaniu tego, czego chce, ponieważ jest „zajęty” i „ważny”, a ludzie nie umrą, a rodziny pozwać go lub wtrącić do więzienia, jeśli zdmuchuje swoją część procesu. Po drugie, interesariusze projektu zwykle mają lepsze pojęcie o tym, co chcą, aby sprzęt był wykonywany, ponieważ jest to dla nich mniej abstrakcyjne. Naprawdę nie wiedzą, czego chcą, dopóki tego nie zobaczą. Co jest mniej problematyczne ze sprzętem.

HLGEM
źródło
Masz ważny punkt. Rodzaje rzeczy, które tradycyjnie wytwarzamy w sprzęcie, są dobrze rozumiane: procesory, kontrolery USB, punkty końcowe PCI Express, kontrolery pamięci itp. Następnie wprowadzamy całą logikę biznesową aplikacji do oprogramowania. Może podczas pracy nad oprogramowaniem stosy stają się coraz bardziej chaotyczne i mniej zrozumiałe?
Nathan Farrington
-1

Istnieją narzędzia wysokiego poziomu z wieloma gotowymi „klockami”, jak je nazywacie, które można łączyć w aplikacje. Cegły są gotowymi elementami do użycia, wystarczy je połączyć. Może uważasz, że to łatwiej ... dopóki twój klient nie poprosi cię o jakieś dziwne i nieoczekiwane zmiany.

AndSoYouCode
źródło