프레임워크 없이 프로그레시브 웹 애플리케이션 설계 및 구축(3부)

이 시리즈의 첫 번째 파트로 돌아가서 우리는 이 프로젝트가 시작된 이유를 설명했습니다. 즉, 바닐라 JavaScript로 작은 웹 응용 프로그램을 만드는 방법을 배우고 디자인을 하지 않는 개발자가 자신의 디자인 작업을 하게 하려는 열망이 약간 있습니다.

2부에서 우리는 몇 가지 기본적인 초기 디자인을 취하고 몇 가지 도구와 기술을 선택하여 작업을 시작했습니다. 우리는 디자인의 일부가 변경된 방법과 이유와 이러한 변경의 결과에 대해 다루었습니다.

이 마지막 부분에서는 간단한 웹 애플리케이션을 In/Out으로 만들면서 배운 가장 가치 있는 교훈을 살펴보기 전에 기본 웹 애플리케이션을 PWA(프로그레시브 웹 애플리케이션)로 전환하고 애플리케이션을 '배송'하는 방법을 다룰 것입니다.

• JavaScript 배열 메소드의 엄청난 가치;
• 디버깅;
• 귀하가 유일한 개발자일 때 귀하는 다른 개발자입니다.
• 디자인 은 개발입니다.
• 지속적인 유지 관리 및 보안 문제
• 정신, 동기 또는 둘 다를 잃지 않고 사이드 프로젝트 작업
• 일부 제품 배송은 제품 없음 배송보다 낫습니다.

따라서 배운 내용을 살펴보기 전에 HTML, CSS 및 JavaScript로 작성된 기본 웹 응용 프로그램을 PWA(프로그레시브 웹 응용 프로그램)로 변환하는 방법을 살펴보겠습니다.

이 작은 웹 응용 프로그램을 만드는 데 소요된 총 시간의 관점에서 볼 때 약 2주에서 3주 정도 소요될 것으로 예상합니다. 그러나 저녁에 30-60분 단위로 진행되었기 때문에 실제로 첫 번째 커밋부터 2018년 8월에 '1.0' 버전이라고 생각되는 것을 업로드할 때까지 약 1년이 걸렸습니다. 기능 완성', 간단히 말해서 만족스러운 단계에서 큰 최종 푸시를 예상했습니다. 알다시피, 나는 응용 프로그램을 프로그레시브 웹 응용 프로그램으로 만드는 데 아무 일도 하지 않았습니다. 결과적으로 이것은 전체 프로세스 중 실제로 가장 쉬운 부분이었습니다.

프로그레시브 웹 애플리케이션 만들기

좋은 소식은 작은 JavaScript 기반 앱을 '프로그레시브 웹 앱'으로 전환할 때 삶을 쉽게 만들어주는 도구가 많다는 것입니다. 이 시리즈의 1부로 돌아가 생각한다면 프로그레시브 웹 앱이 된다는 것은 일련의 기준을 충족한다는 것을 의미한다는 것을 기억할 것입니다.

웹 애플리케이션이 어떻게 측정되는지 파악하려면 가장 먼저 Google Chrome의 Lighthouse 도구를 방문해야 합니다. '감사' 탭에서 Progressive Web App 감사를 찾을 수 있습니다.

이것은 내가 처음으로 In/Out을 실행했을 때 Lighthouse가 나에게 말한 것입니다.

초기에 In/Out은 Progressive Web App에 대해 ⁵⁵ ⁄ ₁₀₀ 점에 불과했습니다. 그러나 나는 거기에서 ¹⁰⁰ ⁄ ₁₀₀ 까지 한 시간도 채 걸리지 않았습니다!

그 점수를 향상시키는 편의는 내 능력과 거의 관련이 없었습니다. Lighthouse가 수행해야 할 작업을 정확히 알려 주었기 때문입니다!

필수 단계의 몇 가지 예: manifest.json 파일(기본적으로 앱에 대한 메타데이터를 제공하는 JSON 파일) 포함, 헤드에 수많은 메타 태그 추가, 표준 URL 참조 이미지에 대해 CSS에 인라인된 이미지 전환, 홈 화면 이미지를 추가합니다.

많은 홈 화면 이미지를 만들고 매니페스트 파일을 만들고 많은 메타 태그를 추가하는 것은 1시간 이내에 많은 일을 하는 것처럼 보일 수 있지만 웹 응용 프로그램을 빌드하는 데 도움이 되는 멋진 웹 응용 프로그램이 있습니다. 얼마나 좋은데요! https://app-manifest.firebaseapp.com을 사용했습니다. 응용 프로그램과 로고에 대한 데이터를 제공하고 제출을 누르면 필요한 모든 것이 포함된 zip 파일이 제공됩니다! 그 다음부터는 복사해서 붙여넣기만 하면 됩니다.

서비스 워커와 같은 지식 부족으로 한동안 미루던 것들도 https://serviceworke.rs와 같은 서비스 워커 전용 사이트와 수많은 블로그 게시물 덕분에 상당히 쉽게 추가되었습니다. 서비스 워커가 있다는 것은 프로그레시브 웹 애플리케이션의 필수 기능인 앱이 오프라인에서 작동할 수 있다는 것을 의미했습니다.

애플리케이션을 PWA로 만드는 것과 엄격하게 관련이 있는 것은 아니지만 Chrome Dev Tools의 'coverage' 탭도 매우 유용했습니다. 몇 달에 걸쳐 디자인과 코드를 산발적으로 반복한 후에 중복 코드가 있는 위치를 명확하게 표시하는 것이 유용했습니다. 나는 단순히 잊어 버린 코드베이스를 어지럽히는 몇 가지 오래된 함수를 발견했습니다!

간단히 말해서 Lighthouse 감사 권장 사항을 검토한 결과 저는 선생님의 애완동물처럼 느껴졌습니다.

현실은 응용 프로그램을 가져 와서 프로그레시브 웹 응용 프로그램으로 만드는 것이 실제로 매우 간단하다는 것입니다.

마지막 개발 작업을 마치면서 웹사이트의 하위 도메인에 작은 응용 프로그램을 업로드했습니다.

회고

내 작은 웹 응용 프로그램을 개발한 지 몇 달이 지났습니다.

나는 그 이후 몇 달 동안 응용 프로그램을 아무렇지도 않게 사용했습니다. 현실은 내가 하는 팀 스포츠 조직의 대부분이 여전히 문자 메시지를 통해 발생한다는 것입니다. 그러나 응용 프로그램은 매일 밤 종이 조각을 찾는 것보다 누가 들어오고 나가는지 기록하는 것보다 확실히 쉽습니다.

따라서 거의 필수 서비스가 아닌 것은 사실입니다. 또한 개발이나 디자인에 대한 기준을 설정하지도 않습니다. 저도 100% 만족한다고 말씀드릴 수는 없습니다. 그냥 포기할 수 있는 지경에 이르렀습니다.

그러나 그것은 결코 운동의 요점이 아니었다. 나는 경험에서 많은 것을 얻었다. 다음은 제가 가장 중요하게 생각하는 사항입니다.

디자인 은 개발이다

처음에는 디자인에 가치를 두지 않았습니다. 나는 패드와 펜으로 스케치하거나 스케치 응용 프로그램에서 보낸 시간이 코딩에 더 잘 보낼 수 있는 시간이라고 믿고 이 프로젝트를 시작했습니다. 그러나 곧바로 코드를 작성했을 때 나는 종종 바쁜 바보였습니다. 가능한 가장 낮은 정확도로 먼저 개념을 탐색하면 장기적으로 훨씬 더 많은 시간을 절약할 수 있습니다.

처음에는 사용자 경험 관점에서 근본적으로 결함이 있다는 것을 깨닫기 위해 코드에서 작업하는 데 몇 시간을 소비한 경우가 많았습니다.

지금 제 의견은 종이와 연필이 최고의 계획, 디자인 및 코딩 도구라는 것입니다. 직면한 모든 중대한 문제는 주로 종이와 연필로 해결되었습니다. 텍스트 편집기는 솔루션을 실행하는 수단일 뿐입니다. 종이에 의미가 없는 것은 코드로 작업할 가능성이 없습니다.

그 다음으로 감사하게 된 것은 디자인이 반복적이라는 사실을 이해하는 데 왜 그렇게 오랜 시간이 걸렸는지 모르겠습니다. 나는 무의식적으로 대문자 "D"를 가진 디자이너의 신화를 샀습니다. 누군가가 주변을 어슬렁거리며 샤프펜슬을 직선 가장자리로 들고 서정적으로 서정적이며 평평한 흰색(두유와 함께)을 홀짝이며 자연스럽게 완전한 형태의 시각적 완성도를 세상에 탄생시켰습니다.

이것은 '천재' 프로그래머의 개념과 달리 신화입니다. 디자인이 처음이지만 직접 시도해 보는 경우 흥분을 불러일으키는 첫 번째 아이디어에 얽매이지 않는 것이 좋습니다. 변형을 시도하는 것은 너무 저렴하므로 그 가능성을 수용하십시오. 내가 In/Out 디자인에 대해 좋아하는 것은 첫 번째 디자인에 없었습니다.

나는 "책은 쓰여지는 것이 아니라 다시 쓰여지는 것이다"라는 격언을 만든 소설가 마이클 크라이튼(Michael Crichton)이라고 생각합니다. 모든 창작 과정이 본질적으로 동일하다는 사실을 인정하십시오. 프로세스를 신뢰하면 불안이 줄어들고 연습은 미적 이해와 판단을 개선할 것입니다.

당신은 프로젝트의 다른 개발자입니다

이것이 산발적으로만 수행되는 프로젝트에만 해당되는지 확실하지 않지만 다음과 같은 무모한 가정을 했습니다.

"나만 기록하기 때문에 문서화할 필요가 없으며 내가 썼기 때문에 분명히 이해할 것입니다."

진실에서 멀어질 수는 없습니다!

30분 동안 프로젝트 작업을 해야 하는 저녁이 있었는데, 6개월 전에 작성한 함수를 이해하려고 노력하는 것 외에는 아무것도 하지 않았습니다. 코드 재지정이 그렇게 오래 걸리는 주된 이유는 품질 주석이 부족하고 이름이 잘못 지정된 변수 및 함수 인수 때문입니다.

저는 일상 업무에서 코드 주석 처리에 매우 부지런하며, 다른 사람이 제가 작성하는 내용을 이해해야 할 수도 있다는 점을 항상 염두에 두고 있습니다. 그러나 이 경우 나는 다른 사람이었다. 6개월 동안 작성한 코드 블록이 어떻게 작동하는지 정말로 기억할 것이라고 생각하십니까? 당신은하지 않습니다. 이것에 대해 저를 믿으십시오. 시간을내어 그 일에 대해 의견을 말하십시오!

그 이후로 귀하의 구문 형광펜이 주석의 중요성에 대해 잘못되었다는 블로그 게시물을 읽었습니다. 기본 전제는 구문 형광펜이 주석을 사라지게 해서는 안 되며 가장 중요한 것이어야 한다는 것입니다. 나는 동의하는 경향이 있으며 가려움을 긁는 코드 편집기 테마를 곧 찾지 못하면 그 목적에 맞게 조정해야 할 수도 있습니다!

디버깅

버그를 발견하고 모든 코드를 작성했을 때 키보드와 의자 사이에서 오류가 발생했을 가능성이 높다고 말하는 것은 불공평하지 않습니다. 그러나 그렇게 가정하기 전에 가장 기본적인 가정도 테스트해 볼 것을 제안합니다. 예를 들어, 내 코드로 인한 문제라고 생각했던 문제를 해결하는 데 2시간 넘게 걸렸던 기억이 납니다. iOS에서는 텍스트 입력을 허용하는 입력 상자를 얻을 수 없었습니다. 왜 그것이 전에 나를 막지 않았는지 기억나지 않지만 그 문제에 대한 나의 좌절은 기억합니다.

아직 수정되지 않은 Safari의 버그로 인한 것으로 밝혀졌습니다. 다음과 같은 경우 Safari에서 알 수 있습니다.

 * { user-select: none; }

스타일 시트에서 입력 상자는 입력을 받지 않습니다. 다음을 사용하여 이 문제를 해결할 수 있습니다.

 * { user-select: none; } input[type] { user-select: text; }

이것이 내가 "앱 재설정" CSS 재설정에서 취하는 접근 방식입니다. 그러나 이것의 정말 실망스러운 부분은 이미 이것을 배웠고 나중에 잊어 버렸다는 것입니다. 문제를 해결하는 동안 마침내 WebKit 버그 추적을 확인하기 시작했을 때 버그 보고서 스레드에 해결 방법을 작성한 지 1년이 넘었습니다.

데이터로 구축하고 싶으신가요? JavaScript 배열 방법 배우기

아마도 이 앱 빌드 연습을 통해 JavaScript 기술이 얻은 가장 큰 발전은 JavaScript Array 메서드에 익숙해진 것입니다. 이제 모든 반복 및 데이터 조작 요구 사항에 대해 매일 사용합니다. map() , filter() , every() , findIndex() , find() 및 reduce() ) 와 같은 메소드가 얼마나 유용한지 아무리 강조해도 지나치지 않습니다. 거의 모든 데이터 문제를 해결할 수 있습니다. 무기고에 아직 없다면 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array를 북마크에 추가하고 가능한 한 빨리 파헤쳐 보십시오. 내가 선호하는 배열 방법에 대한 설명이 여기에 문서화되어 있습니다.

ES6은 Set , Rest 및 Spread 와 같은 배열 조작을 위한 다른 시간 절약 기능을 도입했습니다. 제가 한 가지 예를 나누는 동안 저를 기쁘게 해주십시오. 단순한 평면 배열에서도 중복을 제거하려는 경우 많은 양의 실수가 있었습니다. 더 이상은 아닙니다.

"Mr Pink"라는 중복 항목이 있는 배열의 간단한 예를 살펴보겠습니다.

 let myArray = [ "Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue", "Mr Pink" ];

ES6 JavaScript로 중복을 제거하려면 이제 다음을 수행하면 됩니다.

 let deDuped = [...new Set(myArray)]; // deDuped logs ["Mr Orange", "Mr Pink", "Mr Brown", "Mr White", "Mr Blue"]

솔루션을 수동으로 롤링하거나 라이브러리에 도달해야 하는 작업이 이제는 언어에 적용되었습니다. 분명히, 그렇게 큰 문제처럼 들리지 않을 수 있는 짧은 배열과 같은 경우 수백 개의 항목과 중복 항목이 있는 배열을 볼 때 얼마나 많은 시간이 절약되는지 상상해 보십시오.

유지 관리 및 보안

NPM을 사용하여 빌드하는 모든 것은 빌드 도구를 위한 것일지라도 보안 문제에 취약할 가능성이 있습니다. GitHub는 잠재적인 문제를 잘 알 수 있도록 해주지만 여전히 유지 관리에 대한 부담이 있습니다.

단순한 부수적인 프로젝트의 경우, 이것은 적극적인 개발을 따르는 몇 달과 몇 년 동안 약간의 고통이 될 수 있습니다.

현실은 보안 문제를 해결하기 위해 종속성을 업데이트할 때마다 빌드가 중단될 가능성이 있다는 것입니다.

몇 달 동안 내 package.json 은 다음과 같았습니다.

 { "dependencies": { "gulp": "^3.9.1", "postcss": "^6.0.22", "postcss-assets": "^5.0.0" }, "name": "In Out", "version": "1.0.0", "description": "simple utility to see who's in and who's out", "main": "index.js", "author": "Ben Frain", "license": "MIT", "devDependencies": { "autoprefixer": "^8.5.1", "browser-sync": "^2.24.6", "cssnano": "^4.0.4", "del": "^3.0.0", "gulp-htmlmin": "^4.0.0", "gulp-postcss": "^7.0.1", "gulp-sourcemaps": "^2.6.4", "gulp-typescript": "^4.0.2", "gulp-uglify": "^3.0.1", "postcss-color-function": "^4.0.1", "postcss-import": "^11.1.0", "postcss-mixins": "^6.2.0", "postcss-nested": "^3.0.0", "postcss-simple-vars": "^4.1.0", "typescript": "^2.8.3" } }

그리고 2019년 6월까지 GitHub에서 다음과 같은 경고를 받았습니다.

내가 직접 사용하는 플러그인과 관련된 것은 없었고, 모두 내가 사용한 빌드 도구의 하위 종속성이었습니다. 이것이 JavaScript 패키지의 양날의 검입니다. 앱 자체에서는 In/Out에 문제가 없었습니다. 프로젝트 종속성을 사용하지 않았습니다. 그러나 코드가 GitHub에 있었기 때문에 문제를 해결하고 수정해야 한다는 의무감을 느꼈습니다.

package.json에 대한 몇 가지 선택 사항을 변경하여 수동으로 패키지를 업데이트할 수 있습니다. 그러나 Yarn과 NPM에는 모두 자체 업데이트 명령이 있습니다. 터미널에서 업데이트할 수 있는 간단한 수단을 제공하는 yarn upgrade-interactive 를 실행하기로 했습니다.

아주 쉬워 보이지만 어떤 업데이트가 가장 중요한지 알려주는 작은 색상의 키도 있습니다.

--latest 플래그를 추가하여 최신 패치 버전이 아니라 종속성의 가장 최신 주요 버전으로 업데이트할 수 있습니다. 한 푼에…

문제는 JavaScript 패키지 세계에서 상황이 빠르게 움직이기 때문에 몇 가지 패키지를 최신 버전으로 업데이트한 다음 빌드를 시도하면 다음과 같은 결과가 발생한다는 것입니다.

그래서 저는 package.json 파일을 롤백하고 --latest 플래그 없이 이번에 다시 시도했습니다. 그것은 내 보안 문제를 해결했습니다. 내가 정직하게 말하지만 월요일 저녁에 내가 가진 가장 재미있는 것은 아닙니다.

이는 모든 측면 프로젝트의 중요한 부분에 영향을 미칩니다. 당신의 기대에 현실적이 되는 것.

사이드 프로젝트

당신이 같은지 모르겠지만 나는 현기증이 나는 낙관주의와 흥분이 내가 프로젝트를 시작하게 만들고, 어떤 것이든 된다면 당혹감과 죄책감이 나를 끝내게 만든다는 것을 발견했습니다.

여가 시간에 이 작은 응용 프로그램을 만든 경험이 재미있었다고 하면 거짓말일 것입니다. 누구에게도 그 일에 대해 입을 열지 않았으면 하는 경우가 있었습니다. 하지만 이제 완료되었습니다. 시간을 투자할 가치가 있었다고 100% 확신합니다.

즉, 직면한 문제를 이해하고 해결하는 데 시간이 얼마나 걸릴지에 대해 현실적임으로써 이러한 사이드 프로젝트에 대한 좌절감을 완화할 수 있습니다. 1주일에 몇 번 밤에 30분만 시간을 가집니까? 여전히 사이드 프로젝트를 완료할 수 있습니다. 속도가 느려진다고 해서 불만을 품지 마십시오. 상황이 당신의 완전한 주의를 즐길 수 없다면 아마도 당신이 익숙했던 것보다 더 느리고 꾸준한 속도로 준비하십시오. 코딩이든, 과정을 마치든, 저글링을 배우든, 작은 웹 애플리케이션을 작성하는 데 왜 그렇게 오랜 시간이 걸렸는지에 대한 일련의 기사를 작성하는 것은 사실입니다!

간단한 목표 설정

목표 설정을 위해 화려한 과정이 필요하지 않습니다. 그러나 작거나 짧은 작업을 분류하는 데 도움이 될 수 있습니다. '드롭다운 메뉴용 CSS 작성'과 같은 간단한 작업은 제한된 시간 내에 완벽하게 달성할 수 있습니다. 반면 '상태 관리를 위한 디자인 패턴 연구 및 구현'은 그렇지 않을 것입니다. 물건을 분해하십시오. 그런 다음 레고처럼 작은 조각들이 서로 연결됩니다.

이 프로세스를 더 큰 문제를 해결하는 것으로 생각하면 유명한 Bill Gates의 인용문이 생각납니다.

"대부분의 사람들은 1년 동안 할 수 있는 것은 과대평가하고 10년 동안 할 수 있는 것은 과소평가합니다."

이것은 소아마비 퇴치를 돕는 사람에게서 온 것입니다. Bill은 그의 물건을 알고 있습니다. 빌의 말을 들어라.

아무것도 배송하지 않는 것보다 무언가를 배송하는 것이 좋습니다.

이 웹 애플리케이션을 '배송'하기 전에 코드를 검토했고 완전히 낙담했습니다.

나는 완전히 순진하고 경험이 없다는 점에서 이 여정을 시작했지만 코드를 설계하는 방법에 관해서는 괜찮은 선택을 했습니다. 나는 디자인 패턴을 연구하고 구현했으며 패턴이 제공하는 모든 것을 즐겼습니다. 애석하게도 프로젝트를 끝내고자 하는 마음이 더욱 간절해지면서 규율을 지키지 못했습니다. 코드가 있는 그대로의 접근 방식은 실제로 뒤죽박죽이며 비효율성이 만연합니다.

그 후 몇 달 동안 나는 그러한 결점이 별로 중요하지 않다는 것을 깨닫게 되었습니다. 설마.

저는 Helmuth von Moltke의 이 인용문을 좋아합니다.

"어떤 작전 계획도 주요 적대 세력과의 첫 번째 접촉 이후로 확실하게 확장되지 않습니다."

그것은 다음과 같이 의역되었습니다.

"적과의 첫 접촉에서 살아남는 계획은 없습니다."

아마도 우리는 그것을 더 요약하고 단순히 "젠장"으로 갈 수 있습니까?

다음 유추를 통해 배송된 내용에 대해 동의하게 되었다고 추측할 수 있습니다.

친구가 첫 마라톤에 도전하겠다고 발표했다면 결승선을 통과하는 것이 가장 중요할 것입니다. 나는 그들의 완주 시간에 대해 질책하지 않을 것입니다.

나는 최고의 웹 응용 프로그램을 작성하기 시작하지 않았습니다. 내가 정한 임무는 단순히 디자인하고 만드는 것이었습니다.

좀 더 구체적으로 말하자면, 저는 개발 관점에서 웹 애플리케이션이 어떻게 구성되었는지에 대한 기초를 배우고 싶었습니다. 디자인의 관점에서, 나는 (간단하지만) 디자인 문제를 스스로 해결해 보고 싶었습니다. 이 작은 응용 프로그램을 만드는 것은 이러한 도전과제를 해결한 후 몇 가지를 해결했습니다. 전체 애플리케이션의 JavaScript는 5KB(gzipped)에 불과했습니다. 어떤 프레임워크로도 접근하기 힘든 작은 파일 크기. 아마도 Svelte를 제외하고.

이러한 성격의 도전 과제를 설정하고 어떤 시점에서 무언가를 '출시'할 것으로 예상하는 경우 처음에 그 일을 하는 이유를 적으십시오. 그 이유들을 마음의 최전선에 두고 그것들에 따라 행동하십시오. 모든 것은 궁극적으로 일종의 타협입니다. 고상한 이상 때문에 계획한 일을 끝내지 못하게 하지 마십시오.

요약

전반적으로 인/아웃 작업을 한 지 1년이 다 되어가는 지금, 제 느낌은 크게 세 가지로 나뉩니다. 아쉬운 점, 개선하고 싶은 점, 그리고 앞으로의 가능성입니다.

후회했던 일들

이미 언급했듯이, 나는 애플리케이션의 상태를 변경하고 DOM에 렌더링하는 더 우아한 방법이라고 생각했던 것에 집착하지 않아 실망했습니다. 이 시리즈의 두 번째 부분에서 논의한 것처럼 예측 가능한 방식으로 많은 문제를 해결한 관찰자 패턴은 프로젝트 '배송'이 우선 순위가 되면서 결국 폐기되었습니다.

처음에는 내 코드가 창피했지만 다음 몇 달 동안 더 철학적으로 성장했습니다. 나중에 보행자 기술을 더 많이 사용하지 않았다면 프로젝트가 결코 끝나지 않았을 가능성이 매우 높습니다. 개선이 필요한 것을 세상에 내보내는 것이 세상에 태어나지 않은 것보다 여전히 기분이 좋습니다.

인/아웃 개선

시맨틱 마크업을 선택하는 것 외에는 접근성에 대한 어포던스를 만들지 않았습니다. In/Out을 구축할 때 나는 표준 웹 페이지 접근성에 확신이 있었지만 응용 프로그램을 다룰 만큼 지식이 부족했습니다. 저는 지금 그 분야에서 훨씬 더 많은 작업/연구를 수행했으므로 이 응용 프로그램을 더 쉽게 액세스할 수 있도록 하는 데 시간을 할애하는 것을 즐깁니다.

'사람 추가' 기능의 수정된 디자인 구현이 서두르고 있습니다. 재앙이 아니라 내가 원하는 것보다 조금 더 거칠다. 그것을 더 매끄럽게 만드는 것이 좋을 것입니다.

큰 화면도 고려하지 않았습니다. 단순히 콘텐츠 튜브를 만드는 것 이상으로 더 큰 크기로 작동하도록 하는 디자인 문제를 고려하는 것은 흥미로울 것입니다.

가능성

localStorage를 사용하면 제 단순한 요구 사항에 적합했지만 '적절한' 데이터 저장소가 있으면 데이터 백업에 대해 걱정할 필요가 없었습니다. 로그인 기능을 추가하면 게임 조직을 다른 개인과 공유할 수 있는 가능성도 열립니다. 아니면 모든 플레이어가 자신이 플레이하고 있는지 여부를 표시할 수 있습니까? 이렇게 단순하고 겸손한 시작에서 얼마나 많은 길을 탐색할 수 있는지 상상할 수 있다는 것이 놀랍습니다.

iOS 앱 개발을 위한 SwiftUI도 흥미롭습니다. 웹 언어로만 작업해 본 경험이 있는 사람에게는 언뜻 보기에 SwiftUI가 이제 과감하게 시도해볼 수 있는 것처럼 보입니다. 개발 경험과 결과를 빌드하고 비교하기 위해 특정 항목을 만들기 위해 SwiftUI로 In/Out을 다시 빌드하려고 할 것입니다.

이제 모든 것을 마무리하고 이 모든 것의 TL;DR 버전을 제공할 시간입니다.

웹에서 어떻게 작동하는지 배우고 싶다면 추상화를 건너뛰는 것이 좋습니다. CSS든 JavaScript든 프레임워크가 무엇인지 정말로 이해할 때까지 프레임워크를 버리십시오.

디자인은 반복적이므로 그 프로세스를 수용하십시오.

원하는 대로 가장 충실도가 낮은 매체로 문제를 해결하십시오. Sketch에서 아이디어를 테스트할 수 있다면 코드로 이동하지 마세요. 펜과 종이를 사용할 수 있다면 스케치로 그리지 마십시오. 먼저 논리를 작성하십시오. 그런 다음 코드로 작성하십시오.

현실적이되 절대 낙심하지 마십시오. 하루에 30분 정도만 무언가를 하는 습관을 들이면 결과를 얻을 수 있습니다. 그 사실은 당신의 탐구가 어떤 형태를 취하든 사실입니다.