Có ổn không khi sống mà không biết chương trình bạn tạo ra hoạt động như thế nào?

Ý tôi là, có những lib thực sự hữu ích có thể giải quyết vấn đề khi bạn gặp khó khăn và không biết cách giải quyết vấn đề này hoặc bằng kiến ​​thức về ngôn ngữ lập trình bạn sử dụng ... Ví dụ: Boost for C ++ hoặc JQuery cho JavaScript hoặc Spring cho Java ... Họ giải quyết vấn đề trong vài giây và bạn không thực sự quan tâm họ đã làm như thế nào (mặc dù chúng được viết bằng chính ngôn ngữ bạn đang lập trình) ... Vì vậy, tôi tự hỏi có phải tôi đơn độc khi sử dụng lib trong khi không có khả năng viết giải pháp cho các vấn đề của tôi từ đầu hoặc đó là thông lệ tiêu chuẩn?

Có ổn không khi tự hiểu cách giải quyết vấn đề và sử dụng các thư viện thay thế?

Nói chung, không, không phải vậy.

Một thư viện có thể giúp bạn tiết kiệm công việc (khó!) Để tìm ra cách giải quyết vấn đề, sau đó gỡ lỗi giải pháp, và sau đó, duy trì nó. Nhưng, nếu bạn sẽ sử dụng nó, tốt hơn bạn nên đảm bảo rằng bạn hiểu cách thức hoạt động của nó - tại sao giải pháp thực sự giải quyết vấn đề. Bạn không cần phải biết cách phát minh ra ô tô, động cơ và robot chế tạo động cơ ô tô, nếu bạn làm thợ cơ khí - nhưng bạn sẽ hiểu rõ hơn về cách các bộ phận hoạt động, tất cả những gì chúng làm và cách chúng hợp nhau!

Đây là lý do tại sao bạn sẽ thấy nhiều người trở nên rất chuyên biệt - nhiều lần chỉ học cách làm việc với một ngôn ngữ, một nền tảng duy nhất, một khung duy nhất và một bộ thư viện.

Điều đó đang được nói, chỉ có rất nhiều bạn sẽ có thời gian để tìm hiểu. Đôi khi bạn phải dùng phím tắt - lấy chúng, nhưng biết chúng là phím tắt. Có lẽ bạn chỉ đọc đủ về một thư viện để biết bạn có thể tìm ra nó, nếu bạn có thời gian. Hoặc có thể bạn chỉ tìm ra hai chức năng mà bạn thực sự cần gọi và chỉ đủ để thực hiện các cuộc gọi một cách chính xác. Đó là một phím tắt, sẽ có giá - thường là sau này, khi ai đó (có thể là người lớn tuổi hơn và có kinh nghiệm hơn, bạn) phải sửa mã.

Có lần computerworld.com.au hỏi Bjarne Stroustrup "Bạn có lời khuyên nào cho các lập trình viên sắp tới không?"
Và anh ấy đã trả lời"Biết nền tảng của khoa học máy tính: thuật toán, kiến ​​trúc máy, cấu trúc dữ liệu, v.v. Đừng chỉ sao chép một cách mù quáng các ứng dụng từ ứng dụng này sang ứng dụng khác. Biết những gì bạn đang làm, nó hoạt động và tại sao nó hoạt động. biết ngành này sẽ ra sao sau 5 năm nữa hoặc bạn sẽ làm gì sau đó, vì vậy hãy tập hợp một danh mục các kỹ năng chung và hữu ích. Cố gắng viết mã tốt hơn, nguyên tắc hơn. Làm việc để "lập trình" nhiều hoạt động chuyên nghiệp hơn và ít hoạt động "hack" ở mức độ thấp (lập trình cũng là thủ công, nhưng không chỉ là thủ công). Học từ kinh điển trong lĩnh vực và sách giáo khoa nâng cao tốt hơn; không hài lòng với "cách" dễ tiêu hóa hướng dẫn và tài liệu trực tuyến - thật nông cạn. "
Hy vọng nó sẽ làm rõ nghi ngờ của bạn về những gì cần thiết cho mộtLập trình viên thực sự và những gì cần thiết cho bất cứ ai là một.

Vâng - và tất cả chúng ta đều làm điều đó!

Ví dụ, hãy lấy một lỗi rất đơn giản mà tôi đã sửa trong một số mã đồ họa liên quan đến Mac. Mã xung quanh lỗi liên quan đến một số bước:

1. Đầu tiên, một phương thức Objective C phân bổ bộ đệm pixel bằng cách sử dụng malloc () và gắn nó vào đối tượng Objective C của nó.
2. Sau đó, một cái gì đó xảy ra và một thường trình C gửi một thông điệp đến đối tượng Objective C và lấy bộ đệm pixel.
3. Thường trình C nén nội dung bộ đệm pixel bằng jpeglib và gửi nó qua kết nối TCP / IP.

Có rất nhiều điều tồi tệ đang diễn ra ở đó! Dưới đây là một vài điều:

• Một bộ cấp phát bộ nhớ động để thực hiện malloc (), giả sử bộ nhớ nằm liền kề nhau và có thể định vị tuyến tính.
• Hệ thống bộ nhớ ảo hạt nhân Darwin nằm bên dưới để ánh xạ cả RAM vật lý bị phân mảnh và không gian đĩa (là một thiết bị vật lý khác với RAM), thành một thứ xuất hiện cho bộ cấp phát bộ nhớ động như RAM liền kề và có thể định tuyến tính.
• Hệ thống đối tượng của C
• Hệ thống nhắn tin thời gian chạy Mac OS và cách nó tương tác với các đối tượng Objective C
• Việc triển khai thư viện jpeglib của thư viện jpeglib, sử dụng thuật toán biến đổi cosine rời rạc
• Thói quen kết nối không gian người dùng để gửi dữ liệu, gọi qua các triển khai giao thức TCP và IP khác nhau, lần lượt gọi vào nhân hệ điều hành. Sau đó, tùy thuộc vào những gì bạn đã bật cho mạng của mình, nó có thể gọi trình điều khiển cho cổng Ethernet, chip wi-fi hoặc bất thường hơn là trình điều khiển USB hoặc Firewire.

Bạn có hiểu tất cả các chi tiết về cách tất cả những điều đó được thực hiện? Tôi chắc chắn không! Tôi nghi ngờ có rất nhiều người trên hành tinh này - thậm chí có thể không có ai. Vì vậy, tôi không lo lắng về nó.

Nhưng đó là một điều tốt để tò mò, và để tìm hiểu ít nhất một chút về các thư viện và công cụ bạn sử dụng. Khi tôi mới bắt đầu lập trình, tôi biết trình biên dịch và hệ điều hành không thể là phép màu, nhưng chúng chắc chắn có vẻ như vậy với tôi. Bằng cách khơi gợi sự tò mò của tôi về những điều đó, tôi đã học được rất nhiều điều và có một sự nghiệp tuyệt vời cho đến nay.

Tôi tìm thấy lý do chính mà chúng tôi sử dụng các thư viện là không "phát minh lại bánh xe" mọi lúc, trừu tượng hóa các vấn đề họ dự định giải quyết. Bạn có thể cố gắng tự giải quyết vấn đề, nhưng điều đó sẽ mất nhiều thời gian hơn.

Tuy nhiên tôi cảm thấy rằng chúng ta cũng cần biết hoặc đoán xem vấn đề được thư viện giải quyết như thế nào. Điều này thường được ghi lại trong tài liệu người dùng của thư viện và với phần mềm nguồn mở, bạn luôn có thể tự mình xem mã.

Ngoài ra, chúng tôi thường giải quyết vấn đề bằng cách trừu tượng hóa những phần khó khăn, vậy tại sao nó không ổn?

Các thư viện đang ở đó để cung cấp giải pháp cho các vấn đề phổ biến. Bạn cần quyết định nếu họ giải quyết vấn đề cụ thể mà bạn đang giải quyết. Họ KHÔNG thay thế cho việc không biết cách giải quyết vấn đề. Ví dụ: giả sử ứng dụng của bạn yêu cầu bảng băm, bạn nên có đủ kiến ​​thức để hiểu vấn đề mà bảng băm đang giải quyết. Bạn sẽ có thể đánh giá hiệu suất của thư viện bạn đang sử dụng để quyết định xem nó có hoạt động trong ứng dụng của bạn hay không. Tôi tin rằng việc sử dụng một thư viện để trang trải cho kiến ​​thức kỹ thuật không đầy đủ không phải là trường hợp sử dụng chính xác. Quyết định sử dụng thư viện sẽ xoay quanh việc có sử dụng thư viện hay không sẽ tăng tốc độ phát triển và cung cấp giải pháp được kiểm tra và đáng tin cậy. Quyết định sử dụng thư viện không nên xoay quanh việc các lập trình viên không có khả năng giải quyết một vấn đề nhất định.

Tùy bạn .

Điều tốt nhất bạn hiểu các công cụ bạn đang làm việc với tốt hơn là bạn có thể tận dụng chúng.

Ví dụ, tôi hiếm khi sử dụng jQuery, nhưng khi tôi phải biết tôi nên tận dụng lợi thế gì từ nó và làm cách nào để làm cho nó cùng tồn tại với các khung công tác khác như Mootools.

Ngoài ra, tôi sẽ sớm phiêu lưu vào gamedev với UDK, và tôi chắc chắn rằng tôi càng hiểu về nó, tôi sẽ càng có thể uốn cong nó theo ý muốn xấu xa của mình, nhưng tôi cũng có thể làm theo những hướng dẫn không có trí tuệ. Tôi chọn cách đầu tiên, chỉ cần thêm một chút thời gian và chu kỳ não và tôi sẽ nhận được kết quả tốt hơn và dễ dàng hơn .

Điều quan trọng là phải biết vương quốc của bạn và một phần của quá trình.

Ví dụ: giả sử bạn đang sử dụng thư viện xử lý ảnh. Bạn có thực sự cần biết tất cả về làm mờ gaussian, biến đổi và không gian màu không? Số Nhưng bạn cần phải biết lý do tại sao bạn sử dụng thư viện ở nơi đầu tiên. Hoặc một chức năng sắp xếp của khung. Bạn có cần biết thuật toán sắp xếp thực tế được sử dụng? Trong hầu hết các trường hợp, không. Nhưng bạn cần phải biết tại sao bạn cần sắp xếp dữ liệu.

Mặt khác, nếu bạn đang viết một trình biên dịch, bạn sẽ hiểu rõ hơn về cách trình biên dịch hoạt động, vì đó là phần của bạn trong quy trình.

Một số khung công tác như jQuery trừu tượng đi rất nhiều. Bạn có cần biết chính xác họ đang làm việc như thế nào không? Không. Nhưng có một sự hiểu biết cơ bản, mạnh mẽ về những gì thư viện đang làm sẽ rất có lợi cho bạn khi bạn viết mã bởi vì bạn sẽ hiểu rõ hơn lý do tại sao khung được thực hiện theo cách đó và có thể sử dụng nó hết tiềm năng .

Theo kinh nghiệm của tôi: vì bạn không thể loại bỏ sự phụ thuộc vào thư viện, bạn và nhóm của bạn nên biết đủ để giải quyết vấn đề.

Là lập trình viên, chúng tôi có ít thời gian, vì vậy chúng tôi phải chọn người có mức độ ưu tiên cao nhất. Vấn đề phải được giải quyết, nhanh và nhẹ nhàng nhất có thể. Chỉ có lý do này làm cho "học tất cả về mọi thứ hoạt động" hơi dư thừa.

Điều tôi muốn thêm vào đây là "sự phụ thuộc". Là một cộng đồng, tất cả chúng ta đều phụ thuộc vào người khác. Chúng tôi đứng trên Người khổng lồ để xây dựng ứng dụng của mình: Java, .NET, API ... Và chúng tôi tin tưởng Người khổng lồ về công việc của họ; bởi vì nó làm việc cho rất nhiều người Nếu bạn gặp vấn đề về khung hoặc API, rất có thể những người khác đã phải đối mặt với nó ở đâu đó và có một giải pháp / giải quyết.

Vấn đề duy nhất ở đây: có thể, ở đâu đó, trong một tiêu chí hạn chế, Người khổng lồ sụp đổ.Ví dụ: flash không được hỗ trợ trong một số HĐH và có nhiều thứ chúng ta không thể làm nếu không có nó. Khả năng này là nhiều hơn không, nhưng trong trường hợp này chúng ta có những điều nhỏ mà chúng ta có thể làm. Chỉ trong những trường hợp này, kiến ​​thức về "những gì đằng sau mũ trùm" mới chứng minh được sự hữu ích, vì nó chỉ ra vấn đề thực sự ở đâu và có thể tạo ra một vấn đề lớn; nhưng tôi không chắc thời gian chúng ta đầu tư thực sự xứng đáng.

Để đối phó với khả năng đó, tôi nghĩ có một giải pháp: bởi vì hầu hết các lập trình viên có thể dễ dàng nắm bắt được "hoạt động bề mặt" của thư viện, và chỉ đôi khi chúng ta thực sự cần một người rất hiểu biết: hãy chia nhóm để làm điều đó. Cố gắng bao gồm một nhóm mà mỗi người đã trải nghiệm khoảng 1,2 thư viện / công cụ / "bộ kỹ năng" hữu ích có liên quan : một người có kinh nghiệm tốt về jQuery, một người có chuyên môn về cơ sở dữ liệu, ... Điều này sẽ giúp giảm thiểu rủi ro.

Một quan điểm khác là bảo mật. Khi bạn sử dụng một thư viện mà bạn không biết chính xác hoạt động bên trong, thì bạn sẽ đưa ra các giả định về những gì chính xác đang xảy ra. Mỗi giả định thất bại có thể mở ra một vectơ tấn công cho kẻ tấn công độc hại.

Khi gọi Quicksort, sau đó bạn nên biết về hành vi xấu nhất. Khác kẻ tấn công có thể tiêm dữ liệu trường hợp xấu nhất và thực hiện DoS.

Khi gọi một thư viện nén, thì bạn nên lưu ý rằng khi một số dữ liệu nén thành ít byte hơn, thì phải có dữ liệu "nén" thành nhiều byte hơn so với ban đầu. Vì vậy, khi giả định của bạn là bộ đệm đầu ra chỉ cần kích thước của dữ liệu đầu vào vì nó nén [đến ít byte hơn], thì có một lỗi tràn bộ đệm đang chờ xảy ra.

Bạn nên biết đủ các nguyên tắc cơ bản về những điều bạn sẽ làm, để có thể chứng minh những giả định của bạn là đúng. Khác thư viện nên rõ ràng quan tâm đến điều này, ví dụ như ném một ngoại lệ khi bộ đệm đầu ra được cung cấp không đủ lớn.

Không thể hiểu mọi thứ bạn sử dụng miễn là bạn chắc chắn nó hoạt động. Một khi bạn bị cắn bởi một lỗi trong lib thì sẽ có thời gian để xem nó hoạt động như thế nào, tại sao nó hoạt động và tại sao nó không hoạt động. Tất nhiên, bạn luôn được hoan nghênh và khuyến khích nhìn dưới mui xe ngay cả khi bạn không phải làm thế.

Một trong những điều khó khăn trong lập trình là vượt qua cám dỗ để tự mình giải quyết tất cả các vấn đề.

Nó là ok nhưng nó nguy hiểm. Là thông lệ chung, người ta nên biết làm việc về những gì mình đã phát triển.

Loại ...

Sẽ tốt thôi miễn là bạn có được ý chính chung về những gì thư viện hoặc khung đang cố gắng thực hiện. Đối với các bộ phận nội bộ và những gì không sau đó, không. Hãy tiếp cận thực tế. Nó hoạt động, nó đã làm những gì tôi muốn nó làm, được thôi.

Vấn đề là không bị sa lầy với hàng loạt chi tiết nhỏ và chỉ cần thực hiện ý tưởng chết tiệt của bạn.

Tôi đoán, vấn đề là, bạn sẽ không biết tất cả mọi thứ. Nghiêm túc mà nói, bạn có quá ít thời gian để điều tra mọi thứ, bởi vì nó sẽ khiến bạn mất tập trung khỏi mục tiêu chính là tạo ra ý tưởng đó của bạn. Dần dần, có lẽ, bạn có thể dành một chút thời gian rảnh vào cuối tuần để đọc một chương hoặc chủ đề này.

Nhưng đừng cố gắng tìm ra mọi thứ, trừ khi bạn có nhiều thời gian rảnh ... Hãy nhìn nó theo cách này. Lý do cho các ngôn ngữ lập trình là để bảo vệ chúng tôi thực hiện mã lắp ráp, lý do cho mã lắp ráp là để bảo vệ chúng tôi thực hiện 1 và 0. Tôi không nghĩ bạn cần biết mọi chi tiết tốt đẹp của cơ chế đằng sau nó, nhưng chỉ cần biết ý chính chung của nó. Giống như một người thu gom rác, tôi biết nó sẽ xử lý các con trỏ / bộ nhớ của tôi, tôi không quan tâm nó sử dụng thuật toán gọn gàng kỳ diệu nào, tôi chỉ biết nó hoạt động (cho những gì tôi cần) và nó không làm gì khác. Có thể là con của nó nhưng meh. Tất nhiên trừ khi bạn ở trong lĩnh vực mà bạn phải đối phó với nó. Sau đó, bạn sẽ không hỏi câu hỏi này vì nó là một phần công việc của bạn haha.