Là một lập trình viên cao cấp lời khuyên về việc luôn luôn sử dụng sách là một ý tưởng tốt? [đóng cửa]


53

Tôi là một nhà phát triển cơ sở và chỉ mới ở trong ngành được 5 năm. Ở công ty hiện tại của tôi có một đàn anh hãy gọi anh ta là Infestus. Thỉnh thoảng tôi được trao cơ hội để tỏa sáng và làm một cái gì đó hoàn toàn mới từ đầu.

Một trong những ví dụ gần đây nhất là tôi phải tạo một singleton trong ứng dụng đa luồng. Tôi đã quyết định sử dụng phương pháp này . Ngay khi Infestus nhìn thấy nó, anh ta đã nhanh chóng gọi tôi là đồ ngốc và bảo tôi sử dụng phương pháp này . Khi hỏi anh ta tại sao anh ta lại gạt nó đi vì điều này tốt hơn và đó là cách mà cuốn sách này về Java nói rằng nó tốt hơn.

Và đó là một mô hình phổ biến: bất cứ khi nào tôi có cơ hội làm điều gì đó mới, tôi nhanh chóng bị Infestus bắn hạ và lý do duy nhất tại sao phương pháp của anh ấy tốt hơn là vì những cuốn sách đó được viết bởi các lập trình viên nổi tiếng. Anh ấy luôn cố gắng đưa cho tôi những cuốn sách để đọc để tôi có thể "học" những cách lập trình.

Tôi mới chỉ lập trình được tiền trong 5 năm, nhưng liệu có nên luôn mù quáng theo dõi cuốn sách về những cách tốt nhất để giải quyết vấn đề, hay tôi nên thử nghiệm mọi lúc mọi nơi? Hàng loạt khiếu nại liên tục từ Infestus đang bắt đầu khiến tôi không bao giờ thử bất cứ điều gì mới và làm theo các ví dụ trong sách.

EDIT : Tôi hoàn toàn bị mất. Vâng, tôi biết rằng làm theo bất cứ điều gì một cách mù quáng là một ý tưởng tồi. Nhưng lập trình viên thần thánh Infestus này dường như biết rất nhiều, nói với tôi rằng cách duy nhất để lập trình đúng là đọc sách và tuân theo mọi thứ cho đến T. Tất cả các quy tắc mà anh ta áp đặt là những điều được viết trong sách, vì vậy tôi chỉ đang tự hỏi nếu sách là cách duy nhất đúng.

EDIT2 : Infestus không phải là ông chủ của tôi. Ông chỉ là một trong những nhà phát triển cao cấp phụ trách việc xem xét mã. Và hầu hết các ý kiến ​​của ông sau khi đánh giá bao gồm tên sách trong đó phương pháp như vậy và như vậy là sai.


100
Là theo bất cứ điều gì mù quáng là một ý tưởng tốt?
Thất vọngWithFormsDesigner

16
Theo dõi bất cứ điều gì một cách mù quáng là một ý tưởng tồi, nhưng đừng để "Infestus" làm bạn khó chịu trên sách. Đọc sách là một trong những cách tốt nhất để ra khỏi vùng thoải mái và nâng cao kỹ năng lập trình của bạn.
Kyralessa

21
Nghe có vẻ như đàn anh có thể biết lý do tại sao anh ta đang theo những cách giải quyết vấn đề cụ thể này - nhưng có lẽ họ không muốn dành thời gian để giải thích lý do cho bạn, và chỉ đưa bạn đến các tài nguyên giải thích nó. Bạn đã đọc các tài nguyên anh ấy đã hướng dẫn bạn? Họ có giải thích tại sao giải pháp được chọn không?
Joris Timmermans

28
5 năm vào đó bạn không còn là đàn em nữa, bạn biết không? Infestus biết điều đó?
iluxa

25
...brushed it off as this is better and that's how this and this book about java says it is better. Điều này sẽ đặt ra chuông báo động ngay lập tức. Nếu Infestus không thể đưa ra lời giải thích độc lập, anh ta có thể không hiểu chính mình. (Hoặc anh ta cần một bản sao Sách minh họa về những lý lẽ xấu .)
Blrfl

Câu trả lời:


87

Bạn sẽ chạy vào lập trình viên như thế này toàn bộ sự nghiệp của bạn. Không có gì sai với thử nghiệm và tự học. Chắc chắn sách rất hay. Nhiều lần các ví dụ hoạt động trong một môi trường sạch, nhưng nếu bạn là nhà phát triển cho một công ty khác thì không có thứ gì gọi là môi trường sạch (không có sự can thiệp từ người khác).

Thật tuyệt khi biết cách làm mọi thứ theo cách "đúng", nhưng ý kiến ​​thay đổi theo từng năm. Vì vậy, học những gì bạn có thể. Lấy những gì bạn có thể từ nhà phát triển cao cấp, pha trộn nó với kiến ​​thức mà bạn tự học. Cuối cùng, bạn sẽ là một nhà phát triển cao cấp và sẽ được rút kinh nghiệm và dạy các nhà phát triển cơ sở.

Đừng là một thằng ngốc về nó.


65

Anh ta thực sự gọi bạn là ngu ngốc, hay anh ta chỉ chê bai mã? Gọi bất cứ điều gì ngu ngốc là vô nghĩa, nhưng điều đó không làm mất hiệu lực đề xuất. Tôi nghĩ Infestus đã đưa ra một đề nghị có giá trị, và trong tương lai bạn nên xem xét đề xuất của anh ấy một cách nghiêm túc. Anh ta dường như làm rất nhiều việc đọc, và ít nhất trong trường hợp này ý kiến ​​của anh ta được thông tin đầy đủ. Đồng bộ hóa vừa tốn kém vừa khó khăn. Việc thực hiện được đề xuất của anh ta hiệu quả và đơn giản hơn so với của bạn và được đảm bảo để làm việc.

Anh ấy luôn cố gắng đưa cho tôi những cuốn sách để đọc để tôi có thể "học" những cách lập trình.

Đó là loại anh ấy. Anh ấy đang tích cực cố gắng để giúp bạn, nhưng dường như bạn đang để cho cái tôi của bạn cản trở. Đừng chỉ trích cá nhân mã của bạn. Mã rẻ để sản xuất và dễ dàng thay đổi. Nếu ai đó chỉ cho bạn một cách đơn giản hơn để làm một cái gì đó, cảm ơn họ.

Và vâng, đọc sẽ làm cho bạn một lập trình viên tốt hơn nhiều. Tất cả các chuyên gia tôi đã biết đọc rộng rãi. Nếu bạn không đọc nhiều, thì bạn là người tầm thường nhất, và trong năm năm nữa bạn có thể thấy rằng bạn không còn có thể tiếp thị được nữa.


6
Bạn đưa ra một quan điểm rất hay và bài viết bạn liên kết đến rất thú vị, nhưng cuối cùng nó nói rằng khóa kiểm tra kép không hoạt động với JDK 1.4 trở về trước (với các mô hình bộ nhớ của JDK). Kể từ JDK 1.5 và hơn thế nữa, nó hoạt động, miễn là trường giữ thể hiện được khai báo là không ổn định (đó là trường hợp trong ví dụ được liên kết bởi OP).
Shivan Dragon

4
Cảm ơn bạn đã cho lời khuyên :) và vâng, anh ấy thực sự gọi tôi là ngu ngốc (đôi khi điên rồ) bất cứ khi nào anh ấy thực sự tức giận về mã. Đó không phải là quá nhiều cái tôi của tôi nhận được trong cách chấp nhận câu trả lời của anh ấy mà là cách anh ấy cố gắng đẩy nó xuống cổ họng của tôi và tên anh ấy sử dụng cho tôi và mã của tôi, nhưng đó là một câu chuyện khác. Tuy nhiên, thật tốt khi biết rằng sách cung cấp cái nhìn sâu sắc :)
Quillion

6
@Quillion - Cá nhân tôi sẽ không gọi tên anh ấy. Có vẻ như bạn đang rất chán ngấy với mọi thứ. Tôi sẽ nghiêm túc xem xét việc nói chuyện với người quản lý của bạn về điều này, thậm chí có thể là nhân sự. Cuộc sống quá ngắn để có người lạm dụng.
webdad3

2
@Quillion - Không ai nên đối xử với bạn như vậy. Tôi không quan tâm họ là ai. Và luôn luôn nhớ rằng mọi người đều có thể thay thế. Tôi nghiêm túc xem xét việc nói chuyện với Infestus trước, sau đó đến người quản lý của bạn, sau đó là nhân sự. Nếu bạn không nhận được sự hài lòng thì hãy tiếp tục. Tin tôi đi, bạn sẽ tìm thấy một nhóm người tuyệt vời khác.
webdad3

1
Infestus đang có một phản ứng cảm xúc với những gì anh ta thấy là xấu xí sâu sắc. Anh ta có lẽ có thể hưởng lợi từ ai đó yêu cầu anh ta kiểm soát bản thân.
kevin cline

22

Đọc một cuốn sách không nên mù quáng: tác giả nên cố gắng thuyết phục bạn về những ưu điểm của cách tiếp cận của anh ấy / cô ấy khi anh ấy trình bày nó. Thật hợp lý khi đàn anh của bạn chỉ cho bạn một cuốn sách giải thích cách tiếp cận ưa thích của anh ấy, thay vì yêu cầu anh ấy tự giải thích: mặc dù anh ấy có thể giải thích lợi ích của sở thích của mình mà không cần dựa vào cuốn sách, đó cũng là một nỗ lực trùng lặp. tác giả của cuốn sách đã thực hiện.

Vì vậy, hãy đọc cuốn sách, xem tác giả của cuốn sách nói gì và nếu nó làm bạn bối rối, hoặc bạn muốn xác nhận sự hiểu biết của mình, hoặc bạn không đồng ý, sau đó nói chuyện với cấp trên của bạn về nó, nhưng bây giờ bạn sẽ có thể có một cuộc thảo luận hiệu quả hơn.


Tôi sẽ đồng ý. Nếu tác giả của một cuốn sách không thể giải thích giá trị của cách tiếp cận mà họ đang nói đến, làm thế nào một người đọc cuốn sách của tác giả sẽ có thể làm điều đó, vì vậy một trong hai điều phải là sự thật. điều đó tồn tại và người đọc chỉ đơn giản là không hiểu nó, hoặc một lời giải thích không tồn tại và người đọc nên cố gắng tìm một lời giải thích cho phương pháp đó. Vì chúng ta nói về một chủ đề cụ thể, một trong đó chỉ có một vài cách hợp lệ để thực hiện nó, một lời giải thích chắc chắn phải tồn tại. Nói cách khác, tôi đồng ý với câu trả lời của bạn.
Ramhound

17

Có ba yếu tố chính cho bất kỳ mối quan hệ lành mạnh. Giao tiếp, trung thực và tin tưởng. Điều đó được tính cho tất cả các mối quan hệ, thậm chí các mối quan hệ làm việc. Bạn nên nói chuyện với người giám sát của bạn về những mối quan tâm này.

Nếu bạn không hiểu lý do của anh ấy để ủng hộ một thiết kế nhất định, thì hãy nói với anh ấy điều đó . Nói với anh ấy rằng bạn chưa đọc cuốn sách và bạn muốn hiểu tại sao cách làm của anh ấy tốt hơn. Điều quan trọng là bạn nên cố gắng hiểu cách làm việc của anh ấy.

Tôi nghĩ bạn cũng nên đối xử với người này với sự tôn trọng hơn. Trong đầu bạn, bạn đang gọi anh ấy là những tên xúc phạm, và chỉ trích cách tiếp cận của anh ấy với những gì bạn nghĩ là "học tập". Coi chừng đó Mặt khác, bạn đã nói anh ấy gọi bạn là ngu ngốc. Điều đó không tuyệt, và bạn nên nói với anh ấy rằng không hay để gọi ai đó là ngu ngốc.

Ý tưởng có thể là ngu ngốc. Tất cả chúng ta đều phạm sai lầm và bỏ lỡ mọi thứ, ngay cả những người đàn anh. Khi có một lỗ hổng trong thiết kế, câu hỏi hay nhất là "Tại sao bạn làm theo cách này? Sẽ không bị hỏng trong tình huống X, Y, Z? Sẽ không thiết kế B tốt hơn?"

Hãy nhớ rằng bạn đang làm việc trên phần mềm này với những người khác. Đó là một kỹ năng khó để học. Không có vấn đề gì khi bạn không viết bất cứ điều gì từ đầu, luôn có chỗ để tỏa sáng bằng cách làm cho mã của bạn trở thành mã tốt nhất bạn có thể.

Và "tốt nhất" rất thường có nghĩa là dễ đọcdễ hiểu . Chúng tôi lập trình viên dành rất nhiều thời gian để đọc mã của người khác. Nếu mã đó rõ ràng và dễ đọc, thì điều đó làm cho mã thực sự có giá trị. Một trong những cách chúng ta học để viết mã tuyệt vời là đọc nhiều mã tốt. Bạn rất thường tìm thấy mã rất tốt trong sách. Vì vậy, đọc một hoặc hai cuốn sách lập trình tốt sẽ có khả năng giúp bạn trở thành một lập trình viên tốt hơn.


Tôi thực sự nghĩ về kỹ năng của anh ấy là tin kính và có sự tôn trọng. Tuy nhiên, những lời chỉ trích nặng nề trong bất cứ điều gì mới đang bắt đầu làm tôi thất vọng ngay cả khi thử những điều mới và dính vào những cuốn sách, và vâng, anh ấy rất thô tục.
Quillion 5/12/13

6
Mới không phải lúc nào cũng tốt, và cũ không phải lúc nào cũng xấu. Nếu anh ta chỉ trích một ý tưởng, yêu cầu biết tại sao. Luôn luôn hỏi tại sao. "Bởi vì cuốn sách nói như vậy" không đủ tốt. Mặt khác, khi đọc cuốn sách, anh ta rất có thể có một quan điểm rộng lớn hơn nhiều. Bạn cũng nên cố gắng mở rộng quan điểm của riêng mình, đến mức bạn có thể biện minh cho thiết kế của mình dựa trên giá trị riêng của nó.
Gustav Bertram

2
Đừng nghĩ về bất cứ ai là tin kính. Bạn không thể luôn luôn dựa vào anh ấy. Đối xử với anh ta như một đồng nghiệp có nhiều kinh nghiệm. Nếu bạn đối xử với anh ta như một vị thần, bạn đang bán rẻ bản thân và bạn sẽ không bao giờ được tôn trọng.
webdad3

7

Trong công ty nơi bạn làm việc, nó có thể là. Đây là những gì họ yêu cầu bạn làm.

Kỹ sư Infestus này thực hiện một công việc rất kém trong việc giáo dục các nhà phát triển cơ sở bằng cách nói với họ "điều này được viết trong cuốn sách và đó là lý do tại sao". Anh ấy không phải là một nhà thuyết giáo, anh ấy là một kỹ sư, và anh ấy có thể phá vỡ nó và trình bày các khái niệm để đàn em có thể học hỏi từ kinh nghiệm của anh ấy.

Tôi sẽ khuyến khích bạn nói chuyện với các nhà phát triển có kiến ​​thức trong công ty của bạn, hỏi họ những câu hỏi về ưu và nhược điểm của các kỹ thuật lập trình khác nhau, v.v ... Điều này cùng với việc đọc sách và blog (tôi muốn giới thiệu Joel trên Phần mềm - chỉ cần Google, đó là điều bắt buộc) sẽ cho bạn một sự hiểu biết tốt hơn.


4

IMHO, có 2 khía cạnh ở đây, mà bạn nên giải quyết riêng:

  • Thực tế là anh chàng là một thằng ngốc, gọi tên bạn và đơn giản là vì anh ta có thể (anh ta là đàn anh, nếu không, một trong hai bạn phàn nàn về người khác, anh ta sẽ nhận được lợi ích của sự nghi ngờ) chỉ đơn giản là hành vi như bắt nạt, và chỉ xấu.

Cố gắng không cúi xuống cấp độ của mình với điều này. Đừng cố bắt nạt anh ta trở lại hoặc "nói với anh ta" với ông chủ hoặc bất cứ điều gì. Làm hết sức để bỏ qua khía cạnh này trong hành vi của anh ấy, hãy nhớ rằng nó trở nên quá cực đoan (tức là nếu nó ảnh hưởng đến năng suất của bạn và như vậy), bạn nên làm gì đó về nó.

  • Thực tế là anh ấy nói với bạn rằng mã của bạn rất tệ (và làm thế nào để làm cho đúng). Thành thật từ những gì bạn mô tả, bỏ qua giọng điệu của anh chàng, khía cạnh hành vi của anh ta không phải là xấu. Bạn học mọi thứ nhanh hơn rất nhiều và nhận thấy chúng trong bối cảnh thích hợp khi bạn có ai đó có kinh nghiệm sửa lỗi cho bạn và nói với bạn không chỉ những gì bạn đã làm sai, mà còn làm thế nào để làm điều đó đúng (so với việc bạn tự học tất cả từ thử nghiệm cá nhân / thử nghiệm lỗi và tương tự).

Nhiều lần tôi đã có người sửa lại những gì tôi nghĩ ban đầu là "mã hoàn hảo của tôi" và tôi cảm thấy buồn vì anh chàng đang nói tôi phải làm gì để sau đó nhận ra rằng anh ta đã đúng, phiên bản của tôi rất tệ, phiên bản của anh ta rất tệ, tốt, và cảm ơn Chúa, ông đã thấy điều đó! :) Vì vậy, tôi đã học cách giảm bớt những thôi thúc ban đầu của mình về "này, bạn không nói cho tôi biết phải làm gì, mista!" và thay vào đó, mỗi lần ai đó sửa lỗi cho tôi, tôi thực sự, khách quan, kiểm tra lại mã của tôi, sau đó kiểm tra mã của anh ấy và đảm bảo rằng anh ấy không thực sự đúng và đó là tôi đang làm điều sai lầm. Nếu đó là lỗi của tôi, tôi cảm ơn anh ấy từ sự giúp đỡ, và chắc chắn rằng tôi thực sự hiểu cách giải pháp của anh ấy hoạt động (thay vì chỉ sao chép / dán nó vào).

Và này, đôi khi tôi thấy rằng sự điều chỉnh được cung cấp trên thực tế còn tệ hơn những gì tôi đã làm ban đầu, tại thời điểm đó tôi cố gắng nói tất cả những điều này với anh chàng kia. Thành thật mà nói, tôi nhận thấy rằng không có gì khiến người khác tôn trọng bạn nhanh hơn khi họ thấy rằng bạn có thể chấp nhận sửa lỗi khi bạn mắc lỗi, nhưng đồng thời, không ngại nói bạn là người duy nhất Ai đúng khi bạn nghĩ như vậy, cho rằng bạn có thể chứng minh ngay rằng bạn dựa trên sự khẳng định của mình trên một số nghiên cứu thực tế, và không chỉ là bản ngã.

Về điểm này, tôi nghĩ bạn nên thực sự cố gắng và nói chuyện với anh chàng về những gì anh ta đề xuất, và những gì bạn đề xuất và vv. Cho anh ấy thấy bạn nghĩ gì, làm thế nào bạn có được một giải pháp cụ thể và lý do tại sao bạn nghĩ nó tốt hơn anh ấy (khi bạn nghĩ một cách trung thực và khách quan). Hoặc, nếu bạn phát hiện ra rằng đề xuất của anh ấy tốt hơn đề xuất của bạn, hãy nói với anh ấy như vậy, bày tỏ sự đánh giá cao của bạn về sự giúp đỡ. Điều này có thể xây dựng lại một số cây cầu bị đốt cháy.


1
Tôi hoàn toàn đồng ý với bạn :) và tôi cố gắng phớt lờ giọng nói của anh ấy và luôn cố gắng coi thường tôi vì tôi đoán đó là tính cách của anh ấy. Nhưng điều khiến tôi bận tâm nhất là anh ấy sẽ nói với tôi mã của tôi là sai (điều đó không ổn tôi không bận tâm), và sau đó thay vì cố gắng giải thích cho tôi những cách sai anh ấy sẽ đưa cho tôi một cuốn sách và nói với tôi đọc nó trước khi tôi thử viết mã ngu ngốc nữa. Đó là điều khiến tôi đặt câu hỏi liệu các cuốn sách có tất cả các câu trả lời hay không, vì một nửa thời gian khi tôi đọc cuốn sách, nó không áp dụng hoàn hảo cho kịch bản trong tay.
Quillion

Vâng, vâng, tôi hiểu ý của bạn, nhưng tất cả những gì thực sự phụ thuộc vào cuốn sách và cách anh ấy giới thiệu nó. tức là nếu anh ta nói những điều như "bạn đã làm xấu, hãy đọc một số sách lập trình" điều đó rõ ràng là xấu, nhưng nếu anh ta nói "Hãy nhìn xem, phiên bản Java 2 hiệu quả sẽ cho một ví dụ đơn giản và tốt hơn về cách làm Singletons, hãy xem nó ở đây . safaribooksonline.com/book/programming/java/9780137150021/... ", sau đó tôi muốn nói đó là một điều hữu ích cho bạn (một lần nữa, bỏ qua một bên thảo luận về những giai điệu của giao hàng)
Shivan Rồng

Tôi sẽ không bao giờ "Bỏ qua" hành vi này. Sẽ có một cuộc trò chuyện với sếp của anh ta hoặc bỏ qua chỉ nói chuyện với sếp của anh ta nếu tôi đã nói với anh ta rằng tên gọi sẽ không bay.
Rig

3

Tự mình thử nghiệm và học tất cả những gì bạn có thể. Sau khi bạn đọc đủ sách, bạn sẽ phát hiện ra rằng có nhiều sách về các chủ đề cụ thể và chúng có thể mâu thuẫn với nhau. Hãy thử một trong những bạn nghĩ là tốt nhất và thử cả hai nếu bạn có thời gian hoặc muốn so sánh / tương phản.

Đối phó với sếp của bạn là một chủ đề và cách tiếp cận hoàn toàn khác. Nếu tôi muốn ai đó làm một cái gì đó theo cách chính xác trong một cuốn sách, tôi sẽ nói với họ. Đó chỉ là tôi bởi vì tôi không liên kết với độc giả tâm trí. Sếp của bạn biến điều này thành thói quen, chỉ cần hỏi xem anh ấy có giới thiệu bất kỳ cuốn sách hoặc tài liệu tham khảo nào khi bạn nhận được một dự án mới.

Dù bạn làm gì, đừng ngừng làm việc với các dự án mới. Tôi biết rằng tất cả chúng ta đều dễ dàng đưa ra lời khuyên về cách xử lý tình huống này và họ có thể hoặc không thể làm việc, nhưng bạn là người phải sống với nó và chịu đựng sự tiêu cực. Bạn sẽ trở nên tốt hơn, nhưng điều đó thường đến từ việc viết nhiều mã hơn về những điều mới, học hỏi từ những thành công và thất bại.


3

Theo dõi sách một cách mù quáng là một ý tưởng tồi, nhưng có một sự khác biệt giữa việc theo dõi một cuốn sách một cách chính xác và theo dõi nó một cách mù quáng .

Khi bạn đang cố gắng hiểu nội dung trong một cuốn sách, nói chung phù hợp để theo dõi chính xác vào lúc đầu, trong khi bạn đang cảm thấy những gì nó đang cố gắng dạy cho bạn. Điều lạ lùng là bạn vẫn sẽ không hiểu mọi thứ khi bạn hoàn thành - đó là cách mọi thứ như thế này thường diễn ra - nhưng việc theo dõi cuốn sách chính xác lúc đầu sẽ cho bạn một điều gì đó để thử nghiệm, khi bạn cố gắng hiểu câu hỏi của mình. Điều lạ lùng nữa là bạn sẽ tìm ra những cách mà bạn không đồng ý với những gì trong cuốn sách, nhưng bạn sẽ hiểu được những vấn đề mà cuốn sách đang cố gắng giải quyết, để đến lúc viết mã của riêng bạn, bạn có thể giải quyết chúng theo cách riêng của bạn (hoặc có thể theo cách của họ, ít nhất là một phần) thay vì chỉ để lại những vấn đề đó để cắn bạn sau này.

Một điều khác vốn không phải là đặc thù của Java, nhưng vẫn đặc biệt phổ biến trong cộng đồng đó. Tôi nghĩ rằng tôi có thể đoán những cuốn sách mà bạn đang nói đến và chúng là một phần chính của từ vựng của cộng đồng Java. Hiểu chúng và cách chúng mô tả mọi thứ, sẽ giúp ích rất nhiều khi bạn cần hiểu mã Java khác mà bạn tìm thấy. Đó là một kỹ năng có giá trị theo đúng nghĩa của nó.


3

Đọc sách và bài viết trên blog rất hữu ích trong lập trình. Có một số cuốn sách, mà tất cả các nhà phát triển nên đọc.

Tuy nhiên, sách không phải là nguồn duy nhất để tìm hiểu các khái niệm và công nghệ lập trình khác nhau. Ngày nay đào tạo dựa trên video theo yêu cầu đang trở nên rất phổ biến. Bạn có thể kiểm tra Pluralsight , nơi cung cấp đào tạo chất lượng cao cho các chuyên gia.

Trên thực tế, nếu bạn chỉ đọc những cuốn sách sẽ không giúp được gì. Bên cạnh việc đọc còn có những điều khác mà chúng ta cần phải làm là tốt. Bạn có thể tìm thêm chi tiết ở đây .


Đào tạo dựa trên video, đào tạo dựa trên lớp học, hoặc chỉ đọc tài liệu nguồn. Cuối cùng, tất cả họ đều chia sẻ một điều, bạn đọc (hoặc nghe) mã mới và nghe / đọc một lời giải thích về lý do phương pháp đó được thực hiện.
Ramhound

2

Bạn nên hỏi anh ta những gì đặc biệt là sai với phương pháp của bạn. Nếu anh ta không thể trả lời rõ ràng, bạn có thể khá chắc chắn rằng đó chỉ là một anh chàng bình thường thích cảm thấy vượt trội.


1
Kỹ năng của anh ấy và các chương trình anh ấy viết rõ ràng cho thấy sự vượt trội của anh ấy trong lập trình. Tuy nhiên, hầu hết lý do tại sao anh ta làm một cái gì đó cụ thể luôn được liên kết với sách của các tác giả nổi tiếng. Tuy nhiên tôi không quan tâm đến cảm giác của anh ấy đối với tôi, thay vào đó tôi muốn biết liệu sách có thực sự là cách tốt nhất để trở thành chương trình tốt hay không và liệu chúng có đáng tin như thể một người tôn giáo tin tưởng vào kinh thánh hay không.
Quillion 5/12/13

Bạn chắc chắn nên biết lý do tại sao chọn một cách tiếp cận hơn một cách tiếp cận khác. Đi đến một giải pháp khác hơn bạn đã tìm ra phải được chứng minh bằng lý do bạn hiểu. Nếu không, các kỹ năng (giống như cao cấp) của bạn sẽ không được tốt hơn. Bạn có thể lấy ý tưởng từ sách nhưng ý tưởng mới là điều quan trọng, không phải nơi nào hoặc do ai trình bày. Lập trình là không có tôn giáo :).
clime

1
Các bạn, và đừng quá sợ hãi anh ta. Nghe có vẻ như anh ta có thể là một lập trình viên rất giỏi nhưng không tốt bằng việc lãnh đạo và dạy người.
clime

@Quillion - Cách duy nhất để trở thành một lập trình viên giỏi là làm rất nhiều, bằng cách đọc sách (hoặc bất kỳ nguồn nào khác), bạn có thể bổ sung thực sự viết mã bằng cách đọc. Bạn thậm chí đã đọc cuốn sách trong câu hỏi? Bạn phải quyết định xem tác giả của mã có đáng nghe hay không, một tác giả tuyên bố đã có 20 năm ở Java, là một người tốt để lắng nghe. Điều đó có nghĩa là có một cơ hội tốt, anh ấy đã nói chuyện với các nhà phát triển Java thực tế, về một số chủ đề nhất định. Nếu tôi đang viết một cuốn sách về Java, tôi sẽ đi đến nguồn cho nghiên cứu của mình và sử dụng kinh nghiệm của mình để giải thích chủ đề này.
Ramhound

@Ramhound vâng tôi phải đọc những cuốn sách anh ấy tặng tôi. Và vâng, tôi đồng ý với những cuốn sách của ông về những chủ đề nhất định. Tuy nhiên, vấn đề tôi tìm thấy với những cuốn sách mà anh ấy đề xuất là chúng mô tả một thế giới hoàn hảo, nơi tất cả các mã được thực hiện đúng, và nửa còn lại họ cảm thấy hơi lỗi thời. Nhưng việc anh ấy thường xuyên gửi thư rác cho tôi để đọc và bảo vệ tất cả những tranh luận của anh ấy với những cuốn sách hơn là cố gắng giải thích cho tôi, khiến tôi nghĩ rằng có lẽ sách không phải là nguồn tốt nhất. Tuy nhiên có vẻ như chúng là như vậy, và tôi sẽ nghiên cứu thêm về chúng.
Quillion

2

Điều về sách là chúng - chủ yếu - thông qua các phiên bản, có cơ hội tốt hơn để phát hiện ra các thực tiễn và quan niệm sai lầm. Ngoài ra, "những tên tuổi lớn" là những người có kinh nghiệm, dựa vào việc giỏi để kiếm thêm tiền bán sách, do đó, có một số đảm bảo chất lượng tối thiểu về những gì họ nói.

Điều đó nói rằng, đọc sách, giấy tờ và các nguồn khác là một cách tốt để phát triển như một chuyên gia, tất nhiên, khi được xác nhận bằng thực tiễn. Vì vậy, thật tốt khi bạn đọc những cuốn sách đó (ngay cả những cuốn sách được Infestus khuyên dùng). Tuy nhiên, các cuốn sách chủ yếu phải mở rộng sự hiểu biết của bạn về chủ đề này, vì hầu như sẽ luôn có những cách khác để giải quyết vấn đề tương tự.

Về cách tiếp cận "đi một mình" của bạn, vấn đề là: bạn có thể duy trì quan điểm của mình không? Làm thế nào để bạn chứng minh giải pháp của bạn là tốt hơn so với bất kỳ khác? Đôi khi bạn có thể tự mình nghĩ ra các giải pháp sáng sủa, nhưng, khi so sánh với các giải pháp đã biết khác, bạn phải có khả năng tranh luận lý do tại sao các giải pháp của bạn tốt hơn, vì các trường hợp khác có lợi cho họ, ít nhất là các trường hợp sử dụng. Sau đó, hãy sáng tạo và chu đáo, nhưng quan trọng nhất là có hiệu quả.

Nếu tôi là, bạn sẽ đọc những cuốn sách đó. Điều đó sẽ giúp bạn bằng cách cung cấp cho bạn nhiều tranh luận hơn, đồng thời, bạn có thể thấy rằng Infestus - có thể - đang lấy nhầm những cuốn sách đó làm đối số, và anh ta chưa phát hiện ra vì không ai biết nội dung của những cuốn sách đó. Hoặc bạn có thể thấy rằng anh ấy thực sự k


1

Kinh nghiệm của tôi là khi quan tâm đến vấn đề lập trình, chất lượng và cách trình bày thông tin với lời giải thích đầy đủ trong sách sẽ tốt hơn rất nhiều khi tìm kiếm thông tin cùng chủ đề trên internet. Internet thường thiếu giải thích thích hợp, bối cảnh và chất lượng.

Số lượng thông tin nói trên internet cao hơn.

Vì vậy, chiến lược chung của tôi là học từ sách để hiểu sâu hơn và sau đó học từ internet để tiếp xúc với những hàm ý khác nhau và mở rộng kinh nghiệm của tôi. (Và thường thấy cách không làm công cụ).


1

Tôi sẽ nghiên cứu giá trị của từng phương pháp và đưa ra đánh giá của riêng bạn. Nếu bạn nghĩ rằng cách tiếp cận của bạn tốt hơn, hãy thảo luận với Infestus cho đến khi một trong hai bạn thuyết phục người kia. Nếu bạn không thể đạt được thỏa thuận, bạn có thể hỏi ý kiến ​​thứ hai hoặc chỉ chấp nhận cách tiếp cận của Infestus, tùy thuộc vào mức độ bạn cảm nhận về điều đó.

Trong trường hợp của singletons, một lập luận bạn có thể đưa ra đối với cách tiếp cận enum là enum không thể mở rộng các lớp. Tôi thường viết mã như thế này:

public class DateSerializer extends AbstractSerializer<Date> {
  public static final DateSerializer SINGLETON = new DateSerializer();

  private DateSerializer() {}

  public byte[] serialize(Date date) { ... }
}

Điều này không thể được thực hiện với enums. Vì cách tiếp cận enum không hoạt động trong mọi trường hợp, bạn có thể lập luận rằng vì mục đích nhất quán, nên tránh ngay cả khi không cần một extendsđiều khoản.

Một số đối số khác có thể được đưa ra chống lại việc sử dụng enums:

  • đó là một hack - nó đang sử dụng enum cho một cái gì đó mà họ không có ý định
  • thật khó hiểu với những độc giả chưa từng thấy nó trước đây

Umm ... tại sao bạn lại triển khai serializer ngày như một singleton? Nếu nó không trạng thái, bạn sẽ mong muốn nó rẻ để khởi tạo và việc có nhiều trường hợp không phải là mối quan tâm chính. Nếu nó không phải là không quốc tịch, thì bạn phải làm cho nó được đồng bộ hóa và có khả năng nó sẽ trở thành nút cổ chai ...
Stephen C

@StephenC đối với các lớp không trạng thái, có vẻ lạ khi cho phép nhiều trường hợp khi một trường hợp đủ, và lợi thế là gì? Một singleton trạng thái xuất hiện trong tâm trí là một trình phân tích cú pháp packrat - bạn có thể có một vài lớp singleton mở rộng một AbstractParser. Đúng, nó yêu cầu đồng bộ hóa nếu bạn phân tích song song, nhưng chia sẻ trạng thái ghi nhớ là quan trọng.
Daniel Lubarov

Ngược lại, có vẻ lạ đối với tôi rằng bạn sẽ bận tâm với những người độc thân và sự phức tạp nảy sinh từ họ nếu bạn không cần. Theo tôi, cách tiếp cận đơn giản nhất là tạo, sử dụng và vứt bỏ các vật thể "biến thế" ... trừ khi có lý do / động cơ mạnh mẽ để tái sử dụng chúng.
Stephen C

1

Tôi chủ yếu dựa vào sách như một nguồn kiến ​​thức - đây là những nền tảng tuyệt vời và tôi nghĩ Infestus nói đúng rằng bạn nên tiêu thụ số lượng sách đáng kể trong thời gian rảnh rỗi vì chúng thực sự tăng tốc các kỹ năng của bạn. Sách không phải là nguồn thông tin duy nhất mà tôi nghĩ bạn nên tiêu thụ - tham dự nhóm người dùng địa phương của bạn, nhận các bản tin công nghệ có liên quan đến hộp thư đến của bạn, đọc blog.

Tuy nhiên, tôi không đồng ý với khẳng định rằng vì nó được viết theo một cách nhất định trong một cuốn sách, đó là cách nó phải được thực hiện. Có những cuốn sách cung cấp lời khuyên tuyệt vời, và chúng được viết bởi các chuyên gia, và được các chuyên gia đánh giá, nhưng đã tham gia vào một cuốn sách tương đối đơn giản, tôi có thể nói với bạn rằng phải mất ít nhất hai năm để bắt đầu viết, chỉnh sửa và phát hành một cuốn sách . Tốc độ thay đổi trong công nghệ là nhanh chóng và lời khuyên của hai năm trước có thể không còn là lời khuyên chính xác cho ngày hôm nay. Hiệu trưởng chung thường đứng trước thử thách của thời gian, nhưng tối ưu hóa một hoạt động cụ thể có thể bị vô hiệu với một phần cứng mới hoặc bản phát hành phần mềm mới.

Gợi ý yêu cầu Infestus chuyển qua các đề xuất với bạn là một cách tuyệt vời - bỏ đi, đọc mọi thứ và quay lại với một loạt các câu hỏi chu đáo mà bạn đã cố gắng trả lời / giải quyết cho chính mình cùng với bằng chứng hỗ trợ cho bạn phương pháp.

Có những câu hỏi về việc sau 5 năm tại sao bạn vẫn còn là một thiếu niên. Đối với tôi, thước đo quan trọng của việc một người nào đó là một thiếu niên không phải là nhiều năm kinh nghiệm mà là họ cần bao nhiêu cho ăn bằng thìa. Tôi hy vọng một nhà phát triển cấp trung sẽ tương đối tự túc, một người tiêu dùng chu đáo về các nguồn tri thức có thể hành động và mở rộng nó đến tình huống của họ. Họ cũng nên ở giai đoạn mà họ có thể bắt đầu dạy đàn em vì họ có hiểu biết vững chắc về chủ đề của họ để họ có thể giải thích mọi thứ rõ ràng. Năng lực cốt lõi khác là sự tự tin - nếu bạn đã hoàn thành công việc, đọc nội dung và sản xuất một thứ gì đó đàng hoàng, đừng ngại đứng lên tranh luận vì một thiếu niên cần có sự xác nhận, nhà phát triển yêu cầu sự đồng thuận.


1

Gác lại cách cư xử nơi làm việc, gạt sang một bên thực tế về vai trò cố vấn mà các nhà phát triển cấp cao có, gác lại mong muốn khám phá của bạn, gạt sang một bên hành vi xúc phạm và gạt sang một bên những cuốn sách ...

Mục đích của việc xem xét mã trong một nhóm là 1) để xác thực mã và 2) để đảm bảo người viết mã hiểu được ý nghĩa của việc cải tiến mã. Đây không phải là nơi để nói "thay đổi điều này vì Martin Fowler đã nói như vậy trong cuốn sách của GoF". Tuy nhiên, đây là nơi để nói "thay đổi điều này vì [giải thích ngắn gọn]; có nhiều chi tiết hơn về thảo luận này trong cuốn sách của GoF".

Nếu nhà phát triển cấp cao của bạn không, ít nhất là đơn giản và tinh tế, đưa ra lời giải thích cho một sự thay đổi và khăng khăng sử dụng lời nói "vì [cuốn sách]", thì anh ta là một kẻ thông minh và một kẻ ngốc. Làm thế nào để bạn đối phó với nó? Đề cập đến nó trong một cuộc họp nhóm, bằng lời nói và yêu cầu các đồng đội của bạn cung cấp một hoặc hai lời giải thích ngắn gọn về lợi thế hoặc sự cần thiết của sự thay đổi, cùng với tài liệu tham khảo cuốn sách hữu ích đó. Hãy chắc chắn để cảm ơn ông đã tham khảo cuốn sách.

Đối mặt với nó, mục tiêu của bạn là đánh giá cao đề xuất thay đổi và không bị mất điều kiện cho nhiệm vụ hoặc công việc của bạn. Nói anh ta rằng. "Tôi sẽ đánh giá cao đề xuất thay đổi nhiều hơn nếu bạn có thể mô tả ngắn gọn về lợi thế hoặc sự cần thiết của thay đổi khi bạn xem lại mã của mình; vì tôi đang tìm các tài liệu tham khảo sách của mình một mình để giải thích một chút."

Nếu anh ta tiếp tục từ chối cung cấp một lời giải thích đơn giản với các tài liệu tham khảo sách của mình, nếu bạn có thể cung cấp một cuốn sách hoặc tài nguyên khác có tiếng tăm tương đương hoặc lớn hơn trong ngành với một ý kiến ​​khác và nó phù hợp với kịch bản của bạn, bạn có thể thêm sách của riêng mình tham khảo trong nhận xét đánh giá của bạn trong việc xem xét giữ lại mã gốc. Làm điều này đủ lần, anh ta có thể lùi lại. Hãy rất cẩn thận rằng các đối số là đúng và quan trọng hơn đáng kể; Không sao để nhà phát triển cấp cao sai mà vẫn có cách của anh ta, đây là điều tôi đã học và tiếp tục phải học.


1

Tôi muốn nói rằng chỉ học lập trình từ sách là không thể, nhưng chúng tốt sẽ mang lại cho bạn một sự thúc đẩy to lớn. Nó giống như karate - bạn sẽ không nhận được đai đen khi chỉ đọc về nó;) Tôi tin rằng trong trường hợp này, ông Infestus đã đề cập đến "Java hiệu quả" của Joshua Bloch. Đây thực sự là một cuốn sách tuyệt vời về phát triển Java và bạn chắc chắn nên đọc nó nếu bạn chưa có.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.