Jaka jest twoja najbardziej kontrowersyjna opinia programowa?

Jest to zdecydowanie subiektywne, ale chciałbym uniknąć kłótni. Myślę, że może być interesujące pytanie, jeśli ludzie będą traktować to odpowiednio.

Pomysł na to pytanie zrodził się z wątku komentarza z mojej odpowiedzi na „Jakie jest pięć rzeczy, których nienawidzisz w swoim ulubionym języku?” pytanie . Twierdziłem, że klasy w języku C # powinny być domyślnie zapieczętowane - nie podam mojego uzasadnienia w pytaniu, ale mogę napisać pełniejsze wyjaśnienie jako odpowiedź na to pytanie. Zaskoczyła mnie gorąca dyskusja w komentarzach (obecnie 25 komentarzy).

Jakie masz sporne opinie ? Wolałbym raczej unikać rzeczy, które kończą się względnie religijnie przy stosunkowo niewielkich podstawach (np. Ustawianie nawiasów klamrowych), ale przykłady mogą obejmować takie rzeczy, jak „testowanie jednostek nie jest strasznie pomocne” lub „pola publiczne naprawdę są w porządku”. Ważną rzeczą (w każdym razie dla mnie) jest to, że masz uzasadnienie swoich opinii.

Proszę przedstawić swoją opinię i uzasadnienie - zachęcam ludzi do głosowania na opinie, które są dobrze uzasadnione i interesujące, niezależnie od tego, czy zgadzasz się z nimi.

Programiści, którzy nie kodują w wolnym czasie dla zabawy, nigdy nie będą tak dobrzy jak ci, którzy to robią.

Myślę, że nawet najmądrzejsi i najbardziej utalentowani ludzie nigdy nie staną się naprawdę dobrymi programistami, chyba że traktują to jako coś więcej niż pracę. Oznacza to, że w wolnym czasie wykonują niewielkie projekty lub po prostu bawią się mnóstwem różnych języków i pomysłów.

(Uwaga: nie mówię, że dobrzy programiści robią tylko programowanie, ale robią więcej niż programowanie od 9 do 5)

Jedyną „najlepszą praktyką”, z której powinieneś cały czas korzystać, jest „Użyj swojego mózgu”.

Zbyt wielu ludzi wskakuje na zbyt wiele bandwagonów i próbuje narzucić metody, wzorce, ramy itp. Na rzeczy, które ich nie uzasadniają. To, że coś jest nowe lub ktoś szanowany ma opinię, nie oznacza, że ​​pasuje do wszystkich :)

EDYCJA: Tylko dla wyjaśnienia - nie sądzę, że ludzie powinni ignorować najlepsze praktyki, cenne opinie itp. Tylko, że ludzie nie powinni po prostu ślepo skakać bez myślenia o tym, DLACZEGO to „coś” jest tak wspaniałe, CZY dotyczy to tego, co ja robię i jakie to przynosi korzyści / wady?

„Googling to” jest w porządku!

Tak, wiem, że obraża to niektórych ludzi, że ich lata intensywnego zapamiętywania i / lub chwalebnych stosów książek programistycznych zaczynają spadać obok zasobu, do którego każdy może uzyskać dostęp w ciągu kilku sekund, ale nie powinieneś tego robić przeciwko ludziom którzy go używają.

Zbyt często słyszę, jak odpowiedzi Google na problemy wynikają z krytyki, i to naprawdę bez sensu. Przede wszystkim należy przyznać, że każdy potrzebuje materiałów do odniesienia. Nie wiesz wszystkiego i musisz to sprawdzić. W związku z tym, czy to naprawdę ma znaczenie, skąd masz informacje? Czy ma to znaczenie, jeśli spojrzałeś na to w książce, w Google lub usłyszałeś od gadającej żaby, którą halucynowałeś? Nie. Prawidłowa odpowiedź to właściwa odpowiedź.

Ważne jest, abyś zrozumiał materiał, wykorzystał go jako środek do udanego rozwiązania programistycznego, a klient / Twój pracodawca jest zadowolony z rezultatów.

(chociaż jeśli otrzymujesz odpowiedzi od halucynacyjnych żab rozmawiających, prawdopodobnie powinieneś mimo wszystko uzyskać pomoc)

Większość komentarzy w kodzie jest w rzeczywistości zgubną formą powielania kodu.

Większość czasu spędzamy na utrzymywaniu kodu napisanego przez innych (lub nas samych), a złe, niepoprawne, nieaktualne, wprowadzające w błąd komentarze muszą znajdować się na szczycie listy najbardziej irytujących artefaktów w kodzie.

Myślę, że w końcu wiele osób po prostu je usuwa, szczególnie te potworności z kwiatów.

Znacznie lepiej skoncentrować się na zapewnieniu czytelności kodu, refaktoryzacji w razie potrzeby i zminimalizowaniu idiomów i dziwactwa.

Z drugiej strony wiele kursów uczy, że komentarze są prawie ważniejsze niż sam kod, co prowadzi do tego, że następny wiersz dodaje jeden do stylu komentowania faktury .

XML jest wysoce przereklamowany

Myślę, że zbyt wielu przeskakuje do modemu XML, zanim użyje swoich mózgów ... XML dla stron internetowych jest świetny, ponieważ jest do tego przeznaczony. W przeciwnym razie uważam, że niektóre definicje problemów i przemyślenia projektowe powinny wyprzedzić każdą decyzję o ich użyciu.

Moje 5 centów

Nie wszyscy programiści są sobie równi

Dość często menedżerowie uważają, że DeveloperA == DeveloperB po prostu dlatego, że mają taki sam poziom doświadczenia i tak dalej. W rzeczywistości wydajność jednego programisty może być 10-krotnie, a nawet 100-krotnie wyższa niż u innego programisty.

Mówienie o tym jest ryzykowne z politycznego punktu widzenia, ale czasami mam ochotę na to zwrócić uwagę, chociaż nawet jeśli kilku członków zespołu może wydawać się mieć takie same umiejętności, nie zawsze tak jest. Widziałem nawet przypadki, w których wiodący programiści byli „poza nadzieją”, a młodsi twórcy wykonali całą pracę - upewniłem się jednak, że dostali uznanie. :)

Nie rozumiem, dlaczego ludzie myślą, że Java jest absolutnie najlepszym „pierwszym” językiem programowania do nauki na uniwersytetach.

Po pierwsze, uważam, że pierwszy język programowania powinien być taki, aby podkreślał potrzebę uczenia się przepływu sterowania i zmiennych, a nie obiektów i składni

Po drugie, uważam, że ludzie, którzy nie mieli doświadczenia w debugowaniu przecieków pamięci w C / C ++, nie mogą w pełni docenić tego, co Java przynosi do tabeli.

Naturalnym postępem powinno być także przejście od „jak to zrobić” do „jak znaleźć bibliotekę, która to robi”, a nie na odwrót.

Jeśli znasz tylko jeden język, bez względu na to, jak dobrze go znasz, nie jesteś świetnym programistą.

Wydaje się, że istnieje postawa, która mówi, że gdy jesteś naprawdę dobry w C #, Javie lub jakimkolwiek innym języku, od którego zacząłeś się uczyć, to wszystko czego potrzebujesz. Nie wierzę w to - każdy język, którego się nauczyłem, nauczył mnie czegoś nowego o programowaniu, które mogłem przywrócić do pracy wraz ze wszystkimi innymi. Myślę, że każdy, kto ograniczy się do jednego języka, nigdy nie będzie tak dobry, jak mógłby być.

Wskazuje mi również na pewien brak dociekliwości i chęci eksperymentowania, co niekoniecznie wiąże się z cechami, których spodziewałbym się u naprawdę dobrego programisty.

Wydajność ma znaczenie.

Instrukcje drukowania są prawidłowym sposobem debugowania kodu

Uważam, że debugowanie kodu za pomocą śmiecia System.out.println(lub dowolnego innego polecenia drukowania, które działa w twoim języku) jest w porządku . Często może to być szybsze niż debugowanie i można porównać wydrukowane wyniki z innymi uruchomieniami aplikacji.

Pamiętaj tylko, aby usunąć instrukcje drukowania, gdy przejdziesz do produkcji (lub lepiej, zamień je w instrukcje logowania)

Twoim zadaniem jest pozbawienie cię pracy.

Kiedy piszesz oprogramowanie dla swojego pracodawcy, każde tworzone przez ciebie oprogramowanie musi być napisane w taki sposób, aby każdy programista mógł je pobrać i zrozumieć przy minimalnym wysiłku. Jest dobrze zaprojektowany, jasno i konsekwentnie napisany, sformatowany w sposób przejrzysty, udokumentowany tam, gdzie powinien być, budowany codziennie zgodnie z oczekiwaniami, sprawdzany w repozytorium i odpowiednio wersjonowany.

Jeśli zostaniesz potrącony przez autobus, zwolniony, zwolniony lub odejść z pracy, Twój pracodawca powinien mieć możliwość natychmiastowego zastąpienia cię, a następny facet może wkroczyć na twoją rolę, odebrać kod i wstać biegnie w ciągu tygodnia. Jeśli on lub ona nie może tego zrobić, to poniosłeś porażkę.

Co ciekawe, przekonałem się, że osiągnięcie tego celu uczyniło mnie bardziej wartościowym dla moich pracodawców. Im bardziej staram się być jednorazowy, tym bardziej cenię się dla nich.

1) Farsa na aplikacje biznesowe :

Myślę, że cała frameworka „Enterprise” to dym i lustra. J2EE, .NET, większość frameworków Apache i większość abstrakcji do zarządzania takimi rzeczami powoduje znacznie większą złożoność niż rozwiązują.

Weź zwykłą platformę Java lub .NET ORM, lub dowolną podobno nowoczesną platformę MVC, która albo „magia” rozwiązuje żmudne, proste zadania. W końcu piszesz ogromne ilości brzydkiego bojlera XML, który jest trudny do sprawdzenia i szybkiego napisania. Masz masywne interfejsy API, z których połowa ma tylko zintegrować pracę z innymi interfejsami API, interfejsy, których nie można odtworzyć, oraz abstrakcyjne klasy, które są potrzebne tylko w celu przezwyciężenia nieelastyczności Java i C #. Po prostu nie potrzebujemy większości tego.

Co powiesz na wszystkie różne serwery aplikacji z własną składnią deskryptorów, zbyt złożone bazy danych i produkty do pracy grupowej?

Nie chodzi o to, że złożoność == zła, to ta niepotrzebna złożoność == zła. Pracowałem w ogromnych instalacjach dla przedsiębiorstw, w których część z nich była konieczna, ale nawet w większości przypadków kilka domowych skryptów i prosta nakładka internetowa to wszystko, co jest potrzebne do rozwiązania większości przypadków użycia.

Spróbuję zastąpić wszystkie te aplikacje dla przedsiębiorstw prostymi strukturami sieciowymi, bazami danych open source i trywialnymi konstrukcjami programistycznymi.

2) Wymagane n-letnie doświadczenie:

O ile nie potrzebujesz konsultanta lub technika do obsługi konkretnego problemu związanego z aplikacją, interfejsem API lub platformą, to tak naprawdę nie potrzebujesz osoby z 5-letnim doświadczeniem w tej aplikacji. Potrzebny jest programista / administrator, który potrafi czytać dokumentację, ma wiedzę domenową na temat wszystkiego, co robisz i potrafi szybko się uczyć. Jeśli musisz się uczyć w jakimś języku, porządny programista to zrozumie za niecałe 2 miesiące. Jeśli potrzebujesz administratora serwera X, za dwa dni powinien on przeczytać strony podręcznika i grupy dyskusyjne i być na bieżąco. Cokolwiek mniej, a ta osoba nie jest warta tego, co otrzymuje.

3) Wspólny program studiów „informatyka”:

Większość stopni informatyki i inżynierii oprogramowania to byki. Jeśli twoim pierwszym językiem programowania jest Java lub C #, oznacza to, że robisz coś złego. Jeśli nie dostaniesz kilku kursów pełnych algebry i matematyki, to źle. Jeśli nie zagłębisz się w programowanie funkcjonalne, jest ono niekompletne. Jeśli nie możesz zastosować niezmienników pętli do trywialnej pętli for, nie jesteś wart swojej soli jako rzekomy informatyk. Jeśli masz doświadczenie w posługiwaniu się językami X i Y oraz orientacją obiektową, jest ono pełne s ***. Prawdziwy informatyk postrzega język w kategoriach stosowanych pojęć i składni, a także metodologie programowania jako jedną z wielu, i tak dobrze rozumie leżące u podstaw filozofie, że wybór nowych języków, metod projektowania lub języków specyfikacji powinien bądź trywialny.

Gettery i Settery są wysoce nadużywane

Widziałem miliony ludzi twierdzących, że publiczne pola są złe, więc czynią je prywatnymi i zapewniają wszystkim, którzy je pobierają i ustawiają. Uważam, że jest to prawie identyczne z upublicznieniem pól, może nieco inaczej, jeśli używasz wątków (ale ogólnie tak nie jest) lub jeśli twoje akcesoria mają logikę biznesową / prezentacji (przynajmniej coś „dziwnego”).

Nie opowiadam się za polami publicznymi, ale przeciwko tworzeniu gettera / settera (lub własności) dla każdego z nich, a następnie twierdzeniu, że robi to enkapsulacja lub ukrywanie informacji ... ha!

AKTUALIZACJA:

Ta odpowiedź wzbudziła pewne kontrowersje w komentarzach, więc postaram się ją trochę wyjaśnić (pozostawiam oryginał nietknięty, ponieważ wiele osób go głosowało).

Po pierwsze: każdy, kto korzysta z pól publicznych, zasługuje na czas więzienia

Teraz tworzenie pól prywatnych, a następnie używanie IDE do automatycznego generowania programów pobierających i ustawiających dla każdego z nich jest prawie tak samo złe, jak używanie pól publicznych.

Dużo ludzi myśli:

private fields + public accessors == encapsulation

Mówię (automatyczne lub nie) generowanie pary getter / setter dla twoich pól skutecznie przeciwstawia się tak zwanej enkapsulacji, którą próbujesz osiągnąć.

Na koniec pozwólcie mi zacytować wujka Boba w tym temacie (zaczerpniętym z rozdziału 6 „Czystego kodu”):

Istnieje powód, dla którego nasze zmienne są prywatne. Nie chcemy, aby ktokolwiek na nich polegał. Chcemy wolności zmiany ich rodzaju lub implementacji pod wpływem kaprysu lub impulsu. Dlaczego więc tak wielu programistów automatycznie dodaje obiekty pobierające i ustawiające do swoich obiektów, odsłaniając swoje prywatne pola tak, jakby były publiczne?

Diagramy UML są mocno przereklamowane

Oczywiście istnieją użyteczne diagramy, np. Diagram klas dla wzoru złożonego , ale wiele diagramów UML nie ma absolutnie żadnej wartości.

Opinia: SQL to kod. Traktuj to jako takie

To znaczy, podobnie jak Twój C #, Java lub inny ulubiony język obiektów / procedur, opracuj styl formatowania, który będzie czytelny i łatwy do utrzymania.

Nienawidzę, gdy widzę niechlujny, swobodnie sformatowany kod SQL. Jeśli krzyczysz, gdy widzisz oba style nawiasów klamrowych na stronie, dlaczego lub dlaczego nie krzyczysz, gdy widzisz dowolny sformatowany SQL lub SQL, który przesłania lub zaciemnia warunek DOŁĄCZ?

Czytelność jest najważniejszym aspektem twojego kodu.

Tym bardziej niż poprawność. Jeśli jest czytelny, łatwo go naprawić. Jest również łatwy do optymalizacji, łatwy do zmiany, łatwy do zrozumienia. Mam nadzieję, że inni programiści też się z tego czegoś nauczą.

Jeśli jesteś programistą, powinieneś być w stanie napisać kod

W zeszłym roku przeprowadziłem sporo wywiadów i dla mojej części wywiadu miałem przetestować sposób, w jaki ludzie myślą, i jak zaimplementowali proste do umiarkowanych algorytmy na białej tablicy. Początkowo zaczynałem od pytań takich jak:

Biorąc pod uwagę, że Pi można oszacować za pomocą funkcji 4 * (1 - 1/3 + 1/5 - 1/7 + ...) z większą liczbą terminów dających większą dokładność, napisz funkcję, która oblicza Pi z dokładnością do 5 miejsc po przecinku .

Jest to problem, który powinien skłonić cię do myślenia, ale nie powinien być poza zasięgiem doświadczonego programisty (można na nie odpowiedzieć w około 10 wierszach C #). Jednak wielu z naszych (rzekomo przebadanych przez agencję) kandydatów nie mogło nawet zacząć na nie odpowiadać, ani nawet wyjaśnić, w jaki sposób mogliby na nie odpowiedzieć. Po jakimś czasie zacząłem zadawać prostsze pytania, takie jak:

Biorąc pod uwagę, że powierzchnia koła jest równa iloczynowi liczby razy promień do kwadratu, napisz funkcję, aby obliczyć powierzchnię koła.

O dziwo, ponad połowa kandydatów nie mogła napisać tej funkcji w żadnym języku (potrafię czytać najpopularniejsze języki, więc pozwalam im używać dowolnego wybranego języka, w tym pseudokodu). Mieliśmy „programistów C #”, którzy nie mogli napisać tej funkcji w języku C #.

Byłem tym zaskoczony. Zawsze myślałem, że programiści powinni umieć pisać kod. Wydaje się, że obecnie jest to opinia kontrowersyjna. Z pewnością jest to jeden z kandydatów na rozmowę kwalifikacyjną!

Edytować:

W komentarzach pojawia się wiele dyskusji na temat tego, czy pierwsze pytanie jest dobre, czy złe, i czy należy zadawać pytania tak złożone, jak to w wywiadzie. Nie będę się tutaj zagłębiał (to zupełnie nowe pytanie) poza tym, że powiedziałem, że w dużej mierze brakuje ci sensu tego wpisu .

Tak, powiedziałem, że ludzie nie mogą zrobić z tym żadnego postępu, ale drugie pytanie jest trywialne i wielu ludzi nie może zrobić z tym żadnego postępu! Każdy, kto nazywa się programistą, powinien umieć napisać odpowiedź na drugą w ciągu kilku sekund bez zastanowienia. I wielu nie może.

Używanie notacji węgierskiej powinno być karane śmiercią.

To powinno być dość kontrowersyjne;)

Wzory projektowe bardziej szkodzą dobremu projektowi niż mu pomagają.

Projektowanie oprogramowania IMO, szczególnie dobre projektowanie oprogramowania, jest zbyt różnorodne, aby można je było w znaczący sposób uchwycić we wzorach, szczególnie w niewielkiej liczbie wzorów, które ludzie mogą zapamiętać - i są one zbyt abstrakcyjne, aby ludzie pamiętali więcej niż garstkę. Więc niewiele pomagają.

Z drugiej strony, zbyt wiele osób zakochuje się w tej koncepcji i próbuje stosować wszędzie wzorce - zwykle w wynikowym kodzie nie można znaleźć rzeczywistego projektu między wszystkimi (całkowicie pozbawionymi znaczenia) Singletonami i Fabrykami Abstrakcyjnymi.

Mniej kodu jest lepsze niż więcej!

Jeśli użytkownicy powiedzą „to jest to?”, A Twoja praca pozostanie niewidoczna, oznacza to, że została wykonana poprawnie. Chwałę można znaleźć gdzie indziej.

PHP jest do bani ;-)

Dowód jest w budyniu.

Testy jednostkowe nie pomogą Ci napisać dobrego kodu

Jedynym powodem przeprowadzenia testów jednostkowych jest upewnienie się, że kod, który już działa, nie ulegnie uszkodzeniu. Najpierw pisanie testów lub pisanie kodu do testów jest śmieszne. Jeśli napiszesz do testów przed kodem, nie będziesz nawet wiedział, jakie są przypadki brzegowe. Możesz mieć kod, który przejdzie testy, ale nadal nie powiedzie się w nieprzewidzianych okolicznościach.

Co więcej, dobrzy programiści utrzymają niską spójność, co sprawi, że dodanie nowego kodu raczej nie spowoduje problemów z istniejącymi rzeczami.

W rzeczywistości uogólnię to jeszcze bardziej,

Większość „najlepszych praktyk” w inżynierii oprogramowania ma na celu powstrzymanie złych programistów przed spowodowaniem zbyt dużych szkód .

Są po to, aby trzymać złych programistów i powstrzymywać ich od popełniania głupich błędów. Oczywiście, ponieważ większość programistów jest zła, jest to dobra rzecz, ale dobrzy programiści powinni uzyskać przepustkę.

Napisz małe metody. Wygląda na to, że programiści uwielbiają pisać długie metody, w których robią wiele różnych rzeczy.

Myślę, że metoda powinna zostać stworzona wszędzie tam, gdzie można ją nazwać.

Od czasu do czasu można pisać kod śmieci

Czasami szybki i brudny kawałek śmieci to wszystko, co jest potrzebne do wykonania określonego zadania. Wzory, ORM, SRP, cokolwiek ... Wyrzuć konsolę lub aplikację internetową, napisz trochę wbudowanego sql (czujesz się dobrze) i spełnij wymagania.

Kod == Projekt

Nie jestem fanem skomplikowanych diagramów UML i niekończącej się dokumentacji kodu. W języku wysokiego poziomu twój kod powinien być czytelny i zrozumiały. Skomplikowana dokumentacja i diagramy nie są tak naprawdę bardziej przyjazne dla użytkownika.

Oto artykuł na temat Code as Design .

Tworzenie oprogramowania to tylko praca

Nie zrozum mnie źle, bardzo lubię tworzyć oprogramowanie. Od kilku lat prowadzę blog na ten temat. Spędziłem tu wystarczająco dużo czasu, aby mieć> 5000 punktów reputacji. Pracuję na początku, robiąc zazwyczaj 60 godzin tygodniowo za znacznie mniej pieniędzy, niż mógłbym uzyskać jako wykonawca, ponieważ zespół jest fantastyczny, a praca interesująca.

Ale w wielkim schemacie rzeczy jest to tylko praca.

Ma znaczenie poniżej wielu rzeczy, takich jak rodzina, moja dziewczyna, przyjaciele, szczęście itp., A poniżej innych rzeczy, które wolałbym robić, gdybym miał nieograniczone zapasy gotówki, takie jak jazda na motocyklach, jachty żaglowe lub snowboard.

Myślę, że czasami wielu programistów zapomina, że ​​programowanie jest po prostu czymś, co pozwala nam mieć ważniejsze rzeczy w życiu (i mieć je poprzez robienie czegoś, co sprawia nam przyjemność), a nie być celem samym w sobie.

Myślę też, że nie ma nic złego w kontroli plików binarnych .. jeśli jest ku temu dobry powód. Jeśli mam zestaw, dla którego nie mam źródła i niekoniecznie muszę znajdować się w tym samym miejscu na każdej maszynie deweloperskiej, zwykle umieszczam go w katalogu „binariów” i odwołuję się do niego w projekcie, używając ścieżki względnej .

Wydaje się, że wiele osób uważa, że ​​powinienem zostać spalony na stosie, nawet w tym samym zdaniu wspominając o „kontroli źródła” i „pliku binarnym”. Znam nawet miejsca, w których obowiązują surowe zasady, które mówią, że nie można ich dodawać.

Każdy programista powinien znać podstawową architekturę nowoczesnych komputerów. Dotyczy to również programistów, którzy atakują maszynę wirtualną (a może nawet bardziej, ponieważ powtarzano im, że nie muszą się martwić zarządzaniem pamięcią itp.)

Architekci / projektanci oprogramowania są przereklamowani

Jako programista nienawidzę pomysłu Software Architects. Są to w zasadzie ludzie, którzy nie kodują już w pełnym wymiarze godzin, czytają czasopisma i artykuły, a następnie mówią, jak zaprojektować oprogramowanie. Powinni to robić tylko ludzie, którzy faktycznie zarabiają na życie w pełnym wymiarze godzin. Nie obchodzi mnie, czy byłeś najlepszym programistą na świecie 5 lat temu, zanim zostałeś Architektem, twoja opinia jest dla mnie bezużyteczna.

Jak to jest kontrowersyjne?

Edycja (w celu wyjaśnienia): Myślę, że większość architektów oprogramowania robi świetnych analityków biznesowych (rozmawiając z klientami, pisząc wymagania, testy itp.), Po prostu uważam, że nie mają oni miejsca w projektowaniu oprogramowania, na wysokim poziomie lub w inny sposób.

Nie ma podejścia „uniwersalnego” do rozwoju

Dziwi mnie, że jest to opinia kontrowersyjna, ponieważ wydaje mi się, że to zdrowy rozsądek. Istnieje jednak wiele wpisów na popularnych blogach promujących podejście „jeden rozmiar dla wszystkich” w rozwoju, więc myślę, że tak naprawdę jestem w mniejszości.

Widziałem rzeczy reklamowany jako do prawidłowego podejścia do jakiegokolwiek projektu - zanim jakiekolwiek informacje o niej wiadomo - są takie rzeczy jak korzystanie z Test-Driven Development (TDD), Domain Driven Design (DDD), Mapowanie obiektowo-relacyjnego (ORM) , Agile (wielka A), Orientacja obiektowa (OO) itp., Obejmująca wszystko, od metodologii po architektury i komponenty. Oczywiście wszystkie z przyjemnymi akronimami na rynku.

Wydaje się, że ludzie posuwają się nawet do umieszczania znaczków na swoich blogach, takich jak „Jestem napędzany testem” lub podobnych, tak jakby ich ścisłe przestrzeganie jednego podejścia bez względu na szczegóły projektu było w rzeczywistości dobrą rzeczą .

To nie jest

Wybór właściwych metodologii, architektur i komponentów itp. Jest czymś, co należy zrobić dla każdego projektu i zależy nie tylko od rodzaju projektu, nad którym pracujesz i jego unikalnych wymagań, ale także od wielkości i możliwości zespołu, z którym pracujesz.