문제

WPF와 Silverlight의 풍부한 표현 기능 덕분에 저와 같은 개발자는 다음 프로젝트에서도 그랬듯이 요즘에는 그래픽 디자이너와 더 자주 긴밀하게 협력하게 될 것입니다.

이 작업을 더 원활하게 진행하는 데 대한 팁과 경험(두 가지 관점 모두에서)을 갖고 있는 사람이 있나요?

예를 들어, 최근 디자이너에게 소스 제어를 언급했을 때 그래픽, 이미지 등을 소스 제어할 수 없으므로 시간 낭비라는 말을 금방 들었습니다.그래서 나는 이렇게 대답했습니다.좋습니다. 하지만 WPF/Silverlight의 XAML 파일은 어떻습니까?

Scott Hanselman은 이 주제에 대해 다음과 같이 말했습니다. 팟캐스트, 하지만 그는 도구에 더 초점을 맞춘 반면 나는 의사소통 문제/측면에 더 관심이 있습니다.

도움이 되었습니까?

해결책

나는 디자이너와 매우 긴밀하게 협력하는 프로젝트에 4개월을 보냈지만 그는 여전히 CVS의 기본 아이디어(내가 선택한 소스 제어 시스템이 아님)를 이해하지 못했습니다.여기서는 템플릿 파일, JavaScript 및 CSS에 대해 이야기하고 있습니다.그는 바보가 아닙니다. 그것은 그의 일을 더 어렵게 만드는 것 중 하나일 뿐이므로 그는 그 일에 전적으로 헌신하는 것을 거부합니다.

내 경우에는 거의 모든 JavaScript가 마크업에 의존한다는 점과 그가 순수 CSS, DIV 기반 레이아웃을 테이블 기반 레이아웃으로 변경했을 때 내 모든 JS가 변경된다는 사실을 알려주지 않고 실제로 요점을 파악해야 했습니다. 부수다.

프로젝트를 진행하면서 나와 꽤 잘 지내고, 업무 외적으로 축구도 하는 디자이너와는 각자의 책임에 대해 매우 열띤 대화를 나누는 경우가 많았다.이런 교류를 그냥 넘어갈 만큼 그를 잘 알지 못했다면 견디기 힘든 작업 환경이 만들어졌을 것 같아요.따라서 저는 프로젝트가 진행되는 동안 두 당사자 모두에게 기대되는 것이 무엇인지 관리자나 프로젝트 감독자와 함께 두 사람 사이에 정확히 설정하는 것이 중요하다고 생각합니다.

내 경우에는 최근에 거의 문제가 없었는데, 왜냐하면 CVS의 상황이 정리됐고, 원할 때마다 마크업을 변경할 수 없다는 생각이 들었기 때문이다.템플릿 파일을 만들고 직접 작업하는 대신 디자이너는 정적 파일에서만 작업하며 이를 템플릿 파일에 연결하는 것은 내 책임입니다.

그것은 양측의 의사소통과 약간의 타협에 관한 것입니다.

다른 팁

제가 발견한 것 중 하나는 개발자로서 코드를 디자인하는 방식이 디자이너가 코드로 수행할 수 있는 작업에 큰 영향을 미친다는 것입니다.웹에서 Silverlight 또는 WPF 샘플 애플리케이션을 다운로드하여 Blend에서 여는 경우가 종종 있는데, 디자이너 내에서 코드가 제대로 실행되지 않아 Blend 충돌이 발생하는 경우가 있습니다.충돌이 발생하지 않으면 실행 중인 애플리케이션과 전혀 유사하지 않습니다.

저는 최근 호주와 뉴질랜드의 Tech Ed에서 "디자인 가능성을 위한 디자인"에 적용할 수 있는 기술에 대해 강연했습니다.짧은 불릿 목록이 포함되어 있습니다:

  1. 데이터 바인딩을 활용할 수 있는 코드를 작성하세요.Model-View-ViewModel 또는 프레젠테이션 패턴이 이에 적합합니다.

  2. 서비스 종속성에 대한 "디자인 타임" 스텁을 제공하세요.바인딩하려는 클래스가 웹 서비스 호출을 수행하는 경우 웹 서비스 클라이언트를 디자이너가 blend 내부에서 사용하는 "더미 데이터"를 반환하는 스텁 클래스로 교체해야 합니다.이는 IoC 및 종속성 주입을 통해 쉽게 수행할 수 있으며, HtmlPage.IsEnabled == false인 경우 하나의 구현을 주입합니다.

  3. 데이터 바인딩을 사용하면 XAML 파일에 있는 "명명된 요소"의 수를 제한할 수 있습니다.뒤에 많은 코드를 작성하면 C# 코드가 txtName 또는 txtAddress와 같은 명명된 요소와 결합되어 디자이너가 쉽게 "망칠" 수 있습니다.

  4. 클릭 이벤트 핸들러 뒤에 있는 코드 대신 명령 패턴을 사용하십시오.핸들러에서 이벤트 호출자를 느슨하게 결합하면 이름이 더 적은 요소를 가질 수 있으며 디자이너가 특정 명령을 호출하기 위해 버튼이나 메뉴 항목 중에서 자유롭게 선택할 수 있습니다.

  5. Blend에서 코드를 테스트해보세요!자신을 순수한 개발자라고 생각하더라도 도구에서 코드를 사용할 수 있는지 테스트하고 디자인 타임에 최상의 경험을 얻기 위해 노력해야 합니다.어떤 사람은 "테스트 가능성을 위한 설계"에 대해 불평하고 단지 코드를 더 테스트하기 쉽게 만들기 위해 소프트웨어 설계 결정을 내리는 것처럼 도구가 소프트웨어 설계에 영향을 주어서는 안 된다고 주장합니다.나는 이것이 현명한 일이며 실제 디자이너-개발자 작업 흐름을 진행할 수 있는 유일한 방법이라고 생각합니다.

다른 팁은 작게 시작하는 것입니다.디자이너가 XAML, WPF 및 Silverlight를 처음 접한다면 먼저 프로젝트 팀에 소개하고 그들이 알고 있는 도구를 사용하여 몇 가지 기본 디자인을 수행하도록 하세요.Adobe Illustrator에서 몇 가지 버튼과 일러스트레이션을 작업한 후 XAML로 내보내고 디자인 자산을 직접 활용하는 방법을 보여주세요.계속해서 더 많은 것을 소개하면 고객이 관심을 갖고 Blend로 전환하기를 원할 것입니다.꽤 학습 곡선이 있지만 확실히 그만한 가치가 있습니다!

행운을 빌어요!

추신:나는 내 블로그에 패턴과 디자이너 친화적인 코드 작성에 대한 내용을 작성했습니다. http://jonas.follesoe.no.또한 내 Tech Ed 강연의 비디오 녹화 링크와 해당 주제에 대한 추가 자료를 읽을 수 있는 많은 링크도 찾을 수 있습니다.

이것은 주제에서 약간 벗어난 것일 수 있지만(소스 제어 및 그래픽에 대한 귀하의 질문에 구체적으로 답변하고 있습니다) ~할 수 있다 바이너리 데이터(이미지 등)를 소스 제어에 넣습니다(제 생각에는 많은 경우에 그래야 한다고 생각합니다). 단지 더 많은 디스크 공간을 차지할 뿐이며 차이점 보기를 사용하여 의미 있는 방식으로 변경된 사항을 분석할 수 없습니다. 하지만 얻을 수 있는 것은 각 개정판을 문서화한 커밋 메시지 기록, 롤백 기능 및 쉽게 보관할 수 있는 기능(개정에 태그 지정 SVN 용어로) 특정 릴리스/버전에 속하는 모든 파일(시각적 자산, 문서, 소스 코드 등)이 함께 포함됩니다.또한 빌드 시스템이 소스 제어에서 특정 소프트웨어 버전을 빌드하는 데 필요한 모든 것을 가져오는 것이 더 쉽습니다.

초기 디자인 및 건축 세션에 그래픽 디자이너를 참여시킵니다.

당신은 그들을 참여시켜 잘못된 가정을 드러내고 벽 너머로 물건을 앞뒤로 던지기보다는 함께 일하는 패턴을 확립하기를 원합니다.

원래는 전문 디자이너가 Expression Blend에서 작업하고 개발자가 Visual Studio에서 작업하여 단일 공유 소스 파일 집합을 변경하는 것으로 구상되었습니다.확실히 그렇게 하는 것이 가능하지만(다른 개발자가 예상한 것을 깨뜨리지 않았는지 정기적으로 주의 깊게 확인하는 한)또는 디자인 도구), Microsoft 내부 일부를 포함하여 개발자 커뮤니티의 많은 구성원은 Blend와 Visual Studio 프로젝트 활동을 분리하여 유지하는 것의 이점을 발견했습니다. 심지어 Blend에서 생성된 Xaml의 신중하게 리팩터링된 버전을 수동으로 잘라서 디자이너와 개발자가 단일 공유 코드 기반에서 직접 작업할 수 있도록 허용하는 대신 "공식" VStudio 프로젝트 소스를 사용합니다.영국에 있는 Microsoft의 사용자 경험 팀은 실제 프로젝트에서 디자이너와 개발자의 노력을 조율하려고 할 때 직면한 문제를 설명하는 비디오를 게시했습니다.

Real_World_WPF_DesignersAndDevelopersWorkingTogether

배운 주요 교훈 중 하나는 서로의 영역을 전혀 모르는 디자이너와 개발자로 프로젝트를 진행할 수 없다는 것입니다.개발자는 디자이너가 장식할 수 있는 유용한 UI 셸과 디자이너가 상호 작용을 디자인할 수 있는 유용한 데이터 "스텁"을 디자이너에게 제공할 수 있을 만큼 Blend에 충분히 익숙해야 하며, 디자이너는 자신이 필요로 하지 않는 개발 문제에 대해 충분히 이해해야 합니다. 컨트롤을 삭제하고 이를 사용자 정의 시각적 요소로 대체하는 등의 작업을 수행하지 마십시오. 원래 컨트롤에 연결된 모든 기능이 손상되었다는 사실을 깨닫지 못하는 것입니다.

디자이너/개발자의 워크플로 결합에 대한 Microsoft의 비전은 현실에서 확실히 무너지는 것 같습니다.저는 약 4개월 동안 2개의 전용 디자인 리소스가 포함된 상당히 큰 규모의 WPF 프로젝트를 진행한 경험이 있습니다.다음은 Microsoft가 종종 잊어버리는 몇 가지 사실입니다.

  • 디자이너는 종종 Mac 사용을 선호합니다. (저희 회사의 디자이너는 100% Mac - 0% Windows입니다.)
  • Blend는 Mac에서 실행되지 않습니다(VM 솔루션의 경우 디자이너는 일반적으로 외국 OS에서 이상한 응용 프로그램을 실행하는 것과 같은 괴상한 솔루션을 좋아하지 않습니다).
  • 디자이너는 Photoshop과 Illustrator 등 업무 도구를 사용합니다.기간.
  • 오늘날의 공격적인 일정은 일반적으로 디자이너가 완전히 새로운 애플리케이션/디자인 환경(예: Blend)을 배울 충분한 시간을 제공하지 않습니다.

위에서 언급한 내용을 통해 제가 알아차린 것은 이것이 매우 기술적인 디자이너이거나 그래픽에 능숙한 프로그래머라는 새로운 직업 유형을 창출한다는 것입니다.기본적으로 디자인 자산을 원시 형식(보통 .psd 또는 일러스트레이터 형식)으로 가져와 필요에 따라 신청 프로세스에 적용할 수 있는 사람입니다.

나는 그 사람(그래픽에 능숙한 프로그래머)으로 밝혀졌습니다.저는 Illustrator 파일에서 XAML을 내보내고 필요할 때 직접 정리하고 이러한 자산을 Blend 또는 VS에서 쉽게 사용할 수 있는 표시 개체로 만드는 데 많은 시간을 보냈습니다.또한 디자인 요소를 가져와 블렌드를 사용하여 다시 그리는 경우도 있었습니다(보통 원본 자산이 비트맵 기반이고 이를 벡터로 변환하는 것이 더 적합한 경우).

내 응용 프로그램은 일반적이지 않았을 수 있습니다. 그래픽이 매우 풍부하고 해상도 독립성이 주요 목표 중 하나였기 때문에 여러 해상도와 종횡비에서 보기 좋게 표시되어야 했습니다(오늘날 환경에서 TV용으로 디자인할 때의 어려움을 생각해 보십시오. 저해상도 SD와 고해상도 HD 모두에서 보기 좋게 보입니다.

요약하자면, 저는 WPF가 놀라운 기술이며 Microsoft에게 있어 절대적으로 올바른 방향으로 나아가는 단계라고 생각합니다.그러나 디자이너의 역할을 재정의하지 않는 한 개발 프로세스에 디자이너를 통합하기 위한 최종 솔루션은 아닙니다.

저는 귀하가 언급한 Hanselman 팟캐스트의 디자이너인 Felix Corke입니다. 여기에 개발자가 아닌 진정한 창작자의 몇 가지 요점이 있습니다.

개발자 도구에 익숙해지는 데는 오랜 시간이 걸렸습니다. 몇 년 전 xaml 작업을 처음 시작했을 때 Visual Studio, C# 또는 어떤 유형의 소스 제어에 대해서도 들어본 적이 없었습니다.Illustrator나 3DsMax가 당신에게 낯선 것처럼 나에게도 그것들은 낯설었습니다.

나의 가장 큰 요점은 디자이너가 개발자 관행을 알 것이라고 기대할 수 없다는 것입니다. 많은 양의 손을 잡고 할 준비를 하십시오.새로운 것을 배울 필요는 없지만 디자이너는 앱 개발의 완전히 새로운 무서운 측면을 접하게 될 것입니다.나는 몇 가지 솔루션과 체크인을 제대로 엉망으로 만들었습니다(그리고 여전히 그렇습니다).

다행스럽게도 저는 단순한 크리에이티브보다는 디자인 중심의 통합자가 되는 법을 배웠으며 아마도 이것이 귀하의 프로젝트에 포함되어야 할 역할일 것입니다.이것은 제가 Mix의 디자이너/개발자 세션인 미인과 괴짜를 위해 만든 그림입니다. 두 사람 중 한 사람이 스펙트럼의 양쪽 끝에서 너무 멀리 떨어져 있으면 다른 사람의 작동 방식과 역할이 무엇인지 이해하기 어려울 수 있습니다.

alt text

특정 질문에 답변해 드리겠습니다.

ps. 소스 제어에서 100Mb+ .psd 파일을 원하지 않습니다. ;)

저는 WPF 노력을 성공시키기 위해 제가 수행해야 했던 역할인 Integrator 접근 방식을 굳게 믿습니다.

Laurent Bugnion은 우편 내가 말하는 내용을 설명하는 것입니다. 로비 잉게브레센 또한 이 접근 방식을 크게 믿습니다.

하지만 기본적으로 누군가는 개발자 세계와 디자이너 세계 사이에 존재하는 '간극'을 메워야 합니다.일반적으로 일어나는 일은 이 사람이 개발자 세계나 디자이너 세계 출신이라는 것입니다.개발자 세계 출신이라면 아마도 디자이너 경향이 있는 개발자일 것입니다(그들은 모양과 느낌, 애플리케이션의 시각적 요소, 화면 레이아웃 등을 담당합니다).디자이너 세계 출신이라면 코드를 두려워하지 않고 가끔씩 코드를 작성하여 애니메이션이나 반짝이는 것을 얻는 것을 즐깁니다.

그러나 그들이 어느 세계에서 왔는지에 관계없이 그들은 대개 이전에 갖지 못한 기술을 쌓아야 합니다.내 경우에는 UI 레이어를 좋아하는 개발자이기 때문에 디자이너적 성향을 지닌 개발자라고 말하고 싶다.그 격차를 메우고 그래픽 디자이너와 생산적인 대화를 나누기 위해 저는 다음과 같은 디자이너 유형의 기술을 모두 익혀야 했습니다.Expression Design, XAM 3D 등 활용법 학습

Shannon Braun은 최근 지역 개발자 회의에서 개발자/디자이너 관계와 커뮤니티가 발견한 작업 흐름에 대해 프레젠테이션을 했습니다.나는 회의에 참석하지 않았지만 그의 생각은 슬라이드 그 문제에 관해 훌륭한 토론이 있었습니다.

디자이너가 소프트웨어 제품 구축과 관련된 전체 작업에서 멀리 떨어져 있어야 한다고 느끼는 정도는 해결해야 할 훨씬 더 큰 문제입니다.자신의 작업이 전체에 어떻게 통합되는지 알 필요가 없다는 디자이너의 표현된 권리에 영합하지 마십시오.

디자이너 커뮤니티에서 성장한 엄격한 전문화는 소프트웨어 개발 산업이 직면한 가장 큰 산업 성숙도 문제 중 하나입니다.이는 예상대로 더 많은 재작업과 더 긴 주기 시간을 생성하는 전문화 수준입니다.

이는 상호 작용 설계 및 구현을 전혀 인식하지 못하는 개발자의 자격 감각에도 해당됩니다.

극단적인 전문화는 언제나 생산성 문제를 기하급수적으로 증가시킵니다.학습 문화를 촉진하는 프로세스를 채택하여 조직적으로 문제를 해결하세요.이는 대부분의 다른 생산 산업이 이미 실현하고 있는 성숙도 수준이며, 소프트웨어는 비참할 정도로 뒤쳐져 있습니다.

과도한 전문화 사이에서 핸드오프가 발생하는 개발 워크플로의 모든 위치에서 작업 대기열과 버퍼가 형성됩니다.소프트웨어는 이를 우리가 직면한 가장 큰 문제 중 하나로 인식하지 못하는 몇 안 되는 산업 중 하나로 남아 있습니다.Microsoft가 도구와 지침을 통해 과도한 전문화를 영속화함으로써 과도한 전문화가 점점 더 정상적인 것처럼 보이기 때문에 Microsoft 커뮤니티에서는 이러한 현상이 더욱 악화됩니다.개발 노력에 Microsoft만큼 많은 비용을 낭비할 여력이 없다면 흐름과 생산성 문제에 대해 훨씬 더 많은 정보를 얻을 수 있는 방법론을 찾아야 합니다.

결과적으로 테스트할 수 없는 개발자와 코딩할 수 없는 테스터는 동일한 산업적 미성숙의 증상입니다.

TFS용 Scrum 템플릿에서는 이에 대해 배울 수 없습니다.Microsoft는 가장 기본적인 형태에서도 민첩한 사고를 구현하는 데 수년 뒤쳐져 있었습니다. 이제 Lean 사고로 발전하고 있으므로 Microsoft는 Lean 사고를 제품 라인에 통합하려는 시도에서 3~5년 더 걸릴 것입니다. .Microsoft가 팀과 워크플로를 구성하는 방법을 알려줄 때까지 기다리지 마십시오.Microsoft가 몇 년 안에 궁극적으로 주목하게 될 사람들로부터 지금 당장 배울 수 있습니다.

내 경험에 따르면 (소규모) 팀의 모든 사람이 이 역할을 수행할 수 없는 한 통합자 또는 "개발자" 역할은 이 프로세스에 실제로 참여해야 합니다.이는 매우 드문 상황입니다.일반적으로 개발자는 개발에는 매우 능숙하지만 디자인/유용성에는 그다지 뛰어나지 않고, 디자이너는 미적/유용성에는 뛰어나지만 코딩을 원하지 않거나 코딩 교육을 충분히 받지 못한 경우가 많습니다.두 세계를 넘나들며 "언어를 구사"할 수 있는 사람을 갖는 것은 매우 중요합니다.

통합자는 설계자가 생성하는 설계 자산과 개발 중인 컨트롤을 조정해야 합니다.현재 프로젝트에는 6명의 활동적인 개발자와 2명의 외부 디자이너가 있습니다.저는 이 프로젝트의 통합자이며 하루의 대부분을 Expression Blend에서 보냅니다.개발자는 주로 VS에서 제품 사양을 충족하는 컨트롤을 만드는 작업을 수행하고 디자인 샵에서는 최종 제품의 모습을 디자인합니다.디자이너는 Illustrator에서 작업하고 있습니다.제가 맡은 일은 Illustrator 파일을 가져와서 컨트롤 스타일을 만든 다음 개발팀에서 개발한 컨트롤에 적용하는 것입니다.PSD 및 AI 파일에 대한 기본 지원을 갖춘 Blend 3으로 전환함에 따라 이 작업이 훨씬 쉬워졌습니다.

애플리케이션의 기본 트렁크와 별도의 솔루션에서 애플리케이션의 "모양"을 만든 다음 나중에 ResourceDictionaries를 기본 앱에 병합하는 것이 매우 유용합니다.여전히 불완전한 컨트롤에 너무 얽매이지 않고 올바른 모양과 느낌을 얻을 수 있습니다.

SL에 대한 언급 이후 RIA 프로젝트를 언급했다고 가정하겠습니다.

저는 Adobe와 함께 애플리케이션과 서비스를 설계하고 개발하는 꽤 많은 RIA 프로젝트를 수행했습니다.

여러분에 비하면 한심하지만 프로그래밍 경험도 있고 UX 및 비주얼 디자이너로서 14년간의 경험을 바탕으로 제가 드릴 수 있는 최고의 조언은 다음과 같습니다.

서로를 이해하지 못할 것이라는 사실을 받아들이십시오.

프로그래머는 생각한다 무엇 기능성이 완성되어야 한다, 디자이너는 이렇게 생각한다 어떻게 기능이 작동해야 합니다.

개발자에게 버튼은 대부분 일반적이지만 디자이너에게는 그렇지 않습니다.디자이너는 구성으로 생각하고, 개발자는 프레임워크로 생각합니다.

그러므로 귀하의 책임이 다르다는 것을 이해하는 법을 배우십시오.

개발자는 코드가 얼마나 일반적인지 생각해야 하며 모든 것을 고유하고 하드코딩된 구성으로 취급할 여력이 없습니다.그 고유성을 어떻게든 자동화할 수 없다면 말입니다.

디자이너는 애플리케이션이나 서비스가 어떻게든 독특하다고 생각해야 합니다.버튼이 버튼이 아니라는 뜻일 수도 있습니다.크기나 색상이 다르거나 기타 불편사항이 있을 수 있습니다.

그러므로 당신이 디자이너의 책임을 이해하고 디자이너도 당신의 책임을 이해하고 있음을 인정함으로써 디자이너와 좋은 관계를 발전시키십시오.

당신이 세계 최고의 애플리케이션을 만드는 데 관심이 없다는 것이 아닙니다.단지 이러한 디자인 결정 중 일부에는 상당한 시간이 걸립니다.

디자이너가 자신의 시간을 낭비하지 않도록 디자이너가 당신에게 어떻게 전달해야 하는지 명확히 이해해야 합니다.어떤 형식, 자산인가요?명명?

한 패러다임에서 다른 패러다임으로의 전달과 관련된 모든 것.

그리고 가장 중요한 것은 그들이 JavaScript를 수행하는 방법이나 CVS의 기본 아이디어를 이해하는 방법을 모른다는 점을 전달하고 존중하는 것입니다.

대부분의 개발자는 자신의 생명을 구하기 위해 커닝하는 방법, 미망인이 무엇인지, FireWorks를 가장 잘 레이어링하는 방법 또는 사실적인 아이콘을 만드는 방법, 좋은 태그라인을 제시하거나 Joe를 4단어로 평균화할 수 있는 내용을 만드는 방법을 알지 못할 것입니다.그리드나 정렬이 무엇인지 모르며 검은 바탕에 녹색과 보라색을 만드는 경향이 있습니다.

그리고 디자이너는 프로그래밍을 한다고 해서 로봇이 되는 것은 아니며 창의적인 아이디어와 솔루션을 가질 수 없다는 것을 이해해야 합니다.또한 그는 프로젝트를 만드는 데 관련된 내용을 이해할 수 있도록 최소한 의사 프로그램을 프로그래밍하는 방법을 배우려고 노력해야 합니다.

그리고 가장 중요한 것은.Mac과 Mac에 대해 논쟁을 시작하지 마십시오.PC :) 이로 인해 프로젝트가 취소되었습니다.

솔직히 당신은 디자이너에게 이미지가 할 수 있고 "소스 컨트롤 미스터에 넣을 것"이라고 말해야합니다. :)

약간 비관습적일 수 있으며 병합이나 그런 성격의 어떤 것도 수행할 수 없지만 개정 및 기록 등이 있을 것입니다.이미지는 소스 제어에 들어가는 리소스 파일에 포함될 수도 있습니다.

XAML은 소스 제어에 포함될 수 있고 있어야 하며 해당 마크업 파일로서 모든 기능의 이점을 누릴 수 있습니다.

디자이너와 함께 일하면서 얻은 팁에 관해서는, 당신과 함께 일하고 있는 디자이너가 그 말만으로도 겁이 나기 때문에 결국 당신과 함께 일하는 사람이 누구인지에 대한 이야기로 귀결될 수도 있습니다.기본적인 모범 사례를 친절하게 설명하고 거기서부터 진행하겠습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top