2009-03-25 30 views
6

Tôi nhớ phương pháp tiếp cận hiệu quả cũ của việc nghiên cứu một khuôn khổ mới. Nó luôn luôn là cách tốt nhất để đọc một cuốn sách tốt về chủ đề này, nói MFC. Khi tôi cố gắng bỏ qua rất nhiều tài liệu để tăng tốc mã hóa, hóa ra sau đó sẽ nhanh hơn để đọc toàn bộ cuốn sách trước. Không có cách nào tốt để nghiên cứu một khuôn khổ trong các phần nhỏ. Hoặc ít nhất là tôi không nhìn thấy chúng sau đó.Chiến lược hiệu quả để nghiên cứu khung/thư viện một phần

Những năm gần đây có rất nhiều điều mới đã xảy ra: kết quả tìm kiếm được cải tiến từ Google, blog lập trình, nhiều người tham gia thảo luận trên Internet, nhiều khung nguồn mở.

Ngay bây giờ khi chúng tôi viết phần mềm, chúng tôi thường phụ thuộc vào khung/thư viện của bên thứ ba (thường là nguồn mở). Và rất nhiều lần chúng ta chỉ cần biết một lượng nhỏ chức năng của họ để sử dụng chúng. Nó chỉ là tìm cách đơn giản nhất để sử dụng một tập hợp con nhỏ của thư viện mà không có sự bi quan không cần thiết.

Bạn làm gì để nghiên cứu ít nhất có thể của khung công tác và vẫn sử dụng hiệu quả?

Ví dụ: giả sử bạn cần lập chỉ mục một bộ tài liệu với Lucene. Và bạn cần làm nổi bật các đoạn trích tìm kiếm. Bạn không quan tâm đến thân cây, lưu trữ chỉ mục trong một tệp so với nhiều tệp, truy vấn mờ và nhiều nội dung khác sẽ chiếm bộ não của bạn nếu bạn nghiên cứu sâu về Lucene.

Vậy chiến lược, cách tiếp cận, thủ thuật để tiết kiệm thời gian của bạn là gì?

Tôi sẽ liệt kê những gì tôi sẽ làm, mặc dù tôi cảm thấy rằng quy trình của tôi có thể được cải thiện.

  • Tìm kiếm "hướng dẫn lucene", "ví dụ làm nổi bật lucene" và cứ tiếp tục như vậy. Hãy thử để ước tính số điểm tin cậy của các bài viết không chính thức (bài đăng trên blog) dựa trên ngày xuất bản, số lượng và giai điệu của nhận xét. Nếu không có câu trả lời nhất định - hãy thu thập các từ khóa và liên kết tìm kiếm mới trên mục tiêu.
  • Tìm kiếm hướng dẫn thực sự nhanh/hướng dẫn mới trên trang web chính thức
  • Ước tính giá trị của javadocs đối với người mới. (Đọc Lucene highlight package summary)
  • Tìm kiếm các ví dụ đơn giản đi kèm với thư viện, liên quan đến những gì bạn cần. (Nghiên cứu "src/demo/org/apache/lucene/demo")
  • Hỏi về "ví dụ làm nổi bật tìm kiếm Lucene đơn giản" trong danh sách thư Lucene. Bạn có thể nhận được không có câu trả lời hoặc thậm chí có được một danh tiếng xấu nếu bạn hỏi một câu hỏi ngớ ngẩn. Và thường thì bạn không biết liệu câu hỏi của bạn là ngớ ngẩn bởi vì bạn chưa nghiên cứu sâu về khuôn khổ.
  • Hỏi nó trên Stackoverflow hoặc dịch vụ QA khác ", bạn có thể cho tôi ví dụ làm việc về từ khóa tìm kiếm nổi bật trong Lucene" hay không. Tuy nhiên câu hỏi này rất cụ thể và có thể không có câu trả lời hoặc điểm số kém.
  • Ước tính mức độ dễ dàng nhận được câu trả lời từ mã khung nếu nó được mở nguồn.

Tuyến đường nghiên cứu/tìm kiếm của bạn là gì? Viết chúng theo thứ tự ưu tiên nếu có thể.

Trả lời

4

Tôi sử dụng kỹ thuật ba giai đoạn để đánh giá API.

1) Khám phá - Trong giai đoạn này tôi tìm kiếm StackOverflow, CodeProject, Google và Newsgroup với nhiều cụm từ tìm kiếm khác nhau nhất có thể và thêm mọi thứ phù hợp với nhu cầu của tôi vào một danh sách lớn.

2) Lọc/sắp xếp - Đối với mỗi mục tôi tìm thấy trong giai đoạn thu thập của tôi, tôi cố gắng tìm hiểu xem nó có phù hợp với nhu cầu của tôi hay không. Để làm điều này, tôi chuyển ngay vào tài liệu API và đảm bảo rằng nó có tất cả các tính năng tôi cần. Kết quả của điều này đi vào một danh sách trọng với các giải pháp tốt nhất ở đầu và tất cả các cruft lọc ra.

3) Nguyên mẫu - Tôi lấy vài ứng cử viên hàng đầu và cố gắng thực hiện một thử nghiệm nhỏ để đánh tất cả các tính năng quan trọng. Bất cứ điều gì phù hợp với dự án tốt nhất ở đây thắng. Nếu vì một lý do nào đó, một vấn đề xuất hiện với lựa chọn tốt nhất trong quá trình triển khai, có thể quay trở lại các triển khai khác.

Tất nhiên, một số lượng lớn các yếu tố đi vào việc chọn API tốt nhất cho dự án. Một số yếu tố quan trọng:

  1. Điều này sẽ tăng kích thước phân phối của tôi bao nhiêu?
  2. API phù hợp với kiểu mã hiện tại của tôi như thế nào?
  3. Sản phẩm có chất lượng cao/bất kỳ tài liệu nào không?
  4. Được sử dụng bởi rất nhiều người?
  5. Cộng đồng hoạt động như thế nào?
  6. Nhóm phát triển hoạt động như thế nào?
  7. Nhóm phát triển đáp ứng yêu cầu vá lỗi như thế nào?
  8. Nhóm phát triển có chấp nhận các bản vá của tôi không?
  9. Tôi có thể mở rộng nó cho phù hợp với nhu cầu của mình không?
  10. Sẽ tốn bao nhiêu để thực hiện tổng thể?

... Và tất nhiên còn nhiều hơn thế nữa. Nó phụ thuộc rất nhiều vào dự án.

Để tiết kiệm thời gian, tôi sẽ nói cố gắng tiết kiệm quá nhiều ở đây sẽ chỉ trở lại để cắn bạn sau này. Thời gian đưa vào lựa chọn một thư viện tốt ít nhất cũng quan trọng như thời gian thực hiện nó. Ngoài ra, suy nghĩ xuống đường, trong sáu tháng bạn sẽ được hạnh phúc hơn mã hóa hoặc bạn sẽ được tranh luận với một đội dev devophat :). Chi tiêu một vài ngày thêm bây giờ làm một đánh giá kỹ lưỡng về sự lựa chọn của bạn có thể tiết kiệm rất nhiều đau sau đó.

-1

Vậy chiến lược, cách tiếp cận, thủ thuật để tiết kiệm thời gian của bạn là gì?

Vâng, tôi tìm kiếm. Tôi thường không bao giờ đặt câu hỏi, thích nghiên cứu bản thân mình.Nếu tệ hơn tồi tệ hơn tôi sẽ đọc tài liệu. Trong một số trường hợp (nói rằng, khi tôi đang làm một số công việc với SharpSVN), tôi phải xem xét nguồn, cụ thể là các trường hợp thử nghiệm, để có được một số thông tin về cách API hoạt động.

Nói chung, tôi phải trung thực, hầu hết 'nghiên cứu' và 'học' của tôi là ngẫu nhiên.

Ví dụ: chỉ vài giây trước, tôi đã khám phá cách nhận thư mục "Gần đây" trong C#. Tôi không có ý tưởng làm thế nào để làm điều đó trước khi nhìn thấy câu hỏi, xem xét nó thú vị, và sau đó tìm kiếm.

Vì vậy, đối với tôi 'lừa đảo' thực sự là tôi treo lơ lửng trên diễn đàn, trả lời câu hỏi và vô tình nhặt kiến ​​thức. Sau đó, khi đến lúc tôi nghiên cứu một cái gì đó; cơ hội là tôi biết một chút về nó, và tìm kiếm dễ dàng hơn và tôi có thể tập trung vào việc thực hiện [thường thực hiện một chương trình thử nghiệm đầu tiên] và tiến triển từ đó.

+0

Tài liệu hầu như luôn tăng tốc sự hiểu biết. Ngoài ra treo xung quanh diễn đàn chắc chắn là không hiệu quả (câu hỏi của OP), nhưng một cách tốt đẹp để mở rộng kiến ​​thức web của bạn. – Griffin

1

1) Tìm kiếm Google cho nhiệm vụ của tôi

2) nhìn vào ví dụ với một vài thư viện khác nhau, không cần phải buộc bản thân mình xuống Lucene ví dụ, nếu tôi không biết những tùy chọn khác mà tôi có .

3) Nhìn vào ngày cập nhật cuối cùng trên trang chính, nếu nó chưa được cập nhật trong 6 tháng rời (với một số ngoại lệ)

4) Tìm kiếm các nhiệm vụ mẫu với thư viện (chưa đọc hướng dẫn)

5) Tôi có thể hiểu điều gì đang diễn ra mà không có hướng dẫn không? Nếu có tiếp tục nếu không bắt đầu lại 1

6) Cố gắng thực hiện các nhiệm vụ

7) Xem bản thân mình thất bại

8) Đọc một hướng dẫn

9) Cố gắng thực hiện công việc

10) Xem bản thân mình thất bại và yêu cầu trên StackOverflow hoặc gửi thư cho tác giả, đăng lên nhóm người dùng (nếu thân thiện)

11) Nếu tôi có thể hoàn thành công việc, tôi sẽ xem xét khuôn khổ đáng học và đọc hướng dẫn chính trong 2 giờ (nếu nó không vừa trong 2 giờ tôi chỉ bỏ qua những gì còn lại cho đến khi tôi cần nó)

1

Tôi không có công thức, theo nghĩa là tập hợp các bước tôi luôn theo dõi, phần lớn là vì mọi thứ tôi học đều khác nhau. Một số điều hoàn toàn mới đối với tôi (Dojo chẳng hạn, tôi không có sự lưu loát trong kịch bản Java nên đó là một nhiệm vụ lớn), một số cải tiến kiến ​​thức trước đây (Iknow EJB 2 tốt, vì vậy học EJB 3 trong khi trên bề mặt là mới với tất cả chú thích của nó, xây dựng trên các khái niệm.)

Chiến lược chung của tôi là tôi mô tả là "Xoắn ốc và Công viên". Trước tiên, tôi cố gắng khoanh tròn phong cảnh, hiểu hình dạng chung, tôi Công viên các khái niệm mà tôi không nhận được chưa, đừng để nó lo lắng cho tôi. Sau đó, tôi đi sâu hơn một chút vào một số khu vực, nhưng một lần nữa cố gắng không bị ám ảnh bởi một, Xoắn ốc vào chủ đề. Hy vọng rằng tôi bắt đầu unpark và hiểu, nhưng cũng cần phải đậu nhiều thứ hơn.

Ban đầu tôi muốn câu trả lời cho những câu hỏi như:

  • gì đó là gì?
  • Tại sao tôi nên sử dụng điều này thay vì điều khác mà tôi đã biết
  • Điều gì có thể? Bất kỳ điểm ngọt thú vị nào. "Ví dụ: ooh xem bản cập nhật AJAX có định hướng tốt đẹp"

Tôi thực hiện rất nhiều việc đọc lướt.

Sau đó, tôi muốn khám phá thêm về các bước nhảy. Tôi bắt đầu tìm kiếm gotchas và lời khuyên tốt. (Ví dụ: trong java:. Tại sao Equals "wibble" (var) một cấu trúc hữu ích?)

kỹ thuật cụ thể và các nguồn thông tin:

  • quan trọng nhất: làm! Càng sớm càng tốt, tôi muốn làm một hoặc hai hướng dẫn. Tôi có lẽ phải có mạch đầu tiên của xoắn ốc được thực hiện, nhưng sau đó tôi muốn liên lạc và thử nghiệm.
  • Tài liệu tổng quan
  • Tài liệu sản phẩm
  • Diễn đàn và nhóm thảo luận, học bằng cách trả lời câu hỏi là kỹ thuật yêu thích của tôi.
  • nếu có thể, tôi cố gắng tìm kiếm rất kinh nghiệm. Tôi may mắn có được những đồng nghiệp của mình ngay lập tức giàu kiến ​​thức và kinh nghiệm.
+0

+1 để theo dõi "gotchas". Chúng có thể trở thành rào cản lớn để hiểu sau này. – Griffin

1
  1. Hướng dẫn bắt đầu nhanh.
  2. Xem nhanh tài liệu API nếu có.
  3. Đọc mã mẫu.
  4. Lộn xộn xung quanh BẠN CÓ MESS AROUND (xin lỗi vì chữ hoa).

Nếu đó là một thư viện nhỏ/API có cộng đồng nhỏ hoặc không, bạn luôn có thể liên hệ với nhà phát triển và yêu cầu trợ giúp vì anh ấy có thể sẽ vui lòng giúp bạn; anh ấy vui vì một người nữa đang sử dụng API của mình.

0

Tôi sẽ không bao giờ đọc javadoc. Vì thường thì không có. Và khi có, rất có thể nó không được cập nhật. Vì vậy, một trong những bị lẫn lộn ở tốt nhất.

Bắt đầu với hướng dẫn đơn giản nhất có thể bạn tìm thấy trong vòng vài phút. Thường thì hướng dẫn sẽ dẫn bạn đến các nguồn khác ở phần cuối, vì vậy, phần lớn thời gian một là trên một con đường đi sâu hơn và sâu hơn.

2

Câu trả lời cho câu hỏi của bạn tùy thuộc vào nơi bạn rơi vào tính liên tục của tính tổng quát/tính đặc hiệu. Bạn có muốn giải quyết vấn đề ngay lập tức không? Bạn đang tìm kiếm để phát triển một sự hiểu biết sâu sắc về thư viện? Có thể bạn đang ở đâu đó giữa những thái cực đó. Jeff Atwood has a post về cách lập trình di chuyển giữa các cấp này, dựa trên nhu cầu của họ.

Khi lần đầu tiên bắt đầu, hãy đọc điều gì đó về thiết kế cấp cao của khung hoặc thư viện (hoặc ngôn ngữ hoặc bất kỳ công nghệ nào), tốt nhất là bởi một trong những nhà thiết kế.Hãy thử xác định những vấn đề mà họ đang cố gắng giải quyết, nguyên tắc tổ chức đằng sau thiết kế là gì và những tính năng chính là gì. Điều này sẽ hình thành khuôn khổ khái niệm mà từ đó sự hiểu biết trong tương lai sẽ treo.

Bây giờ hãy nhảy vào nó. Tạo một cái gì đó. Không sao chép và dán mã của ai đó. Thay vào đó, khi mọi thứ không hoạt động, hãy đọc thông báo lỗi chi tiết và trợ giúp về các thông báo lỗi đó và tìm hiểu lý do xảy ra lỗi. Nó có thể bực bội, khi mọi thứ không hoạt động, nhưng nó buộc bạn phải suy nghĩ, và đó là khi bạn học.

1

Danh sách gửi thư là tài nguyên tuyệt vời miễn là bạn làm bài tập ở nhà trước khi đặt câu hỏi.

Danh sách gửi thư lưu trữ là vô giá đối với hầu hết các câu hỏi tôi đã có về nội dung liên quan đến CoreAudio.

0

Nó thực sự phụ thuộc vào chủ đề là gì và lượng thông tin là chủ đề. Học theo ví dụ là một cách hay để bắt đầu một chủ đề hoàn toàn mới cho bạn, đặc biệt nếu bạn có kiến ​​thức về các thư viện hoặc ngôn ngữ tương tự khác. Bạn có thể lấy một chủ đề mà bạn quen thuộc và nói "Tôi hiểu cách triển khai bằng X, cho phép xem nó được thực hiện bằng cách sử dụng Y".

Các vấn đề liên quan