Hầu hết các công cụ lập trình được đánh giá thấp [đóng]

Chúng tôi có nhiều công cụ tuyệt vời giúp ích rất nhiều khi lập trình, chẳng hạn như trình soạn thảo văn bản tốt, IDE, trình gỡ lỗi, hệ thống kiểm soát phiên bản, v.v ... Một số công cụ ít nhiều phải có "công cụ" để hoàn thành công việc (ví dụ: trình biên dịch) .

Vẫn luôn có những công cụ giúp ích rất nhiều, nhưng vẫn không được chú ý nhiều, vì nhiều lý do, chẳng hạn, khi chúng được phát hành, chúng đã đi trước thời đại và bây giờ ít nhiều bị lãng quên.

Loại công cụ lập trình bạn có nghĩ là những ai đánh giá thấp nhất? Thúc đẩy câu trả lời của bạn.

Một con vịt cao su. Vâng thật đấy.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Cao su gỡ lỗi vịt , ducking cao su , và kiểm tra duckie cao su là những thuật ngữ chính thức được sử dụng trong công nghệ phần mềm để đề cập đến một phương pháp gỡ lỗi mã. Cái tên này ám chỉ đến một câu chuyện về ngày tận thế có khả năng trong đó một lập trình viên chuyên gia giấu tên sẽ giữ một con vịt cao su ở bàn của mình mọi lúc, và gỡ lỗi mã của mình bằng cách buộc mình phải giải thích nó, từng dòng một, cho con vịt.

Để sử dụng quy trình này, một lập trình viên giải thích mã cho một đối tượng vô tri, chẳng hạn như một con vịt cao su, với mong muốn khi đạt được một đoạn mã không chính xác và cố gắng giải thích nó, lập trình viên sẽ nhận thấy lỗi. Khi mô tả những gì mã được cho là phải làm và quan sát những gì nó thực sự làm, bất kỳ sự không thống nhất giữa hai điều này trở nên rõ ràng ...

Bút và vở.

1. Công trình không có điện.
2. Di động.
3. Doodle trên / trong khi buồn chán trong các cuộc họp
4. Lưu trữ thông tin hữu ích.
5. Nếu nó được viết ra, mọi người coi trọng nó hơn.
6. Những người khác có thể đọc nó và học hỏi.

Các công cụ khác nhau dường như không được sử dụng khi so sánh các đầu ra nhật ký hoặc dữ liệu trong các tệp văn bản phẳng. Hoặc có thể đó chỉ là một ngách? Tôi dường như thấy nó rất hữu ích và hữu ích cho việc gỡ lỗi để so sánh các bản ghi thực thi chương trình khổng lồ và xác định một hoặc hai chi tiết đã thay đổi.

Các công cụ định hình hiệu suất cũng rất tốt để có, đặc biệt là khi bạn chạm vào một nút thắt quan trọng, nhưng có vẻ như rất ít người quen thuộc với chúng (và tôi thừa nhận mình có bằng cấp trong danh mục này).

Các công cụ XML tốt là rất quan trọng - nếu bạn đang làm việc với các tệp XML hơn một chục hoặc nhiều lược đồ. Đôi khi bạn cần nhiều hơn chỉ là cú pháp cơ bản làm nổi bật các trình soạn thảo khác cung cấp. Ngoài ra khi làm việc với XML, học XSL có thể rất hữu ích. Nhiều lần tôi thấy những gì có thể được thực hiện trong một biến đổi XSL đơn giản được thực hiện trong nhiều dòng trong mã của ứng dụng. Mặc dù cần làm rõ: Tôi không gợi ý rằng chính XML là một "công cụ lập trình được đánh giá thấp"; Tôi đề nghị rằng giá trị của các trình soạn thảo XML tốt được đánh giá thấp, từ những gì tôi đã thấy.

Biểu thức chính quy

Họ chỉ là rất hữu ích. Chúng giúp ích khi tìm kiếm thông qua các tệp nhật ký, phân tích văn bản, v.v. Chúng chỉ cực kỳ hữu ích.

Tôi thấy thật kỳ lạ khi có nhiều người tôi biết rằng họ chưa từng sử dụng chúng bởi vì có một chút đường cong học tập liên quan đến họ. Rất nhiều lần tôi thấy mọi người làm mọi thứ một cách khó khăn (Lưu ý: trước regex tôi đã làm mọi thứ một cách khó khăn) khi một regex đơn giản có thể nhanh chóng hạ gục nó.

Đồng đội của bạn. Khi bạn không có ý tưởng nóng bỏng nào đó và quên kết hợp nhóm của mình, bạn sẽ không bao giờ nghe thấy mối quan tâm hoặc ý tưởng của họ về lý do tại sao nó không hoạt động hoặc tại sao nó thậm chí còn tốt hơn.

Tôi nói điều này, bởi vì thật dễ dàng để nghĩ rằng lập trình là một thứ chống đối xã hội mà mọi người thực hiện ở các góc với những ý tưởng tuyệt vời của họ. Những người nghĩ rằng điều này đánh giá thấp giá trị của các đội và đồng đội của họ trong việc giúp thực hiện ý tưởng / dự án chìm / bơi.

Google. Có rất ít vấn đề chưa được giải quyết và ghi lại. Một truy vấn Google được điều chỉnh tốt có thể tiết kiệm cho mọi người rất nhiều thời gian.

Xa và xa công cụ được đánh giá thấp nhất để tìm "nút cổ chai" là Ctrl+ Choặc nút "Tạm dừng", trong trình gỡ lỗi.

Kiểm tra đoạn cuối của bài đăng này , và bài đăng này , và bài đăng này , để bắt đầu.

Rất nhiều lần tôi thấy / nghe thấy mọi người nói rằng "Chương trình quá chậm! Tôi có thể làm gì với nó? Tôi đã thử một hồ sơ (nếu họ đã làm), nhưng tôi không hiểu nó nói gì. Mọi người có đoán được không? Giúp tôi với! " Vâng, đoán chỉ là vậy. Những gì tôi đã luôn luôn làm, và những người khác cũng vậy, làm cho nó diễn ra, làm gián đoạn nó và kiểm tra ngăn xếp cuộc gọi. Nếu vấn đề thực sự tồi tệ, hãy chơi lô tô , nó ở ngay trước mặt bạn. Nếu vấn đề chỉ nhẹ, bạn làm điều đó nhiều lần. Bất cứ điều gì xuất hiện trên nhiều mẫu, mà bạn có thể tránh, là một nút cổ chai bạn có thể khắc phục.

Vâng, đây là downvote-mồi, nhưng nó hoạt động.

Loại công cụ lập trình nào bạn nghĩ là bị đánh giá thấp nhất? Thúc đẩy câu trả lời của bạn.

Trình biên dịch.

Hầu hết mọi người không dành thời gian để hiểu trình biên dịch lựa chọn của họ làm gì. Họ chỉ cảm thấy rằng nó làm cho mã thành một chương trình có thể chạy được và đó là tất cả những gì họ đi. Trên hầu hết các cấu hình hiện đại, có một số cấu hình mà bạn có thể cung cấp cho nó để làm cho nó làm những gì bạn cần. Đây là một ví dụ, tôi cá rằng một nửa các nhà phát triển trong văn phòng của bạn không biết làm thế nào để đặt cảnh báo là mức lỗi (giả sử nó thực sự có một). Những tùy chọn để bạn có để xuất các biểu tượng gỡ lỗi? Những tối ưu hóa nào (hoặc mức độ nào) mà bạn muốn nó thực hiện. Danh sách cứ kéo dài.

Bộ não của bạn. Các công cụ khác sẽ không có nhiều ý nghĩa nếu không có nó.

Tốt tuổi

print

Đôi khi, một trình gỡ lỗi hoặc trình lược tả hoặc sơ đồ luồng UML là hữu ích. Và đôi khi chúng làm bạn phát điên. Tôi luôn thấy mình rơi vào việc sử dụng các câu lệnh in (hoặc theo dõi hoặc NSLog hoặc những gì bạn có) chỉ để đảm bảo mã của tôi đang làm những gì tôi nghĩ nó đang làm khi tôi nghĩ nó đang làm điều đó.

Các tập lệnh cũ đơn giản ... cho dù chúng tôi phát triển bao nhiêu ngôn ngữ thế hệ tiếp theo, chúng tôi vẫn chủ yếu dựa vào các tập lệnh cũng có thể đạt được hầu hết các nhiệm vụ hàng ngày bằng cách viết một vài dòng tập lệnh.

Bút và bảng trắng.

Bạn không thể đánh bại công nghệ thấp khi cố gắng giải thích điều gì đó.

ack . Nó giống như grep -r, nhưng nó được thiết kế để tìm kiếm thông qua mã nguồn của bạn.

Perl và các ngôn ngữ kịch bản khác. Tuyệt vời cho các tác vụ hơi phức tạp đối với các công cụ GUI như Agent Ransack.

Phím tắt cho phép tái cấu trúc nhanh chóng, thường xuyên và an toàn. Tìm hiểu làm thế nào để trích xuất (hoặc nội tuyến, v.v.) các biến, phương thức, hằng hoặc các lớp khi nhấn một số khóa về cơ bản thay đổi cách tôi viết mã. Bạn sẽ chỉ tái cấu trúc thường xuyên (tức là đủ) khi chi phí là tối thiểu, do đó, làm cho các phím tắt này trở thành bản chất thứ hai là điều cần thiết để viết và duy trì mã tốt theo như tôi nghĩ.

Vì vậy, nói chung, sử dụng các công cụ tốt (IDE / trình soạn thảo) và tìm hiểu cách tận dụng tối đa các tính năng mà họ cung cấp.

Tiếp theo kiểm tra đơn vị và TDD, để giữ cho mã của bạn có thể kiểm tra được và ngăn ngừa sợ tái cấu trúc.

Sử dụng những thứ này và bạn sẽ dễ dàng chuyển sang viết mã bảo trì chính xác theo nguyên tắc DRY và tự ghi lại.

Kiểm thử đơn vị cung cấp các lợi ích sau:

• Các nhà phát triển trở thành khách hàng đầu tiên của mã. Một lỗi được phát hiện càng nhanh thì càng ít tốn kém để sửa chữa. Lỗi có thể bị bắt trước khi xây dựng, cài đặt hoặc triển khai .
• Kiểm tra thay đổi quan điểm của bạn về mã. Là thiết kế rõ ràng? Nó có xử lý các trường hợp góc?
• Hiệu ứng Hawthorne sẽ cải thiện chất lượng, chỉ đơn giản bằng cách thông báo rằng một nhóm đang xuất bản các số liệu kiểm tra chất lượng / thử nghiệm.
• Ngay cả khi các bài kiểm tra không được kiểm tra trong kiểm soát nguồn, chúng có thể là một cách tuyệt vời để khám phá và tìm hiểu địa hình mới.
• Xác suất cao có ít lỗi hơn!

Máy phát mã

Trình tạo mã có thể tạo ra một lượng lớn mã hiệu quả và không có lỗi từ một định nghĩa đơn giản. Việc sử dụng loại ORM là rõ ràng nhất để tạo các lớp truy cập dữ liệu, nhưng có nhiều cách sử dụng tiềm năng hơn.

Hỗ trợ tạo mã dường như vẫn còn ở giai đoạn sơ khai cả từ quan điểm lập trình viên và khung công tác, nhưng tôi tin rằng đó là thứ chúng ta sẽ thấy ngày càng nhiều. Trong .NET, bạn có thể bắt đầu học hỏi với công cụ CodeDOM .

Tôi sử dụng AgentRansack rất nhiều. Nó là một trợ giúp rất lớn tìm kiếm thông qua hàng ngàn tệp rất nhanh chóng. Nó đã tiết kiệm cho tôi rất nhiều thời gian, nhưng tôi không biết nhiều lập trình viên biết hoặc sử dụng nó.

Phương pháp hình thức.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

Thật khó để nói quá tầm quan trọng của họ. Mỗi vòng lặp và mọi câu lệnh if bắt đầu như một ý tưởng đòi hỏi một loại "bằng chứng" nào đó. Hầu hết các lập trình viên làm điều này bằng chứng hầu hết thời gian trong đầu của họ. Bạn hỏi câu lệnh if làm gì và chúng có thể nói rõ - một cách hợp lý và hợp lý - những lựa chọn là gì và tại sao các lựa chọn là hoàn chỉnh, nhất quán và độc quyền.

Nhưng một số chỉ có vẻ đoán ngẫu nhiên. Họ cần thêm trợ giúp và phương pháp chính thức có thể là loại trợ giúp họ cần.

Nó chỉ là đại số (và tính toán) cho mã. Không có gì quá phức tạp hay phức tạp.

Các mẫu thiết kế vật lý như rời khỏi ghế để chạy bộ nhanh dưới ánh sáng mặt trời và không khí trong lành giữ cho bộ não của chúng ta chạy ở mức cao nhất.

Vâng, đó là Half Life 2 (chèn trò chơi yêu thích của bạn vào đây). Nếu tôi gặp vấn đề, tôi không thể giải quyết, tôi chỉ cần thoát ra và bắt đầu chơi với trò chơi yêu thích của mình và đột nhiên giải pháp xuất hiện trong tâm trí tôi. Vì vậy, thành thật mà nói, nó không phải là một trò chơi hoặc một cái gì đó tương tự mà là làm một cái gì đó khác . Tôi thường thấy mọi người ngồi trên một vấn đề trong nhiều giờ mà không giải quyết được và tất cả những gì họ nên làm là đưa bộ não của họ ngoại tuyến trong một khoảng thời gian ngắn.

Stack Overflow - trợ giúp chuyên gia nhanh chóng khi bạn bị mắc kẹt

trang web câu hỏi và trả lời cho các lập trình viên chuyên nghiệp và đam mê. Nó được xây dựng và điều hành bởi bạn như một phần của mạng Stack Exchange của các trang web Hỏi & Đáp. Với sự giúp đỡ của bạn, chúng tôi sẽ cùng nhau xây dựng một thư viện các câu trả lời chi tiết cho mọi câu hỏi về lập trình ...

Tôi nghĩ rằng nó là Notepad / TextPad / chương trình chỉnh sửa văn bản đơn giản. Mọi người đều có lúc họ cần một bản sửa lỗi nhanh mà không cần mở IDE và chỉ cần chỉnh sửa nhanh. Và tất cả các máy tính có một số loại chương trình chỉnh sửa văn bản đơn giản.

Khẳng định và một alwaysAssert()chức năng tốt . IMHO những điều này quan trọng hơn các bài kiểm tra đơn vị, bởi vì các bài kiểm tra đơn vị chỉ có thể tìm thấy lỗi trong các trường hợp cụ thể mà bạn nghĩ sẽ kiểm tra. Nếu cùng một lập trình viên viết mã và các bài kiểm tra, anh ấy / cô ấy có thể sẽ bỏ lỡ các trường hợp cạnh giống nhau trong cả hai. Hơn nữa, đôi khi kiểm thử đơn vị là không thực tế vì môi trường trong đó các thành phần chức năng và / hoặc dữ liệu mà nó hoạt động quá phức tạp để đưa ra một trường hợp kiểm tra giả định.

Vẻ đẹp của các khẳng định nằm ở khả năng ghi lại các giả định và kiểm tra chúng trên các đầu vào không bị tước đoạt . Nếu bất kỳ giả định nào trong số này là sai, mã của bạn sẽ thất bại lớn thay vì "làm việc" nhưng tạo ra kết quả không chính xác. Nó cũng thất bại gần với gốc rễ của vấn đề hơn là không có sự khẳng định. Trong thực tế, nếu bạn nêu rõ các giả định đủ về một đoạn mã và tất cả các giả định này đều đúng thì mã thường đúng.

Một nắm bắt phổ biến về khẳng định là chúng có thể được tắt. IMHO mọi ngôn ngữ hoặc thư viện chuẩn phải có alwaysAssert()chức năng hoặc tương đương thô có chức năng tương tự assertnhưng không thể tắt được. Điều này có thể được sử dụng để kiểm tra các giả định trong các lĩnh vực quan trọng của mã không thực hiện, trong đó lợi ích của việc tắt các xác nhận là không đáng kể.

Phím F1. - Hữu ích cho các chương trình bạn không biết và cho các chương trình bạn đang làm việc. (Giả sử rằng đó là một ứng dụng lớn.)

Mạnh mẽ để lọc ra các vấn đề là người dùng báo cáo lỗi dựa trên cách giải thích của họ về cách phần mềm nên hoạt động. Tất nhiên, có thể là bản thân thiết kế đã bị lỗi. Nhưng nó là một câu chuyện khác.

Các tiện ích lõi UNIX khác nhau, nhưng chủ yếu findvà đôi khi grephoặc ed. Khả năng tìm thấy mọi thứ trong các tập tin sâu là vô giá, đặc biệt khi bạn đột nhiên thừa hưởng một cơ sở mã và phải sửa nó. Ngay cả khi mã được nói là tài liệu tốt, bạn có thể sẽ phải săn, và một sự hiểu biết mạnh mẽ về việc findgiết chết nó.

Tò mò

Gọi nó là "Câu đố về lập trình." Một công cụ so với người sử dụng nó là gì? Mong muốn biết làm thế nào và tại sao một cái gì đó làm hoặc không hoạt động mở rộng kiến ​​thức của một người nhiều hơn bất kỳ công cụ cụ thể nào và điều đó đúng ngoài lập trình.

Ctrl + C    
Ctrl + V

Tiết kiệm vô số giờ trên toàn thế giới!

Đuôi

Tail có thể được sử dụng để theo dõi tập tin đầu ra của chương trình trong thời gian thực. Nó đã giúp ích rất nhiều khi phát triển cho các hệ thống không cung cấp cho người khác phương tiện đọc nhật ký.

Chương trình ví dụ là;

• đuôi cho Unix.
• đuôi cho Mac.
• BareTail cho Windows.

Tôi đã kết hợp một trình tạo đồ thị cuộc gọi Perl một lần. Nó cực kỳ hữu ích, nhưng lại vất vả với các mã không theo thủ tục hoặc các thói quen ngoài tệp.