내가 아는 길을 따른 다음 올바른 코딩 방법을 구현하거나 좋은 코딩 방법으로 시작하여 퍼지하려고 노력합니까?

우선, 나는 취미로 절차 적 프로그래밍을하는 데 익숙하다고 말하고 싶습니다. 저는 몇 가지 언어로 OOP를 배우고 연습이 아닌 이론을 이해하려고합니다 .

특히 데이터베이스 백엔드가있는 PHP에서 빌드하려는 애완 동물 프로젝트가 있습니다 (무엇을 신경 쓰지 않았습니까). 내 주된 이유는 모든 장치에서 앱을 사용했기 때문에 WebApp이 논리적 인 선택처럼 보였습니다.

유지 관리 가능한 PHP 웹 응용 프로그램을 빌드하려면 OOP, 클래스, 프레임 워크, 라이브러리 등을 사용해야한다는 것을 이해합니다. 이것은 논리적으로 들리므로 인기있는 웹 사이트 중 일부를 사용해보기로 결정합니다. 그러나 주말 동안 시도하고 자습서를 끝내려고 한 주말 내내 튜토리얼을 소규모 프로젝트에 적용하려고 혼란스럽고 좌절했습니다.

나는 주로 개념 증명을 위해 다른 프로그램 (Microsoft Access)에서 앱을 빌드하기로 결정하고 몇 시간 만에 웹 파트를 제외하고 주요 목표를 달성했습니다.

내 질문은 내가, 내가 알고있는 경로를 따라야한다 다음 올바른 코딩 방법을 구현하기 위해 시도하거나 내가해야 시작 관행을 코딩 좋은으로, 그리고를 통해 내 방식을 꾸며 낼려고? 이 프로젝트의 경우 GitHub에서 공개 소스가되기를 원하므로 코드를 사용하고 변경하는 다른 사람들에게 열려 있지만 코드를 잘못 작성하면 도움이되는 코더를 수집하기가 어렵다는 것도 알고 있습니다.

모범 사례는 주로 프로젝트를보다 쉽게 ​​수행 할 수 있도록하기 위해 경험에서 수집 한 제안 및 제안입니다.

이 IMHO의 주요 측면은 경험 부분입니다. 이러한 모범 사례는 더 많은 경험을 가진 사람이 초보자와 공유 할 수있는 좋은 방법이지만, 이것이 모범 사례가 무엇인지 진정으로 이해하려면 최소한 최소한의 경험이 필요하다고 생각합니다. 그렇지 않으면 법의 규칙에 따라 맹목적으로 따를 수 있으며, 결국 다른 사람들이 당신을 위해 천천히 생각하게함으로써 학습 속도가 느려질 것입니다.

어쨌든, 나에게 소프트웨어 프로젝트에서 가장 중요한 일은 ... 글쎄 ... 완성하고, 배송 ... 짧게 작동시키는 것입니다!

그 시점 이전의 것은 증 기기, 상상력의 비유입니다. 일단 당신이 작동하는 무언가를 가지고 있다면 당신은 그것이 느리고, 유지하기 힘들고, 테스트하기 어려운지 등을 진정으로 평가할 수 있습니다. 그것을 작동시키는 과정은 아마도 그것을 다시 생각하도록 도울 모범 사례가있는 것들을 노출시킬 것입니다. 그 목표를 달성하기가 더 쉬운 방법으로

예, 먼저 아는 것부터 시작하고 어려운 일을주의하십시오. 벽에 부딪히면 물러서서 벽을보고 벽이 무엇인지 알아보십시오. 많은 경우에 당신은 당신이 문제의 근원이라는 것을 알게 될 것입니다. 해결하려는 문제의 일부에 대한 이해 부족, 보유하고있는 도구를 더 잘 활용할 수있는 방법에 대한 지식 부족 또는 항상 코 바로 아래에 있지만 준비가되지 않은 다른 도구에 대한 무지 그들의 숙달을 시작하십시오.

동시에 새로운 일을하는 방법에 대해 계속 읽으십시오. 이 모범 사례를 읽고 프로젝트에서 어려운 점에 적용되는지 확인하십시오. 그렇지 않은 경우, 그들의 존재를 기억하고 때때로 다시 방문하십시오. 궁금해. 시간이 지남에 따라 위에서 얻은 관찰은 여기에서 얻은 지식으로 자연스럽게 클릭하는 것을 볼 수 있습니다.

마지막으로 배운 내용을 실험하고 그것이 더 간단한 지 확인하십시오. 이것을 유지하고 결국 당신은 그들이 무엇인지에 대한 모범 사례를 읽을 것입니다. 어려움을 겪고 쉽게 배울 수있는 방법을 배운 사람들의 간단한 조언. 심지어 당신은 그들 중 일부에 동의하지 않을 수도 있고 당신의 방식이 실제로 당신에게 더 효과적이라는 것을 알 수 있습니다. 그러나 지식이 없으면 맹목적으로 걷는 것입니다.

행운을 빕니다

TL; DR

당신은 그것을 모두 알 수 없습니다. 당신이 알 수있는 모든 "사물"주위에는 항상 더 깊이와 폭이 있습니다. 가면서 배우십시오. 지금 적절하다고 생각되는 "모범 사례"를 적용하십시오 . 실수하다. 비용 이 많이 드는 실수 를 피하십시오 . 프로젝트가 비용이 많이 드는 실수로 이어질 수있는 경우 멘토를 찾으십시오.

그리고 지금 긴 대답은 ...

1. "작업 소프트웨어는 진행의 주요 척도입니다." ( 애자일 선언문 )

지식의 가장자리를 볼 수 있다면 정말 좋습니다! 가장자리를 추구하십시오! 계속 배우도록! 그러나 명심하십시오, 당신은 영원히 배우고 분석 할 수 있습니다 .

무언가를 만드십시오.

2. 배우고 실수하십시오. "나쁜"것을 만들지 마십시오. *

지식 / 기술의 한계를 뛰어 넘으십시오. 당신 은 실수를 할 것입니다. 그들에게서 배울 수 있습니다. 그러나 무모 할 필요는 없습니다 .

보다 숙련 된 개발자 및 멘토를 찾고 작업하는 데 소요되는 시간 은 프로젝트 의 비즈니스 가치 및 위험 프로파일 에 비례하여 증가해야합니다 .

직접 CLI 를 작성하는 경우 : 원하는대로 작동 시키십시오.

당신은 은행의 웹 포털을 작성하는 경우 : 서라운드 자신과 매우 숙련 된 개발자.

3. "모범 사례"는 따옴표로 작성하고 윙크로 말해야합니다.

"실습"은 X 가 적어도 일부 경우 에 성공한 것으로 관찰 될 때 "모범 사례"로 승격됩니다 . 누군가는 혜택 X 를 달성하기위한 실습 A 의 이점을 인식하고 이를 인터넷에서 "모범 사례"로 선언합니다. 다른 사람들은 종종 합당한 이유 때문에 동의합니다. 그러나 그 시점부터 우리는 일반적으로 일부 관행이 "우수 관행"이고 다른 관행이 "반 패턴" 또는 "고약한 " 이유를 파악하지 못합니다.

문제는 "모범 사례"가 결코 자립하지 않는다는 것입니다. "앤티 패턴"은 실제로 그 자체로는 악마적인 것이 아닙니다. 심지어 "스텐 치"조차 가끔 부패에서 나옵니다. 때로는 그 악취가 공상적이고 맛있는 치즈 일뿐입니다 ...

당신은 같은 것을 실행하지 않는다 "의존성 주입" "의존성 주입은"이기 때문에 (DI)를 본질적으로 비즈니스에 가치. 작동하는 제품을 제작하는 데 원격으로 필요한 것은 아닙니다. 그것은 수행 뭔가 는 것을 아마 원하는 최종 제품에 있습니다. 그러나 그것은 또한 이익을 위해 일을 더 오래 걸리게 할 수도 있습니다 ...

흠 ...

따라서 "모범 사례"를 따라야합니까? 당신이 그들을 이해하지 못하는 경우에도? ... 어 ... 네. 아니요 그러나 그렇습니다. 그러나 귀하와 귀하의 소프트웨어 및 그 목적에 실제로 적용되는 것만 해당됩니다.

POAP를 호출하십시오 ! ^{(예. 내 블로그)}

원칙, 패턴 및 관행은 최종 목적이 아닙니다.

그러므로 각각의 훌륭하고 적절한 적용은 우수하고보다 최종적인 목적에 의해 영감을 받고 제한됩니다. 왜하고있는 일을하고 있는지 이해해야합니다!

(POAP는 POAP에서 면제되지 않습니다.)

따라서 DI의 모든 뉘앙스를 완전히 이해하지 못할 수도 있습니다. 그러나 의도를 이해하면 DI를 "사용해야"하는지 알 수 있으며 DI를 암시 적으로 더 잘 이해할 수 있습니다.

그리고 제품을 출시하면 DI (또는 무엇이든)가 실제로 유익한 지 여부를 반영 할 수 있습니다. 그렇다면 서면으로 이유를 분명히하십시오. 그렇지 않은 경우 서면으로 이유를 분명히하십시오 ...

보너스 독서 / 다소 관련 :

분석 마비 는 일입니다. 분석하고 배워야합니다. 그러나 일을 끝내야합니다. 균형.

당신은 항상 카우보이 코더처럼 느낄 수 있습니다 .

^{* 당신은 실제로 할 것이다 당신은 아무것도에 주목을 할 경우 나쁜 실수를합니다. 하지만 당신은 인간입니다. 우리는 당신을 미리 용서합니다. 아마도. ... 글쎄 ... 우리는 볼 수 있습니다.}

내 질문은, 내가 아는 경로를 따라야하고 올바른 코딩 방법을 구현하려고합니까, 아니면 좋은 코딩 방법으로 시작하여 퍼지하려고 노력해야합니까?

어쩌면 최선을 다해도 여전히 무언가를 배송 할 수 있습니까? 사용자가 제품의 품질과 매력을 평가하는 방법과 제품의 개발자가 코드의 품질을 평가하는 방법 사이에는 두 가지 다른 힘이 있습니다. 이 두 힘을 최대한 조화롭게 만드십시오. 다른 하나를 희생하여 너무 많은 것에 집중하는 것은 일반적으로 가장 비생산적인 경로를 만드는 방법입니다.

글쎄, 우선, 좋은 코딩 관행을 채택하는 것이 번거롭지 않다는 것을 제안합니다 ... 트릭은 각 관행의 목적과 그것을 올바르게 구현하는 방법을 이해하는 것입니다.

짧은 시간 안에 많은 작업을 수행 할 수 있기 때문에 빠른 응용 프로그램 개발 환경은 매혹적입니다. Access에서 전체 회계 시스템을 한 번 구축했습니다. 그러나 당신은 스스로 그것을 말했다 : 당신은 다시 작성하지 않고 웹에 그런 응용 프로그램을 취할 수 없으며, 필요한 도구는 실제로 다릅니다.

더 이상 Access 나 Visual Basic과 같은 시각적 디자인 도구를 더 이상 사용하지 않는 이유가 있습니다. 그들은 실제로 무언가를 성취하는 코드로부터 당신을 격리시키는 경향이 있습니다. 액세스는 훌륭한 도구이지만 웹 응용 프로그램은 다음을 피하기 위해 특별히 설계되어야합니다. 설치 합니다. 외관의 커스터마이징이 어려울 수 있습니다. 웹에서 필요하지 않더라도 Access 응용 프로그램은 항상 다른 Access 응용 프로그램과 매우 유사합니다. 첫 번째 Access 응용 프로그램을 작성하는 대부분의 사람들은 좋은 응용 프로그램을 작성하기에 충분하지 않으며 Access를 사용하여 나쁜 응용 프로그램을 쉽게 작성할 수 있습니다.

이제 웹에서 응용 프로그램을 얻는 새로운 기술을 배우는 것에 사임했습니다. 처음부터 올바른 방법으로 구축해야합니까? 물론이야. 그러나 새로운 개발 환경과 철학을 배우는 것은 다른 것을 배우는 것과 같습니다. 일을 제대로하려면 잠시 동안 기울어 야합니다.

그래서 나는 당신이 잘못된 이분법을 제기했다고 생각합니다. 모든 "모범 사례"를 먼저 배우는 사람은 없습니다. 그들은 가면서 배웁니다. 그러나 모든 OOP 언어로 생산성을 높이려면 OOP를 알아야하거나 최소한 클래스가 어떻게 작동하는지 알아야합니다.

그만한 가치가 있기 때문에 PHP가 최선의 선택이라고 생각하지 않습니다. PHP는 "얕음"이기 때문에 매력적입니다. 즉, 작업 프로그램을 작성하기 위해 많은 것을 알 필요가 없습니다. 모범 사례는 대부분 개발자에게 맡겨져 있습니다. 즉, PHP가 "좋은"프로그램을 작성하는 데 도움이되지 않습니다. 이것은 나쁜 것은 아니지만 Access와 마찬가지로 더 강력한 플랫폼을 위해 PHP를 버릴 수도 있습니다.

적시에 적용 할 수있는 또 다른 패턴으로 OOP를 고려하십시오. OOP는 모든 작업을 체계적으로 해결할 수있는 프레임 워크가 아닙니다. 소프트웨어 엔지니어링에는 그러한 것이 없습니다.

또한 사람들이 좋은 관행 이라고 주장하는 것은 때때로 의문의 여지가 있습니다. 경험이 부족한 개발자가 주어진 문제에 필요하지 않은 매우 복잡한 프로그래밍 패턴을 채택하는 경우가 종종 있습니다. 코드의 복잡성은 문제의 복잡성에 적합해야합니다. 단순성은 중요한 가치입니다.

웹 기사, 업계 전문가의 진술 및 선임 동료의 조언은 잘못 될 수 있습니다. 나는 이것을 많이 보았다.

따라서 문제를 해결하는 가장 간단한 솔루션을 적용하는 것이 좋습니다. 아마도 이것은 귀하의 공간에서 인기있는 프레임 워크 중 하나의 사용법을 포괄합니다. 이 제약 조건 내에서 원하는 코드 종류를 자유롭게 선택할 수 있습니다. 그들의 행동 방식이 귀하의 사례에 적합 하다고 생각하지 마십시오 .

또한 특정 기술이 권장되는 이유를 이해하십시오 . 예를 들어, OOP는 캡슐화에 관한 것입니다. 다른 방법으로 캡슐화 할 수도 있습니다 (프로시 저도 캡슐화에 관한 것임).

부정적인 예 : 때때로 사람들은 데이터베이스를 추상화하기 위해 데이터 액세스 계층을 작성합니다. 여기서이 패턴의 본질은 구체적인 데이터 저장소와 독립적이되고 더 높은 코드 계층에 더 간단한 인터페이스를 제공하는 것입니다. 그러나 이러한 이점이 필요하지 않으면 데이터 액세스 계층이 필요하지 않으며 작업을 저장할 수 있습니다. 그러나 많은 전문가들은 항상 잘못된 추천인 DAL을 수행 할 것을 권장합니다.

좋은 코드는 종종 작업하기가 재미 있다는 것을 알았습니다. 인프라 문제가 아닌 실제 요구 사항을 다루기 때문에 재미 있습니다. 당신이하고있는 일이 너무 거친 작업임을 알게되면 잘못된 패턴 세트를 선택했을 것입니다.