Nhìn lại sự nghiệp và cuộc đời làm lập trình viên của tôi, có rất nhiều cách khác nhau để tôi cải thiện kỹ năng lập trình của mình - đọc mã, viết mã, đọc sách, nghe podcast, xem screencasts và hơn thế nữa.

Câu hỏi của tôi là: điều hiệu quả nhất bạn đã làm để cải thiện kỹ năng lập trình của bạn là gì? Bạn muốn giới thiệu gì cho những người khác muốn cải thiện?

Tôi thực sự mong đợi các câu trả lời khác nhau ở đây và không có câu trả lời "một kích thước phù hợp với tất cả" - tôi muốn biết những gì đã làm việc cho những người khác nhau.

Không theo thứ tự cụ thể ...

• Làm việc với những người thông minh hơn tôi nhiều

• Luôn luôn lắng nghe những gì người khác nói, bất kể họ là thiếu niên, trung cấp, cao cấp hay guru. chức danh công việc không có ý nghĩa gì.

• Học các khuôn khổ / ngôn ngữ khác và xem cách họ làm mọi thứ và so sánh nó với những thứ mà tôi đã biết

• Đọc về các mẫu, thực tiễn tốt nhất và sau đó kiểm tra nội dung cũ của tôi và áp dụng các mẫu đó khi cần thiết

• Lập trình cặp

• Không đồng ý với mọi thứ Joel nói. ;)

Quyết định ĐỂ là một 'Jack-of-all-Trades'

Khá sớm trong sự nghiệp của tôi, tôi là một chuyên gia với một cơ sở dữ liệu và ngôn ngữ lập trình cụ thể. Thật không may, cơ sở dữ liệu cụ thể đó đã mất 'cuộc chiến cơ sở dữ liệu' và tôi phát hiện ra rằng các lựa chọn nghề nghiệp của mình bị ... hạn chế. Sau đó, tôi quyết định một cách có ý thức rằng tôi sẽ không bao giờ để mình trở nên bị đóng hộp như thế nữa. Vì vậy, tôi đã nghiên cứu mọi thứ tôi có thể có trong tay: Windows, Unix, C, C ++, Java, C #, Perl, Python, Access, SQL Server, Oracle, Informix, MySQL, v.v. trở thành 'chàng trai' - "Hỏi Craig, nếu anh ta không biết điều đó, anh ta sẽ học nó." Kết quả là tôi đã làm việc trên tất cả các loại dự án, từ các hệ thống nhúng cho đo từ xa môi trường đến các hệ thống chỉ huy và kiểm soát để phòng thủ tên lửa.

Vấn đề duy nhất tôi từng gặp là với các công ty khăng khăng đòi tôi trở thành một chuyên gia, khi chuyên môn của tôi là một nhà tổng quát. [EDIT: Còn được gọi là Polymath hoặc Renaissance Man hoặc đa chuyên gia. ]

Một cái gì đó để ghi nhớ ... những gì nửa đời của kiến ​​thức trong công nghệ cao? Nó theo dõi theo Định luật Moore: một nửa mọi thứ bạn biết sẽ bị lỗi thời sau 18-24 tháng. Một chuyên gia chọn sai ngành học có thể dễ dàng bị làm suy yếu bởi báo chí của công nghệ; một người nói chung chỉ phải thêm một số kỹ năng và ghi nhớ những bài học trong quá khứ trong việc áp dụng những kỹ năng đó.

Tôi luôn nghĩ về bản thân mình là một lập trình viên khá nóng bỏng. Sau đó, một anh chàng mới, gọi anh ta là Aaron, được thuê vào đội của chúng tôi. Aaron rõ ràng là tốt hơn tôi nhiều trong hầu hết các lĩnh vực. Anh ấy cũng trẻ hơn tôi. Anh ấy làm cho tôi nhận ra tôi đã không thực sự cải thiện nhiều trong những năm qua. Tôi là một hacker phi thường, và là một người tầm thường ở đó.

Điều này cảnh báo tôi có ý thức cố gắng cải thiện bản thân và đặc biệt là chất lượng mã tôi viết.

Aaron dẫn tôi đi học rất nhiều thứ. Anh ấy dạy tôi rằng hầu hết các mã tôi viết sẽ phải được duy trì và gia hạn ít nhất vài năm, vì vậy tôi nên viết mã với suy nghĩ đó. Tôi nên viết bài kiểm tra tự động cho mã của tôi. Aaron luôn nói về việc tôi không bao giờ nên dừng lại ở phiên bản làm việc đầu tiên, nhưng tái cấu trúc và tinh chỉnh cho đến khi mã thanh lịch. Tôi đã phát hiện ra rằng các ngôn ngữ và công cụ tôi đang sử dụng có rất nhiều chỗ để cải thiện.

Điều quan trọng nhất tôi học được từ Aaron là không bao giờ ngừng học hỏi.

Sau một vài năm, Aaron rời công ty. Tôi cảm thấy trống rỗng. Những năm qua với anh ấy đã nâng tôi lên một cấp độ kỹ năng hoàn toàn mới, và tôi nhận ra rằng bây giờ tôi đã tốt hơn nhiều so với các thành viên còn lại trong đội. Họ vẫn đang viết mã xấu và làm những lỗi sai như trước đây. Tôi đã cố gắng dạy chúng, nhưng chúng không có hứng thú để học. Trên thực tế, họ rất bực mình vì ai đó sẽ rất kiêu ngạo khi nói cho họ biết họ đã làm gì sai.

Vì vậy, một vài tháng sau, tôi cũng rời công ty. Tôi chuyển đến một công ty nhỏ hơn với một đội ngũ rất tài năng. Mọi người ở đó muốn tìm hiểu thêm, và tôi yêu nó.

Tôi rất vui vì đã gặp Aaron. Không có anh ta, có lẽ tôi vẫn đang làm việc tại công ty cũ với băng đảng cũ, không đi đến đâu và nghĩ quá nhiều về bản thân.

Hai điều:

1. Đọc mã được viết bởi những người khác nhau.
2. Viết tài liệu cho mã được viết bởi người khác.

Viết mã cực kỳ dễ dàng; mọi người khác mà tôi biết đều có thể làm điều đó. Nhưng đọc mã của người khác và tìm ra những gì nó làm là một thế giới hoàn toàn mới đối với tôi.

Tập gym thường xuyên.

Nghiêm túc mà nói, bộ não của tôi hoạt động tốt hơn rất nhiều khi tôi có vóc dáng. Các vấn đề trở nên dễ dàng hơn và ít áp đảo hơn, việc giải quyết vấn đề ít bị cám dỗ hơn và việc giải quyết từng bước dường như không phải là một nhiệm vụ khó khăn.

Lập trình. Làm việc trên các dự án thú vị. Không có gì giống như vào và làm việc trên các công cụ. Đặc biệt là dưới áp lực. Tôi luôn nói với bất cứ ai hỏi tôi cách lập trình - chỉ cần tìm một dự án thú vị (ngay cả khi bạn phải thực hiện) và làm việc với nó.

Đã làm một công việc bán thời gian dạy kèm sinh viên CS tại trường đại học của tôi. Nó thực sự buộc bạn phải hiểu một cái gì đó ở một cấp độ hoàn toàn khác khi bạn phải giải thích nó cho người khác.

1. Tôi là một fan hâm mộ lớn của hệ thống "học một ngôn ngữ lập trình mỗi năm". Một năm cho bạn đủ thời gian để vượt qua "không sao, tôi biết cú pháp, vì vậy bây giờ tôi biết sự thiên vị của ngôn ngữ" và buộc bạn phải đi xa hơn một chút và hiểu những gì có lợi trong ngôn ngữ đó, và lập trình theo phong cách bản địa ngôn ngữ đó (ý tôi là, cuối cùng bạn không viết các ứng dụng java bằng cú pháp Ruby). Mỗi ngôn ngữ sẽ thay đổi cách bạn nghĩ về lập trình - Tôi biết cách sử dụng đệ quy, nhưng suy nghĩ đệ quy đã không xảy ra cho đến khi tôi tham gia một lớp học về prolog (tôi tưởng tượng một ngôn ngữ chức năng như ML sẽ có tác dụng tương tự).

2. Bắt đầu một dự án thú cưng. Phương trình cá nhân của tôi cho một dự án thú cưng tốt là, một cái gì đó bạn có kinh nghiệm với + thứ gì đó bạn không = ứng dụng bạn sẽ thấy hữu ích. Chẳng hạn, Migratr (dự án đang diễn ra vào cuối tuần của tôi) bắt đầu với tên "Tôi biết c #, nhưng tôi chưa bao giờ mã hóa với API web. Và tôi muốn chuyển tất cả ảnh của mình sang Zooomr". Nó có thể dễ dàng như "Tôi đã được mã hóa theo API web trước đây, nhưng tôi không biết C #"

Xuất bản dự án thú cưng của bạn là một kinh nghiệm giáo dục tuyệt vời trong chính nó. Đột nhiên tất cả những điều thực tế không ai dạy nhưng mọi người đều phải biết (đối với tôi, đó là thiết lập hệ thống thử nghiệm của riêng bạn, tận dụng tối đa các hệ thống kiểm soát phiên bản, làm thế nào để tăng tốc khi không ai đặt ra thời hạn, cách tương tác với bạn người dùng và làm thế nào để biết khi nào nên nói "không" với các yêu cầu tính năng), tất cả những thứ đó nổi bong bóng lên bề mặt và buộc bạn phải tự học ở cấp độ mà bạn chưa từng thấy trước đây - ít nhất là không bằng cách đọc những câu nói nhảm nhí trên dzone về ưu / nhược điểm của cách làm "foo" vs "bar".

Làm hai điều này bao gồm cả hai đầu của quang phổ. Học một ngôn ngữ mới sẽ giúp bạn trở thành một lập trình viên tốt hơn. Dự án thú cưng sẽ giúp bạn trở thành một nhà phát triển tốt hơn: P

Tự lắp ráp. Có phải trên một con chip 6502 cũ khi tôi 13 tuổi? 14? Quá lâu rồi Nhưng tôi không thể nghĩ bất cứ điều gì sẽ cải thiện sự phát triển của bạn hơn là xuống mức bit.

Học tập cung cấp cho bạn cái nhìn sâu sắc về cách máy tính 'suy nghĩ' ở mức độ cơ bản thấp hơn, và sự thanh lịch ở cấp độ này là đáng ngạc nhiên ... không có chuyển động lãng phí, không 'xử lý' dữ liệu. Phát triển ở cấp độ này sẽ dạy cho bạn hiệu quả và trau dồi tư duy phê phán và kỹ năng logic. Nó cũng sẽ chữa cho bạn mọi thói quen cẩu thả mà bạn có khá nhanh!

Chip 65xx có ba thanh ghi (bộ tích lũy, X và Y) và không có hướng dẫn cấp độ máy để nhân hoặc chia. Tôi nhớ mã hóa một thói quen để tính toán thiệt hại chiến đấu, xem qua cuốn sách và đột nhiên nhận ra rằng tôi sẽ phải viết thư viện toán học của riêng mình. Dành vài tuần để viết nguệch ngoạc 1 và 0 trên sổ ghi chép của tôi, cố gắng tìm ra ý nghĩa của 'chia' và 'số thập phân' thực sự có nghĩa là gì.

Tôi đã học C ++, pascal, .NET, nhiều người khác kể từ đó ... nhưng không ai trong số họ dạy tôi nhiều như vậy, khiến tôi tò mò nhiều, hoặc để lại cho tôi cảm giác 'wow' mà hội nghị trên hàng hóa cũ của tôi đã làm .

Nhìn lại những điều cũ tôi đã viết và nhận ra chúng tệ đến mức nào.

Đọc

• sách, không chỉ các trang web
• để tự cải thiện, không chỉ cho dự án mới nhất
• về cải thiện giao dịch của bạn, không chỉ về công nghệ mới nhất
• đọc mã, không chỉ là bạn đang làm việc.

Chỉ cần phát triển sự thèm ăn để đọc.

Lập trình.

Nghiêm túc mà nói, có sách, có katas mã hóa, có những trang như thế này, nhưng tôi tin rằng cách tốt nhất để cải thiện như một nhà phát triển là làm việc trong dự án thực, với những khách hàng thực sự với những yêu cầu thực sự, luôn thay đổi với kỹ thuật thực các vấn đề. Không có thay thế cho kinh nghiệm.

Tôi nghĩ rằng điều quan trọng nhất bạn có thể làm là nỗ lực có ý thức để cải thiện. Không có viên đạn bạc nào, bạn phải tiếp tục tìm kiếm nguồn thông tin mới, trải nghiệm mới và thực hành nhiều hơn.

Và điều quan trọng thứ hai, hãy nghĩ về những gì bạn đang làm, tại sao bạn làm nó và làm thế nào bạn có thể làm nó tốt hơn. Điều tương tự với các dự án trước đó. Nhìn lại những gì bạn đã làm và làm thế nào bạn có thể làm nó khác đi bây giờ. Hãy suy nghĩ về những gì có thể đã được thực hiện tốt hơn, hoặc nơi bạn vẫn có thể cải thiện nó.

Tôi thấy hai ví dụ tuyệt vời về điều này tại nơi làm việc mỗi ngày. Tôi có một đồng nghiệp yêu thích học hỏi và muốn trở thành nhà phát triển tốt nhất có thể. Anh ấy sử dụng bất kỳ thời gian chết nào để đọc blog, đọc sách, thảo luận về kỹ thuật lập trình và đặt hàng tấn câu hỏi. Anh ấy cũng cải thiện rất rõ rệt chỉ trong năm qua. Một đồng nghiệp khác làm công việc của mình, và làm nó khá tốt. Nhưng đó là tất cả những gì anh ấy làm. Anh ấy kiên định với những gì anh ấy biết, không nỗ lực cải thiện, không làm việc với bất kỳ dự án nào ngoài những dự án hiện có của anh ấy và sau 4 năm, anh ấy có chính xác bộ kỹ năng và khả năng lập trình mà anh ấy có khi tôi gặp anh ta.

Nhiều người đã đề nghị viết mã. Tôi phải nói rằng đọc mã của người khác có lợi hơn nhiều.

Cặp đôi được lập trình với những người rất đa dạng và có quan điểm

Những điều cơ bản đã giúp tôi như một lập trình viên:

• Học đánh máy cảm ứng.
• Học cách vượt qua sự nhút nhát và đặt câu hỏi.

Gõ cho một lập trình viên là điều cần thiết. Mọi người đều có một đồng nghiệp "lập trình viên", người đã gõ chính xác bằng hai ngón tay và phải nhìn vào bàn phím để tìm mọi thứ. Không vui. Học cách chạm vào giúp tăng năng suất rất lớn cho năng suất làm lập trình viên của bạn.

Và nếu bạn không hỏi, không ai sẽ nói với bạn.

Đóng góp cho / tham gia vào các dự án nguồn mở cho đến nay là điều lớn nhất đối với tôi.

Bạn có thể đọc tất cả các sách, mã và các dự án nguồn mở mà bạn thích, nhưng bạn cần hiểu khía cạnh người dùng cuối trong phát triển phần mềm. Bạn cần phải bước ra khỏi buồng vang. Vì vậy, tôi sẽ giải quyết một vài điểm phi kỹ thuật sẽ giúp ích cho sự nghiệp kỹ thuật của bạn.

1. Bước ra khỏi bàn phím và tương tác với người dùng cuối và xem, qua đôi mắt của họ, cách họ sử dụng phần mềm. Người dùng cuối thường không có kỹ thuật, vì vậy họ xem phần mềm là một công việc kỳ diệu, trong khi bạn thấy phần mềm là một tập hợp các bước hợp lý. Hai thế giới hoàn toàn khác nhau. Vì vậy, những gì có vẻ dễ dàng và hợp lý với bạn có vẻ khó hiểu và đáng sợ với người khác.

2. Kiểm tra, kiểm tra, kiểm tra. Rất nhiều phần mềm tôi đã thấy trong các tập đoàn lớn sử dụng các trường hợp thử nghiệm. Chết tiệt, họ sử dụng JUnit, xUnit và tất cả các ngôn ngữ thử nghiệm đơn vị khác ngoài kia. Nhưng vấn đề tôi thấy là hầu hết các lập trình viên không bao giờ thấy phần mềm của họ trông như thế nào trong Sản xuất. Tìm hiểu cách người dùng (hoặc hệ thống, nếu đây là các công việc hàng loạt) tương tác với ứng dụng, thư viện hoặc giao diện của bạn để tìm hiểu loại thông tin gớm ghiếc nào họ ném vào nó. Điều này sẽ giúp bạn tạo ra các trường hợp kiểm tra tốt và ngừng giả định rằng chương trình của bạn sẽ luôn được cung cấp đúng bộ dữ liệu.

Đề án đã học.

Viết mã và rất nhiều nó.

Học biểu thức chính quy.

Cạnh tranh trong các cuộc thi thuật toán TopCoder .

Đi hết: tạo dự án của riêng bạn, các cột mốc của bạn, tài nguyên của bạn, phụ thuộc, yêu cầu và kế hoạch kiểm tra. Nó sẽ buộc bạn không chỉ cải thiện kỹ năng lập trình của mình để vận hành trong các thông số cụ thể, mà còn phục vụ để làm nổi bật chính xác nơi bạn cần cải thiện nhất. Thực hiện cập nhật thường xuyên về tiến trình của bạn, cho dù thông qua blog hoặc cập nhật dự án chính thức hơn, để bạn có thể thấy chính xác nơi bạn đã đến và nơi bạn hy vọng sẽ đi.

Bỏ công việc cuối cùng của tôi.

Tôi nghĩ rằng liên tục đặt câu hỏi về những gì bạn đang làm là điều lớn nhất. Đừng bao giờ nghĩ rằng mã của bạn là hoàn hảo, hãy luôn phấn đấu để cải thiện nó.

Có vẻ như tôi đã có 2 hoặc 3 lần khi tôi nghĩ rằng mã của mình là hoàn hảo, sau đó nhận ra rằng tôi còn một chặng đường dài để đi.

Tôi đoán điều lớn nhất là khi tôi bắt đầu thấy mã của mình bị tiêu thụ bởi các lập trình viên khác chứ không phải máy. Viết mã dễ dàng, máy của bạn có thể xử lý, nhưng viết mã DRY khó hiểu, mã dễ hiểu.

Và tôi không có nghĩa là chỉ hiểu "Dòng này làm gì", ý tôi là làm cho nó trở nên tầm thường để tìm ra "Làm thế nào lớp này phù hợp với tất cả các lớp khác" trong khi làm cho giao diện lớp được hình thành tốt đến mức gần như không thể lạm dụng nó

Họ nói rằng 70% mã tốt là kiểm tra và xử lý lỗi. Khi tôi bắt đầu lập trình theo cách đó, mã của tôi đã tốt hơn rất nhiều. Suy nghĩ về những gì có thể đi sai và sau đó xử lý nó ngay lập tức đã tạo ra một sự khác biệt rất lớn. Nó cảm thấy như đang làm tất cả các kiểm tra mà chỉ là nhận được trong cách nhận mã và chạy, nhưng nó sẽ rút ngắn thời gian từ lúc bắt đầu đến kết thúc bởi một yếu tố của 2-4.

Những người này "họ" là ai và "họ" sống ở đâu?

Kỹ năng mã hóa của tôi đã cải thiện rất nhiều khi tôi bắt đầu tự hỏi trước khi thực hiện một cái gì đó làm thế nào tôi sẽ ghi lại điều này .

"Điều" ở đây nên có tất cả các mức độ chi tiết có thể. Từ phương pháp đến toàn bộ sản phẩm. Chẳng hạn, ở cấp độ phương thức, nó ngăn chặn việc thêm một phương thức trong API không phù hợp hoặc không rõ ràng trước khi thực sự viết nó. Và nếu tôi thực sự cần thực hiện một phương pháp tôi không thể ghi lại (một cách dễ dàng), thì đó là một dấu hiệu có vấn đề về thiết kế ở đâu đó ...

Tự động, thái độ " nếu tôi không thể giải thích nó, tôi không viết nó " lọc ra mã xấu và ngược lại một khi tôi biết cách ghi lại chính xác một điều, nó sẽ trở nên đơn giản và dễ thực hiện hơn.

Không ngừng học hỏi và thực hành những gì bạn học.

Bằng phương tiện:

1. Dự án cá nhân: Kể từ khi tôi bắt đầu lập trình, tôi đã thực hiện các dự án cá nhân. Khác nhau, từ các trò chơi nhỏ, xử lý hình ảnh, steganography, thực hiện các đặc tả loại tệp, thực hiện các giao thức khác nhau từ đầu hoặc thực hiện các chương trình khác nhau theo thời gian.

2. Đọc sách: Tôi quyết định đọc và theo dõi các cuốn sách khác nhau trong thời gian rảnh rỗi. Có rất nhiều cuốn sách được viết tốt bởi các chuyên gia chỉ ngồi chờ đợi để được đọc. Độ sâu bạn có thể nhận được từ một cuốn sách là không thể so sánh bằng ví dụ đọc các bài đăng khác nhau trên diễn đàn.

Đây thường là thứ tự thời gian của tôi để học bất kỳ công nghệ mới nào:

1. Thường xuyên đọc blog tốt (Atwood, Martin Fowler, v.v.), Cập nhật tin tức công nghệ, Theo dõi nội dung về công nghệ mới thú vị. Các bước này sẽ cho phép tôi quyết định nếu tôi tìm thấy bất cứ điều gì thú vị để khám phá thêm.

2. Đọc đúng cuốn sách hoặc bất kỳ tài nguyên nào khác để học theo cấp độ của bạn (ví dụ: cho người mới bắt đầu nếu bạn muốn tìm hiểu các mẫu thiết kế, tôi sẽ đề xuất 'Mẫu đầu tiên thiết kế'). Tôi cũng có sở thích cụ thể cho sách .

3. Tung ra một hoặc hai dự án đồ chơi bằng cách sử dụng điều tôi đã học. Tôi không lo lắng về tính hữu ích của dự án. Ý định của tôi chỉ là khai thác việc học của tôi. (ví dụ: Một dự án máy tính cho OOP sẽ ổn)

4. Tôi sẽ xem nếu tôi có thể sử dụng những thứ trong công việc . (ví dụ: Mặc dù chúng tôi không sử dụng lật đổ tại nơi làm việc, tôi sử dụng nó làm kho lưu trữ cục bộ của mình, tôi đã sử dụng Ruby cho một nhiệm vụ nếu không quá đơn điệu và tốn thời gian)

5. Đây là phần tốt nhất mà tôi nghĩ rằng hầu hết mọi người bỏ lỡ. Các buổi chia sẻ kiến ​​thức. Lấy một hoặc hai phiên cho các thành viên trong nhóm chẳng hạn. Tôi tin rằng giảng dạy là một trong những cách tốt nhất để thực sự học công nghệ. Tôi đảm bảo mức độ hiểu biết của bạn về công nghệ sẽ trở nên đa dạng, cho dù khán giả của bạn có hiểu hay không. :-)

Hack một số dự án nguồn mở trong một vài tháng; càng lớn càng tốt. Khi bạn tương tác với một số người có địa lý cao, đa dạng về địa lý, những người không biết bạn, bạn không thể không học hỏi từ những sai lầm của mình nhanh hơn - tôi nghĩ đó là một yếu tố ngượng ngùng nhất định. Thêm vào đó, nếu bạn xác định một hoặc hai người thực sự thông minh, thì bạn có thể lượm lặt được cái nhìn sâu sắc có giá trị, nếu không phải là kiến ​​thức thuần túy, từ họ.