Những yếu tố nào sẽ ảnh hưởng đến cách tôi xác định khi nào nên từ bỏ một dự án nhỏ với một người bạn? [đóng cửa]


30

Tôi đã thấy mình ở một vị trí khó khăn vào cuối. Đã làm việc với một trò chơi với một người bạn lập trình được gần 8 tháng nay. Cả hai chúng tôi bắt đầu là người mới lập trình vào khoảng tháng 8 năm ngoái, anh ấy là sinh viên CS năm thứ 2, tôi là một công nghệ hỗ trợ CNTT bằng thương mại và là một lập trình viên tự học với vô số sách và đăng ký trực tuyến.

Vấn đề mà tôi thường xuyên thấy là khi chúng ta viết ra một đoạn mã, nó thường sẽ bị hack cùng nhau, có nhiều thất bại và nếu đó là một khái niệm hoàn toàn mới đối với một trong chúng ta, đầy những giải pháp ngây thơ. Điều này là tốt, chúng tôi đang học, tôi hy vọng cả hai mã của chúng tôi sẽ bị hack một chút trên các linh hồn hoặc vượt qua thứ hai. Vấn đề thể hiện chính nó khi thực sự sửa chữa và tái cấu trúc những hành vi bị hack cùng nhau.

Đối tác của tôi sẽ giữ hành vi mới của anh ấy với nhau, từ chối xem bất kỳ lỗi nào ngay khi nó bắt đầu hoạt động. Yêu cầu sự hoàn hảo gần như từ một phần cấu trúc, tôi thậm chí không thể cố gắng sử dụng ngay cả khi nó có ý kiến ​​và các phương thức & trường được đặt tên thích hợp. Cho dù tôi có cố gắng thế nào, tôi cũng không thể khiến anh ấy nhìn thấy những lỗ hổng rõ ràng rõ ràng sẽ ngăn chặn mọi thay đổi hoặc mở rộng hành vi mà không phá vỡ hoàn toàn và mọi thứ được kết hợp chặt chẽ với chúng cũng có thể ở cùng một lớp. Các giải pháp bị tấn công liên tục bị tấn công, các thiết kế được suy nghĩ kém sẽ giữ nguyên vị trí của chúng khi lần đầu tiên được hình thành và thử nghiệm.

Tôi dành nhiều thời gian để trông nom mã mới như tôi tự viết nó, tôi không biết phải làm gì. Đối tác của tôi đã mất nó tối nay, và nói rõ rằng dù thế nào, bất kể điểm chuẩn, bất kể thông lệ chung, bất kể bằng chứng không thể bác bỏ, mã của anh ta sẽ giữ nguyên như cách anh ta làm trước. Ngay cả khi toàn bộ cuốn sách đã được viết về lý do tại sao bạn muốn tránh làm điều gì đó, anh ta sẽ từ chối thừa nhận tính hợp lệ của họ khi cho rằng đó chỉ là ý kiến ​​của ai đó.

Tôi có hứng thú với dự án của chúng tôi, tuy nhiên tôi không chắc liệu tôi có thể tiếp tục làm việc với đối tác của mình không. Tôi dường như có ba lựa chọn mở cho tôi.

  • Ngừng quan tâm về chức năng cơ sở mã hóa qua điểm biên dịch, và chỉ giải quyết việc cố gắng duy trì và phân tích hành vi hầu như không đi khập khiễng. Hy vọng rằng một khi mọi thứ bắt đầu bị phá vỡ nghiêm trọng, anh ta sẽ thấy điều đó và cố gắng làm nhiều hơn là chỉ đặt một chiếc băng đô trên thiết kế thiếu sót cơ bản.
  • Theo kịp các cuộc tranh luận bất tận về các vấn đề đã được tìm ra một thập kỷ trước bởi các cá nhân có khả năng hơn nhiều.
  • Dừng lập trình cho dự án này, từ bỏ gần 10.000 dòng mã của tôi và vô số thời gian dành cho thiết kế và tự mình thử và tìm một dự án mới.

Cách tiếp cận nào tôi có thể thực hiện để xác định xem có đáng để tiếp tục với dự án này với người này không? Hay những yếu tố nào sẽ ảnh hưởng đến quyết định của tôi? Chúng tôi đã viết rất nhiều mã và tôi không muốn từ bỏ điều này trừ khi cần thiết.


3
Điều gì về việc đưa ra một hướng dẫn phong cách mã hóa đã được thống nhất và một quy trình xem xét mã? Tránh bất kỳ vấn đề gây tranh cãi, chỉ cần đưa vào đủ tiêu chuẩn là bạn có thể đồng ý với nó.
Brandin

25
Tùy chọn thứ tư (nếu theo giấy phép cho phép): phân tách mã và tiếp tục tự làm việc.
Robert Harvey

4
Mã được cấp phép như thế nào? Bạn có thể rẽ nhánh nó và tiếp tục với người khác?
Jaydee

14
Như @enderland đề cập trong câu trả lời của anh ấy, có một lá cờ đỏ hoàn toàn to lớn trong những gì bạn đã viết: "Đối tác của tôi đã mất nó tối nay, và nói rõ rằng dù thế nào, dù là điểm chuẩn, bất kể thông lệ chung, bất kể thông lệ bằng chứng không thể chối cãi, mã của anh ấy sẽ giữ nguyên như cách anh ấy làm trước. " Nếu bạn có thể thoát khỏi điều này, hãy làm như vậy. Bất cứ ai thực sự có giá trị làm việc cùng sẽ có sự khiêm tốn để chấp nhận rằng đôi khi họ sẽ nhận được những điều sai trái.
Richard J Foster

3
Bất kể bạn quyết định điều gì, dòng mã 10k không bị mất: hãy nghĩ về những gì bạn học được từ việc viết chúng; nghĩ về niềm vui mà bạn có trong thời gian viết mã; và, áp dụng những gì bạn đã học được trong lần lặp thứ ba / thứ tư / thứ tư / n + 1 thậm chí có thể làm cho nó tốt hơn phiên bản hiện tại. Bên cạnh đó nếu bạn biết viết những dòng mã 10k, bạn có thể viết những dòng 10k trong một thời gian tương đối ngắn; Thông thường, việc biết phải viết gì để khiến mọi thứ hoạt động là điều cần nhiều thời gian nhất.
Kasper van den Berg

Câu trả lời:


26

Vận chuyển, mã không hoàn hảo tốt hơn mã hoàn hảo trên bảng trắng không bao giờ được giao.

Điều đó đang được nói ...

Những người trong số bạn có nhiều kinh nghiệm hơn, hoặc đã từng ở trong tình huống tương tự. Bạn đã làm gì? Bạn muốn giới thiệu tôi làm gì?

Tôi sẽ xem xét những điều sau đây.

  • Mục đích của dự án này là gì? Vui vẻ? Tiền bạc? Học?
    • Bạn có thực sự hoàn thành mục đích này?
  • Là người này thực sự cho phép bạn thực hiện tốt hơn các mục tiêu của bạn?
  • Làm thế nào gần bạn thực sự vận chuyển?
  • Những vấn đề này có ngăn cản bạn khởi chạy không? Hay họ là một vấn đề của niềm tự hào cá nhân?
  • Có lợi ích gì khi làm việc với ai đó trên cơ sở tự nguyện khi điều đó làm nản lòng?

Dừng lập trình cho dự án này, từ bỏ gần 10.000 dòng mã của tôi và vô số thời gian dành cho thiết kế và tự mình thử một dự án mới

Hãy xem xét những điều trên, cố gắng suy nghĩ thông qua các công việc bổ sung cần thiết.

Bạn cần tìm ra các ưu tiên của mình và xác định xem các vấn đề liên quan đến làm việc với người này có đáng không. Chúng tôi không thể tìm ra điều này cho bạn.

Đối tác của tôi đã mất nó tối nay, và nói rõ rằng dù thế nào, bất kể điểm chuẩn, bất kể thông lệ chung, bất kể bằng chứng không thể bác bỏ, mã của anh ta sẽ giữ nguyên như cách anh ta làm trước.

Bạn biết bạn không muốn làm việc với kiểu người này.

Bạn đang thực hiện một dự án như thế này có lẽ là vì bạn muốn học lập trình và tìm sự thanh lịch trong chính nghề.


1
Cảm ơn bạn đã trả lời của bạn. Tôi đang hoàn thành mục đích vui chơi (khi không đấu đá) và học tập. Thời tiết bất kỳ số tiền nào được thực hiện là một câu chuyện hoàn toàn khác. Anh ấy giúp tôi hoàn thành mục tiêu của mình, tuy nhiên tôi tin rằng tôi vẫn có thể tự mình hoàn thành chúng, anh ấy giúp tôi có động lực. Trò chơi là một ví dụ tuyệt vời về tính năng creep, tôi thực sự không biết khi nào nó có thể xuất xưởng. Đối tác của tôi đã cố gắng thay đổi từ 2D sang 3D trong nhiều tháng nay, tôi từ chối vì chúng tôi đã vượt quá phạm vi của chúng tôi từ lâu.
Douglas Gaskell

1
Tôi sẽ sẵn sàng bỏ dự án, nếu nó chỉ là của riêng tôi thì nó đã bị bỏ cách đây vài tháng. Yếu tố thúc đẩy của tôi để tiếp tục là có người khác làm việc cùng, ngay cả khi việc đấu đá khiến tôi nghi ngờ điều đó vài ngày. Điều duy nhất kìm hãm tôi từ bỏ nó là một tình bạn như kết nối với anh ta bên ngoài tiền mã hóa, tôi thà tránh ném nó với dự án. Tất nhiên đây không phải là một lời giải thích dựa trên logic, vì cảm xúc cá nhân của họ liên quan đến nó thực sự làm mờ đi khả năng ra quyết định của tôi.
Douglas Gaskell

1
cách nhanh nhất để mất một người bạn là làm việc với họ như bình đẳng!

58

Đây có thể là một điều văn hóa. Trong một số nền văn hóa, thừa nhận rằng bạn đã phạm sai lầm là chưa từng nghe thấy và yêu cầu ai đó thừa nhận mắc lỗi là về điều thô lỗ nhất bạn có thể làm. Nếu đó là tình huống đó, chạy đi.

Theo kinh nghiệm của tôi với những người rất thông minh, nếu bạn nói với họ rằng điều gì đó họ đang làm không hoàn hảo, họ sẽ (1) cung cấp cho bạn một lý do chính xác và dễ hiểu tại sao những gì họ đang làm thực sự đúng, (2) nói bạn biết rằng họ đã sai, nhưng họ không có thời gian để sửa nó vì những ưu tiên, hoặc (3) cảm ơn bạn đã chỉ ra và sửa nó.

Từ chối tìm hiểu là về thuộc tính tồi tệ nhất mà một nhà phát triển phần mềm có thể có. Để anh ấy đến đó. Cuộc sống quá ngắn ngủi và quý giá để lãng phí thời gian của bạn cho anh ấy.


Cảm ơn Gnasher, tôi thấy # 2 định kỳ, mặc dù chúng tôi không có lịch trình thực tế nên tôi không chắc mức độ hợp lệ của phản hồi đó. Tôi sẽ ngủ về điều này và xem những gì tôi nghĩ trong sáng, điều này cần rất nhiều sự cân nhắc trước khi đưa ra quyết định.
Douglas Gaskell

1
"Nếu đó là tình huống đó, hãy chạy đi." - và nói chung, nếu bạn không thể đạt được sự đồng thuận, mục tiêu của bạn là gì thì bạn không thể hợp tác với ai đó. Có vẻ như anh ấy sẽ không đồng ý cho bạn thay đổi mã "của anh ấy", bất kể lý do.
Steve Jessop

Chà, dường như áp lực thời gian không phải là lý do để từ chối những thay đổi.
gnasher729

1
Đây là một câu trả lời tuyệt vời. Bạn không thể ép ai đó thay đổi cách của họ! Tuy nhiên, có vẻ như có rất nhiều thời gian và nỗ lực dành cho dự án của anh ấy cũng như của bạn. Suy nghĩ của tôi có thể là anh ta có thể không muốn thay đổi mã của mình vì anh ta không hiểu cách mà bạn nghĩ nó nên được thực hiện. Đó là hoặc anh ấy đang đau đầu, nhưng nếu anh ấy không hiểu điều đó, hãy cố gắng nhớ rằng anh ấy có thể thất vọng và nghĩ rằng bạn đang "nói xấu" với anh ấy, mặc dù bạn có ý rất tốt. Lời khuyên của tôi là hãy cố gắng nói chuyện với anh ấy khi cả hai cùng quyết định.
zfrisch

^ + Rất dễ bị ai đó xúc phạm khi bạn bắt đầu ở cùng cấp độ và họ vượt qua bạn về kỹ năng. Tôi không nói rằng đó là điều chắc chắn, nhưng chắc chắn có vẻ như nó có liên quan đến nó.
zfrisch

12

Có thể cách dễ nhất là đưa người khác vào dự án - hoặc bạn sai và cơ sở mã của anh ta quá thông minh đối với bạn, hoặc bạn đúng và quá thông minh cho mọi người. Bạn sẽ sớm tìm ra và sẽ nhận được bản sao lưu nếu nó trở thành rác, mã hóa, cấp mã lập trình viên cơ sở.

Mặt khác, một sản phẩm làm việc có giá trị bất kỳ số năm mã tinh chỉnh, thanh lịch, rõ ràng. Tạo trò chơi, vận chuyển nó, sau đó bỏ đi - để anh ta duy trì nó và không làm việc trên v2.


2
Cảm ơn bạn đã trả lời. Hài hước khi bạn đề cập đến điểm đầu tiên của bạn. Anh ta đang cố gắng tìm và đưa vào một lập trình viên mới làm quen mà anh ta có thể dạy để giúp đỡ cho dự án. Tôi chỉ có thể mong đợi điều này sẽ trở nên khủng khiếp nếu có hai người theo cùng một kiểu hack và quên. Tôi thích tùy chọn thứ hai, thực hiện nó, vận chuyển nó, và sau đó rời khỏi nó. Vấn đề tôi có thể gặp phải là chúng tôi đang bán thời gian mặc dù tạo ra một LLC để chúng tôi có một cái tên để vận chuyển trò chơi của chúng tôi theo. Cả hai sử dụng sẽ có 50% chia sẻ tất nhiên. Tuy nhiên, tôi chỉ có thể hoàn thành nó và sau đó tiếp tục. Dự án lớn, có thể là một thời gian.
Douglas Gaskell

20
Bạn không trong bất kỳ trường hợp nào muốn tham gia một mối quan hệ kinh doanh ràng buộc về mặt pháp lý với một người như thế.
gnasher729

3
@ douecraftg14b mang đến một đàn em để dạy .. đứa trẻ tội nghiệp. Đề nghị bạn mang đến một anh chàng có kinh nghiệm "vì anh ta sẽ tăng tốc nhanh hơn nhiều và giúp hoàn thành sản phẩm". Đặt mục tiêu của bạn trên một dòng kết thúc - hoặc cả hai bạn có ý định làm việc theo sở thích này mãi mãi và mãi mãi? (thấy điều đó xảy ra, cho đến khi nó bị hủy bỏ)
gbjbaanb

Tôi có kế hoạch hoàn thành nó, chắc chắn. Mặc dù tôi tin rằng đó là một dự án quá lớn để giải quyết như là lần đầu tiên của chúng tôi. Nó bắt đầu như một thiết kế đơn giản, nó không phải là bất cứ nơi nào gần quy mô như bây giờ. Ranh giới của phạm vi của chúng tôi liên tục bị đẩy bởi tính năng creep bởi đối tác của tôi, tôi có phần đáng trách vì điều đó vì tôi cho phép nó xảy ra và thậm chí đồng ý với một số tính năng. Phạm vi là đến mức nếu để yên, có lẽ chúng ta đang xem xét hoàn thành trong vòng một năm. Rất may với cách tôi đã lập trình nó, các bộ phận có thể dễ dàng được đưa ra và đưa vào các dự án khác sau này.
Douglas Gaskell

4
Hãy nghĩ về mã như thuộc về dự án, không phải của bạn. Nếu bạn có quyền sở hữu chung của sản phẩm, bạn có thể sử dụng lại tất cả các mã cho dự án tiếp theo của bạn. Nếu bạn không biết ai sở hữu cái gì, thì hãy thảo luận ngay bây giờ. Chúc may mắn.
gbjbaanb

9

Dưới đây là một số ý tưởng ngay cả khi một số trong số chúng là loại trừ lẫn nhau.

  • Trách nhiệm nguồn riêng. Nếu bạn làm việc trên Mô-đun A và anh ấy trên Mô-đun B, bạn có thể cạnh tranh với các phong cách khác nhau của mình. Là anh ấy phát hành các tính năng làm việc thường xuyên? Anh ta có đạt đến điểm cần viết lại mã từ đầu không? Tái cấu trúc mã từ các mô-đun của bạn và không chạm vào anh ấy,

  • Hãy để anh ta thực hiện việc duy trì mã tồi tệ nhất của mình. Nếu anh ta làm điều đó thành công, bạn đã tránh được một nhiệm vụ khủng khiếp. Nếu anh ta không thể, anh ta sẽ cảm thấy đau.

  • Xem xét nó từ một quan điểm người dùng hoặc kinh doanh. Trong một số trường hợp, bạn chỉ cần một sản phẩm khả thi mà google hoặc Microsoft có thể mua. Mặt khác, bạn đang tung ra một sản phẩm để tiếp thị và hỗ trợ hàng ngàn khách hàng với mã lỗi hoặc bị hack sẽ là địa ngục. Không giống nhau nếu mã của bạn điều khiển máy bay không người lái bằng tên lửa hạt nhân hoặc tạo video vui vẻ cho thanh thiếu niên.

  • Anh ấy làm các lớp, bạn làm các bài kiểm tra. Tái cấu trúc mã với các bài kiểm tra dễ dàng và an toàn hơn. Bằng cách này, bạn sẽ không cần phải nhìn vào bên trong mã chỉ là thanh Junit. Điều này giả định rằng A) bạn đang lập trình kiểm tra, B) mã đồng nghiệp của bạn có thể kiểm tra được. Nếu bạn thấy khó xây dựng các bài kiểm tra trong giai đoạn mã hóa thì sẽ tệ hơn.

  • Đi cùng nhau để đào tạo hoặc các sự kiện. Khi bạn không biết cách đúng là khá tự nhiên, hãy sử dụng cách duy nhất bạn biết. Xem mã của người khác có thể không giải quyết được mọi thứ nhưng sẽ không bị tổn thương khi thử.

  • Tìm điểm mạnh bổ sung của bạn. Tái cấu trúc đôi khi có thể là niềm vui. Nếu anh ta viết những thứ mà ít nhất là công việc bạn có thể thực hiện tái cấu trúc. Ông có thể làm gai để khám phá các giải pháp mà không kết thúc trong mã sản xuất.

  • Anh ta có thể không muốn viết lại mã nhưng anh ta có thể đồng ý viết mã mới tốt hơn. Tôi hiểu rằng viết lại là khó khăn, nhàm chán và có thể phá vỡ mọi thứ. Phát triển một số đảo chất lượng. Bằng cách này, anh ta sẽ có những ví dụ tốt về cách làm việc.

  • Sử dụng quy tắc trinh sát cậu bé . Đừng để những thứ còn nguyên vẹn trừ khi bạn cần phải làm việc với nó. Nếu một mô-đun được viết xấu nhưng hoạt động và không cần thay đổi, hãy để nó như thế. Nếu bạn cần sửa một lỗi hoặc hoàn thành một tính năng, hãy cải thiện nó một chút. Sau một thời gian, 20% số lớp bạn thay đổi 80% sẽ được cải thiện. Nhiều hòn đảo chất lượng.

Chúng tôi không thể đề xuất đâu là giải pháp tốt nhất mà không biết cả hai bạn. Chúc may mắn.


4

Ok, đây là một câu trả lời bạn có thể sẽ không thích.

Không 'sửa' mã trừ khi không thực hiện được tính năng.

Đây là lý do của tôi. Bạn có lẽ đang cố gắng kiếm tiền. Để kiếm tiền, bạn phải vận chuyển các tính năng hoàn thành một cách nhanh chóng. Không ai sẽ trả tiền cho bạn nhiều hơn cho một trò chơi máy tính 'được mã hóa tốt'.

Hầu hết các công ty đều có cùng một vấn đề. Tái cấu trúc mã hiện có để làm cho nó 'tốt hơn', đôi khi còn khách quan hơn về tốc độ hoặc độ tin cậy HOẶC viết các tính năng mới.

99% thời gian họ chọn viết các tính năng mới vì kết quả của phân tích lợi ích chi phí đơn giản.


15
Điều này nằm trong toàn bộ tranh luận về "nợ kỹ thuật", phải không? Khi bạn viết tính năng mới đó (hoặc sửa đổi một tính năng hiện có), nó có mất thời gian gấp ba lần và tạo ra số lỗi gấp mười lần nếu bạn theo kịp cấu trúc lại của mình không? Nếu vậy, có lẽ bỏ qua tái cấu trúc là một nền kinh tế sai lầm.
Ben Aaronson

1
Bạn sẽ nghĩ như vậy, nhưng tôi đã làm việc trong rất nhiều công ty thành công và tôi (hầu như) không bao giờ thấy tái cấu trúc ở mức ưu tiên cao. Kết luận của tôi là nó chỉ đơn giản là không trả tiền.
Ewan

Điều đó đủ công bằng và tôi chắc chắn có một loạt ý kiến ​​về vấn đề này, có vẻ như không giải quyết theo cách này hay cách khác là một thiếu sót đáng kể từ câu trả lời. Ngoài ra tôi có thể sai nhưng đọc giữa các dòng trong câu hỏi, tôi nghĩ rằng các mã xấu OP đang lo lắng về có thể cách tồi tệ hơn so với loại mã bạn đang suy nghĩ về.
Ben Aaronson

heh nhưng cũng có vẻ như chi phí để thực hiện các thay đổi là rất cao. Trong câu trả lời của tôi, tôi cố gắng đưa ra mục tiêu 'bạn có phải vì tiền không?' trả lời, cộng với quan điểm chủ quan của tôi về sự cân bằng của xác suất nằm ở đâu
Ewan

1
Điều này là hợp lý trong một số trường hợp, nhưng nếu "mã làm việc" của ai đó khiến người khác dành gấp đôi thời gian cho mã của họ hoặc tích hợp các hệ thống với nhau hoặc công việc trong tương lai, thì đó không còn là một quyết định đơn giản "giao hàng không giao hàng". Rất nhiều dự án quy mô lớn chết họ không đưa ra quyết định thực hiện đúng hơn là nhanh.
thúc vào

3

Tôi thích tất cả các câu trả lời cho đến nay. Lấy một trong những điểm từ câu trả lời của enderland :

Có lợi ích gì khi làm việc với ai đó trên cơ sở tự nguyện khi điều đó làm nản lòng?

Tôi muốn dành thời gian này để cắm cho trao đổi ngăn xếp mã xem lại . Đó là một nơi tuyệt vời nơi bạn có thể nhận được mã của mình được các chuyên gia phê bình. Và thành thật mà nói, rất nhiều đánh giá mã có rất hữu ích cho những người liên quan - người hỏi, người trả lời và những người vấp ngã và đọc chúng. Bạn hiếm khi nhận được những đánh giá hữu ích như vậy trong một môi trường chuyên nghiệp (có thể chỉ là trường hợp tại những nơi tôi đã làm việc vì bất kỳ lý do gì).

Lời khuyên của tôi là gửi một số mã của bạn để xem xét. Tôi sẽ không đề nghị sử dụng nó như đạn để chứng minh anh chàng này sai - tôi nghi ngờ anh ta sẽ thuộc nằm lòng - nhưng bạn có thể nhận được thông tin rất hữu ích cả về mã bạn đã viết và mã anh ta viết. Tôi khuyên bạn nên gửi các đoạn mã mà hai bạn chiến đấu nhiều nhất. Trong tất cả khả năng, cả hai bạn đều sai ở một mức độ nào đó và bạn có thể sử dụng đánh giá như một cách để một bên thứ ba khách quan bước vào. Điều này sẽ thực hiện một số điều:

  • Bạn có thể ngắt kết nối với tình cảm căng thẳng.

  • Bạn nhận được lời khuyên chuyên nghiệp thời gian thực. Một sự thúc đẩy lớn cho những gì bạn đang học.

  • Ai đó sẽ nói với bạn rằng bạn sai. Điều này là tốt, bởi vì bất cứ ai lập trình trong bất kỳ khoảng thời gian nào cũng sẽ nghe thấy điều này. Bạn có thể xử lý nó kém như anh chàng này bạn đang làm việc hoặc bạn có thể học cách đối phó với nó.

Tôi nghĩ rằng nếu bạn sử dụng mã đánh giá đúng cách, bạn sẽ có được nhiều thứ bằng cách đối phó với người cực kỳ bực bội này. Và nó tương tác hơn nhiều so với một cuốn sách hoặc trang web có nội dung "làm điều này, bởi vì đó là cách đúng đắn hầu hết thời gian".

Tương tự như vậy, có trao đổi ngăn xếp nhà phát triển trò chơi . Không quá nhiều nơi để đăng mã để xem xét, nhưng để hỏi về các khái niệm / ý tưởng mà bạn đang đấu tranh. Một lần nữa, nơi đó là rất hữu ích cho tất cả tham gia.

Bạn có thể đã thấy cả hai trang web này trước đây; Tôi chỉ muốn chắc chắn rằng chúng là một phần của bộ công cụ của bạn.


2

Nghe có vẻ khá vô vọng. Tôi có lẽ sẽ từ bỏ và tiếp tục nếu tôi cảm thấy về nó như bạn làm; chắc chắn sẽ đến lúc để đi và bạn có thể ở đó.

Nếu bạn chưa sẵn sàng bỏ đi, bạn cần tìm cách đi đến thỏa thuận tốt hơn về quy trình của mình. Có vẻ như bạn có các tiêu chuẩn mã hóa, nhưng không phải là tiêu chuẩn theo thỏa thuận. Lần tới khi bạn đến ngã tư, lần sau bạn muốn khỉ với một chút mật mã và bạn của bạn muốn để nó một mình, hãy quay lại một cuộc trò chuyện dọc theo các dòng sau:

douecraft: Tôi muốn thay đổi nó bởi vì X, ở ngay trong hướng dẫn của chúng tôi.

bạn thân: nó ổn như thế nào

douecraft: Vì vậy, bạn đang nói rằng chúng ta nên thay đổi các hướng dẫn?

bạn thân: Không, tôi chỉ nghĩ nó ổn như thế nào thôi.

douecraft: Vậy hướng dẫn là gì?

bạn thân: tôi không biết - bạn đã viết chúng.

douecraft: Bạn sẽ viết hướng dẫn gì?

bạn thân: tôi sẽ không viết hướng dẫn Đúng là phí thời gian.

douecraft: Vì vậy, chúng ta chỉ nên vứt bỏ các hướng dẫn và viết bất cứ điều gì tào lao chúng ta nghĩ lúc đó?

bạn thân: Đây không phải là tào lao.

douecraft: Nó có hoàn hảo không? Có lý tưởng không?

bạn thân: Nó hoàn thành công việc; Hãy chuyển sang tính năng tiếp theo.

douecraft: Có bất cứ điều gì chúng ta có thể đồng ý, rằng X là mã tốt và Y là mã xấu?

bạn thân: Để tôi yên Tôi chỉ muốn mã!

Chà, điều đó không tốt, phải không? Tôi đoán cảm giác tôi có là bạn và Buddy muốn những thứ khác nhau. Nếu có bất cứ điều gì bạn có thể đồng ý, thật tuyệt; bắt đầu từ đó và xây dựng nó Nhưng bạn không thể khiến anh ấy đồng ý muốn những gì bạn muốn - nhiều hơn bạn có thể khiến bản thân muốn những gì anh ấy muốn. Nếu bạn có thể tìm thấy mong muốn chung đó, và đi đến thỏa thuận chung từ đó, có lẽ bạn có thể làm việc cùng nhau.

douecraft: Bạn muốn gì?

bạn thân: tôi chỉ muốn viết mã

douecraft: Tôi cũng muốn viết mã, nhưng tôi muốn cảm thấy tự hào về mã của mình.

bạn thân: tôi tự hào về mã của tôi

douecraft: Đây là một chức năng tôi tự hào - bạn nghĩ gì về nó?

bạn thân: Chà, không sao, nhưng bạn không nên tính toán lại X trong vòng lặp; nó không hiệu quả.

douecraft: Vì vậy, bạn đang nói rằng chúng ta nên luôn luôn tính toán các giá trị không đổi bên ngoài các vòng lặp?

bạn thân: À, duh!

douecraft: Bạn có nghĩ rằng nên có trong hướng dẫn của chúng tôi?

bạn thân: Tất nhiên rồi.

douecraft: OK, tôi sẽ thêm nó vào hướng dẫn của chúng tôi và tôi sẽ cập nhật mã của mình ...

douecraft: Làm thế nào bây giờ?

bạn thân: Tốt thôi.

Bây giờ Buddy đang đóng góp cho các hướng dẫn (tuy nhiên một cách gián tiếp), và vì vậy anh ấy có một chút ý thức về quyền sở hữu. Có lẽ - chỉ có thể - anh sẽ bắt đầu coi trọng họ hơn. Tôi nghĩ rằng tôi có xu hướng quét sạch bảng và bắt đầu lại với các hướng dẫn, ban đầu cho phép hầu hết hoặc tất cả chúng đến từ Buddy. Đi trước và viết mã shit để anh ta cảm thấy cần phải thêm vào các hướng dẫn; hãy để họ đến từ anh ấy Có lẽ sau đó anh sẽ bắt đầu hiểu lý do cho họ.

Nhưng nếu bạn muốn từ bỏ và tiếp tục - đó cũng có thể không phải là một lựa chọn tồi.


2

Giả sử bạn quyết định từ bỏ dự án:

  • Ngã ba mã và cấu trúc lại nó, sử dụng nó làm mục danh mục 'trước / sau'
  • Vì mục tiêu là (chủ yếu hoặc một phần) để học lập trình và vì học một cái gì đó mất 2-4 lần miễn là làm điều gì đó bạn đã biết, công việc đó không thực sự lãng phí.
  • 'Đính kèm chi phí chìm' (khoản đầu tư bạn đã thực hiện trong một liên doanh trước khi biết đó là một ý tưởng tồi) là một trong những lỗi phổ biến nhất của con người trong quá trình ra quyết định
  • Để giữ tình bạn, hãy đóng khung quyết định của bạn là ưu tiên tình bạn hơn mã hóa

1

tl; dr bạn nên từ bỏ dự án.

Không cần biết thêm về điều này sau đó bạn đã nói với chúng tôi, tôi suy đoán rằng ma sát mà bạn gặp phải có liên quan đến kinh nghiệm.

Mặc dù bạn không phải là một lập trình viên chuyên nghiệp với tư cách là một chuyên gia CNTT, nhưng lần đầu tiên bạn có thể học được cách làm việc chăm chỉ, nhưng việc bạn tham khảo về bản thân trong tương lai cho thấy bạn đã lừa dối anh ấy / cô ấy trong quá khứ và học được không

Sinh viên CS năm thứ 2 của bạn, ngay cả khi có năng khiếu, có lẽ thiếu quan điểm đã làm điều đó (nếu bạn giống tôi, lặp đi lặp lại :).

Anh ấy / cô ấy sẽ không bao giờ thực sự tin vào giá trị của việc sửa chữa mọi thứ khi bạn đi cho đến khi anh ấy / cô ấy bị sẹo do không làm điều đó hoặc được hướng dẫn trong một nền văn hóa với kỷ luật kỹ thuật đặc biệt, hoặc cả hai.

Người này có thể là đồng nghiệp lập trình của bạn, nhưng không phải là đồng nghiệp dự án của bạn, vì vậy thực hiện trò chơi này như một dự án ngang hàng có thể là một nguyên nhân bị mất. Trừ khi bạn chuẩn bị chỉ để ăn chi phí trong tương lai. Có lẽ mối quan hệ là đủ giá trị với bạn. Trong trường hợp đó, hãy cho hem / cô ấy đủ dây để treo mình và bước vào để giúp dọn dẹp mớ hỗn độn khi người đó buộc phải thừa nhận vấn đề.

Mặt khác bảo lãnh và thực hiện một dự án với một người ngang hàng, hoặc làm một dự án cố vấn / người cố vấn trong đó đó là động lực ngay từ đầu.


1

Để thêm điểm bổ sung cho tất cả các câu trả lời tuyệt vời:

  • Sẽ mất bao nhiêu nỗ lực để hoàn thành dự án? Lưu ý rằng việc hoàn thành "10% cuối cùng" mất nhiều thời gian hơn mọi người mong đợi. Điều đó bao gồm kiểm tra / điều chỉnh chơi, sửa lỗi khả năng sử dụng, đối phó với nhiều nền tảng đích, phát hành, ... Nếu đó là một trò chơi iOS, thì có ký mã và thông qua đánh giá của Apple. Thành thật mà nói, hoàn thiện có thể mất đến "90%" đầu tiên. Và sẽ rất khó khăn nếu mã xấu như bạn đề xuất. (Bạn có thể bắt đầu chơi thử ngay bây giờ không?)
  • Trên thực tế, nhiều khả năng mọi người sẽ thích trò chơi của bạn như thế nào?
  • Coi chừng " chìm chi phí heuristic ". Đánh giá 10.000 đầu tư mã dòng dưới ánh sáng của bức tranh lớn, nhìn lại một sản phẩm đã hoàn thành và không có sự lạc quan quá mức.
  • Bạn có thể tiếp tục đi nếu phải mất thêm 3 năm nữa? Hai bạn có phong cách phát triển khác nhau (không phải là một trận đấu nhóm tốt). Nghe có vẻ như bạn gần hết kiên nhẫn và nếu bạn tiếp tục, việc giữ bạn bè có thể khó khăn.

3
"10% cuối cùng" mất nhiều thời gian hơn nếu 90% mã là rác :-(
gnasher729

0

Bạn chỉ nên tiếp tục thực hiện mã theo cách bạn nghĩ là đúng, với các nhận xét và như vậy và tạo một bản sao của phiên bản mã của bạn (trong trường hợp anh ta thay đổi mã của bạn).

Đừng đánh nhau, đừng nổi giận, hãy mỉm cười khi thấy những quyết định tồi tệ của anh ấy.

Chỉ khiếu nại với tư cách người dùng, nếu nó đang hoạt động, đừng phàn nàn.

Đừng từ bỏ, điều quan trọng là làm quen với những người khác với bạn, điều đó sẽ xảy ra trong một công việc thực sự.

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.