Sự phát triển của các ứng dụng CLI có được coi là lạc hậu không? [đóng cửa]

Tôi là một DBA non trẻ với nhiều kinh nghiệm trong lập trình.

Tôi đã phát triển một số CLI, các ứng dụng không tương tác để giải quyết một số tác vụ lặp đi lặp lại hàng ngày hoặc loại bỏ lỗi của con người khỏi các nhiệm vụ hàng ngày phức tạp hơn. Những công cụ này bây giờ là một phần của hộp công cụ của chúng tôi.

Tôi thấy các ứng dụng CLI rất tuyệt vời vì bạn có thể đưa chúng vào quy trình làm việc tự động.

Ngoài ra, triết lý Unix là làm một việc duy nhất nhưng làm tốt và để đầu ra của một quy trình là đầu vào của một quy trình khác, là một cách tuyệt vời để xây dựng một bộ công cụ hơn là hợp nhất thành một lợi thế chiến lược.

Ông chủ của tôi gần đây đã nhận xét rằng việc phát triển các công cụ CLI là "lạc hậu" hoặc tạo thành một "hồi quy".

Tôi nói với anh ấy rằng tôi không đồng ý, vì hầu hết các công cụ CLI tồn tại bây giờ không phải là di sản mà là các dự án trực tiếp với các phiên bản cải tiến được phát hành mọi lúc.

Đây có phải là loại phát triển được coi là "lạc hậu" trên thị trường?

Nó có vẻ xấu trên một rèsumè?

Tôi cũng đã xem xét tất cả các giải pháp cho dù chúng là web hay máy tính để bàn, nên có dòng lệnh, tùy chọn không tương tác. Một số người coi đây là một sự lãng phí tài nguyên lập trình.

Mục tiêu này có xứng đáng trong dự án phần mềm không?

Tôi cũng nghĩ rằng đối với một ứng dụng web hoặc máy tính để bàn, có giao diện CLI thay thế là một cách tuyệt vời để chứng minh rằng logic nghiệp vụ được tách rời hoàn toàn khỏi GUI.

Có khả năng làm việc với CLI hầu như không phải là điều tôi sẽ xem xét ngược lại. Nó trông thật tuyệt vời trong một bản lý lịch, đặc biệt là nếu bạn có thể quay nó trong bản lý lịch của mình bằng một cụm từ như "Được sử dụng (Powershell / Bash) để xây dựng một bộ công cụ tự động hóa để gửi tin nhắn SMS khi Cơ sở dữ liệu bị hỏng".

Khi tôi chịu trách nhiệm thuê người, kiến ​​thức làm việc về CLI là thứ tôi tìm kiếm.

Về cơ bản, nó đi xuống "sử dụng công cụ phù hợp cho công việc."

Nếu bạn phải tương tác với người dùng, bạn sẽ muốn một số loại GUI. Chúng tôi đã có nhiều thập kỷ nghiên cứu và kinh nghiệm cho thấy rằng họ làm cho điện toán trở nên trực quan và hiệu quả hơn rất nhiều. Đó là lý do tại sao GUI đã chiếm lĩnh thế giới kể từ năm 1984: chúng chỉ hoạt động tốt hơn để tương tác với mọi người.

Nhưng nếu bạn đang tự động hóa một chương trình với các tập lệnh, chương trình của bạn sẽ không tương tác với mọi người; nó tương tác với một kịch bản. Và giao diện tốt nhất cho điều đó là một giao diện dựa trên văn bản, vì những lý do nên rõ ràng bằng trực giác.

Việc phát triển các chương trình CLI để người dùng làm việc trực tiếp được coi là lạc hậu và có lý do chính đáng. Nhưng nếu đó không phải là những gì bạn đang làm, nếu bạn đang viết các công cụ năng suất tự động hóa, thì bạn sẽ không làm gì sai bằng cách cho họ CLI.

Nghệ thuật lập trình Unix của Eric Raymond là tác phẩm kinh điển cho lập luận bạn đang đưa ra. Tôi sẽ không cố gắng cô đọng cuốn sách tuyệt vời của anh ấy thành một vài đoạn. Tuy nhiên, hãy nhớ rằng đối số áp dụng chủ yếu cho các lập trình viên, quản trị viên tự động hóa các tác vụ bằng cách sử dụng tập lệnh hoặc cung cấp năng lượng cho người dùng phần mềm kỹ thuật cao như CAD.

Ngay cả với người dùng có kỹ thuật cao, bạn phải xem xét họ đang đội chiếc mũ nào. Ví dụ, tôi viết phần mềm nhúng cho thiết bị mạng để kiếm sống. Tất cả các sản phẩm của chúng tôi đều có cả CLI và GUI, nhưng các nhà phát triển hầu như đều thích CLI, do tính linh hoạt, tính kịch bản, tính sẵn có, tốc độ, v.v.

Tuy nhiên, chính nhóm nhà phát triển đó lại cực kỳ thích GUI trên phần mềm kiểm soát phiên bản của chúng tôi, mặc dù CLI của nó mạnh hơn và được hỗ trợ và ghi lại cũng như GUI. Sự khác biệt là chúng tôi là người dùng cuối của phần mềm kiểm soát phiên bản, không phải quản trị viên hoặc nhà phát triển.

Vì vậy, hãy xem xét cẩn thận vai trò của người dùng khi họ sử dụng các tiện ích của bạn và lên kế hoạch cho giao diện người dùng phù hợp. Nếu sếp của bạn đề cập đến nó, rất có thể bạn cần cải thiện tài liệu và / hoặc đào tạo về CLI ít nhất. Nếu bạn liên tục nói với mọi người một tính năng chỉ khả dụng trên CLI khi họ mong đợi nó cho GUI, có lẽ bạn cần phải xem xét lại các ưu tiên phát triển của mình, xem xét nhu cầu của người dùng tốt hơn.

Không chỉ Unix mà được điều khiển bởi các chương trình dòng lệnh. Microsoft cũng đang đi theo hướng đó.

Microsoft đã đẩy PowerShell một thời gian rồi. Tất cả phần mềm máy chủ hiện tại của họ (Exchange, SharePoint, Server 2012, System Center, v.v.) có thể được kiểm soát hoàn toàn thông qua dòng lệnh PowerShell. Và PowerShell phụ thuộc vào các chức năng nhỏ làm tốt một việc và chuyển dữ liệu sang chức năng tiếp theo (mặc dù nó xử lý các đối tượng thay vì chỉ văn bản).

Hầu hết các GUI cho các chương trình đó chỉ đơn giản là một giao diện cho các lệnh PowerShell, nhiều người thậm chí còn cho bạn biết những lệnh nào nó sẽ chạy để làm cho kịch bản dễ dàng hơn. Mọi thứ bạn có thể làm từ GUI bạn có thể làm từ PowerShell. Điều ngược lại là không đúng - có khá nhiều chức năng chỉ được hiển thị trong PowerShell.

Vì vậy, nếu * nix luôn làm điều đó và Microsoft đang đi theo hướng đó ... dường như không quá lạc hậu với tôi!

Tôi chắc chắn sẽ không nói đó là một điều xấu. Điều thú vị về các chương trình CLI là khi triển khai chúng, bạn có thể có phạm vi rất hạn chế. Chẳng hạn, nếu tôi muốn viết một catbản sao hoặc "một chương trình in nội dung của tệp ra màn hình", điều đó rất khả thi với CLI.

Tuy nhiên, nếu bạn không sử dụng CLI thì bạn sẽ có một chương trình cơ bản với GUI hiển thị một số văn bản. Nhưng sau đó, bạn cũng phải buộc mở một hộp thoại tập tin và nối nó lên .. nhưng sau đó ai đó cũng muốn có thể sửa đổi văn bản và lưu nó ở nơi khác ..

Phạm vi creep là vô lý với các ứng dụng GUI. Thật dễ dàng để tránh mặc dù với các ứng dụng CLI. "Bạn muốn chỉnh sửa tệp và sau đó lưu lại? cat foo > ed > bar" Với các ứng dụng CLI, việc người dùng của bạn (không phải bạn, nhà phát triển) kết hợp nó với các công cụ khác là chuyện nhỏ.

Bây giờ, điều đó đang được nói, các chương trình CLI đang bắt đầu được xem là "ngược". Điều này là do rất nhiều sự phát triển ứng dụng ngày nay xảy ra ở các thị trường nơi người dùng kết hợp công cụ của bạn với các công cụ khác là không thể. Tôi sẽ không đi sâu vào vấn đề đó ở đây, nhưng tôi đã viết một bài đăng trên blog về cách "thị trường thực thi tâm lý không chủ", hoàn toàn trái ngược với một ứng dụng CLI được thiết kế tốt (để làm một việc và làm tốt điều đó )

GUI và CLI đều có vị trí của chúng. GUI rất tuyệt vời khi cho phép người dùng thực hiện các hoạt động đóng hộp nhất định một cách nhanh chóng. CLI dành cho khi bạn muốn làm những việc mà GUI không cho phép bạn làm. CLI thường mạnh hơn và khó sử dụng hơn.

Một công cụ CLI tốt cho phép người dùng thực hiện những điều mà người viết công cụ không bao giờ nghĩ tới. Một ví dụ là lệnh 'find' UNIX. Lệnh này:

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

tìm thấy các tệp trong thư mục hiện tại (nhưng giới hạn ở 5 cấp độ) có tên bắt đầu 'xyzzy' và đã được sửa đổi hơn 3 ngày trước và sau đó xóa chúng (lưu ý: mã chưa được kiểm tra). Và đó là cách sử dụng đơn giản vừa phải. Bạn có thể sử dụng trình quản lý tệp để thực hiện loại việc đó, nhưng sẽ mất nhiều thời gian hơn và dễ bị lỗi. Tất nhiên, mạnh hơn có nghĩa là CLI có thể dễ dàng bị lạm dụng và tạo ra vấn đề cho chính bạn!

Một nhà phát triển giỏi có thể viết một công cụ CLI theo cách nó cũng có GUI cho phép thực hiện một bộ hoạt động giới hạn. Người dùng có thể bắt đầu với GUI và tìm hiểu sự phức tạp của CLI sau này.

Một bài đọc tốt (dài và thiên vị (?)) Trên trao đổi CLI / GUI là tại:

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

Không, nó không hề lạc hậu chút nào.

"Hướng" có liên quan nhiều đến quan điểm của chúng tôi. Một người dùng hài lòng với đường dẫn hiện tại hướng tới các giao diện "một trải nghiệm tất cả các thiết bị" đơn giản sẽ xem CLI như một sự hồi sinh hoặc hồi quy chắc chắn. Nó không phù hợp với mong đợi chung của họ.

Một lập trình viên, quản trị viên hoặc người sử dụng năng lượng có thể coi đó là sự tiến bộ hợp lý của các công cụ theo kinh nghiệm của họ. Nhiều trong số này bắt đầu sử dụng các công cụ GUI. Khi họ muốn hoặc cần mở rộng quy mô, họ nhanh chóng tìm ra lý do tại sao CLI tồn tại và sự tiến triển đó cộng hưởng với việc xây dựng nhiều công cụ CLI hơn.

Có cái này của Paul Ferris: http://www.linuxplanet.com/linuxplanet/opinions/1505/1

Đối với cá nhân tôi, ý tưởng về cú pháp khác biệt hai. Khi cú pháp hiện diện phần nào trong GUI, kết quả gần như không bao giờ tốt và linh hoạt cũng như nghĩ ra cú pháp CLI. Khi điều này được kết hợp với các đường ống và chuyển hướng, GUI sẽ bị xẹp do nó không hữu ích bên ngoài các trường hợp sử dụng theo kế hoạch.

Sở thích cá nhân của tôi về điều này là các công cụ CLI cung cấp tùy chọn --gui hoặc --verbose đủ để cho phép trình bao bọc GUI tương tác một cách mạnh mẽ bao gồm các thanh trạng thái và các yếu tố cơ bản khác mà mọi người tìm đến GUI.

Tất nhiên, chi phí cho việc này về cơ bản là hai chương trình với một chương trình khá vô dụng, nhưng lợi ích chính là có thể kết hợp một hoặc nhiều công cụ CLI tuyệt vời vào GUI tùy chỉnh mà không cần sửa đổi các công cụ CLI đã nói. Thông thường, điều này chỉ được thực hiện để cung cấp tùy chọn GUI trên một CLI cụ thể, nhưng ý tưởng điều khiển nhiều công cụ với một GUI định hướng "quy trình" hoặc "trường hợp sử dụng" có thể mang lại kết quả tương tự như đường ống và chuyển hướng và kịch bản cho trường hợp sử dụng đó, làm cho nó có sẵn cho những người không thực hiện các hoạt động đó đủ thường xuyên để đạt được thành thạo trong khi vẫn không gây ức chế cho người dùng CLI.

Tôi đã gặp cách tiếp cận này trên SGI IRIX và thực sự thích nó. Tôi thấy mình sử dụng GUI hoặc dòng lệnh khi cần thiết và điều tuyệt vời là biết chính xác những gì các nút ưa thích đang thực sự làm.

Khi có nhiều môi trường hoạt động khác nhau, các trình bao bọc GUI có thể khác nhau đáng kể mà không ảnh hưởng đến công cụ CLI.

Tôi thấy điều này trong Linux ngày nay với những thứ như các công cụ đĩa / hệ thống tập tin, trong đó GUI có thể thêm rất nhiều giá trị ngay cả với người dùng quen thuộc CLI.

Trong trường hợp các hệ thống tập tin / đĩa / thiết bị đã biết, việc loại bỏ CLI không khó khăn và dĩ nhiên nó có thể được viết kịch bản. Sai lầm có thể đau đớn tuy nhiên.

Trong trường hợp những điều đó có thể không được biết hoặc có thể thực hiện các hoạt động không được thực hiện thường xuyên đủ để duy trì trạng thái ổn định và không có lỗi, thì việc chạy GUI cung cấp một môi trường có thể dễ dàng xác minh, các hoạt động được nối với nhau và sau đó chạy một cách tự tin, không cần kịch bản.