이 사람은 누구라고 생각합니까? 그는 "훌륭한" 코드 작성에 대해 무엇을 알고 있습니까?!

그렇게 생각하는 것이 100% 옳을 것입니다. 그리고 완전히 정직하게 말하면… 저는 훌륭 하지 않은 코드를 작성하는 데 훨씬 더 많은 경험이 있습니다.

좋지 않은 코드는 여러 가지 이유로 작성됩니다(일부는 아래에 나열됨).

1. 그것의 단단한
2. "위대한"은 주관적입니다
3. 소프트웨어는 결코 완성되지 않는다
4. 품질은 현재 요구 사항에 따라 변경될 수 있습니다.
5. 작동하는 많은 소프트웨어가 좋지 않습니다(나쁜 역할 모델).
6. 소프트웨어를 원하는 사람들은 종종 소프트웨어 엔지니어가 아닙니다.
7. …

최적이 아닌 코드에 대한 깊은 경험에도 불구하고 저는 거의 10년 동안 저와 다른 인간이 원하는 것을 컴퓨터에게 (가능한 한 친절하게) 요청한 경험이 있습니다.

그동안 저는 다양한 개념과 패턴을 이해하게 되었고 다른 사람들에 대한 깊은 불신도 배웠습니다.

이 기사에서는 소프트웨어의 좋은 점과 나쁜 점을 간략하게 설명하고 실제 똑똑한 사람들의 증거를 제공합니다.

라이드에 오신 것을 환영합니다

"훌륭하다"는 것

"훌륭함"이 무엇인지 정의하는 것으로 시작하겠습니다. 그러나 그렇지 않은 것을 빠르게 언급함으로써 정의하기가 더 쉬울 수 있습니다.

훌륭한 코드는

1. 읽기 어렵지 않다
2. 추론하기 어렵지 않다
3. 오늘 또는 글을 쓴 후 7일 동안 자신을 미워하게 만들지 않습니다.

1. 90% 구조 및 10% 구문
2. 예측 자원 관리와 쌍을 이루는 정보 추상화 기능
3. 수학 친구(구체적으로 집합/범주 이론)
4. 하드웨어가 아닌 사람을 위해 작성됨

1. 90% 구조 및 10% 구문

이 모든 아이디어는 훨씬 더 포괄적이고 깊은 주제에서 영감을 얻었습니다. 구조와 관련하여 SOLID 프로그래밍 패러다임을 살펴볼 수 있습니다.

SOLID는 유지 관리 가능한 소프트웨어를 구축하기 위해 따라야 하는 5가지 "규칙" 집합을 나타냅니다. 아래에 나열된 개념

S - Single-responsiblity Principle
O - Open-closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D - Dependency Inversion Principle

이러한 원칙은 객체 지향 프로그래밍(좋아하든 싫어하든)의 힘을 중심으로 하며 추상화를 소프트웨어 친화적인 덩어리로 나누는 우아한 방법을 설명합니다.

이러한 원칙을 따르면 기능적 소프트웨어에서 발생하는 많은 고약한 복잡성을 피할 수 있습니다.

예를 들어 SOLID 원칙을 사용하면 코드 공간을 줄이고 공통 기능을 중심으로 파일을 배치할 수 있습니다. 코드베이스의 다른 부분에 영향을 주지 않고 기능을 쉽게 탐색하고 추가/제거할 수 있습니다.

이러한 문제는 코드 수준이 아닌 애플리케이션의 구조 수준 에서 완전히 방지됩니다

구조 수준 청결은 지속적인 조직을 강화하는 강력한 방법입니다.

Digital Ocean의 SOLID에 대한 이해하기 쉬운 기사: 여기

그것이 충분하지 않다면 — Bob 삼촌은 계속해서 뱅커를 떨어뜨립니다 .

2017년에 발표된 그의 최신 책을 적극 추천합니다(솔직히 더 최근의 모든 책도 마찬가지입니다).

"클린 아키텍처: 소프트웨어 구조 및 디자인에 대한 장인 가이드" —https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/

이 책은 이러한 개념을 시스템 수준 으로 확장하는 방법을 탐구합니다 .

더 많은 애플리케이션을 "클라우드"로 이동하고 분산 서비스를 활용합니다. 이러한 디자인 원칙은 코드의 위대함 에 점점 더 많은 영향을 미칩니다 .

훌륭한 코드는 애플리케이션 디자인의 구조를 채우는 도구일 뿐이며 시스템은 구문이 아닌 구조를 통해 표현되어야 합니다.

2. 예측 자원 관리와 짝을 이루는 정보 추상화 기능

음… 당신은 그것으로 나를 정말 잃었습니다. 와우의 기능?

그것을 분해하자.

"정보 추상화 기능"은 우리의 코드가 추상화의 출력임을 표현하는 간결한 방법입니다 .

즉, 우리의 코드는 우리가 응용 프로그램의 개념을 분할하기로 결정한 방법을 반영합니다.

더 구체적으로; 문제에 직면하여 "사용자"와 "세션"을 만들어야 한다고 결정하면 문제를 사용자와 세션이라는 추상적인 아이디어로 효과적으로 분할한 것입니다.

...알았어 우리는 "정보 추상화 기능"을 다루었다고 생각합니다.

다음으로 소프트웨어 엔지니어가 미래를 내다보고 미래의 변화를 견딜 수 있는 시스템을 구축하는 임무를 맡은 멋진 방법인 "예측 자원 관리"와 짝을 이룹니다

몰랐다면 — 최신 프레임워크가 생성되기 1년 전에 최신 프레임워크를 사용하지 않은 것은 프로그래머의 잘못입니다. 어떻게 몰랐어!? (비꼬는 말로 읽어주세요. 개인적이지 않다는 것을 약속드립니다).

요약하자면; 코드의 품질이 항상 계산 복잡성, 줄 수 또는 우아한 변수 이름에 있는 것은 아닙니다.

미래의 예측할 수 없는 변화를 견딜 수 있도록 문제 를 추상적인 덩어리로 효과적으로 분할 하는 능력입니다 .

예 예 예, 알고 있습니다. 그것은 가능하지 않은 것 같습니다. 그렇지 않습니다. 개발자로서 우리가 알고 있는 것과 모르는 것을 관리하는 것이 우리의 임무입니다.

그것은 위험 평가 및 비용 계획에 대한 연습입니다. 허, 당신이 가입한 것을 몰랐습니다.

그러나 희망이 있습니다!

신뢰할 수 있는 개념 (곧 추가 예정)을 따름으로써 우리는 변화하는 세상을 위해 우리 자신과 응용 프로그램을 강화할 수 있습니다.

정말 좋은 내용에 들어가기 전에 — 여기에서 "신뢰"할 가치가 있는 몇 가지 아이디어를 인정할 수 있습니다.

• 표준 기관(이미 그것에 대해 깊이 생각한 사람들이 있습니다. 그들의 훌륭한 작업을 활용하면 정말 감사할 것입니다. 이것은 특히 알고리즘, 보안, 교차 플랫폼 및 QR 코드와 같은 기타 정말 중요한 것들에 적용됩니다).
• 정적 및 강력한 유형의 언어(솔직히 이것은 피해야 할 낮은 수준의 보안 문제에 관한 것이 아닙니다. 유형의 인간 중심적 특성에 관한 것입니다. 하나는 코드에서 유형을 위반하면 컴파일러가 소리를 지르고 둘째, 다른 개발자는 실제로 코드가 수행하는 작업을 알 수 있습니다.)
• 시(단어보다는 몇 가지 기호로 복잡한 의미를 전달하는 능력에 대한 것입니다. 귀하의 코드는 시입니다. 상상력이 매우 부족한 청중이지만 여전히 짧고 달콤하게 읽어야 합니다).

당신이 아닐 수도 있지만 — 당신의 코드는 수학과 친구가 되어야 합니다.

예, 알아요. 수학은 지루하고 실생활에서 미분을 사용한 적이 없습니다.

하지만…. 약속합니다. 매우 도움이 될 수 있습니다. 실제로 우리가 가지고 있는 가장 신뢰할 수 있는 도구입니다.

오랜 오픈 소스 기여 역사를 가지고 있고 핵심 소프트웨어의 대부분의 버그를 해결했기 때문에 신뢰할 수 있습니다. 이제 개발자(수학자)는 양자 물리학과 같은 미친 것들을 알아내느라 바쁩니다.

은행 계좌와 통신을 보호하기 위해 암호화와 같은 유용한 정보를 신뢰할 수 있습니다. [ADD FAVORITE PROGRAMMING LANGUAGE HERE]의 유형 시스템을 적용하기 위해 집합 이론을 신뢰할 수 있습니다. 어리석은 일을 유지하기 위해 Google지도 및 ChatGPT에서 경로를 최적화하기 위해 선형 대수학을 신뢰할 수 있습니다.

모든 멋진 UI와 빛나는 화면 뒤에는 컴퓨터가 바로 그것이라는 사실을 기억하는 것이 중요합니다. 컴퓨터 사용자.

모든 복잡성을 제거하면 덧셈과 뺄셈의 핵심만 남습니다.

아마도, 아마도… 우리가 우리 자신의 코드에 그 모든 힘을 불어넣을 수 있는 방법이 있을 것입니다.

조금 더 깊이 잠수하자

당신(독자)이 객체지향 프로그래밍에 익숙하다고 가정하겠습니다.

그리고... 또한 함수형 프로그래밍에 대해 들어본 적이 있을 것이라고 짐작할 수 있습니다. 그러나 그것은 나중에 배울 내용이라고 결정했습니다.

당신이 그 진영에 있다면 전통적인 수학의 의미론을 더 밀접하게 따르는 프로그래밍 언어의 아름다움과 우아함을 인식하지 못할 수 있습니다.

우리(평범한 사람들)는 주류 언어가 제공하는 추상화에 빠져 있습니다. 우리는 우리가 원할 때마다 변수를 생성할 수 있고 복잡한 제어 흐름을 구성할 수 있기를 기대 if합니다else

그러나 우리(일반인)는 더 스마트한 함수형 프로그래밍 카운터 파트에 주목해야 합니다.

단순하고 제한적인 언어에는 숨겨진 초능력이 있습니다. 증명 가능한( ⚡️ 수학 기반 ) 방법을 제공하여 코드가 모든 경우를 다루거나 무한한 기계에 분산될 수 있는 별개의 작업 조각으로 나눌 수 있음을 보여줍니다.

Infinity와 Proofs는 일반 프로그래머에게는 어려운 아이디어이지만 수학자라면 누구나 아침 식사로 먹습니다.

예를 들어 아래 비디오의 슈퍼히어로 중 한 명은 시스템 모델링이 실제 코드를 한 줄도 보지 않고 믿을 수 없을 정도로 복잡한 버그를 악용하기 위한 단계별 지침을 찾는 방법을 어떻게 제공하는지 보여줍니다

비밀은 시스템 설계에 적용되는 공식 수학의 힘에 있습니다.

올바르게 적용되면(모든 것을 함수형 언어로 다시 작성할 필요는 없습니다) 수학의 모든 이점을 무료로 얻을 수 있습니다.

이러한 혜택에는 다음이 포함되지만 이에 국한되지는 않습니다.

• 프로그램을 사용할 수 있는 모든 가능한 방법에 대해 자동으로 테스트 생성
• 응용 프로그램에 구성 요소 또는 시스템을 제거하는 추가의 의미를 탐색합니다.
• 코드가 작동하는지 100% 확신하십시오. 비행기 랜딩 기어 소프트웨어가 제대로 작동하는지 확인하고 싶을 것입니다.
• 이 비디오의 연사가 가르칠 수 있는 다른 더 복잡한 것들. 아, 그리고 이것을 배우는 것에 대해 진지하게 생각한다면 TLA+를 확인하세요.

어쩌면 우리는 놀랍도록 지루한 개념 중 일부를 사용하여 코드를 지루할 정도로 놀랍게 만들 수 있습니다.

훌륭한 코드는 지금부터 1000년 이상 동일한 아이디어가 적용될 수 있는 구체적인 아이디어를 갖기를 열망해야 합니다.

Pathagotem은 ~기원전 570년에 삼각형을 위한 훌륭한 소프트웨어를 내놓았습니다… 1500년 전과 같습니다!

가능한 경우 수학에서 배우거나 사용해야 할 수도 있습니다. 인간이 오래 지속되는 추상화를 표현하는 방법을 아는 가장 좋은 방법입니다.

4. 하드웨어가 아닌 사람을 위해 작성

좋아, 수학 문제는 충분해. 우리가 소프트웨어에 대해 이야기할 때 인간을 피하려고 하는 만큼 말입니다. 그들은 항상 혼합됩니다.

인간에 대해 이야기합시다. 인간은 어떻게 적응합니까?

글쎄요... 그들은 처음부터 소프트웨어를 원하는 사람들이고 실제로 이러한 언어를 생각해 낸 사람들입니다.

게다가 컴퓨터는 자신이 실행하는 코드에 대한 의견이 없습니다.

사람들은 그렇습니다. 사람들은 "작동"하는 것과 그렇지 않은 것을 정의합니다.

그래서 — 우리는 인권을 위해 모든 것을 지향해야 한다고 생각합니까?

예! 이는 예쁜 UI와 인체공학적 모바일 앱이 필요하다는 의미만은 아닙니다.

인간성을 소프트웨어 개발로 확장해야 합니다. 우리는 이것을 여러 수준에서 느껴야 합니다 .

인류는 모든 수준의 개발자 경험에 있어야 합니다. 다음은 인간 중심의 몇 가지 질문입니다.

• 사람들은 코드베이스에 온보딩됩니다. 당신의 문서는 그것을 용이하게합니까?
• 몇 개의 도구/명령 또는 특수 설정 단계를 수행해야 합니까?
• 새 테스트를 추가하는 것은 어떤 모습입니까? 새로운 기능?
• 당신의 프로젝트는 얼마나 많은 프레임워크/언어를 요구합니까? 더 적을 수 있습니까?
• 완전히 새로운 것에서 완전한 생산에 이르기까지 얼마나 많은 노력이 필요합니까?
• 깨는 모습은? 그것을 고치기 위해 깨어나야 합니까?

그러나 좋은 개발자로 구성된 소규모 팀은 부품일 경우 합보다 큽니다(올바르게 수행된 경우).

그렇다면 팀에서 어떻게 훌륭한 코드를 얻을 수 있을까요 ?

일부 솔루션은 다른 솔루션보다 쉽습니다. 예를 들어 쉽고 효과적인 방법은 모든 것을 표준화하는 것입니다. 즉, 개별 기여에서 모든 개성을 제거하는 것입니다.

가혹하게 들리겠지만 견고한 시스템은 작업을 수행하는 특정 방식/유형/패턴을 갖습니다. 코드 구문에는 사용자 정의와 창의성이 거의 없어야 합니다.

이것이 좋은 이유는 무엇입니까? 개발자의 정신적 부담을 크게 덜어줍니다. 무언가를 할 수 있는 "방법"이 있다면 그 "방법"을 수행해야 합니다.

이는 솔루션을 코드 수준에서 구조 수준(앞에서 언급함)으로 효과적으로 이동합니다. 우리는 맞춤형 결정보다는 시스템 수준의 결정과 패턴에 의존해야 하기 때문입니다.

간단히 말해서 모든 개발자는 공통 유형을 공유해야 합니다. 이렇게 하면 사용자 지정이 제거되고 다양한 개발자 작업을 훨씬 쉽게 통합할 수 있습니다.

이 아이디어는 형식보다 훨씬 더 확장되어야 하며 시스템 수준에서 효과적으로 표준화할 수 있는 개념이 많을수록 코드가 커집니다.

훌륭한 코드는 다른 팀 구성원의 잘 작성된 기여가 종종 코드베이스의 다른 부분과 구별되지 않습니다. 또한 한 사람이 어디에서 시작하고 다른 사람이 끝냈는지 볼 수 없어야 합니다.

다음 비디오에서는 시스템이 더욱 복잡해짐에 따라 팀을 구성하고 생산성을 높이는 전략을 자세히 살펴봅니다.

이것은 복잡한 시스템 디자인의 아이디어가 컴퓨터의 범위를 훨씬 벗어나고 동물/식물 생물학, 사회적 상호 작용 및 행성과 같은 자연 현상을 다루기 때문에 매혹적인 주제입니다.

우리는 필사자/개발자에 불과하며 우리 손에 많은 힘을 쥐고 있습니다. 우리는 복잡하고 쓸모없는 것들의 엄청난 더미를 만들 수 있습니다 — 그리고 같은 손으로 제가 이 글을 쓰고 있는 행성과 다르지 않은 우리만의 복잡한 동적 시스템을 만들 수 있습니다.

다음 시간까지 계속 코딩하고 사랑과 평화를 전파하세요 ✌️