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

by Jon Buys - Sep. 22,2012

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

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

Lờingườ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ủabạn hay không? Bạn có thể tuân theo các bước trong bàiviế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òmngó hay không, đặc bieettj nếu đó là một tính năngchung. 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ấpthuận mã nguồn của ai đó khác vào trong dự án của bạnphả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ấyphép

Điều đầu tiên đểnhìn vào là giấy phép nào mã nguồn đã được tung ratheo. Nếu giấy phép không tương thích với dự án đượcmong đợi ở cuối cùng, thì thực sự không cần nhìn vàodự án đó xa hơn. Bạn có định phát hành dự án cuốicù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ấpnhận trong sử dụng trong các ứng dụng web, nơi mà bạnkhông phân phối lại dạng nhị phân cuối cùng và sảnphẩm là dịch vụ mà ứng dụng đó cung cấp. Các giấyphé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ìnvào kho công cộng của dự án. Khi nào lần cuối nó đượccậ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ềulúc, một lập trình viên sẽ có một ý tưởng, ném cùngvà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ạynhanh, và nếu dự án bạn đang xem xét đã đi qua cả 1-2nă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ệtvờ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ó.

Oneof the best benefits to open source software is how it can fill inthe gaps when developing applications. At times it makes sense tolook around and see if anyone else has already solved the problem youare looking at, especially if it is a common feature. Unfortunately,not all open source projects are built the same, and deciding toadopt someone else’s code into your project must be carefullyconsidered. Here are seven steps to starting a successful long-termrelationship with an open source project.

License

Thefirst thing to look at is the what license the code has been releasedunder. If the license is incompatible with the intended finalproject, there’s really no need to look at the project further. Doyou intend to release your final project as open source? If so, thanthe GPL or one of it’s relatives might be a good fit. GPL code isalso generally acceptable in use in web applications, whe-re you arenot redistributing a final binary and the product is the service theapplication provides. However, if you are planning on selling yourapplication, avoid the GPL like the plague. Friendlier licenses likeBSD 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 lasttime it was up-dated? Look at the commit history, how often is theproject up-dated? Many times, a developer will have an idea, throwtogether a repository and release it to the world, and then d-rop itlike a hot potato and walk away. Code moves fast, and if the projectyou are looking at has gone for a year or two without an up-date, it’slikely that the project has been abandoned. It is still possible thatthe code is fantastic, but if the project has been abandoned youreally need to ask yourself if you are willing to take it over.

Age of project

Tuổicủ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útmột (hoặc từng byte một chăng?) Nếu dự án bạn đangxem 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ự ánmà khán thính phòng và mục đích dự kiến. Mã nguồn mớicó thể tốt, nhưng theo cá nhân, tôi không thích ý tưởngbất kỳ thứ gì ở bản thử nghiệm beta trong các dự áncủa tôi được đưa ra sản xuất. Thường là tốt hơnhã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áckiểm thử đơn vị

Các kiểm thử đơnvị là cực nhọc. Nếu tác giả hoặc các tác giả củamột dự án nguồn mở mất thời gian để xây dựng cáckiểm thử đơn vị trong nó, điều tốt lành hãy cượcrằng họ đã định dựa án sẽ được sử dụng trongsả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, tuynhiê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ấtlượng mã nguồn

Hãy bắt đầu duyệtqua 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àngkhô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ảibiết những gì nó làm và cách nó làm việc. Nếu bạnkhông biết, thì bạn đang sắp có vấn đề, đặc biệtnếu bạn định sử dụng mã nguồn đó theo cách hơi khácvới dự kiến ban đầu của các tác giả.

Kiểmthử 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 theophải làm là xây dựng một dự án nhanh, ném ra mà khôngsử 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óinó phải làm. Liệu nó có biên dịch trong môi trường củabạ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ểmthử sửa đổi - Kết thúc

Tôi cân nhắc kiểmthử 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àmnó 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áccá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 haykhông? Hay, liệu nó có uốn và bẻ cong được để thíchnghi được cho sử dụng ngoài mức qui định hay không?

Nếu bạn đi theonhững chỉ dẫn đó, bạn có thể tin tưởng vào sự lựachọ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ữngkinh nghiệm bổ sung, tôi thực sự muốn nghe về chúngtrong các bình luận.

Thebest software is iterated on over time, continually getting a littlebetter, bit by bit. (or is that byte by byte?) If the project you arelooking at is fairly young, say, less than a year or two, you maywant to consider looking a little deeper into the projects intendedaudience and purpose. New code can be good, but personally, I don’tlike the idea of beta testing anything in one of my projects goinginto production. It’s generally better to let someone else battleharden the code before you pick it up.

Unittests

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

Code quality

Startbrowsing through the code. How does it work? How is it written? Doyou see any obvious rookie mistakes in the code? Any indicators thatwhoever wrote it didn’t really know what they were doing? It istough to read someone else’s code, but if you are going to beadopting this project for the long haul, you are going to need toknow what it does and how it works. If you don’t, you are going torun into issues, especially if you intend to use the code in a wayslightly different f-rom the original authors intent.

Basic use test

Afterperusing the code till you are comfortable with it, the next thing todo is to build a quick, throw-away project that uses nothing but theabsolute minimum needed to test that the code actually does what itsays it does. Does it compile in your environment? Are the righthooks in the right places? If the project is good, it will probablycome with just such a sub-project that showcases its capabilities anddescribes how to integrate.

Modification test - Finishing up

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

Ifyou follow these guidelines, you can be confident in your choice ofopen source code to include in your main project. If you haveadditional ideas or other experiences, I’d love to hear about themin the comments.

Dịch: Lê Trung Nghĩa

letrungnghia.foss@gmail.com