Tôi có nên tiếp tục thực hành mã hóa tự học hay học cách làm mã hóa một cách chuyên nghiệp? [đóng cửa]


36

Gần đây tôi đã có được công việc chuyên nghiệp, đi chơi với các lập trình viên khác và kết bạn trong ngành. Điều duy nhất là tôi tự học 100%. Điều đó khiến phong cách của tôi cực kỳ sai lệch so với phong cách của những người được đào tạo bài bản. Đó là các kỹ thuật và cách tổ chức mã của tôi khác nhau.

Đó là một hỗn hợp của một số điều tôi làm. Tôi có xu hướng pha trộn một số mô hình lập trình với nhau. Giống như chức năng và OO. Tôi nghiêng về phía Chức năng nhiều hơn OO, nhưng tôi thấy việc sử dụng OO khi một cái gì đó có ý nghĩa hơn như một thực thể trừu tượng. Giống như một đối tượng trò chơi. Tiếp theo tôi cũng đi con đường đơn giản khi làm việc gì đó. Ngược lại, có vẻ như đôi khi mã tôi thấy từ các lập trình viên chuyên nghiệp rất phức tạp vì lợi ích của nó! Tôi sử dụng rất nhiều đóng cửa. Và cuối cùng, tôi không phải là người bình luận tốt nhất. Tôi thấy việc đọc qua mã của tôi dễ dàng hơn đọc bình luận. Và hầu hết các trường hợp tôi chỉ đọc mã ngay cả khi có ý kiến. Thêm vào đó, tôi được cho biết rằng, vì đơn giản là tôi viết mã của mình, rất dễ đọc nó.

Tôi nghe các lập trình viên được đào tạo chuyên nghiệp tiếp tục và về những thứ như bài kiểm tra đơn vị. Một cái gì đó tôi chưa bao giờ sử dụng trước đây vì vậy tôi thậm chí không có ý tưởng mờ nhạt nhất về những gì họ đang làm hoặc cách họ làm việc. Rất nhiều và rất nhiều dấu gạch dưới "_", đó không thực sự là sở thích của tôi. Hầu hết các kỹ thuật tôi sử dụng là trực tiếp từ tôi hoặc một vài cuốn sách tôi đã đọc. Không biết gì về MVC, tôi đã nghe rất nhiều về nó mặc dù với những thứ như backbone.js. Tôi nghĩ đó là một cách để tổ chức một ứng dụng. Nó chỉ làm tôi bối rối bởi vì bây giờ tôi đã tạo ra cấu trúc tổ chức của riêng mình.

Đó là một chút đau đớn. Tôi hoàn toàn không thể sử dụng các ứng dụng mẫu khi học một cái gì đó mới như với Ubuntu một cách nhanh chóng. Tôi gặp khó khăn khi hiểu mã mà tôi có thể nói là từ một người được đào tạo. Hoàn thành lập trình OO thực sự để lại một hương vị xấu trong miệng của tôi, nhưng đó dường như là điều mà MỌI NGƯỜI khác đang sử dụng nghiêm ngặt.

Điều đó khiến tôi không tự tin vào vẻ ngoài của mã của mình hoặc tự hỏi liệu tôi có gây ra tia lửa khi tham gia một công ty hay có thể đóng góp cho các dự án nguồn mở hay không. Trong thực tế, tôi khá sợ thực tế là mọi người cuối cùng sẽ kiểm tra mã của tôi. Đây có phải là điều bình thường mà bất kỳ lập trình viên nào cũng trải qua hay tôi thực sự nên tìm cách thay đổi kỹ thuật của mình?


2
Không ai trở thành một nhà phát triển vững chắc trong một tuần / tháng. Phải mất thời gian để biết cách phân phối mã theo phong cách đáng tin cậy và có thể bảo trì. Chắc chắn bạn sẽ trở thành một "nhà phát triển ngôi sao nhạc rock", nếu bạn giữ được giai đoạn học hỏi và tò mò về cách làm mọi thứ tốt hơn!
EL Yusubov

11
Bạn nên lưu ý rằng phần mềm sản xuất có xu hướng tồn tại lâu hơn tác giả ban đầu của nó - có thể viết mã mà người khác có thể hiểu để duy trì là một kỹ năng rất quan trọng. Khuyến khích người khác đọc mã của bạn và cho bạn biết họ nghĩ gì và học hỏi từ nó.

1
"cực kỳ sai lệch so với phong cách của những người được đào tạo bài bản" nơi này ở đâu trên trái đất? Chưa bao giờ tôi tìm thấy một học sinh được đào tạo bài bản.
Phản ứng

2
Tôi sẽ rất vui khi được làm việc với nhiều người hiểu hơn về việc đóng cửa, chứ đừng nói đến việc suy nghĩ về việc sử dụng lập trình chức năng ...
Izkata

Miễn là bạn cho các lập trình viên / nhà tuyển dụng khác biết lý lịch của bạn, bạn sẽ ổn thôi. Có một sự khác biệt giữa việc tự học và không mã hóa như một người được đào tạo tốt, và được đào tạo và không mã hóa như những người khác được đào tạo tương tự.
Pureferret

Câu trả lời:


62

Trong thực tế, tôi khá sợ thực tế là mọi người cuối cùng sẽ kiểm tra mã của tôi.

Tốt Ý thức được rằng mọi người sẽ xem mã của bạn sẽ khiến bạn cố gắng hơn.

Lập trình đã trở thành một lĩnh vực vô cùng lớn. Có hàng tá chủ đề, công cụ, hốc và chuyên môn, một số trong đó là toàn bộ sự nghiệp cho chính họ. Có rất nhiều thứ để học và biết, và khi bạn làm việc với các lập trình viên khác, sẽ luôn có những thứ bạn biết rằng họ không và những thứ họ biết rằng bạn không biết. Đây là một điều tốt.

Nếu bạn lo lắng rằng kinh nghiệm của bạn không đầy đủ, có rất nhiều bước bạn có thể thực hiện để sửa đổi điều đó thông qua giáo dục chính thức và hợp tác với các chuyên gia được đào tạo. Nhưng có vẻ như bạn sợ có một số mốc có thể định lượng được sau đó mọi người nói "Được rồi, bây giờ tôi đã thành thạo điều đó, tôi chính thức là một lập trình viên." Không có cột mốc nào như vậy. Tôi chắc chắn đã có những khoảnh khắc mà tôi nghĩ "ừ, giờ tôi đang ở đâu đó" sau khi tôi học được điều gì đó mới, nhưng không có danh sách kỳ diệu nào về những điều bạn phải biết và làm để tự gọi mình là lập trình viên.

Tôi biết rất nhiều điều về lập trình, tôi đã sử dụng hàng tá ngôn ngữ trong rất nhiều dự án, và tập hợp kiến ​​thức lập trình mà tôi có thể gọi là của riêng tôi là rất nhỏ. Và tôi thích điều đó. Thành thật mà nói, một lập trình viên không phải là một cái gì đó bạn là. Một lập trình viên là một cái gì đó bạn không ngừng học hỏi để trở thành.

Hãy kiểm kê trung thực các kỹ năng, điểm mạnh và điểm yếu của bạn. Nhận phản hồi từ những người có nhiều kinh nghiệm hơn bạn. Tìm kiếm các vị trí phù hợp với vị trí bạn nghĩ - nhưng đừng ngại đi tìm những công việc nằm ngoài khả năng làm chủ hiện tại của bạn. Nếu bạn chỉ nhận những công việc bạn đã biết mọi thứ, bạn sẽ không bao giờ học được ở nơi làm việc.


44
Một lập trình viên là một cái gì đó bạn không ngừng học hỏi để trở thành . Tôi có nên dịch cái này sang tiếng Trung Quốc và tạo ra một hình xăm của nó không?
Radu Murzea

1
@SoboLAN Tôi cho phép bạn làm điều này. Tôi muốn hình ảnh, mặc dù!
asfallows

2
codereview.stackexchange.com là trang web duy nhất tôi biết trực tiếp, mặc dù tôi chắc chắn có những trang khác. Mặc dù vậy, có rất nhiều giá trị khi có ai đó xem xét cá nhân và nói chuyện với họ từng người một. Có lẽ có một trường đại học / cao đẳng gần bạn với một giáo sư thân thiện, người sẵn sàng gặp bạn? Đó là điều tốt nhất tôi có thể nghĩ ra tại chỗ - có thể những người khác sẽ có ý tưởng tốt hơn.
asfallows

1
Theo tôi, thử nghiệm thực sự là nếu bạn đã gửi mã mà người khác thực sự sử dụng.

4
@ ThorbjørnRavnAndersen: và lần đầu tiên bạn nhận ra rằng mọi người thực sự đang sử dụng những gì bạn sản xuất có thể rất đáng sợ lúc đầu. Và rất có quyền sau đó. Và sau đó đáng sợ một lần nữa, khi bạn thấy rằng lỗi lớn mà bạn đã gây ra ;-)
Joachim Sauer

16

Khi bạn bắt đầu phát triển các ứng dụng hợp tác với các nhà phát triển khác, một số trong những phong cách cá nhân này sẽ gây cản trở.

Nếu bạn bắt đầu làm việc tại một cửa hàng sử dụng dấu gạch dưới, bạn sẽ sử dụng dấu gạch dưới. Mọi người, bất kể nền tảng trước đây của họ, tuân theo tiêu chuẩn cửa hàng cho phong cách mã hóa.

Trừ khi phong cách mã hóa của bạn cực kỳ rõ ràng, tốt hơn là bạn nên làm quen với việc viết các bình luận rõ ràng, súc tích giải thích cách mã của bạn hoạt động, để các nhà phát triển khác có thể theo dõi nó.

Nếu bạn không biết gì về bài kiểm tra đơn vị, hãy mua một cuốn sách hay. Có rất nhiều sách hay về thử nghiệm đơn vị ngoài kia. Tương tự với MVC.

Các nhà phát triển phần mềm chuyên nghiệp biết cách chơi tốt với những người khác mà không vứt rác vào hộp cát. Những người giỏi nhất biết cách đọc và viết mã bất kể phong cách.


5

Lập trình có một thành phần nghệ thuật và một thành phần kỷ luật với nó. Thành phần nghệ thuật là trong việc nghĩ ra các phương pháp tốt nhất và thực hiện chúng; kỷ luật là đảm bảo rằng bạn đã làm đúng và những người khác có thể hiểu mã của bạn và nâng cao nó khi cần thiết.

Thành phần nghệ thuật rất thú vị: bạn làm điều đó bởi vì bạn thích nó. Đương nhiên, đó là phần mà bạn tự dạy mình trước.

Thành phần kỷ luật có nhiều phiền toái: bạn làm điều đó không cần thiết. Đó là một thành phần quan trọng của việc làm việc trong một nhóm, mặc dù: bạn không thể tránh khỏi việc đó, ít nhất là ở một mức độ nào đó. Khi mã của bạn được tích hợp với mã của các đồng đội của bạn, tính linh hoạt của bạn để "thay đổi mọi thứ theo ý muốn" sẽ khiến mũi lao xuống. Tuy nhiên, bạn cần có khả năng thay đổi mã của mình một cách tự tin để đáp ứng các yêu cầu thay đổi hoặc giải quyết các lỗi. Đây là nơi có nhiều bài kiểm tra "nhàm chán" khác nhau: với rất nhiều bài kiểm tra được thực hiện, thật dễ dàng để kiểm tra xem sự thay đổi mới nhất của bạn có phá vỡ mọi thứ hay không.

Kiểu mã cũng đạt được tầm quan trọng, bởi vì việc tuân thủ một kiểu chung giúp mã dễ đọc hơn cho mọi người. Trong các công ty lớn hơn, bạn sẽ tìm thấy các công việc hàng đêm kiểm tra việc tuân thủ các tiêu chuẩn mã hóa một cách tự động và gửi e-mail cho bạn những cảnh báo khó chịu khi bạn đi chệch hướng.

Quay lại câu hỏi của bạn, tập trung vào thành phần nghệ thuật là giai đoạn đầu phát triển tự nhiên của lập trình viên. Có thể mất vài năm làm việc trong ngành trước khi bạn bắt đầu đánh giá cao thành phần kỷ luật. Mặc dù vậy, bạn không cần chủ động tìm cách "thay đổi kỹ thuật của mình": họ sẽ biến hình một cách tự nhiên trong quá trình làm việc trong một nhóm.


3

Đối với câu hỏi của bạn, bạn nên luôn luôn tìm cách thay đổi kỹ thuật của mình, để nắm lấy dự án độc đáo và công nghệ mới nổi.

@ khẳng định quan điểm của "Thành thật mà nói, một lập trình viên không phải là bạn. Một lập trình viên là thứ bạn không ngừng học hỏi." thực sự là tất cả và kết thúc tất cả mã hóa.

Thật tuyệt khi bạn nhận thấy các khu vực nơi bạn làm điều gì đó khác biệt với những người khác, đặc biệt là khi bạn thấy đó là một tiêu chuẩn. Bạn đã phát hiện ra Thử nghiệm đơn vị và MVC - và bây giờ bước tiếp theo của bạn phải là tìm hiểu về chúng. Xem cách chúng hoạt động, những gì bạn cần để thực hiện chúng và thử và nhận biết khi nào đó là một thiết kế tốt để thực hiện chúng.

Đây là một lĩnh vực không ngừng phát triển với các ngôn ngữ và mô hình mới tăng giảm. Nếu bạn cảm thấy thoải mái với khía cạnh mã hóa, hãy bắt đầu kiểm tra phần thiết kế. Tìm hiểu những gì làm cho chúng tốt và khi sử dụng chúng.

Chắc chắn tham gia vào một nhóm là một lợi ích tuyệt vời - bạn luôn cần những con mắt khác để xem mã của bạn để phát hiện ra những khu vực bạn vội vã hoặc không nghĩ ra ý nghĩa đầy đủ.


2

Bạn không cần phải là một nhà bình luận lớn hơn. Nhưng bạn nên là một người đi làm tốt (vâng, bắt đầu sử dụng một số loại VCS - tôi khuyên dùng Git).

Phong cách là một thứ mà LUÔN LUÔN phát triển. Đừng lo lắng về nó. Bạn sẽ tìm hiểu mã nào có thể tái sử dụng và mã nào không. Nhưng bạn phải thực hành và để được giúp đỡ cho nó.

Hãy thử giúp đỡ trong một số dự án Nguồn mở trên Github. Một số người thực sự tốt ở đó, và sẽ cố gắng giúp bạn. Đây là lời khuyên tốt nhất tôi có thể cung cấp cho bạn.


2

Trong thực tế, tôi khá sợ thực tế là mọi người cuối cùng sẽ kiểm tra mã của tôi. Đây có phải là điều bình thường mà bất kỳ lập trình viên nào cũng trải qua hay tôi thực sự nên tìm cách thay đổi kỹ thuật của mình?

Làm thế nào bạn biết những gì để thay đổi mà không có một số phản hồi từ các lập trình viên giàu kinh nghiệm hơn?

Việc người khác xem xét công việc của bạn có thể gây khó khăn, đặc biệt là một vài lần đầu tiên, nhưng đó là cách tốt nhất để nhận được những lời chỉ trích mang tính xây dựng mà bạn cần để cải thiện kỹ năng của mình. Có một trang SE để đánh giá mã mà bạn có thể thấy hữu ích. Yêu cầu bạn bè thông minh xem mã của bạn là một cách tốt khác để nhận được một số phản hồi.


2

Điều quan trọng nhất là phát triển tính linh hoạt. Bạn càng quen thuộc với các khái niệm cơ bản, bạn càng có thể phản ứng nhanh hơn trong bất kỳ ngôn ngữ, phương pháp lập trình, phong cách hoặc môi trường nào.

Làm chủ ít hơn là học mọi thứ / mọi thứ / có để học, và nhiều hơn về việc học / cách / để giải quyết vấn đề, trong nhiều tình huống khác nhau.

Và đơn thuốc tốt nhất cho điều đó là thực hành. Bạn nên luôn luôn có một dự án; nếu bạn đang ở giữa các hợp đồng biểu diễn được trả tiền, hãy lấy một món đồ chơi cá nhân. Thời gian rảnh rỗi một ngày cuối tuần? Làm việc thông qua 'thế giới xin chào' cho một ngôn ngữ hoặc nền tảng mà bạn chưa từng sử dụng trước đây. Tìm cách để học được nhiều thứ cùng một lúc. Ví dụ: xây dựng một cái gì đó trong Google App Engine và bạn sẽ tìm hiểu tất cả cùng một lúc về cơ sở dữ liệu Python, BigTable và hướng cột. Bạn cũng sẽ nhận được một lượng tốt phong cách Google "chuyên nghiệp".

Một vị tướng giỏi biết cách áp dụng chiến thuật đã học và thu thập kinh nghiệm trong nhiều địa hình khác nhau. Nghe có vẻ như bạn có một số chiến thuật và kinh nghiệm, nhưng bạn cần phải gặp một số địa hình xa lạ. Đó có lẽ là cách tốt nhất để xác định những gì bạn biết và những gì bạn cần học tiếp theo.

Và nếu phong cách "chuyên nghiệp" là những gì bạn đang theo đuổi, hãy tham gia một số dự án "chuyên nghiệp". Tìm một dự án nguồn mở mà bạn thích, chỉ định cho mình một thay đổi để thực hiện và thiết lập về nó. Hãy chuẩn bị cho những người đánh giá jackass, nhưng hãy nhớ rằng phần lớn những người trong lĩnh vực này đã không đến được nơi họ có kỹ năng xã hội trơn tru. Vấn đề là phơi bày bản thân với càng nhiều thứ bạn muốn càng tốt. Và bạn phải xây dựng bản thân đủ tốt để tự làm điều đó. Không có lớp học thực sự có thể dạy bạn. Trên thực tế, ngày nay có quá nhiều việc học tập trên lớp đang diễn ra và không đủ năng lực thực tế vững chắc.


Cảm ơn Johnny đã đưa ra câu trả lời được đăng đầu tiên của bạn và chào mừng bạn đến với nhóm lập trình viên trên Stack Exchange. Vui lòng kiểm tra ra những hướng dẫn hữu ích cho các câu hỏi và câu trả lời trên các trang web Ngăn xếp giá: programmers.stackexchange.com/questions/how-to-answer - DeveloperDon
DeveloperDon

1

Điều đó khiến tôi không tự tin vào vẻ ngoài của mã của mình hoặc tự hỏi liệu tôi có gây ra tia lửa khi tham gia một công ty hay có thể đóng góp cho các dự án nguồn mở hay không. Trong thực tế, tôi khá sợ thực tế là mọi người cuối cùng sẽ kiểm tra mã của tôi. Đây có phải là điều bình thường mà bất kỳ lập trình viên nào cũng trải qua hay tôi thực sự nên tìm cách thay đổi kỹ thuật của mình?

Theo tôi, không cần phải lo lắng về những gì người khác nghĩ về mã của bạn nếu bạn tập trung vào các thước đo khách quan về chất lượng của nó. Là nó

  • Chính xác?
  • Có thể hiểu được?
  • Duy trì?
  • Hiệu quả?

Theo nguyên tắc đầu tiên, mục tiêu của bạn là luôn luôn tập trung vào các phẩm chất khách quan hơn là ý kiến ​​của người khác. Tập trung vào ý kiến ​​của người khác là con đường dẫn đến sự tầm thường, và, như bạn đang trải qua, lo lắng.

Lý do duy nhất để quan tâm đến ý kiến ​​của người khác là có thể hòa nhập tốt với xã hội (hoặc trong môi trường làm việc) với họ. Nếu bạn luôn đi đầu trong mục tiêu cải thiện phẩm chất khách quan của công việc, thì bạn không cần phải cảm thấy sợ hãi về phản ứng của người khác - chúng chỉ là cơ hội để tìm hiểu hoặc, ở những chi tiết thực tế, tồi tệ nhất để đối phó .

Hãy thành thật với chính mình !! Tiếp tục học hỏi và tận hưởng những gì bạn làm.


Cảm ơn Chris đã đưa ra câu trả lời được đăng đầu tiên của bạn và chào mừng bạn đến với nhóm lập trình viên trên Stack Exchange. Tôi rất tôn trọng dòng suy nghĩ của bạn. "Những gì mọi người nói bạn không thể làm, bạn hãy thử và thấy rằng bạn có thể." Henry David Thoreau. Vui lòng kiểm tra các hướng dẫn hữu ích này cho các câu hỏi và câu trả lời trên các trang web Stack Exchange: lập trình
DeveloperDon

1

Bạn nhắc tôi nhớ về bản thân mình sau khi học đại học để trở thành Kỹ sư phần mềm. Nếu bạn muốn trở thành một lập trình viên, tôi sẽ nói hãy đảm nhận một vị trí. Bạn sẽ cần phải nhận xét mã của bạn, viết các bài kiểm tra đơn vị, hiểu, đầy đủ, mã hướng đối tượng. Nhưng ngay bây giờ bạn không có lý do thực sự để làm như vậy. Miễn là bạn chỉ làm việc trên các dự án nhỏ cá nhân. Nơi mà bạn không phải trả lời cho bất kỳ ai trừ chính bạn. Bạn sẽ không phát triển hơn nữa như là một nhà phát triển.

Bằng cách tham gia vào các dự án lớn mà nhiều người đang thực hiện và phải trả lời các câu hỏi quản lý như "Bản phát hành này có miễn phí không? Bởi vì chúng tôi sẽ phát hành nó cho khách hàng." Bạn sẽ phát triển như một lập trình viên / kỹ sư. Bạn sẽ nhận được một số gõ cứng. Bạn có thể tìm thấy những điều bạn đề cập có giá trị hơn và bạn có thể tìm thấy những điều mới mà không ai có mặc dù trước đó. Bạn sẽ phát triển.

Ngay cả trường đại học của tôi đã thất bại trong việc dạy tôi những điều này mặc dù họ đã cố gắng.

Đối với thử nghiệm đơn vị tìm kiếm Phát triển hướng thử nghiệm.

Để bình luận hãy nghĩ về mã mà bạn đã viết sau khi bạn đi. Và thời gian người khác sẽ dành kỹ thuật đảo ngược nó.

Đối với ngôn ngữ hướng đối tượng. Hiểu nó ít nhất. Đó là một công cụ mà bạn có thể sử dụng để giải quyết các vấn đề theo cách dễ đọc hơn.

Chúc may mắn: D


0

Nói tóm lại, cách tốt nhất để học nói chung là đi chơi với ai đó mà bạn có thể học hỏi từ . Nếu bạn cảm thấy rằng kỹ năng của mình không bị trầy xước, đi chơi với những người giỏi hơn bạn là điều tốt nhất bạn có thể làm. Chắc chắn tốt hơn nhiều so với rút tiền và cô lập bản thân hơn nữa.

Tuy nhiên, tôi nghĩ rằng bạn đang vẽ một bức tranh rất đơn giản và sai lệch. Khác xa với tất cả các lập trình viên "được dạy một cách chuyên nghiệp" thực sự là tốt. Chỉ vì họ làm điều gì đó không nhất thiết có nghĩa là đó là điều đúng đắn.

Và nhiều (nhưng không phải tất cả) những gì bạn đang nói thực sự nghe giống như bạn là người có thể dạy họ một hoặc hai mẹo.

Tôi nghiêng về phía Chức năng nhiều hơn OO, nhưng tôi thấy việc sử dụng OO khi một cái gì đó có ý nghĩa hơn như một thực thể trừu tượng.

Điều đó nghe thật tuyệt với tôi. Các lập trình viên giỏi nhất là những người sử dụng công cụ phù hợp cho công việc. Tôi luôn chọn một người biết cả hai mô hình và sử dụng từng mô hình trong đó có ý nghĩa đối với người chỉ sử dụng một mô hình một cách tôn giáo.

Tiếp theo tôi cũng đi con đường đơn giản khi làm việc gì đó. Ngược lại, có vẻ như đôi khi mã tôi thấy từ các lập trình viên chuyên nghiệp rất phức tạp vì lợi ích của nó!

Một lần nữa, đơn giản là tốt . Đừng làm cho mã của bạn phức tạp cho đến khi nó cần phức tạp. Một số người làm có xu hướng làm cho mọi việc ra phức tạp của một số ý tưởng sai lầm của sự thanh lịch, hoặc bởi vì "chúng tôi sẽ cần chức năng bổ sung này sau". Nói chung, tốt hơn là làm điều đơn giản nhất giải quyết vấn đề của bạn.

Tôi sử dụng rất nhiều đóng cửa. Tốt Đó là lý do họ ở đó. Họ sợ một số người bị mắc kẹt trong mô hình gần như đã lỗi thời của những năm 1990 và Java, nhưng thực sự, đó là vấn đề của họ.

Và cuối cùng, tôi không phải là người bình luận tốt nhất.

Những gì nên được nhận xét, và làm thế nào, là rất chủ quan. Không có "đúng" hay "sai" thực sự ở đó, nhưng khi làm việc trong một nhóm, điều quan trọng là viết mã mà toàn bộ nhóm, và không chỉ tác giả của mã, có thể hiểu được. Và đôi khi, các thỏa hiệp phải được thực hiện để phù hợp với phong cách mã hóa của đội. Điều đó không nhất thiết có nghĩa là bạn nên viết thêm bình luận, điều đó đơn giản có nghĩa là đó là điều mà bạn và nhóm của bạn sẽ phải đồng ý.

Tôi nghe các lập trình viên được đào tạo chuyên nghiệp tiếp tục và về những thứ như bài kiểm tra đơn vị. Một cái gì đó tôi chưa bao giờ sử dụng trước đây vì vậy tôi thậm chí không có ý tưởng mờ nhạt nhất về những gì họ đang làm hoặc cách họ làm việc.

Vâng, hỏi họ. :) Kiểm tra mã của bạn là điều cần thiết và kiểm tra đơn vị là một công cụ phổ biến và hữu ích cho việc này.

Rất nhiều và rất nhiều dấu gạch dưới "_", đó không thực sự là sở thích của tôi.

Như với nhận xét, đó là chủ quan, và phụ thuộc vào ngôn ngữ. Trong C và C ++, lowercase_with_underscoreslà một quy ước đặt tên khá phổ biến. Trong nhiều ngôn ngữ khác, bạn hầu như không bao giờ thấy dấu gạch dưới. Nhưng vào cuối ngày, nó thực sự không quan trọng. Cho dù một chức năng được gọi write_to_loghay WriteToLogkhông thực sự sẽ tạo ra sự khác biệt. Ai đó sẽ phải mút nó và tuân theo những gì nhóm đã thỏa thuận ở đó.

Không biết gì về MVC, tôi đã nghe rất nhiều về nó mặc dù với những thứ như backbone.js. Tôi nghĩ đó là một cách để tổ chức một ứng dụng. Nó chỉ làm tôi bối rối bởi vì bây giờ tôi đã tạo ra cấu trúc tổ chức của riêng mình.

Như với bài kiểm tra đơn vị, không bao giờ ngừng học tập. Bạn làm việc cùng với những người biết những điều bạn không làm và những người đến từ một nền tảng khác với bạn. Học hỏi lẫn nhau. Rõ ràng có những điều bạn có thể dạy chúng, nhưng cũng có những điều bạn không biết, hoặc chưa bao giờ nghe nói, chúng có thể dạy bạn. Điều đó không có nghĩa là bạn (hoặc họ) là một lập trình viên tồi. Nó có nghĩa là một lập trình viên giỏi là một người cố gắng cải thiện và học hỏi từ những người khác.

Hoàn thành lập trình OO thực sự để lại một hương vị xấu trong miệng của tôi

Tương tự ở đây, và tôi là cái mà bạn gọi là "được đào tạo chuyên nghiệp" (bằng CS). Những người đã được dạy lập trình khác nhau nhiều như những người tự học. Có vẻ như bạn đang làm việc với một số người thực sự cần học một vài thủ thuật mới.

Trong thực tế, tôi khá sợ thực tế là mọi người cuối cùng sẽ kiểm tra mã của tôi. Đây có phải là điều bình thường mà bất kỳ lập trình viên nào cũng trải qua hay tôi thực sự nên tìm cách thay đổi kỹ thuật của mình?

Cả hai. Tất nhiên thật đáng sợ khi người khác nhìn vào (và phán xét) những gì bạn đã làm. Nhưng nó cũng rất giáo dục. Họ có thể cho bạn biết những gì họ đã làm khác, hoặc tại sao họ lại làm điều đó khác. Họ có thể giúp bạn cải thiện, và họ cũng có thể tự học được điều gì đó. Cho họ xem mã giải quyết vấn đề tốt hơn giải pháp "ưa thích" của họ đã làm và hy vọng họ sẽ đi "ồ, thật gọn gàng. Làm thế nào bạn biết để làm điều đó? Bạn nên gọi cái này là gì? "


0

Đây không phải là một câu trả lời đầy đủ, bạn đã có một vài câu trả lời hay. Tuy nhiên, có một vài điểm mà theo tôi có vẻ hơi bối rối và chưa được giải quyết.

Đó là một hỗn hợp của một số điều tôi làm. Tôi có xu hướng pha trộn một số mô hình lập trình với nhau. Giống như chức năng và OO. Tôi nghiêng về phía Chức năng nhiều hơn OO, nhưng tôi thấy việc sử dụng OO khi một cái gì đó có ý nghĩa hơn như một thực thể trừu tượng. Giống như một đối tượng trò chơi.

Đối với tôi có vẻ như bạn đang nhầm lẫn giữa lập trình khai báo và lập trình mệnh lệnh , hơn là lập trình theo hướng đối tượng chức năng. Nếu bạn có nghĩa là bạn nghiêng về lập trình khai báo và tránh xa mệnh lệnh thì đó là một điều tốt. Tuyên bố tìm cách loại bỏ các tác dụng phụ, điều này sẽ giúp mã của bạn dễ hiểu hơn.

Ngôn ngữ lập trình hiện đại thường hỗ trợ mô hình lập trình khai báo. Ví dụ: trong C #, sử dụng Linq dẫn đến kiểu khai báo, bởi vì bạn không nói làm thế nào để đạt được điều bạn muốn; bạn chỉ nói những gì bạn muốn

Hoàn thành lập trình OO thực sự để lại một hương vị xấu trong miệng của tôi, nhưng đó dường như là điều mà MỌI NGƯỜI khác đang sử dụng nghiêm ngặt.

Ngôn ngữ hiện đại thường là ngôn ngữ đa mô hình. Thật hiếm khi ai sử dụng ngôn ngữ "thuần túy". Nhiều ngôn ngữ chức năng hỗ trợ các đối tượng và tác dụng phụ. Các ngôn ngữ được coi là hướng đối tượng thường không áp đặt ràng buộc rằng mọi thứ đều là đối tượng.

Bạn có ý nghĩa gì khi hoàn thành OO? Tôi chưa bao giờ làm việc với mã OO "thuần túy". Có lẽ bạn có thể cung cấp cho chúng tôi một số chi tiết cụ thể hơn về những gì bạn không thích. Một minh họa từ một dự án nguồn mở có thể giúp ích.

Các chương trình OO cung cấp cho chúng ta nhiều tính năng để hỗ trợ những thứ như: trừu tượng hóa dữ liệu, đóng gói, nhắn tin, mô đun hóa, đa hình và kế thừa. Nếu tôi nhìn vào một cơ sở mã không tận dụng điều đó, nó sẽ để lại mùi vị khó chịu trong miệng tôi.


Tại sao các downvote?
Dave Hillier

0

Câu trả lời ngắn gọn: có.

Dạy bản thân hầu như đều tốt.
Lọc với ý nghĩa tốt, lời khuyên tốt.

WRT học lập trình chuyên nghiệp, vâng.
Bạn đang nghĩ gì vậy?
Hội nghị, hội thảo, chứng nhận, bằng cấp?
Mỗi cái có một chi phí / lợi ích.
Khi ROI tốt, nếu bạn có tài nguyên, hãy dùng nó.

Cân nhắc lời khuyên về bằng cấp bằng cách xem xét nguồn: những người có / không có họ có quyền lợi.
Nói chuyện với một nửa tá mỗi.

Là học viện bị cô lập từ ngành công nghiệp? Thường xuyên.
Là một mức độ vô giá trị? Đô la khôn ngoan, khó cãi.
Sinh viên tốt nghiệp hầu như luôn kiếm được nhiều tiền hơn, nhưng coi chừng các khoản vay đại học.

Kiến thức khôn ngoan? Có lẽ.
Nếu bạn ghét trường học, bạn sẽ không nhận được nhiều hơn bạn đưa vào.

Nếu bạn cảm thấy bằng cấp là một mục tiêu xứng đáng với bạn, thì có lẽ là như vậy.

Đào sâu hơn và tìm hiểu về chương trình học, chi phí, môi trường. Hãy chắc chắn rằng bạn có sự quan tâm, cam kết, thời gian và nguồn lực. Có lẽ bạn đã đi học mười ba năm, vậy bốn người khác là gì? Họ sẽ là người đắt nhất, và người chính mà bạn sẽ dựa vào để làm cho họ có giá trị nhất là bạn.

Chi phí có thể khá đáng sợ, nhưng chúng chỉ kể một phần câu chuyện vì có nhiều khoản tài trợ và học bổng cho công đức, nhu cầu, và một trăm lý do khác.

Nếu bạn đi, chọn thông minh và nụ thông minh.


0

Câu hỏi thứ hai - Tôi có thể sử dụng phong cách của riêng mình không?

Bạn có hai câu hỏi.

Đầu tiên là trong tiêu đề của bạn. Xin vui lòng xem câu trả lời trước đó của tôi.

Đoạn thứ hai được trình bày chi tiết trong khoảng năm đoạn mà bạn mô tả phong cách của bạn khác với phong cách chuyên nghiệp như thế nào với các điểm được liệt kê dưới đây:

  • Tự học 100%.
  • Khác nhau về kỹ thuật và tổ chức.
  • Pha trộn giữa chức năng và hướng đối tượng.
  • Ít phức tạp hơn.
  • Rất nhiều đóng cửa.
  • Rất ít ý kiến.
  • Không có bài kiểm tra đơn vị.
  • Rất ít dấu gạch dưới.
  • Không có MVC.
  • Không có xương sống.
  • Không có ứng dụng mẫu.

Tóm tắt, tôi nghĩ bạn đang hỏi liệu có ổn không khi bạn sử dụng phương pháp Frank Sinatra - "Tôi đã làm theo cách của tôi." Tôi cảm thấy tuyệt vời khi bạn gọi mã của người khác là chuyên nghiệp, nhưng bạn không tham gia với nó. Phong cách là một vấn đề cá nhân dính, và cuộc tranh luận về thế nào là mã tốt là vô tận và thường lãng phí thời gian. Một số vấn đề có thể dễ dàng hơn nếu nhóm của bạn sử dụng quy ước mã hóa bằng văn bản. Xin vui lòng kiểm tra:

http://en.wikipedia.org/wiki/Coding_conventions

Có một nghi thức giết chết mã của người khác, và đó là một điều khác mà bạn nên làm việc với nhóm của mình. Đặt làn da dày của bạn lên và hy vọng chúng không quá tàn bạo, nhưng bất cứ điều gì bạn làm, đừng tham chiến.

Bạn nhận xét về sự lo lắng về những người khác nhìn thấy mã của bạn. Hãy sẵn sàng vì không chỉ họ sẽ nhìn thấy nó, mà họ sẽ viết lại nó và cho bạn biết điều gì sai với phong cách của bạn. Đồng nghiệp của bạn có thể linh hoạt hoặc cứng nhắc. Dù bằng cách nào, tôi khuyên bạn không nên viết lại mã của họ cho kiểu hoặc biến mỗi điểm của kiểu thành một cuộc đàm phán.

Lý do để có mã thống nhất (và đào tạo thống nhất) là để tăng tốc độ và năng suất phát triển, và trong một trường hợp nào đó, thể chế hóa việc học các thực hành tốt nhất. Các vấn đề như camelCase hoặc use_underbars có vẻ tầm thường và nhỏ nhặt, nhưng có những lợi ích cho tính nhất quán.

Hãy cởi mở để thử nghiệm đơn vị và phát triển theo hướng thử nghiệm. Khi bạn ở một mình, không phải là một phần của việc thực hiện các dự án để trả tiền, nó giống như một sở thích hơn. Công cụ của bạn không cần phải phù hợp với những gì người khác đang làm. Nếu mã của bạn gặp sự cố, không có vấn đề lớn. Nhưng khi bạn tham gia với một nhóm, mã mà bạn viết có thể ảnh hưởng đến toàn bộ nhóm, đặc biệt nếu nó đến được với khách hàng.

Tương tự, nếu nhóm của bạn sử dụng MVC, vui lòng tìm hiểu về nó, hy vọng từ cùng các nguồn mà họ tham chiếu. Các phương pháp cấu trúc chương trình có thể tạo ra sự khác biệt lớn như đã được thể hiện bằng thí nghiệm. Một lần nữa, lấy ví dụ và lãnh đạo từ nhóm của bạn.

Nếu nhóm của bạn sử dụng backbone.js, bạn cũng sử dụng nó. Đội của bạn giống như những con vịt đang bay theo đội hình. Xếp hàng cùng nhau giúp họ tiêu tốn ít năng lượng hơn, giúp họ an toàn hơn và giúp họ đến nơi họ đang đi hiệu quả hơn. Sự tương tự bị phá vỡ nếu bạn thúc đẩy nó rất nhiều, nhưng có những lợi thế lớn để sử dụng các công cụ, kỹ thuật phổ biến và sắp xếp đằng sau các quyết định của các đội.


0

Lời khuyên đưa ra khá hữu ích, nhưng tôi cố gắng nhớ rằng mục tiêu chính của tôi là tạo ra 'phần mềm hoạt động' hữu ích cho người dùng của tôi. Đối tượng của tôi thường KHÔNG phải là một nhóm lập trình viên - họ là những người kinh doanh sẵn sàng trả tiền cho một giải pháp tự động (Người dùng không quan tâm đến Phương pháp OO, Khung, Kiểm tra đơn vị, nhận xét mã, v.v. gác máy

Tôi đã tìm thấy những lý tưởng của Tuyên ngôn Agile hữu ích trong sự nghiệp của mình (www.agilemanifesto.org)

  • Các cá nhân và tương tác qua các quy trình và công cụ
  • Phần mềm làm việc trên tài liệu toàn diện
  • Hợp tác khách hàng qua đàm phán hợp đồng
  • Đáp ứng để thay đổi theo kế hoạch

0

Tôi hoàn toàn liên quan đến câu hỏi này. Tôi có cùng cảm xúc và một nền tảng rất giống nhau (nhưng không hoàn toàn giống nhau). Tôi được cho là được đào tạo chuyên nghiệp (hay đúng hơn là về mặt học thuật) vì vậy tôi phải biết về lập trình OO, v.v. Lập trình không phải là chủ đề chính của tôi nhưng tôi đã thực hiện nó. Tôi đã học OO trong một số khóa học của mình và không hiểu lý do gì cả. Nguyên vẹn, lần duy nhất tôi hiểu OO là khi tôi làm công việc thương mại và bị ép buộc bởi hai cố vấn tuyệt vời.

Tôi chắc rằng giáo sư của tôi cũng xuất sắc không kém nhưng bạn thấy lợi ích thực tế trong thực tế trong môi trường thương mại so với lập trình chức năng nhưng bạn không có cơ hội thấy nó trong một khóa học được thiết kế để chạy và dạy và kết thúc trong vài tháng . Tôi chưa có cơ hội làm việc trên cấu trúc dựa trên MVC nhưng tôi chắc chắn nó sẽ giống như vậy tức là tôi có thể chọn các khái niệm làm việc từ một cuốn sách nhưng tôi sẽ hiểu lợi ích của nó khi tôi thấy nó được sử dụng trong môi trường thương mại. Và tôi hoàn toàn đồng ý với bạn, tại sao sử dụng OO và MVC và bất kỳ cấu trúc phức tạp nào khác nếu bạn có thể giải quyết vấn đề thông qua một cách đơn giản hơn. Lời khuyên của tôi là đừng ngại công việc vì nó sẽ khiến bạn gặp phải tình huống khác và cho phép bạn hiểu những điều tương tự ở một khía cạnh khác.

Chắc chắn tôi đã học cú pháp và khái niệm trong nền tảng học vấn của mình nhưng đó là trong thế giới thương mại nơi tôi bắt đầu học lập trình.


Không có gì thay thế cho trải nghiệm trong thế giới thực, cho dù việc giảng dạy có tốt đến đâu
Andrew
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.