Thiết kế đề xuất của tôi thường tệ hơn so với đồng nghiệp của tôi - làm thế nào để tôi trở nên tốt hơn? [đóng cửa]

Tôi đã lập trình được vài năm và nói chung là rất tốt khi sửa chữa các vấn đề và tạo các tập lệnh từ nhỏ đến trung bình, tuy nhiên, tôi thường không giỏi trong việc thiết kế các chương trình quy mô lớn theo cách hướng đối tượng. Một số câu hỏi

1. Gần đây, một đồng nghiệp có cùng số năm kinh nghiệm như tôi và tôi đang làm việc về một vấn đề. Tôi đã làm việc với một vấn đề lâu hơn anh ta, tuy nhiên, anh ta đã đưa ra một giải pháp tốt hơn và cuối cùng chúng tôi sẽ sử dụng thiết kế của anh ta. Điều này thực sự ảnh hưởng đến tôi. Tôi thừa nhận thiết kế của anh ấy tốt hơn, nhưng tôi muốn đưa ra một thiết kế tốt như của anh ấy. Tôi thậm chí đang dự tính bỏ việc. Không chắc chắn tại sao nhưng đột nhiên tôi cảm thấy dưới một áp lực nào đó, ví dụ như đàn em sẽ nghĩ gì về tôi và vân vân? Nó có bình thường không? Hay tôi đang suy nghĩ quá nhiều về điều này?

2. Công việc của tôi liên quan đến lập trình trong Python. Tôi cố gắng đọc mã nguồn nhưng bạn nghĩ tôi có thể cải thiện kỹ năng thiết kế như thế nào? Có cuốn sách hay phần mềm nào tốt mà tôi nên học không?

Vui lòng làm sáng tỏ cho tôi. Tôi sẽ thực sự đánh giá cao sự giúp đỡ của bạn.

Tôi nghĩ rằng đây là một dấu hiệu rất tích cực về kỹ năng của bạn. Điều phổ biến hơn nhiều đối với những người gặp khó khăn khi đưa ra thiết kế 'tốt hơn' trong một nhóm là hoàn toàn không có khả năng nhận ra lý do tại sao một thiết kế khác tốt hơn.

Bạn có hai điểm mạnh thực sự tuyệt vời (và đáng ngạc nhiên là không phổ biến) dành cho bạn:

• Bạn có khả năng đánh giá thiết kế của bạn so với người khác một cách khách quan
• Bạn có mong muốn và nỗ lực để làm cho thiết kế của bạn tối ưu

Bạn chỉ còn vài năm nữa và còn một chặng đường dài để đi, nhưng với thái độ này, bạn chắc chắn sẽ đến đó, đừng bỏ cuộc; tất cả chúng ta đối phó với các thiết lập tinh thần như thế này. Thường xuyên có cơ hội tôi thích cắm Nguyên tắc thiết kế (KHÔNG giống như mẫu thiết kế) và tôi nghĩ đây là một ví dụ hoàn hảo về nơi chúng có ích. Nghiên cứu chúng và thực hành áp dụng chúng trong thiết kế của bạn, bạn sẽ trước khi bạn biết rằng nó đã tiến thêm một bước về vấn đề này.

Vào cuối ngày nhớ, thiết kế là khó. Chúng ta đang đối phó với sự trừu tượng ở mức độ cao phức tạp mỗi ngày, để tạo ra chúng từ không khí mỏng, để chúng hoạt động tốt và dễ sử dụng bởi các đồng nghiệp là một nhiệm vụ cực kỳ khó khăn. Nó cần thực hành, trong nhiều năm .

Vì vậy, hãy nhớ và chỉ cần nhớ: có một nhóm người ngoài kia không thể đánh giá hai thiết kế và thực sự nhận ra một thiết kế phù hợp hơn một thiết kế khác, bạn nghĩ họ hợp nhau như thế nào trong việc tạo ra các thiết kế tốt?

Chỉnh sửa:
tip mẹo nhỏ, sau khi hiểu rõ các nguyên tắc và thực hành ứng dụng của họ một chút, tôi nghĩ rằng có một viên ngọc khác từ một câu hỏi khác ở đây nói về giá trị của việc nghiên cứu nhiều ngôn ngữ có mục đích và quy tắc khác nhau:

Lý tưởng nhất, mỗi lập trình viên nên biết một ngôn ngữ từ mỗi lớp. Bạn có thể học được gì:

1. Một ngôn ngữ chính OOP gõ tĩnh: Java, C # (chủ yếu được sử dụng trong phần mềm doanh nghiệp) và C ++ (lập trình hệ thống và các ứng dụng máy tính để bàn phức tạp)
2. Ngôn ngữ OOP dựa trên nguyên mẫu: Javascript (lập trình web phía máy khách)
3. Một ngôn ngữ thủ tục: C (phần mềm nhúng và lập trình hệ thống)
4. Một ngôn ngữ chức năng: Haskell, ML hoặc Lisp (ngôn ngữ chức năng tốt cho phần mềm song song cao).

Một ngôn ngữ lập trình logic (Prolog) có lẽ không hữu ích trong công nghiệp, được sử dụng chủ yếu trong nghiên cứu về AI.

Điều này sẽ giúp mở rộng sự đa dạng của các ý tưởng nảy ra trong đầu khi cố gắng thiết kế một giải pháp.

1. Điều này là hoàn toàn bình thường đối với nhiều người để đưa ra các thiết kế có chất lượng khác nhau. Trước đây tôi đã được mời làm giám khảo các cuộc thi về thiết kế phần mềm, vì vậy tôi đã chứng kiến ​​tận mắt điều này: ngay cả những thiết kế đơn giản nhất cũng dẫn đến các giải pháp có chất lượng khác nhau, tất cả đều đến từ những người thông minh và có kinh nghiệm.
2. Đọc mã nguồn ở mức quá thấp để giúp bạn cải thiện kỹ năng thiết kế của mình: mã giải quyết sự phức tạp ở cấp độ thấp hơn so với thiết kế tổng thể.

Cách tốt nhất để cải thiện phần mềm thiết kế là thiết kế phần mềm ^* . Một cách để làm điều đó là bằng cách xem xét các cuộc thi thiết kế: TopCoder có một kho lưu trữ hơn 100 thiết kế thành phần, hoàn thành với tài liệu thiết kế UML và các triển khai trong Java và / hoặc C #. Chọn một thành phần hoàn thành mà bạn thích, đọc đặc tả yêu cầu và cố gắng đưa ra một thiết kế ban đầu để đáp ứng các yêu cầu. Dành một hoặc hai giờ để suy nghĩ về vấn đề và phác thảo sơ đồ lớp, sau đó mở thiết kế chiến thắng và đọc những gì tác giả đã làm. So sánh thiết kế của anh ấy với thiết kế của bạn, phát hiện sự khác biệt và xem thiết kế của bạn có tốt hơn không. Kiểm tra bảng điểm cạnh tranh để xem các giám khảo đánh giá thiết kế như thế nào. Điều này sẽ cung cấp cho bạn thông tin phản hồi mà bạn cần để quyết định cách cải thiện kỹ năng thiết kế của bạn.

Đừng bỏ công việc của bạn. Tốt hơn là làm việc với một người có kỹ năng tốt hơn bạn, để bạn có thể học hỏi từ người đó.

Nhìn vào thiết kế tốt hơn và xác định tại sao nó tốt hơn. Lấy từ thiết kế được chấp nhận và suy nghĩ về cách bạn có thể áp dụng thiết kế simliar trong các tình huống khác. Một khi bạn biết lý do tại sao nó tốt hơn thiết kế của bạn, thì bạn sẽ biết những gì không phù hợp để thực hiện lần sau khi bạn thực hiện một thiết kế. Nói chuyện với nhà phát triển khác và hỏi làm thế nào anh ta đưa ra thiết kế.

Để cải thiện kỹ năng thiết kế, điều tốt nhất cần làm là tạo ra các thiết kế, sau đó tàn bạo với chính mình trong việc đánh giá chúng và xác định cách chúng có thể được cải thiện. Hãy tự hỏi mình những câu hỏi như: Nó có hoạt động không và nó có đáp ứng yêu cầu về mọi mặt không, có duy trì được không, làm thế nào tôi có thể kiểm tra điều này, nó có gây ra vấn đề về hiệu suất không, khả năng thay đổi và thiết kế sẽ tốt đến mức nào có thể xử lý sự thay đổi. Đọc về các mẫu thiết kế và sau đó cố gắng áp dụng chúng cho các thiết kế của bạn. Tái cấu trúc không thương tiếc sau khi đưa ra một thiết kế nội bộ. Nếu bạn đang thiết kế cơ sở dữ liệu cùng với ứng dụng, hãy đọc nhiều về chuẩn hóa và hiệu suất điều chỉnh db, bạn sẽ học được nhiều về thiết kế cơ sở dữ liệu nếu bạn học cách làm cho cơ sở dữ liệu hoạt động hiệu quả và hiệu quả nhất. Đối với các ứng dụng, hãy nghĩ về các nguyên tắc DRY và RẮN trong việc thực hiện thiết kế của bạn. Đọc về antipotype để biết những điều cần tránh.

Nhận ra một thiết kế tốt hơn là một khả năng quan trọng. Bạn nên khuyến khích điều này khi bạn làm theo một số gợi ý trước đó liên quan đến việc xem xét các thiết kế.

Trên tiêu chí nào bạn đánh giá các thiết kế khác tốt hơn? Có đơn giản và dễ hiểu hơn không? Nó đã cung cấp một lợi thế hiệu suất? Có phải nó mở rộng hơn? Có nhiều nguyên tắc thiết kế như phân rã, trừu tượng hóa, ẩn thông tin và mô đun thành phần mà bạn có thể sử dụng để đánh giá các thiết kế và bạn có thể đã nhận ra.

• Cố gắng đặt tên cho tiêu chí của bạn, hiểu chúng, mở rộng chúng và tái sử dụng chúng khi bạn nhìn vào các thiết kế khác. Khi bạn tự thiết kế mọi thứ, hãy biến nó thành một phần trong quy trình của bạn để sử dụng các tiêu chí đó và có ý thức đo lường các thiết kế của bạn chống lại chúng. Sau đó, hãy chuẩn bị để sửa đổi hoàn toàn hoặc loại bỏ thiết kế của bạn nếu nó không đáp ứng các tiêu chí của bạn.

Bạn sẽ lấy ý tưởng về các nguyên tắc khác nhau cho thiết kế từ một số nguồn sau: http://www.cs.wustl.edu/~schmidt/PDF/design-principles4.pdf Thiết kế phần mềm trên wikipedia Google "Nguyên tắc thiết kế phần mềm"

• Hiểu các mô hình khác nhau cho thiết kế phần mềm, chẳng hạn như Thiết kế hướng đối tượng hoặc Thiết kế chức năng hoặc Thiết kế phân tích có cấu trúc. Đây có thể là những tư duy hoàn toàn khác nhau để tiếp cận một nhiệm vụ thiết kế và mỗi người đều có những lĩnh vực mà họ nổi trội. Tìm hiểu những điều này như là công cụ cho hộp công cụ của bạn. http://userpages.umbc.edu/~khoo/survey2.html

• Hãy chắc chắn rằng bạn đang tách biệt thiết kế với việc triển khai, cố gắng lập sơ đồ những thứ bạn thấy là thiết kế tốt, để tách biệt ngôn ngữ và chi tiết triển khai khỏi các nguyên tắc thiết kế cấp cao hơn. Và để phát triển "con mắt thiết kế" và khả năng giao tiếp của bạn.

• Cuối cùng, nhưng có lẽ quan trọng nhất, đọc rộng rãi là một công cụ rất tốt - có nhiều điều thú vị từ phân tích Fractals đến Bayesian đến Logic mờ cho Xử lý ngôn ngữ tự nhiên, có thể cung cấp thức ăn cho những ý tưởng sẽ xuất hiện sau đó và bất ngờ. Với trang web, bạn có thể kiểm tra các chủ đề xa và rộng, chỉ để bạn giải trí và chỉnh sửa và nó sẽ có lợi. Bạn không cần phải trở thành chuyên gia, chỉ cần làm quen với các điều khoản và ý tưởng.

Hãy vui vẻ - đừng làm điều đó nếu bạn không thích nó ít nhất một chút!

Vâng, bạn đã thực hiện bước đầu tiên. Bạn thừa nhận rằng bạn có một cái gì đó để học, rằng công việc của đồng nghiệp của bạn tốt hơn của bạn và bạn muốn học hỏi và cải thiện.

Bước thứ hai là phân tích. Nhìn vào công việc của anh ấy và đừng chỉ nói rằng nó tốt hơn; Tìm hiểu tại sao nó tốt hơn. Hãy tìm những chi tiết cụ thể và những điểm mà anh ấy đã làm tốt hơn.

Một khi bạn hiểu điều đó, hãy trích xuất các nguyên tắc đằng sau nó. Đặt câu hỏi như thế này:

• Điều gì về thiết kế này là tốt hơn so với thiết kế của tôi?
• Đây có phải là một cái gì đó cụ thể cho thiết kế này, hoặc nó là một nguyên tắc chung có thể được áp dụng cho các thiết kế khác trong tương lai?
• Nếu đó là một nguyên tắc chung, giới hạn của nó là gì? Khi nào thì không nên làm mọi thứ theo cách này? (Điều này rất quan trọng. Nó giúp bạn không coi một số ý tưởng hữu ích là một cây búa vàng , ngay cả trong trường hợp không phù hợp.)

Cố gắng tự mình tìm ra mọi thứ, bởi vì bạn sẽ nội tâm hóa các ý tưởng tốt hơn nếu bạn đưa ra chuỗi lý luận dẫn bạn đến kết luận, nhưng cũng nói chuyện với đồng nghiệp của bạn để đảm bảo bạn sẽ hiểu được mọi thứ đúng. (Bạn không muốn phạm sai lầm trong lý luận của mình và tiếp thu một nguyên tắc tồi tệ.) Và hãy thoải mái nhờ đồng nghiệp giúp đỡ nếu bạn không thể tìm ra. Lập trình là một môn học mà sự khiêm tốn có xu hướng được tôn trọng, và rất nhiều lập trình viên sẽ nhảy vào cơ hội để dạy cho ai đó một cái gì đó mới, có lẽ là một phần lớn của lý do tại sao StackOverflow lại phát triển quá nhanh.

Tôi cũng muốn thêm (ngoài những câu trả lời hay) rằng còn nhiều điều hơn thế "Anh ấy có thể tạo ra một thiết kế tốt hơn tôi". Các câu trả lời khác tập trung vào cách bạn có thể trở nên tốt hơn trong Thiết kế, tất cả đều tốt và ... nhưng ...

Tôi đặt cược tiền rằng BẠN có thể làm điều gì đó tốt hơn so với đồng nghiệp của bạn. Không phải để tạo ra một trận đấu tức giận hay bất cứ điều gì (Bạn có thể làm Y tốt hơn không? Làm phiền bạn, tôi có thể làm X tốt hơn!), Nhưng để chỉ ra sự thật rằng mọi người đều có điểm mạnh và điểm yếu.

Tại công việc của tôi có 4 nhà phát triển. Có những lúc hai "lập trình viên" chính có thể tạo ra những thứ khiến tôi rơi vào bụi bặm. Làm cho đầu tôi quay cuồng cố gắng quấn đầu tôi xung quanh sáng tạo của họ.

Nhưng tôi giỏi SQL hơn và viết kịch bản dòng lệnh so với hiện tại và có thể tự động hóa những thứ khiến THEM rơi vào bụi bặm.

Họ có tốt hơn tôi không? Trong một số khu vực chắc chắn. Chết tiệt, ở rất nhiều khu vực họ - Tôi là nhà phát triển cơ sở tại cửa hàng của tôi cho đến nay và cá nhân họ có nhiều năm kinh nghiệm với tôi. Mặc dù có nhiều năm kinh nghiệm, tôi vẫn tốt hơn ở một số khu vực so với họ.

Ngừng tập trung vào thực tế rằng ai đó giỏi X hơn bạn. Người đó, không cần cố gắng hay thậm chí nghĩ về nó, có thể có thể thiết kế cho bạn ngay cả sau khi bạn thực hành nó trong 10 năm tới. Không phải là bạn không nên khắc phục điểm yếu của mình, nhưng hãy nhớ rằng với mỗi điểm mạnh đều có điểm yếu.

Tập trung vào cả hai - Điểm mạnh và điểm yếu - của bạn và đồng nghiệp.

Trong mọi khía cạnh của cuộc sống, bạn sẽ tìm thấy những người không tốt bằng bạn, cũng như những người giỏi hơn bạn, đặc biệt là chỉ sau "một vài năm" kinh nghiệm.

Bạn phải học hỏi từ mọi người.

Đừng cảm thấy tồi tệ. Có thể bạn đồng nghiệp là một lẽ tự nhiên. Bạn nên chúc mừng anh ấy một cách chân thành và học hỏi nhiều nhất có thể từ anh ấy.

Đừng để sự chuyên nghiệp ghen tị giữa bạn và cơ hội học hỏi.

1. Một vài năm thực sự không nhiều. Và hơn là có những người có quan điểm thiết kế cấp cao tốt hơn hoặc tồi tệ nhất. Ví dụ, tôi đã biết những người có khả năng viết thuật toán phức tạp cho các chương trình cấp thấp trong nháy mắt nhưng không có khả năng hiểu các thiết kế và khái niệm cấp cao hơn như sự gắn kết và phụ thuộc. Tuy nhiên đây không phải là một trạng thái thực tế. Cả hai bạn đều có thể trở nên tốt hơn ở thiết kế cấp cao hơn (đọc một vài cuốn sách, thử một vài mẹo ở nhà, v.v.) và bạn cũng có thể khám phá ra rằng ở các lĩnh vực lập trình khác, lập trình viên đồng nghiệp của bạn kém hơn. Ngoài ra, nếu bạn nghĩ rằng bạn có cùng trình độ cả về kinh nghiệm và kiến ​​thức về công nghệ, điều này có thể đã có một tình huống ngẫu nhiên. Lần sau có thể bạn có ý tưởng thiết kế tốt hơn. Ngoài ra, thay vì bỏ công việc của bạn, hãy nắm lấy cơ hội này và học hỏi từ đồng nghiệp của bạn. Lần tới, hãy cùng nhau thiết kế, cố gắng nắm bắt bí mật, suy nghĩ của anh ấy Lập trình giống như một nghề thủ công, nó được học bằng cách làm và xem người khác làm việc đó.

2. Kỹ năng thiết kế chủ yếu đi kèm với kinh nghiệm và sau khi bạn đọc một vài cuốn sách quan trọng. Tôi muốn giới thiệu cho bạn những điều sau đây:

   • Robert C. Marting - Nguyên tắc, mô hình và thực tiễn nhanh nhẹn (có 2 phiên bản, một trong Java và một trong C #. Không quan trọng bạn chọn cái nào, các ý tưởng và nguyên tắc có thể được áp dụng cho bất kỳ đối tượng nào được định hướng - và không chỉ - mã nguồn)
   • Hơn, Robert C. Marting có 2 cuốn sách thú vị khác: Clean Code và The Clean Coder
   • Ngay cả khi Martin bao gồm tất cả các mẫu thiết kế hiện đại trong cuốn sách đầu tiên của mình, bạn muốn tìm kiếm cuốn sách mẫu thiết kế ban đầu của Gang of Four.
   • Cuối cùng, có những cuốn sách khác được đánh giá cao hiện nay: Phần mềm hướng đối tượng phát triển được hướng dẫn bởi các bài kiểm tra, hoặc tái cấu trúc bởi M. Feathers (tôi nghĩ), hoặc Viết các trường hợp sử dụng hiệu quả của A. Cockburn và một vài điều nữa bạn sẽ khám phá trên đường đi.

Không có cuốn sách nào trong số này là viên đạn ma thuật, nhưng đọc 2 đề xuất đầu tiên có thể sẽ thay đổi quan điểm và nhận thức của bạn về lập trình mãi mãi.

Đừng để nó đến với bạn. Nếu bạn có nhiều năm kinh nghiệm sửa lỗi và tạo các chương trình nhỏ, đó là những gì bạn sẽ nổi trội. Đồng nghiệp của bạn có thể có nhiều năm kinh nghiệm thiết kế các dự án lớn hơn.

Làm quen với các bit cơ bản là vô cùng tiện dụng, nhưng nếu bạn muốn thiết kế tốt hơn, bạn sẽ phải thiết kế một vài dự án. Lặp lại cho đến khi kỹ năng chìm vào.

Nói tóm lại, "năm kinh nghiệm" không phải lúc nào cũng tương đương. Đi làm cho năm của bạn có giá trị một cái gì đó.

"Trở nên tốt hơn" thường ngụ ý đo lường thiết kế hoặc mã của bạn dựa trên thứ gì đó / ai đó tốt hơn, cẩn thận so sánh những gì khác biệt, học hỏi từ những khác biệt đó và liên tục cố gắng cải thiện các thiết kế trong tương lai của bạn dựa trên điều đó. Cảm thấy quá tệ khi phát hiện ra rằng bạn cần tìm hiểu thêm sẽ làm chậm quá trình có lợi này. Nếu bạn chuyển đến một nơi nào đó nơi không có người (hoặc tài nguyên khác) đôi khi có thể hoặc luôn cung cấp cho bạn sự so sánh tốt hơn, bạn có thể mất cơ hội này để tìm hiểu và làm chậm quá trình đặt cược của mình tốt hơn.