jQuery가 다른 Javascript 프레임 워크에 비해 채택되는 이유는 무엇입니까?
저는 프로그래머 그룹을 관리합니다. 저는 직원들의 의견을 소중하게 생각하지만 최근에는 웹 프로젝트에서 사용할 수 있습니다.
개인적으로 MooTools를 선호 하지만 일부 팀은 jQuery 가 더 많이 채택되기 때문에 jQuery 로 계획하고 싶어하는 것 . 충분하지 않습니다.
jQuery 와 MooTools를 모두 사용했습니다. 이 특별한 에세이 는 두 프레임 워크에서 내가 어떻게 느끼는지 반영하는 경향이 있습니다. jQuery 는 DOM 조작에 적합하지만이를 지원하는 데 제한이있는 것입니다.
기능면에서 jQuery 와 MooTools 모두 쉬운 DOM 선택 및 조작을 허용합니다 .
// jQuery
$('#someContainer div[class~=dialog]')
.css('border', '2px solid red')
.addClass('critical');
// MooTools
$('#someContainer div[class~=dialog]')
.setStyle('border', '2px solid red')
.addClass('critical');
jQuery 와 MooTools 모두쉬운 AJAX를 허용합니다.
// jQuery
$('#someContainer div[class~=dialog]')
.load('/DialogContent.html');
// MooTools (Using shorthand notation, you can also use Request.HTML)
$('#someContainer div[class~=dialog]')
.load('/DialogContent.html');
jQuery 와 MooTools 모두쉬운 DOM 애니메이션을 허용합니다.
// jQuery
$('#someContainer div[class~=dialog]')
.animate({opacity: 1}, 500);
// MooTools (Using shorthand notation, you can also use Fx.Tween).
$('#someContainer div[class~=dialog]')
.set('tween', {duration: 500})
.tween('opacity', 1);
jQuery 는 다음과 같은 추가 기능을 제공합니다.
- 지지자 커뮤니티
- 플러그인 저장소
- Microsoft의 ASP.NET 및 VisualStudio와 통합
- Microsoft, Google 및 기타에서 사용
MooTools 는 다음과 같은 추가 기능을 제공합니다.
- JS 용 클래식 OOP 에뮬레이션이 포함 된 객체 지향 프레임 워크
- 확장 된 외장 개체
- 기본 기능 지원을위한 브라우저 간 일관성 향상.
- 더 쉬운 코드 병합
- World Wide Web Consortium, Palm 등에서 사용합니다.
그 점을 감안할 때 MooTools 는 jQuery 가하는 모든 일을하는 것처럼 보이지만 (일부는 jQuery 에서 할 수없고 MooTools 에서 할 수 있음 ) jQuery 는 학습 곡선이 더 작습니다.
그래서 질문은 왜 당신이나 당신의 팀 이 다른 JavaScript 프레임 워크 대신 jQuery 를 선택 했습니까?
참고 : jQuery 가 훌륭한 프레임 워크라는것을 알고 인정하지만, 다른 옵션은현재 사용하는 것보다 jQuery 를 선택해야하는이유를 결정합니다( MooTools )?
이상한 질문 이네요 ... 느낌이 ...
- mootools에 매우 익숙하고 OOP 모델을 최대한 활용하여 코드를 이미 관리하고 지원하기 쉽게 만듭니다.
- 당신은 jQuery의 목적이 DOM 조작과 AJAX에 대해 다소 다르고 조정하고 mootools가 jQuery하는 모든 일을하고 그 다음 일부를 수행한다는 것을 알고 있습니다.
- jQuery의 인기를 높이고 지원을 덜 중요하게 만드는 것들이 많이 사용됩니다.
결론은 과대 광고입니까? jQuery를이 'AJAX', .NET 및 웹 2.0과 같은이 마법의 마케팅 유행어 중 하나에 돌고-하는 요구를 위해 큰하지만 왜 당신은 당신을 위해 잘 작동하는 프레임 워크와 함께 머물고 화해야합니까? 또한 다음과 같은 사항을 다룰 비즈니스 고려 사항도 있습니다.
- 프레임 워크 수명, 또는 계속 성장하는 jQuery에 직면하여 mootools가 사라질 가능성이 있습니다. 1.3 베타 1을 이미 출시했습니다. 2.0이 연말 출시 될 예정이라는 점에서 매우 의심 스럽습니다.
- 직원 및 교육 비용 (나는 mootools 프로그래머를 찾는 것이 이력서 / 이력서에 jquery를 두드리는 것보다 더 생각합니다).
- 주어진 자원이 주어진 각 프레임 워크에서 시스템을 유지하고 확장하는 데 시간 (및 비용).
두 프레임 모두 훌륭하지만 mootools를 사용하는 데 귀하의 관심이 가장 잘 맞는다고 생각합니다.
개인적으로 jQuery는 내가 필요한 것을 정확히 수행합니다.
나는 잘 구조화 된 내 서버 측 측에서 코드에서 대부분의 작업을 수행합니다. 적절한 OOP, 레이어 및 MVC 아키텍처가 있습니다. Javascript로 뭔가를 해야 할 때 , 지금까지 jQuery가 필요한 것을 발견했습니다. 솔직히이 세 가지 범주로 나 고용니다.
- 간단한 DOM 조작 , 일반적으로 서버에 도달하지 않고 항목을 표시 / 숨 깁니다.
- Ajax는 Nuff가 말했다.
- 모달 팝업, 애니메이션, 숨김 / 표시로의 페이드 전환을 포함하는 UI 특전 . 나는 하드 코어 백엔드는 사람이 코딩 오전, 내가 빨아 UI 물건에. 나는 jQuery를 사용 하여 프로그래밍 방식으로 매력적으로 보이는 것을 만들 수있는 점이 정말 마음에 씁니다 .
많은 jQuery 플러그인 라이브러리는 방대하고 클라이언트 측 작업을 단순화하는 라이브러리 많이 많이 찾았습니다. 좋은 물건.
MooTools는 OO 사고 방식을 도입했습니다. 이것은 좋지만 제가 필요한 것은 아닙니다. 나는 구조화를 모두 백엔드에 유지하고 싶습니다. 그리고 클라이언트 측 코드에 그 생각을 도입 할 필요가 없습니다. 나에게 클라이언트 측 코드는 매우 작은 부분이며 클래스 관점에서 생각하는 것은 너무 과도하고 더 작업입니다. MooToools의 모범 사례라고 생각되는 것을 사용한다면 하나가 아닌 두 개의 응용 프로그램을 구축 할 것입니다.
나는 그것이 왜 그렇게 인기가 있는지, 특히 여기 주변에서 요약 생각합니다. 전반적으로 우리는 백엔드 코드 유형의 사람이며 jQuery를 사용하면 프로그래밍 방식으로 매력적인 UI를 만들 수 있으며 백엔드 코어에 집중할 수 있습니다.
저는 자바 전개에 고전적인 객체 지향을 응용하는 것을 좋아하지 않습니다. 한 자바 프로그래머가 OO에 Base2를 사용하는 반면 다른 프로그래머는 Prototype, Moo, JS.Class 또는 Joose를 사용하는 방법이 너무 많습니다. Resig는 의도적으로 jQuery에 클래스를 추가하지 않기로 결정하기 때문에, 이는 더 많은 작업이 자바 스크립트 방법을 찾도록 장려했습니다.
결과적으로 jQuery 작성자가 자바 스크립트를 읽고 다른 사람이 읽기 쉬운 jQuery 코드를 작성하는 것이 더 많은 것입니다. 저는 일반적으로 JavaScript에서 클래스 OOP를 에뮬레이트하려고합니다. 대신, 나는 즉석에서 객체를 생성하고 전달하며 배열을 가지고 있습니다. 이해하기가 너무 많음 그 생각을 OOP 언어로 제도는 것조차 발견했습니다!
내가 아는 모든 것에 대해 Moo가 jQuery를 잘 따라 잡았거나 능가했을 수 있습니다. 하지만 어떤 말이 앞서 나가고 있는지 확인하기 위해 6 ~ 7 개의 훌륭한 JavaScript 라이브러리를 추적하는 데 시간을 할애 할 수 없습니다.
나는 주로 타이밍의 문제라고 생각합니다. 많은 프로그래머가 AJAX에 뛰어 들었을 때 jQuery는 문제를 해결 한 새롭고 멋진 제품이었습니다.
다른 도서관이 대부분 따라 잡았습니다. YUI, ExtJS, Dojo, Moo- 모두 훌륭합니다. 하지만 모두 사용할 수 없습니다.
나는 도서관의 새로운 기능의 파급 효과 알아 내려고 열심히 일을 할 사용합니다. 예를 들어 jQuery는 1.3부터 라이브 이벤트를 추가했습니다. 여러 페이지에서 코드를 잘라낼 수 있습니다. Moo는 지금도 그것을 제공하고 그리고 그것이 바로 사용할 수 있습니까?
나는 Moo가 굉장하다고 확신합니다. 나는 그것을 배울 시간을 갖고 싶습니다. 하지만 도장을 보며? 한 프로젝트에서 효율적으로 jQuery에서 대부분의 아이디어를 끌어들이는 것을 알았습니다. 그리고 그것은 pubsub와 Comet에 대한 좋은 지원을 가지고 있습니다.
나는 당신과 공감합니다. 그러나 당신의 프로그래머는 말이 옳다. jQuery를 사용하는 경우에는 많은 사람들이 경력에 유익하며, jQuery를 사용하는 경우 도움을 요청 수있는 책, 예제 및 동료 프로그래머가 더 많이 있습니다.
결국 jQuery를 사용하기로 결정 OO 라이브러리를 사용할지 여부를 결정하기 전에 신중하게 생각하십시오. 멋진 것들 (JS.Class 또는 Joose와 같은)이 그것의 단계를 밟는다는 것은 대부분의 자바 펼쳐 프로그래머가 코딩하는 방식을 의미합니다.
나는 논쟁에 대해 머리를려고 노력하는 방식으로 잠시 동안이 똑같은 질문을 스스로에게 해줍니다. 그리고 제가 읽은 토론을 통해 압도적 인 반응은 "더 널리 읽었습니다."
나는 둘 다 사용하게하는 사람입니다. 직장에서의 JQuery ( "더 많이 채택"하고 개인 프로젝트의 채택 됨) Mootools. 그 결과, 나는 항상 JQuery를 사용할 때마다 느꼈다. JSON 지원, 요소 생성, 이벤트 처리 등이 포함됩니다. 직장에서 나는 75 개의 긴 이벤트를 작성하는 자신을 발견하고 그 결과로 더러움을 느낀다.
하지만 JQuery에 대한 나의 주요 제품은 대부분의 사람들과 개발자가 우려하는 일관성이나 관행이 부족한 것입니다. "더 많은 플러그인을 사용할 수 있습니다."일화는 구조적 으로든 다른 방식으로도 사용할 수 있습니다. "허용 된"플러그인 모델을 배우는 데 몇 주가 걸렸고, 그 후에도 현재 구조 내에서 오류와 비 효율성을 발견 한대로 저만의 실용적인 스타일을 적용했습니다. 누구나 뛰어 들어 JQuerying을 시작할 수있는 'Pro'라고 할 수 있습니다. 그러나 저는 그것을 '단점'이라고 부르는 경향이 있습니다. 많이 사용하는 표준을 30 가지 다른 방법을 사용하여 고정하기 어렵습니다.
그래서 "JQuery를 안다"는 것은 무엇을 의미 하는가? .hide (). 보여 주다 (). 점점 뚜렷해지다 (). fadeOut ()을 사용하는 방법을 알고 있나요?
직장에서 JS 조폭을해야 할 때 Mootools가 그리워요. 중복 JSON 지원이 의미입니까? 어서 ......
"광범위하게 채택 된"응답에 대한 응답으로, 우리 모두는 osCommerce에가 가장 " 광범위하게 채택 된 "쇼핑 카트라는 것을 알고 있으며 그게 똥 더미가 무엇인지 알고 있습니다 . 나는 JQuery와 OSCommerce를 비교하지 않습니다. 나는 "Widely Adopted"응답의 결함을 지적하고 있습니다.
채널에있는 애플 용 앱 스토어에 10 개의 만개의 앱이 있나요? 50,000 개는 방귀 앱입니다. JQuery에 대한 많은 사람들이 물론 쓰레기와 가치의 비율은 훌륭합니다.
jQuery를 사용하면 명확하고 간결한 함수 프로그래밍 방법에 액세스 할 수 있습니다. C # 3.0의 (LINQ)에서 메서드 체인이 출시 된 이후로 이것은 .NET 프로그래머에게 매우 잘 작동합니다. 따라서 한 언어에서 다음 언어로의 흐름이 쉽습니다. DOM에서 객체 또는 객체 목록을 쿼리 할 수 있다는 것이 훨씬 더 효과적입니다. 처음에는 jQuery의 선택력이 매력적이며 확장 성, 그리고 물론 그와 함께 제공되는 모든 내장 기능이 훌륭합니다. 또한 다른 사람이 무엇을했는지 먼저 확인한 다음 해결책이 없으면 직접 시도한다는 점에서 뒤에있는 커뮤니티가 훌륭합니다. 마지막으로 ...하지만 확실히 중요한 것은 ... Microsoft가 Visual Studio 10에 포함하고 지원한다는 사실은 훌륭합니다. Moo Tools, Prototype 등은 위의 모든 것과 경쟁 할 수 없습니다.
어쨌든 JS 프레임 워크는 매우 비슷합니다. 한동안 mootools로 작업 해왔다면 그것에 충실하십시오. 당신의 프레임 워크를 아는 것이 이것 저것 때문에 하나를 선택하는 것보다 훨씬 더 중요합니다.
제 생각에는 mootools는 고급 자바 스크립트 프로그래머에게는 더 좋고, jquery는 비 자바 스크립트 프로그래머에게는 더 좋습니다. 두 문서를 모두 읽은 후에 생각하는 것입니다. 저는 그것들 중 어느 것도 사용하지 않았습니다. jQuery는 자바 스크립트의 핵심, 함수 바인딩, 객체 복제, 스레드 스택 등을 지원하지 않습니다.
다른 프레임 워크와 마찬가지로 jQuery는 수행하는 작업을 수행하며 요구 사항에 맞지 않으면 다른 것을 사용해야합니다. 자바 스크립트에서 복잡한 프로그래밍을하기 위해 jQuery를 사용하지 않습니다. DOM 조작과 CSS3 스타일을 간단하게 만들고 95 %의 시간을 필요로하기 때문에 사용합니다.
한동안 MooTools를 보지 않았습니다. 그러나 여기에 JQuery에 대한 요점이 있습니다.
- 일관된 프로그래밍 모델 (작동하는 JQuery 방식이 있음)
- 훌륭한 문서 . 내가 시작했을 때 JQuery는 최고의 문서를 가지고있었습니다.
- 광범위한 타사 연결
- Microsoft 지원-저는 asp.net 개발자입니다. 이것은 고객의 마음을 편하게하는 데 도움이됩니다. 또한 내 도구와 함께 제공됩니다.
- 많은 시작 가이드.
- JQuery의 웹 사이트는 MooTool의 웹 사이트보다 멋지게 보입니다. 그게 중요한 건 미안하지만 그래요 이러한 도구 중 상당수는 개발자뿐 아니라 디자이너에게도 호소력을 발휘해야합니다.
야 그니.
예, 여기에서는 다소 틀렸지 만 이것이 jQuery가 MooTools보다 더 큰 기반을 갖는 주된 이유입니다. MooTools가 제공하는 모든 추가 기능은 훌륭하지만 YAGNI.
그것은 최선이 아니라 만족에 관한 것입니다. 당면한 문제에 대한 적절한 해결책을 찾는 것입니다. jQuery는 사용하기 쉽고 기본 목표는 DOM 조작입니다. 자바 스크립트를 사용하는 95 %의 사람들이 DOM을 조작하기 위해 그렇게하고 있기 때문에 더 긴 MooTools 학습 곡선을 거치지 않아도됩니다. MooTools는 단순히 jQuery가 적은 노력으로 제공하지 않는 것을 테이블에 가져 오지 않습니다.
MooTools는 사용하기 전에 더 많은 것을 요구합니다. jQuery를 사용하면 무언가를 빠르게 통합 할 수 있습니다. 크고 무거운 js 앱을 작성하기 시작하면 해당 접근 방식의 몇 가지 단점에 부딪 힐 수 있지만 js를 작성하는 사람들의 95 %가 그렇게하지 않으므로 그 문제는 중요하지 않습니다. 그들은 무거운 작업을 위해 서버 측 언어를 사용하고 DOM을 위해 자바 스크립트를 사용합니다.
그 문제에 대해서는 팀에도 중요하지 않을 수 있습니다. 목록을 살펴 보려면 지점별로 (jQuery 먼저) :
대규모 지지자 커뮤니티-프로젝트와 약간만 관련이 있습니다. 개인적으로 팀과 더 관련이 있습니다. 불행이 닥치고 (제발, 하느님, 아니요) 회사가 사라지면 jQuery는 MooTools보다 더 많은 일자리를 얻습니다.
플러그인 저장소-바퀴를 재발 명하는 데 도움이되므로 관련성이 매우 높습니다.
Microsoft의 ASP.NET 및 VisualStudio와의 통합-.NET 상점의 경우 매우 적합합니다. 사실, 이것만으로도 .NET을 사용하는 경우 전환해야합니다.
Microsoft, Google 및 기타 사용자가 사용합니다. 누가 신경 쓰나요?
이제 MooTools 목록 :
JS 용 클래식 OOP 에뮬레이션을 사용하는 객체 지향 프레임 워크-프로젝트의 특성이 장점이 아니라면 관련이 없습니다. 나는 당신이 무엇을 만들고 있는지 모르지만 웹 상점의 경우 이것은 거의 관련이 없습니다. 대부분의 웹 상점에는이를 플러스 할 수있는 충분한 코드가 없습니다.
확장 된 네이티브 개체-대부분의 웹 상점과는 무관 함
기본 기능 지원을위한 브라우저 간 일관성 향상. -관련
더 쉬운 코드 재사용-이것은 큰 저장소의 jQuery 이점과 약간 충돌합니다. 큰 저장소는 그 자체로 코드 재사용을 말합니다. 나는 당신이 코드 재사용의 좁은 정의를 사용하고 있다고 생각합니다. 내가 작성한 많은 jQuery 코드와 MT 코드를 재사용했습니다.
World Wide Web Consortium, Palm 등에서 사용합니다. -관련이 없습니다. 다른 사람이 무엇을 사용하는지에 대한 유일한 관련성은 당신이 그곳에서 일자리를 원할 때입니다. 그것을 사용하는 어떤 특정 상점보다 얼마나 많은 상점이 그것을 사용하는지에 더 관련성이 있습니다.
자바 스크립트 코딩에 접근하는 진정한 방법은 없습니다. 편견을 없애고 팀과 함께 앉아 편견도 제거하십시오. 현재 진행중인 (그리고 수행하고자하는) 프로젝트의 특정 유형과 해당 사례에 적용되는 각 도서관의 강점에 대해 이야기하십시오. (다른 케이스가 존재하지 않기 때문에 다른 케이스를 어떻게 처리할지는 중요하지 않습니다.) 그로부터 합의에 도달해야합니다.
(YAGNI = 설명이 필요하다면 당신은 그것을 필요로하지 않을 것입니다.)
prototype.js 또는 mootools와 달리 확장하거나 기본 객체를 원숭이 패치하지 않기 때문에 jQuery를 기본 UI 라이브러리로 사용하기로 선택했습니다. 문서화 각도에서 시작하면 어떤 프레임 워크를 사용할 지에 대한 의문의 여지가 없습니다.
당신은 스스로 그것을 말합니다.
그 점을 감안할 때 MooTools는 jQuery가하는 모든 일을하는 것처럼 보이지만 (jQuery에서는 할 수없고 MooTools에서는 할 수있는 일도 있음) jQuery는 학습 곡선이 더 작습니다.
MooTools가 수행하는 대부분의 추가 기능은 우리 가 필요로하지 않는 것 입니다.
당신이 스스로 말했듯이 jQuery는 배우기 쉬우 며, 실제로 프레임 워크를 선택할 때 대부분의 사람들에게 더 중요합니다.
JavaScript에서 필요하지 않은 것은 분명히 OOP와 추악한 객체 에뮬레이션입니다.
지난번에 MooTools를 확인했을 때 (1,5 년 전 :-) 여러 선택을 조작하는 브라우저 비 호환성이있었습니다.
그래서 jQuery는 완전히 괜찮아 보입니다.
jQuery는 멋진 라이브러리 일뿐만 아니라 제작자 인 John Resig도 Pro Javascript Techniques 의 저자로서 거리의 신뢰를 받고 있습니다.
우리 사무실에는이 책이 2-3 부 있습니다.
jQuery는 작지만 (의도적으로 그렇게) 플러그인을 통해 기능을 추가 할 수 있습니다.
mootools에 대한 내 경험을 다소 불쾌하게 만든 것은 문서화와 API의 안정성이었습니다. 사용중인 mootools-Version과 관련된 문서를 찾을 수 없었습니다. 정의 된 API가 안정적이라면 그다지 문제가되지 않을 것입니다. 그러나 최신 버전에서 사라진 일부 기능 (검색 시간 후에 변경 로그가 발견됨)으로 인해 마이그레이션도 불가능했습니다. 그 후 mootools는 나를 위해 경주에서 벗어났습니다.
다른 많은 사람들과 마찬가지로 저는 단순한 사용자 인터페이스 조작에 클래스 기반 OOP를 도입하고 싶지 않습니다. 그것이 내가 jQuery를 사용하는 이유입니다. 그렇게 복잡한 사용자 인터페이스가 아닙니다. 풍부한 브라우저 측 응용 프로그램을 구축해야 할 때 항상 다양한 위젯을 즉시 사용할 수있는 큰 솔루션 (ExtJS, YUI, qooxdoo)으로 전환했습니다.
더 큰 사용자 커뮤니티 와 더 광범위한 채택은 유사한 기능과 개념을 제공하는 도구 / 라이브러리를 비교할 때 큰 차이를 만듭니다. 더 큰 커뮤니티는 더 많은 지원, 더 많은 예제, 더 많은 좋은 아이디어 및 더 많은 재사용 가능한 코드 스 니펫을 의미하며, 이는 드문 시나리오에서 작업 할 때 특히 중요합니다.
둘째, 내가 본 벤치 마크에서 jQuery는 MooTools보다 빠릅니다.
또한 작은 코어를 유지하고 플러그인을 통해 기능을 추가하는 데 중점을 두는 것이 정말 마음에 듭니다. 코어 라이브러리가 정말 커지고 다루기 어려워지는 것을 방지합니다.
개인적으로 MooTools를 사용 해본 적이 없지만 대부분의 jQuery 기능이나 개념과 동일한 수준의 수용 가능한 라이브러리를 제공하는 환상적인 라이브러리라는 점은 의심 할 여지가 없지만 1 번 포인트는 저를위한 케이크입니다.
또 다른 이유 : jquery를 관리에 판매하는 것이 더 쉽습니다. 기업 환경에서 내부 asp.net 기반 개발을 수행하면 마법의 단어는 "Visual Studio에서 지원"합니다.
한 가지 이유는 이것이 전부가 아닙니다. 꽤있다 몇 가지 다른 기능 뿐만 아니라이 . 다른 경우에는 모든 사람이 사용하는 것은 아닙니다. 그러나 나는 좋은 호언을 방해하고 싶지 않습니다.
많은 답을 찾아야합니다 ... 훌륭한 문서와 커뮤니티 지원이 중요합니다. 나는 js 프로그래밍을 싫어했고, 명실상부 한 것처럼 피하고 싶었지만 이제는 jquery와 빠른 학습 곡선 때문에 완전히 수용했습니다.
최고의 기술을 가진 사람이 항상 그런 것은 아닙니다!
Mootools, jquery 프로토 타입 등을 사용할 때 제대로 작동하지 않거나 전혀 작동하지 않습니다. 동시에 사용할 이유가 전혀 없다는 데 동의했지만 가끔씩 동일한 페이지 (예 : 플러그인, 슬라이드 쇼, 위젯)에 표시됩니다. 등) 일이 작동하지 않습니다.
그 자체로는 받아 들일 수 없습니다. 따라서 jquery의 모든 소품은 불필요한 두통을 일으키지 않습니다!
사람들이 팩스를 사용하기 시작한 이유는 무엇입니까? 특정 시점에서 혜택은 기하 급수적으로 증가합니다.
'ProgramingTip' 카테고리의 다른 글
| Python Pandas에서 두 값 사이의 DataFrame에서 행을 선택하는 방법은 무엇입니까? (0) | 2020.10.28 |
|---|---|
| Typescript를 사용하여 Express Request 객체 확장 (0) | 2020.10.28 |
| 바이트 배열을 맵 키로 사용 (0) | 2020.10.28 |
| 선택을 반복하고 선택하거나 선택하지 않는 각을 계산합니다. (0) | 2020.10.28 |
| Go에서 파일에 추가 (0) | 2020.10.28 |