강좌를 완료하고 YouTube에서 일련의 비디오를 보거나 iOS 개발에 관한 일련의 기사를 읽었으므로 이제 첫 번째 애완동물 프로젝트를 작성할 준비가 되었습니다.

첫째, 잘 했어요! 정말 대단해요. 당신은 멋지다! 💪

둘째, 애완동물 프로젝트는 당신의 기술을 엄청나게 향상시켜 줍니다. 지침을 따르지 않고 스스로 뭔가를 시작하면 엄청난 시간과 노력을 들여야 하고, Google을 많이 검색하고, 새로운 정보를 많이 읽고, 이를 필터링하여 상황에 정확하게 맞추려고 노력해야 합니다. 간단히 말해서, 그것은 이미 당신을 5배나 향상시켜 줄 실제 작업입니다.

그러나 대부분의 초보자는 주요 사항을 무시합니다(주도적으로가 아니라 중요성을 이해하지 못한 채). 지난 6개월 동안 저는 적극적으로 활동했습니다. 멘토링 애완 동물 프로젝트를 포함하여 신규 이민자의 질문과 문제를 돕습니다.

나는 초보자로서 당신이 필수 목록에 포함시키고, 숙달하고, 이해하고, 사용해야 하는 상위 3가지 사항을 확인했습니다.

액세스 수준

처음에는 private 수식어에 관심을 두는 사람이 거의 없습니다. 한편, 한밤중에 깨우면 누구나 즉시 SOLID에 대해 설명할 수 있습니다. 다양한 스마트 기사를 읽은 사람들은 S (단일 책임) 아이디어에 따라 여러 클래스를 만들려고 합니다.

그리고 깨끗한 양심을 가지고 class A 의 속성을 class B 에서 변경하고 그 반대의 경우도 마찬가지입니다.

 class A { var someAValue: Int? } class B { let a = A() func foo() { a.someAValue = 1 } }

일반적으로 여전히 명확하지 않은 경우 계획은 다음과 같습니다. 항상 모든 곳에 private 작성 하고 컴파일러가 불평할 때 외부에서 이 속성이나 함수에 액세스해도 괜찮은지 생각해 보세요. 만약 그렇다면 - private 제거하세요 .

생각할 때 실제 비교를 통해 스스로를 안내하십시오. 예를 들어 클래스가 상점인 경우 외부 고객이 goods 속성에 분명히 액세스할 수 있어야 합니다. 그러나 moneyInCashRegister 는 내부 매장 직원만 변경할 수 있습니다.

결국, 고객은 fetch 는 물론이고 put 사용해도 금전등록기에 접근할 수 없어야 합니다.

"나는 어떤 속성을 만질 수 있고 어떤 속성은 private 수정자 없이도 만질 수 없는지 완벽하게 이해합니다."라고 주장할 수도 있습니다. 그러나 액세스 수준 수정자를 작성하는 것은 설계의 일부입니다. 3층에 외부로 통하는 문이 있는 집에 대한 청사진은 만들지 않을 것이라고 확신합니다.

그런 다음 열지 마십시오. 결국, 다른 사람들도 귀하의 코드를 사용할 가능성이 높습니다.

그런데 var 및 let 에서도 비슷한 상황이 존재합니다. 다시 말하지만, 값이 변경될 것이라고 즉시 확신하지 않는 한 항상 let 사용하십시오.

아키텍처 단순성

나는 초보자들이 모든 것을 미리 계획하려고 하는 경향을 발견했습니다. 이는 칭찬할 만한 일이지만 개발자는 경험 부족으로 인해 실수를 저지르는 경우가 많습니다. 그들은 지나치게 복잡한 관리자를 미리 준비합니다(보통 다음에서 복사). 스택 오버플로 ) 많은 복잡한 방법을 사용하지만 결국에는 사용하지 않습니다. 결과적으로 코드의 양과 복잡성이 증가합니다.

편리하고 기성품처럼 보이는 서비스 대신 우리 프로그래머는 결국 문제와 오해만 남게 되었습니다. 건축도 마찬가지다.

내 요점을 전달하기 위해 프로그래밍의 역사를 간략하게 살펴보겠습니다. 1960년대 말에는 프로그래밍의 인기가 높아지면서 프로그램의 규모도 커졌다. 아시다시피, 프로그램 크기가 클수록 코드 줄이 많아지고 프로그램 이해가 더 복잡해지고 어려워집니다.

이 문제를 해결하기 위해 구조화된 프로그래밍, 즉 프로그램을 더 작고 관리 가능한 부분으로 나눌 수 있는 기능과 절차가 등장했습니다. 코드는 모듈화되고 재사용 가능하며 이해하기 쉬워졌습니다.

구조화의 출현으로 인해 프로그램의 규모와 복잡성 한계에 다시 도달할 때까지 프로그램이 더욱 성장했습니다. 따라서 1970년대 후반과 1980년대 초반에 이르러 객체 지향 프로그래밍 접근 방식이 형성되었습니다. 이 솔루션을 통해 유연하고 확장 가능한 시스템을 구축하여 점점 더 복잡해지는 작업을 처리할 수 있었습니다.

다음 10년 동안 우리는 컴퓨터 게임의 붐을 목격했습니다. 사용자 동작(클릭, 누르기)에 대한 반응이 중요한 것으로 밝혀져 이벤트 중심 프로그래밍이 등장하게 되었습니다.

그리고 웹 및 데스크톱 애플리케이션에서 코드를 구성하기 위해(동일한 데이터를 다른 관점에서 재배열해야 하는 경우) MVC 패턴(즉, 시각적 표현에서 모델을 분리)이 나타났습니다.

당신은 문제가 발생하면 -> 해결책이 나타난다는 주요 아이디어를 파악했습니다. 문제 -> 해결책.

그렇다면 이제 초보 프로그래머가 문제가 아직 발생하지 않은 시점에 솔루션(아키텍처)을 적용하기 시작하는 이유는 무엇입니까? 튜토리얼에서는 최소한 MVP를 선택하도록 즉시 제안합니다. 하나/두 개의 화면에 대한 테스트 작업에서는 항상 MVC를 사용하지 않도록 지정합니다.

인터뷰 중에 동일한 화면 1개 또는 2개를 사용하여 두 개의 애완동물 프로젝트를 작성한 사람에게 VIPER 문제에 대해 질문합니다. 아직 문제에 직면하지 않았다면 문제에 대해 어떻게 알 수 있습니까?

사람들은 아키텍처 측면에서 테스트 가능성의 편리성에 대해 자주 이야기하지만 테스트를 작성한 적은 없습니다. 그리고 만약 그렇다면 그것은 실제 애플리케이션에 연결하지 않고 단위 테스트에만 초점을 맞춘 일부 튜토리얼만을 기반으로 한 것입니다.

MVP 체계를 간단한 용어로 설명할 수 있지만 ViewInput 및 ViewOutput 과 같이 비슷한 이름을 가진 프로토콜에 관해서는 종종 혼란을 겪습니다. 깊은 곳에서는 이미 이 모든 것이 오버헤드로 간주됩니다 🙄🤯

결론: 스스로 문제를 일으키지 마십시오. MVC를 부끄러워하지 마세요. 컨트롤러가 너무 커지거나 불편을 겪게 되면 이제 새로운 접근 방식을 찾아야 할 때라는 것을 알게 될 것입니다.

UI 단순성

프론트 엔드 개발은 초보자를 위한 도파민 천국입니다. 코드를 작성하면 즉시 화면에 결과가 표시됩니다. 보상을 받을 수 있습니다 🍭. 그것은 틀림없이 동기를 부여합니다. 그러나 이 동전에는 이면이 있습니다. 초보자는 지나치게 복잡한 UI를 당장 만들려고 애쓰는 경우가 많습니다.

게다가 복잡한 기능은 복잡한 UI를 따르는 경향이 있습니다. 오늘날 SwiftUI가 작업을 단순화하더라도 실제 진전 없이 추가 기능을 추가하는 데 많은 시간을 소비할 수 있습니다.

저는 팀을 구성하고 하나의 프로젝트를 진행하는 과정에서 iOS 개발을 배웠습니다. 우리 팀에서 한 남자가 다크 모드에 대한 글꼴과 색상을 선택하여 앱 개발을 시작하자고 제안했습니다.

전반적으로 그는 전체 과정을 그것에 투자했으며 글꼴과 색상이 훌륭하다는 점은 주목할 가치가 있습니다. 그러나 그 사람은 그 동안 실제 코드를 거의 0줄도 작성하지 않았습니다.

의심할 여지 없이 애플리케이션의 아름다움과 기능이 매우 중요합니다. 결국 이 측면에 시간을 투자해야 할 것입니다. 좀 더 간단한 것부터 시작하는 것이 좋습니다. MVP(최소 실행 가능 제품)를 개발하고 가장 중요한 기능에 중점을 두고 거기에서 시작하세요.

그만큼 80-20 규칙 여기에 적용됩니다. 애플리케이션의 기초를 만든 다음 추가 사항을 추가합니다. 반대의 접근 방식은 복잡한 뉘앙스와 씨름하고 계속 중단되는 주요 기능을 지속적으로 처리하게 됩니다.

모바일 개발을 처음 시작하는 사람에게는 복잡한 솔루션을 조기에 채택할 위험이 있습니다. 프런트 엔드 개발의 시각적 보상은 매력적일 수 있지만 간단한 MVP로 시작하는 것이 더 현명한 경우가 많습니다.

역사적 추세에 따르면 솔루션은 진정한 문제에 대응하여 발전해야 합니다.

기본 원칙을 이해하고 실제 문제가 발생할 때 이를 해결하는 것은 효과적인 개발에 매우 중요합니다.

여기에도 게시됨