Co uważasz za pierwszą zasadę programowania?

59

Zawsze lubiłem zadawać sobie pytanie: „jakie są pierwsze zasady?” po tym, jak nauczyłem się podstawowych rzeczy (np. programowania). To inspirujące pytanie, IMO, które może zmusić cię do myślenia o najważniejszych zasadach stojących za czymś, szczególnie umiejętności takich jak programowanie.

Jak myślisz, co jest pierwszą zasadą programowania? Nieco później dam odpowiedź poniżej.

Weipeng L.
źródło
Nie mówimy o klubie walki.
Job

Odpowiedzi:

97
  1. KISS - Keep It Simple Stupid
  2. SUCHO - Nie powtarzaj się
  3. YAGNI - Nie będziesz go potrzebować
Rachunek
źródło
KISS powinien być Keep It Simple Smart. Za pierwszym razem, gdy musisz przepisać dużą część kodu, ponieważ nie zaprojektowałeś inteligentnego i rozszerzalnego, zgodzisz się na to. :)
8
Myślę, że KISS powinien brzmieć „Keep Simple, Głupi!”
Dennis C,
Właściwie pracuję nad postem na blogu o tym, jak ci dwaj są najbardziej bliscy i drodzy sercu programistów i jak jednocześnie są trochę oksymoronami, jak często trzeba wybierać jeden przeciwko drugiemu
10
Dodałbym również YAGNI.
3
@Programmin Tool - Nie sądzę, żeby „głupi” był zbyteczny. Myślę, że to pokazuje, że mamy tendencję do bycia „inteligentnymi”, a to przejawia się jako niepotrzebna złożoność. Moim zdaniem „głupi” próbuje nam przypomnieć o tej tendencji, pomagając nam pamiętać, co początkowo uważamy za „mądre”, zwykle nie.
codekaizen
37

Napisz kod tak, jakby to Ty musiałbyś go utrzymywać.

Patrick Desjardins
źródło
To bardzo praktyczna heurystyka, 3x :)
19
Napisz kod tak, jakby psikopata dzierżący topór musiał go utrzymać. FTFY.
Forgotten Semicolon
10
... a dzierżący topór psychopata wie, gdzie mieszkasz.
CAD bloke
2
.. i właśnie wyostrzył siekierę ...
Roalt
1
... a on pracuje u twojego boku.
Broken_Window
29

Bądź tak leniwy, jak to możliwe.

Preston Guillot
źródło
2
Ponownie, zbyt ogólne, IMO. To nasuwa pytanie: „Jak leniwa jest odpowiednia ilość lenistwa, naprawdę?”, Ponieważ oczywiście „niechlujstwo” jest czymś, czym nie chcesz być.
Jest to odniesienie do „Lenistwa, niecierpliwości i pychy” Perla
Więc mówimy o innym rodzaju lenistwa? Myślałem o „leniwych” Bob oznacza „nie przeszkadza organizuje swój kod przed pobiera splątane”: D
2
Zbyt ogólne. Według tej analogii wszystkie zmienne i funkcje miałyby 1 literę, ponieważ byłem „zbyt leniwy”, aby wpisać coś znaczącego. Zakładając, że musiałem to również utrzymywać, być może masz rację, ponieważ uczynię to tak łatwym do utrzymania, jak to możliwe.
Kyle Ballard
3
@Kyle: Tak, o to chodzi. „Prawdziwe lenistwo” sprawia, że ​​wszystko jest łatwiejsze zarówno teraz, jak i w przyszłości. Co okazuje się tym samym, co robienie rzeczy właściwie. Jeśli teraz pracujesz mniej, a więcej później, nie będziesz „leniwy”.
23

Zen, część I: Programowanie to tylko droga, a nie droga.

Programowanie jest tylko techniką uczenia komputera, co musi robić. Sukces w tworzeniu szybkiego, niezawodnego oprogramowania oznacza znajomość algorytmów, najlepszych praktyk i wszystkich innych rzeczy niekoniecznie związanych z programowaniem (językiem).

Zen, część II: Jeśli się spieszysz, idź powoli. Jeśli naprawdę się spieszysz, objazd.

Brzmi głupio, ale nie pozwól sobie na kompromisy, które (naprawdę) mogą później sprawić ci kłopotu. Mam zasadę: jeśli jesteś rdzeniem programu, postaraj się być jak najbardziej precyzyjny i dobry. Jeśli używasz metod od samego rdzenia, które są głęboko w twoim oprogramowaniu, postaraj się szybciej kodować. Jeśli kodujesz powyżej tych dwóch, możesz nawet trochę bardziej niechlujny.

Błędy projektowe są najtrudniejsze do znalezienia i / lub naprawienia, następnym krokiem są błędy programistyczne w częściach, na których wszyscy polegają, a następnie „prawdziwe popisywanie się części oprogramowania”. Jeśli musisz naprawić błąd projektowy na końcu projektu, ummm, to nie jest dobre ... ;-)

Zen, część III: Poznaj swoją ścieżkę, Neo.

Poznaj swoje środowisko, narzędzia i rzeczy, na których codziennie polegasz, i posortuj je, aby działało dla Ciebie. Najlepiej, jeśli używasz „środowiska” programowania tak naturalnego, że nawet nie musisz o tym myśleć. Jeśli musisz wykonać pracę, nie wprowadzaj „nowych wymyślnych rzeczy”, ale wykonuj swoją pracę. Te rzeczy można wprowadzić w nowym projekcie, a mianowicie wtedy, gdy masz czas na ich przygotowanie i użycie.

Georgi
źródło
I znowu: wylądowałem w krainie Zen, mówiąc o programowaniu :)
@ część III - nie dodawaj „nowych fantazyjnych rzeczy”, chyba że dostaniesz za to wynagrodzenie!
Jason
+1 za odniesienie do macierzy. Jestem frajerem dobrego (to i Zen. Sprawia, że ​​myślę o Pythonie)
19

KISS (niech to będzie proste, głupie).

To rzeczywiście nasuwa pytanie „Jak definiujesz proste?” A także „Kiedy jest coś zbyt prostego do wykonania zadania?” Dlatego nie możesz zostać dobrym programistą, znając pierwszą zasadę programowania.

Dima
źródło
Myślę, że to zbyt ogólna zasada. Nasuwa się pytanie „jak naprawdę zdefiniować„ proste ”.
3
a jeśli jesteś głupi, to skąd byś wiedział, gdyby to było proste?
Steven A. Lowe
To dobrze, Steven :)
1
„Dlatego nie możesz zostać dobrym programistą, znając pierwszą zasadę programowania” - uwielbiaj to.
1
@Dima: masz rację, mam na myśli, że jakość i prostota (przynajmniej w tym przypadku) są nie do zdefiniowania, ale wiemy to, kiedy to widzimy, jeśli nasze oczy są wytrenowane.
Adriano Varoli Piazza
18

Przedwczesna optymalizacja jest źródłem wszelkiego zła. - Donald Knuth

Ryszard Szopa
źródło
Czy we wdrażaniu LUB w projekcie.
16

Nie wymyślaj koła ponownie.

Patrick Desjardins
źródło
Prawidłowa odpowiedź na pytanie, czy należy wymyślić koło na nowo, zawsze brzmi „zależy”. Tak więc „nie wymyślaj koła ponownie” idzie tak daleko. Może to służyć jako dobra heurystyka przez większość czasu, ale nie za każdym razem.
5
Niektóre „koła” wymagają ponownego opracowania.
Powiedz to Dunlopowi. Wynalazł oponę pneumatyczną. Gdyby to nie on wymyślił koło, mielibyśmy dość wyboistą jazdę.
Kibbee
3
A może:
Wymyśl
16

Zrozum najpierw problem!

OscarRyz
źródło
Ach, w końcu ktoś z tym. Możesz całować, yagni, wysuszyć wszystko, czego chcesz. Nie ma sensu, jeśli programujesz coś za darmo.
@ e-satis: Tak, to właśnie myślałem, kiedy po raz pierwszy na to odpowiedziałem. Przewijam wszystkie odpowiedzi i, o dziwo, nikt wcześniej nie napisał.
OscarRyz
Dobra odpowiedź. Godziny i godziny marnują się, gdy programiści nie rozumieją w pełni wymagań danego problemu.
Steve Wortham
Problem polega na tym: skąd wiesz, że rozumiesz problem?
CamelCamelCamel
13

YAGNI - Nie będziesz go potrzebował . Ideą YAGNI jest programowanie pod kątem twoich wymagań, a nie potencjalnych, potencjalnych funkcji. Założeniem jest, że przestrzegając tego, co musisz zaprogramować, będziesz (między innymi) zmniejszać rozdęcie kodu, zmniejszać złożoność, unikać pełzania funkcji i ograniczać ograniczenia dotyczące tego, co można zrobić (i jak można to zrobić) w przyszłość.

Podejrzewam, że działa w tandemie z modułową konstrukcją: przyszłe funkcje można rozszerzyć bez przeprojektowywania istniejącego kodu.

Brian M. Hunt
źródło
12

Wiedzieć, kiedy nie programować.

ctrlShiftBryan
źródło
co do licha to ma znaczyć?
A kiedy to jest?
Czasami musisz rozwiązać problem użytkowników inaczej - nie tylko kodować rozwiązanie.
Ludzki osąd i podejmowanie decyzji są częścią wszystkiego; czasami nie ma sensu próbować zautomatyzować oceny.
S.Lott,
1
Ma na myśli to, że wiele problemów programistycznych można rozwiązać taniej i szybciej, kupując gotowe aplikacje, komponenty lub biblioteki.
Gordon Bell
11

Kawa weszła, kod wyszedł.

użytkownik9282
źródło
3
Herbata w moim przypadku =)
+1 hmm bardziej jak „Kawa w kodzie, kod + dużo przerw na odpoczynek?” :) Uwielbiam kawę i herbatę, huśtam się w obie strony ...
Darknight
10

Jeśli nie został przetestowany, jest zepsuty.

Raz
źródło
Zgadzam się w tej sprawie
7

Istnieją dwa sposoby konstruowania projektu oprogramowania: Jednym ze sposobów jest uczynienie go tak prostym, aby oczywiście brakowało braków, a drugim sposobem jest uczynienie go tak skomplikowanym, aby nie było oczywistych braków. Pierwsza metoda jest znacznie trudniejsza.

- Charles Antony Richard Hoare

Chris Vest
źródło
6
  1. Rozróżnij przyczynę i skutek (praca z komputerami)

  2. Rozróżnij fakt i opinię (praca z ludźmi)

  3. Tak proste, jak to możliwe, ale nie prostsze (projekt)

Michael Easter
źródło
5

Programowanie to środek, a nie koniec. A może „Can nie oznacza, że ​​powinien”.

CrashCodes
źródło
5
  1. Dowiedz się, dlaczego program uszczęśliwia kogoś (w przeciwnym razie, dlaczego nie bawisz się na zewnątrz z innymi dziećmi?). (Tą osobą może być ty.)
  2. Opracuj koncepcyjny model domeny biznesowej, który uchwyci całą potrzebną złożoność i nic więcej.
  3. Opracuj koncepcyjny model architektury oprogramowania, który uchwyci całą potrzebną złożoność i nic więcej.
  4. Bezwzględnie trzymaj się wszelkiej innej złożoności.
Dow Wasserman
źródło
dobrze powiedziane! nie mogłem się zgodzić więcej
Antony
5

Moim zdaniem najważniejszą zasadą jest zmniejszenie złożoności poprzez tworzenie dobrych abstrakcji .

To zawiera

  • zrozumienie problemu do rozwiązania,
  • zaprojektowanie odpowiedniego rozwiązania i
  • wdrażając to,
  • najlepiej w taki sposób, aby kod był zrozumiały i łatwy do utrzymania,

ale także określenie punktu, w którym należy przestać tworzyć abstrakcje i przejść do podstawowych właściwości technologii wdrażania (np. system bazy danych, język programowania), aby zapobiec tworzeniu dodatkowej złożoności, której można uniknąć.

mh
źródło
4

Programuj z myślą o widowni. W ten sposób nie zakładaj, że nic, co napiszesz, nie będzie czytane i przechowywane przez ciebie lub kogoś innego.

Następstwem tego jest: Udowodnij, że rozumiesz problem, który próbujesz rozwiązać, dobrze nazywając zmienne, funkcje i klasy!

torial
źródło
4

nie działa, dopóki nie pokazałeś tego w teście

Audun
źródło
6
To nieprawda, napisałem mnóstwo kodu, który działa i nie jest testowany! : D
1
„Nie testowałem tego, udowodniłem tylko, że jest poprawny” :)
Daniel Daranas
4

Pomyśl najpierw, kod później.

Nie jesteś tak inteligentny, jak ci się wydaje. Zadawać pytania. Naucz się cenić swoich rówieśników.

Podczas debugowania pierwsza odpowiedź prawie zawsze będzie błędna.

Kod, który piszesz z zamiarem wyrzucenia, staje się podstawą znacznie większych procesów. Nigdy nie zostawiaj niczego napisanego przypadkowo.

Mike Hofer
źródło
3

Każdy problem można rozwiązać za pomocą innej warstwy pośredniej.

Jozuego
źródło
W rzeczywistości zbyt wiele pośrednich jest problemem, który czeka na rozpoznanie i rozwiązanie. Więc ..
rozwiązane ... przez kolejną warstwę pośrednictwa! =)
Erik Forbes
Co dziwne, to prawda. Spójrz na wiosnę ...
3

Poznaj swoje narzędzia.

dmckee
źródło
3

Zasada: Oprogramowanie to przechwytywanie wiedzy .

Konsekwencje: Wiele technik reprezentacji wiedzy, wszystkie oparte na abstrakcji . Daje nam warstwy, poziomy, hermetyzację, rozdzielenie problemów.

Wiele technik reprezentacji procedur, wszystkie oparte na sekwencji , wyborze , powtórzeniu .

S.Lott
źródło
3

Napisz kod dla następnego faceta.

Gabriel Isenberg
źródło
3

Zawsze pisz kod tak, jakby osoba, która go utrzyma, jest psychotycznym seryjnym zabójcą, który wie, gdzie mieszkasz

Nigdy nie myśl, że wiesz wszystko o programowaniu, kontynuuj naukę

Amy
źródło
2

Zacząłem programować, studiując elektronikę cyfrową, więc sądzę, że podstawowe bramki logiczne (nie, i xor, jak sugeruje) były pierwszymi zasadami programowania.

Bill jaszczurka
źródło
2

Chodzi o użytkownika.

Bryan Oakley
źródło
2

Śmieci w - Śmieci w Nie ma znaczenia, jak ładny jest twój interfejs użytkownika, jeśli dane są złe.

HLGEM
źródło
2

SUCHO, prawie wszystko inne odradza się z tego. KISS jest drugim końcem działania równoważącego, aby upewnić się, że nie dążysz do elegancji oprogramowania do poziomu szaleństwa.

Quibblesome
źródło
2

Zacznij od wyjścia i pracuj wstecz.

mea
źródło