* Những * khái niệm lập trình mà tôi nên nắm vững để có hiểu biết sâu sắc về nghề thủ công (lập trình) của tôi là gì? [đóng cửa]

Theo thứ tự quan trọng, nếu có thể làm như vậy và có thể không, thì nền tảng quan trọng nhất của việc biết cách lập trình là gì. Thuật toán, lặp, đệ quy, vv?

Lưu ý rằng nơi tôi đặt vv là nơi câu hỏi của tôi nằm. Gần đây tôi đã đọc một bài đăng trên Internet nói rằng 9 trên 10 lập trình viên không thể thở hổn hển !

http: //www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html

Tôi muốn có một kiến ​​thức sâu sắc về những gì tôi thực sự đang cố gắng thực hiện khi lập trình và hiểu toàn diện về các công cụ cơ bản theo ý của tôi. Về cơ bản tôi muốn có thể vẽ với tất cả các màu của gió.

Danh sách này là một sự khởi đầu ... bạn đang hỏi một câu hỏi lớn!

• Làm thế nào để làm rõ và viết ra những gì khách hàng muốn ("yêu cầu"). Đây là một nghệ thuật trong và của chính nó. Nếu bạn có thể làm điều này, công việc lập trình của bạn sẽ tốt hơn nhiều.
• Làm thế nào để ước tính và kế hoạch dự án. Mọi người sẽ yêu cầu bạn ước tính, hãy chuẩn bị.
• Làm thế nào để xem xét một cách xây dựng mã của người khác.
• Thiết kế mẫu. Đây là một vấn đề lớn. Nhưng đừng quá nhiệt tình sử dụng chúng vì lợi ích của nó.
• Tìm hiểu sự khác biệt giữa lỗi, sự cố và yêu cầu tính năng
• Luôn cập nhật với các khung / thư viện. Bạn không cần phải sử dụng chúng, nhưng bạn cần biết những gì họ làm và những người thân của họ. Nếu một cái gì đó dường như quá khó khăn thì có lẽ (hy vọng) một cách dễ dàng hơn để làm mọi thứ.
• Làm thế nào để ghi lại các thuật toán phức tạp trong một sơ đồ hoặc chỉ viết nó ra bằng tiếng Anh. Đừng hy vọng rằng ai đó sẽ dành 2 ngày để cố gắng thiết kế mã của bạn.
• Cách tổ chức cấu trúc mã của bạn để bất kỳ ai khác có thể hiểu nó
• Cách nhận xét mã của bạn
• Cách viết bài kiểm tra đơn vị
• Biết những gì đang xảy ra dưới mui xe. Ví dụ: gọi một dịch vụ web - nó thực sự đang làm gì?
• Làm thế nào để trừu tượng đi logic vào các lớp.
• Cách mã hóa lại
• Tìm hiểu ý chính của khá nhiều ngôn ngữ lập trình. Bạn sẽ ngạc nhiên về những gì bạn có thể học hỏi từ các lĩnh vực khác
• Làm thế nào để nói với các lập trình viên khác những gì để viết.
• Làm thế nào để giải thích cho quản lý những gì bạn đang làm và tại sao.
• Giống như Peter đã nói, làm thế nào để gỡ lỗi. Tôi đồng ý với tất cả những gì anh ấy nói, lập trình viên thực sự gỡ lỗi, không chỉ là đoán.
• Làm thế nào để làm việc với người điên. Có rất nhiều trong số họ ra khỏi đó.
• Làm thế nào để có được STUFF DONE. Tất cả các lý thuyết trên thế giới sẽ không giúp bạn nếu bạn không thể hoàn thành công việc.

Tôi đã trả lời một câu hỏi khác dọc theo các dòng tương tự (có nội dung tương tự) ở đây:

Mẹo, hướng dẫn, điểm cần nhớ để kết xuất mã chuyên nghiệp?

Trong tiêu đề " vv " xuất hiện một cái gì đó có thể dễ dàng chiếm 50% hoặc nhiều thời gian của bạn.

Tìm hiểu làm thế nào để gỡ lỗi.

Điều này có nghĩa là học Phương pháp khoa học . Tôi có nghĩa là thực sự học nó. Và sau đó áp dụng nó với sự trung thực tự tàn bạo . Tìm hiểu cách nêu chính xác những gì bạn biết là đúng, những gì bạn biết là không đúng và những điều bạn không biết. Bất cứ khi nào bạn chậm chạp gán một mục vào danh mục sai, bạn đã làm cho cuộc sống của bạn rất nhiều khó khăn hơn .

Học cách nói "Tôi nghĩ" thay vì "Tôi biết". Bạn chỉ có thể nói "Tôi biết" khi bạn "nghĩ" điều gì đó là đúng (hoặc sai), và sau đó bạn chứng minh điều đó!

Nhiều lỗi rất nhỏ, nhưng chúng có thể khó nhìn thấy vì bạn "biết" mã nên là gì ... ngoại trừ không phải vậy. Tìm một freind để giải thích nó. Yêu cầu họ trở thành một "thằng ngốc chuyên gia": một người không biết mã của bạn, nhưng người mà bạn biết bạn không thể thổi bay BS. Đừng ngạc nhiên nếu ở giữa một mô tả cho họ, bạn đột nhiên dừng lại và nói, "và vì vậy bạn có thể ... thấy ... thấy rằng ... sh * t. Cảm ơn."

Các lỗi không cần thiết đòi hỏi một kho kỹ thuật. Một tác phẩm kinh điển có thể nhanh chóng làm nổi bật hầu hết các lỗi không liên quan đến thời gian là Hàng rào Sói ở Alaska. Có một con sói ở đâu đó ở Alaska; xây dựng một hàng rào cắt nhà nước một nửa. Sói ở phía nào? Cắt bên đó làm đôi. Lót, rửa sạch, lặp lại. Làm điều này 20 lần tại các địa điểm được chọn tốt trong mã sẽ giảm diện tích nơi con bọ (sói) có thể xuống 1/1048576. Giết con sói đó.

Mẹo: nhìn cho handwaves -physical, tâm thần, hay bất kỳ loại khác. Ngay khi bạn (hoặc đồng nghiệp của bạn) nao núng / chuyển hướng / giảm thiểu sự chú ý phải trả cho một phần của mã, hãy hoàn toàn điên cuồng . Bởi vì khu vực mà bạn chỉ biết lỗi không thể, mặc dù bạn đã dành hàng giờ / ngày để tìm kiếm thứ d * mn và vẫn không thể tìm thấy nó ... đó là vị trí có xác suất cao nhất cho lỗi. Không ai có được 'tạm biệt' , không ai (bao gồm cả máy, HĐH, trình biên dịch hoặc bạn ) nhận được bất kỳ loại "sự tôn trọng" nào. Có một lỗi. Giai đoạn = Stage. Kết thúc câu. Bây giờ đi giết điều d * mn.

Tôi biết không có trường nào dạy gỡ lỗi như một môn học cho chính nó. IMNSHO, đây có thể là bằng chứng rõ ràng nhất mà họ (các trường đại học / giáo sư) không dạy bạn trở thành một lập trình viên, thay vào đó, họ dạy bạn trở nên ... giống họ? Khắc nghiệt? Có lẽ. Thật? Làm cho tâm trí của riêng bạn. Bây giờ hãy chứng minh điều đó.

Tôi e rằng đây là một câu hỏi khá lớn đối với bất kỳ ai trả lời một cách thuyết phục hoặc có thẩm quyền, đặc biệt là bạn muốn có một danh sách ưu tiên. Có rất nhiều lập trình viên ngoài kia, và họ làm việc trên những thứ rất khác nhau - chắc chắn, các nguyên tắc cơ bản vẫn giống nhau, nhưng những gì bạn cần để duy trì hoạt động trong bộ nhớ của bạn có thể thực sự khác biệt, và thực sự có rất nhiều nhiệm vụ mà bạn có thể giữ được trình độ cao mà không đi sâu hơn.

Dường như bạn thực sự quan tâm về việc làm thế nào để trở thành một nhà phát triển tốt hơn, và không chỉ là một giao dịch độc quyền. Tôi thấy điều đó thật đáng ngưỡng mộ và tôi có thể chia sẻ một số điều đã giúp tôi học cách lập trình.

Khá nhiều tất cả các chương trình tập trung vào các thuật toán và cấu trúc dữ liệu. Đến lượt chúng, là những ví dụ cho câu hỏi lớn hơn - làm thế nào để chúng ta mô hình hóa mọi thứ và quy trình từ thế giới thực thành một đại diện để máy tính có thể hiểu được. Nếu bạn chỉ mới bắt đầu, có thể hữu ích khi sử dụng ngôn ngữ lập trình cấp cao hơn (như Java, Python, bất cứ thứ gì) để làm quen với việc thực hiện các cấu trúc dữ liệu và thuật toán.

Tại một thời điểm nhất định, khi chơi xung quanh với các cấu trúc dữ liệu và thuật toán, bạn có thể bắt đầu nhận được câu hỏi gặm nhấm đó "nhưng làm thế nào để chúng ta biết từ máy tính phải làm gì, với máy tính thực sự làm gì?" Sau đó, bạn có thể xem xét cách máy tính thực sự tính toán - cách bộ nhớ và CPU phối hợp với nhau để thực hiện các lệnh, cách hệ điều hành trừu tượng hóa phần cứng để bạn có thể viết chương trình, mở tệp, mà không cần mã hóa ở mức thấp cụ thể giao diện ổ cứng.

Đây có lẽ là một điểm tốt để bắt đầu - cách các thuật toán và cấu trúc dữ liệu mô hình hóa các vấn đề từ thế giới thực và cách một máy tính thực sự thực hiện tính toán. Biết cái sau rất hữu ích trong việc thành thạo các ngôn ngữ cấp thấp hơn như C, sử dụng ít khói và gương hơn so với OO và ngôn ngữ kịch bản :)

YAGNI : "Luôn thực hiện mọi thứ khi bạn thực sự cần chúng, không bao giờ khi bạn thấy trước rằng bạn cần chúng."

Theo kinh nghiệm của tôi, thông thường các "lập trình viên" sẽ thấy trước nhiều trường hợp trong tương lai và cố gắng "cải thiện" mã bằng cách thêm mã để dự đoán chúng! Trong hầu hết các trường hợp, mã mà họ đã thêm sẽ chỉ làm mờ mã và thêm độ phức tạp vào mã.

Điều quan trọng nhất cần biết về việc trở thành một lập trình viên là viết mã là một công việc khó khăn và thái độ "cổ áo xanh" giống như người lao động đối với việc sản xuất những gì bạn được trả tiền để sản xuất sẽ giúp bạn tiến xa hơn bất kỳ học hỏi bí truyền nào.

Tìm hiểu để vào khu vực. Điều đó có nghĩa là trạng thái tinh thần khi bạn chỉ tập trung vào nhiệm vụ của mình và bạn có thể bắt đầu giữ nhiều thứ tuyệt vời trong đầu và cách chúng tương tác tất cả cùng một lúc. Khi bạn đã có thói quen vào khu vực theo ý muốn, hãy bắt đầu lo lắng về phần còn lại. Cho đến khi bạn có thể viết ra mã giống như một loại mã nào đó đang bị hỏng, phần còn lại hầu như vô dụng.

BIÊN TẬP:

Nếu bạn không tin điều này và bạn đánh giá thấp tôi, tôi tin rằng bạn không biết liệu bạn có quyết tâm thực hiện nó trong 20 năm hay không. Tôi biết rằng tôi làm bởi vì tôi chấp nhận điều này. ;)

Một câu hỏi gần đây, liên quan theo cách nào đó với câu hỏi này và Trả lời có một liên kết đến Blog này thảo luận về cùng một vấn đề từ một góc độ khác.

Có lẽ khái niệm quan trọng nhất đối với bất kỳ nhà phát triển nào là "khiêm tốn" .... Một khi bạn chấp nhận bạn không biết tất cả, bạn sẵn sàng khám phá các giải pháp. Hầu hết những người viết blog về lập trình đều nằm trong nhóm phần trăm hàng đầu, và vấn đề là nhiều người vẫn chưa kiểm soát được xu hướng tự ái của mình .... đó là lý do tại sao họ viết blog ..... Bạn cần học cách xác định những blogger này và mặc kệ

Blog được liên kết thực sự không có gì nhiều ngoài một lời ca ngợi - Trong mọi ngành công nghiệp phàn nàn rằng sinh viên tốt nghiệp gần đây là vô dụng là phổ biến, phải mất nhiều năm để có được chúng hữu ích và hiệu quả. Có lẽ vấn đề là những guru tự xưng này thực sự kỳ vọng quá nhiều và đã quên rằng một khi họ sẽ không thể giải quyết FizzBuzz. Theo định nghĩa, không phải ai cũng có thể nằm trong top 10 phần trăm, theo định nghĩa, một nửa số lập trình viên dưới mức trung bình ......