프로그래밍의 첫 번째 원칙을 무엇이라고 생각하십니까?

59

나는 항상 "이것의 첫 번째 원칙은 무엇입니까?" 기본적인 것 (예 : 프로그래밍)을 배운 후 영감을주는 질문 인 IMO는 무엇보다 배후에서 가장 중요한 원칙, 특히 프로그래밍과 같은 기술에 대해 생각하게 할 수 있습니다.

그렇다면 프로그래밍의 첫 번째 원칙은 무엇이라고 생각하십니까? 나중에 아래에 답변을 드리겠습니다.

programming-languages 
— 웨이 펭 L
소스
파이트 클럽에 대해서는 이야기하지 않습니다.
— Job

답변:

97
  1. 키스-간단한 바보 유지
  2. 건조-스스로 반복하지 마십시오
  3. YAGNI-넌 필요 없어
— 계산서
소스
KISS는 단순하게 유지해야합니다. 똑똑하고 확장 가능한 디자인을하지 않았기 때문에 코드의 큰 덩어리를 다시 작성해야 할 때 이에 동의하게됩니다. :)
8
나는 KISS가 "간단하고 멍청하게 유지해야한다"고 생각합니다.
— Dennis C
실제로이 두 방법에 대한 블로그 게시물에 일하고 있어요 프로그래머의 마음에 가장 가까이와 사랑이 동시에 그들이 자주 모순 어법의 약간은 시간이 다른에 대해 하나를 선택해야합니다 방법
10
나는 또한 YAGNI를 추가 할 것입니다.
3
@Programmin Tool-나는 "멍청한"것이 불필요한 것이라고 생각하지 않습니다. 나는 그것이 "똑똑한"경향이 있고 이것이 불필요한 복잡성으로 나타난다 고 생각한다. 내가 알다시피, "멍청한"은 우리가 처음에 "똑똑하다"라고 생각하는 것을 일반적으로 기억하지 못하도록함으로써 이러한 경향을 상기시켜줍니다.
— codekaizen
37

해당 코드를 유지 관리해야하는 것처럼 코드를 작성하십시오.

— 패트릭 데 자르 딘
소스
이것은 매우 실용적인 휴리스틱입니다. 3x :)
19
도끼를 휘두르는 사이코 패스가 유지해야하는 것처럼 코드를 작성하십시오. FTFY.
— 세미콜론 잊혀진
10
그리고 도끼를 휘두르는 정신병자는 당신이 사는 곳을 알고 있습니다.
— CAD bloke
2
.. 그리고 그는 방금 도끼를 날카롭게했습니다 ...
— Roalt
1
... 그리고 그는 당신 옆에서 일하고 있습니다.
— Broken_Window
29

가능한 한 게 으르십시오.

— 프레스턴 길로
소스
2
다시 말하지만 IMO. 이것은 분명히 "느슨한"게으른 양이 얼마나 게으른 지 궁금하다.
이는 펄의 참조 "게으름, 성급함과 오만함"입니다
우리는 다른 종류의 게으름에 대해 이야기하고 있습니까? "게으른"Bob은 "코드가 엉
2
너무 일반적입니다. 그 유추에 따르면 모든 변수와 함수는 1 글자가됩니다. 왜냐하면 의미있는 것을 입력하기에는 너무 게으 르기 때문입니다. 그러나 그것을 유지해야한다고 가정하면 가능한 한 쉽게 유지 관리하기 쉽기 때문에 아마도 정확할 것입니다.
— Kyle Ballard
3
@Kyle : 예, 그게 요점입니다. "진정한 게으름"은 현재뿐만 아니라 미래에도 가장 쉬운 일입니다. 어떤 일을 제대로하는 것과 같은 것으로 판명되었습니다. 지금 더 적은 일을하고 나중에 더 많은 일을한다면, 당신은 "가능한 한 게으르지"않을 것입니다 :)
23

젠, 파트 I : 프로그래밍은 길이 아니라 길일뿐입니다.

프로그래밍은 컴퓨터에게해야 할 일을 가르치는 기술 일뿐입니다. 빠르고 안정적인 소프트웨어를 성공적으로 만들려면 알고리즘, 모범 사례 및 프로그래밍 (언어)에 반드시 연결되지 않은 다른 모든 항목을 알아야합니다.

젠, 파트 II : 급한 경우 천천히 걷는다. 정말로 서두르면 우회하십시오.

어리석게 들리지만 나중에 실제로 문제를 일으킬 수있는 타협에 빠지지 마십시오. 나는 규칙을 얻었다 : 만약 당신이 프로그램의 핵심이라면, 가능한 한 정확하고 훌륭하게 노력하십시오. 소프트웨어에 깊이있는 핵심 방법을 사용하는 경우 코딩 속도를 높이십시오. 이 두 가지 이상을 코딩하는 경우 조금 더 조잡해질 수도 있습니다.

설계 오류는 찾기 및 / 또는 수정하기가 가장 어렵고, 다음 단계는 모든 사람이 의존하는 부품의 프로그래밍 오류와 "실제 소프트웨어 부품"입니다. 프로젝트가 끝날 때 디자인 오류를 수정 해야하는 경우 음, 좋지 않습니다 ... ;-)

젠, 파트 III : 네 길을 알아, 네오.

환경, 도구 및 매일 의존하는 것들을 알고 그것이 당신을 위해 작동하도록 정렬하십시오. 프로그래밍 "환경"을 너무 자연스럽게 사용하여 생각조차하지 않는 것이 가장 좋습니다. 일을 끝내야한다면 "멋진 새 물건"을 소개하지 말고 일을하십시오. 이 물건들은 새로운 프로젝트에서, 즉 준비하고 사용할 시간이있을 때 소개 될 수 있습니다.

— 게오르기
소스
어, 그리고 다시 : 나는 프로그래밍에 대해 이야기하면서 Zen 땅에 착륙했습니다 :)
@part III-돈을받지 않으면 "멋진 새 물건"을 추가하지 마십시오!
— Jason
매트릭스 참조의 경우 +1 나는 좋은 사람 (
19

KISS (간단하고 멍청하게 유지).

실제로 "단순을 어떻게 정의합니까?"라는 질문을 실제로 간청합니다. 또한 "현재 어떤 일이 너무 간단한가?" 그렇기 때문에 프로그래밍의 첫 번째 원칙 만 알고 있으면 훌륭한 프로그래머가 될 수 없습니다.

— 디마
소스
나는 이것이 너무 일반적인 규칙이라고 생각합니다. "정말 간단하게 어떻게 정의합니까?"라는 질문을 제기합니다.
3
그리고 만약 당신이 바보라면, 그것이 단순한 지 어떻게 알 것입니까?
— Steven A. Lowe
좋은 예입니다, Steven :)
1
"그래서 프로그래밍의 첫 번째 원리 만 알고 있으면 좋은 프로그래머가 될 수 없습니다."
1
@Dima : 네 말이 맞아, 나는 품질과 단순성 (이 경우 적어도)은 정의 할 수 없지만, 우리의 눈이 훈련되면 그것을 볼 때 그것을 알고 있습니다.
— Adriano Varoli 광장
18

조기 최적화는 모든 악의 근원입니다. -도널드 크 누스

— Ryszard Szopa
소스
구현 또는 설계 여부.
16

바퀴를 재발 명하지 마십시오.

— 패트릭 데 자르 딘
소스
휠을 재발 명해야하는지 여부에 관한 질문에 대한 정답은 항상 "의존"입니다. 따라서 "바퀴를 재발 명하지 마십시오"는 지금까지만 진행되었습니다. 대부분의 경우 좋은 휴리스틱으로 사용되지만 항상 그런 것은 아닙니다.
5
일부 "바퀴"는 재창조되어야합니다.
던롭에게 알려주세요. 그는 공압 타이어를 발명했습니다. 휠을 재발 명하지 않으면 우리는 꽤 울퉁불퉁합니다.
— Kibbee
3
어떻습니까 : 혜택이 비용 가치가있는 경우에만 휠을 재발 명하십시오
— e.James
16

먼저 문제를 이해하십시오!

— OscarRyz
소스
아, 마침내이 사람을 가진 사람. 당신은 ca 키스, yagni, 당신이 원하는 모든 건조. 아무것도 프로그래밍하지 않으면 쓸모가 없습니다.
@ e-satis : 그래, 내가 처음 대답했을 때 내가 생각한 것. 나는 모든 대답을 스크롤하고 놀랍게도 아무도 전에 게시하지 않았습니다.
— OscarRyz 2016 년
좋은 대답입니다. 프로그래머가 문제의 전체 요구 사항을 제대로 이해하지 못하면 시간과 시간이 낭비됩니다.
— Steve Wortham
문제는 : 문제를 이해한다는 것을 어떻게 알 수 있습니까?
— CamelCamelCamel
13

YAGNI-당신은 그것을 필요로하지 않습니다 . YAGNI의 기본 개념은 잠재적 인 기능이 아닌 요구 사항에 맞게 프로그래밍하는 것입니다. 전제 조건은 프로그래밍해야 할 사항을 유지함으로써 (다른 것들 중에서) 코드 부풀림을 줄이고, 복잡성을 줄이며, 기능 충돌을 피하고, 수행 할 수있는 작업 (및 수행 방법)에 대한 제한을 줄입니다. 미래.

모듈 식 디자인과 함께 작동한다고 가정합니다. 기존 코드를 다시 디자인하지 않고도 향후 기능을 보강 할 수 있습니다.

— 브라이언 엠 헌트
소스
12

프로그래밍하지 않을 때 알기.

— ctrlShiftBryan
소스
이것은 무엇을 의미 하는가?
그리고 언제입니까?
때로는 솔루션을 코딩하는 것만이 아니라 사용자 문제를 다르게 다루어야하는 경우가 있습니다.
인간의 판단과 의사 결정은 모든 것의 일부입니다. 때로는 판단을 자동화하려는 데 아무런 의미가 없습니다.
— S.Lott
1
즉, 선반 응용 프로그램, 구성 요소 또는 라이브러리를 구매하여 많은 프로그래밍 문제를보다 저렴하고시기 적절하게 해결할 수 있습니다.
— Gordon Bell
11

커피 입력, 코드 출력

— 사용자
소스
3
내 경우에 차 =)
"Coffee In, Code + 많은 수의 휴식 시간과 같은 +1 흠?" :) 나는 커피와 차를 모두 사랑하고, 두 가지 방법으로 스윙합니다.
— Darknight
10

테스트하지 않은 경우 고장입니다.

— 라즈
소스
동의합니다
7

소프트웨어 설계를 구성하는 두 가지 방법이 있습니다. 한 가지 방법은 간단하게 결함이 없도록하고, 다른 방법은 너무 복잡하게하여 명백한 결함이없는 것입니다. 첫 번째 방법은 훨씬 더 어렵다.

-찰스 안토니 리차드 호 아레

— 크리스 조끼
소스
6

  1. 원인과 결과 구분 (컴퓨터 작업)

  2. 사실과 의견 구분 (사람과의 협력)

  3. 가능한 한 단순하지만 단순하지는 않습니다 (디자인).

— 마이클 이스터
소스
5
  1. 프로그램이 왜 누군가를 행복하게 하는지 이해하십시오 . (이 사람은 당신이 될 수 있습니다.)
  2. 필요한 모든 복잡성을 더 이상 포착하지 못하는 비즈니스 도메인 의 개념적 모델을 개발하십시오 .
  3. 필요한 모든 복잡성을 더 이상 포착하지 않는 소프트웨어 아키텍처 의 개념 모델을 개발하십시오 .
  4. 다른 모든 복잡성을 무자비 하게 유지하십시오.
— 도브와 세르 만
소스
잘했다! couldnt 더 동의
— Antony
5

제 생각에는 가장 중요한 원칙은 좋은 추상화 를 만들어서 복잡성 을 줄이는 것입니다 .

여기에는

  • 해결해야 할 문제를 이해하고
  • 적절한 솔루션을 설계하고
  • 그것을 구현,
  • 바람직하게는 코드를 이해하고 유지 보수 할 수있는 방식으로

피할 수없는 추가적인 복잡성을 피하기 위해 추상화 생성을 중단하고 구현 기술 (예 : 데이터베이스 시스템, 프로그래밍 언어)의 기본 속성으로 내려가는 지점을 결정합니다.

— mh
소스
4

청중을 염두에두고 프로그램하십시오. 따라서 귀하가 작성하는 내용이 귀 하나 다른 사람이 읽거나 유지하지 않을 것이라고 가정하지 마십시오.

이에 대한 추론 : 변수와 ​​함수 및 클래스의 이름을 잘 지정하여 해결하려는 문제를 이해하고 있음을 증명하십시오!

— 화제
소스
4

테스트에서 보여줄 때까지 작동하지 않습니다.

— 오둔
소스
6
사실이 아닙니다. 작동하고 테스트되지 않은 수많은 코드를 작성했습니다! : D
1
"나는 그것을 테스트하지 않았다, 나는 그것이 옳다는 것을 증명했다":)
— Daniel Daranas
4

먼저 생각하고 나중에 코드를 작성하십시오.

당신이 생각하는 것만 큼 똑똑한 곳은 없습니다. 질문. 동료를 소중히 여기는 법을 배우십시오.

디버깅 할 때 첫 번째 대답은 거의 항상 틀릴 것입니다.

던지기 위해 쓰는 코드는 훨씬 더 큰 프로세스의 초석이되는 경향이 있습니다. 우연히 쓰여진 것을 남겨 두지 마십시오.

— 마이크 호퍼
소스
3

다른 간접 계층으로 모든 문제를 해결할 수 있습니다.

— 여호수아
소스
실제로, 너무 많은 간접적 인 지시는 그 자체가 확인되고 해결되기를 기다리는 문제입니다. 그래서 ..
또 다른 간접 계층에 의해 해결되었습니다! =)
— Erik Forbes
이상하게도 그 사실입니다. 봄을 봐 ...
3

원칙 : 소프트웨어는 지식 포착 입니다.

결과 : 지식 표현을위한 많은 기술이 모두 추상화에 있습니다. 계층, 계층, 캡슐화, 우려 분리를 제공합니다.

프로 시저 표현에 대한 많은 기술은 모두 Sequence , Choice , Repetition에 있습니다.

— 로트
소스
3

코드를 유지할 사람이 당신이 사는 곳을 알고있는 정신병 연쇄 살인범처럼 항상 코드를 작성하십시오

또한 프로그래밍에 대한 모든 것을 알고 있다고 생각하지 말고 계속 학습하십시오.

— 에이미
소스
2

나는 디지털 전자 공학을 공부하면서 프로그래밍에 들어갔 기 때문에 프로그래밍의 첫 번째 원칙은 기본 로직 게이트 (또는 xor가 암시하지 않음)라고 생각합니다.

— 도마뱀 빌
소스
2

쓰레기 수거-쓰레기 수거 데이터가 좋지 않은 경우 사용자 인터페이스가 얼마나 좋은지는 중요하지 않습니다.

— HLGEM
소스
2

DRY, 다른 모든 것들이 스폰됩니다. KISS는 광기 수준에 소프트웨어 우아함을 추구하지 않도록 균형 잡기의 다른 끝입니다.

— 기발한
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.