意識通りに長くて汚い私のコード
もう二度とだめだ.今止まれ!

언제나 첫 시작은 위대했다. 
30분도 지나지 않아 
손가락이 타이핑 하기를 망설이게 되더라. 

수십번의 삽질 끝에 사이드 플젝이 끝나면 
항상 만족감 보다는 좌절감이 컸다.
이유는 "코드가 길고 더러워서".

아무도 못 알아보는 내 코드(나도 못 알아봄) 
좀 고쳐보려 책과 레퍼런스를 뒤적뒤적.
그렇게 프로그래밍 아키텍쳐를 찾아보게 되었는데.

(웹 개발에서 가장 많이 사용되는 MVC를 기준으로 중점적으로 작성하였습니다) 

MVC

Webベースで最も一般的なアーキテクチャです.
正式に発表された最初のパターン.

MVCモデルを作成する理由の1つは、ビジネスロジックとプレゼンテーションロジックを区別して、元のデータへの汚染を最小限に抑えることです.javascript自体は制御しにくい言語であるため、アーキテクチャの使用が切実である.
最近では多様なerrorやsynthetic sugar(async await, class)などの利点に加えて,Webベースの作成に必要な要素とされている.

아키텍쳐의 목적은 코드 정리와 가독성 보다, 
프로그램의 확장, 유지, 보수에 있다고 해도 과언이 아니다.

코드를 MODEL - VIEW - CONTROLLER로 분류한다.

MODEL 에는 필요한 DATA 및 자료들을 (비즈니스 로직)
VIEW 에는 웹의 외형 변화 및 사용자 관점의 환경을 (프레젠테이션 로직)
CONTROLLER는 따로 분류된 위의 두개의 영역 코드들을 조정한다. (어플리케이션 로직)

MODEL

プログラムを実行するために必要なすべてのデータはここで分類されます.
データベースまたはtypescriptまたはapiから得られたデータプロトタイプもここに格納される.
通常、格納データlibraryプロセスを経て、stateに戻ります.
MVCコード分類で最も注意すべき部分はcontrollerとmodelの「関連性」である.viewはmodelに接触してはならない.viewもviewのデータに直接依存することはできません.
しかし、2人は現場での依存性が高い.
100%完璧な区分でコードを生成することは難しい.
この点については,理論的には正式な報告はない.
各開発環境とプロジェクトチームには必ずわずかな違いがあります.
これらの欠点を補うために,modelやMVCなどのアーキテクチャが生まれた.

VIEW

MVPのデータが読めなかったり、資料が見つからなかったりしてMVVMが発生したからといって、返された結果をそのままユーザに提示することはできない.△一般的には理解できないが、modelを作るのは意味がない.error管理は、レイアウト変更配置や例外処理などのプレゼンテーションロジックを提供する.
ユーザは、ディスプレイに表示された結果を表示し、ユーザが望むジェスチャーを行うのを助けることができる.
最終的にはviewに直接影響を及ぼす区間であるため、viewの基礎製作に際してelementについて具体的な理解が必要である.

controller

これは、viewおよびD.O.Mの中間ブリッジであり、ユーザのニーズに応じてmodelからデータを取得するか、またはviewのmodelに基づいてデータを生成および格納する.
これは,プログラム実行において本質的に必要な関数呼び出しを実現する区間である.viewおよびmodel基底関数については、「実行」のみが関連する.
これをアプリケーションロジックと呼びます.