일부 프로그래머가 개발의 UI 부분을 싫어하는 이유는 무엇입니까? [닫은]

내가 만난 많은 프로그래머들은 항상 "그는 UI 사람이 아닙니다"라고 말합니다. 사실 오늘날 웹, Windows, Linux, OSX 또는 다른 유형의 개발에 관계없이 개발은 이제 잘 생긴 UI를 갖춘 소프트웨어로 구성됩니다. 왜 그렇게 많은 개발자들이 UI 작업을 좋아하지 않는 것 같습니까?

나는 UI 사람도 아닙니다. 글쎄, 나는 내 자신의 프로젝트에서 UI를 수행하지만 직장에서 나는 그것과 아무런 관련이 없습니다. 내 작업은 프론트 엔드가 아닌 앱의 용기에 있습니다.

그 외에도 나는 그것이 증오보다 더 지루하다고 생각합니다. UI 디자인은 어렵고 어려운 부분입니다. 구현은 대부분 거친 작업입니다. 사용자 인터페이스를 구현하는 방법에는 거의 도전이나 혁신이 없으며, 약간의 정신을 가지기 전에 화면에 확인란을 넣을 수있는 횟수는 매우 많습니다. 픽셀을 "정확히"정렬하는 데 시간을 소비하지도 않습니다.

좋은 UI를 만들려면 백엔드 코드를 작성하는 것보다 많은 기술이 필요합니다.

백엔드 요구 사항은 일반적으로 블랙 박스처럼 지정할 수 있으며 x는 들어오고 y는 나올 것으로 예상됩니다. 작동하게하려면 논리를 구현해야하며 작동하는지 또는 작동하지 않는지 프로그래밍 방식으로 테스트 할 수 있습니다.

좋은 UI를 만들려면 사용성, 시각적 디자인, 레이아웃 및 색 구성표와 같은 것들을 고려해야합니다. 여기에는 약간의 예술적 창의력이있는 것이 보너스이며, 많은 프로그래머들은 자신이 이것을 가지고 있다고 느끼지 않습니다. 논리적 인 두뇌에는 UI 문제에 대한 해결책이 정답이 없거나 '올바르게'수행되었는지를 쉽게 확인할 수있는 방법이 없기 때문에 주관적으로 보일 수 있습니다.

UI 경험이 많지 않거나 많은 연구를하지 않은 많은 프로그래머는 유용성 관점과 디자인 측면 (예 : 색상)에서 좋은 UI 디자인 뒤에 규칙과 과학이 있다는 것을 깨닫지 못합니다. 이론).

물론, 일부 프로그래머는이 부분에 문제가 없지만 많은 UI가 코드에 지루하기 때문에 싫어합니다. 그것들은 기능적 일 필요가 있고 설계상의 어려움이없는 관리자 페이지의 양식 페이지와 같은 많은 반복적 인 작업으로 구성 될 수 있습니다.

사람들은 다른 관심사를 가지고 있습니다. 일부 프로그래머는 데이터 구조 및 알고리즘, 아키텍처, 유용성 및 UI 디자인 또는 이들과 다른 틈새의 조합에 더 관심이 있습니다. 그들은 각각 다른 기술과 문제에 대한 다른 사고 방식을 요구합니다. 프로그래밍의 저수준 너트를 좋아한다면 사용자의 생각에 크게 신경 쓰지 않을 수도 있고 그 반대도 마찬가지입니다.

개인적으로 나는 후자의 캠프에 빠진다. 복잡한 알고리즘보다 UI를 디자인하는 것이 훨씬 낫다. 내가 흥미로워하는 것은 단지 종류입니다.

주어진 UI 디자인이 좋은지 나쁜지는 상당히 주관적 입니다. 프로그래머들은 일반적으로 매력적이지 않다고 생각합니다. 좋은 UI 기술을 수량화하고 검증하기위한 수십 년의 노력으로 적용 할 수있는 광범위한 규칙을 만들 수 있었지만, UI가 좋은지 여부를 실제로 판단하지 못하는 경우에는 많은 A / B 테스트 및 기타 사용자 관찰이 필요합니다. 기법.

프로그래밍에는 분명한 주관성이 있지만 일반적으로 실행 속도, 메모리 요구 사항, 미래의 요구를 충족시킬 수있는 유연성,보다 효과적인 것으로 입증 된 사례 중 하나를 선택하는 것이 객관적인 이유를 가리킬 수 있습니다. 주어진 UI 선택을 방어하고 심지어 선택 자체를 결정하는 것은 일반적으로 지원하기위한 완전히 다른 종류의 주장 인 "I like it"으로 저하됩니다.

나는 개인적으로 UI 개발을 좋아하지 않기 때문에 즐기지 않습니다. 이해하기에는 좋지 않은 사용자 심리학의 거대한 요소가 있습니다. 내 가장 큰 문제는 내가 자신의 신발에 넣을 수 없다는 것입니다. 나는 사용자에게 직관적 인 것을 모르거나, 일을 예쁘게 만드는 법을 모르기 때문에 직관적 인 레이아웃을 만드는 방법을 크게 모른다.

필자는 일부 프로그래머가 UI 디자인을 싫어하는 것이 자신이 좋지 않은 일을하는 것을 싫어한다고 생각하지는 않는다. UI 개발에 능숙하지 않은 개발자가 많이 있습니다.

UI 디자인의 문제는 모든 사람이 의견을 가지고 있다는 것입니다. 옳고 그른 대답은 없습니다. 반면 개발자는 흑백과 논리를 좋아합니다. 모든 규모의 회사에서 모든 사람들이 동의 할 1+1=2것이지만, 어느 글꼴이 가장 읽기 쉬운 지 물어보십시오 (Comic Sans Obviously)... 홍수에 대비하십시오. 모든 사람이 다르기 때문에 만 다른 답변과 모든 사람이 옳습니다.

실제로 UI 작업을 즐기는 개발자 (특히 웹 디자인에 대한 공평한 분배를 했음)로서, 기술을 갖추지 못한 사람이 UI를 사용하지 않을 때 감사합니다.

개발에는 많은 데이터를 보유하고 한 번에 많은 데이터를 처리 할 수있는 기능이 필요합니다. UI 디자인에는 무결성을 유지하면서 최소한으로 끓일 수있는 기능이 필요합니다. 나는 그 도전을 좋아 합니다. 누군가 화면에서 관리 할 수없는 wall-o-data 인 UI를 만드는 것을 보았을 때 울었습니다. (배치, 색상 이론 등에 관해서도 총 괴짜입니다.)

반면에, 나는 저수준 물건을 싫어 합니다. 드라이버, 커널 또는 그와 비슷한 코드는 절대 만지지 않을 것입니다 : shudder : "UI가 아닌 사람들"에게 맡기고 다른 누군가가 그것을 즐기거나 행복하지 않을 것입니다.

나는 그것이 대부분의 프로그래머가 뇌의 왼쪽 부분을 사용한다고 생각합니다.

이 주제를 더 읽을 수 있는 좋은 자료 입니다.

잘못된 사람들로부터 너무 많은 정보를 받기 때문에 UI 개발이 복잡해집니다. 그들은 모두 그래픽 디자인 전문가입니다. 그들은 당신이 무언가에 대한 공식을 알고 싶을 때 찾을 수있는 곳이 없습니다.

그들은 자신이 원하는 것을 알지 못하지만 그것을 볼 때 맛이 없으며 결정력이있는 사람들은 응용 프로그램을 사용하지 않지만 녹색이어야한다고 확신합니다. 양식에서 필드의 수를 제한하는 등 좋은 UI에 대한 지침을 따르고 필드를 모두 '필요'하고 별도의 탭에 배치하기 때문에 50 개의 필드를 추가하라는 요청이 너무 많습니다. Excel과 동일합니다. 농민!

당신은 이것을 만들 수 없습니다. 나는 한 법률 회사의 회계 부서에서 최고 두 사람 (약 500K / 연봉)이 변호사가 사용한 청구 웹 사이트 페이지의 라벨을 반박하는 데 30 분을 소비 한 회의에 앉아있었습니다. 이것은 변호사들이 이해하기 쉽도록 만들어졌다. 왜 변호사에게 물어 보지 않겠습니까? 너무 쉽다. 따라서 IT 부서는 WTF "잔여 순 청구 금액"이 무엇인지 알고 싶어하는 변호사로부터 50 번의 전화 통화를하게되며 그 이유는 시간 입력 양식에 있습니다.

브로콜리를 좋아하는 사람도 있고 그렇지 않은 사람도 있습니다. 우리는 그것을 먹어야 할 수도 있지만 그것을 좋아할 필요는 없으며 먹을 때 그것을 즐기지 않을 것입니다. 뿐만 아니라 가능한 한 많이 먹지 않아도됩니다.

UI 외에도 코딩해야 할 것들이 많이 있습니다. 웹 서비스, Windows 서비스, 전자 레인지의 UI는 많지 않음.

UI를 그리는 데 도움이되는 도구가 빨대를 통해 죽은 아기 원숭이를 빨기 때문일 수도 있습니다.

UI 개발에는 이해하기 어려운 것들이 있습니다.

레이아웃 중 하나입니다. 저는 15 년 넘게 UI를 개발해 왔지만 아직 레이아웃 관리에 대한 적절한 솔루션은 없었습니다.

또 다른 하나는 이벤트 라우팅입니다. MVP 아키텍처와 프레임 워크에서 요구하는 사항이 있더라도 대부분의 복잡한 UI에는 이벤트 라우팅 문제가 있다고 주장 할 수 있습니다. 테스트 프레임 워크 중 하나라도 제대로 해결할 수 있으면 발견 될 수 있습니다.

나는 매우 지루하고 느리다는 것을 알았 기 때문에 UI dev를 싫어했던 것을 알고 있습니다. 특히 레이아웃 코드를 작성하여 양식이나 창에 물건을 배치합니다. 이제 Visual Studio의 Forms Designer와 같은 UI 디자이너 도구를 사용하면 거의 즐길 수 있습니다. 내가 다른 사람들로부터 들었던 다른 이유는 "멍청하다", "항상 너무 많이 변한다", "충분히 도전하지 않는다", "지루하고 지루하다"등이다.

모든 체스 플레이어가 체스 판 디자인과 함께 플레이하는 것을 좋아하지 않는 이유는 무엇입니까?

어떤 사람들이 그것을 좋아하지 않는 것은 이상하지 않습니다 ... 우리가 기대 해야하는 것은 이상합니다.

UI 작업을 좋아합니다. 그것이 항상 나에게 해당되는 것은 아니지만, 지난 몇 년간 UI 작업이 향상되면서 UI 작업에 대한 즐거움이 높아졌습니다. 일부 개발자는 스타일 시트 또는 색상 팔레트 근처에서 허용해서는 안된다는 것을 알고 있습니다. 확실히 다른 스킬 셋이며 모든 사람이 가지고있는 것은 아닙니다.

UI 프레임 워크를 싫어하는 것만 큼 UI 작업을 싫어하는 것은 아닙니다. 예를 들어 .NET을 10 년 이상 프로그래밍했습니다. 웹 응용 프로그램을 만들기위한 프레임 워크는 훌륭합니다 (ASP.NET WebForms 및 ASP.NET MVC). 그러나 데스크톱 응용 프로그램을 작성하기위한 프레임 워크는 좋아하지 않습니다 (WinForms 및 WPF).

따라서 이와 관련하여 GUI 응용 프로그램 작성은 내가 싫어하는 프레임 워크 사용의 한 측면입니다.

또 다른 측면이 있습니다. 저는 종종 "엔터프라이즈"스타일의 응용 프로그램, 즉 데스크톱 응용 프로그램이 서버에서 데이터를 받아야하는 응용 프로그램을 사용합니다. 이 경우 한 형식에서 다른 형식으로 데이터를 변환하는 계층이 너무 많아서 실제로 지루합니다.

예를 들어 응용 프로그램은 일련의 DTO 개체를 통해 정보를받습니다. 그런 다음 응용 프로그램은 서버에서 만든 동일한 도메인 클래스를 재사용하지 않고 데이터의 자체 모델 표현을 만듭니다. 모델 클래스는 모델의 속성을 노출하는 뷰 모델 (WPF MVVM 패턴)에 사용됩니다.

같은 데이터가 다른 클래스로 표현되는 경우가 많습니다. 그리고 그것은 지루해집니다. 그러나 이것은이 유형의 데스크톱 응용 프로그램에 특정한 문제입니다.

이 유형의 응용 프로그램에는 한 클라이언트에서 다른 클라이언트로 즉시 업데이트하기 위해 변경 사항을 얻는 방법과 같은 흥미로운 문제가 있습니다.

나는 이런 이유로 UI 개발을 좋아하지 않습니다.

1. 개발자는 자유롭게 만들 수있는 자유가 줄어 듭니다. 고객은 반응해야하는 UI의 모든 작은 부분을보고 의견을 가질 수 있습니다. 다음과 같은 요청이 나타납니다. 그 버튼을 거기로 옮기십시오. 신경 쓰지 말고 다시 옮기십시오. 백엔드 코드는 거의 보이지 않습니다.

2. 백엔드가 더 "플라톤"인 반면 UI는 더 지저분합니다. 백엔드 코드의 추악한 혼란을 보았지만 UI 코드보다 깨끗하게 (코드 관점에서) 더 일반적이라고 생각합니다. UI는 실제로 깔끔하고 사용자를 위해 잘 설계 될 수 있지만 개발자이기 때문에 개발자보다 코드에 더 많은 시간을 소비하므로 코드를 정리하는 데 더 큰 관심을 기울입니다.

3. UI가 백엔드보다 "배관"에 가깝다고 생각합니다. 즉, 영리한 알고리즘에 대한 기회가 적고 실제로 두뇌를 한계까지 밀고 있습니다.

나는 UI (웹이 아닌 데스크탑)와 내부 내장을 모두 수행합니다.

내가 좋아하거나 싫어하는 양은 DSL (Domain-Specific-language)과 같은 것을 사용하여 얼마나 많은 양을 할 수 있는지에 달려 있습니다.

UI 도메인에서 사용자에게 제공하는 정보와 사용자가 얻는 정보의 복잡성은 양식 디자이너, 많은 이벤트 핸들러, MVC와 같은 일반적인 도구를 사용해야하는 경우 미쳐 버릴 수 있습니다. 모든 "최신 상태"의 것들. 고맙게도, 수십 년 전에 저는 더 나은 방법이라고 생각하는 것을 발견했습니다. 그것이 DSL을 만들어서 작동시키는 것입니다. 현재는 Dynamic Dialogs라고하며, Differential Execution 이라고하는 제어 구조를 기반으로합니다 . 좋은 소식은 주어진 기능에 대해 소스 코드가 대략 10 배나 작아 UI에 더 많은 기능을 넣을 수 있다는 것입니다. 나쁜 소식은, 제가 가르치려고했던만큼 기술을 옮기는 데는 운이 없었습니다.

UI가 아닌 도메인에서 UI를 접목 한 명령 줄에서 사용할 수있는 DSL로 시작한 많은 제품에서 교훈을 얻었습니다. 이는 전문가에게 UI를 우회 할 수있는 것을 제공하는 반면, 일반 사용자에게는 부담없이 사용할 수있는 것을 제공합니다. (예 : R, SPlus, Matlab, SAS, WinBugs) 따라서 당사 제품 에는 전문가를위한 명령 줄 언어가 있습니다. 파서, 코드 생성기, 프리 컴파일러 및 런타임 모델링 엔진을 사용하여 이러한 것들을 개발하는 것을 좋아합니다. 그에 대한 노력은 UI에 대한 노력보다 최소한 10의 힘입니다.

UI 노력이 많은 이유 중 하나는 DSL로는 할 수없는 "접착제"가 여전히 많기 때문입니다. 데이터 그리드 관리, 모든 종류의 데이터 정렬 방법, 하품 "균열"에 빠지는 모든 것 순수한 UI와 기초 언어 사이.

그래서 당신의 질문은 "왜 일부 프로그래머들은 개발의 UI 부분을 싫어합니까?"입니다. DSL이없는 "접착제"때문에 나는 그것을 싫어한다.

솔직히 나는 최고의 GUI 툴킷을 찾은 다음 실제로 그 기능을 배우는 것이 PITA라는 것을 알았습니다. 대학에서 UI를 많이 배우지 않고 초보자 인 것을 언급하지 않는 것은 말할 것도 없습니다. ..

이미 언급 한 것 (코드를 작성하는 것은 지루하고 지루하며 좌절 한 일이며 디자인은 일반적으로 아이디어를 구현하려는 사람들에게 어떤 문제가 발생했는지에 대한 단서가없는 사람이 먼저 수행함)보다 중요한 요소는 백엔드보다 훨씬 더 많은 변화를 가져야한다는 아이디어를 가진 사람들과 협력해야합니다. 결과적으로, 당신은 움직이는 스펙에 대해 더 많이 촬영하고 있으며,이 사람들은 또한 nitpickers 경향이 있습니다. 구성 요소가 테스트 대상자가 생각했던 위치에서 1 픽셀 떨어져 있기 때문에 문자 그대로 사용자 인터페이스에서 테스트에 실패했습니다. 작동 했습니까? 예. 좋았어? 예. 그러나 그는 픽셀 수를 계산하기 시작했고 나머지는 다른 픽셀과 일치하지 않는 단일 픽셀이므로 재 작업을 위해 다시 보냈습니다.

몇 가지 더 포인트 :

1) UI 디자인은 테스트하기가 더 어려울 수 있습니다. 버튼이 제대로 작동하는지 확인할 수 있지만 사용하기 쉬운 지 테스트하는 것이 더 어렵습니다. 장애가있는 사람과 함께 사용할 수 있는지 테스트하는 것은 어떻습니까?

2) 많은 프로그래머들이 훈련을받지 않았으며 그것에 대해 잘 모릅니다.

사실 많은 UI 도구 / 프레임 워크 / API가 나쁘고 복잡하며 직관적으로 멀리 있습니다. C / C ++의 Win32 API로 javax.swing, CSS 등을 사용하여 개발 했으므로 UI ​​개발을 다루지 않아야합니다 ... Qt 프레임 워크까지!

CS 학생은 UI를 제외하고 데이터 구조, 데이터베이스, C ++ 등을 배우게됩니다. 따라서 처음부터 잘하지 못할 것 입니다. 당신이 그것을 잘하지 않으면, 당신은 그것을 싫어합니다.

코인, UI 디자인 및 백엔드 코드의 양면에서 작업 한 결과, 코인의 양면이 기본적으로 동일한 것으로 나타났습니다.

일상적인 것과 다른 요구 사항은 항상 오지 않으며 현재 모든 서비스가 CRUD를 중심으로 돌아가는 시대에 지루해집니다.

어쨌든 프론트 엔드를 코딩하면 기본적으로 프론트 엔드 디자인에 경험이없는 손을 조이는 더 나은 상호 작용과 미친 역 동성이 가능합니다. 저는 개인적으로 프론트 엔드에서 어려운 방법을 배웠으며 프론트 엔드 디자인이 훨씬 흥미롭고 도전적이라고 편안하게 말할 수 있습니다.