#30468 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:14
    * Mô tả triệu chứng của vấn đề hay lỗi mà bạn gặp cách rõ ràng.
    * Mô tả môi trường xảy ra sự cố (máy tính, hệ điều hành, các ứng dụng và những gì liên quan). Mô tả bản phân phối của bạn và phiên bản đang dùng (ví dụ: "Fedora Core 2'', "Slackware 9.1''...).
    * Mô tả các nghiên cứu mà bạn đã tiến hành để thử và tìm hiểu về vấn đề trước khi bạn đặt câu hỏi.
    * Mô tả các bước kiểm tra mà bạn đã tiến hành để thử và xác định vấn đề trước khi bạn đặt câu hỏi.
    * Mô tả tất cả các thay đổi về phần cứng và cấu hình phần mềm có thể liên quan tới sự cố.

Cố gắng tốt nhất để đoán trước các câu hỏi mà các hacker có thể hỏi và trả lời chúng trước khi yêu cầu sự giúp đỡ. Simon Tatham đã viết một bài tiểu luận tuyệt vời có tiêu đề là Làm thế nào để báo lỗi phần mềm thật hiệu quả(12) . Tôi khuyên các bạn nên đọc tài liệu này.

Mọi nẻo đường đều dẫn tới tương lai!
#30469 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:14
Bạn cần mô tả chính xác và đầy đủ thông tin. Điều này không có nghĩa là đổ một lượng lớn thông tin về mã nguồn hay dữ liệu vào một yêu cầu giúp đỡ. Nếu bạn có một trường hợp thử nghiệm phức tạp và nó làm cho chương trình không chạy nữa thì hãy cố gắng làm cho nó gọn lại và càng nhỏ càng tốt.

Điều này có lợi vì ít nhất 3 lý do. Một: bạn được xem là đã cố gắng làm cho câu hỏi trở nên đơn giản và thường là bạn sẽ có được câu trả lời. Hai: làm cho câu hỏi đơn giản hơn thường là làm cho bạn có câu trả lời hữu ích. Ba: trong quá trình trau chuốt câu hỏi của bạn có thể bạn tự tìm được cách khắc phục hoặc phương án khác.

Mọi nẻo đường đều dẫn tới tương lai!
#30470 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:15
Khi bạn gặp phải sự cố với một phần mềm thì đừng tuyên bố rằng bạn đã tìm ra lỗi trừ khi bạn rất chắc chắn về điều đó. Gợi ý: trừ khi bạn có thể cung cấp một đoạn mã nguồn có thể giải quyết sự cố hay một bước thử nghiệm hồi quy lại một phiên bản trước mà giải thích được sự hoạt động không bình thường của phần mềm đó thì bạn gần như là không chắc chắn lắm. Điều này áp dụng cho cả các trang web và các tài liệu khác, nếu bạn tìm thấy "lỗi'', bạn nên cung cấp một cụm từ thay thế và chỉ ra cần thay ở trang nào.

Hãy nhớ rằng, có rất nhiều người dùng khác không trải qua các vấn đề của bạn. Nếu không thì bạn đã có thể biết về nó trong khi đọc các tài liệu và tìm kiếm trên web (bạn đã làm thế trước khi bạn phàn nàn chứ?). Điều này có nghĩa thường là chính bạn làm gì đó sai chứ không phải phần mềm. Những người viết ra phần mềm đã làm việc rất vất vả để phần mềm có thể chạy tốt tới mức có thể.

Nếu bạn tuyên bố là bạn đã tìm ra lỗi thì bạn đã gián tiếp nói rằng họ đã làm gì đó sai và thường là bạn đã xúc phạm họ - thậm chí cả khi bạn đúng. Thực là không ý tứ tí nào khi la ầm lên trong tiêu đề thư là bạn đã tìm ra "lỗi''. Khi đặt câu hỏi, tốt nhất là viết như bạn đã làm gì đó sai, thậm chí trong thâm tâm bạn khá chắc chắn là bạn đã tìm ra lỗi thực sự. Nếu đó thực sự là lỗi thì bạn sẽ biết về nó trong câu trả lời. Hãy cư xử như vậy để người duy trì phần mềm sẽ xin lỗi bạn nếu có lỗi thật, còn không thì bạn sẽ nợ họ một lời xin lỗi vì bạn đã làm mọi thứ rối tung lên.

Mọi nẻo đường đều dẫn tới tương lai!
#30471 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:16
Một số người biết rằng không nên cư xử một cách thô lỗ hay kiêu ngạo khi yêu cầu một câu trả lời đã cư xử hoàn toàn ngược lại, tỏ vẻ khổ sở. "Tôi biết rằng tôi chỉ là một người thất bại đáng thương, nhưng...''. Điều này chỉ làm rối bời mọi thứ và hoàn toàn không nên. Nó đặc biệt là một sự quấy rầy nếu nó đi kèm với sự mơ hồ về vấn đề thực sự. Đừng làm phí thời gian của bạn cũng như của chúng tôi với những điều thô thiển như vậy.

Thay vì thế hãy diễn đạt bối cảnh của sự việc và câu hỏi của bạn thật rõ ràng tới mức bạn có thể. Đó là cách tốt hơn để tạo ra vị trí của bạn. Đôi khi các diễn đàn trên web có nhiều nơi riêng cho các câu hỏi của người mới bắt đầu. Nếu bạn cảm thấy bạn có câu hỏi của những người như vậy thì hãy tới đó. Nhưng cũng đừng dùng khổ nhục kế.

Mọi nẻo đường đều dẫn tới tương lai!
#30472 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:17
Sẽ chả có ích gì khi nói với hacker những điều bạn nghĩ đã gây ra vấn đề. (Nếu chẩn đoán tốt như thế thì tại sao bạn lại cần tư vấn người khác để tìm sự giúp đỡ?). Vì vậy nói với họ triệu chứng thực sự của những gì đã xảy ra sẽ tốt hơn là giải thích và chẩn đoán. Hãy để họ làm việc đó. Nếu bạn cảm thấy việc nói ra các suy đoán của bạn là quan trọng thì hãy nói rõ như thế và mô tả tại sao câu trả lời đó không giúp được bạn.

Ngu ngốc:
Tôi liên tục bị lỗi SIG11 khi biên dịch nhân, và cho rằng có một vết rạn nhỏ trên các vi mạch của bo mạch chủ. Đâu là cách tốt nhất để kiểm tra điều này?

Thông minh:
Cái máy tính tự lắp lấy của tôi dùng K6/233 trên bo mạch FIC-PA2007 (VIA Apollo VP2chipset) - với 256MB Corsair PC133 SDRAM - bắt đầu thường xuyên bị lỗi SIG11 khoảng 20 phút sau khi bật máy trong lúc đang biên dịch nhân, nhưng không bao giờ bị trong 20 phút đầu. Khởi động lại máy cũng không làm khởi động lại đồng hồ nhưng để máy tắt qua đêm thì có. Đẩy hết dữ liệu từ bộ nhớ sang phân vùng hoán đổi cũng không giúp gì. Sau đây là bản ghi của phiên biên dịch tiêu biểu.

Mọi nẻo đường đều dẫn tới tương lai!
#30473 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:17
Manh mối có ích nhất để tìm ra cái gì đã chạy sai thường nằm ở sự kiện xảy ra ngay trước nó. Vì vậy tài khoản người dùng của bạn có thể mô tả chính xác bạn đã làm gì và máy tính đã làm gì để dẫn đến việc đã xảy ra. Trong trường hợp xử lý các dòng lệnh thì có một bản ghi các phiên làm việc (ví dụ sử dụng ngôn ngữ kịch bản) và trích dẫn khoảng 20 dòng có liên quan thì sẽ rất hữu ích.

Nếu phần mềm gặp sự cố của bạn có lựa chọn chẩn đoán (ví dụ -v để hiển thị nhiều thông tin), hãy cố nghĩ cẩn thận về việc lựa các tùy chọn sẽ thêm các thông tin gỡ rối có ích vào bản ghi. Nếu tài khoản người dùng của bạn kết thúc quá dài (hơn bốn khổ), thì sẽ có ích hơn nếu mô tả ngắn gọn vấn đề của bạn lên đầu và sau đó là phần đuôi theo thứ tự thời gian. Làm theo cách đó các hacker sẽ biết cần phải tìm gì khi đọc qua tài khoản người dùng của bạn.

Mọi nẻo đường đều dẫn tới tương lai!
#30474 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:18
Nếu bạn đang cố gắng tìm hiểu thế nào để làm được một việc gì đó (ngược lại với báo cáo lỗi), hãy bắt đầu bằng việc mô tả mục tiêu cần thực hiện. Sau đó mới mô tả các bước mà bạn đã đi qua và bị vướng mắc. Thường thì người cần giúp đỡ về kỹ thuật thường có mục tiêu bậc cao và bị mắc kẹt trên con đường mà họ nghĩ là sẽ đi tới mục tiêu. Họ đến để tìm kiếm sự giúp đỡ cho các bước của họ mà không biết rằng con đường mà họ đã chọn là sai. Cần phải đầu tư rất nhiều nỗ lực để có thể vượt qua trở ngại này.

Ngu ngốc:
Làm thế nào để có được công cụ chọn mầu trong chương trình FooDraw để lấy được giá trị thập lục phân của màu RGB?

Thông minh:
Tôi đang cố thay bảng mầu trong một hình ảnh với các giá trị khác mà tôi đã chọn. Ngay bây giờ cách duy nhất mà tôi thấy có thể làm là sửa từng bảng mầu một nhưng tôi không làm sao dùng công cụ chọn mầu trong FooDraw's để lấy một giá trị thập lục phân của màu RGB.

Phiên bản thứ hai của câu hỏi là thông minh hơn. Nó cho phép câu trả lời gợi ý một công cụ phù hợp hơn cho công việc.

Mọi nẻo đường đều dẫn tới tương lai!
#30475 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:19
Hacker tin rằng giải quyết sự cố phải là một quá trình công khai và trong suốt trong đó câu trả lời đầu tiên có thể hoặc sẽ được chỉnh sửa nếu ai đó có kinh nghiệm hơn chỉ ra rằng nó chưa hoàn chỉnh hay chưa đúng. Hơn nữa họ còn được tán thưởng vì hành động suất xắc và sự hiểu biết của họ từ những đồng nghiệp. Khi bạn yêu cầu trả lời bằng thư riêng, bạn đã phá vỡ quá trình đó và sự tán thưởng. Đừng làm thế. Đó là quyền lựa chọn của người được hỏi rằng họ có trả lời bằng thư riêng hay không - và nếu anh ta làm thế thì thường là câu hỏi của bạn quá tệ hoặc quá hiển nhiên để gây chú ý cho nhiều người.

Chỉ có một trường hợp ngoại lệ cho quy tắc này. Nếu bạn nghĩ rằng câu hỏi của bạn sẽ nhận được rất nhiều câu trả lời giống nhau thì câu thần chú sẽ là "hãy trả lời riêng cho tôi bằng thư điện tử và tôi sẽ tóm tắt câu trả lời cho cả nhóm''. Thật là lịch sự để thử và giúp cho nhóm thư hay nhóm tin khỏi bị tràn ngập bởi các câu trả lời giống hệt nhau về căn bản - nhưng bạn phải giữ lời hứa là sẽ tóm tắt các câu trả lời.

Mọi nẻo đường đều dẫn tới tương lai!
#30477 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:20
Các câu hỏi không dứt khoát thường được hiểu là tốn thời gian vô ích. Thường là người có khả năng cho bạn câu trả lời hữu ích lại là người bận rộn nhất (nếu họ tự làm lấy các công việc đó). Những người như vậy thường rất dị ứng với việc tốn thời gian vô ích, vì vậy họ cũng dị ứng với các câu hỏi không dứt khoát. Bạn sẽ dễ có câu trả lời hữu ích nếu bạn dứt khoát về cái mà bạn muốn người trả lời giúp bạn (cung cấp chỉ dẫn, gửi mã nguồn, kiểm tra bản vá lỗi...). Điều này sẽ làm tập trung nỗ lực của họ và đặt một ranh giới cao hơn về thời gian và sức lực để giúp đỡ bạn. Điều này là tốt.

Để hiểu được thế giới mà các chuyên gia đang sống, hãy nghĩ rằng họ có dồi dào kinh nghiệm chuyên môn nhưng rất hiếm thời gian. Câu hỏi của bạn càng chiếm ít thời gian thì bạn càng có cơ hội có được câu trả lời từ ai đó rất giỏi và cũng rất bận rộn. Sẽ thật hữu ích nếu bạn gói gọn khuôn khổ câu hỏi của bạn sao cho các chuyên gia tốn ít thời gian nhất để trả lời - tuy nhiên điều này thường là không giống với việc đơn giản hóa câu hỏi.

Vì vậy, ví dụ như, "Anh có thể vui lòng cho tôi một chỉ dẫn về sự giải thích cho vấn đề X?'' thường là câu hỏi thông minh hơn là "Anh hãy vui lòng giải thích cho tôi vấn đề X?''. Nếu bạn có một đoạn mã nguồn không chạy thì sẽ là thông minh hơn nếu hỏi ai đó giải thích cái gì không đúng chứ không phải là nhờ họ sửa nó.

Mọi nẻo đường đều dẫn tới tương lai!
#30478 gửi bởi laser
Ngày 06 Tháng 04 2009 , 11:21
Các hacker có khả năng rất giỏi để nhận biết các câu hỏi trong bài tập về nhà; phần lớn chúng tôi đã làm chúng. Những câu hỏi đó là để bạn tìm ra cách giải quyết, và bạn sẽ có kinh nghiệm từ đó. Yêu cầu một chỉ dẫn thì không sao chứ đừng xin toàn bộ đáp án. Nếu bạn gặp phải câu hỏi trong bài tập về nhà mà không giải quyết được thì nên hỏi trong diễn đàn của người dùng hoặc trong diễn đàn "người dùng'' của dự án đó (như là một kế sách cuối cùng). Trong khi các hacker sẽ nhận ra đó là câu hỏi từ bài tập về nhà, nhưng ít nhất một số người dùng có kinh nghiệm có thể cho bạn vài lời chỉ dẫn.

Mọi nẻo đường đều dẫn tới tương lai!