Nghi thức nguồn mở

Tôi đã bắt đầu làm việc với dự án nguồn mở đầu tiên của mình trên Codeplex và đã bắt gặp một số mã khủng khiếp. (Tôi đã biết rằng C # vẫn có câu lệnh "goto") Tôi bắt đầu thêm các tính năng mà "chủ sở hữu" muốn và sau khi khám phá cơ sở mã và xem nó là một mớ hỗn độn (ví dụ: sử dụng "goto") Tôi muốn dọn sạch nó một chút Nhưng tôi có một chút lo ngại và đó là lý do tại sao tôi chuyển sang tất cả các bạn: đó có phải là nghi thức đúng đắn để tôi "sửa" "mã xấu" hay tôi nên để nó hoạt động trên các tính năng mới? Như tôi đã nói trước đây, tôi mới tham gia vào toàn bộ bối cảnh OSS và làm việc trong một nhóm nói chung vì vậy tôi không muốn làm hỏng nó.

Bạn có thể làm điều này, nếu bạn khiêm tốn về điều đó và nó không phá vỡ bất cứ điều gì . Bạn không thể đi xung quanh việc định dạng lại mã và giới thiệu các lỗi. Liệu nó có bài kiểm tra đơn vị tốt? Nếu không, tôi sẽ bắt đầu đóng góp bằng cách thêm các bài kiểm tra đơn vị, rồi đi sửa cấu trúc sau.

Mục đích của nguồn mở là để có được nhiều mắt hơn vào một dự án và cải thiện nó. Điều đó bao gồm làm cho mã tốt hơn. Điều đó nói rằng, đó là hình thức tốt để quảng cáo trong danh sách những gì bạn định làm. Bạn có thể bị đẩy lùi hoặc bạn có thể nhận được một loạt +1. Những gototuyên bố đó có thể ở đó bởi vì tác giả ban đầu không thể nghĩ ra cách nào tốt hơn để hoàn thành công việc. Nếu bạn bị đẩy lùi, thật tốt khi nhập một hộp thoại để tìm hiểu áp lực đến từ đâu. Cố gắng không để nó trở nên cá nhân, và cố gắng giải quyết các mối quan tâm.

Tóm lại, bài kiểm tra đơn vị nói to hơn giáo điều. Nếu bạn có thể chứng minh rằng mã sẽ bị trục trặc trong một số trường hợp như hiện tại, bạn sẽ có được ngón tay cái hoặc tác giả ban đầu sẽ đi vào và sửa chữa mọi thứ.

Hãy nhớ rằng, trong nguồn mở, cộng đồng quan trọng hơn mã. Nếu không có cộng đồng (cả người dùng và nhà phát triển), thì không có dự án.

Những người ghen tị bảo vệ mã của họ thường không đăng nó cho thế giới xem xét kỹ lưỡng và nếu họ làm vậy, cộng đồng xung quanh nó sẽ không tồn tại được lâu. Hãy khéo léo, nhưng đừng băn khoăn rằng bạn sẽ làm tổn thương cảm xúc.

Chỉ cần nói với họ những gì bạn muốn làm trước khi bạn đầu tư quá nhiều thời gian vào nó. Đôi khi có những lý do lịch sử cho những điều không rõ ràng. Lý do gotos được tránh là chúng có thể tạo ra các đường dẫn không dự đoán được thông qua mã. Theo đó, mối nguy hiểm của việc loại bỏ gotos là bạn không nhận thấy một trong những con đường có lợi và vô tình bỏ qua nó từ bộ tái cấu trúc.

Mặt khác, có lẽ tác giả ban đầu không thể nghĩ ra một cách sạch hơn để viết nó vào thời điểm đó. Đây là nơi mã nói to hơn lời nói, bởi vì họ có thể không tin rằng nó có thể được thực hiện sạch hơn cho đến khi bạn hiển thị chúng. Một trong những đóng góp nguồn mở đầu tiên của tôi là sửa chữa ngăn xếp hoàn tác cải thiện đáng kể hiệu năng, nhưng một số nhà phát triển cốt lõi cho biết nghe có vẻ quá phức tạp khi tôi lần đầu tiên mô tả nó. Một mẫu mã ngắn mang chúng trên tàu.

Nếu nó thực sự có lý do tốt để bỏ nó vào, tôi sẽ đẩy ít nhất cho một bình luận giải thích những lý do đó.

Phát biểu từ kinh nghiệm ...

Dự án mã nguồn mở đầu tiên tôi đóng góp, tôi đầy đặn và dấm khi tôi mới bắt đầu.

Những gì tôi làm ngay lập tức là trải qua một loạt các tệp nguồn và bắt đầu cách điệu mọi thứ theo sở thích cá nhân của tôi, tạo ra một bản vá lớn và gửi nó.

Nếu bạn đang làm việc với ai đó 'tốt' (như tôi), anh ấy sẽ ngay lập tức từ chối bản vá. Chủ yếu là bởi vì, khi bạn đóng góp cho một dự án nguồn mở, bạn sẽ chia nhỏ các bản sửa lỗi của mình thành các phần có kích thước khớp cắn giải quyết một vấn đề duy nhất. 'Đã xóa tất cả các gotos' không phải là một ví dụ hay về cam kết nguyên tử. Ngay cả khi bạn chia nó thành các cam kết nhỏ hơn, được ghi chép đầy đủ trước tiên, nó vẫn có thể bị từ chối.

Lý do là bởi vì mã được làm việc bởi nhiều người (với các kiểu khác nhau) theo thời gian, việc chấp nhận các thay đổi trên toàn bộ thư viện để phù hợp với phong cách của một nhà phát triển là không khả thi. Nếu việc thay đổi phong cách vì lợi ích của phong cách là khả thi thì mọi dự án nguồn mở sẽ không bao giờ tiến lên vì mã sẽ liên tục được chỉnh sửa để phù hợp với các kiểu nhà phát triển khác nhau.

Tái cấu trúc mã và thêm chức năng (hoặc loại bỏ hành trình không dùng nữa) thường được ưu tiên hơn mã 'làm sạch'.

Phần khó nhất và bổ ích nhất khi làm việc trong một dự án nguồn mở là, bạn sẽ được hỏi tại sao bạn lại đề xuất thực hiện các thay đổi mà bạn đang gửi. Nếu bạn có thể đưa ra một lý do chính đáng thì sẽ có cơ hội tốt hơn rằng bản vá của bạn sẽ được gửi.

Lời khuyên của tôi là thực hiện một vài trong số những thay đổi này trên một tệp nguồn để đưa ra ý kiến ​​về những gì bạn đang cố gắng thực hiện trước tiên. Nếu các thay đổi được chứng minh và chấp nhận tốt, hãy hỏi nếu có nhiều thay đổi như nó sẽ cải thiện chất lượng của dự án. Bằng cách đó, bạn sẽ không lãng phí rất nhiều nỗ lực cho việc gì nếu bản vá của bạn bị từ chối trong tương lai.

Phát triển nguồn mở nhiều hơn viết mã. Bạn đang làm việc để xây dựng mối quan hệ tin cậy bởi vì những người gác cổng (nhà phát triển kiểm soát truy cập đẩy) sẽ làm những gì họ có để bảo vệ tính toàn vẹn của dự án. Khi bạn gửi thêm các bản vá, người gác cổng sẽ cảm nhận rõ hơn về phong cách của bạn và bạn sẽ không phải biện minh cho những thay đổi của mình nhiều như vậy.

Đó là một quá trình mất thời gian nhưng nó rất bổ ích. Không chỉ bạn sẽ học được rất nhiều từ việc có thể để xem xét, phê bình và mã của người khác không nhưng bạn sẽ được phê bình về phong cách của riêng bạn.

Trước khi bạn lãng phí rất nhiều thời gian để cố gắng 'sửa chữa sự bất công của các lỗi trong phong cách mã hóa của người khác', hãy tự hỏi điều này:

Là những thay đổi bạn đang đề xuất dựa trên việc tăng thêm giá trị cho dự án hay chúng dựa trên tôn giáo phong cách nội bộ của riêng bạn.

Có rất nhiều tôn giáo trên Stack Overflow (và các trang web Stack Exchange liên quan). Ý tôi là một rất nhiều . Mọi người nghĩ và nói về phong cách không ngừng, như thể bạn càng nói về nó, bạn càng tiến gần đến phong cách mã hóa 'hoàn hảo, lý tưởng, không thể phá hủy, không thể sai lầm'. Tôi nói về nó rất nhiều vì nó rất vui.

Trong thế giới mã nguồn mở, phong cách không quá quan trọng. Chức năng là .

Lưu ý: Tất cả những lời khuyên này đều cho rằng người gác cổng của bạn là một lập trình viên hợp lý và tài năng. Nếu anh ấy là, hãy tự cho mình may mắn rằng bạn đã không bị mắc kẹt với một trong những người da trắng b @ & # & es có mối quan tâm duy nhất là bảo vệ 'đứa con' của họ. Họ làm tồn tại trong môi trường tự nhiên, vì vậy đừng ngạc nhiên nếu bạn gặp phải một.

Chất lượng> Nghi thức

Theo tôi, bạn không nên lo lắng về việc chỉnh sửa mã của người khác ngay khi bạn phát hiện ra nó có chất lượng kém. Để đạt được chất lượng phần mềm tốt, bạn chỉ cần chăm sóc mã sạch. Tôi không thấy bất kỳ vấn đề nào với việc cam kết cải tiến mã của người khác, những người khác nên biết và biết ơn rằng có những lập trình viên làm việc với mã của họ.

Nếu bạn có thể tìm ra một cách tốt hơn để giải quyết vấn đề mà không cần sử dụng "goto", thì tôi khuyên bạn nên đi tìm nó. Một chút nỗ lực để làm cho mã tốt hơn ngày hôm nay có thể giúp bạn tiết kiệm nhiều nỗ lực hơn trong tương lai.

Giao tiếp với tác giả ban đầu cũng là một ý tưởng tốt.

Không có gì sai với goto. Nhìn vào mã lắp ráp - rất nhiều gotos (nhảy và các nhánh) ở khắp mọi nơi.

Lý do tại sao gotocó một tên xấu trong những ngày này là vì tuyên bố Go Toj của tờ Dijkstra được coi là có hại , trong đó xác định chính xác tuyên bố goto là một điều rất xấu.

Lưu ý rằng đó là 50 năm trước, nơi công nghệ phần mềm thậm chí chưa được đặt tên và hầu hết các ngôn ngữ lập trình về cơ bản là trừu tượng của máy cơ bản cũng như ngôn ngữ máy chứa goto, chúng cũng vậy. Bạn có thể thử lập trình một số trong Microsoft Basic (bản gốc, trên Apple] [hoặc Commodore 64) để có ý tưởng về cách suy nghĩ đó.

Điều Dijkstra đã tranh luận là để giữ mọi thứ đơn giản, đừng nhảy khắp nơi, mà thay vào đó hãy giữ một con đường chương trình đơn giản hơn với một kết thúc chung. Ví dụ, sự trở lại từ một phương thức. Nói cách khác - chỉ nhảy địa phương, không phải toàn cầu.

Đây là một bước để mang lại những thứ như các cuộc gọi phương thức với các đối số, mô đun hóa mã, các gói, v.v ... tất cả đã được giới thiệu để chế ngự sự phức tạp của phát triển phần mềm. Tuyên bố goto chỉ là người ngoài cuộc đầu tiên trong cuộc chiến đó.