Đánh giá phần mềm nguồn mở như thế nào

How To Evaluate Open Source Software

by Jon Buys - Sep. 22, 2012

Theo: http://ostatic.com/blog/how-to-evaluate-open-source-software

Bài được đưa lên Internet ngày: 22/09/2012

Lời người dịch: Bạn có muốn đánh giá xem liệu kho mã nguồn của một dự án phần mềm nguồn mở nào đó có khả năng được chấp thuận để đưa vào dự án của bạn hay không? Bạn có thể tuân theo các bước trong bài viết này.

Một trong những lợi ích tốt nhất đối với PMNM là cách mà nó có thể lấp đầy các khoảng trống khi phát triển các ứng dụng. Đúng lúc có ý nghĩa nhìn quanh để tìm ra liệu có ai đó khác đã giải quyết được vấn đề mà bạn đang nhòm ngó hay không, đặc bieettj nếu đó là một tính năng chung. Không may, không phải tất cả các dự án nguồn mở được xây dựng như nhau, và việc quyết định chấp thuận mã nguồn của ai đó khác vào trong dự án của bạn phải được cân nhắc thận trọng. Đây là 7 bước bắt đầu một mối quan hệ thành công dài hạn với một dự án nguồn mở.

Giấy phép

Điều đầu tiên để nhìn vào là giấy phép nào mã nguồn đã được tung ra theo. Nếu giấy phép không tương thích với dự án được mong đợi ở cuối cùng, thì thực sự không cần nhìn vào dự án đó xa hơn. Bạn có định phát hành dự án cuối cùng của bạn như là nguồn mở hay không? Nếu thế, thì là GPL hoặc một trong những họ hàng của nó có thể là phù hợp tốt. Mã nguồn GPL cũng thường được chấp nhận trong sử dụng trong các ứng dụng web, nơi mà bạn không phân phối lại dạng nhị phân cuối cùng và sản phẩm là dịch vụ mà ứng dụng đó cung cấp. Các giấy phép thân thiện hơn như BSD và Apache trao cho tác giả con đường để xây dựng bất kể thứ gì họ muốn, và phân phối nó bất kể họ muốn thế nào.

Hoạt động

Thứ nhì, hãy nhìn vào kho công cộng của dự án. Khi nào lần cuối nó được cập nhật? Hãy nhìn vào lịch sử đệ trình mã nguồn, dự án thường xuyên được cập nhật tới đâu? Nhiều lúc, một lập trình viên sẽ có một ý tưởng, ném cùng vào một kho và tung nó ra thế giới, và sau đó bỏ nó như một miếng khoai tây nóng và đi mất. Mã nguồn chạy nhanh, và nếu dự án bạn đang xem xét đã đi qua cả 1-2 năm mà không có cập nhật, thì hình như dự án đó đã bị bỏ rơi. Vẫn có khả năng là mã nguồn là tuyệt vời, nhưng nếu dự án đã bị bỏ rơi thì bạn thực sự cần yêu cầu chính bản thân mình nếu bạn có thiện chí nắm lấy nó.

One of the best benefits to open source software is how it can fill in the gaps when developing applications. At times it makes sense to look around and see if anyone else has already solved the problem you are looking at, especially if it is a common feature. Unfortunately, not all open source projects are built the same, and deciding to adopt someone else’s code into your project must be carefully considered. Here are seven steps to starting a successful long-term relationship with an open source project.

License

The first thing to look at is the what license the code has been released under. If the license is incompatible with the intended final project, there’s really no need to look at the project further. Do you intend to release your final project as open source? If so, than the GPL or one of it’s relatives might be a good fit. GPL code is also generally acceptable in use in web applications, where you are not redistributing a final binary and the product is the service the application provides. However, if you are planning on selling your application, avoid the GPL like the plague. Friendlier licenses like BSD and Apache give the author leeway to build whatever they like, and distribute it however they like.

Activity

Second, take a look at the project’s public repository. When was the last time it was updated? Look at the commit history, how often is the project updated? Many times, a developer will have an idea, throw together a repository and release it to the world, and then drop it like a hot potato and walk away. Code moves fast, and if the project you are looking at has gone for a year or two without an update, it’s likely that the project has been abandoned. It is still possible that the code is fantastic, but if the project has been abandoned you really need to ask yourself if you are willing to take it over.

Age of project

Tuổi của dự án

Phần mềm tốt nhất được lập qua thời gian, tiếp tục tốt hơn từng chút một (hoặc từng byte một chăng?) Nếu dự án bạn đang xem xét còn khá trẻ, ví dụ, ít hơn 1-2 năm, thì bạn có thể muốn cân nhắc xem một chút sâu hơn vào các dự án mà khán thính phòng và mục đích dự kiến. Mã nguồn mới có thể tốt, nhưng theo cá nhân, tôi không thích ý tưởng bất kỳ thứ gì ở bản thử nghiệm beta trong các dự án của tôi được đưa ra sản xuất. Thường là tốt hơn hãy để ai đó chiến đấu cật lực thêm nữa với mã nguồn trước khi bạn nhặt nó.

Các kiểm thử đơn vị

Các kiểm thử đơn vị là cực nhọc. Nếu tác giả hoặc các tác giả của một dự án nguồn mở mất thời gian để xây dựng các kiểm thử đơn vị trong nó, điều tốt lành hãy cược rằng họ đã định dựa án sẽ được sử dụng trong sản xuất. Sự hiện diện của những kiểm thử đơn vị là một chỉ số tốt của một dự án nghiêm túc, tuy nhiên, có qua thử thách mới biết hay dở thế nào, khi họ nói, sao cho bạn sẽ cần xem xét các kiểm thử đơn vị, và xem những gì chúng thực sự làm. Việc nhìn vào mã nguồn của các kiểm thử đơn vị mang tới cho tôi các điểm tiếp sau:

Chất lượng mã nguồn

Hãy bắt đầu duyệt qua mã nguồn. Nó làm việc thế nào? Nó được viết thế nào? Bạn có thấy bất kỳ lỗi lính mới nào rõ ràng không trong mã nguồn? Bất kỳ chỉ số nào bất kỳ ai đã viết nó thực sự không biết những gì họ đã làm? Khó đó mã nguồn của ai đó khác, nhưng nếu bạn định sẽ áp dụng dự án này về lâu dài, thì bạn sẽ cần phải biết những gì nó làm và cách nó làm việc. Nếu bạn không biết, thì bạn đang sắp có vấn đề, đặc biệt nếu bạn định sử dụng mã nguồn đó theo cách hơi khác với dự kiến ban đầu của các tác giả.

Kiểm thử sử dụng cơ bản

Sau khi theo đuổi mã nguồn cho tới khi bạn thoải mái với nó, thứ tiếp theo phải làm là xây dựng một dự án nhanh, ném ra mà không sử dụng gì ngoài sự tối thiểu cần thiết cần để kiểm thử rằng mã nguồn thực sự làm những gì nó nói nó phải làm. Liệu nó có biên dịch trong môi trường của bạn được không? Liệu có mọi thứ đặt đúng chỗ không? Nếu dự án là tốt thì nó sẽ có khả năng chỉ đi với một dự án con mà bày ra các khả năng của nó và miêu tả cách để tích hợp.

Kiểm thử sửa đổi - Kết thúc

Tôi cân nhắc kiểm thử tùy ý này, vì việc nhòm vào dự án để làm thứ gì đó ngoài những gì nó ngụ ý làm là thứ gì đó phiền muốn hơn so với nó đáng được thế. Tuy nhiên, nếu bạn biết rằng bạn sẽ cần làm vài sửa đổi, thì có thể đáng giá mất thời gian của bạn để làm nó bên ngoài dự án chính của bạn để xem cách mà mã nguồn hành xử. Liệu nó có bắt đầu vỡ ra theo các cách thức không mong đợi hay không? Liệu nó có thực sự là một thứ nhỏ bé dễ vỡ hơn so với mong đợi hay không? Hay, liệu nó có uốn và bẻ cong được để thích nghi được cho sử dụng ngoài mức qui định hay không?

Nếu bạn đi theo những chỉ dẫn đó, bạn có thể tin tưởng vào sự lựa chọn mã nguồn mở của bạn sẽ đưa được vào trong dự án chính của bạn. Nếu bạn có những ý tưởng hay những kinh nghiệm bổ sung, tôi thực sự muốn nghe về chúng trong các bình luận.

The best software is iterated on over time, continually getting a little better, bit by bit. (or is that byte by byte?) If the project you are looking at is fairly young, say, less than a year or two, you may want to consider looking a little deeper into the projects intended audience and purpose. New code can be good, but personally, I don’t like the idea of beta testing anything in one of my projects going into production. It’s generally better to let someone else battle harden the code before you pick it up.

Unit tests

Unit tests are hard. If the author or authors of an open source project took the time to build unit tests into it, it’s a good bet that they intended the project to be used in production. The existence of unit tests is a good indicator of a serious project, however, the proof is in the pudding, as they say, so you will need to take a look at the unit tests, and see what they actually do. Looking at the code of the unit tests brings me to the next point:

Code quality

Start browsing through the code. How does it work? How is it written? Do you see any obvious rookie mistakes in the code? Any indicators that whoever wrote it didn’t really know what they were doing? It is tough to read someone else’s code, but if you are going to be adopting this project for the long haul, you are going to need to know what it does and how it works. If you don’t, you are going to run into issues, especially if you intend to use the code in a way slightly different from the original authors intent.

Basic use test

After perusing the code till you are comfortable with it, the next thing to do is to build a quick, throw-away project that uses nothing but the absolute minimum needed to test that the code actually does what it says it does. Does it compile in your environment? Are the right hooks in the right places? If the project is good, it will probably come with just such a sub-project that showcases its capabilities and describes how to integrate.

Modification test - Finishing up

I consider this an optional test, since bending the project to do something outside of what it was meant to do is probably more trouble than it’s worth. However, if you know that you are going to need to do some modification anyway, it may be worth your time to do it outside of your main project to see how the code behaves. Does it start to break in unexpected ways? Is it actually a little more brittle than expected? Or, does it bend and flex to accommodate use outside of the norm?

If you follow these guidelines, you can be confident in your choice of open source code to include in your main project. If you have additional ideas or other experiences, I’d love to hear about them in the comments.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com