Có phải vì tất cả đều được viết bằng các ngôn ngữ được quản lý, thu gom rác hơn là mã gốc?
Không. Mã chậm sẽ hoạt động kém bất kể. Chắc chắn, một ngôn ngữ cụ thể có thể giới thiệu một số loại vấn đề nhất định trong khi giải quyết những vấn đề khác. Nhưng các lập trình viên giỏi hoàn toàn có khả năng tìm ra cách giải quyết đủ thời gian.
Có phải các lập trình viên cá nhân đã viết phần mềm cho các thiết bị này?
Từng phần. Trong nhiều trường hợp, nó có khả năng ít nhất là một yếu tố góp phần. Đây là một tác dụng phụ đáng tiếc của một ngành công nghiệp nơi các lập trình viên giỏi có nhu cầu cao và nguồn cung ngắn. Ngoài ra, khoảng cách giữa các cấp độ khả năng kỹ thuật khác nhau có thể khá lớn. Vì vậy, lý do là đôi khi các lập trình viên được giao nhiệm vụ triển khai một số phần mềm nhất định có thể được chúc mừng chỉ để làm cho nó hoạt động (loại).
Trong tất cả các trường hợp này, các nhà phát triển ứng dụng biết chính xác nền tảng phần cứng họ đang nhắm mục tiêu và khả năng của nó là gì; họ đã không đưa nó vào tài khoản?
Từng phần. Để bắt đầu, nền tảng phần cứng chính xác có lẽ không được biết đến, vì điều đó thường được đàm phán với các nhà sản xuất khác nhau song song trong quá trình phát triển phần mềm. Trong thực tế, thậm chí có thể có những thay đổi nhỏ (nhưng không nhất thiết là không đáng kể) đối với phần cứng cơ bản sau khi phát hành ban đầu. Tuy nhiên, tôi đồng ý rằng các khả năng chung sẽ được biết đến.
Một phần của vấn đề là phần mềm có thể không được phát triển trên phần cứng, nó được thực hiện trong trình giả lập. Điều này gây khó khăn cho việc tính toán hiệu suất thiết bị thực sự ngay cả khi trình giả lập chính xác 100% - điều mà chúng không có.
Tất nhiên, điều này không thực sự biện minh cho việc kiểm tra không đủ trên phần cứng nguyên mẫu thích hợp trước khi phát hành. Sự đổ lỗi đó có lẽ nằm ngoài sự kiểm soát của dev / qa.
Có phải anh chàng đi khắp nơi lặp đi lặp lại "tối ưu hóa là gốc rễ của mọi tội lỗi", anh ta có khiến họ lạc lối không?
Không. Tôi chắc chắn rằng họ không nghe lời anh ta; nếu không, anh ta sẽ không bị trích dẫn sai thường xuyên (điều đó được cho là " tối ưu hóa sớm ..."). : -D
Nhiều khả năng có quá nhiều lập trình viên thực hiện một trong 2 thái cực liên quan đến tối ưu hóa.
- Hoặc là họ hoặc bỏ qua nó hoàn toàn.
- Hoặc họ ám ảnh mình với những chi tiết vụn vặt không liên quan gì đến các yêu cầu thực hiện thực tế . Hiệu quả ròng là ngân sách hết và mã quá bị xáo trộn để tối ưu hóa các vấn đề hiệu suất thực sự một cách an toàn.
Có phải đó là một tâm lý của "oh nó chỉ là thêm 100ms" mỗi lần cho đến khi tất cả những mili giây đó cộng lại thành vài phút?
Có thể. Rõ ràng nếu Sleep(100)đã được sử dụng như là giấy tương đương được sử dụng để làm chậm chảy máu chân tay bị cắt đứt - thì vấn đề sẽ được dự kiến. Tuy nhiên, tôi nghi ngờ vấn đề còn tinh tế hơn thế.
Vấn đề là phần cứng máy tính hiện đại (bao gồm cả các thiết bị nhúng) nhanh hơn nhiều so với việc mọi người cho họ tín dụng. Hầu hết mọi người, ngay cả các lập trình viên "có kinh nghiệm" đều không đánh giá cao máy tính nhanh như thế nào. 100ms là một thời gian dài - một thời gian rất dài . Và khi nó xảy ra, "thời gian rất dài" này cắt giảm 2 cách:
- Đầu tiên là các lập trình viên lo lắng không cần thiết về những điều mà máy tính làm cực kỳ nhanh chóng. (Điều đó xảy ra rằng đó chỉ là một mối quan tâm " tăng giá trị 300 lần mỗi giây " đã đưa tôi đến đây ngay từ đầu.)
- Thứ hai là đôi khi họ không thể hiện sự quan tâm đúng mức khi mọi thứ mất một thời gian rất dài (trên thời gian tính toán). Vì thế:
- nếu họ bỏ qua ảnh hưởng của độ trễ khi giao tiếp qua mạng hoặc với thiết bị lưu trữ;
- nếu họ bỏ qua tác động của một luồng bị chặn và chờ đợi một luồng khác;
- nếu họ quên rằng vì máy tính hoạt động quá nhanh, nó rất có khả năng lặp lại một nhiệm vụ thường xuyên hơn mức cần thiết, mà không có nhà phát triển nhận thức được vấn đề
- ... Nếu có bất kỳ sự kết hợp nào của quá mức như vậy xảy ra, một thói quen sẽ bất ngờ chạy rất chậm (theo thời gian tính toán). Một vài lần lặp lại và nó thậm chí sẽ được con người chú ý - nhưng có thể rất khó để xác định vì hàng trăm thứ liên kết với nhau đều tự chạy một cách nhanh chóng.
Có phải lỗi của tôi, vì đã mua những sản phẩm này ngay từ đầu?
Vâng chắc chắn. Vâng, không phải cá nhân bạn mà là người tiêu dùng nói chung. Sản phẩm được bán (và mua ) theo danh sách kiểm tra tính năng. Quá ít người tiêu dùng đang đòi hỏi hiệu suất tốt hơn.
Để minh họa quan điểm của tôi: Lần cuối cùng tôi muốn mua một chiếc điện thoại di động, cửa hàng thậm chí không thể cung cấp một mô hình demo để chơi với tại cửa hàng. Tất cả những gì họ có là vỏ nhựa có nhãn dán để hiển thị màn hình trông như thế nào. Bạn thậm chí không thể cảm nhận được trọng lượng như thế - hãy để một mình hiệu suất hoặc khả năng sử dụng. Quan điểm của tôi là nếu đủ người phản đối mô hình kinh doanh đó và bỏ phiếu bằng ví của họ để lên tiếng phản đối, chúng tôi sẽ là một bước nhỏ đi đúng hướng.
Nhưng họ không, vì vậy chúng tôi không; và mỗi năm điện thoại di động mới chạy chậm hơn trên phần cứng nhanh hơn.
(Những câu hỏi không được hỏi.)
- Là người tiếp thị để đổ lỗi? Từng phần. Họ cần ngày phát hành. Và khi nói ngày hiện ra lờ mờ, sự lựa chọn giữa "làm cho nó hoạt động" và "làm cho nó nhanh hơn" là không có trí tuệ.
- Là người bán hàng để đổ lỗi? Từng phần. Họ muốn nhiều tính năng hơn trong danh sách kiểm tra. Họ thổi phồng danh sách tính năng và bỏ qua hiệu suất. Họ (đôi khi) đưa ra những lời hứa không thực tế.
- Là người quản lý để đổ lỗi? Từng phần. Các nhà quản lý thiếu kinh nghiệm có thể mắc nhiều sai lầm, nhưng ngay cả những người quản lý có kinh nghiệm cũng có thể (hoàn toàn đúng) hy sinh thời gian để giải quyết các vấn đề về hiệu suất có lợi cho những mối quan tâm khác.
- Là thông số kỹ thuật để đổ lỗi? Từng phần. Nếu một cái gì đó bị bỏ qua đặc điểm kỹ thuật, việc "quên" về nó sau này sẽ dễ dàng hơn nhiều. Và nếu nó không được nêu cụ thể, mục tiêu là gì? (Mặc dù cá nhân tôi tin rằng nếu một đội tự hào về công việc của mình, họ sẽ lo lắng về hiệu suất bất kể.)
- Là giáo dục để đổ lỗi? Có lẽ. Giáo dục có thể sẽ luôn luôn ở phía sau. Tôi chắc chắn không chấp nhận "giáo dục" mà nhanh chóng tạo ra những người mới bắt đầu với sự phát triển phần mềm hiểu biết hời hợt. Tuy nhiên, giáo dục được hỗ trợ bởi lý thuyết và thấm nhuần văn hóa học tập không thể xấu.
- Là nâng cấp để đổ lỗi? Từng phần. Phần mềm mới, phần cứng cũ thực sự là định mệnh hấp dẫn. Ngay cả trước khi phiên bản X được phát hành, X + 1 đang trong kế hoạch. Phần mềm mới tương thích, nhưng phần cứng cũ có đủ nhanh không? Nó đã được thử nghiệm? Một bản sửa lỗi hiệu năng cụ thể có thể được đưa vào phần mềm mới - khuyến khích nâng cấp phần mềm không đúng cách.
Về cơ bản, tôi tin rằng có nhiều yếu tố đóng góp. Vì vậy, thật không may, không có viên đạn bạc để sửa nó. Nhưng điều đó không có nghĩa là nó cam chịu và u ám. Có nhiều cách để góp phần cải thiện mọi thứ.
Vì vậy, tại thời điểm nào mọi thứ đã đi sai cho các sản phẩm này?
IMHO chúng tôi không thể thực sự xác định bất kỳ điểm duy nhất. Có nhiều yếu tố đóng góp phát triển theo thời gian.
- Quầy đậu: cắt giảm chi phí, thời gian thị trường. Nhưng sau đó một lần nữa chúng ta sẽ thực hiện những tiến bộ chúng ta đã đạt được mà không có áp lực?
- Nhu cầu cao và nguồn cung thấp của những người có kỹ năng trong ngành. Không chỉ các lập trình viên, mà cả các nhà quản lý, người thử nghiệm và thậm chí là nhân viên bán hàng. Thiếu kỹ năng & kinh nghiệm dẫn đến sai lầm. Nhưng sau đó một lần nữa nó cũng dẫn đến việc học.
- Công nghệ chảy máu cạnh. Cho đến khi một công nghệ trưởng thành, nó sẽ thường xuyên cắn theo những cách không ngờ tới. Nhưng sau đó một lần nữa nó thường cung cấp một số lợi thế ở nơi đầu tiên.
- Biến chứng phức tạp. Theo thời gian, ngành công nghiệp đã phát triển: thêm nhiều công cụ, công nghệ, lớp, kỹ thuật, trừu tượng, phần cứng, ngôn ngữ, biến thể, tùy chọn. Điều này khiến cho phần nào không thể có sự hiểu biết "đầy đủ" về các hệ thống hiện đại. Tuy nhiên, kết quả là chúng tôi cũng có khả năng làm được nhiều hơn trong thời gian ngắn hơn rất nhiều.
Chúng ta có thể làm gì để lập trình viên làm gì để tránh gây ra nỗi đau này cho chính khách hàng của mình?
Tôi có một vài gợi ý (cả kỹ thuật và phi kỹ thuật) có thể giúp:
- Trong sofar càng tốt - sử dụng sản phẩm của riêng bạn. Không có gì giống như trải nghiệm đầu tay để tiết lộ những điều khó xử, chậm chạp hoặc bất tiện. Tuy nhiên, bạn sẽ cần có ý thức tránh bỏ qua những thiếu sót do "kiến thức nội bộ". Ví dụ: Nếu bạn không gặp vấn đề gì khi đồng bộ danh bạ vì bạn làm điều đó với tập lệnh Python backlink - bạn không sử dụng "sản phẩm". Điều này dẫn đến điểm tiếp theo ...
- Lắng nghe người dùng của bạn (tốt nhất là người đầu tiên, nhưng ít nhất là người thứ hai thông qua hỗ trợ). Tôi biết các lập trình viên (nói chung) thích ở xa và tránh sự tương tác của con người; nhưng điều đó không giúp bạn khám phá những vấn đề mà người khác gặp phải khi sử dụng sản phẩm của bạn. Ví dụ: Bạn có thể không nhận thấy rằng các tùy chọn menu chậm, bởi vì bạn biết tất cả các phím tắt và sử dụng riêng các phím tắt đó. Ngay cả khi hướng dẫn sử dụng đầy đủ tất cả các phím tắt, một số người vẫn sẽ thích các menu - mặc dù bị chậm một cách khó tin.
- Phấn đấu để cải thiện kỹ năng và kiến thức kỹ thuật của bạn một cách liên tục. Phát triển kỹ năng để phân tích phê bình mọi thứ bạn học. Đánh giá lại kiến thức của bạn thường xuyên. Trong một số trường hợp, hãy chuẩn bị để quên những gì bạn nghĩ bạn đã biết. Điều này dẫn đến ...
- Một số công nghệ / kỹ thuật có thể rất phức tạp dẫn đến những hiểu lầm tinh vi và triển khai không chính xác. Những người khác thông qua sự phát triển của kiến thức phổ biến hoặc các công cụ có sẵn có thể rơi vào hoặc không được ủng hộ (ví dụ: Singletons). Một số chủ đề khó đến nỗi họ tạo ra một loạt các "học giả h Focus-p Focus" truyền bá một cơ thể thông tin sai lệch khổng lồ. Một lỗi đặc biệt của tôi là thông tin sai lệch xung quanh đa luồng. Một triển khai đa luồng tốt có thể cải thiện đáng kể trải nghiệm người dùng. Thật không may, rất nhiều cách tiếp cận sai đối với đa luồng sẽ làm giảm đáng kể hiệu năng, tăng các lỗi thất thường, tăng rủi ro khóa chết, làm phức tạp việc sửa lỗi, v.v.
- Lấy quyền sở hữu. (Không nghiêm túc, tôi không chơi lô tô trong phòng họp.) Đàm phán với người quản lý, chủ sở hữu sản phẩm, nhân viên bán hàng về các tính năng hiệu suất được ưu tiên hơn một số mục trong danh sách kiểm tra. Yêu cầu thông số kỹ thuật tốt hơn. Không phải trẻ con, mà bằng cách đặt câu hỏi khiến mọi người nghĩ về hiệu suất.
- Hãy là một người tiêu dùng sành điệu. Chọn điện thoại có ít tính năng hơn nhưng nhanh hơn. (Không phải CPU nhanh hơn, UI nhanh hơn.) Sau đó hãy khoe về nó ! Càng nhiều người tiêu dùng bắt đầu yêu cầu hiệu suất, càng nhiều quầy đậu sẽ bắt đầu lập ngân sách cho nó.