Jak „proste” jest prawdziwe rozwiązanie KISS? [Zamknięte]

Przyznaję : mam problem z „utrzymywaniem prostoty i skrótu” przez większość czasu, ponieważ próba zrobienia tego zgodnie z książkami, które przeczytałem, wzorami, które słyszałem itp. Daje mi taki entuzjazm - entuzjazm pochodzący z poczucie tego, że jestem na właściwej drodze do prawdopodobnej doskonałości.

Z drugiej strony tak, to kładzie na mnie dodatkowy nacisk w związku z czasem dotrzymywania terminów ...

Ale ilekroć mówię do siebie: „Następnym razem uprość to, głupku!” Trudno mi uczynić to „prostym”, gdy nadejdzie następnym razem, ponieważ zaczyna się dziwnie ... i po pewnym czasie jest niewygodne.

Potem zaczynam oceniać moje rozumienie pojęcia „prosty” ...

Czy SIMPLE oznacza zbyt krótki, aby działał, ale jest trudny w utrzymaniu i rozszerzaniu?

Czy SIMPLE oznacza złamanie wielu zasad OOP?

Czy SIMPLE oznacza oszukiwanie?

Czy SIMPLE oznacza po prostu dotrzymywanie terminów bez zawierania umów? itp.

Co to właściwie jest?

Pytanie brzmi : czy możesz napisać DOKŁADNĄ definicję SIMPLE pod względem zasady KISS? -Jeśli jest.

Dzięki!

Nauczmy się francuskiego KISS:

La perfection est atteinte, non pas lorsqu'il n'y plus plus rien à ajouter, mais lorsqu'il n'y plus plus rien à emeryt. - Antoine de Saint-Exupéry

Co jest przetłumaczone na:

Doskonałość jest osiągana, nie wtedy, gdy nie ma już nic do dodania, ale kiedy nie ma już nic do zabrania. - Antoine de Saint-Exupéry

Scenariusz

Musisz wyciąć i uszczypnąć.

Rozwiązanie A: Nie KISS

Rozwiązanie B: KISS

Jak dla dokładnej definicji: Trudno określić skali bezwzględnej do pomiaru prostotę. Głównie dlatego, że prawdziwa prostota wyklucza prawdziwe zrozumienie danego problemu, a to jest rzadko osiągalne. Powiedzmy jednak, że rozwiązania A i B ilustrują różnicę między rozwiązaniami, które mają tendencję do nadmiernego komplikowania i prostoty.

„Spraw, aby rzeczy były jak najprostsze, ale nie prostsze” - Einstein

Utrzymanie kodu tak prostego, jak to możliwe, ale nie prostsze, zależy od rozwiązanego problemu. Tak długo, jak problem, który rozwiązuje się, zmienia się, podobnie KISS.

Istnieje równowaga między nadmierną inżynierią (och, to wygląda na świetne miejsce, aby pochwalić się moimi umiejętnościami Wzornictwa Projektowego!) I niedostateczną inżynierią (gdybym tylko użył fabryki, nie miałbym tego połączenia, które spowodowało, że zrobiłem 20 zmiany kodu ...). Celem jest łatwość konserwacji.

Prostota nie oznacza łamania dobrych zasad programowania. W rzeczywistości oznacza to coś wręcz przeciwnego.

Czy SIMPLE oznacza zbyt krótki, aby działał, ale jest trudny w utrzymaniu i rozszerzaniu?

Nie. Trudność w utrzymaniu i rozbudowie jest dużym objawem złożoności. W rzeczywistości uważam, że rozszerzenie kodu prowadzi do uproszczenia kodu, ponieważ na początku nie zajmujesz się każdym przypadkiem, możesz uprościć kod podstawowy.

Czy SIMPLE oznacza złamanie wielu zasad OOP?

Nie. Większość zasad OOP ma na celu utrzymanie kodu w czystości i lepszą organizację, co w końcu jest prostsze.

Czy SIMPLE oznacza oszukiwanie?

Nie. Pisanie jest trudne do utrzymania kodu i włamań pod pozorem dotrzymywania terminów.

Czy SIMPLE oznacza po prostu dotrzymywanie terminów bez zawierania umów? itp.

Nie. Terminy i prostota kodu to dwa osobne problemy. Pisanie prostego kodu nie zajmuje więcej czasu (choć jest to powszechne nieporozumienie).

Jest to bardzo trudne do wyjaśnienia, ponieważ proste nie oznacza dla wszystkich tego samego.

Przykład. Niektórzy deweloperzy uważają, że ?:to proste, ale inni uważają, że ifstwierdzenie jest lepsze. Gdy spadnie do tego poziomu, nie możesz zadowolić wszystkich.

Ogólnie rzecz biorąc, proste środki bez złożoności . Aby zrozumieć prostotę, musimy zrozumieć złożoność.

Istnieją dwa rodzaje złożoności:

Zasadnicza złożoność odnosi się do sytuacji, w której wszystkie rozsądne rozwiązania problemu muszą być skomplikowane (i być może mylące), ponieważ „proste” rozwiązania nie rozwiązałyby właściwie problemu. - Wikipedia

Przypadkowa złożoność to złożoność pojawiająca się w programach komputerowych lub ich procesie rozwoju (programowaniu komputerowym), która nie jest niezbędna do rozwiązania problemu. - Wikipedia

Podstawową złożoność można sprawdzić, zadając następujące pytania:

Czy to rozwiązanie jest proste? Czy mogę wyjaśnić to moim rówieśnikom w ciągu kilku minut, a oni to rozumieją? Czy istnieje prostsze rozwiązanie problemu? Jeśli tak, czy są jakieś kompromisy między skomplikowanym rozwiązaniem a prostym? Czy możemy żyć z tymi kompromisami? Na przykład wielu programistów popełnia błąd polegający na mikrooptymalizowaniu wszystkiego, a ich rozwiązanie (a także kod) staje się zbyt skomplikowane.

Sprawdzanie przypadkowej złożoności:

Czy kod jest prosty? Jeśli wrócę do tego za trzy miesiące, ile czasu zajmie mi zbudowanie kontekstu w mózgu, aby mógł dokonać zmian, których muszę dokonać? Czy wszystko w moim kodzie źródłowym ma wyraźny cel i skutecznie przekazuje ten cel mnie i innym programistom ? Jak trudno jest przetestować mój kod? Zwykle im bardziej skomplikowany jest kod, tym trudniej jest przeprowadzić test jednostkowy, więc zwykle używam tego jako miary złożoności. Zwykle potrzebujesz małych, dobrze nazwanych i skoncentrowanych klas i metod. Wzory projektowe zwykle pomagają również je osiągnąć.

Jeśli chcesz użyć wzorca projektowego tylko dlatego, że po prostu o nim przeczytasz, prawdopodobnie wprowadzi on przypadkową złożoność. Jeśli chcesz coś włożyć, bo myślisz, że jest „mądry”, prawdopodobnie wprowadzi przypadkową złożoność.

Mam nadzieję, że to pomaga i nie zapominam: proste nie oznacza ŁATWE .

Zawsze czułem, że zasady stojące za X11 ( http://en.wikipedia.org/wiki/X_Window_System#Principles ) są warte uwagi. Nie zawsze udaje mi się osiągnąć ten cel.

W szczególności muszę sobie przypominać ... „Nie dodawaj nowych funkcji, chyba że znasz jakieś prawdziwe aplikacje, które będą tego wymagać”. Oraz „Jeśli możesz uzyskać 90 procent pożądanego efektu za 10 procent pracy, użyj prostszego rozwiązania ”.

Pytanie brzmi: czy możesz napisać DOKŁADNĄ definicję SIMPLE pod względem zasady KISS? -Jeśli jest.

Nie.

Prosty - w tym konkretnym kontekście jest dokładnie odwrotny do złożonego. Prostota nie musi oznaczać: Każda głupia osoba musi to zrozumieć - ale musisz się upewnić, że możesz to zrozumieć, nawet jeśli sam tego nie napisałeś.

Złożoność można osiągnąć poprzez dokładne zrozumienie referencji - pozbądź się ich! Wiele plików / klas powiązanych ze sobą - nie ma mowy! I skomplikowany kod (czyli pętle łańcuchowe, wiele warstw ITE itp.) - nikt nie chce tego czytać.

Moim zdaniem: bardzo łatwo jest dodać kolejną funkcję, w klasach można również dodawać funkcje prywatne, aby nie bałaganić interfejsu. Dlaczego więc nie skorzystać z tej przewagi i ograniczyć swoje funkcje / procedury do 50 linii. Może nawet mniej. Uzyskaj wymowne imiona. W ten sposób większość komentarzy staje się przestarzała. W ten sposób twoje funkcje są łatwe do odczytania, łatwe do modyfikacji / rozszerzenia.

Oczywiście ... ostatnie kilka zdań działałoby tak: W klasach istnieje możliwość definiowania funkcji prywatnych, po prostu skorzystaj z tej możliwości, aby podzielić funkcje na 50 linijek, aby były bardziej czytelne (nie zapominaj o dobrych nazwach, więc nie musisz komentować tak dużo).

ALE: O wiele łatwiej jest (!) Przeczytać wszystko, jeśli jest przystanek, który pokazuje: Skończyłem myśl, przejdźmy do następnego.

To, co określiłbym jako proste.