Luồng công việc của lập trình viên định hướng CLI khác với luồng công việc theo định hướng GUI như thế nào?

Tôi đã nghe nhiều về những lợi ích của việc thực hiện ít công việc lập trình trong các ứng dụng GUI và sử dụng nhiều công cụ dòng lệnh hơn (đặc biệt là liên quan đến việc hoàn thành công việc hiệu quả hơn). Tuy nhiên, vì tôi không hiểu quy trình làm việc của mình sẽ khác như thế nào nếu tôi phụ thuộc nhiều hơn vào các công cụ dòng lệnh, tôi không thể dễ dàng đánh giá liệu cá nhân tôi có đủ tiền để đầu tư thời gian và nỗ lực học một bộ công cụ mới và thay đổi quy trình làm việc của tôi.

Ngay bây giờ:

• Tôi mã hóa một số dự án phụ bằng các ngôn ngữ như C / C ++ / D / C # / Java / Python bằng Visual Studio, Eclipse, v.v. và chạy chúng bằng cách thiết lập các cài đặt xây dựng và nhấn F5 để xây dựng / chạy.

• Tôi đang phát triển một chương trình web tại nơi làm việc, do đó liên quan đến việc sử dụng Django để thiết lập máy chủ, kết nối với cơ sở dữ liệu, v.v ... hầu như tất cả trong trình soạn thảo văn bản SciTE.

• Để khởi chạy các chương trình thông thường, tôi sử dụng Launchy ... vẫn không có thiết bị đầu cuối. :)

• Để sao chép tệp và không có gì, tôi sử dụng tìm / di chuyển thường xuyên trong trình quản lý tệp đồ họa (Windows Explorer, Nautilus).

• Gỡ lỗi: Tôi sử dụng Visual Studio hoặc công cụ gỡ lỗi cho Windows (nếu tôi đang ở trên Windows). Tôi chưa thực hiện nhiều sửa lỗi trên Linux, nhưng đối với những việc tôi đã làm, tôi đã sử dụng Eclipse (cũng cho Java trên Windows).

• Tại nơi làm việc: Để kết nối với hệ thống xây dựng và thiết lập dự án, tôi chỉ sử dụng các công cụ đã được tích hợp vào Eclipse để sử dụng - không cần thiết bị đầu cuối hay bất cứ thứ gì (mặc dù tôi chắc chắn rất vui khi sử dụng thiết bị đầu cuối nếu tôi thực sự muốn)

Làm những điều này trong CLI là gì? Những phần nào trở nên nhiều hơn / kém hiệu quả? Những khía cạnh nào trong quy trình làm việc của tôi sẽ cần phải được thay đổi để có được lợi thế lớn nhất từ ​​việc chuyển sang làm việc chủ yếu trong CLI? Nói cách khác ... Nếu bạn biến tôi thành một bậc thầy về dòng lệnh, thì quy trình mã hóa mới của tôi sẽ khác với cách làm việc hiện tại, tập trung vào GUI của tôi như thế nào?

Tôi không nghĩ rằng điều này là đúng nữa. CLI có một lợi thế cụ thể - nếu bạn biết trước những gì bạn đang tìm kiếm, thì bạn có thể nhập nó nhanh hơn bạn có thể điều hướng đến nó trong một menu. Điều này có nghĩa là nếu bạn rõ ràng muốn đưa ra các lệnh cho chương trình có ít ngữ cảnh thì nó hầu như nhanh hơn. Tuy nhiên, có hai vấn đề.

Thứ nhất, các chương trình GUI có thể suy ra ngữ cảnh cho bạn. Ví dụ: tính năng Đi đến Định nghĩa và Intellisense của Visual Studio. Làm thế nào bạn có thể sao chép các tính năng đó trong CLI?

Thứ hai, các chương trình GUI có thể hiển thị lại nhiều hơn cho bạn. Ví dụ, Visual Studio Parallel Profiler, là biểu đồ sử dụng CPU trên nhiều lõi theo thời gian. Làm thế nào bạn có thể hiển thị điều đó trong CLI? Nó sẽ không có ý nghĩa. Ngay khi dữ liệu của bạn được thể hiện tốt hơn dưới dạng văn bản khác, CLI sẽ bị mất ngay lập tức. Một ví dụ dễ dàng khác là điểm dừng. Trong Visual Studio, bạn bấm vào lề của dòng bạn muốn ngắt. Bạn sẽ làm gì trong CLI, cố gắng tìm tệp và số dòng và nhập lệnh đó? Điều đó sẽ đưa bạn một thập kỷ tương đối. Điều đó thậm chí còn không tính đến một số cải tiến GUI mới hơn, như Canvas gỡ lỗi.

GUI có thể chậm hơn nếu bạn muốn dành thời gian đẩy Debug nhiều lần, nhưng ngay khi các trường hợp sử dụng trở nên phức tạp hơn, thì CLI không thể theo kịp.

Tôi nghĩ rằng sự khác biệt lớn nhất không nằm ở các nhiệm vụ riêng lẻ mà ở hai điều:

Đầu tiên và quan trọng nhất, tự động hóa. CLI vốn là kịch bản thường khó hơn trên Windows. Tôi đã nghe thấy những điều được cải thiện với PowerShell nhưng tôi chưa sử dụng nó.

Thứ hai, triết lý UNIX về "tách mối quan tâm". Tôi có thể viết một giao diện dựa trên đường đọc nhỏ vào một cái gì đó và sử dụng shell Mx của emacs sử dụng nó trong GUI của emacs. Điều này làm cho đơn giản hơn để tận dụng các công cụ khác và chức năng hiện có.

Để gỡ lỗi gdb hoạt động tốt nhưng tôi thường thích trình gỡ lỗi VS. Đây có lẽ là phần mềm tốt nhất mà Microsoft từng làm.

Để xây dựng và chạy mọi thứ: thực hiện. Hoặc bash. Bất cứ nơi nào.

Để phát triển: emacs (chuyển đổi gần đây từ vi, thật xấu hổ!). Vi nếu làm việc qua ssh.

Tôi thực sự không thể làm quen với Eclipse. Tôi nghĩ đó là một vấn đề "hình dạng của tâm trí": nó không phù hợp với tôi.

Đối với tôi, việc chuyển sang luồng công việc CLI từ Visual Studio liên quan đến việc ghi nhớ rất nhiều lệnh * nix. Nó cũng liên quan đến một số vấn đề đau đầu mỗi khi tôi làm hỏng việc đăng ký SVN.

Nhưng sự khác biệt lớn nhất trong quy trình làm việc đối với tôi là tôi đã hiểu rõ hơn về cách một hệ điều hành hoạt động . Với quy trình làm việc GUI, nó chỉ cần nhấp vào nút và chờ chương trình phản hồi. Trong thế giới dòng lệnh, tôi cảm thấy như mình đang bảo máy tính trực tiếp làm gì đó.

Nói cách khác, quy trình làm việc GUI là máy tính liên lạc lại với bạn, trong khi quy trình làm việc CLI có vẻ giống như bạn đang giao tiếp trực tiếp với máy tính.

Một cái không tốt hơn cái kia, nhưng thực hiện chuyển đổi từ một môi trường hoàn toàn dựa trên GUI vào thiết bị đầu cuối chắc chắn là một chuyến đi.

Dưới đây là nhiều quan sát từ một lập trình viên đã sống ở cả hai thế giới. Tôi sẽ không lặp lại điểm đã được thực hiện trong các câu trả lời khác:

Phát triển dựa trên CLI có xu hướng sử dụng nhiều chương trình, mỗi chương trình thực hiện 1 chức năng. Phát triển dựa trên GUI có xu hướng sử dụng 1 chương trình lớn (IDE), thực hiện hàng tá chức năng khác nhau. Sự khác biệt này có một số hậu quả:

Vì IDE được dự định là một "ngôi nhà" của bạn, nơi bạn làm việc mọi lúc, nên họ có thể sử dụng định dạng độc quyền (có thể là nhị phân) để giữ dữ liệu của bạn. Khả năng tương thích không phải là mối quan tâm lớn, vì họ không mong đợi bạn làm việc trong 2 IDE khác nhau trong cùng một dự án. Mặt khác, các công cụ CLI thường chỉ hoạt động với các tệp văn bản thuần túy.

Với sự phát triển dựa trên CLI, bạn có thể tăng dần các công cụ hoặc tích hợp các công cụ mới vào quy trình công việc của mình, dễ dàng hơn. Chọn một IDE là tất cả hoặc không có gì, và chuyển đổi IDE của bạn là khó khăn hơn.

Sử dụng tập lệnh xây dựng CLI, thay vì trình đơn "Xây dựng" tích hợp của IDE, có nhiều khả năng bạn có thể rời khỏi mã của mình trong một vài năm, quay lại và xây dựng nó mà không phiền phức. Với sự phát triển dựa trên GUI, có khả năng lúc đó bạn đang chạy một IDE hoàn toàn khác. Có lẽ cái bạn đang sử dụng khi bạn viết mã thậm chí không chạy trên HĐH hiện tại của bạn.

Trong một IDE, xây dựng các công cụ của riêng bạn có nghĩa là học API trình cắm (có thể lớn) và có thể sử dụng một ngôn ngữ cụ thể. Khi sử dụng CLI, không có gì đặc biệt là cần thiết để tạo các công cụ tùy chỉnh.

Mặt khác, ưu điểm của IDE là nó được tích hợp "tốt". Vì vậy, bạn có thể nhấp vào cửa sổ trình chỉnh sửa của mình để đặt điểm dừng của trình gỡ lỗi, v.v.

Một điểm khác: sự lựa chọn của bạn cũng sẽ phụ thuộc vào nền tảng phát triển, HĐH và (các) ngôn ngữ mà bạn sử dụng. Trên một số nền tảng nhất định, phát triển dựa trên IDE đã ăn sâu vào văn hóa phát triển thịnh hành. Ở những người khác, phát triển dựa trên CLI là phổ biến. Nếu bạn đang sử dụng một nền tảng nơi phát triển dựa trên IDE là phổ biến, có khả năng các công cụ CLI sẽ được phát triển kém và được hỗ trợ kém. Các ngược lại cũng đúng.

Hầu hết thời thơ ấu của tôi không dành cho máy tính vì chúng tôi thậm chí còn có internet ở trang trại. Tôi bắt đầu lập trình muộn ở trường trung học và về cơ bản làm việc trong GUI mọi lúc. Ở trường đại học, tôi đã gặp một anh chàng lớn lên trên CLI và làm mọi thứ theo cách đó. Vì vậy, tôi quyết định thiết lập một máy chủ linux thay vì nghe prof. Sau một vài năm, bạn thân của tôi đã xem tôi viết một số mã nhúng và không thể tin được cách tôi viết.

Về cơ bản tôi sử dụng một nửa GUI CLI. Có một số điều mà các môi trường được đóng gói GUI thực hiện nhanh hơn và hiệu quả hơn nhiều. Và điều tương tự cũng đúng với CLI. Hầu hết các chỉnh sửa văn bản của tôi được thực hiện trong VIM vì các trình soạn thảo CLI tiên tiến VIM / EMACS (không có cuộc chiến nào ở đây) làm cho thao tác văn bản hiệu quả nhất. Mặt khác, như gỡ lỗi nhúng bằng GDB, cũng đau đớn như chỉnh sửa văn bản mà không có bàn phím. Chắc chắn nó mạnh mẽ và chắc chắn với đủ thời gian bạn sẽ tìm thấy thông tin bạn đang tìm kiếm nhưng có một cửa sổ GUI đẹp với quyền truy cập tức thì vào bất kỳ khối bộ nhớ nào là vô giá, đặc biệt là khi cố gắng so sánh nó với khối bộ nhớ khác.

Dù sao, điều tôi thực sự muốn nói là nó không nên là GUI so với CLI mà là CLI tốt hơn và GUI nào tốt hơn. Bởi vì cuối cùng nếu IO của bạn chậm hơn quá trình suy nghĩ của bạn thì có vấn đề.

"chuyển đổi thành một guru CLI qua đêm?" Vâng, có sự cọ xát. GUI được thiết kế tốt có xu hướng dễ khám phá hơn CLI và dễ tha thứ hơn cho người mới.

Quy trình làm việc của tôi, gần đây được tăng cường bởi trình quản lý cửa sổ ốp lát (dwm), bao gồm rất nhiều thao tác gõ. Máy tính xách tay của tôi bây giờ thực sự có thể sử dụng được mà không cần cắm chuột (Bàn di chuột phù hợp với những gì còn lại của việc trỏ). Tôi giữ rất nhiều ứng dụng mở và chuyển đổi với alt-tab. Tôi không lãng phí thời gian di chuyển và thay đổi kích thước cửa sổ.

Hầu hết thời gian, tôi sử dụng trình duyệt, vim và một loạt các thiết bị đầu cuối. SSH mang lại cho tôi rất nhiều sự linh hoạt về nơi tôi làm việc (về thể chất). Máy tính để bàn từ xa có thể mang lại trải nghiệm tốt hơn khi tất cả chúng ta đều có đường ống 10Gigabit lên mạng, nhưng tôi sẽ không nín thở.

Tôi chưa học được vim đủ tốt để tận dụng các tính năng phức tạp của nó, nhưng tôi đang nghiêng về hướng đó - tôi muốn có vim nhảy đến đúng dòng # sau khi thất bại. (Về mặt kỹ thuật vim là Giao diện Trực quan, mặc dù nó chạy trong một thiết bị đầu cuối, nhưng tôi lái nó bằng bàn phím chứ không phải chuột.)

Vấn đề thực sự là giao diện được thiết kế kém . Các giao diện được thiết kế tốt rất khó để tạo ra, vì vậy chúng không xảy ra rất thường xuyên trong cả hai trại. Nhưng vì ngày nay nhiều pháp sư không thiết kế đang thiết kế GUI hơn CLI, ....

(Peeve thú cưng lớn khác của tôi bị phình to windows C Turbo C là một IDE tuyệt vời. Tại sao Nook của tôi dường như chạy chậm hơn so với máy Mac cổ điển? Tại sao một mình kernel lại chiếm nhiều dung lượng đĩa hơn toàn bộ hệ thống trước đây?)

Với giao diện người dùng đồ họa, bạn buộc phải tương tác với chương trình nhiều lần để thực hiện cùng một hoạt động lặp đi lặp lại. Với hệ vỏ, bạn có thể tự động hóa mọi thứ dễ dàng hơn và để các chương trình hoạt động cùng nhau thông qua đường ống - ví dụ có thể được sử dụng để xuất kết quả khớp với biểu thức thông thường trong một tập hợp các tệp hoặc gói mạng. Như đã nói, nó nhanh hơn cho nhiều hoạt động.

Lập trình trong thiết bị đầu cuối có lẽ không tốt hơn nhiều so với trình soạn thảo đồ họa, trừ khi bạn sử dụng SSH.

Cá nhân tôi đã tìm thấy trình bao unix dễ tiếp cận hơn nhiều so với dòng lệnh Windows điển hình và hiện đang đắm mình trong hệ thống Linux với trình quản lý cửa sổ ốp lát và rất nhiều thiết bị đầu cuối.

Tất cả các ví dụ của bạn là quá trình một bước. Trong hầu hết các môi trường GUI, nếu bạn muốn di chuyển một tệp không liên quan đến ứng dụng hiện tại mà bạn đang ở, bạn có thể làm nếu từ menu tệp mà không cần rời khỏi ứng dụng. Không có ý nghĩa đi đến một dấu nhắc lệnh. Nếu bạn muốn sao chép tệp và đặt tên khác, trên dòng lệnh bạn có thể thực hiện tất cả việc này cùng một lúc. Để đặt tệp này trong tệp bó, ít nhất bạn cần biết cách thực hiện việc này, nhưng sau đó bạn có thể thực thi tệp bó từ GUI nếu muốn.

Tôi đã có một cuộc tranh luận tương tự về các lệnh bàn phím v. Chuột.

Cách tôi làm việc ủng hộ GUI cho đến nay.

Cách sử dụng điển hình:

• Ba IDE cho ba nền tảng khác nhau. Cũng là một cửa sổ Notepad ++ cho một số tập lệnh. Đơn giản là không có cách nào tôi có thể nhớ các lệnh cho tất cả các hệ thống xây dựng đó. Vấn đề với CLI là bạn cần biết nhiều chi tiết chỉ để xây dựng hoạt động. IDES hiện đại thường có một số tùy chọn thích hợp trong đó theo mặc định. Bạn luôn có thể có một cái nhìn gần hơn khi thời gian đến.
• SVN hoặc Git tích hợp. Có rất nhiều lựa chọn cho một chương trình phụ trợ cho lập trình và hầu hết thời gian tôi chỉ thực hiện cam kết hoặc cập nhật.
• Công cụ mạng: May mắn cho tôi, tôi cũng có thể thực hiện tất cả các thiết lập mạng trong văn phòng của chúng tôi. Hầu hết các bo mạch mạng sẽ cung cấp cho bạn tải các lệnh CLI, nhưng nếu có một điều mà bạn cần có cái nhìn tổng quan về trạng thái, thì đó là tường lửa và định tuyến. Để định tuyến, tôi chỉ có thể sống với dòng lệnh, nhưng tường lửa trở nên phức tạp và nếu có một thứ GUI tốt thì nó sẽ hiển thị nhiều thông tin.
• Nói chung có rất nhiều chuyển từ thứ này sang thứ khác. Bối cảnh chuyển đổi dễ dàng hơn với một bối cảnh trực quan.

Đối với lợi ích chính của CLI, kịch bản, tôi hầu như không bao giờ làm điều đó. Các tác vụ lặp đi lặp lại mà chúng ta có chỉ là các ứng dụng công việc định kỳ mà chúng ta đã cùng nhau thực hiện trong c # và không thường xuyên thay đổi. Chúng tôi có nhiều cách để làm cho mọi thứ chạy trong Linux, nhưng chủ yếu là nó được chuyển (boost), vì vậy việc gây rối với các tệp và những thứ như vậy được giảm thiểu. Và nếu mọi thứ trở nên rợn tóc gáy, cũng có những IDE tốt cho Linux.