Là liên tục tìm kiếm các ví dụ mã là một dấu hiệu của một nhà phát triển xấu? [đóng cửa]

Tôi là một sinh viên CS có nhiều năm kinh nghiệm về C và C ++ và trong vài năm qua tôi đã liên tục làm việc với Java / Objective C để phát triển ứng dụng và bây giờ tôi đã chuyển sang phát triển web và chủ yếu tập trung vào ruby rails và tôi đã nhận ra rằng (như với sự phát triển ứng dụng, thực sự) tôi tham chiếu cách mã khác quá nhiều. Tôi liên tục thực hiện chức năng của Google cho rất nhiều thứ mà tôi tưởng tượng mình có thể làm được từ đầu và nó thực sự đã phá vỡ sự tự tin của tôi một chút.

Các nguyên tắc cơ bản không phải là một vấn đề, tôi ghét sử dụng nó làm ví dụ nhưng tôi có thể chạy qua javabat trong cả java / python ở giai đoạn nước rút - rõ ràng không phải là một thành tựu và nhưng ý tôi muốn nói là tôi có cơ sở vững chắc cho các nguyên tắc cơ bản Tôi nghĩ?

Tôi biết những gì tôi cần sử dụng điển hình nhưng cú pháp tham chiếu liên tục. Tôi sẽ thích một số lời khuyên và đầu vào về điều này, vì nó đã giữ tôi lại khá vững chắc về mặt tìm kiếm công việc trong lĩnh vực này mặc dù tôi đang hoàn thành bằng cấp của mình. Lý do chính của tôi để hỏi không thực sự là về việc làm, nhưng hơn nữa tôi không muốn trở thành người duy nhất tại một cuộc thi hackathon không gõ mã không ngừng và ngồi đó với 20 tab Google / github mở và tôi đã không tham dự bất kỳ do thiếu tự tin một chút ...

Là một người là một nhà phát triển tồi bằng cách liên tục tìm kiếm các ví dụ mã cho các nhiệm vụ từ trung bình đến phức tạp?

Sao chép-dán một cách mù quáng: xấu.

Tra cứu tài liệu, đọc các ví dụ mã để hiểu rõ hơn: tốt.

Tôi thà làm việc với một người luôn tìm kiếm mọi thứ và đảm bảo mọi thứ hoạt động như dự định hơn là một người quá tự tin nghĩ rằng anh ta biết tất cả nhưng không. Nhưng điều tồi tệ nhất là một người không bận tâm đến việc mọi thứ hoạt động như thế nào và chỉ sao chép mã từ trang web một cách không chính thức (và sau đó khi các báo cáo lỗi bắt đầu mưa thì không thể sửa chữa bất cứ điều gì chính xác).

Nếu bạn mã hóa các giải pháp của mình một cách có thể duy trì và thực sự HIỂU những gì bạn sao chép / dán / sửa đổi thì không có vấn đề gì.

Tôi chết bên trong mỗi khi tôi hỏi một nhà phát triển cấp cao về câu hỏi tại sao anh ta làm gì và câu trả lời là "Tôi không biết, tôi đã sao chép mã và nó hoạt động vào thời điểm đó".

Giống như với kỹ năng lập trình với / ra tài liệu API , tìm kiếm các ví dụ mã là một dấu hiệu không phải của một lập trình viên tồi, mà là của một người thiếu thông thạo ...

... Ở đây, tôi đang nói về sự trôi chảy. Về việc không chỉ có khả năng một cái gì đó mà còn thông thạo.

Bạn có biết nó là gì để thông thạo? Đó là khi ai đó nhìn vào bạn, dường như bạn viết mã khi bạn nhập ...

• ... Như thể mã đúng chỉ đơn giản chảy từ ngón tay của bạn đến màn hình. Như thể bạn không kiểm tra tài liệu, hướng dẫn và hướng dẫn sử dụng API. Trên thực tế, bạn làm kiểm tra tất cả, nhưng đó là vô hình vì đó là tất cả trong đầu của bạn. Bạn đã có tất cả kiến ​​thức bạn cần ngay trong não của mình - được sạc, tải và sẵn sàng sử dụng.

... Đó là kiến ​​thức lưu loát. Đó là khi bạn mất một phút để làm những gì người mới mất một giờ. Thật đáng để nỗ lực, thực sự. Nó có mùi như chiến thắng.

... Và thực tế đối với tôi là cách đáng tin cậy duy nhất để có được sự lưu loát.

Có một lý thuyết về học tập được gọi là chu trình Kolb (sau người mô tả nó). Các mục trong chu trình này là:

Concrete experience -> Reflective observation
    ^                        |
    |                        v
Active experimentation <- Abstract conceptualisation

Những người khác nhau thích bắt đầu ở những nơi khác nhau trong chu kỳ. Vì vậy, hoàn toàn có thể học bằng cách tìm kiếm các mẫu (giai đoạn quan sát phản xạ), sau đó làm việc từ các mẫu đó đến bức tranh lớn thông qua sự trừu tượng.

Những người khác sẽ học theo những cách khác nhau: một số người thích bắt đầu bằng cách thử (nghĩa là bằng thử nghiệm) sau đó phản ánh về những gì đã đi đúng hay sai. Vấn đề là đây chỉ là những cách khác nhau để tấn công vấn đề học tập: không có cách nào là không chính xác.

Tiết lộ đầy đủ - Tôi là một người già được đào tạo về một loại tiền Internet khác nhau có sẵn trong thời đại làm việc. Tôi đã xem các kỹ năng của các nhà phát triển trẻ ngày càng xuống cấp chủ yếu là do họ không lưu giữ thông tin hoặc hiểu giải pháp mà họ đã nắm bắt được từ Internet. Tôi đã quan sát thấy mức độ năng lực mà một người có được sau 1-2 năm kinh nghiệm, 20 năm trước, bây giờ là mức độ năng lực mà một người có được sau 5 - 7 năm kinh nghiệm. (Vâng, đó là một quan sát cá nhân nhưng tôi đã tuyển dụng rất nhiều, tôi không có dữ liệu thống kê về vấn đề này và vâng, đôi khi tôi già và cáu kỉnh, lấy câu nói này với một hạt muối. Và rời khỏi sân của tôi. )

Nhìn lên mọi thứ là không hiệu quả về thời gian. Nó cũng là một triệu chứng của một người không có nhiều kiến ​​thức chuyên sâu. Những người có kiến ​​thức chuyên sâu có thể viết mã nhanh hơn những người không biết cách giải quyết vấn đề mà không cần tìm kiếm mọi thứ. Vì vậy, nó là giá trị nó để học cách xử lý nhiều thứ hơn mà không cần phải tìm kiếm liên tục.

Bây giờ tôi không nói bạn không bao giờ nên tìm kiếm mọi thứ, tôi đang nói bạn nên học cách giữ lại kiến ​​thức và chỉ cần tìm kiếm những thứ bạn sử dụng hiếm khi hoặc khi bạn gặp phải một vấn đề hoặc ngôn ngữ hoặc mô hình thực sự mới. Và tôi không nói rằng bạn không nên đọc để theo kịp các giải pháp và công cụ và ngôn ngữ mới.

Mối quan tâm thực sự của tôi với các nhà phát triển, những người thường xuyên tìm kiếm mọi thứ rằng quá nhiều trong số họ (không nhất thiết là bạn) không bao giờ phát triển các kỹ năng phân tích để hiểu các vấn đề họ gặp phải và các giải pháp cần thiết. Đọc có bao nhiêu câu hỏi, nơi người đó đặt thông báo lỗi mà người đó rõ ràng không hiểu, nhưng điều này khá rõ ràng với bất kỳ ai hoạt động ở cấp độ chuyên nghiệp. Hoặc những người mà người đó nói, "nó không hoạt động, tại sao?" không có tham chiếu đến thông báo lỗi hoặc cách nó không hoạt động và mã đúng về mặt cú pháp. Hoặc những người được cung cấp một đoạn mã sẽ hoạt động,

Vì vậy, nếu những gì bạn đang tìm kiếm là một phần của chức năng cốt lõi của ngôn ngữ (BTW thì điều này sẽ bao gồm SQL nếu bạn đang truy cập cơ sở dữ liệu) bạn đã sử dụng hơn sáu tháng, tôi nghi ngờ bạn cũng đang tìm kiếm nhiều Nếu những gì bạn đang tìm kiếm là các tính năng nâng cao, đặc biệt là những tính năng bạn có thể sử dụng hiếm khi, thì bạn đang làm tốt.

Nhưng làm thế nào để bạn học cách giữ lại nhiều thông tin hơn? Trước tiên hãy hiểu tại sao mã bị hỏng. Ngay cả khi ai đó cung cấp cho bạn một giải pháp hiệu quả, nếu bạn không thấy lý do tại sao nó lại hiệu quả và bạn thì không. Nếu bạn không hiểu thông báo lỗi thì hãy hỏi ý nghĩa của nó và sau đó cố gắng tự giải quyết nó.

Và không bao giờ cắt và dán một giải pháp bạn không hiểu. Trong thực tế, không cắt và dán ở tất cả. Nếu bạn muốn giữ lại thông tin, bạn cần phải gõ nó. Thực tế việc tự viết mã giúp bạn học nó. Đó là một kỹ thuật học tập nổi tiếng.

Thực hành khái quát hóa sự hiểu biết của bạn về mã. Tôi đã thấy mọi người hỏi những câu hỏi tương tự hết lần này đến lần khác bởi vì họ không hiểu rằng giải pháp họ nhận được một tháng trước cho vấn đề ABC là giải pháp tương tự cho vấn đề mới DEF.

Vì vậy, khi bạn đã nghiên cứu một cái gì đó, hãy dành chút thời gian để suy nghĩ về loại vấn đề nào sẽ tốt cho việc giải quyết và viết cho bạn những ghi chú về điều đó. Sau đó, khi bạn có một vấn đề cần giải quyết, trước tiên hãy kiểm tra ghi chú của chính bạn để xem bạn đã lưu ý một kỹ thuật có thể. Nếu bạn đánh giá nhiều cách để giải quyết vấn đề, hãy ghi chú về loại vấn đề, các giải pháp có thể bạn đã xem xét và ưu và nhược điểm của từng vấn đề. Một lần nữa, việc ghi chú là giúp củng cố kiến ​​thức trong não của bạn, bạn đã có quá trình suy nghĩ của riêng mình về các ưu và nhược điểm và không phải làm lại điều đó (hoặc ít nhất là không sâu lắm, bạn có thể vẫn tìm kiếm các kỹ thuật có thể hơn) cho vấn đề tương tự tiếp theo.

Và khi quyết định học gì tiếp theo, hãy tìm hiểu sâu về một trong những công nghệ chính của bạn trước khi bắt đầu học 30 ngày đầu tiên với công nghệ khác (điều này giả định rằng bạn có đủ kiến ​​thức để thực hiện công việc của mình, nếu bạn cần sử dụng 6 công nghệ - có được những điều cơ bản trong tất cả sáu công nghệ trước khi đi sâu). Sau đó quay trở lại, học những thứ mới, ở cấp độ cơ bản, học một cái gì đó chuyên sâu hơn, sau đó học thêm nhiều công nghệ mới ở cấp độ cơ bản. Nếu bạn làm điều này theo thời gian, bạn sẽ thấy rằng mức độ cơ bản của bạn về những gì bạn muốn từ một công nghệ mới sâu sắc hơn nhiều vì bạn hiểu những câu hỏi nâng cao hơn để hỏi về nó.

Một cách khác để học cách giữ lại kiến ​​thức là dạy nó cho người khác. Trả lời các câu hỏi tại những nơi như thế này, trình bày các chủ đề đào tạo cho nhóm của bạn, thuyết trình tại các nhóm người dùng địa phương của bạn, viết các mục blog và giúp duy trì wiki thông tin tại công ty của bạn để giúp các nhà phát triển khác.

Tìm kiếm các ví dụ mã không phải là một dấu hiệu của nhà phát triển xấu. Một người hiếm khi cần rất ít thứ để nhớ chính xác tất cả các giao diện họ cần, do đó, việc tìm kiếm mọi thứ và các ví dụ mã thường là tài liệu tham khảo dễ sử dụng nhất.

Những gì bạn không nên làm là sao chép và dán các ví dụ vì chúng hoạt động ở đó, vì vậy chúng cũng phải hoạt động ở đây mà không hiểu cách chúng hoạt động. Điều đó thường dẫn đến rất nhiều bit vô dụng bị sao chép cùng với kết quả là khó duy trì vì nếu bạn không biết nó hoạt động như thế nào khi bạn viết nó, bạn sẽ không biết sáu tháng sau và sẽ không thể sửa nó.

Nhưng miễn là bạn hiểu mã bạn đang sao chép từ một ví dụ, đó là cách hợp lệ để hoàn thành công việc nhanh hơn và đó thường là điều tốt.

Những câu trả lời là khá tốt. Nhưng bạn bị một vấn đề sâu sắc hơn nhiều so với sao chép / dán hoặc thiếu "kỹ năng".

So sánh là gây chết người. Bạn càng so sánh bản thân với người khác và để tài năng của họ ảnh hưởng đến cách bạn nhìn nhận bản thân, bạn sẽ càng co mình lại và chết bên trong. Bạn không đến hackathons vì sợ rằng mọi người sẽ thấy bạn không được đánh giá cao như thế nào. Và lý do duy nhất bạn nghĩ rằng bạn không được đánh giá cao là vì bạn so sánh bản thân với các tin tặc có thể tạo ra nhiều mã hơn từ đầu, nhanh hơn.

Ngay cả khi "Dòng mã mỗi phút" là một thước đo tốt cho kỹ năng đo lường, bạn cần chấp nhận thực tế rằng sẽ luôn có những nhà phát triển tốt hơn ngoài đó . Và nó ổn khi cho người khác thấy rằng bạn thiếu kỹ năng.

Bạn không cần phải giỏi như, hoặc tốt hơn bất kỳ ai khác. Bạn cần phải hài lòng với thực tế là bạn sẽ luôn thiếu theo một cách nào đó, và rằng bạn đang học hỏi không ngừng. Nếu bạn không thể hạnh phúc với việc trở thành một nhà phát triển kém hơn, bạn sẽ KHÔNG BAO GIỜ hạnh phúc.

Một điều nữa: nỗi sợ bị từ chối của những người mà bạn cho là "vượt trội" chính xác là điều ngăn cản bạn cọ xát vai với những nhà phát triển tốt hơn và học hỏi từ họ. Vì vậy, nỗi sợ hãi của bạn ngăn cản bạn phát triển, điều này duy trì nỗi sợ hãi của bạn. Điều này ngăn cản bạn phát triển. Xem chu kỳ? Bạn phải phá vỡ chu kỳ ở đâu đó.

Tôi nghĩ rằng rất nhiều trong số đó phụ thuộc vào cách làm việc của bạn. Bộ nhớ của tôi bốc mùi, vì vậy tôi muốn lấy mã gần với những gì tôi muốn nhất có thể và làm lại nó để nó thực hiện công việc mới. Nó là một ví dụ và một lời nhắc nhở về tất cả những điều tôi phải làm. Chẳng hạn, tôi đã sử dụng SQL đơn giản trong 20 năm, nhưng tôi không bao giờ có thể nhớ bố cục của câu lệnh CHỌN hoặc CẬP NHẬT. (Tôi nghĩ rằng người ta cần dấu ngoặc đơn, nhưng tôi không thể nhớ cái nào.) Mặt khác, một số điều tôi có thể nhớ; Tôi có thể kết hợp triển khai Java Iterator với đôi mắt nhắm nghiền.

Hầu hết các mã tôi sao chép là của riêng tôi, nhưng tôi chắc chắn sao chép mã khác khi tôi đang học một cái gì đó mới.

Tôi không biết về hackathons. Họ có thể vẽ lên một tập hợp các lập trình viên với những ký ức nhiếp ảnh. Tôi sẽ thử và xem. Nếu trông như một thằng ngốc làm phiền bạn, bạn không nên lập trình.

Tôi mong bạn hiểu, triệt để, tất cả các mã bạn sao chép và sửa đổi, nhưng, cho đến khi tôi đọc một số câu trả lời khác, nó không bao giờ xảy ra với tôi ai đó có thể sao chép mà không hiểu. (Tôi dường như đang học những tật xấu mới mọi lúc trên trang này ...)

... Tôi đã nhận ra rằng ... Tôi tham khảo mã khác quá nhiều. Tôi liên tục google chức năng cho rất nhiều thứ tôi tưởng tượng tôi có thể làm được từ đầu và nó thực sự đã phá vỡ sự tự tin của tôi một chút.

Sau đó dừng lại. Đi về hướng khác một lúc. Tự mình thực hiện mọi thứ, ngay cả khi bạn biết bạn có thể tìm thấy chính xác thứ bạn cần trong thời gian ngắn hơn nhiều.

Điều đã xảy ra là cơ bắp giải quyết vấn đề của bạn (tên Latin là gluteus mojo ) đã bị suy yếu do không sử dụng, và bây giờ bạn tránh sử dụng nó vì bạn biết nó yếu như thế nào. Bạn cần bắt đầu xây dựng và làm săn chắc cơ bắp giống như khi bạn tập trên bắp tay tại phòng tập thể dục. Bắt đầu với sự lặp lại cao và sức đề kháng thấp - rất nhiều vấn đề dễ dàng. Khi bạn xây dựng một số sự tự tin, chuyển sang các vấn đề dài hơn, khó khăn hơn.

Bạn sẽ dần dần cảm thấy mojo của bạn trở lại và nhu cầu dựa vào Google của bạn sẽ giảm đi. Mặc dù vậy, hãy tiếp tục tập luyện cơ bắp đó và đảm bảo rằng bạn không rơi vào lối cũ. Thử thách bản thân để giải quyết vấn đề trước và chỉ sau đó tìm kiếm các giải pháp khác. Đôi khi bạn sẽ thấy rằng những người khác đã tìm thấy một cách tốt hơn để làm điều tương tự, những lần khác bạn sẽ quyết định rằng giải pháp của riêng bạn là tốt hơn.

Là một người là một nhà phát triển tồi bằng cách liên tục tìm kiếm các ví dụ mã cho các nhiệm vụ từ trung bình đến phức tạp?

Một người không thể hoàn thành mọi việc mà không tìm thấy ví dụ là một nhà phát triển tồi. Vấn đề là: bạn sẽ không biết liệu bạn có thể hay không cho đến khi bạn thử.

Bạn còn trẻ và bạn đã làm việc với rất nhiều ngôn ngữ lập trình. Tôi sẽ đoán rằng bạn có thể tiếp thu ngôn ngữ mới nhanh hơn ngôn ngữ cũ. Bạn vẫn chưa dành đủ thời gian cho một ngôn ngữ trên một ứng dụng đủ lớn để phát triển lưu loát.

Bạn có đang tìm kiếm các giải pháp rộng rãi mọi lúc như: toàn bộ quá trình kết nối lưới web với bảng cơ sở dữ liệu hoặc một phần nhỏ hơn như định dạng chuỗi kết nối (tôi phải tìm kiếm điều đó mỗi lần kể từ khi tôi viết khoảng bốn năm một lần. )?

Bạn sẽ luôn tìm kiếm các tham chiếu đến cú pháp của các dòng mã hoặc hàm khác nhau. Bạn càng lập trình, càng có nhiều thách thức và các môi trường và ngôn ngữ khác nhau mà bạn gặp phải. Nếu bạn cần một hướng dẫn toàn bộ mỗi khi bạn làm một cái gì đó, thì bạn có một vấn đề.

Tôi đã có một giáo sư thường nói rằng anh ta ghét đưa ra các bài kiểm tra dựa trên việc cố gắng giữ lại một loạt thông tin mà bạn đã nhồi nhét vào đêm hôm trước vì dù sao bạn cũng quên rất nhiều thông tin. Tốt hơn là nên biết tài nguyên của bạn và bạn có thể sử dụng chúng đúng cách để tìm thông tin mà bạn không biết. Tôi thích áp dụng một nguyên tắc tương tự cho mọi thứ tôi làm, kể cả công việc.

Tôi nghĩ rằng các công cụ quan trọng nhất bạn có là tài nguyên của bạn, miễn là bạn sử dụng chúng đúng cách. Vì vậy, khi tôi viết mã, tôi có thể hiểu được những kiến ​​thức hiện có của mình và sau đó nghiên cứu bằng cách hỏi các lập trình viên khác hoặc tìm kiếm trên Internet, để hiểu rõ hơn về giải pháp thích hợp. Kiến thức sẽ được xây dựng theo thời gian và sau một thời gian, bạn sẽ tự nhiên biết và hiểu các kỹ năng tốt hơn. Tôi liên tục tìm kiếm mọi thứ cho dù tôi có thực sự cần thông tin hay không, và tôi có thể thành thật nói rằng tôi học được điều gì đó mới mỗi ngày.

Nếu bạn hiểu vấn đề bạn đang cố gắng giải quyết và hiểu cách bạn muốn giải quyết nó, việc tìm kiếm cú pháp chính xác không phải là vấn đề lớn theo quan điểm của tôi.

Tôi tốt nghiệp khoảng hai năm trước và bị ném vào bầy sói khi tôi nhận được công việc của mình. Tôi đã phải học, duy trì và nâng cấp một ứng dụng lớn được viết bằng ngôn ngữ mà tôi chưa từng chạm tới trước đây. Tôi sẽ nhận được một báo cáo lỗi, xem qua mã và tìm hiểu cách tôi muốn sửa nó, và sau đó phải google các ví dụ về cách làm những thứ tôi muốn bằng ngôn ngữ đó.

Nếu bạn đang hoàn thành công việc, và hiểu nó đủ để không tạo ra tiếng vang không cần thiết, thì có lẽ bạn vẫn ổn.

Sao chép thuần túy và dán như đã nêu nhiều lần trong các câu trả lời này là xấu. Nhưng như vậy là viết mọi thứ từ đầu. Nếu nó không phải là một thành phần quan trọng là cốt lõi đối với doanh nghiệp của bạn, hãy tìm một thư viện hoặc đoạn mã để thực hiện trước. Ngoại lệ khi tìm đoạn trích là vấn đề rất đơn giản, bạn có một bức tranh rất rõ ràng về cách thực hiện và nếu bạn không sử dụng thư viện: bạn sẽ không cần phải làm gì thêm.

Cá nhân tôi biết nếu tôi viết một cái gì đó phổ biến, tôi có thể có một số lỗi tinh vi và có lẽ một hoặc hai lỗi không tinh tế mà không có nhiều thử nghiệm. Vì vậy, tôi tìm kiếm một giải pháp tương tự, sửa đổi và kiểm tra để tiết kiệm thời gian kiểm tra và phát triển hơn tất cả. Bởi vì cuối cùng, tôi chịu trách nhiệm cung cấp một sản phẩm hoạt động, có thể mở rộng, nằm trong hoặc dưới ngân sách và đáp ứng thời hạn. Sử dụng lại mã và thư viện là một bước tốt hướng tới mục tiêu đó.

Tôi nghĩ rằng đọc các ví dụ mã, và chỉ đọc mã nguồn của những gì người khác đã phát triển nói chung, là cách tốt nhất để cải thiện kỹ năng của bạn. Tôi thực sự nghĩ rằng nó sẽ mở ra những cánh cửa trong não bạn nếu không được mở ra.

Nếu bạn nghĩ ra giải pháp A và người khác nghĩ ra giải pháp B, khi mỗi bạn chia sẻ giải pháp của mình, bạn có thể nhận ra giải pháp C có thể còn tốt hơn A hoặc B.

Tôi nghĩ rằng có nhiều cấp độ thành thạo phát triển phần mềm. Chỉ như vậy, bởi vì cũng có nhiều cấp độ thành thạo tài liệu phát triển phần mềm . Thành thật mà nói, những ngày này, các hệ thống là những đơn đặt hàng có cường độ phức tạp hơn so với khi tôi bắt đầu lập trình máy tính vào giữa những năm 1980.

Sau đó, bạn phải biết bạn muốn máy tính làm gì và bạn đã viết tài liệu dày 6 inch cho bạn biết máy tính đã làm những việc cơ bản nhất định như thế nào. Đặt những gì bạn muốn vào một hình thức mà máy tính có thể thực hiện là vấn đề biết nội dung của các chỉ số của những cuốn sách đó và ngôn ngữ lập trình (hoặc hai. Thực sự, sau khi học bốn hoặc năm ngôn ngữ, những ngôn ngữ khác chỉ là phương ngữ.)

Ngày nay, nhiệm vụ đó đòi hỏi phải biết một ngôn ngữ, biết một hệ thống, biết một mô hình, một mô hình lập trình và ít nhất một bộ API, tất cả đều là các mục tiêu di chuyển.

Vì vậy, một người có trình độ kiến ​​thức cơ bản nhất định hỏi xung quanh không phải là một lập trình viên giỏi. Ông là loại lập trình viên giỏi nhất , được cung cấp các môi trường ngày nay và các công ty không quan tâm như Microsoft thực sự áp dụng bất kỳ loại nghiêm ngặt nào vào tài liệu cơ bản của riêng họ. Hầu hết các công cụ của họ là tài liệu tham khảo tự tham khảo và một số mã mẫu rất xấu . (Hai trường hợp mà tôi gặp phải là "Trình cài đặt Windows" và API để tạo tệp phim WMV.)

Bởi vì Microsoft, Google và, ở một mức độ thấp hơn, Apple, tất cả đều dựa vào "cộng đồng" để bù đắp cho sự thiếu hụt rất thực tế đó, hỏi xung quanh không chỉ quan trọng, nó còn quan trọng. Và việc trở thành một người có thể được hỏi và là người có thể đưa ra những câu trả lời và phản hồi chắc chắn trong môi trường ngày nay cũng quan trọng không kém. Đó là lý do tại sao các trang web như trang web stackexchange.com cũng hữu ích như chúng.

Vì vậy, hãy đặt câu hỏi, (hỏi một cách thông minh!) Cho các mẫu và tôn trọng những người cung cấp câu trả lời, và làm như vậy sẽ không được coi là dấu hiệu của một "nhà phát triển tồi".

Và một điều nữa: Cung cấp các mẫu xấu thực sự là dấu hiệu của một nhà phát triển tồi. Nó làm cho các nhà phát triển xấu dễ dàng phát hiện hơn, nhưng cũng tổng hợp các tìm kiếm google. Nếu bạn thiếu tự tin về các mẫu mã đơn giản, đơn giản, đơn giản, đừng đưa ra.

Và, xin vui lòng, đừng chế giễu những người hỏi.

Đối với tôi có vẻ như vấn đề đối với bạn là ít hiểu những gì bạn đang tham khảo, và nhiều hơn với các vấn đề về cơ sở và bộ nhớ. Nếu điều đó làm giảm sự tự tin của bạn, thì đúng vậy, đó là một vấn đề - nhưng chắc chắn nó có thể được giải quyết!

Đối với tôi, những thử thách kiểu này xuất hiện ở nhiều khía cạnh khác nhau trong cuộc sống của tôi. Ví dụ, để có thể thể hiện tốt một bản nhạc, tôi cần phát triển sự độc lập của mình với bản nhạc tôi đã đưa ra - làm thế nào bạn thực sự cảm nhận được âm nhạc nếu mũi của bạn vẫn bị chôn vùi trong tập sách của bạn? Đôi khi, nếu tôi có thời gian, tôi sẽ ghi nhớ toàn bộ bản nhạc - ngay cả khi nó không bắt buộc cho buổi biểu diễn của tôi. Tại sao? Khi bản nhạc đã biến mất, tôi dễ dàng tập trung vào các khía cạnh thách thức và bao quát hơn của âm nhạc mà tôi cần để có được, và tôi dễ dàng hơn trong việc tạo ra âm nhạc thuần túy đáng kinh ngạc đó. Vì vậy, tôi thấy nó thường có giá trị thêm rắc rối.

Kinh nghiệm của tôi với lập trình đã tương tự. Tôi nghĩ rằng các phím là:

1. thực hành ngôn ngữ - gõ nó, chạy nó, nói nó nếu nó giúp; làm như vậy nhiều lần
2. xây dựng cơ sở của bạn - sử dụng cùng tính năng hoặc mẫu trong các tình huống khác nhau; đặt các tính năng với nhau; làm chương trình.
3. cung cấp đủ thời gian giữa các lần lặp lại để đảm bảo rằng mọi thứ đang thực sự đi vào bộ nhớ dài hạn của bạn.

Những nguyên tắc này dường như được áp dụng khi học bất kỳ ngôn ngữ, thực sự! Xem cách nhớ từ mới chẳng hạn. Các phương pháp Pimsleur cũng làm việc như thế này.

Tôi đã thấy rằng hầu hết tất cả các nguyên tắc, cú pháp và thư viện chung của ngôn ngữ và công nghệ tôi sử dụng thường xuyên có thể được ghi nhớ hoàn toàn, bằng cách sử dụng các khóa này. Mặc dù vậy, tôi vẫn không ngừng lùng sục trên Internet những ví dụ và sự khôn ngoan! Nhưng thời điểm đó, tôi đang tìm kiếm xác nhận về vấn đề tôi đang cố gắng giải quyết, nhiều cách tiếp cận khác nhau đã được thực hiện, các công cụ có thể giúp đỡ và tư vấn cho các thư viện ít được sử dụng. Đó là một loại tìm kiếm rất khác so với tôi sử dụng khi lần đầu tiên tôi học một ngôn ngữ và chuyên sâu về hướng dẫn và hướng dẫn sử dụng.

Từ câu chuyện của bạn, đây là một số vấp ngã cụ thể tôi nghĩ bạn có thể gặp phải.

1. Nếu bạn đang vật lộn với cú pháp, bạn có thể không được thực hành đủ. Điều này đặc biệt đúng nếu bạn đang sao chép và dán thẳng vào mã của mình, thay vì phát triển sự lặp lại và - tôi có thể nói không? - bộ nhớ cơ sẽ giúp bạn có được thực sự tốt. Để chống lại điều này, chỉ cần phát triển các bài tập và kỷ luật, tập trung vào sự lặp lại và thời gian, điều đó sẽ cải thiện cơ sở của bạn trong các lĩnh vực bạn muốn. Gợi ý:
   • Viết một chương trình đơn giản trong cùng một ngôn ngữ mỗi ngày một lần, mỗi ngày.
   • Nhập ví dụ thay vì sao chép và dán chúng.
2. Nếu bạn đang vật lộn với việc xây dựng các giải pháp cho các vấn đề có kích thước vừa phải, bạn có thể không có đủ kinh nghiệm với việc xây dựng. Thử những thứ này xem:
   • Bắt đầu một dự án cỡ trung bình trong một số công nghệ hoặc ngôn ngữ mà bạn muốn giỏi. Hoặc dùng thử tính năng mạnh mẽ hơn trong một dự án nguồn mở mà bạn quan tâm. Hãy bỏ qua nó một chút mỗi ngày. (Hãy nhớ rằng, khi bạn đang theo đuổi các dự án lớn hơn này: hãy thử từng viên gạch. Đừng thử và xây dựng toàn bộ mọi thứ cùng một lúc!)
   • Sử dụng cùng một tính năng mới trong bốn ngày liên tiếp, trong bốn bối cảnh khác nhau.
   • Thử thách bản thân để mã hóa một cái gì đó với trình duyệt web đã tắt!
   • Thực tế ghi chép về những thứ bạn đang học. Tổng hợp những gì bạn đang học và viết ra những quan sát của bạn. (Trên thực tế, viết ra những điều đó, và buộc bản thân phải thể hiện điều gì đó bằng lời nói của mình, giúp tôi rất nhiều.)
   • Viết câu trả lời và xác minh chúng, cho các câu hỏi StackOverflow về công nghệ bạn đang tiếp thu. (Điều này thường có thêm lợi ích giúp bạn có được một chút tiếng tăm khi học. :-))
3. Bạn có thể lan truyền thực hành của bạn quá mỏng. Bạn dường như đang làm việc trong nhiều ngôn ngữ khác nhau. Điều này có rất nhiều lợi thế, nhưng nó có nhược điểm là làm loãng trải nghiệm của bạn. Nếu bạn dành thời gian làm việc bằng năm ngôn ngữ khác nhau, bạn sẽ ghi nhớ ít hơn nếu bạn dành cùng một thời gian cho một ngôn ngữ. Tồi tệ hơn, có rất nhiều nhận thức không hoàn toàn giống nhau giữa các ngôn ngữ khác nhau (đó có phải là nếu, elsif hoặc elif ??) khiến bạn gặp khó khăn. Để chống lại điều này, làm sắc nét sự tập trung của bạn. Chọn một thứ để học và học nó lạnh. Sau đó chuyển sang điều tiếp theo.

Tôi nghĩ rằng nếu bạn tập trung vào việc đưa ra mã vừa phải, hiệu quả và năng suất của bạn sẽ tăng lên. Có lẽ mất nhiều thời gian hơn để tìm kiếm mã, đọc / hiểu nó, sao chép nguồn của bạn, sửa đổi nó cho phù hợp, v.v.

Nếu bạn tự mình nghĩ ra, nó rất có thể thích nghi với tình huống cụ thể của bạn và sau một thời gian, những giải pháp này sẽ đến với bạn nhanh hơn là tìm kiếm chúng.

Cách tôi nhìn nhận, đó là giống như bạn muốn có ý kiến ​​thứ hai về một giải pháp nào đó, vì vậy bạn tìm kiếm cách người khác (trên Internet) làm điều đó. Nếu bạn thấy mình đang làm / muốn điều này quá nhiều, hãy nghĩ về nó như hỏi một đồng nghiệp về những gì anh ấy / cô ấy nghĩ về một giải pháp. Nếu bạn hỏi đồng nghiệp một câu hỏi cứ sau 15 phút, anh ấy / cô ấy có thể sẽ khó chịu. Do đó, bạn sẽ hỏi ít câu hỏi hơn và cố gắng tự mình đưa ra.

Hình dung điều này khi muốn tìm kiếm mọi thứ trên Internet.

Cách tốt nhất để tìm hiểu những gì bạn không biết: google nó! Tôi cảm thấy bạn đúng ngang với hầu hết các nhà phát triển. Đặt phức tạp tự ti trong ba lô của bạn và đi vào với một tâm trí cởi mở.

Đừng ngại đặt câu hỏi, nghiên cứu về Google, thử và thất bại. Tất cả là một phần của nó.

Phát triển phần mềm trong cài đặt công ty đòi hỏi một lượng sử dụng lại mã hợp lý. Tại sao phải viết lại hàm / phương thức nếu API đã tồn tại và được sử dụng rộng rãi? Nó rất có thể sẽ hiệu quả như bất cứ điều gì bạn viết và mất ít thời gian hơn.

Tất nhiên, thành công trong phát triển phần mềm cũng cần phải nghỉ ngơi từ bàn phím, để bạn có thể đọc và hiểu những gì đang thực sự diễn ra. Lấy bất kỳ khuôn khổ web. Bạn nên biết những gì đang diễn ra bên dưới để bạn hiểu mã bạn đang viết, nhưng bạn có thể sẽ không bao giờ phải tự viết một khung web từ đầu.

Bạn chỉ cần viết mã tận dụng loại khung (giả sử khung dựa trên thành phần yêu cầu một kiểu nhất định) và điều này xuất phát từ việc hiểu bức tranh lớn hơn. Tìm hiểu bức tranh lớn hơn và bạn sẽ ổn thôi.

Rõ ràng từ các câu trả lời đã được đưa ra rằng không có gì sai khi nghiên cứu vấn đề của bạn, thay vì mã hóa một cách mù quáng. Nhưng câu hỏi chưa được giải quyết, bởi vì bạn đã không hỏi nó trực tiếp, là tại sao bạn cảm thấy không an toàn - và bạn có thể làm gì về nó? Rốt cuộc, rất nhiều người google tìm cách khắc phục vấn đề và có rất nhiều sự tự tin (ngay cả những người không nên ...)

Vậy lam gi? Có lẽ bạn chỉ cần vài trăm cái vỗ vào lưng, cái mà bạn vừa có, và bây giờ có thể tự tin viết mã. Nhưng nếu điều đó không thực hiện được, tôi khuyên bạn nên xem xét thử nghiệm tự động và Phát triển dựa trên thử nghiệm. Không có gì nói "hoàn thành tốt" như "Tất cả các bài kiểm tra đã qua" từ bộ kiểm tra của bạn: Khi bạn đến đó, bạn biết bạn đã làm đúng.

Bạn cũng nên thử thách bản thân một chút: Bạn nói rằng bạn luôn tìm kiếm cú pháp mà bạn đã biết; vì vậy hãy ép bản thân viết một số mã mà không cần tra cứu cú pháp và bạn sẽ sớm nhận ra rằng bạn đang làm tốt mọi thứ.

Các nhà phát triển không sinh ra vĩ đại, vĩ đại nhưng vĩ đại không tự động đi kèm với kinh nghiệm. Ngược lại, thiếu kinh nghiệm không làm cho nhà phát triển trở nên tồi tệ. Sự khác biệt giữa nhà phát triển tuyệt vời và nhà phát triển tồi không nằm ở kiến ​​thức miền của họ, mà là phương pháp của họ. Dấu ấn riêng biệt của một nhà phát triển vĩ đại là anh ta có ý thức mã hóa. Nói cách khác, một nhà phát triển giỏi luôn biết tại sao anh ta lại làm việc gì đó. Từ quan điểm của đạo đức cá nhân, điều này đòi hỏi sự can đảm trí tuệ và tính toàn vẹn.

Điều này rất quan trọng để dành một chút thời gian và tìm hiểu những điều cơ bản, những điều phức tạp hơn được xây dựng trên đó. Nếu không có nền tảng để hiểu ngôn ngữ và những gì đang diễn ra đằng sau hậu trường, mã hóa sẽ chỉ đơn giản là hack hack

Vì vậy, đọc sách với các ví dụ và đề cập đến chúng là lập trình xấu là bối cảnh của câu hỏi của bạn. Nhìn thấy rất ít người ghi lại API của họ một cuốn sách là tất cả những gì chúng ta còn lại.

Tôi không biết lý do của bạn là gì khi đặt câu hỏi này, có lẽ bạn có thể tự trả lời câu hỏi này sau khi đọc tình huống của tôi khi tôi đề cập đến rất nhiều ví dụ về mã.

Tôi chưa bao giờ có cơ hội đến trường đại học khi tôi ở trên đường vào năm 16 tuổi. Tôi phải thừa nhận rằng nhiều lúc tôi phải vật lộn và phải lên mạng để lấy ví dụ. Vô tình mặc dù lúc này tôi có một khối u não đang phát triển trong đầu (đến năm 2010 nó có kích thước bằng một quả cam). Sau 5 lần phẫu thuật não, 6 tuần kết hợp hóa trị / xạ trị và 10 tháng hóa trị, tôi vẫn đang lập trình với các trang web được viết bằng tay có thể xem được từ hồ sơ của tôi.

Có, tôi cần rất nhiều ví dụ mã bây giờ với tổn thương não, vậy điều đó có khiến tôi trở thành một lập trình viên tồi không?

Vì vậy, tôi thấy bạn đã đề cập rằng bạn sẽ tham gia một cuộc thi hackathon. Tôi đã đến khá nhiều trong năm qua (hơn 15) và nhận thấy rằng chúng rất tốt cho việc học. Và tuyệt vời cho việc học tôi có nghĩa là học cách không bao giờ viết mã như vậy nữa. Tôi chủ yếu cố gắng làm một cái gì đó mới ở mỗi hackathon tôi đi chỉ để tôi có thể học những điều mới. Vì có một hạn chế lớn về thời gian, bạn chỉ dựa vào việc sao chép dán tất cả các mã bạn có thể tìm thấy và điều này sẽ cắn vào mông bạn khi bạn đang kiểm tra nó.

Tuy nhiên, những điều tốt đẹp đến từ nó, bạn: A) TÌM HIỂU rất nhiều trong quá trình kiểm tra lỗi (cũng khóc rất nhiều) B) Biết không bao giờ viết mã như vậy một lần nữa và học các cách thực hành mã hóa tốt hơn. Ngoài ra, tại hackathons bạn sẽ gặp những người có thể dạy cho bạn rất nhiều điều mới mà bạn chưa từng biết đến và bạn sẽ làm những việc bạn sẽ không bao giờ làm ở trường.

Vì vậy, những gì tôi nói là dán sao chép là xấu, và bạn sẽ không học được gì, và thời gian bạn lưu bằng cách dán sao chép sẽ cắn bạn sau này trong quá trình kiểm tra lỗi và bạn không biết mình đã viết gì, đó là 8 giờ sáng, và được cung cấp nhiên liệu với tất cả các caffeine. Nhưng, tôi nghĩ miễn là bạn kiểm tra lỗi mã của mình, bạn sẽ phải học mọi thứ bạn đã sao chép trước đó.

Chà, tôi không gọi mình là một lập trình viên giỏi. Nhưng những gì tôi làm rất đơn giản. Nếu tôi không biết cách làm một cái gì đó, tôi thực sự xem một số mã / ví dụ trên Internet. Sau đó, sau khi đọc nó, tôi cố gắng viết lại, tối ưu hóa nó và sử dụng những thứ phù hợp nhất với mã tôi muốn.

Lưu ý: Đọc mã từ Internet không khiến bạn trở thành một nhà phát triển tồi. Thật tốt khi nhìn cách người khác làm điều đó và bạn sẽ luôn học được điều gì đó. Nhưng sau đó, sao chép nó một cách mù quáng là không tốt.

Nếu một nhà phát triển / sinh viên muốn nói .. Wikipedia .. để sao chép / dán mã vào dự án của họ, thì bạn chỉ cần cố gắng để nó hoạt động "thì kỹ năng duy nhất mà người này đang phát triển là 'Cách google'. Có thể có một số quá trình thẩm thấu ở đó, nhưng không phải là một bó. (Bạn sẽ không tin có bao nhiêu người làm điều này trong các khóa học đại học)

TUY NHIÊN, Nếu bạn phân tích mã người khác và thực sự nghĩ về những gì đang diễn ra trong chính mã, thì điều đó không làm cho một người trở thành một nhà phát triển tồi. Nó làm cho họ trở thành một nhà phát triển quyết tâm và có thể chỉ ra một phong cách học tập mang tính xúc giác hoặc trực quan hơn. Tôi học bằng ví dụ rất tốt. Nếu ai đó nói với tôi điều gì đó hoặc cố gắng giải thích cho tôi, tôi thường yêu cầu họ chỉ cho tôi biết họ đang nói về điều gì.

Nhìn, phân tích và học từ mã thực sự khiến họ trở thành một nhà phát triển giỏi theo thời gian , bởi vì họ đang đọc và học bằng ngôn ngữ họ đang sử dụng.

Tôi thường nói đùa rằng tôi biết ngôn ngữ máy tính hơn ngôn ngữ tiếng Anh của mình. Điều này đặt ra câu hỏi; "Bạn sẽ giải thích điều đó cho tôi trong Java plz?"

Tôi nghĩ nó hơi giống như chơi Cờ vua. Chúng tôi kiểm tra từng mảnh riêng lẻ và theo dõi nơi chúng có thể di chuyển theo các quy tắc, và chúng tôi phải trải qua quá trình kiểm tra ý thức đó trong một khoảng thời gian cho đến khi tiềm thức tham gia, tiết lộ các mô hình và các chuỗi cảm hứng.

Với lập trình có thể có nhiều phần và quy tắc hơn, tôi thường vấp phải cú pháp và mắc kẹt với các lỗi cần tìm mãi bằng cách vượt qua 'quy tắc', nhưng cuối cùng tiềm thức sẽ khởi động. Khi nó đủ lâu, tôi có thể đọc đôi khi trở lại và ngạc nhiên trước những gì nó có thể làm.