Czy programiści ignorujący jakość / standardy są lepsi dla firmy? [Zamknięte]

Czy programiści, którzy decydują się nie traktować optymalizacji kodu, standardów i najlepszych praktyk jako najwyższego priorytetu, tworzą bardziej użyteczny kod niż ci programiści, którzy chcą się martwić o optymalizację, wdrożenie standardów i praktyk kodowania ponad terminowe wykonywanie zadań?

Jak porównują te różne metodologie w odniesieniu do poszczególnych przeglądów wydajności?

Jak wyglądają te style w recenzjach?

Jaki jest najlepszy sposób, aby wpłynąć na swój zespół, aby wdrożyć więcej najlepszych praktyk podczas SDLC?

Nie, otrzymają szacunek tylko od właściciela projektu w danym momencie.

Przez lata będą niszczeni przez:

• przyszli opiekunowie,
• przyszli testerzy,
• przyszli właściciele projektów,
• przyszli menedżerowie,
• i prawie każdy, kto w przyszłości będzie związany z bazą kodu.

Mogą nawet uzyskać takie samo leczenie od:

• obecni testerzy,
• obecni autorzy dokumentacji technicznej.

Fałszywa dychotomia: cechy są ortogonalne.

                Wysoka jakość Niska jakość

Zyskowny NIESAMOWITY Szkicowy

Nierentowna Iffy FIRE FIRST

Nie. Najlepsze praktyki są najlepsze, ponieważ z definicji pomagają w poprawniejszym wykonywaniu projektów w krótszym czasie, dzięki szybszym modyfikacjom w przyszłości, więc ich ignorowanie gwarantuje zmniejszenie zysków. Oczywiście, twoi menedżerowie mogą zalecać praktyki, które ich zdaniem są najlepsze, ale tak naprawdę nie są, lub mogą źle ocenić, za co zapłacą klienci, a co nie - wtedy wszystkie zakłady są wyłączone.

Standardy kodowania są trudniejsze; możliwe jest przepisanie koderom zbyt wielu szczegółów, co prowadzi do obniżenia wydajności. Ale z doświadczeniem dość łatwo jest powiedzieć użyteczne wskazówki od mikro-zarządzających zatrzymujących anal, więc to samo dotyczy: rzeczywiste najlepsze praktyki są zawsze warte zachodu, pseudo-najlepsze praktyki zwykle nie.

Optymalizacja kodu zwykle nie jest warte zrobienia, chyba że mierzone co się zatory są, potwierdził , że robi optymalizacji jest konieczne i zmierzono , że sprytny trik rzeczywiście spełnia rquirement PreFormance. W przeciwnym razie (co jest najczęściej) nie warto tego robić, a zatem nie jest optymalne.

Czy zgadzam się z programistami, którzy nie dbają o optymalizację kodu i praktyki? Nie.

Czy wykonują pracę, którą muszą wykonać? Tak.

W biznesie chodzi o zarabianie pieniędzy, a jedynym sposobem na zarabianie pieniędzy jest wydawanie produktów. Zazwyczaj oznacza to, że projekty mają ścisłe harmonogramy, co oznacza, że ​​najlepszy sposób na zrobienie czegoś może nie być najszybszym sposobem na zrobienie czegoś.

Chociaż nie zgadzam się z tym stylem rozwoju, może być postrzegany przez firmę jako szanowany, jeśli produkty zostaną wydane.

No i chciałbym znaleźć najszybszą trasę z dala od wspomnianej firmy, która ceni te wady.

Tak i nie, co jest nieco mdłe, ale to najlepsza praktyka, a nie doskonała praktyka. Idealnie powinieneś stale ich przestrzegać, ale zawsze będzie sytuacja, w której firma będzie chciała stawiać swoje potrzeby przed potrzebami twoich produktów.

Opiekunowie będą cię nienawidzić, ale szef cię pokocha.

Najlepsze praktyki są trochę jak zdrowy rozsądek, wszyscy zgadzają się, że wszyscy powinni to wiedzieć, dopóki dowolne dwie osoby nie zaczną szczegółowo o tym dyskutować. Nie ma dwóch osób całkowicie zgodnych co do definicji i nie ma logicznego źródła prawdy, które dotyczyłoby wszystkich sytuacji.

Czy piszesz system nawigacji dla satelity kosmicznego (prawdopodobnie nie jesteś)? Zatem Hell Żadnej słabej jakości / wykonania kodu nigdy nie można zaakceptować w tego rodzaju pracy.

Czy piszesz jednorazową stronę internetową dla jednorazowego nacisku marketingowego (prawdopodobnie tego też nie robisz lub nie zadałbyś tego pytania, ale jest to bardziej prawdopodobne niż satelita)? Potem do diabła Tak, wyrzuć ten kawałek puchu za pomocą wszelkich środków niezbędnych do dotrzymania terminu, kolejny dyrektor marketingu prawdopodobnie i tak zrobi coś innego z inną firmą. TO, CO NIE JESTEŚ SZTUKA ANI NAUKA - ZARABIAJ.

Wszystko inne pomiędzy: do negocjacji, zwłaszcza, gdy deweloper jest na haku, aby uzyskać początkowe wsparcie.

Dopóki nie nastąpi drugie przyjście jakiejkolwiek świętej istoty, którą wolisz, i on / ona / ona / ona w cudowny sposób zdefiniuje praktyki rozwoju, będzie znaczna przestrzeń do dyskusji na temat każdego projektu, który nie jest bezpośrednio odpowiedzialny za decyzje dotyczące życia i śmierci, które nie są tak mało znaczące, by być jednorazowymi.

Wszystko poza najlepszymi praktykami oznaczonymi jako krytyczne dla życia jest zazwyczaj bardziej podobne do zasad firmy, specyfikacji klienta lub osobistej opinii. Wiele z nich to osobista opinia, na którą zgodzi się obecnie wiele osób, ale to nie czyni z niego niezmiennego przewodnika dla wszystkich sytuacji.

Ile pieniędzy zarabiają dla firmy, jest dyskusyjne. Jeśli poziom ponownego sprawdzenia tego kodu będzie wyższy, koszty utrzymania wzrosną i ktoś nie będzie zadowolony. Wysokie koszty konserwacji długoterminowej są droższe niż robienie tego odpowiednio z góry.

To, ile szacunku otrzymują, zależy od konkretnego przypadku. W pewnym momencie jednak ktoś to zauważy.

Nie dbanie o te rzeczy może sprawić, że firma zyska więcej pieniędzy w perspektywie krótkoterminowej, ale w dłuższej perspektywie może kosztować firmę więcej pieniędzy z powodu większej liczby napraw błędów i kodowania konserwacji.

Czasami konieczna może być szybka i brudna praca, jeśli konkurencyjne firmy spieszą się z jednoczesnym wprowadzaniem podobnych produktów na rynek, ale należy dokładnie rozważyć przyszłe koszty takich działań.

Wszystko zależy od klienta.

Klient, który lubi szybkie i brudne (i zwykle tańsze), nie dba o to, że będzie stwarzał problemy w przyszłości.

Pomyśl o konstrukcji szafki.

Niektórzy zapłacą i docenią dobrej jakości szafki na zamówienie. Nie przeszkadza im dodatkowy koszt szuflad z twardego drewna i sprzętu na najwyższym poziomie. Nie mają nic przeciwko, że zbudowanie i zainstalowanie rzeczy zajmie dodatkowy tydzień lub nawet miesiąc.

Wielu nie. Wielu wybierze tanie, masowo produkowane płyty wiórowe, które dostaniesz w dużym sklepie. Chcą je zainstalować w ciągu 2 dni. Mała luka tu i tam jest całkowicie do przyjęcia. Nie obchodzi ich, że rozpadną się za 10 lat.

Więc jeśli Twoi menedżerowie chwalą programistę, który robi to szybko i brudnie, to albo Twoi klienci nie chcą wysokiej jakości, albo menedżerowie okłamują klientów.

Tylko czas powie. Rób to, czego chcą menedżerowie lub znajdź inną pracę.

Nie, nigdy. Optymalizacja kodu IMO, najlepsze praktyki, faktyczne kunszt to NAJWAŻNIEJSZE rzeczy, które trzeba mieć w bazie kodu; bez tego wszystko zamienia się w szlam i jest trzymane razem z taśmą klejącą. To niezrównoważony projekt. To jak ignorowanie guza, ponieważ jest mały i jesteś teraz zdrowy; na pewno jesteś teraz zdrowy, ale kilka lat później staje się terminalny, ponieważ tak długo go ignorujesz.

Nie tylko nie zgadzam się z programistami, którzy nie dbają o te rzeczy, ale nie mam szacunku dla nich do uruchomienia. Pewnym sposobem, aby skłonić mnie do rozważenia odejścia z organizacji, bez względu na to, jak krótki byłbym tam czas, jest otoczenie przez zespół, w którym jestem jedyną osobą (jeśli nie jedyną w całej firmie), która dba o to na temat odpowiednich koncepcji inżynierii oprogramowania.

Dobra lektura: http://www.joelonsoftware.com/items/2009/09/23.html

Ale IMHO, jedna z najlepszych praktyk to kolejna dla człowieka koszmar. A każda nietrywialna baza kodu będzie koszmarem dla osoby z zewnątrz.

Cokolwiek myślisz, nie przejmuj się tym.

EDYCJA: Nie bronię żadnej pozycji, w zależności od zadania, które mógłbym pochylić się w którąkolwiek stronę.

Lepiej dla firmy? To zależy.

W przypadku startupu z ograniczonymi środkami, zrób to i wyślij go tam - nie ma znaczenia, czy jest bałagan, który można naprawić później, gdy będzie więcej zasobów.

W przypadku dojrzałego produktu, w którym wielu użytkowników polega na jakości oprogramowania, wszystko należy zrobić „prawidłowo”.

Lepiej dla indywidualnego programisty? Właściwie to nie ma znaczenia. Po prostu rób to samo, co robią koledzy i pozwól kierownictwu poradzić sobie z konsekwencjami - to nie twoja praca. Jeśli przez cały czas naprawiasz bzdury innych, będziesz postrzegany jako powolny, a będziesz tym, który nadal tam jest, podczas gdy inni będą awansowani ponad ciebie. Skorzystaj z programu lub wyjdź, póki możesz, jeśli jest tak źle.

Zależy od dewelopera i projektu / sytuacji.

Niezwykłe czasy wymagają nadzwyczajnych środków.

Więc jeśli potrzebuję czegoś dostarczonego teraz, a ktoś jest nadmiernie inżynierską aplikacją Java klasy korporacyjnej, która wykorzystuje nie mniej niż 14 najnowszych frameworków modnych, a prosty skrypt w języku Python wykona zadanie, jest gorzej niż programista, który skraca rogi i myśli błędny kod wykona się w normalnych czasach.

Częścią bycia programistą jest elastyczność. Nie powinieneś być niewolnikiem swoich narzędzi i ślepo postępuj zgodnie z praktykami - zawsze będzie przypadek, w którym cię zawiodą. Wiedza, kiedy złamać i nagiąć reguły, jest jedną z rzeczy, które mają duże doświadczenie i są cenne.

W twoim przypadku - jeśli zapewnia większą wartość niż ty, ponieważ prędkość ma kluczowe znaczenie, nawet po uwzględnieniu zwiększonych kosztów utrzymania na drodze, to zasługuje na lepszą rekompensatę. Z drugiej strony - jeśli utkniesz w sprzątaniu jego bałaganu - masz problem z komunikacją z zarządem.

Jest to przypadek indywidualny. Z wyjątkiem stylu kodowania - nie ma tam wymówki.

Przykro mi, ale musiałbym nie zgodzić się z większością odpowiedzi na to pytanie, z wyjątkiem pierwszego.

Podstawową wartością oprogramowania jest jego elastyczność.

Nie sądzę, że powinieneś przepisywać kod innych ludzi bez uzasadnionego powodu. Jeśli musisz zmienić moduł z jakiegokolwiek powodu, aby wdrożyć swoją funkcję, jesteś teraz, na dobre lub na złe, właścicielem tego modułu. Zmień to, przepisz trochę, przepisz wszystko.

Nigdy nie produkuj niskiej jakości pod względem elastyczności. Nie ma czegoś takiego jak wyrzucanie czegokolwiek w oprogramowaniu. Jeśli klient powie, że jest tymczasowy i że nie będzie go potrzebował po określonej dacie, i nie dba o jakość, albo powiedz „źle” lub napisz na piśmie, że kod nie zostanie zmieniony ani przez ciebie, ani przez innego programistę jest wdrożony do produkcji lub masz prawo pozwać ich.

Najgorsze założenie, jakie widzę w niektórych z tych odpowiedzi, jest takie, że jakiś czysty kod w jakiś sposób zmniejsza szybkość rozwoju. Dla każdego projektu dowolnej substancji (ponad 6 godzin pracy) czysty kod przyspiesza rozwój w dłuższej perspektywie (cokolwiek dłuższego niż tydzień). Widziałem to raz po raz.

Zły kod jakości jest po prostu lekceważący zawód i współpracowników. Przepraszam ale prawda.

Więc nigdy nie niskiej jakości, jeśli chodzi o elastyczność, nigdy!