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

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?

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

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 .

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.

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,

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.

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ć.

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!

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.

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)

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.

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.