Tại sao tôi nên sử dụng IDE? [đóng cửa]

Trong một câu hỏi khác, Mark nói rất nhiều về IDE, nói rằng "một số người vẫn không biết" tại sao "họ nên sử dụng một ...". Là một người sử dụng vim để lập trình và làm việc trong môi trường mà hầu hết / tất cả các đồng nghiệp của tôi sử dụng vim hoặc emacs cho tất cả công việc của họ, các lợi thế của IDE là gì? Tại sao tôi nên sử dụng một?

Tôi chắc chắn đây là vấn đề được tính phí đối với một số người và tôi không quan tâm đến việc bắt đầu một cuộc chiến rực lửa, vì vậy vui lòng chỉ trả lời với lý do bạn tin rằng phương pháp dựa trên IDE là ưu việt . Tôi không muốn nghe về lý do tại sao tôi không nên sử dụng IDE; Tôi đã không sử dụng một. Tôi muốn nghe từ "phía bên kia của hàng rào", có thể nói như vậy.

Nếu bạn nghĩ rằng IDE có thể phù hợp với một số loại công việc nhưng không phải loại khác, tôi cũng muốn nghe lý do tại sao.

Nó thực sự phụ thuộc vào ngôn ngữ bạn đang sử dụng, nhưng trong C # và Java tôi thấy các IDE có lợi cho:

• Điều hướng nhanh chóng đến một loại mà không cần phải lo lắng về không gian tên, dự án, v.v.
• Điều hướng đến các thành viên bằng cách coi họ là siêu liên kết
• Tự động hoàn thành khi bạn không thể nhớ tên của tất cả các thành viên
• Tạo mã tự động
• Tái cấu trúc (một khối lớn)
• Sắp xếp nhập khẩu (tự động thêm nhập khẩu thích hợp trong Java, sử dụng các chỉ thị trong C #)
• Cảnh báo theo kiểu bạn (nghĩa là một số lỗi thậm chí không yêu cầu chu trình biên dịch)
• Di chuột qua một cái gì đó để xem các tài liệu
• Giữ chế độ xem tệp, lỗi / cảnh báo / kiểm tra bảng điều khiển / đơn vị, v.v. và mã nguồn tất cả trên màn hình cùng một lúc một cách hữu ích
• Dễ dàng chạy thử nghiệm đơn vị từ cùng một cửa sổ
• Gỡ lỗi tích hợp
• Kiểm soát nguồn tích hợp
• Điều hướng đến nơi xảy ra lỗi thời gian biên dịch hoặc ngoại lệ thời gian chạy trực tiếp từ các chi tiết lỗi.
• Vân vân!

Tất cả những tiết kiệm thời gian. Chúng là những thứ tôi có thể làm thủ công, nhưng với nhiều nỗi đau hơn: tôi muốn viết mã hơn.

Mã hoàn thành. Nó giúp rất nhiều với việc khám phá mã.

Câu trả lời ngắn gọn về lý do tại sao tôi sử dụng IDE là sự lười biếng.

Tôi là một tâm hồn lười biếng, người không thích làm mọi thứ một cách khó khăn khi có một cách dễ dàng để làm điều đó thay vào đó. IDE làm cho cuộc sống dễ dàng và rất hấp dẫn đối với chúng ta lười biếng dân gian.

Khi tôi nhập mã, IDE sẽ tự động kiểm tra tính hợp lệ của mã, tôi có thể tô sáng một phương thức và nhấn F1 để nhận trợ giúp, nhấp chuột phải và chọn "đi đến định nghĩa" để chuyển thẳng đến nơi được xác định. Tôi nhấn một nút và ứng dụng, với trình gỡ lỗi tự động được đính kèm được khởi chạy cho tôi. Và thế là danh sách tiếp tục. Tất cả những điều mà một nhà phát triển làm trên cơ sở hàng ngày được tập hợp dưới một mái nhà.

Không cần sử dụng IDE. Nó chỉ là công việc khó khăn hơn không.

Tôi không nghĩ thật công bằng khi thực hiện "trình soạn thảo văn bản và cửa sổ bảng điều khiển so với IDE" cổ điển khi "trình soạn thảo văn bản" thực sự là emacs. Hầu hết các tính năng tiêu biểu cho IDE: s cũng có trong emacs. Hoặc có lẽ chúng thậm chí bắt nguồn từ đó, và IDE hiện đại chủ yếu là cải tiến / đơn giản hóa giao diện.

Điều này có nghĩa là đối với câu hỏi ban đầu, câu trả lời không quá rõ ràng. Nó phụ thuộc vào cách mọi người trong trang web nghi vấn sử dụng emacs, nếu họ chủ yếu sử dụng nó làm trình soạn thảo văn bản hoặc nếu họ đi ra ngoài và sử dụng tập lệnh tùy chỉnh, tìm hiểu các lệnh cho các chế độ có liên quan, biết về gắn thẻ mã, v.v.

Tôi đến câu hỏi này từ hướng ngược lại. Tôi đã được đưa lên lập trình với rất ít pitstops ở vùng đất Makefile + Emacs. Từ trình biên dịch đầu tiên của tôi trên DOS, Microsoft Quick C, tôi đã có một IDE để tự động hóa mọi thứ. Tôi đã dành nhiều năm làm việc trong Visual C ++ 6.0 và khi tôi tốt nghiệp vào Enterprise Java, tôi đã làm việc với Borland JBuilder và sau đó định cư trên Eclipse, điều này đã trở nên rất hiệu quả đối với tôi.

Trong suốt quá trình tự học ban đầu, đại học và bây giờ là sự nghiệp chuyên nghiệp, tôi đã nhận ra rằng bất kỳ sự phát triển phần mềm lớn nào được thực hiện chỉ trong IDE đều trở nên phản tác dụng. Tôi nói điều này vì mong muốn nhất IDE của bạn để làm việc trong họphong cách đặc biệt I-control-how-the-world-works. Bạn phải cắt và xúc xắc các dự án của bạn dọc theo dòng của họ. Bạn đã quản lý các bản dựng dự án của mình bằng các hộp thoại lẻ của chúng. Hầu hết các IDE quản lý các phụ thuộc xây dựng phức tạp giữa các dự án kém và các phụ thuộc có thể khó hoạt động 100%. Tôi đã ở trong những tình huống mà IDE sẽ không tạo ra bản dựng mã hoạt động trừ khi tôi thực hiện Clean / Rebuild All. Cuối cùng, hiếm khi có một cách rõ ràng để đưa phần mềm của bạn ra khỏi sự phát triển và vào các môi trường khác như QA hoặc Sản xuất từ ​​IDE. Đây thường là một lễ hội nhấp chuột để xây dựng tất cả các đơn vị triển khai của bạn hoặc bạn đã có một số công cụ khó xử mà nhà cung cấp IDE cung cấp cho bạn để đóng gói mọi thứ. Nhưng một lần nữa,

Tôi đã học được rằng, để thực hiện phát triển quy mô lớn với một nhóm, chúng tôi có thể làm việc hiệu quả nhất nếu chúng tôi phát triển mã bằng IDE và thực hiện tất cả các bản dựng bằng cách sử dụng các tập lệnh dòng lệnh được viết thủ công. . shell và chạy các script ở đó.

Các bản dựng thủ công yêu cầu chúng ta bỏ lỡ một số tính năng trong IDE hiện đại như biên dịch nền, nhưng những gì chúng ta đạt được còn quan trọng hơn nhiều: các bản dựng sạch và dễ dàng có thể sống trong nhiều môi trường. "Xây dựng một cú nhấp chuột" tất cả những kẻ nhanh nhẹn nói về? Chúng tôi có nó. Các tập lệnh xây dựng của chúng tôi cũng có thể được gọi trực tiếp bởi các hệ thống tích hợp liên tục. Việc các bản dựng được quản lý thông qua tích hợp liên tục cho phép chúng tôi tạo giai đoạn chính thức hơn và di chuyển các triển khai mã của bạn sang các môi trường khác nhau và cho chúng tôi biết gần như ngay lập tức khi ai đó kiểm tra mã xấu phá vỡ các bản kiểm tra bản dựng hoặc đơn vị.

Trong thực tế, việc tôi đảm nhận vai trò xây dựng từ IDE không làm chúng tôi tổn thương quá nhiều. Các công cụ intellisense và tái cấu trúc trong Eclipse vẫn hoàn toàn hữu ích và hợp lệ - việc biên dịch nền chỉ đơn giản phục vụ để hỗ trợ các công cụ đó. Và, việc cắt các dự án đặc biệt của Eclipse đã phục vụ như một cách rất hay để phá vỡ các vấn đề của chúng tôi theo cách mà mọi người có thể hiểu (mặc dù vẫn hơi dài dòng theo sở thích của tôi). Tôi nghĩ một trong những điều quan trọng nhất về Eclipse là các tích hợp SCM tuyệt vời, đó là điều làm cho sự phát triển nhóm trở nên thú vị. Chúng tôi sử dụng Subversion + Eclipse, và điều đó rất hiệu quả và rất dễ dàng để đào tạo người của chúng tôi trở thành chuyên gia tại.

Là tác giả của câu trả lời mà bạn nêu bật trong câu hỏi của mình và thừa nhận đến câu hỏi này hơi muộn, tôi phải nói rằng trong số nhiều lý do đã được liệt kê, năng suất của một nhà phát triển chuyên nghiệp là một trong những lý do nhất kỹ năng được đánh giá cao.

Theo năng suất, ý tôi là khả năng thực hiện công việc của bạn hiệu quả với kết quả tốt nhất có thể. IDE cho phép điều này trên nhiều cấp độ. Tôi không phải là chuyên gia về Emacs, nhưng tôi nghi ngờ rằng nó thiếu bất kỳ tính năng nào của các IDE chính.

Thiết kế, tài liệu, theo dõi, phát triển, xây dựng, phân tích, triển khai và bảo trì, những bước đệm quan trọng trong ứng dụng doanh nghiệp, đều có thể được thực hiện trong IDE.

Tại sao bạn không sử dụng thứ gì đó mạnh mẽ như vậy nếu bạn có sự lựa chọn?

Là một thử nghiệm, hãy cam kết sử dụng IDE trong 30 ngày và xem bạn cảm thấy thế nào. Tôi rất thích đọc suy nghĩ của bạn về kinh nghiệm.

Có một IDE có những ưu điểm sau:

• Biên dịch thường là "đang hoạt động" có nghĩa là không còn chuyển sang dòng lệnh để biên dịch
• Gỡ lỗi được tích hợp và có trong IDE có nghĩa là trình gỡ lỗi bước thực sự sử dụng trình soạn thảo tại chỗ của bạn để hiển thị trực quan cho bạn mã nào được thực thi
• IDE thường có kiến ​​thức ngữ nghĩa hơn về ngôn ngữ bạn đang làm việc và có thể cho bạn thấy các vấn đề có thể xảy ra trong khi gõ. Tái cấu trúc mạnh mẽ hơn nhiều so với "thay thế tìm kiếm".

Có nhiều hơn nữa, có lẽ bạn nên thử.

IDE về cơ bản là:

• Trình chỉnh sửa hoàn thành mã, tái cấu trúc và tài liệu
• Trình gỡ lỗi
• Trình thám hiểm hệ thống tập tin
• Máy khách SCMS
• Xây dựng công cụ

Tất cả trong một gói duy nhất.

Bạn có thể có tất cả những điều này (và một số thứ nữa) bằng cách sử dụng các công cụ riêng biệt hoặc chỉ là một trình soạn thảo lập trình tuyệt vời và các công cụ bổ sung, như Emacs (Vim cũng vậy nhưng có IMO ít IDEbility hơn một chút).

Nếu bạn thấy mình chuyển đổi rất nhiều giữa một tiện ích và tiện ích tiếp theo có thể được tích hợp trong môi trường hoặc nếu bạn thiếu một số khả năng được liệt kê ở đây (và hoàn toàn hơn trong các bài đăng khác), có lẽ đã đến lúc chuyển sang IDE (hoặc để cải thiện tính khả dụng của môi trường của bạn bằng cách thêm macro hoặc không. Nếu bạn đã xây dựng cho mình một 'IDE' (theo nghĩa tôi đã đề cập ở trên) bằng cách sử dụng nhiều hơn một chương trình, thì không cần phải chuyển sang một IDE thực tế.

Nhật thực:

Có mã higlighting, biên dịch trong nền, chỉ ra lỗi của tôi khi tôi đi cùng.

Tích hợp với javadoc, đề xuất tên biến với ctrl-Space.

Khi tôi biên dịch, tôi gặp lỗi ngay tại đó. Tôi có thể nhấp đúp vào một lỗi và nó sẽ hiển thị dòng thích hợp.

Tích hợp thực sự tốt với JUnit, ctrl-F11 chạy thử nghiệm, cho tôi biết các thử nghiệm đã thất bại. Nếu có một ngoại lệ trong cửa sổ đầu ra, tôi có thể nhấp đúp vào một dòng và đưa tôi đến dòng không thành công. Không chỉ vậy, nhưng ctrl-F11 đảm bảo mọi thứ được biên dịch trước khi chạy các bài kiểm tra (có nghĩa là tôi không bao giờ quên làm điều đó).

Tích hợp với kiến. Một lệnh để xây dựng và triển khai ứng dụng.

Tích hợp với trình gỡ lỗi, bao gồm gỡ lỗi từ xa các máy chủ web.

Các công cụ tái cấu trúc FANTASTIC, tìm kiếm các tham chiếu đến một phần của mã. Giúp tôi biết tác động của một sự thay đổi.

Tất cả trong tất cả, nó làm cho tôi năng suất hơn.

Tôi đã sử dụng Emacs làm môi trường chính cho cả phát triển và thư / tin tức trong khoảng 10 năm (1994-2004). Tôi đã khám phá ra sức mạnh của IDE khi tôi ép mình học Java vào năm 2004 và thật ngạc nhiên là tôi thực sự thích IDE ( IntelliJ IDEA ).

Tôi sẽ không đi vào lý do cụ thể vì rất nhiều trong số chúng đã được đề cập ở đây - chỉ cần nhớ rằng những người khác nhau yêu thích các tính năng khác nhau. Tôi và một đồng nghiệp đã sử dụng cùng một IDE, cả hai chúng tôi chỉ sử dụng một phần nhỏ các tính năng có sẵn và chúng tôi không thích cách sử dụng IDE của nhau (nhưng cả hai chúng tôi đều thích IDE).

Nhưng có một lợi thế với các IDE so với các môi trường liên quan đến Emacs / Vim mà tôi muốn tập trung vào: Bạn dành ít thời gian hơn để cài đặt / định cấu hình các tính năng bạn muốn.

Với Wing IDE (cho Python) Tôi đã sẵn sàng bắt đầu phát triển 15-20 phút sau khi cài đặt. Không biết tôi cần bao nhiêu giờ để có được các tính năng tôi sử dụng và chạy với Emacs / Vim. :)

Nó chắc chắn dẫn đến một sự cải thiện năng suất cho tôi. Đến mức tôi thậm chí viết mã các ứng dụng Linux trong Visual Studio trên Vista và sau đó sử dụng máy ảo Linux để xây dựng chúng.

Bạn không cần phải ghi nhớ tất cả các đối số cho một lệnh gọi hàm hoặc phương thức, một khi bạn bắt đầu nhập nó, IDE sẽ cho bạn thấy những đối số nào là cần thiết. Bạn nhận được trình hướng dẫn để đặt thuộc tính dự án, tùy chọn trình biên dịch, v.v. Bạn có thể tìm kiếm mọi thứ trong toàn bộ dự án thay vì chỉ các tài liệu hoặc tệp hiện tại trong một thư mục. Nếu bạn gặp lỗi trình biên dịch, bấm đúp vào nó và nó sẽ đưa bạn đến đúng đường vi phạm.

Tích hợp các công cụ như trình soạn thảo mô hình, kết nối và duyệt cơ sở dữ liệu bên ngoài, quản lý bộ sưu tập mã "đoạn mã", công cụ mô hình GUI, v.v ... Tất cả những điều này có thể có riêng, nhưng có tất cả chúng trong cùng một môi trường phát triển thời gian và giữ cho quá trình phát triển chảy hiệu quả hơn.

Có thể có những lý do khác nhau cho những người khác nhau. Đối với tôi đây là những lợi thế.

1. Cung cấp một cảm giác tích hợp cho dự án. Ví dụ, tôi sẽ có tất cả các tệp dự án liên quan trong chế độ xem đơn.
2. Cung cấp năng suất mã tăng như
   1. Đánh dấu cú pháp
   2. Giới thiệu các hội đồng
   3. Intellisense
   4. Chế độ xem tập trung của cơ sở dữ liệu và các tệp UI liên quan.
   5. Tính năng sửa lỗi

Cuối ngày, nó giúp tôi viết mã nhanh hơn tôi có thể làm trong notepad hoặc wordpad. Đó là một lý do khá tốt để tôi thích IDE.

Một IDE có thể là một lựa chọn 'ưu việt' dựa trên những gì nhà phát triển đang cố gắng thực hiện.

Một trình soạn thảo văn bản có thể là 'ưu việt' vì các IDE thường hướng đến một (hoặc một lựa chọn nhỏ) các ngôn ngữ.

Nếu nhà phát triển dành phần lớn thời gian của mình cho một ngôn ngữ đơn lẻ hoặc một cụm 'ngôn ngữ' liên quan (như C # và T-SQL), trong một HĐH, thì các công cụ thiết kế GUI, gỡ lỗi, intellisense, tái cấu trúc, v.v. một IDE tốt có thể rất hấp dẫn. Ví dụ, nếu bạn dành phần lớn thời gian để làm việc trong VB.NET, với một chút T-SQL bây giờ và sau đó, trong môi trường Windows, thì bạn sẽ khá ngớ ngẩn khi không nhìn vào Visual Studio hoặc IDE tương đương .

Tôi không có thành kiến ​​với những người thích IDE hoặc soạn thảo văn bản, cả hai đều có thể rất hữu ích và hữu ích nếu được học tốt !

Tôi nghĩ rằng nó chủ yếu liên quan đến phạm vi nhận thức cho nhà phát triển. IDE cung cấp một cái nhìn vĩ mô về bối cảnh làm việc của nhà phát triển. Bạn có thể đồng thời xem phân cấp lớp, tài nguyên được tham chiếu, lược đồ cơ sở dữ liệu, tài liệu tham khảo trợ giúp SDK, v.v. Và với rất nhiều điều bị ảnh hưởng và ảnh hưởng đến tổ hợp phím của bạn và khối lượng kiến ​​trúc và giao điểm kiến ​​trúc mở rộng, nó càng trở nên khó khăn hơn chỉ làm việc từ một đảo mã tại một thời điểm.

OTOH, "chỉ tôi và vim và những người đàn ông" cho tôi một cái nhìn siêu nhỏ gọn hơn - nhưng mãnh liệt và chính xác - về công việc của tôi. Sẽ ổn nếu tôi có một cơ sở mã được gắn kết chặt chẽ, được phân vùng tốt, được kết hợp thưa thớt được xây dựng bằng một ngôn ngữ với một bộ thư viện tĩnh để làm việc - không phải là tình huống điển hình của bạn, đặc biệt là khi kích thước nhóm nhà phát triển và định hình lại cấu trúc mã theo thời gian, khoảng cách và sở thích cá nhân.

Tôi hiện đang làm việc trên các dự án trong Flex và .NET. Một trong những điều hay hơn về Flex là có bao nhiêu cách khác nhau để thực hiện một điều tiêu chuẩn - lấy dữ liệu từ cơ sở dữ liệu, mở / đóng / đọc / ghi tệp, v.v. (Tuy nhiên, tôi đang sử dụng IDE của Trình tạo Flex / Eclipse - một ví dụ điển hình nặng như VS, bởi vì tôi vẫn đang học những điều cơ bản và tôi cần các bánh xe huấn luyện. Tôi hy vọng sẽ phát triển trở lại vim một khi tôi tự tin về mô hình của mình.) Theo quan điểm này, tôi có thể làm gì Tôi cần phải làm một cách chuyên nghiệp bằng cách biết một vài điều thực sự thực sự tốt.

OTOH, tôi không thể tưởng tượng đến điểm đó bằng .NET vì chế độ xem tôi dự kiến ​​sẽ duy trì tiếp tục mở rộng và thay đổi. Có tính toàn vẹn về mặt khái niệm ít hơn và qua một số nhà phát triển trong một dự án trong vài tháng, tính nhất quán ít hơn nhiều - nhưng IDE hỗ trợ điều đó, có thể khuyến khích điều đó. Vì vậy, nhà phát triển thực sự cần (và có thể dễ dàng hơn) biết nhiều thứ khác đầy đủ hơn. Điều này cũng có lợi ích là giúp họ trả lời (hoặc thậm chí hiểu) tỷ lệ câu hỏi trên StackOverflow cao hơn rất nhiều. Tức là chúng ta có thể có một kho kiến ​​thức sâu hơn. Và chúng tôi có thể đáp ứng với nhiều loại quảng cáo trợ giúp hơn.

Mọi thứ có thể đi quá xa theo cả hai hướng. Có thể với phạm vi "chỉ dành cho biên tập viên", nó giống như "nếu bạn chỉ có một cái búa, mọi thứ trông giống như một cái đinh". Với phương pháp IDE, đối với bất cứ điều gì bạn muốn gắn chặt với nhau, bạn có nhiều lựa chọn ốc vít và các công cụ liên quan để lựa chọn - nals / búa, ốc vít / tua vít, bu lông / cờ lê, keo dán / súng / kẹp, nam châm và trên và trên - tất cả trong tầm tay của bạn (với một trình hướng dẫn để giúp bạn bắt đầu).

Đừng nghĩ nó là độc quyền. Sử dụng IDE cho các lợi ích mà nó cung cấp và chuyển sang trình soạn thảo văn bản vim / ưa thích khi bạn cần một số trọng tâm nghiêm túc.

Tôi thấy IDE tốt hơn cho refactoring và duyệt và gỡ lỗi và cho tìm ra những gì để làm. Những việc nhỏ sau đó được thực hiện ngay trong IDE, những việc lớn tôi lật sang vim để hoàn thành công việc.

Ngoài các câu trả lời khác, tôi thích kết hợp sức mạnh đang phát triển của IDE với sức mạnh chỉnh sửa của Vim bằng cách sử dụng thứ gì đó như ViPlugin cho Eclipse .

IntelliSense , trình gỡ lỗi tích hợp và cửa sổ ngay lập tức giúp tôi làm việc hiệu quả hơn rất nhiều ( Visual Studio 2008 ). Với mọi thứ trong tầm tay, tôi có thể giữ phần lớn dự án khổng lồ trong đầu trong khi viết mã. Microsoft có thể tiếp tục thả bóng trên hệ điều hành của họ, nhưng Visual Studio là một trong những sản phẩm tốt nhất từng được phát triển.

Tôi không hiểu bạn đang nói gì. Bạn hỏi "Tôi có nên sử dụng IDE thay vì ...", nhưng tôi không hiểu giải pháp thay thế là gì - Vim và Emacs đáp ứng nhiều chức năng mà bất kỳ IDE nào sẽ cung cấp cho bạn. Khía cạnh duy nhất họ không xử lý rằng một IDE lớn hơn có thể là những thứ như các nhà thiết kế UI. Sau đó, câu hỏi của bạn rút ra chỉ đơn giản là "tôi nên sử dụng IDE gì" với các đối số được đưa ra cho lĩnh vực đơn giản hơn của Vim và Emacs.

Đối với tôi, một IDE tốt hơn bởi vì nó cho phép điều hướng mã nhanh hơn, điều này rất quan trọng nếu bạn có một cái gì đó trong tâm trí để thực hiện. Giả sử bạn không sử dụng IDE, sẽ mất nhiều thời gian hơn để đến đích. Suy nghĩ của bạn có thể được xen vào thường xuyên hơn. Nó có nghĩa là nhiều lần nhấp / nhiều phím hơn phải được nhấn. Người ta phải tập trung nhiều hơn vào suy nghĩ làm thế nào để thực hiện mọi thứ. Tất nhiên, bạn cũng có thể viết ra mọi thứ nhưng sau đó người ta phải nhảy giữa thiết kế và thực hiện. Ngoài ra, một nhà thiết kế GUI tạo ra sự khác biệt lớn. Nếu bạn làm điều đó bằng tay, nó có thể mất nhiều thời gian hơn.

Các IDE dựa trên GUI như Visual Studio và Eclipse có một số lợi thế so với các IDE dựa trên văn bản như Emacs hoặc vim vì khả năng hiển thị của chúng:

• Xem trước và chỉnh sửa trực tiếp WYSIWYG cho thiết kế GUI
• Trình chỉnh sửa thuộc tính hiệu quả (ví dụ: lựa chọn màu bằng bảng màu GUI, bao gồm cả dừng định vị, v.v.)
• Mô tả đồ họa của phác thảo mã, mối quan hệ tập tin, vv
• Sử dụng hiệu quả hơn bất động sản màn hình để hiển thị điểm dừng, dấu trang, lỗi, v.v.
• Hỗ trợ kéo và thả tốt hơn với HĐH và các ứng dụng khác
• Tích hợp chỉnh sửa bản vẽ, hình ảnh, mô hình 3D, v.v.
• Hiển thị và chỉnh sửa các mô hình cơ sở dữ liệu

Về cơ bản với IDE dựa trên GUI, bạn có thể nhận được nhiều thông tin hữu ích hơn trên màn hình cùng một lúc và bạn có thể xem / chỉnh sửa các phần đồ họa của ứng dụng dễ dàng như các phần văn bản.

Một trong những điều thú vị nhất để trải nghiệm khi là nhà phát triển là chỉnh sửa phương pháp tính toán một số dữ liệu và xem đầu ra trực tiếp của mã của bạn được hiển thị bằng đồ họa trong một cửa sổ khác, giống như người dùng của bạn sẽ thấy nó khi bạn chạy ứng dụng. Bây giờ đó là chỉnh sửa WYSIWYG!

Các IDE dựa trên văn bản như Emacs và vim có thể thêm các tính năng như hoàn thành mã và tái cấu trúc mã theo thời gian, vì vậy về lâu dài hạn chế chính của chúng là mô hình hiển thị dựa trên văn bản của chúng.

Tôi cũng gần như chỉ sử dụng Vim (gần như vì tôi đang cố gắng học emacs bây giờ) cho tất cả các công cụ phát triển của mình. Tôi nghĩ rằng trực giác tuyệt đối (từ GUI tất nhiên) là lý do chính tại sao mọi người thích sử dụng IDE. Bằng cách trực quan, ít hoặc không cần chi phí học tập của công cụ. Chi phí học tập càng ít, họ càng có thể hoàn thành công việc.

Một IDE cho phép một người làm việc nhanh hơn và dễ dàng hơn ... Tôi nhận thấy tôi đã dành rất nhiều thời gian để điều hướng mã trong một trình soạn thảo văn bản đơn giản ...

Trong một IDE tốt, thời gian sẽ giảm nếu IDE hỗ trợ chuyển sang các chức năng, đến vị trí chỉnh sửa trước đó, đến các biến ... Ngoài ra, một IDE tốt giúp giảm thời gian thử nghiệm các tính năng và dự án ngôn ngữ khác nhau, như thời gian khởi động có thể nhỏ

Một vài lý do tôi có thể nghĩ đến khi sử dụng IDE:

• Trợ giúp tích hợp là một yêu thích.
• Bộ tái cấu trúc tích hợp với Bản xem trước của Visual Studio
• IntelliSense , hightlighting, dễ điều hướng cho các dự án lớn, gỡ lỗi tích hợp, v.v. (mặc dù tôi biết với addins, bạn có thể có thể nhận được rất nhiều điều này với Emacs và Vim ).
• Ngoài ra, tôi nghĩ rằng IDE ngày nay có cơ sở người dùng rộng hơn và có thể nhiều người phát triển bổ trợ cho họ, nhưng tôi có thể sai.

Và thật lòng mà nói, tôi thích con chuột của tôi. Khi tôi sử dụng các trình soạn thảo dựa trên văn bản thuần túy, nó trở nên cô đơn.

Tiết kiệm thời gian để phát triển
Làm cho cuộc sống dễ dàng hơn bằng cách cung cấp các tính năng như Tích hợp gỡ lỗi, intellisense.

Có rất nhiều, nhưng sẽ khuyên bạn nên sử dụng một, chúng rõ ràng hơn.

Tôi không chắc có một đường phân chia rõ ràng giữa trình soạn thảo văn bản và IDE. Bạn có sở thích của Notepad ở một đầu của thang đo và các IDE hiện đại tốt nhất ở đầu kia, nhưng có rất nhiều thứ ở giữa. Hầu hết các trình soạn thảo văn bản có tô sáng cú pháp; các trình soạn thảo nhằm vào các lập trình viên thường có nhiều tính năng khác như điều hướng mã dễ dàng và tự động hoàn tất. Emacs thậm chí cho phép bạn tích hợp trình gỡ lỗi. Các IDE của thậm chí mười năm trước có ít tính năng hơn để giúp các lập trình viên hơn bạn mong đợi về một trình soạn thảo văn bản nghiêm túc ngày nay.

Lý do chính của tôi để sử dụng một là khi mã vượt quá 100 tệp.

Mặc dù ctags có thể thực hiện công việc, một số IDE có một cách khá tốt để điều hướng các tệp dễ dàng một cách siêu nhanh.

Nó tiết kiệm thời gian khi bạn có rất nhiều việc phải làm.

Đối với tôi, đó chỉ là phiên bản GUI của mọi thứ chúng tôi đã làm trong những ngày tốt đẹp của thiết bị đầu cuối. Tôi sẽ luôn đồng ý rằng IDE không vượt trội lắm vì chúng ẩn rất nhiều thứ, đặc biệt là liên quan đến các công cụ liên kết, nhưng chúng có một lợi thế đáng chú ý trong một số trường hợp, ví dụ như với các nền tảng phát triển nhất định như Qt.

Một số IDE giống như trực quan của những người khác thậm chí dường như phân tích mã của bạn khi bạn nhập mã và phát hiện lỗi trước khi bạn biên dịch: có vẻ như logic chỉ một IDE có thể phối hợp chặt chẽ với trình biên dịch để phát hiện ngay vấn đề trong nguồn đã nhập.

Câu trả lời hoang dã của tôi rằng cuộc chiến ngọn lửa IDE / Dòng lệnh tồn tại chỉ là do tòa nhà thực thi C / C ++ không được xử lý tốt theo quan điểm chuẩn hóa, không giống với ngôn ngữ D; mỗi nền tảng xử lý biên dịch / liên kết / vv theo cách riêng của nó, vì vậy để làm cho nó bớt lộn xộn hơn, họ tạo một IDE.

Từ quan điểm của bạn, có thể sử dụng dòng lệnh đơn giản hơn, nếu chỉ có một trình biên dịch với các tùy chọn tiêu chuẩn, thì sẽ dễ dàng, nhưng sự thật là C / C ++ rất linh hoạt, vì vậy, cuối cùng, tất cả nền tảng làm theo cách riêng của họ, do đó IDE không lãng phí giải thích cách thực hiện.

Nếu bạn có thể tìm hiểu làm thế nào một thực thi nói chuyện với kernel hoặc nếu bạn biết bất cứ điều gì về thiết kế trình biên dịch, có thể có một cách để làm việc với một dòng lệnh thích hợp, nhưng tôi nghi ngờ bạn có.

Microsoft hay Apple, tất cả đều xấu, sẽ phải đề xuất một cách đơn giản để xây dựng ứng dụng mà không cần nhập chi tiết và vì việc xây dựng một ứng dụng phụ thuộc trực tiếp vào kiến ​​trúc của HĐH, nên nó sẽ khó "chuẩn" như dòng lệnh là.

Để đặt các ứng dụng đơn giản, lớn và phức tạp mà bạn không muốn tìm hiểu sâu về những gì nó làm -> IDE, các phần mềm nhỏ hoặc thiết kế phần mềm hệ thống đơn giản -> dòng lệnh. Tất nhiên ngoại trừ những thư viện tiện lợi đó nhúng Makefile, nhưng đó là một câu chuyện khác.

Ngoài ra, tôi nghĩ rằng IDE được sử dụng khi ứng dụng được phân phối có liên quan, trớ trêu thay, GUI hoặc thứ gì đó có giao diện hoặc được liên kết trực tiếp với HĐH, do đó, một lần nữa, nó cũng dành cho những người sẽ sử dụng UI / GUI mà không biết Làm thế nào nó hoạt động, trong khi những người sẽ lập trình hệ thống sẽ không cần tất cả.

IDE chỉ là thứ rác rưởi hiện đại, nhưng tôi nghĩ sau 100 năm nữa dòng lệnh sẽ vẫn tồn tại.

Tôi thích một IDE vì nó đặt rất nhiều chức năng trong tầm tay của tôi. Chỉnh sửa / Biên dịch / khả năng hiển thị của các tệp trong dự án là tất cả những điều tôi đánh giá cao trong một IDE. Bây giờ tôi sử dụng Visual Studio nhưng ở kiếp trước tôi đã sử dụng SlickEdit và thấy rằng nó làm cho quá trình phát triển của tôi trở nên hợp lý hơn so với khi tôi không sử dụng nó.

Chỉ có một điều cần xem xét khi quyết định có nên sử dụng IDE hay không và đó là liệu nó có giúp bạn làm việc hiệu quả hơn hay không.

Câu hỏi ngắn nên câu trả lời ngắn :)

Nó phụ thuộc rất nhiều vào những gì bạn đang làm và ngôn ngữ bạn đang thực hiện. Cá nhân tôi có xu hướng không sử dụng IDE (hoặc "IDE của tôi bao gồm 3 xterms chạy vim, một chạy máy khách cơ sở dữ liệu và một ngôn ngữ bash prompt hoặc tailing log ", tùy thuộc vào mức độ bạn định nghĩa" IDE ") cho hầu hết các công việc của tôi, nhưng, nếu tôi thấy mình đang phát triển GUI dựa trên nền tảng, thì tôi sẽ tìm đến IDE phù hợp với ngôn ngữ tức thì - IMO, IDE và chỉnh sửa biểu mẫu đồ họa rõ ràng được thực hiện cho nhau.