Jak przekonać mojego szefa, że ​​ANSI C jest nieodpowiedni do naszego nowego projektu? [Zamknięte]

Kilka miesięcy temu zaczęliśmy opracowywać aplikację do kontroli opracowanego przez nas sprzętu testowego i rejestrować zestaw pomiarów. Powinien mieć prosty interfejs użytkownika i prawdopodobnie wymagałby wątków ze względu na ciągłe nagrywanie, które musi mieć miejsce. Ta aplikacja będzie używana przez kilka lat i będzie utrzymywana przez wielu studentów informatyki w tym okresie.

Nasz szef ukończył szkołę jakieś 30 lat temu (nie należy tego traktować jako przestępstwo; mam też ponad połowę tego czasu na plecach) i nakazał nam opracowanie tej aplikacji w ANSI C. Uzasadnieniem jest to, że on jest jedynym, który będzie przez cały czas i dlatego musi być w stanie zrozumieć, co robimy. Orzekł również, że nie powinniśmy używać abstrakcyjnych typów danych; podał nam nawet listę zmiennych globalnych (westchnienie), których chce, abyśmy użyli.

Próbowałem tego podejścia przez jakiś czas, ale tak naprawdę spowalniało mnie to, aby upewnić się, że wszystkie operacje wskaźnika są bezpieczne i że wszystkie łańcuchy mają odpowiedni rozmiar. Ponadto liczba wierszy kodu, które faktycznie dotyczyły danego problemu, stanowiła tylko niewielką część naszej bazy kodu. Po kilku dniach wyrzuciłem całość i zacząłem od nowa, używając C #. Nasz szef widział już działający program i podoba mu się sposób jego działania, ale nie wie, że napisano go w innym języku.

W przyszłym tygodniu spotkamy się, aby omówić kod źródłowy, aby „wiedział, jak go zachować”. Jestem trochę przestraszony i chciałbym usłyszeć od was, jakich argumentów mógłbym użyć na poparcie mojej decyzji.

Twój tchórzliwy,

Zauważ, że „Zrób to w ten sposób, więc jestem pewien, że mogę to utrzymać” jest w rzeczywistości bardzo dobrym wymogiem - większość programów spędza dużo więcej czasu na utrzymywaniu niż na pisaniu, a utrzymanie rozwiązania w znanej technologii jest zwykle dobrym pomysłem.

Wyobraź sobie, że jakiś nowy komputerowiec, gdy zostanie poproszony o napisanie aplikacji C #, napisał ją w Haskell w ciągu dwóch dni i powiedział: „Hej, to działa, a mnie nie ma, pa”, pozostawiając na tobie utrzymanie.

Wyobraź sobie, że jakiś nowy komputerowiec zapytany o napisanie aplikacji ANSI C 15 lat temu napisał ją w Visual Basic 6 w ciągu dwóch dni i zostawił. Teraz musisz go utrzymać, a system Windows 7 zaczyna narzekać już po włożeniu nośnika instalacyjnego .

To może być dobra okazja, aby powiedzieć - jak zasugerował Heinzi w komentarzach - że „jest to szybki prototyp napisany w języku C #, który wygląda bardzo podobnie do C - czy powinniśmy przygotować go do produkcji lub zaimplementować w ANSI C, tak jak ty zapytał ”, a następnie weź teraz dyskusję. Posiadanie faktycznego źródła do zobaczenia jest znacznie lepsze niż „Hej, nie powinniśmy pisać naszej następnej aplikacji w Haskell, ponieważ jest szybsza”.

Innymi słowy - masz teraz możliwość wykazania, że ​​można rozważyć nową platformę. Przywołaj, że napisałeś prototyp przed przeglądem kodu - pomoże to usunąć wrażenie, że próbujesz zakraść C # pod radarem. Sugerowałbym również wykazanie, że cały istniejący kod napisany w ANSI C może być używany z poziomu C #. Osobiście uważam, że dowiesz się, że celem pozostaje ANSI C, aby pozostać na jednej platformie.

W tym przypadku wydaje się, że twój szef jest twoim klientem, a jego podstawowym wymogiem jest, aby był w stanie utrzymać aplikację, gdy będziesz się poruszać. To wydaje się całkiem rozsądne.

Zatem wybór polega na zrobieniu tego, o co prosi, lub zademonstrowaniu, że można ukończyć programowanie ORAZ nauczyć go, jak utrzymywać aplikację C # w ograniczonym czasie i przy niższych kosztach. Jeśli nie możesz tego zrobić, nie spełniasz wymagań projektu.

Nie podałeś wielu informacji, ale myślę, że C jest absolutnie właściwym wyborem - pracuję jako inżynier w zakładzie przemysłowym i większość (jeśli nie całość) naszego kodu jest napisana w C. Jeśli potrzebujesz uzyskać pomiary z urządzenie (zakładam, że przepływomierz, termopara lub podobne tutaj) i wyświetlanie go w czasie zbliżonym do czasu rzeczywistego C jest doskonałym wyborem.

Jest szybki, przenośny (nigdy nie pisałem w C #, ale nie sądzę, że działa bez konkretnej wersji frameworka i zwykle jest oparty tylko na systemie Windows).

Oczywiście można użyć innego języka, aby wykonać GUI. Ale możesz zaoszczędzić sobie wysiłku i po prostu użyć wcześniej istniejącego pakietu trendów (dostępnych jest kilka dobrych programów typu open source).

Podsumowując, powiedziałbym, że bazowe połączenie z częścią sprzętową C jest dobrym wyborem.

O jej. To jest aplikacja w czasie rzeczywistym? Kontrolujesz sprzęt w czasie rzeczywistym? Gromadzisz dane w czasie rzeczywistym? Używasz języka ze śmietnikiem? O jej.

Chociaż zgadzam się, że prawdopodobnie możesz zrobić aplikację w bardziej nowoczesnym języku w krótszym czasie, prawdopodobnie nie jest to główne kryterium. ŁATWOŚĆ PROGRAMOWANIA JEST PRAWDOPODOBNIE MNIEJSZA WAŻNA NIŻ INNE KRYTERIA, takie jak te ustalone przez szefa, ORAZ czas reakcji i deterministyczne zachowanie.

Sugerowałbym wykonanie prototypu w języku C # lub Python, aby przetestować główną funkcjonalność i interfejs użytkownika. NASTĘPNIE przetestuj to, mierząc rzeczywiste opóźnienia i czasy reakcji, gdy aplikacja trafi dużą ilością danych, przez wiele dni ciągłego działania. Istnieje prawdopodobieństwo, że aplikacja może być zbyt wolna lub pozostawać w tyle w przypadkowych momentach, gdy uruchomi się VM lub moduł wyrzucania śmieci.

Proponuję przedstawić to, co zrobiłeś jako PROTOTYPE.

Kodowanie w C nie jest takie trudne. Jeśli nie masz ochoty, powiedz tak. Jest nas wielu gotowych na wyzwanie. (Zajmuję się kodowaniem C w czasie rzeczywistym, od dziesięcioleci).

Cóż, pierwszą rzeczą do zrobienia jest pójście do szefa i przyznać się. Zignorowałeś jego wyraźną prośbę, a co gorsza robiłeś to od miesięcy. Nie wiem, ile czasu masz na to, ale zakładając, że jest to większość czasu przeznaczonego na realizację projektu, musisz zmierzyć się z faktem, że wkrótce możesz szukać nowej pracy.

Im szybciej sobie z tym poradzisz, tym lepiej.

Po drugie, nie sądzę, abyś mógł go przekonać, że ANSI C jest nieodpowiedni, co musisz zrobić, to przekonać go o kilku innych rzeczach (1), że c # jest wystarczający, (2) może łatwo nauczyć się utrzymywać c #, (3 ), że nie potrafiłeś napisać go w C. Zakładając, że nadal masz pracę i rolę do odegrania w tym projekcie, skoncentrowałbym się na 2, podkreślając podobieństwa między c i c #.

Cytaty w odpowiedzi na komentarze ...

Kilka miesięcy temu zaczęliśmy tworzyć aplikację [...] Po kilku dniach zeskrobałem całość i zacząłem od nowa za pomocą C #

upoważnił nas do opracowania tej aplikacji w ANSI C. Uzasadnieniem jest to, że jest on jedynym, który będzie dostępny przez cały czas, i dlatego musi być w stanie zrozumieć, co robimy.

Jest to dość rozsądny wymóg.

Orzekł również, że nie powinniśmy używać abstrakcyjnych typów danych;

To nie ma sensu. Teraz zaczyna pachnieć nieco podejrzanie, ponieważ jest to wymóg projektowania programu, a nie wymóg językowy. Jeśli kod powinien być łatwy w utrzymaniu, priorytetem powinno być wdrożenie narzędzi ADT lub użycie dobrze przetestowanych, wcześniej istniejących.

podał nam nawet listę zmiennych globalnych (westchnienie), których chce, abyśmy użyli.

Ok, więc teraz śmierdzi. Teraz możemy stwierdzić, że twój szef ma ograniczone doświadczenie nie tylko z różnych języków programowania, ale ogólnie z programowania. Doświadczony programista-weteran, bez względu na preferencje językowe, nigdy by tego nie powiedział. (Jedyny wyjątek, jaki mogę wymyślić, to to, że większość kodu ma działać w dość małym systemie osadzonym, a zatem oczekiwano, że cała niezbędna pamięć robocza dla kodu zostanie wstępnie przydzielona. Pomysł, że ten sam kod jest taki sam oczekuje się jednak, że interfejs użytkownika na poziomie ekranu zdecydowanie temu przeciwdziała).

Zgaduję, że twój szef nigdy nie brał udziału w dużych projektach oprogramowania o kluczowym znaczeniu, ale najprawdopodobniej latał w różnych projektach niskiej jakości.

Nie ma to więc nic wspólnego z językiem programowania C. Możesz łatwo pisać równie złośliwe programy w języku C #. Bardzo częstym błędem jest przekonanie, że dobry projekt programu zależy od języka. To po prostu nieprawda!

C # z pewnością ma ładniejszą, czystszą i mniej niejasną składnię niż C. Ma wiele możliwości projektowania programów, ponieważ ma o wiele więcej słów kluczowych związanych z OO niż C. Ale poza tym nie mówi ci, jak pisać programy. Jeśli uważasz, że wszystko napisane w C jest domyślnie okropne, a wszystko napisane w C # jest domyślnie niebem, założę się, że obecnie piszesz raczej okropne programy w C #, nie zdając sobie z tego sprawy.

Sugeruję, abyś stworzył abstrakcyjny, niezależny od języka, ale szczegółowy projekt programu, zanim cokolwiek innego. Użyj normalnego, obiektowego podejścia. Jakie są tam obiekty i jak się między sobą komunikują, jakie są potrzebne zależności itp. Itp. Kiedy dobrze przemyślisz projekt programu i zapisałeś go na papierze, nie powinno to mieć większego znaczenia dla ciebie ani dla twojego szefa, który język, w którym zdecydowałeś się go wdrożyć.

Pierwszą kwestią, którą musisz rozwiązać, jest emocjonalna, irracjonalna. Branża IT nieustannie się zmienia i chociaż na wszystko jest miejsce, problem stanowi odmowa poprawy lub przyjęcia zmian.

Dlaczego twój szef trzyma się ANSI C? Jeśli jest to jedyny język, który zna, być może nadszedł czas na zmianę, ale racjonalny argument może być niewystarczający. Czy twój szef poczuje się niedoceniany lub być może zwolniony, jeśli zostanie zmuszony do pracy w obcym języku? Podkreśl, jakie ma doświadczenie i jakie inne korzyści przynosi.

Jeśli nie rozwiążesz tego problemu, wszystkie racjonalne argumenty, które możesz przedstawić, zostaną zmarnowane. Jako podwładny możesz nie być tym, który może prowadzić z nim tę dyskusję. Być może porozmawiam o tym z jednym z innych menedżerów, jeśli istnieją.

Zastanów się również nad tym z własnej perspektywy. Dlaczego chcesz używać C #? Ile z tego jest chęć użycia czegoś nowego i fajnego? Bądź ze sobą szczery. Jeśli to rozpoznasz, pomoże ci to w skuteczniejszej sprzeczce.

Druga kwestia dotyczy ryzyka i kosztów. Pisanie oprogramowania jest drogie, a wybór języka jest głównym czynnikiem. Rozważać:

1. Jak długo potrwa pisanie w C # w porównaniu do C? Dzięki łatwiejszej orientacji obiektu i lepszemu usuwaniu śmieci C # może być łatwiejszy. Jeśli jednak aplikacja korzysta z wielu niezarządzanych wywołań interfejsu API, C może być łatwiejsze.
2. Jeśli używasz C #, czy musisz kupić dodatkowe narzędzia? Wygląda na to, że korzystasz już z Visual Studio, ale czy potrzebujesz dodatkowych narzędzi do lokalizacji, przeglądania i analizy kodu, debugowania itd.?
3. Jak łatwo jest utrzymać? Jeśli znajdziesz błąd, jak szybko można go naprawić. C # może zmniejszyć orientację obiektu. Automatyczne zbieranie śmieci pozwala także uniknąć większości problemów z wyciekiem pamięci i wskaźnikiem.
4. Jak łatwo jest wspierać? Jeśli masz personel pomocniczy, mogą wiedzieć, jak odczytać zrzut awaryjny, ale czy wiedzą, jak używać windbg z SOS? Czy na komputerach docelowych jest już zainstalowana odpowiednia wersja środowiska .Net?
5. Zastanów się nad personelem. Ile osób zna C w porównaniu do C #? Jeśli jedno z was lub oboje opuścicie organizację, jak łatwo byłoby was zastąpić? Czy programiści C są tańsi lub drożsi niż programiści C #?

Mógłbym kontynuować, ale chodzi o to, aby przestać spierać się o techniczne zalety samych języków. Zalety techniczne to rzeczy, które rozumiesz tylko Ty i Twój szef. Jeśli zaczniesz mówić o wpływie na biznes, przyciągniesz znacznie szerszą grupę ludzi i przedstawisz o wiele bardziej przekonujący argument.

Może C jest lepszym wyborem. C # nie jest automatycznie lepszy dla wszystkich sytuacji. Być może robisz ten projekt przy użyciu C, ale robisz dowód koncepcji C # dla następnego. Pamiętaj, że możesz przegrać bitwę, ale nadal wygrać wojnę.

Może inny argument: prawdopodobnie bardzo trudno jest znaleźć studentów informatyki, którzy mają wystarczające doświadczenie, aby pisać kod C bez popełniania błędów. ANSI C nie jest pierwszą rzeczą, której ludzie się dzisiaj uczą.

Teraz wszyscy studenci informatyki mnie zabiją.

Zupełnie nie przekonałeś nas, że ANSI C była nieodpowiednia. C to doskonały język, który wydaje się być dostosowany do opisywanych zadań. Z krótkim opisem zadania (oprócz wymogu językowego) poleciłbym również C (a może idź).

Myślę, że problem polega na tym, że programowałeś w C, a twój umysł myślał w C #. Mam podobny problem, kiedy przełączam się z Perla na C lub Java. Musisz nauczyć się dostosowywać do języka, a nie nauczyć się tłumaczyć ze swojego sposobu myślenia na język dnia.

Problemem nie jest twój szef ani język C. Problem polega na otwarciu umysłu na różne sposoby myślenia. Zmiana języka programowania jest dla Ciebie korzystna.

Po pierwsze, musisz teraz powiedzieć swojemu szefowi, że jest w innym języku. Będzie (zrozumiale) zły, jeśli przyniesiesz coś celowo wbrew wymaganiom bez uprzedzenia.

Teraz najlepszym sposobem na wyjaśnienie tych rzeczy szefowi / menedżerom jest przedstawienie ich pod względem czasu i pieniędzy. Oszacuj, ile czasu zajmie taki projekt w ANSI C, a następnie oszacuj, ile czasu zajmie to na wyższym poziomie, takim jak C #. Uwaga: Powiedziałem wyższy poziom, a nie nowoczesny. Może to również pomóc w złagodzeniu sytuacji. Mam na myśli, że nie poradziłbyś sobie z malowaniem pokoju za pomocą małego pędzla, używałbyś wałków i innych rzeczy, które sprawiają, że każde pociągnięcie (linia kodu) obejmuje więcej obszaru projektu. Ponadto, jeśli ty lub jeden z członków waszego zespołu nie znacie C lub nie czujecie się dobrze, robiąc duży projekt w C, to jeszcze bardziej pochłania problem czasowy, ponieważ będą musieli przyspieszyć.

Wygląda również na to, że twój szef próbuje zarządzać. Jestem pewien, że jedna z pozostałych odpowiedzi spróbuje wyjaśnić, w jaki sposób zmusić szefa do zrobienia tego mniej

Awersja superwizora do ADT została skierowana gdzie indziej, podobnie jak pozorna niewiedza deweloperów o kosztach GC, więc skupię się na „wątkach”.

Być może zamiast myślenia w kategoriach wątków .NET (lub JVM, jeśli jest to tak indoktrynowane), możesz chcieć wielu procesów, używając jakiegoś mechanizmu komunikacji międzyprocesowej (IPC) do komunikacji między nimi. Np. - wiadomości systemu Windows, pamięć współdzielona, ​​bufor plików zmapowanych w pamięci, nazwany potok, cokolwiek. Poświęć małe procesy na interakcję z urządzeniem lub aspektem urządzenia i sprawdzanie IPC w celu komunikowania się z aktualizacjami i potwierdzania żądań, a także mieć nieco większy proces utrzymywania GUI i komunikowania się z urządzeniami „monitorującymi” za pomocą dowolnego wybranego IPC.