Khi Voi PostgreSQL tiếp tục
tiến tới một bản phát hành khác, tôi đã suy nghĩ khá nhiều
về vai trò của người dùng phần mềm thiết kế giao diện người dùng
của nó. Hôm nay, tôi đã đề xuất một điều gì đó khiến tham số cơ sở dữ liệu mà mọi người
từng phải lo lắng và điều đó không rõ ràng chút nào
về cách đặt và làm cho giá trị của nó phần lớn là tự động. Đó là một thay đổi khá rõ ràng
rõ ràng; người dùng khó chịu, hành vi mặc định tốt
được thiết lập và hành vi mặc định đó được đề xuất dưới dạng bản vá. Nếu nó được áp dụng, tôi sẽ rất sốc khi phát hiện ra bất kỳ ai coi đó là một quyết định
tồi tệ.
Đã có một cuộc thảo luận tương tự về
cách làm lại giao diện người dùng xung quanh các điểm kiểm tra cơ sở dữ liệu. Hiện tại, tốc độ ghi dữ liệu vào đĩa bằng một điểm kiểm
định bị ảnh hưởng bởi ba giá trị mà người dùng có thể chỉ định. Sự tương tác
giữa những thứ này được ghi lại đủ tốt, mặc dù theo cách
phản ánh mức độ phức tạp và một số người dùng nhận thấy hành vi mà nó cung cấp
thực hiện tốt. Rất có thể để làm cho mọi thứ trở nên
tốt hơn cho người dùng thông thường, sẽ có một hồi quy
về hiệu suất trong một số trường hợp liên quan đến mã hiện tại. Việc sử dụng
cách triển khai khác làm thay đổi quy mô hiệu quả của các thông số
sẽ dẫn đến những thay đổi nhỏ về thời gian và chúng sẽ không
nhất thiết phải tích cực. Trong tình huống này, điều tốt nhất chúng ta có thể làm
với tư cách là một cộng đồng phát triển là thu thập đủ dữ liệu điểm chuẩn để thực hiện
lời kêu gọi đó. Có thể là việc cải thiện các tình huống xấu nhất
làm mất đi một chút mọi thứ so với việc thực hiện trước đó. Nếu
kết quả ròng trở nên dễ điều chỉnh hơn – thay thế nhiều
cài đặt phức tạp bằng một cài đặt duy nhất, như tôi đã đề xuất có thể là hướng đi đúng
ở đây – trung bình thì điều đó sẽ tốt hơn. Đôi khi, cần phải từ bỏ cách tiếp cận cũ để có được
một cách tiếp cận tốt hơn.
Nhưng đây là mức độ chúng tôi lo ngại
về hành vi vi phạm mà người dùng dựa vào. Tập trung nhiều vào khả năng tương thích ngược
và chỉ thêm những thứ theo cách không
loại bỏ phương pháp tiếp cận cũ trong quá trình phát triển PostgreSQL. Đôi khi, không có
sự lựa chọn nào khác:bạn phải thúc đẩy một cách tiếp cận mới. Trong những trường hợp
mà cả hành vi cũ và mới đều hoàn toàn chính đáng, thì việc đạt được ý kiến đa số rõ ràng là rất khó. Đó thường là trường hợp
trong thiết kế giao diện người dùng. Mặc dù bạn có thể đánh giá tiêu chuẩn đó bằng các công cụ và chuyên gia
phù hợp, nhưng điều này hiếm khi được thực hiện trong cộng đồng
nguồn mở. Rất khó để có được sự đồng thuận của cộng đồng từ sự hỗn hợp
của các ý kiến cá nhân.
Tôi đã được nhắc lại về cách không
xử lý phản hồi của người dùng với tư cách là nhà phát triển bằng cách nhận một số bản cập nhật hôm nay
về sự hồi quy gây khó chịu kéo dài trong cách gnome- thiết bị đầu cuối, thiết bị đầu cuối dòng lệnh ưa thích
danh nghĩa của tôi, xử lý nhập liệu bằng bàn phím. Vấn đề lần đầu tiên được đưa vào một báo cáo lỗi gần đúng hai năm trước, trên trình theo dõi
Ubuntu, chỉ để di chuyển đến nguồn
cơ bản của hồi quy:một sự thay đổi có chủ ý của một trong những GNOME các nhà phát triển
để loại bỏ hành vi mà họ thấy không phù hợp. Đã có một vé được mở yêu cầu sửa chữa, nhưng nó không bao giờ là sự xúc phạm đối với tất cả những người có liên quan.
Tôi đã hoạt động đủ tích cực trong lịch sử của vé
sau nên tôi không cần phải lặp lại lập luận của mình ở đây.
Về cơ bản, tất cả những gì tôi muốn là một tùy chọn cấu hình hộp kiểm để
có thể quay trở lại hành vi cũ. Tôi thậm chí còn bắt đầu
làm việc đó, đào sâu vào mã để đề xuất các giải pháp thay thế,
chỉ để nhận ra rằng không có cách nào mà điều này lại được hợp nhất. Những đề xuất
của tôi tập trung vào việc cố gắng tìm ra điểm chung có thể làm hài lòng tất cả mọi người. Rõ ràng là các nhà phát triển không
quan tâm đến điều đó. Họ đang làm theo cách họ thích và
mọi người khác không quan trọng. Rằng tôi đã được thông báo rằng sẽ mất “
vài trăm” lời phàn nàn trước khi điều này được coi là quan trọng
khiến tâm trí tôi bối rối, vì việc sử dụng phím điều khiển trong thiết bị đầu cuối
không phải là điều phổ biến nhất. . Đã có hàng chục báo cáo,
mọi khiếu nại nhận được đều được thống nhất trong cách giải quyết
ưu tiên và người duy nhất không đồng ý là một trong những nhà phát triển
của họ.
Chúng tôi nhận được một số phàn nàn từ mọi người rằng
cộng đồng PostgreSQL chứa đầy các nhà phát triển thích
các giải pháp thuần túy về mặt kỹ thuật hơn là chỉ cung cấp cho người dùng những gì họ muốn.
Điều đó đúng ở một mức độ nào đó, chẳng hạn như việc tiếp tục chống lại việc
thêm hiển thị bảng như một cách thay thế để tìm cơ sở dữ liệu
trong cơ sở dữ liệu của bạn. Nhưng tất cả cuộc thảo luận đó đều là những chủ đề mà cuộc thảo luận đưa ra nhiều ý kiến trái chiều nhau; nhiều người
có ý kiến đồng tình với cả hai phe. Nếu mọi người dùng đồng ý về một thiết kế
, trường hợp của vấn đề gnome-terminal này, việc từ chối
những ý kiến đó vì vẫn chưa đúng là chiều cao của sự kiêu ngạo của nhà phát triển
.
Một trong những ví dụ thú vị hơn về
loại điều này liên quan đến việc các nhà phát triển phần mềm Pidgin IM
thay đổi cách định cỡ văn bản cửa sổ trò chuyện trong chương trình.
Người dùng nổi dậy. Có một ví dụ điển hình về hành vi cũ và mới với một số
phân tích tại CodingHorror.
Mọi người đều cảm thấy ngạc nhiên trước cách các nhà phát triển
phớt lờ phản hồi của họ. Nhận thức của họ là
rằng phản hồi của cộng đồng không liên quan đến các nhà phát triển, bởi vì
họ cảm thấy thiết kế của họ tốt hơn thiết kế cũ bất kể người dùng nghĩ gì. Ai đó đã viết một trình cắm thêm để khôi phục hành vi
cũ. Và sau đó là một cuộc chia rẽ chính thức. Tuyên bố
sứ mệnh của đợt fork kết quả, ban đầu được gọi là “Fun Pidgin” và bây giờ
được gọi là “Carrier Instant Messenger”, là một bài đọc thú vị về cách họ cảm thấy
lấy người dùng làm trung tâm phát triển sẽ hoạt động.
Cuộc thảo luận về CodingHorror của Jeff Atwood
về điều này đã gợi ý bốn cách mà một ngã ba như vậy có thể xảy ra. Ông đã bỏ
ra một điều rất quan trọng:khả năng bằng cách chia rẽ các nỗ lực của cộng đồng
, cả hai ngã ba sẽ chết, không có đủ
nguồn lực để cạnh tranh với các lựa chọn thay thế. Trong khi Pidgin vẫn chưa
chết – còn một khoảng cách nữa là “chạy xuống rèm và tham gia
dàn hợp xướng bleedin 'invisibile” –chúng ít quan trọng hơn so với
trước đây, và toàn bộ sự sụp đổ này không giúp ích gì cho nguyên nhân của họ. Kể từ
Ubuntu 9.10, Canonical đã thay thế Pidgin làm ứng dụng khách IM chính
vận chuyển với bản phân phối Linux rất phổ biến đó. Thay vào đó, họ đặt
GNOME Empathy vào vị trí của nó. Liệu điều đó có còn xảy ra nếu cộng đồng
Pidgin không bị rạn nứt và trở nên gắn liền với những chiêu trò PR
tồi tệ như vậy không? Có thể, nhưng điều đó chắc chắn không giúp ích được gì cho trường hợp của họ.
Rằng những quyết định
người dùng thiếu hiểu biết tương tự đang được đưa ra liên quan đến một dự án GNOME phổ biến như
gnome-terminal thật thú vị (tôi cười khá thú vị than khóc) hướng tới
một tình huống tương tự. Hai tháng trước, người ta đã thông báo rằng Ubuntu đã
thay đổi đáng kể việc sử dụng ngăn xếp phần mềm GNOME đầy đủ trong bản phát hành tiếp theo của họ. Lưu ý rất cẩn thận những gì đã xảy ra ở đó.
Mark Shuttleworth cho biết họ đã thuê các nhà thiết kế giao diện người dùng chuyên nghiệp, đặt
họ làm việc để tìm ra cách hoạt động tốt hơn cho trải nghiệm
của người dùng máy tính để bàn, sau đó trình bày kết quả cho Cộng đồng GNOME.
Thay vì chấp nhận công trình vô cùng giá trị này và cảm ơn Canonical
vì đã thực hiện nghiên cứu đó, họ đã bác bỏ đủ những ý tưởng cơ bản mà
không có điểm trung gian nào có thể thực hiện được. Ubuntu hiện đang chuyển mình một cách
lớn đối với dự án Unity, như là con đường duy nhất còn lại để “làm những gì người dùng
của chúng tôi muốn”. Dựa trên sự tương tác của riêng tôi mà tôi đã có với các nhà phát triển GNOME
trong suốt nhiều năm kể từ khi tôi gặp phải sự phiền toái này, phản ứng
mà Mark nhận được không làm tôi ngạc nhiên một chút nào.
Chúng tôi vẫn chưa
rõ ràng việc chia tách Unity này sẽ diễn ra như thế nào. Điều tôi mong đợi là
rằng toàn bộ điều này cũng sẽ dẫn đến một loại tình huống
thất bại kép. Sẽ có một loạt các quá trình phát triển trùng lặp mà ban đầu
không tự nó tạo ra bất kỳ điều gì hữu ích. Các bản phát hành
đầu tiên sẽ có sự kiểm soát chất lượng khủng khiếp – điều này sẽ mất
mãi mãi mới đúng. Và bằng cách chia nhỏ cơ sở nhà phát triển, rất có thể
cả nhóm sẽ không còn đủ người để không bao giờ kết thúc
làm tốt công việc, khiến tất cả chúng ta có nhiều tùy chọn
máy tính để bàn Linux kém (một lần nữa) chứ không phải là một thể thống nhất mà tất cả mọi người đều được xếp hàng để
cải thiện. Tôi đã hy vọng rằng cách Nokia đã cải thiện
giấy phép cho Qt cuối cùng có thể thực hiện việc xem xét cách loại bỏ
việc có cả Qt + GNOME. Thay vào đó, Linux đang có một dự án
phát triển vượt trội và đặt tên cho nó là Unity of all things, là một
trò đùa khủng khiếp.
Nhưng tôi đang nói về cơ sở dữ liệu… một
điều thú vị về PostgreSQL là nó đã
tạo ra bao nhiêu fork. Giấy phép BSD hào phóng đã dẫn đến nhiều nhánh thương mại
mã nguồn đóng; Tôi đã từng làm việc tại một công ty làm
một. Netezza là hãng đầu tiên đưa gel vào sản xuất thương mại
nghiêm túc. Và Cơ sở dữ liệu Greenplum gần đây đã được EMC mua
, nó là một sản phẩm rất thành công. Điều đã không
xảy ra là bất kỳ nhánh mã nguồn mở nào trở thành sự thay thế khả thi
cho bản phân phối chính. Trừ khi bạn có đủ loại nguồn lực lớn
mà một công ty lớn có thể mang lại cho lĩnh vực kỹ thuật, thì việc thu hút cộng đồng chấp nhận ý tưởng của bạn sẽ dễ dàng hơn
so với việc thử
và thực hiện độc lập của họ. Cộng đồng thẳng thắn
PostgreSQL luôn là lựa chọn đúng đắn.
Cộng đồng PostgreSQL tranh luận rất nhiều,
và thù địch với rất nhiều điều mọi người yêu cầu; chúng tôi thậm chí có một
danh sách Chúng tôi Không muốn làm.
Đây là phần lớn những thứ không khả thi về mặt kỹ thuật
để xây dựng mà không có nhược điểm mà không phải lúc nào cũng rõ ràng đối với
những người yêu cầu chúng. Nếu người dùng đặt ra trường hợp tại sao một thay đổi sẽ
tạo ra giao diện người dùng tốt hơn cho một thứ gì đó trong cơ sở dữ liệu và
không có bất kỳ phản đối kỹ thuật nào về lý do tại sao nó sẽ gây ra sự cố,
thay đổi đó được xem xét. Điều tôi chưa từng thấy trong cộng đồng là
bất kỳ nhà phát triển nào đang xếp hàng chống lại sở thích
người dùng nhất trí, rõ ràng – nơi mà tùy chọn đó có thể được cung cấp mà không có
nhược điểm – đơn giản vì họ không thích nó theo cách đó. Nếu bạn là nhà phát triển
của một dự án mã nguồn mở đang lang thang đến nơi mà sự kiêu ngạo đã
lấn át sự khiêm tốn đến mức tệ hại, thì đừng ngạc nhiên nếu người dùng của bạn sẽ
giận dữ đến mức giảm bớt. Và một trong những ngày này, bạn có thể phát hiện ra rằng
các nhánh hoặc quá trình triển khai lại chú ý đến những gì mọi người
thực sự muốn sẽ khiến bạn thay thế.
