CLI 앱 개발이 "뒤로"간주됩니까? [닫은]

저는 프로그래밍 경험이 많은 DBA입니다.

매일 반복되는 작업을 해결하거나 더 복잡한 작업으로 인한 인적 오류를 제거하는 몇 가지 CLI 비 대화식 앱을 개발했습니다. 이 도구는 이제 도구 상자의 일부입니다.

CLI 앱은 자동화 된 워크 플로우에 포함시킬 수 있기 때문에 훌륭합니다.

또한 하나의 일을하지만 잘하는 프로세스의 결과를 다른 일의 입력으로 만드는 유닉스 철학은 전략적 이점으로 통합되는 것보다 도구 세트를 구축하는 좋은 방법입니다.

내 상사는 최근 CLI 도구 개발이 "뒤로"또는 "회귀"라고 언급했습니다.

현재 존재하는 대부분의 CLI 도구는 레거시가 아니라 개선 된 버전이 항상 공개되는 라이브 프로젝트이기 때문에 이에 동의하지 않는다고 말했습니다.

이런 종류의 개발은 시장에서 "뒤로"고려됩니까?

이력서에 나쁘게 보입니까?

또한 웹이든 데스크탑이든 상관없이 모든 솔루션을 고려하여 비 대화식 명령 줄 명령 줄이 있어야합니다. 어떤 사람들은 이것을 프로그래밍 자원의 낭비라고 생각합니다.

이 목표는 소프트웨어 프로젝트에서 가치있는 목표입니까?

또한 웹 또는 데스크톱 앱의 경우 대체 CLI 인터페이스를 갖는 것이 비즈니스 로직이 GUI에서 완전히 분리되었음을 보여주는 좋은 방법이라고 생각합니다.

CLI를 사용하여 작업 할 수있는 능력은 내가 거꾸로 생각하는 것이 아닙니다. 이력서에서는 특히 "데이터베이스가 다운되었을 때 SMS 메시지를 보내는 자동화 도구 모음을 작성하는 데 사용됨 (Powershell / Bash)"과 같은 문구를 사용하여 이력서에서 이력서를 회전시킬 수 있다면 더욱 좋습니다.

사람들을 고용 할 책임이있을 때 CLI에 대한 실무 지식은 내가 찾는 것입니다.

기본적으로 "작업에 적합한 도구를 사용하십시오".

사용자와 상호 작용해야하는 경우 일종의 GUI가 필요합니다. 우리는 컴퓨팅을 훨씬 직관적이고 생산적으로 만든다는 것을 보여주는 수십 년의 연구와 경험을 가지고 있습니다. 이것이 바로 GUI가 1984 년 이래로 전 세계를 점령 한 이유입니다. 사람들과의 상호 작용에 더 효과적입니다.

그러나 스크립트를 사용하여 프로그램을 자동화하는 경우 프로그램은 사람들과 상호 작용하지 않습니다. 스크립트와 상호 작용하고 있습니다. 그에 대한 가장 좋은 인터페이스는 텍스트 기반 인터페이스이며 직관적으로 명백해야합니다.

사용자가 직접 작업 할 수있는 CLI 프로그램의 개발은 역전 된 것으로 간주됩니다. 그러나 이것이 당신이하고 있지 않은 경우, 자동화 생산성 도구를 작성하는 경우 CLI를 제공함으로써 아무런 문제가 없습니다.

Eric Raymond의 The Art of Unix Programming 은 당신이 만들고있는 논쟁에 대한 정식 작업입니다. 나는 그의 훌륭한 책을 몇 문단으로 정리하려고하지 않을 것이다. 그러나 논쟁은 대부분 프로그래머, 스크립팅을 사용하여 작업을 자동화하는 관리자 또는 CAD와 같은 첨단 기술 소프트웨어의 고급 사용자에게 적용됩니다.

고도로 기술적 인 사용자라도 당시 착용하고있는 모자를 고려해야합니다. 예를 들어, 저는 생활을위한 네트워킹 장비를위한 내장 소프트웨어를 작성합니다. 우리 제품에는 모두 CLI와 GUI가 있지만 개발자는 유연성, 스크립팅 가능성, 가용성, 속도 등으로 인해 CLI를 거의 보편적으로 선호합니다.

그러나 동일한 개발자 그룹이 CLI가 더 강력하고 GUI뿐만 아니라 지원 및 문서화 되어도 버전 관리 소프트웨어의 GUI를 압도적으로 선호합니다. 차이점은 우리가 관리자 나 개발자가 아닌 버전 관리 소프트웨어의 최종 사용자라는 것입니다.

따라서 유틸리티를 사용할 때 사용자의 역할을 신중하게 고려하고 이에 따라 사용자 인터페이스를 계획하십시오. 상사가 언급하는 경우 최소한 CLI에 대한 설명서 및 / 또는 교육을 개선해야 할 가능성이 있습니다. 사람들에게 GUI에 대한 기능을 기대할 때 CLI에서만 사용할 수있는 기능을 지속적으로 알려주는 경우 사용자의 요구를 더 잘 고려하여 개발 우선 순위를 재고해야합니다.

커맨드 라인 프로그램에 의해 구동되는 것은 유닉스 만이 아닙니다. 마이크로 소프트도 그렇게 나아가고있다.

Microsoft는 얼마 동안 PowerShell을 추진하고 있습니다. 현재 서버 소프트웨어 (Exchange, SharePoint, Server 2012, System Center 등)는 PowerShell 명령 줄을 통해 완전히 제어 할 수 있습니다. 그리고 PowerShell은 한 가지 기능을 수행하고 다음 기능으로 데이터를 파이프하는 작은 기능을 사용합니다 (단지 텍스트 대신 개체를 파이프하지만).

해당 프로그램에 대한 대부분의 GUI는 단순히 PowerShell 명령에 대한 프론트 엔드이며, 스크립트 작성을보다 쉽게하기 위해 어떤 명령을 실행할지 알려줍니다. PowerShell에서 수행 할 수있는 GUI에서 수행 할 수있는 모든 작업 그 반대는 사실이 아닙니다. PowerShell에만 노출되는 기능이 상당히 많습니다.

* nix가 항상 그렇게한다면, Microsoft는 그런 식으로 가고 있습니다.

나는 그것이 나쁜 것이라고 분명히 말하지 않을 것입니다. CLI 프로그램의 좋은 점은이를 구현할 때 매우 제한된 범위를 가질 수 있다는 것입니다. 예를 들어, cat복제본이나 "파일의 내용을 화면에 인쇄하는 프로그램" 을 작성하려는 경우 CLI를 사용하면 가능합니다.

그러나 CLI를 사용하지 않으면 텍스트를 표시하는 GUI가있는 기본 프로그램이 있습니다. 그러나 파일 대화 상자를 열고 연결해야 할 필요가 있습니다. 그러나 누군가는 텍스트를 수정하고 다른 곳에 저장할 수 있기를 원합니다.

스코프 크리프는 GUI 앱으로 말도 안됩니다. CLI 앱을 사용하면 피하는 것이 매우 쉽습니다. "파일을 편집 한 후 다시 저장하고 싶습니까? cat foo > ed > bar"CLI 응용 프로그램을 사용하면 사용자 (개발자가 아닌)가 다른 도구와 파일을 결합하는 것이 쉽지 않습니다.

이제 CLI 프로그램이 "뒤로"시작되고 있습니다. 요즘 도구를 다른 도구와 결합하는 사용자가 불가능한 시장에서 많은 응용 프로그램 개발이 이루어지기 때문입니다. 여기서는 다루지 않겠지 만, "마켓 플레이스가 비 마스터 정신을 강화하는 방법"에 대한 블로그 게시물을 작성했습니다 . 이는 잘 설계된 CLI 앱과 완전히 반대입니다 (한 가지 일을하고 잘 수행하는 것). )

GUI와 CLI는 모두 그 자리에 있습니다. GUI는 사용자가 특정 미리 준비된 작업을 빠르게 수행 할 수 있도록하는 데 유용합니다. CLI는 GUI에서 허용하지 않는 작업을 수행하려는 경우를위한 것입니다. CLI는 일반적으로 더 강력하고 사용하기 어렵습니다.

좋은의 CLI 도구는 사용자가 도구를 쓴 사람이 생각하지 못할 일을 할 수 있습니다. 한 가지 예는 UNIX 'find'명령입니다. 이 명령은

find . -type f -name xyzzy\* -maxdepth 5 -mtime +3 -exec rm {} \;

현재 디렉토리에서 이름이 'xyzzy'로 시작하고 3 일 전에 수정 된 파일을 찾은 다음 삭제합니다 (주 : 테스트되지 않은 코드). 그리고 그것은 적당히 간단한 사용법입니다. 파일 관리자를 사용하여 이러한 종류의 작업을 수행 할 수 있지만 시간이 오래 걸리고 오류가 발생하기 쉽습니다. 물론 더 강력하다는 것은 CLI를보다 쉽게 ​​오용하고 스스로 문제를 일으킬 수 있음을 의미합니다!

능숙한 개발자는 제한된 작업 세트를 수행 할 수있는 GUI도 제공하는 방식으로 CLI 도구를 작성할 수 있습니다. 사용자는 GUI로 시작하여 나중에 CLI의 복잡성을 배울 수 있습니다.

CLI / GUI 트레이드 오프에서 좋은 (길고 편향된 (?)) 읽기는 다음과 같습니다.

http://www.cryptonomicon.com/beginning.html

아니요, 전혀 거꾸로되지 않습니다.

"방향"은 우리의 관점과 관련이 있습니다. 단순한 "모든 장치를 경험하십시오"인터페이스에 대한 현재 경로에 만족하는 사용자는 CLI를 후퇴 또는 회귀로 볼 것입니다. 전반적인 기대치와 일치하지 않습니다.

프로그래머, 관리자 또는 고급 사용자는 경험에 따라 도구의 논리적 진행으로 볼 수 있습니다. 이들 중 다수는 GUI 도구를 사용하여 시작합니다. 확장을 원하거나 확장해야하는 경우 CLI가 존재하는 이유를 신속하게 파악하고 더 많은 CLI 도구를 작성하는 프로세스와 함께 진행이 공진합니다.

폴 페리스 (Paul Ferris)의 사례 : http://www.linuxplanet.com/linuxplanet/opinions/1505/1

개인적으로 신택스 아이디어는이 둘을 차별화합니다. GUI에 구문이 어느 정도 존재하는 경우 CLI 구문을 생각할 때와 마찬가지로 결과가 거의 우수하고 유연합니다. 이것이 파이프 및 리디렉션과 결합되면 GUI는 계획된 사용 사례 외부에서는 그다지 유용하지 않기 때문에 평평 해집니다.

이것에 대한 개인적인 선호는 GUI 래퍼가 상태 표시 줄과 사람들이 GUI를 찾는 다른 기본 요소를 포함하여 강력한 방식으로 상호 작용할 수있을 정도로 충분한 --gui 또는 --verbose 옵션을 제공하는 CLI 도구입니다.

물론 이것의 비용은 본질적으로 하나는 다른 것없이 쓸모없는 두 개의 프로그램이지만, 주요 이점은 CLI 도구를 수정하지 않고 하나 이상의 훌륭한 CLI 도구를 사용자 정의 GUI에 통합 할 수 있다는 것입니다. 대부분의 경우 이는 특정 CLI에서 GUI 옵션을 제공하기 위해서만 수행되지만 "프로세스"또는 "사용 사례"지향 GUI로 여러 도구를 구동한다는 아이디어는 해당 사용 사례에 대한 파이핑 및 리디렉션 및 스크립팅과 유사한 결과를 제공 할 수 있습니다. CLI 사용자를 방해하지 않으면서도 정기적으로 숙달 할 수있을만큼 정기적으로 이러한 작업을 수행하지 않는 사람들이 사용할 수 있습니다.

나는 SGI IRIX 에서이 접근법을 만났고 실제로 그것을 좋아했습니다. 필요에 따라 GUI 또는 명령 줄을 사용하는 것을 발견했으며 멋진 버튼이 실제로 무엇을하는지 정확히 알고있었습니다.

서로 다른 운영 환경이 많은 경우 GUI 래퍼는 CLI 도구에 영향을주지 않고 상당히 다를 수 있습니다.

나는 오늘날 리눅스에서 디스크 / 파일 시스템 도구와 같은 것들을보고있다. GUI는 CLI 사용자들에게도 많은 가치를 추가 할 수있다.

알려진 파일 시스템 / 디스크 / 장치의 경우 CLI를 중단하는 것은 어렵지 않으며 물론 스크립팅 할 수 있습니다. 그러나 실수는 고통 스러울 수 있습니다.

잘 알려지지 않았거나 작업 수행이 정기적으로 수행되지 않고 오류가없는 상태로 유지되는 경우 GUI를 실행하면 쉽게 확인할 수 있고 작업을 체인으로 묶은 다음 안심하고 실행할 수있는 환경이 제공됩니다 (스크립트 필요 없음).