Bạn sẽ phản ứng thế nào nếu ai đó nói với bạn mã của bạn là một mớ hỗn độn?

Tôi là một lập trình viên giỏi, hoặc vì vậy tôi nghĩ trước đây. Tôi luôn thích lập trình. Và tôi muốn học nhiều thứ về lập trình để biến tôi thành một lập trình viên giỏi hơn. Tôi học lập trình được 1 năm và hiện tại tôi đang làm lập trình viên được gần 2 năm. Vì vậy, trong ngắn hạn, tôi có gần 3 năm kinh nghiệm lập trình.

Nhóm của chúng tôi gồm 5 lập trình viên và 4 người trong số chúng tôi là người mới, 1 người có hơn 3 năm kinh nghiệm. Chúng tôi đã làm việc cho một chương trình gần một năm nay và không ai từng xem lại mã của tôi và tôi đã được cấp một trang để làm việc. Chúng tôi chưa bao giờ xem xét mã và tất cả chúng tôi đều mới vì vậy chúng tôi không biết mã sạch sẽ trông như thế nào. Tôi nghĩ lập trình viên tự học?

Chúng tôi đã triển khai chương trình của chúng tôi đến chương trình mà không cần kiểm tra kỹ lưỡng. Bây giờ nó rất chặt chẽ và chúng tôi cần phê duyệt và xem xét mã trước khi chúng tôi thực hiện thay đổi với mã. Lần đầu tiên, ai đó xem lại mã của tôi và anh ta nói đó là một mớ hỗn độn.

Tôi cảm thấy rất buồn và đau đớn. Tôi thực sự yêu thích lập trình và khiến họ nói những điều như thế thực sự làm tôi đau lòng. Tôi thực sự muốn cải thiện bản thân. Nhưng có vẻ như tôi không phải là một lập trình viên thiên tài như trong phim. Bạn có thể cho tôi lời khuyên làm thế nào để tốt hơn? Bạn đã bao giờ trải nghiệm một cái gì đó chỉ trích mã của bạn và bạn cảm thấy thực sự đau đớn? Bạn làm gì trên những sự kiện đó.

Sự thật là có lẽ trong 2 năm nữa bạn sẽ thấy mã hiện tại của mình, bạn sẽ đồng ý rằng đó là một mớ hỗn độn. Học lập trình là một quá trình không bao giờ kết thúc và sẽ luôn có một người giỏi hơn bạn.

Vì vậy, nếu người nói rằng mã của bạn là một mớ hỗn độn không chỉ có ý nghĩa và đó không phải là một trường hợp khác của bệnh "Tôi sẽ làm tốt hơn" trong số các lập trình viên, bạn nên hỏi anh ấy / cô ấy chính xác những gì sai với mã của bạn và làm thế nào bạn có thể cải thiện nó.

Đừng tự hào về việc bạn viết mã tốt như thế nào. Hãy tự hào về cách bạn học tốt. Sau đó, học được rằng mã của bạn cần cải thiện cung cấp cho bạn cơ hội để chứng minh bạn học giỏi như thế nào, thay vì đi qua như những lời chỉ trích về việc bạn lập trình viên tệ đến mức nào.

Đọc http://www.perlmonks.org/?node_id=270083 nếu bạn không biết tôi đang nói về cái gì.

Sau hơn 20 năm tôi biết rằng một số mã của riêng tôi vẫn còn là một mớ hỗn độn. Những gì nó được đưa ra là đưa ra quyết định giữa việc viết mã tốt nhất có thể so với viết những gì cần thiết để hoàn thành công việc. Hoàn thành công việc trong một khung thời gian đã thỏa thuận hơn hẳn nhiệm vụ không bao giờ kết thúc cho sự hoàn thiện kỹ thuật bất kỳ ngày nào.

Bí quyết là học cách chấp nhận nó. Học cách chấp nhận rằng bạn có thể làm tốt hơn. Học cách sống với những sai sót. Học cách chấp nhận rằng bạn sẽ không làm cho nó hoàn hảo vào lần này, và có lẽ là lần sau nữa, và đó là một sự lựa chọn có chủ ý vì sự thay thế không mang lại. Và điều đó còn tệ hơn.

Tuyên bố miễn trừ trách nhiệm: không ai trong số này nên được đọc là "mã xấu là OK".

Mã của mọi người là một mớ hỗn độn và không có lập trình viên giỏi.

Có:

• lập trình viên tàu nhanh
• lập trình viên luôn luôn gửi mã chính xác về ngữ nghĩa,
• lập trình viên luôn đưa ra giải pháp tối ưu và thuật toán nhanh nhất,
• lập trình viên có mã dễ nhìn.

Họ hầu như không bao giờ trở thành cùng một người.

Và có những lập trình viên butthurt cần phải lớn lên và:

• hỏi cái gì sai
• không nhận xét cá nhân, như một thước đo giá trị của họ như một con người;
• nhận ra có các hướng dẫn cú pháp trong các nhóm và chúng phải được tuân theo và chúng là tùy ý, vì vậy chúng không có nghĩa là phải thảo luận về quảng cáo , vì không có giải pháp tối ưu, cũng không phải là từ cuối cùng;
• nhận được tốt hơn trong việc bình luận mã của họ;
• nhận được tốt hơn trong việc bình luận mã của họ; (sic)
• tìm cách dễ dàng hơn để gỡ lỗi, ít thông minh hơn, các giải pháp cho các nhiệm vụ đơn giản, trần tục;
• tham gia một lớp học về SQL
  (Tôi sẽ gửi một nửa dân số thế giới này tham gia một lớp học về SQL, chỉ để ở bên an toàn)

Đó không phải là nghệ thuật, đó là một nghề thủ công.
Chúng tôi cho rằng bạn thông minh: bạn đang lập trình máy tính, chết tiệt.
Vẫn AMD64và x86không bị ép buộc bởi sức mạnh của văn xuôi của bạn. Giữ mọi thứ đơn giản.

Chà, một người nói rằng mã của bạn là một mớ hỗn độn không mang tính xây dựng, ngay cả khi họ đúng. Họ đã cho bạn lý do tại sao nó là một mớ hỗn độn? Giống như, các phương thức quá dài, các trách nhiệm trộn lẫn với nhau, quá nhiều phân nhánh, v.v ... Thành thật mà nói, bất kỳ mã nào tôi viết cách đây một năm tôi sẽ nói là hoàn toàn tào lao vì tôi đã học được một tấn kể từ đó. Vì vậy, đừng cảm thấy tồi tệ về nó. Tôi sẽ lo lắng hơn nếu bạn vẫn thích đọc mã bạn đã viết từ lâu.

Cơ sở mã của bạn càng sạch thì bạn càng dành ít thời gian hơn để chống lại cơ sở mã để giải quyết một vấn đề nhất định. Một năm là một điểm tuyệt vời để có được bởi vì bạn có thể cảm thấy đau đớn của bất kỳ quyết định thiết kế nào bạn đã thực hiện trước đó trong dự án.

Trong dự án hiện tại của tôi, chúng tôi đã tái cấu trúc nhiều lần khi chúng tôi cảm thấy thoải mái hơn với kho công nghệ của mình. Điều này nên được khuyến khích và bạn nên lưu ý các nhiệm vụ mất nhiều thời gian hơn so với hiện tại vì cơ sở mã hiện tại.

Bạn đã đi qua một số phần cũ của mã bạn đã viết? Bạn có thể thấy những điều bạn muốn làm khác bây giờ hoặc tái cấu trúc.

Ngoài ra khi bạn đề cập đến việc thiếu kiểm tra, đây luôn là điều cần xem xét. Trong dự án của chúng tôi, chúng tôi không có thử nghiệm tự động và kết quả là rất nhiều mã được ghép nối cao. Ngay cả khi bạn không viết đơn vị / tích hợp / bất kỳ bài kiểm tra nào thường xuyên, thực hiện nó trong một thời gian sẽ giúp bạn có thói quen làm cho mã của mình trở nên mô đun hơn (và do đó, ít gây rối hơn).

Tôi cảm thấy rất buồn và đau đớn. Tôi thực sự yêu thích lập trình và khiến họ nói những điều như thế thực sự làm tôi đau lòng. Tôi thực sự muốn cải thiện bản thân.

Điều đó là tốt. Điều đó tốt hơn nhiều so với phản ứng như "người đánh giá của tôi không biết anh ta đang nói về điều gì", "người đánh giá của tôi quá kén chọn" hoặc chỉ "người đánh giá của tôi không thích tôi" và bỏ qua họ. Thái độ này là một điều tốt.

Nhưng có vẻ như tôi không phải là một lập trình viên thiên tài như trong phim.

Không chắc bạn xem loại phim nào, nhưng 90% lập trình viên trong phim đều giả tạo đến mức tôi rơi nước mắt khi kết thúc chuỗi.

Bạn có thể cho tôi lời khuyên làm thế nào để tốt hơn?

Đọc và thực hành. Kiểm tra các cuốn sách như Code Complete hoặc Lập trình viên thực dụng . Tìm trên Amazon cho các cuốn sách tương tự.

Bạn đã bao giờ trải nghiệm một cái gì đó chỉ trích mã của bạn và bạn cảm thấy thực sự đau đớn? Bạn làm gì trong những sự kiện đó ..

Tại sao bạn cảm thấy đau? Tôi cảm thấy thất vọng về bản thân vì đã là một kẻ ngốc như vậy ngay từ đầu. Tôi sử dụng động lực đó để làm sạch mã của mình và đảm bảo rằng tôi sẽ không lặp lại sai lầm tương tự . Điều cuối cùng tôi muốn làm nó không học hỏi từ nó. Bạn đã bị đặt xuống một lần, đừng để nó xảy ra lần nữa vì lý do tương tự.

Không có lập trình viên được sinh ra hoàn hảo, hoặc thậm chí gần gũi. Viết càng nhiều mã, bạn càng nhận được nhiều đánh giá và đánh giá bạn cung cấp , sẽ giúp bạn trở thành một lập trình viên toàn diện hơn.

Một trong những điều tốt nhất với tôi về việc trở thành một nhà phát triển là mỗi ngày là một quá trình học tập. Sẽ luôn có một người ngoài kia không biết điều gì bạn làm, và sẽ luôn có người biết điều gì đó mà bạn không biết. Tôi chắc chắn sẽ không coi mình là bất cứ nơi nào ngoài cấp độ đầu vào / cấp cơ sở, nhưng tôi đánh giá cao bất kỳ lời chỉ trích nào tôi có thể nhận được miễn là nó vừa hợp lý vừa được tôn trọng.

Một sự tương tự có thể phù hợp liên quan đến một khoảng thời gian mà tôi là một gia sư dạy viết tại một trường đại học, cũng như khi tôi tham gia các khóa học viết sáng tạo. Viết mã, cho tất cả ý định và mục đích, giống như viết một bài thơ, bài tiểu luận, truyện ngắn hoặc tiểu thuyết. Mỗi cá nhân có cách làm việc riêng của họ, nhưng đồng thời, ngay cả những nhà văn giỏi nhất (hoặc, trong trường hợp này, các nhà phát triển) cũng mắc lỗi hoặc để mọi thứ trôi qua vết nứt. Chúng ta thường có thể không nhận thấy những điều này bởi vì chúng ta đã quá quen với giọng nói của chính mình (hoặc một lần nữa, trong trường hợp này, phong cách mã).

Giống như trong bất kỳ lĩnh vực nào, có những người được coi là chuyên gia. Nếu những người đó không tồn tại, chúng tôi sẽ không có ai để học hỏi. Giả sử cá nhân này trong câu hỏi thực sự là một chuyên gia, tôi sẽ lắng nghe những gì anh ta nói và hỏi những gì anh ta sẽ đề nghị bạn làm để cải thiện mã của bạn. Tuy nhiên, đừng bao giờ quên rằng anh ta không phải là người duy nhất có thể giúp đỡ mình; chúng ta có may mắn là có rất nhiều tài nguyên như SE / SO tồn tại.

Lộn xộn là khá chủ quan. Điều tốt nhất bạn có thể làm là thực sự hỏi người đó (hoặc báo cáo đánh giá): tại sao nó lại lộn xộn? (theo quan điểm của họ, đó là)

Họ nhất định trả lời bạn và bạn sẽ có thể:

• Lập luận chống lại nó (tất nhiên nếu bạn có lý do chính đáng để làm như vậy)
• Cảm thấy rất vui, vì bạn vừa học được điều gì đó mới và mã tương lai của bạn chắc chắn sẽ tuyệt vời hơn vì bây giờ bạn biết cách làm cho nó bớt lộn xộn nhờ lời khuyên của họ.

Thực tế là bạn quan tâm là một dấu hiệu tốt. Hãy bắt đầu với điều đó. Bạn đề cập đến việc bạn thích lập trình, nhưng bạn có thích trở thành một lập trình viên chuyên nghiệp không? Có một sự khác biệt lớn giữa một người đam mê và một chuyên gia. Là một chuyên gia, bạn sẽ được kiểm tra liên tục cho sản phẩm công việc của bạn.

Our team is composed of 5 programmers, and 4 of us are new

Thực tế là bạn đã làm việc hai năm mà không có bất kỳ cuộc đối đầu nào cho tôi biết rằng bạn đang làm việc trong một công việc rất thoải mái, điều đó không tốt lắm nếu bạn thực sự muốn tiến lên như một chuyên gia. Xin lưu ý bạn, một số lập trình viên giỏi nhất trên thế giới làm việc cho nền tảng Linux và yên tâm rằng họ không được đối xử tử tế khi họ mắc lỗi ngoài lề ... ít hơn 'mã lộn xộn'.

Để xem xét nhanh một số nguyên tắc mã hóa khá chuẩn, Tiêu chuẩn cộng tác viên cộng đồng Linux sẽ cung cấp cho bạn ý tưởng về mức độ trách nhiệm mong muốn đối với sản phẩm của bạn. Tham khảo NHẬN QUYỀN MÃ.

Để tiếp tục khẳng định đó, bạn nên học cách chấp nhận đánh giá vì hầu hết các phần mềm tốt đều được xem xét kỹ lưỡng. Điều này hỗ trợ Luật của Linus nêu rõ ...

"Nếu có đủ người đánh giá, mọi vấn đề đều dễ giải quyết."

Cá nhân, tôi đã thấy các nhà phát triển có kỹ năng cao, có trách nhiệm và đáng tin cậy nhận được một cái rìu đơn giản như quên để lại bình luận ... vì vậy nếu ai đó nói với bạn mã của bạn là một mớ hỗn độn thì có lẽ là ... Hãy vượt qua nó ... Tái cấu trúc. Đó là một phần của buổi biểu diễn.

I feel so sad and hurt. 

Hãy tạo một ứng dụng nỗi buồn để đánh giá mức độ khó chịu của bạn khi bạn không áp dụng chính mình.

Bạn đã trả lời vấn đề của mình ... Bạn đừng kiểm tra!

Sau khi thấy một bình luận mà bạn đưa ra nói rằng nhà phát triển java của bạn, tôi gần như buồn bã. Vì vậy, nếu tôi hiểu chính xác bạn nói rằng bạn và nhóm phát triển của bạn đang làm việc trong một cửa hàng java và không có khung kiểm tra cho các ứng dụng của bạn ...

Trong đó nói dối

"Chúng tôi đã triển khai chương trình của mình cho chương trình mà không cần kiểm tra kỹ lưỡng."

Nắm bắt UML Creator Grady Booch ...

Kỹ sư phần mềm nghiệp dư luôn tìm kiếm ma thuật, một số phương pháp hoặc công cụ giật gân mà ứng dụng hứa hẹn sẽ khiến việc phát triển phần mềm trở nên tầm thường. Đó là dấu hiệu của kỹ sư phần mềm chuyên nghiệp để biết rằng không có thuốc chữa bách bệnh như vậy tồn tại.

Alistair Cockburn cung cấp nhiều thông tin trên trang web của mình về việc sử dụng các phương pháp nhanh để tăng hiệu suất và chất lượng cho bạn và nhóm của bạn.

Một trong những khía cạnh quan trọng nhất của lập trình {và cuộc sống} là biết điểm mạnh và điểm yếu của bạn. Nếu bạn không khắc phục được những điểm yếu của mình, bạn sẽ không có bộ kỹ năng toàn diện.

Ra ngoài ... Làm tốt lắm - Đừng than vãn. Tiến về phía trước trong việc phát triển nghề của bạn và để niềm đam mê lập trình của bạn tiếp tục phát triển. Chúc may mắn :-)

Đừng để cảm xúc của bạn cản trở việc cải thiện mã của bạn. Mục tiêu của đánh giá mã là tìm ra các vấn đề, vì vậy bạn không nên quá ngạc nhiên nếu có một số vấn đề. Điều đó nói rằng, họ cũng không phải là một phiên bash coder.

Họ cũng không nên chỉ nói 'Ewwww' và để nó ở đó. Luôn có một lý do tại sao một cái gì đó sai trong lập trình. Ví dụ, thật sai lầm khi để nhiều mã nhận xét ở khắp mọi nơi, nhưng nó sai vì nó làm lộn xộn mã và khiến nó khó đọc hơn, không phải vì ai đó đã nói như vậy trong một cuốn sách.

Mã của bạn không phải là bạn. Nhớ lấy.

Tôi sẽ là người tinh ranh ở đây và tư vấn trên cơ sở .. tốt, rõ ràng. Rõ ràng, mã của bạn là một mớ hỗn độn hoặc câu hỏi bạn đang hỏi là "TẠI SAO ai đó nói mã của tôi là một mớ hỗn độn?" Nhưng bạn không thách thức giả định. Bạn chỉ hành động bị tổn thương và khá thẳng thắn có thể khóc nhưng không có cảm giác gì khi nói đến việc lập trình.

Nhưng thực sự, tại sao bạn hỏi? Bạn biết mã của bạn hút hoặc bạn sẽ hỏi một câu hỏi khác. Nếu ai đó nói với tôi mã web back-end của tôi bị đắm, tôi sẽ cười và nói "được rồi, có chuyện gì với nó à?" Nếu họ nói với tôi rằng JavaScript của tôi bị đắm, tôi sẽ cho họ lập trình viên xã hội tương đương với một đôi môi béo và tôi sẽ không bao giờ hỏi lời khuyên về cách phản ứng vì những con chó nhỏ rõ ràng! @ # $ Ing sai.

Sở hữu những gì bạn giỏi. Và tôi thực sự có nghĩa là chịu trách nhiệm cho nó. bởi vì nó chỉ mất một lần cho một số twit để đoán bạn. Đừng xin phép để được tốt. Chỉ cần biết công cụ của bạn. Kết thúc.

Hãy nhớ điều này: Mã tồi tệ nhất bạn từng thấy là của riêng bạn!

Jeff Atwood của tiền mã hóa.com đã viết rất nhiều về chủ đề này, bạn có thể muốn bắt đầu ở đây: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Nếu bạn muốn cải thiện, hãy bắt đầu đọc những thứ về phong cách mã hóa, mô hình, quy trình công việc, về cơ bản mọi thứ bạn có thể có được. Cũng tìm hiểu thêm ngôn ngữ lập trình, xem cách họ làm công cụ. Nếu bạn đang làm OOP, hãy đọc nó: http://en.wikipedia.org/wiki/Design_Potypes

Cũng nói chuyện với các lập trình viên khác và lập trình cặp hoặc xem mã người khác.

Làm sai là không thể tránh khỏi, lặp lại chúng là.

Hầu hết thời gian bạn nên nói "Cảm ơn" với người đã nói với bạn điều này.

Có thể là họ quan tâm đến nghề nghiệp của họ, họ quan tâm đến công việc của họ, họ quan tâm đến nhóm của họ và họ quan tâm đến bạn.

Nó có thể khó để đưa ra lời chỉ trích. Đừng tức giận về nó. Hãy suy nghĩ về những gì họ đang cố nói với bạn và đừng để cảm xúc của bạn tốt hơn với bạn.

Tôi đã lập trình trong một thời gian dài (30 năm) và phong cách và mã của tôi luôn được cải thiện (tôi hy vọng). Cách duy nhất mà tôi biết sự cải thiện của nó là khi người khác nói với tôi hoặc nếu tôi quay lại và xem lại mã của mình.

Hãy thử nhìn vào mã bạn đã viết khi bắt đầu sự nghiệp của bạn. Bây giờ nó trông như thế nào với bạn? Nó có tốt như bạn nghĩ khi bạn viết không;)

Trước hết, bạn phải hiểu rằng lập trình là một quá trình lặp đi lặp lại, giống như viết một bài báo hoặc một cuốn sách. Trước tiên, bạn viết một "bản thảo thô" của chương trình của bạn, chỉ để làm cho nó hoạt động. Ở giai đoạn này, mã của bạn sẽ là một mớ hỗn độn. Vì vậy, bạn refactor để làm cho mã sạch. Sau đó, bạn hồ sơ và xem những gì bạn cần tối ưu hóa để làm cho nó nhanh chóng. Bí quyết là tái cấu trúc liên tục, nếu không sự lộn xộn sẽ phát triển. Bạn phải dọn dẹp mã của bạn thường xuyên, giống như bạn phải dọn dẹp nhà cửa.

Mã đánh giá là hoàn toàn cần thiết. Bạn phải nhìn mã của mình bằng ít nhất một cặp mắt khác. Khi bạn dành vô số thời gian để xem mã của mình, bạn sẽ quen với nó và bạn có thể dễ dàng bỏ lỡ một lỗi hoặc mùi mã mà đồng nghiệp của bạn có thể nhận thấy ngay lập tức.

Ngoài ra, hành động giải thích mã của bạn cho người khác là một cách tuyệt vời để xem bạn có bỏ sót điều gì không. Điều này giống như đọc một bài báo bạn đang viết thành tiếng. Bộ não của bạn xử lý thông tin âm thanh và hình ảnh theo những cách khác nhau và bạn có thể tìm thấy những sai sót trong lý luận của mình bằng cách chuyển đổi phương thức. Ngoài ra, nếu bạn giải thích mã của mình cho đồng nghiệp và điều gì đó không có ý nghĩa với cô ấy, đó là một dấu hiệu tốt cho thấy bạn nên cấu trúc lại mã của mình.

Khi thực hiện đánh giá mã, điều rất quan trọng đối với cả tác giả và người đánh giá là kiểm tra bản ngã của họ ở cửa. Mục tiêu là làm cho mã tốt hơn. Vì vậy, người đánh giá phải tôn trọng, và tác giả phải giữ một tâm trí cởi mở. Hãy nhớ rằng, đồng nghiệp của bạn là những người sẽ phải duy trì mã của bạn, vì vậy nó phải rõ ràng với họ. Nếu người đánh giá không hiểu biến là gì, hãy đổi tên nó. Nếu người đánh giá không thể hiểu khối mã làm gì, hãy cấu trúc lại nó thành một hàm có tên mô tả. Bất kể những gì bạn có thể nghĩ, nếu đồng nghiệp của bạn không thể hiểu mã của bạn, điều đó là không tốt.

Nói về tái cấu trúc, bạn nhất định phải có khung kiểm tra đơn vị, bởi vì không có nó, bạn không thể cấu trúc lại.

Cuối cùng, tôi đặc biệt khuyên bạn nên đọc "Clean Code" của Robert C. Martin. Nó sẽ cho bạn biết lý do tại sao mã của bạn là một mớ hỗn độn và bạn có thể làm gì để dọn sạch nó.

Bạn có thể cho tôi lời khuyên làm thế nào để tốt hơn?

Câu trả lời của Jay đề xuất sách là một câu hỏi hay, tuy nhiên có vẻ như bạn đang ở bước ngoặt trong công việc.

Quá khứ:

Nhóm của chúng tôi gồm 5 lập trình viên và 4 người trong số chúng tôi là người mới, 1 người có hơn 3 năm kinh nghiệm. Chúng tôi đã làm việc cho một chương trình gần một năm nay và không ai từng xem lại mã của tôi và tôi đã được cấp một trang để làm việc.

Hiện tại:

Bây giờ nó rất chặt chẽ và chúng tôi cần phê duyệt và xem xét mã trước khi chúng tôi thực hiện thay đổi với mã.

Có vẻ như công ty / nhóm / bộ phận của bạn đang học toàn bộ, về mặt quản lý dự án và nhóm cũng như lập trình. Bắt đầu xem xét mã là một cơ hội tuyệt vời để cải thiện trong hầu hết các lĩnh vực nếu nó được quan tâm đúng mức.

Sử dụng điều này như một cơ hội; giả sử bạn đang thực hiện đánh giá ngang hàng (với các nhà phát triển khác trong nhóm của bạn) đề xuất với họ rằng quy trình này rất quan trọng và mọi người đều có thể học hỏi từ nó.

Ở dòng cơ sở, nó sẽ là một đánh giá nhanh với kết quả là "yeah trông ổn". Với một chút nỗ lực tập trung hơn, bạn có thể đưa ra ý tưởng cho nhau, "vâng, nó hoạt động, nhưng bạn có thể đã tiếp cận nó theo cách này, điều này sẽ làm cho mục tiêu của bạn rõ ràng hơn ...". Ghi chú cho tương lai ngay cả khi mã được coi là ok để triển khai.

Nếu điều này sẽ thành công, bạn cần có đội ngũ và người quản lý của mình ở bên, điều này thường có nghĩa là giải thích những lợi ích cho họ. Đối với các nhà phát triển khác, đây là một cơ hội để học hỏi. Đối với người quản lý của bạn, đây là cơ hội để nâng cao kỹ năng cho nhóm với chi phí thấp, do đó tạo ra kết quả đầu ra a) với nhiều giá trị hơn hoặc b) nhanh hơn c) với chi phí bảo trì ít hơn (thường là một vấn đề lớn!).

Đây là một sự thay đổi về văn hóa, mà bạn không thể tự mình thực hiện, nhưng bạn có thể giúp thúc đẩy mọi thứ đi đúng hướng!

Đừng quên, đây là loại thay đổi văn hóa có thể mang lại lợi ích lớn cho các tổ chức; những người quản lý giỏi sẽ nhận ra rằng bạn đang làm việc để làm cho toàn bộ nhóm trở nên tốt hơn, một điều đáng giá.

Bạn có thể cho tôi lời khuyên làm thế nào để tốt hơn? Bạn đã bao giờ trải nghiệm một cái gì đó chỉ trích mã của bạn và bạn cảm thấy thực sự đau đớn? Bạn làm gì trên những sự kiện đó.

Câu trả lời cho điều này có thể được tìm thấy trong các công ty thế hệ mới. Tôi đã từng đến các công ty như Google và FaceBook và tôi thấy rằng nếu bạn theo quy trình Agile / Scrum một cách tôn giáo, thì bạn có thể viết mã tốt hơn và cải thiện nó mỗi lần chạy nước rút.

How to be better? 

Câu trả lời là tái cấu trúc liên tục. Các công cụ phát triển hiện đại như visual studio có rất nhiều công cụ giúp bạn trong quá trình này. Nếu bạn theo quy trình phát triển phần mềm Scrum, sau đó nói ví dụ, bạn đã viết mã xấu trong chu kỳ chạy nước rút 1 và ai đó đã chỉ ra trong khi xem xét nó xấu, thì trong lần chạy nước rút 2, bạn có cơ hội để cấu trúc lại mã.

Những vấn đề này đang xảy ra ngay từ đầu vì thiếu quy trình tốt. Vì vậy, giải pháp là đưa ra một quy trình phát triển phần mềm tốt cho nhóm của bạn và thực hành tái cấu trúc liên tục.

Tôi sẽ cảm ơn họ về phản hồi, và sau đó yêu cầu họ giải thích điều gì làm cho nó xấu và làm thế nào để cải thiện nó.

Nếu bạn đồng ý người đưa ra phản hồi có ý nghĩa, hãy xem xét thực hiện các thay đổi trong tương lai. Nhưng hãy nhớ, chỉ vì ai đó nói nó không có nghĩa là nó đúng.

Bạn có thể đưa ra ví dụ cụ thể về cái được gọi là "một mớ hỗn độn" không?

Trước hết ai đó nói mã của bạn là một mớ hỗn độn rất mơ hồ và chủ quan. Nó có thể có nghĩa là những điều khác nhau cho những người khác nhau. Đây là lý do tại sao; Có hai điều khác nhau phải được xem xét.

Kết cấu

Cấu trúc mã của bạn được điều chỉnh bởi ngôn ngữ, tiêu chuẩn ngành và tiêu chuẩn công ty để đặt tên cho một số. Rõ ràng là có các yếu tố khác là tốt.

Đây là các loại lỗi mà lint, công cụ kiểm tra và các sản phẩm tương tự được thiết kế để xác định. Chúng được xác định rõ và bạn hoặc các công cụ của bạn có thể đưa ra quyết định khách quan về tính hợp lệ / chính xác của chúng.

Phong cách

Mặc dù cấu trúc / quy tắc chuẩn hóa cho mã, mọi nhà phát triển đều có một phong cách nhất định trong cách họ viết và tiếp cận một vấn đề hoặc nhiệm vụ. Thực hiện bảo trì mã trong bất kỳ môi trường nhóm nào và theo thời gian, bạn sẽ có thể đoán được giáo dục về người đã viết mã dựa trên phong cách. Bạn cũng sẽ phát triển phong cách của riêng mình và nó sẽ thay đổi khi bạn có kinh nghiệm và học hỏi nghề của mình.

Vì vậy, bất cứ lúc nào ai đó nói mã của bạn là một mớ hỗn độn bạn cần phải hiểu nếu họ đang nói về cấu trúc hoặc phong cách . Chúng là hai thứ rất khác nhau; cấu trúc là khách quan trong khi phong cách là hoàn toàn chủ quan.

Điều đó đang được nói, bất kỳ phản hồi mang tính xây dựng từ các lập trình viên khác có thể rất có giá trị với bạn. Tất cả tùy thuộc vào bạn và cách bạn đưa ra những lời chỉ trích. Theo thời gian, bạn sẽ biết được ý kiến ​​của ai sẽ thuộc về trái tim so với việc họ sẽ dùng một hạt muối.

Khi bạn tiến bộ trong sự nghiệp, bạn sẽ nhìn lại mã của chính mình và thấy những điều bạn có thể làm khác đi, tốt hơn, sạch hơn và nhanh hơn. Đó là tất cả các phần của quá trình học tập và nhìn thấy những sai lầm trong quá khứ của chính bạn là một dấu hiệu xác thực cho thấy bạn đang mài giũa và cải thiện nghề của mình.

Đừng để một chút chỉ trích làm nản chí tinh thần của bạn. Lấy những gì bạn có thể từ nó và nếu nó có ý nghĩa và có giá trị hãy thêm nó vào kho kiến ​​thức của bạn.

Mặc dù điều quan trọng là phải nhận ra khi mã riêng của bạn là một mớ hỗn độn (cảm giác rất điển hình của các lập trình viên, đặc biệt là khi họ trở nên có kinh nghiệm hơn và tuổi mã trước đó), điều quan trọng hơn là phải lắng nghe khi người khác nói với bạn như vậy.

Chỉ có rất nhiều vấn đề bạn có thể nhận ra trong mã của riêng mình, vì nó được tạo ra trong các ràng buộc về kiến ​​thức lập trình hiện tại của bạn.

Đánh giá mã là cơ hội học tập thiết yếu vì nó có thể giúp bạn có kiến thức mới mà bạn không có trong khi làm việc với mã (nếu không bạn sẽ sử dụng nó và sẽ không có sự lộn xộn).

Tôi nghĩ có hai phần để xử lý phản hồi tiêu cực.

1. Xác định bản chất của vấn đề nêu ra và những gì bạn nên học hỏi từ nó

Khi tôi xem xét hoặc kiểm tra mã của mình, tôi sắp xếp thông tin về các vấn đề về mã trong các thùng như vậy:

• vi phạm các yêu cầu công nghệ cứng
  • hoàn toàn sai (không hoạt động hoặc thực hiện theo yêu cầu)
  • sẽ thất bại trong các trường hợp khác (thay đổi môi trường / cấu hình)
  • sử dụng chức năng không dùng nữa và sẽ phá vỡ trong tương lai gần
• vi phạm thực tiễn tốt nhất trong ngành, thiếu những thứ như
  • sử dụng phương pháp đã được chứng minh cho vấn đề cụ thể
  • hiệu suất
  • tương thích ngược
  • dễ bảo trì
  • phong cách mã hóa
  • tài liệu
• vi phạm nơi làm việc tốt nhất
  • giống như ngành, nhưng cụ thể hơn đối với công ty / đồng nghiệp và có thể khác với ngành cụ thể
• không phù hợp với chuyên môn cá nhân
  • có thể được cải thiện theo một cách nào đó, theo ý kiến ​​của người đánh giá

Lưu ý rằng điều này nằm trong phạm vi từ những điều rất khách quan ("điều này sẽ bị phá vỡ khi được triển khai đến máy chủ sản xuất của chúng tôi") đến những điều rất chủ quan ("Tôi không thích cách bạn đặt tên biến").

2. Xác định thay đổi nào (nếu có) đối với mã sẽ được thực hiện khi xem xét

Sau khi thông tin được xử lý, sẽ có quyết định nếu nó có thể thực hiện được và nếu mã phải được thay đổi. Đây không nhất thiết là quyết định của bạn, ý kiến ​​của bạn có thể hoặc không quan trọng tùy thuộc vào các bên liên quan và chi tiết cụ thể về tình huống của bạn (thâm niên, v.v.). Nhưng kết quả có thể đại khái là:

• vấn đề địa chỉ đầy đủ
  • sửa lỗi
  • định dạng theo kiểu mã hóa yêu cầu
  • và v.v.
• đi đến thỏa hiệp nếu vấn đề nên được giải quyết ở tất cả hoặc một phần, vì có thể có
  • không có tài nguyên (như thời gian hoặc ngân sách)
  • không cần (sẽ chỉ đạt được sự cải thiện không đáng kể, thỏa hiệp ổn định, v.v.)
• hiểu rằng vấn đề nêu lên là không hợp lệ
  • Phản hồi (đặc biệt là từ loại ý kiến ​​chủ quan) rất có thể có hại hoàn toàn và không nên hành động một cách mù quáng

Bạn đã học được rằng cảm thấy đau đớn khi nhận được phản hồi tiêu cực và rất có thể sẽ đau đớn mỗi lần trong tương lai. Tuy nhiên, bạn đã học được cách cơ hội học tập quan trọng và quá trình giúp bạn cải thiện chuyên nghiệp và nơi làm việc của bạn để đạt được cơ sở mã tốt hơn.

Đừng cảm thấy thất vọng. Cuối cùng, bạn sẽ học hỏi từ những sai lầm. Một khi bạn đã giải quyết xong vấn đề, bạn có thể nói chuyện với anh chàng để anh ấy cảm thấy rằng bạn muốn cải thiện. Cố gắng lắng nghe nhiều hơn và tranh luận ít hơn.

Tôi đã trải qua tình huống này và tôi có thể hiểu.

TL; DR

Bạn sẽ phản ứng thế nào nếu ai đó nói với bạn mã của bạn là một mớ hỗn độn?

Nói thẳng ra, "quá lâu tôi không đọc (tất cả các câu trả lời - xin lỗi, tôi hy vọng sẽ tìm thấy thời gian để sau này và chỉnh sửa / sửa đổi điều này nếu cần thiết" "câu trả lời / mẹo:

• Đánh giá ngang hàng cũ. Yêu cầu các phi hành đoàn khác nhau với tâm lý tập thể, trình độ chuyên môn và / hoặc mức độ tích cực khác nhau để xem xét mã của bạn.
• Chỉ cần giải thích một chút về ý nghĩa của các nhóm đồng đẳng "khác biệt": StackExchange diaspora có lẽ là nhóm được gắn bó, chuyên nghiệp và quý trọng nhất vì khó khăn tương đối trong việc trở thành một phần của nó so với Reddit. Reddit có xu hướng rất tích cực trong các tiểu reddits phổ biến hơn - nhưng thật kỳ lạ, các subreddits lập trình khá thân thiện (từ những gì tôi đã trải nghiệm).

Một ví dụ hay, có lẽ là tốt nhất, về tâm lý nhóm người hung hăng, kiểu gangsta là đám đông Diễn đàn XDK, và tệ nhất trong chiếc cúp tồi tệ nhất mà tôi trao cho CyanogenMod cho các diễn đàn Android / kênh IRC.

Đó là một chút lâu hơn tôi dự định; quan điểm của tôi được cho là - nhận được nhiều đánh giá khác nhau, nhưng tập trung vào việc nhận được sự phê phán trung thực từ những người biết giao dịch của họ và biết những lời chỉ trích mang tính xây dựng là gì. Ồ, và có thể đưa ra bất kỳ hình thức phê bình nào mà không để nó làm bạn thất vọng. Nguyên tắc nhỏ: nếu bạn bắt đầu nghe bình luận tương tự liên quan đến một điều có thể tương hỗ với các bình luận, thì hãy thực hiện một số nội tâm kỹ lưỡng hơn.