GUI 프로그래머는 다른 사람보다 부당한 이점이 있습니까?

관리자와 고객은 자신이 볼 수있는 것을 쉽게 이해할 수 있습니다.

나는 디자인 원칙이나 다른 프로그래밍 관용구에 대한 최소한의 지식을 가진 평균 프로그래머 인 많은 GUI 개발자들을 보았습니다. 그러나 프로그래머가 인상적인 사용자 인터페이스를 만들 수있는 경우 이러한 단점은 특히 관리 및 고객에 의해 눈에 띄지 않게됩니다. 내가 아는 많은 GUI 개발자들이 유지하기 어려운 나쁜 코드를 작성하는 대신 GUI를 아름답게하는 데 많은 시간을 할애하고 있습니다.

반면에, API 또는 비즈니스 기능 또는 데이터베이스 코드 (SQL 등)를 개발하는 중간 계층 프로그래머는 진열 할만한 것이 없기 때문에 단점이 있습니다. 코드 검토 자나 아키텍트는 코드의 우아함, 우수한 디자인, 확장 성 등을 높이 평가할 수 있지만 외부 세계에는 아무 의미가 없습니다. 코드는 몇 년 동안 중단되지 않고 유지 관리가 쉽고 성능이 뛰어나지 만 매끄러운 GUI 가하는 '와우'를 유발하지는 않습니다.

내 의견으로는, 이것에 대한 결론은 GUI 프로그래머가 좋은 깨끗한 코드를 작성하는 동기가 적다는 것입니다 (그리고 나는 이것을 위해 크게 하향 조정 될 것입니다).

편집 : GUI 프로그래머가 본격적인 웹 / GUI 디자이너가 아니라 프론트 엔드 프로그래머 (예 : 자바 스윙 프로그래머)를 의미한다고 설명해야합니다.

나머지 공동체는 동의합니까?

나는 당신의 요점을 본다고 생각하지만, 고려해야 할 반대의 문제가 있다고 생각합니다.

본질적으로 UI는 최종 사용자의 '면에서'응용 프로그램의 요소이기 때문에 UI 개발자는 팀 구성원이 앱의 더 깊은 계층에서 작업하는 것보다 더 높은 가시성을 누릴 수 있다고 제안합니다.

확실히 나는 더 높은 가시성이있을 수 있다는 데 동의합니다. 예를 들어 UI 요소를 다루는 개발자는 최종 사용자와 더 자주 상호 작용할 수 있습니다 (인간 / 컴퓨터 상호 작용 측면에 초점을두기 때문에 좋은 이유가있을 수 있습니다).

그러나 문제가있는 경우에도 더 높은 가시성이 작동한다고 생각합니다. 예를 들어 최종 사용자는 이슈가 아닌 경우에도 'GUI 이슈'로 이슈를보고 할 가능성이 높습니다.

그것은 모두 인식으로 귀결 될 수 있으며, 성숙한 조직은 작업하는 앱의 계층과는 별도로 다양한 팀 구성원의 가치, 미덕 및 약점을 인식 할 수 있어야합니다. 성숙한 조직은 'UI 개발자'및 '비즈니스 계층 개발자'와 같은 차이점을 뛰어 넘어 어쨌든 서로 다른 전문 지식을 가진 팀원임을 인정하지만 항상 해당 전문 분야에서 서로를 교육하려고 노력합니다.

프로그래머를 다루지 않는 사람에게는 이런 종류의 것들을 믿겠다 고 자신있게 말할 수 있습니다. 그들은 백그라운드에서 진행되는 작업량을 모릅니다. 버튼 / 텍스트 상자 / 메뉴 / [GUI 요소 삽입]과 버튼 시작을 달성하는 데 걸리는 속도 만 알 수 있습니다. 처음에는 GUI 사람들이 더 좋아합니다.

사람 이 프로그래머를 다루는 경우 약간 다릅니다. 말했듯이 확장 가능하고 유지 관리가 쉬워지고 알고리즘을 다시 작성하여 알고리즘이 더 합리적이거나 다른 유지 관리 유형 작업인지 알 수 있습니다. 이런 종류의 사람은 모든 프로그래머를 똑같이 바라 볼 것입니다.

중간에 그것은 당신의 행동에 달려 있습니다. 속도는 여기서 중요한 요소가됩니다. 양식을 처리하고 저장하는 데 걸리는 시간을 기록 전후에 표시 할 수 있고 개선 된 점이 있다면 동일합니다. 100 개의 클라이언트에서로드중인 앱을 표시하고 서버가 녹는 것을 표시 한 다음 모든 것이 정상인 버전을 표시하십시오. 기타.

요컨대, 그것은 사람과 당신의 행동에 달려 있습니다.

내 회사의 "UI 전문가"(디자인뿐만 아니라 모든 UI 개발을 담당하는 사람)로서 이야기의 일부를 놓치고 있다고 생각합니다. 나는 UI를 담당하는 사람이지만 백엔드, 데이터베이스 등에서 작업합니다. 모든 작업을 수행합니다 (우리는 소규모 팀입니다). [C # 및 ASP.Net WebForms 개발]

우선, 전문가가 아닌 사람들이 GUI 개발자의 작업을 이해하는 것이 훨씬 쉽습니다. 사람들이 직면하고 있기 때문입니다. 비 기술적 인 사람들에게 GUI는 응용 프로그램 입니다. 단점은 GUI가 무언가 잘못되었을 때 가장 먼저 비난 받는다는 것입니다.

둘째, 프론트 엔드를 개발하는 것이 백엔드보다 어려웠습니다 (불분명 한 / 복잡한 알고리즘 제외). 보호해야 할 것이 훨씬 더 많습니다. 상태 비 저장 (앱은 웹에 있음), 브라우저는 일관되게 작동하지 않습니다 (자바 스크립트 라이브러리는 신의 선물이었습니다). (ASP.Net WebForms)로 작업하고 앞으로 모든 어려운 문제는 문제가되지 않습니다.

전반적으로 백엔드 문제보다 UI 문제를 해결하기가 훨씬 더 어려웠습니다.

나는 두 가지 이유로 GUI 개발을 싫어한다.

1. 나는 그래픽 적으로 예술적인 것보다 더 논리적이며 내 UI는 항상 결과적으로 어려움을 겪습니다.
2. UI는 로직을 기반으로하지 않기 때문에 단위 테스트는 어떤 의미로도 작성이 불가능합니다.

그러나 하루가 끝나면 UI에 익숙한 평범한 개발자의 코드보다 최종 사용자가 (프로젝트 스폰서가 아닌) 최종 사용자가 내 코드를 더 잘 이해할 것이라고 생각합니다. .

@TheLQ의 답변을 약간 확장하려면 "시청자"도 달려 있다고 생각합니다.

프로그래밍 배경이없는 몇 가지 상위 관리자 / 감독자에 대한 경험이 있습니다. 어떤 사람들은 프로그래밍을하지 않았지만 크롬과 허브 캡이 엔진과 섀시만큼 중요하다는 것을 이해합니다.

그리고 UI 지글 지글 이외의 다른 메트릭스에 신경 쓰지 않는 일부 상위 관리자 / 감독자에게 경험이 있습니다. 더 많은 UI 지향 개발자가 중요하다고 말하는 것조차도.

IMHO, 우리는 당신이 똥을 연마 할 수 없으며 빠르고 안정적이지만 추악한 응용 프로그램은 외관이 좋고 기능이 우수한 응용 프로그램보다 훨씬 나빠질 것임을 알고 있습니다. 그것은 모두 보는 사람의 눈에 달려 있으며 어느 정도 당신은 당신이 원하는 것과 같은 자질을 위해 노력함으로써 당신이 원하는 빛에서 볼 수있는 힘을 가지고 있습니다.

편집 : 나는 더 낮은 수준의 항목에 대해 더 편안하게 느끼는 누군가가 될 수 있다고 UI 팀만큼 열심히 일할 때 지쳤으며 시스템에서 " 방금 일했다 " 그러나 내가 말했듯이, 감독관은 모든 분야에서 업무가 필요하다는 것을 알고 있습니다.

UI 개발자가 "주니어"개발자라는 일반적인 가정이 있다고 생각합니다. UI 담당자가 선임자로 간주되는 경우 한 가지 경우 만 생각할 수 있습니다.

즉, UI는 앱의 다른 부분보다 훨씬 어렵다고 생각합니다. 저는 UX 디자인에 대해 이야기하는 것이 아니라 코딩에 대해 이야기하고 있습니다. 수백 개가 아닌 수십 개 또는 가능한 시나리오를 설명해야하는 다른 영역은 몇 개입니까? 수십 가지 요소로 어떤 일이 발생해야하는지 파악해야 할 때 화면 크기를 조정하는 것만으로도 막대한 고통이 될 수 있습니다. 이는 "800x600을 지원해야합니다"라는 지침과 HD 해상도 이외의 다른 것을 사용하지 않는 UX 디자이너가있을 때 주로 나타납니다.

따라서 더 많은 노출로 인해 더 많은 선을 얻는다면 그럴만 한 가치가있을 것입니다. 일반적으로, 그들은 좋은 수신 쪽보다 잘못된 수신쪽에 더 자주 있습니다.

GUI 프로그래머가 프로그래머 체인의 맨 아래에 있다는 생각이 종종 있습니다. VS의 버튼을 양식에 끌어 놓기가 얼마나 어려울 수 있습니까? 그걸 프로그래밍하는데 일주일이 걸립니까? 막대를 그리고 있습니다. 따라서 GUI 프로그래머가 버튼 드래 거 인 것처럼 끔찍한 코드도 작성해야한다는 생각에 놀라지 않습니다.

GUI 프로그래밍에는 몇 가지 고유 한 문제가 있습니다. 데이터가로드되는 동안 GUI를 활성 상태로 유지하기위한 멀티 스레딩. 이것은 스레드 안전하고 적절한 코드로 이어집니다. 성능이 매우 중요합니다. 아무도 응용 프로그램을 다시 제어 할 때까지 2 분 정도 기다리는 것을 좋아하지 않습니다. 재사용도 큰 문제가됩니다. 비슷한 화면 10 개를 작성해야하는 경우 코드를 잘 구성하는 것이 좋습니다. 이것은 더 나은 코드로 이어집니다. 물론 좋은 GUI를 만드는 것은 그 자체로 어려운 일입니다.

그러나 일부 사람들에게는 버튼을 앱으로 드래그하기 만하면됩니다. 어떤 사람들에게는 비즈니스 로직이 "메시지를 파싱하여 DB에 넣는 것"에 지나지 않습니다.

그들이하는 것이 분명하다고 생각합니다. 아마도 최고 수준의 개발 주택은 면제되지만 다른 대부분은 그렇지 않습니다.

관리자가 지난 달에 수행 한 작업을 물어 보면 멋진 GUI를 쉽게 보여줄 수 있습니다. 멋진 API를 보여주기는 어렵습니다. 열심히. API의 차가움은 실제 사용을 통해서만 명백합니다. 한눈에 알아볼 수는 없습니다.

내부 시스템의 모든 종류의 해커 및 바로 가기를 피할 수 있습니다. GUI를 다룰 때 그 자유는 없습니다. 내부 API에 불일치가있을 수 있으며 너무 어렵 기 때문에 코더가 처리 할 것으로 기대합니다. 고객이 똑같은 일을하도록 시도 할 수 없습니다. 어떤 의미에서 사용자가 볼 수있는 컴포넌트를 다루어야하는 사람들은 실제로 더 높은 표준을 따라야합니다.

한 가지 간단한 이유 때문에 아이폰이라고 말할 것입니다. 내가 말했던 모든 사람들은 매끄러운 인터페이스 때문에 환상적이라고 생각하지만, 모든 것을 가능하게하는 작업은 상상할 수 있습니다.

청중에 따라 다릅니다. 나는 많은 재무 분석가들과 함께 일하며 좋은 GUI 디자인에 대한 아이디어는 한 양식에 걸릴 수있는 많은 분야를 가진 아이디어입니다. 진심으로, 나는 75-100을 이야기하고 있습니다. 그들은 항상 더 많은 것을 원하는 데이터 중독자입니다. 최근로드하는 데 45 초가 걸릴 수있는 몇 가지 저장 프로 시저의 성능을 개선했습니다 (시간이 시작된 이후의 가중 평균 계산). 30 초로 줄였습니다. 나는 시간의 3 분의 1을 잘라 내고있다. 이력서의 광고 항목이어야합니다. 아무도 눈치 채지 못했습니다. 그 일을 계속하고 15-20으로했습니다. 눈에 띄는 변화. 모두 매우 행복했습니다. 나는 여전히 GUI가 가증하다고 생각하고 우리가 쓸모없는 쓰레기를 꺼내면 2 초 안에로드 될 것이다.

따라서 사용자가 당신을 정말로 사랑하기를 원한다면 최고의 사용자 인터페이스는 전혀 인터페이스가 아니라는 것을 기억하십시오 (누가 내가 그 말을했는지 기억합니다). 이 모든 데이터를보고자했던 분석가들은 모든 데이터 입력을 수행하는 사람이라는 것을 깨달았습니다.

응용 프로그램의 UI 부분을 테스트하는 것은 악몽입니다.

주변의 모든 사람들은 조언을하거나 어떻게해야하는지 요구할 능력이 있다고 생각합니다.

시스템이 제대로 작동하면 나중에 누군가가 그 미덕을 누가 실수로 떠올리더라도 아무도 누가 무엇을했는지 기억하지 못할 것입니다.

그러나 어떤 오류가 발생하면 ( 일부는 항상 발생), 첫 번째로 유죄 판결을받은 사람은 GUI 프로그래머가 될 것입니다. 사용자는 다른 사람을 본 적이 없습니다!