ปัจจัยใดที่ควรมีอิทธิพลต่อวิธีที่ฉันพิจารณาเมื่อจะละทิ้งโครงการเล็ก ๆ กับเพื่อน [ปิด]


30

ฉันพบว่าตัวเองอยู่ในจุดที่ยากลำบากของสาย เคยทำงานในเกมกับเพื่อนเขียนโปรแกรมมาเกือบ 8 เดือนแล้ว เราทั้งคู่เริ่มต้นในฐานะผู้มาใหม่ในการเขียนโปรแกรมประมาณเดือนสิงหาคมของปีที่แล้วเขาเป็นนักเรียน CS ปีที่ 2 ฉันเป็นผู้ให้การสนับสนุนด้านเทคโนโลยีโดยการค้าและเป็นโปรแกรมเมอร์ที่สอนตัวเองด้วยหนังสือมากมายและการสมัครสมาชิกออนไลน์

ปัญหาที่ฉันเห็นอยู่ตลอดเวลาคือเมื่อเราเขียนโค้ดจำนวนหนึ่งบ่อยครั้งที่มันจะถูกแฮ็กเข้าด้วยกันมีความล้มเหลวมากมายและหากเป็นแนวคิดใหม่เอี่ยมสำหรับเราหนึ่งคนที่เต็มไปด้วยโซลูชั่นไร้เดียงสา นี่เป็นสิ่งที่ดีเรากำลังเรียนรู้ฉันคาดหวังว่าโค้ดทั้งสองของเราจะถูกแฮ็กเข้าด้วยกันในภาคเรียนหรือรอบที่สอง ปัญหานำเสนอตัวเองเมื่อมันมาถึงการแก้ไขและ refactoring พฤติกรรมที่แฮ็กด้วยกัน

คู่ของฉันจะยึดติดกับก้อนกรวดที่สดใหม่ของเขาด้วยกันอย่างโจ๋งครึ่มปฏิเสธที่จะเห็นข้อผิดพลาดใด ๆ ในขณะที่มันเริ่มทำงาน การอ้างถึงความสมบูรณ์แบบจากชิ้นส่วนของโครงสร้างฉันไม่สามารถแม้แต่จะใช้แม้ว่ามันจะมีความคิดเห็นและวิธีการและฟิลด์ที่ตั้งชื่อไว้อย่างเหมาะสมก็ตาม ไม่ว่าฉันจะพยายามแค่ไหนฉันก็ไม่สามารถทำให้เขาเห็นข้อบกพร่องที่เห็นได้ชัดซึ่งจะป้องกันไม่ให้เกิดการเปลี่ยนแปลงหรือการขยายตัวของพฤติกรรมโดยไม่ทำลายมันและทุกอย่างที่มันเชื่อมโยงกับพวกเขาอาจจะอยู่ในชั้นเดียวกัน โซลูชันที่ถูกแฮ็กตลอดเวลาจะถูกแฮ็กอยู่ตลอดและคิดว่าการออกแบบที่ไม่ดีจะยังคงอยู่ในแบบที่พวกเขาคิด

ฉันใช้เวลาไปกับการดูแลรหัสใหม่ให้มากขึ้นเพราะฉันเขียนด้วยตัวเองฉันเสียสิ่งที่ต้องทำ คู่ของฉันสูญเสียมันไปคืนนี้และทำให้ชัดเจนว่าไม่ว่าอะไรก็ตามไม่ว่าจะเป็นมาตรฐานไม่ว่าจะเป็นเรื่องธรรมดาการปฏิบัติไม่ว่าจะเป็นข้อพิสูจน์ที่หักล้างไม่ได้ก็ตามรหัสของเขาจะยังคงอยู่ในแบบที่เขาทำ แม้ว่าหนังสือทั้งเล่มจะถูกเขียนขึ้นเกี่ยวกับสาเหตุที่คุณต้องการหลีกเลี่ยงการทำอะไรเขาจะปฏิเสธที่จะยอมรับความถูกต้องของพวกเขาโดยอ้างว่าเป็นเพียงความเห็นของใครบางคน

ฉันมีความสนใจในโครงการของเรา แต่ฉันไม่แน่ใจว่าฉันจะสามารถทำงานร่วมกับคู่ค้าของฉันได้หรือไม่ ฉันดูเหมือนจะมีสามตัวเลือกให้ฉันเปิด

  • หยุดการดูแลเกี่ยวกับการทำงานของ codebase ที่ผ่านจุดรวบรวมและเพียงจัดการกับการพยายามที่จะรักษาและแยกวิเคราะห์พฤติกรรมที่แทบจะไม่คลานไปมา หวังว่าเมื่อสิ่งต่าง ๆ เริ่มสลายอย่างจริงจังเขาจะเห็นและพยายามทำมากกว่าแค่ใส่ bandaid เหนือการออกแบบที่มีข้อบกพร่องพื้นฐาน
  • ติดตามข้อถกเถียงที่ไม่รู้จบเกี่ยวกับปัญหาที่เกิดขึ้นเมื่อทศวรรษที่แล้วโดยบุคคลที่มีความสามารถมากกว่า
  • หยุดเขียนโปรแกรมในโครงการนี้ทิ้งโค้ดของฉันเกือบ 10,000 บรรทัดและใช้เวลาหลายชั่วโมงในการออกแบบและลองหาโปรเจคใหม่ด้วยตัวเอง

ฉันจะใช้วิธีการใดเพื่อตรวจสอบว่าโครงการนี้ดำเนินต่อกับบุคคลนี้ได้หรือไม่ หรือปัจจัยใดที่ควรมีอิทธิพลต่อการตัดสินใจของฉัน เราได้เขียนโค้ดจำนวนมากและฉันไม่ต้องการยอมแพ้เว้นแต่จะจำเป็น


3
สิ่งที่เกี่ยวกับการกำหนดแนวทางสไตล์การเขียนโค้ดที่ตกลงไว้และกระบวนการตรวจสอบโค้ด หลีกเลี่ยงปัญหาที่ถกเถียงกันเพียงแค่ใส่ในมาตรฐานที่คุณสามารถยอมรับได้
Brandin

25
ตัวเลือกที่สี่ (หากอยู่ภายใต้ใบอนุญาต): แยกรหัสและทำงานต่อไปด้วยตัวคุณเอง
Robert Harvey

4
รหัสได้รับใบอนุญาตอย่างไร คุณสามารถแยกมันและต่อกับคนอื่นได้หรือไม่?
Jaydee

14
ในขณะที่ @enderland กล่าวถึงคำตอบของเขามีธงสีแดงขนาดมหึมาในสิ่งที่คุณเขียนว่า: "คู่หูของฉันแพ้ในคืนนี้และทำให้มันชัดเจนว่าไม่ว่าอะไรก็ตามไม่ว่าจะเป็นมาตรฐานไม่ว่าจะเป็นเรื่องธรรมดา หลักฐานที่หักล้างไม่ได้รหัสของเขาจะยังคงอยู่ในแบบที่เขาทำไว้ก่อน " หากคุณสามารถหลีกหนีจากสิ่งนี้ได้ ใครก็ตามที่ควรค่ากับการทำงานอย่างแท้จริงจะต้องมีความอ่อนน้อมถ่อมตนที่จะยอมรับว่าบางครั้งพวกเขาจะได้รับสิ่งผิดปกติ
Richard J Foster

3
ไม่ว่าคุณจะตัดสินใจอย่างไรรหัส 10k บรรทัดก็จะไม่สูญหาย: ลองคิดถึงสิ่งที่คุณเรียนรู้จากการเขียน ลองนึกถึงความสุขที่คุณมีในช่วงการเขียนโค้ด และการใช้สิ่งที่คุณได้เรียนรู้ในการทำซ้ำ (บังคับ) ครั้งที่สาม / สี่ / n + 1 อาจทำให้ดีขึ้นกว่าเวอร์ชันปัจจุบัน นอกจากนี้หากคุณรู้ว่าจะเขียนโค้ด 10k บรรทัดคุณสามารถเขียนบรรทัด 10k ในเวลาอันสั้น บ่อยครั้งที่การรู้ว่าจะเขียนอะไรเพื่อทำให้งานเป็นสิ่งที่ต้องใช้เวลามากที่สุด
Kasper van den Berg

คำตอบ:


26

การจัดส่งรหัสไม่สมบูรณ์ดีกว่ารหัสที่สมบูรณ์แบบบนไวท์บอร์ดที่ไม่เคยได้รับการจัดส่ง

ที่ถูกกล่าวว่า ...

ผู้ที่มีประสบการณ์มากขึ้นหรืออยู่ในสถานการณ์ที่คล้ายคลึงกัน คุณทำอะไรลงไป? คุณอยากแนะนำอะไร

ฉันจะพิจารณาดังต่อไปนี้

  • โครงการนี้มีจุดประสงค์อะไร? สนุก? เงินได้หรือไม่ เพื่อเรียนรู้?
    • คุณบรรลุวัตถุประสงค์นี้จริงหรือไม่
  • คนนี้ช่วยให้คุณบรรลุเป้าหมายได้ดีขึ้นจริงหรือ
  • คุณอยู่ใกล้การจัดส่งจริงแค่ไหน
  • ปัญหาเหล่านี้ทำให้คุณไม่สามารถเปิดใช้งานได้หรือไม่ หรือว่าพวกเขาเป็นเรื่องของความภาคภูมิใจส่วนตัว?
  • การทำงานร่วมกับใครบางคนเป็นไปโดยสมัครใจเมื่อรู้สึกหงุดหงิด?

หยุดการเขียนโปรแกรมในโครงการนี้ทิ้งโค้ดของฉันเกือบ 10,000 บรรทัดและใช้เวลาหลายชั่วโมงในการออกแบบและลองหาโปรเจคใหม่ด้วยตัวเอง

พิจารณาข้างต้นพยายามคิดผ่านงานเพิ่มเติมที่จำเป็น

คุณจำเป็นต้องจัดลำดับความสำคัญของคุณและพิจารณาว่าปัญหาที่เกี่ยวข้องกับการทำงานกับบุคคลนี้มีค่าหรือไม่ เราไม่สามารถเข้าใจสิ่งนี้ได้สำหรับคุณ

คู่ของฉันสูญเสียมันไปคืนนี้และทำให้ชัดเจนว่าไม่ว่าอะไรก็ตามไม่ว่าจะเป็นมาตรฐานไม่ว่าจะเป็นเรื่องธรรมดาการปฏิบัติไม่ว่าจะเป็นข้อพิสูจน์ที่หักล้างไม่ได้ก็ตามรหัสของเขาจะยังคงอยู่ในแบบที่เขาทำ

คุณรู้ว่าคุณไม่ต้องการทำงานกับคนประเภทนี้

คุณกำลังทำโปรเจคแบบนี้น่าจะเป็นเพราะคุณต้องการเรียนรู้การเขียนโปรแกรมและค้นหาความสง่างามในงานฝีมือ


1
ขอบคุณสำหรับการตอบกลับของคุณ. ฉันบรรลุวัตถุประสงค์ของการมีความสนุกสนาน (เมื่อไม่คลุกวงใน) และการเรียนรู้ สภาพอากาศเงินใด ๆ ที่จะทำให้เป็นเรื่องที่แตกต่างอย่างสิ้นเชิง เขาช่วยในการบรรลุเป้าหมายของฉัน แต่ฉันเชื่อว่าฉันยังสามารถบรรลุเป้าหมายเหล่านั้นได้ด้วยตัวเองเขาช่วยด้วยแรงจูงใจ เกมดังกล่าวเป็นตัวอย่างที่ดีของการคืบของเกมฉันไม่สามารถคิดได้เมื่อมันสามารถส่งได้ พันธมิตรของฉันพยายามผลักดันให้มีการเปลี่ยนแปลงจาก 2D เป็น 3D เป็นเวลาหลายเดือนแล้วฉันปฏิเสธเพราะเราได้เกินขอบเขตของเรามานานแล้ว
Douglas Gaskell

1
ฉันยินดีที่จะทำโปรเจ็กต์นี้หากเป็นเพียงของฉันเองมันจะถูกลบหลายเดือนที่ผ่านมา ปัจจัยกระตุ้นของฉันที่จะดำเนินการต่อคือการมีคนอื่นทำงานด้วยแม้ว่าการต่อสู้แบบประจัญบานทำให้ฉันถามว่าบางวัน สิ่งเดียวที่ทำให้ฉันไม่ต้องละทิ้งมันคือมิตรภาพที่เชื่อมโยงกับเขานอกการเข้ารหัสฉันควรหลีกเลี่ยงการทำเช่นนั้นกับโครงการ แน่นอนว่านี่ไม่ใช่คำอธิบายเชิงตรรกะเนื่องจากความรู้สึกส่วนตัวของพวกเขามีส่วนเกี่ยวข้องมันทำให้ความสามารถในการตัดสินใจของฉันสูงขึ้น
Douglas Gaskell

1
วิธีที่เร็วที่สุดในการสูญเสียเพื่อนคือการทำงานกับพวกเขาให้เท่าเทียมกัน!

58

นี่อาจเป็นสิ่งทางวัฒนธรรม ในบางวัฒนธรรมการยอมรับว่าคุณทำผิดพลาดนั้นไม่เคยได้ยินมาก่อนและการขอให้บางคนยอมรับว่าทำผิดนั้นเป็นเรื่องที่น่าอับอายที่สุดที่คุณสามารถทำได้ หากเป็นเช่นนั้นให้หนีไป

จากประสบการณ์ของฉันกับคนที่ฉลาดมากถ้าคุณบอกพวกเขาว่าสิ่งที่พวกเขากำลังทำนั้นไม่สมบูรณ์แบบพวกเขาก็จะ (1) ให้เหตุผลที่ถูกต้องและเข้าใจง่ายว่าทำไมพวกเขาถึงทำถูกต้อง (2) บอก คุณว่าพวกเขารู้ว่ามันผิด แต่พวกเขาไม่มีเวลาแก้ไขเนื่องจากลำดับความสำคัญหรือ (3) ขอบคุณสำหรับการชี้ให้เห็นและแก้ไข

การปฏิเสธที่จะเรียนรู้เป็นเรื่องเกี่ยวกับคุณลักษณะที่แย่ที่สุดที่นักพัฒนาซอฟต์แวร์อาจมี ทิ้งเขาไป ชีวิตนั้นสั้นเกินไปและมีค่าเกินกว่าที่คุณจะเสียเวลากับเขา


ขอบคุณ Gnasher ฉันเห็น # 2 เป็นระยะแม้ว่าเราจะไม่มีตารางเวลาจริงดังนั้นฉันไม่แน่ใจว่าคำตอบนั้นถูกต้องหรือไม่ ฉันจะไปนอนที่นี่และดูว่าฉันกำลังคิดอะไรใน AM อยู่นี้ต้องใช้การพิจารณาอย่างถี่ถ้วนก่อนตัดสินใจ
Douglas Gaskell

1
"ถ้าเป็นสถานการณ์แบบนั้นให้หนีไป" - และโดยทั่วไปแล้วหากคุณไม่สามารถใกล้ถึงฉันทามติว่าเป้าหมายของคุณคืออะไรคุณไม่สามารถร่วมมือกับใครบางคนได้ ดูเหมือนว่าเขาจะไม่ยินยอมให้คุณเปลี่ยนรหัส "ของเขา" ไม่ว่าด้วยเหตุผลใด
Steve Jessop

ดูเหมือนว่าแรงกดดันเวลาไม่ใช่เหตุผลที่จะปฏิเสธการเปลี่ยนแปลง
gnasher729

1
นี่คือคำตอบที่ดี คุณไม่สามารถบังคับให้ใครบางคนเปลี่ยนวิธีการของพวกเขา! อย่างไรก็ตามดูเหมือนว่าจะมีเวลาและความพยายามมากมายในโปรเจ็กต์ของเขาเช่นเดียวกับคุณ ความคิดของฉันอาจเป็นได้ว่าเขาอาจไม่ต้องการเปลี่ยนรหัสของเขาเพราะเขาไม่เข้าใจวิธีที่คุณคิดว่าควรจะทำ ไม่ว่าจะเป็นหรือว่าเขาเป็นคนหยาบคาย แต่ถ้าเขาไม่เข้าใจให้พยายามจำไว้ว่าเขาอาจจะหงุดหงิดและคิดว่าคุณกำลัง "พูดคุย" กับเขาแม้ว่าคุณจะพูดได้ดีก็ตาม คำแนะนำของฉันคือพยายามพูดคุยกับเขาเมื่อคุณทั้งคู่ขึ้นอยู่กับมัน
zfrisch

^ + เป็นเรื่องง่ายที่จะกลายเป็นคนที่ไม่พอใจเมื่อคุณเริ่มต้นในระดับเดียวกันและพวกเขาทำได้ดีกว่าคุณ ฉันไม่ได้พูดแบบนั้นแน่นอน แต่ดูเหมือนว่ามันอาจมีบางอย่างที่เกี่ยวข้องกับมัน
zfrisch

12

อาจเป็นวิธีที่ง่ายที่สุดคือการนำคนอื่นเข้ามาในโครงการ - ไม่ว่าคุณจะผิดและโค้ดเบสของเขาฉลาดเกินไปสำหรับคุณหรือคุณถูกและฉลาดเกินไปสำหรับทุกคน ในไม่ช้าคุณจะค้นพบและจะได้รับการสำรองข้อมูลหากรหัสนั้นเป็นรหัสระดับขยะที่ซับซ้อนและซับซ้อน

ในทางกลับกันผลิตภัณฑ์ที่ใช้งานได้นั้นมีมูลค่าหลายปีรวมถึงโค้ดที่ได้รับการปรับแต่งอย่างประณีตสวยงามและชัดเจน สร้างเกมจัดส่งเดินไปแล้ว - ทิ้งเขาไว้เพื่อดูแลและไม่ทำงานบน v2


2
ขอบคุณสำหรับการตอบกลับ. ตลกที่คุณพูดถึงจุดแรกของคุณ เขาพยายามค้นหาและนำโปรแกรมเมอร์มาเป็นสามเณรซึ่งเขาสามารถสอนเพื่อช่วยโครงงานนี้ได้ ฉันคาดหวังได้ว่าสิ่งนี้จะเปิดออกอย่างน่ากลัวหากมีคนสองคนติดตามการแฮ็กแบบเดียวกันและลืม ฉันชอบตัวเลือกที่สองทำให้จัดส่งแล้วปล่อยทิ้งไว้ ปัญหาที่ฉันอาจพบคือพวกเราเป็นส่วนหนึ่งในการสร้าง LLC เพื่อให้เรามีชื่อเพื่อส่งเกมของเราภายใต้ การใช้งานทั้งสองอย่างจะมีส่วนแบ่ง 50% แน่นอน อย่างไรก็ตามฉันเพิ่งจะทำมันให้เสร็จแล้วก็ไปต่อ โครงการมีขนาดใหญ่ซึ่งอาจใช้เวลาสักครู่
Douglas Gaskell

20
คุณไม่ได้อยู่ภายใต้สถานการณ์ใด ๆ ที่ต้องการป้อนความสัมพันธ์ทางธุรกิจที่มีผลผูกพันตามกฎหมายกับบุคคลเช่นนั้น
gnasher729

3
@ douglasg14b พาจูเนียร์มาสอน .. เด็กผู้น่าสงสาร ขอแนะนำให้คุณนำคนที่มีประสบการณ์ "เพราะเขาจะเร่งความเร็วให้เร็วขึ้นและช่วยให้ผลิตภัณฑ์เสร็จ" กำหนดสถานที่ท่องเที่ยวของคุณเป็นเส้นชัย - หรือคุณตั้งใจจะทำงานอดิเรกนี้ตลอดไปหรือไม่? (เห็นว่าเกิดขึ้นจนกว่าจะถูกยกเลิก)
gbjbaanb

ฉันวางแผนที่จะทำมันให้เสร็จแน่นอน แม้ว่าฉันจะเชื่อว่ามันเป็นโครงการที่ใหญ่เกินกว่าที่จะรับมือได้ในตอนแรกของเรา มันเริ่มจากการออกแบบที่เรียบง่ายมันไม่ควรจะอยู่ใกล้กับระดับที่มันเป็นอยู่ตอนนี้ ขอบเขตของขอบเขตของเราได้รับการผลักดันอย่างต่อเนื่องกับคุณสมบัติการคืบโดยคู่ค้าของฉันฉันเป็นบางส่วนที่จะตำหนิเพราะฉันอนุญาตให้มันเกิดขึ้นและเห็นด้วยกับคุณสมบัติบางอย่าง ขอบเขตคือจนถึงจุดที่ถ้าทิ้งไว้ตามลำพังเราอาจจะดูความสำเร็จภายในหนึ่งปี โชคดีที่ฉันได้ตั้งโปรแกรมมันชิ้นส่วนสามารถนำออกไปและนำเข้าสู่โครงการอื่น ๆ ได้ในภายหลัง
Douglas Gaskell

4
คิดว่ารหัสเป็นของโครงการไม่ใช่ของคุณ หากคุณมีกรรมสิทธิ์ในผลิตภัณฑ์ร่วมกันคุณสามารถใช้รหัสทั้งหมดซ้ำสำหรับโครงการถัดไปของคุณ หากคุณไม่มีความคิดว่าใครเป็นเจ้าของสิ่งใด โชคดี.
gbjbaanb

9

นี่คือความคิดบางอย่างแม้ว่าบางส่วนของพวกเขาเป็นพิเศษร่วมกัน

  • แยกความรับผิดชอบของแหล่งที่มา หากคุณทำงานกับโมดูล A และเขาในโมดูล B คุณสามารถแข่งขันกับสไตล์ที่แตกต่างของคุณ เขาปล่อยคุณสมบัติการทำงานบ่อยครั้งหรือไม่? เขามาถึงจุดที่เขาต้องเขียนโค้ดใหม่ตั้งแต่ต้นหรือไม่? สร้างรหัสใหม่จากโมดูลของคุณและอย่าแตะต้องเขา

  • ให้เขาดูแลรหัสที่แย่ที่สุดของเขา หากเขาทำสำเร็จคุณได้หลีกเลี่ยงงานอันน่าสะพรึงกลัว หากเขาไม่สามารถเขาจะรู้สึกเจ็บปวด

  • พิจารณาจากผู้ใช้หรือมุมมองทางธุรกิจ ในบางกรณีคุณต้องมีผลิตภัณฑ์ที่ใช้งานได้ซึ่ง Google หรือ Microsoft อาจซื้อ คุณกำลังเปิดตัวผลิตภัณฑ์ออกสู่ตลาดและสนับสนุนลูกค้าหลายพันรายด้วยรหัสบั๊กหรือแฮ็กจะเป็นนรก ไม่เหมือนกันหากรหัสของคุณควบคุมโดรนด้วยขีปนาวุธนิวเคลียร์หรือสร้างวิดีโอที่มีความสุขสำหรับวัยรุ่น

  • เขาทำชั้นเรียนคุณทำแบบทดสอบ การสร้างรหัสใหม่ด้วยการทดสอบนั้นง่ายและปลอดภัยยิ่งขึ้น วิธีนี้คุณไม่จำเป็นต้องมองเข้าไปในโค้ดเพียงแค่แถบ Junit สิ่งนี้ถือว่า A) คุณกำลังทดสอบการเขียนโปรแกรม B) รหัสเพื่อนร่วมงานของคุณสามารถทดสอบได้ หากคุณพบว่ายากที่จะสร้างการทดสอบในช่วงหลังการเข้ารหัสจะเลวร้ายยิ่ง

  • ไปด้วยกันเพื่อการฝึกอบรมหรือกิจกรรม เมื่อคุณไม่รู้ว่าวิธีที่ถูกต้องนั้นค่อนข้างเป็นธรรมชาติใช้วิธีเดียวที่คุณรู้ การเห็นรหัสของผู้อื่นอาจไม่สามารถแก้ไขได้ทุกอย่าง แต่จะไม่เจ็บ

  • ค้นหาจุดแข็งเสริมของคุณ การปรับโครงสร้างใหม่อาจเป็นเรื่องสนุก หากเขาเขียนสิ่งที่ทำงานได้อย่างน้อยคุณอาจทำการปรับโครงสร้าง เขาสามารถทำหนามแหลมเพื่อสำรวจวิธีแก้ปัญหาที่ไม่สิ้นสุดในรหัสการผลิต

  • เขาอาจไม่ต้องการเขียนรหัสใหม่ แต่เขาอาจตกลงที่จะเขียนรหัสใหม่ได้ดีกว่า ฉันเข้าใจว่าการเขียนซ้ำเป็นเรื่องยากน่าเบื่อและสามารถทำลายสิ่งต่าง ๆ ได้ ปลูกฝังเกาะที่มีคุณภาพ วิธีนี้เขาจะมีตัวอย่างที่ดีของวิธีการทำสิ่งต่าง ๆ

  • ใช้กฎลูกเสือ อย่าปล่อยให้สิ่งที่ไม่มีใครแตะต้องเว้นแต่คุณจะต้องทำงานกับมัน หากโมดูลมีการเขียนไม่ดี แต่ใช้งานได้และไม่จำเป็นต้องเปลี่ยนให้ปล่อยไว้เช่นนั้น หากคุณต้องการแก้ไขข้อบกพร่องหรือปรับปรุงคุณสมบัติให้สมบูรณ์สักหน่อย หลังจากเวลา 20% ของคลาสที่คุณเปลี่ยน 80% ของเวลาจะดีขึ้น เกาะที่มีคุณภาพมากขึ้น

เราไม่สามารถแนะนำสิ่งที่เป็นทางออกที่ดีที่สุดโดยไม่รู้จักคุณทั้งคู่ โชคดี.


4

ตกลงนี่คือคำตอบที่คุณอาจจะไม่ชอบ

อย่า 'แก้ไข' โค้ดหากไม่สามารถใช้งานคุณสมบัตินี้ได้

นี่คือเหตุผลของฉัน คุณกำลังพยายามหารายได้ เพื่อให้เงินคุณต้องจัดส่งคุณสมบัติที่สมบูรณ์ได้อย่างรวดเร็ว ไม่มีใครจะจ่ายคุณมากขึ้นสำหรับเกมคอมพิวเตอร์

บริษัท ส่วนใหญ่มีปัญหาเดียวกัน Refactor รหัสที่มีอยู่เพื่อให้ 'ดีขึ้น' บางครั้งอาจดีขึ้นอย่างเป็นกลางในแง่ของความเร็วหรือความน่าเชื่อถือหรือเขียนคุณสมบัติใหม่

99% ของเวลาที่พวกเขาเลือกที่จะเขียนคุณสมบัติใหม่เนื่องจากผลลัพธ์ของการวิเคราะห์ผลประโยชน์ทางต้นทุนอย่างง่าย


15
สิ่งนี้อยู่ภายใต้การโต้แย้ง "หนี้ทางเทคนิค" ทั้งหมดใช่มั้ย เมื่อคุณเขียนฟีเจอร์ใหม่นั้น (หรือแก้ไขสิ่งที่มีอยู่) มันจะใช้เวลานานถึงสามเท่าและสร้างข้อผิดพลาดให้ได้มากถึงสิบเท่าตามที่มันจะเกิดขึ้นถ้าคุณต้องรักษาด้วยการปรับโครงสร้างใหม่หรือไม่? ถ้าเป็นเช่นนั้นอาจจะข้ามการปรับโครงสร้างเป็นเศรษฐกิจที่ผิดพลาด
Ben Aaronson

1
คุณจะคิดอย่างนั้น แต่ฉันเคยทำงานใน บริษัท ที่ประสบความสำเร็จมากมายและฉัน (เกือบ) ไม่เคยเห็นการปรับโครงสร้างใหม่ที่มีลำดับความสำคัญสูง ข้อสรุปของฉันคือมันไม่จ่ายออกไป
Ewan

มันยุติธรรมเพียงพอและฉันแน่ใจว่ามีความคิดเห็นที่หลากหลายเกี่ยวกับเรื่องนี้ดูเหมือนว่าจะไม่พูดถึงเรื่องใดเรื่องหนึ่งไม่ทางใดก็ทางหนึ่งเป็นการละเว้นที่สำคัญจากคำตอบ นอกจากนี้ผมอาจจะผิด แต่การอ่านระหว่างบรรทัดในคำถามที่ฉันคิดว่ารหัสไม่ดี OP จะกังวลเกี่ยวกับอาจจะเป็นวิธีที่เลวร้ายยิ่งกว่าชนิดของรหัสที่คุณกำลังความคิดเกี่ยวกับ
Ben Aaronson

เฮ้! แต่ดูเหมือนว่าค่าใช้จ่ายในการเปลี่ยนแปลงจะสูงมาก ในคำตอบของฉันฉันพยายามให้วัตถุประสงค์ 'คุณอยู่ในนี้สำหรับเงินได้หรือไม่' คำตอบบวกมุมมองส่วนตัวของฉันที่ความสมดุลของความน่าจะเป็น
Ewan

1
นี่เป็นเหตุผลที่สมเหตุสมผลในบางกรณี แต่ถ้า "รหัสการทำงาน" ของใครบางคนทำให้คนอื่นใช้เวลามากขึ้นเป็นสองเท่าในรหัสของพวกเขาหรือการบูรณาการระบบเข้าด้วยกันหรือการทำงานในอนาคต โครงการขนาดใหญ่จำนวนมากตายเพราะพวกเขาไม่ได้ตัดสินใจที่จะทำถูกต้องมากกว่าที่จะรวดเร็ว
enderland

3

ฉันชอบคำตอบทั้งหมดจนถึงตอนนี้ รับหนึ่งในคะแนนจากคำตอบของ enderland :

การทำงานร่วมกับใครบางคนเป็นไปโดยสมัครใจเมื่อรู้สึกหงุดหงิด?

ผมอยากจะใช้เวลานี้ในการเชื่อมต่อสำหรับการแลกเปลี่ยนสแต็คการตรวจสอบรหัส มันเป็นสถานที่ที่ยอดเยี่ยมที่คุณสามารถรับรหัสของคุณวิจารณ์โดยผู้เชี่ยวชาญ และโดยความจริงแล้วการตรวจสอบรหัสจำนวนมากมีประโยชน์อย่างมากต่อผู้ที่เกี่ยวข้องเช่นผู้ถามผู้ตอบคำถามและผู้ที่สะดุดและอ่าน คุณไม่ค่อยได้รับความเห็นที่เป็นประโยชน์ในการตั้งค่าระดับมืออาชีพ (ซึ่งอาจเป็นกรณีที่สถานที่ที่ฉันเคยทำงานด้วยเหตุผลใดก็ตาม)

คำแนะนำเล็กน้อยของฉันคือโพสต์โค้ดของคุณเพื่อการตรวจสอบ ฉันจะไม่แนะนำให้ใช้มันเป็นกระสุนเพื่อพิสูจน์ว่าผู้ชายคนนี้ผิด - ฉันสงสัยว่าเขาจะเอาไปใส่ใจ - แต่คุณจะได้รับข้อมูลที่เป็นประโยชน์มากทั้งในโค้ดที่คุณเขียนและโค้ดที่เขาเขียน ฉันขอแนะนำให้ส่งรหัสที่คุณสองคนทะเลาะกันให้มากที่สุด ในทุกโอกาสคุณทั้งคู่มีความผิดในระดับหนึ่งและคุณสามารถใช้การตรวจสอบเพื่อให้บุคคลที่สามมีวัตถุประสงค์เพื่อก้าวเข้ามาสิ่งนี้จะทำให้บางสิ่งสำเร็จ:

  • คุณสามารถตัดการเชื่อมต่อจากความตึงเครียดทางอารมณ์ของสถานการณ์

  • คุณจะได้รับคำแนะนำจากมืออาชีพตามเวลาจริง สิ่งสำคัญที่คุณกำลังเรียนรู้

  • บางคนจะบอกคุณว่าคุณผิด ซึ่งเป็นสิ่งที่ดีเพราะใครก็ตามที่เขียนโปรแกรมเป็นระยะเวลานาน ๆ จะได้ยินเรื่องนี้ คุณสามารถจัดการกับมันได้ไม่ดีเหมือนคนที่คุณทำงานด้วยหรือคุณสามารถเรียนรู้ที่จะจัดการกับมัน

ฉันคิดว่าถ้าคุณใช้รหัสตรวจสอบอย่างถูกต้องคุณมีจำนวนมากที่จะได้รับจากการติดต่อกับคนที่น่าผิดหวัง และมันก็มีปฏิสัมพันธ์มากกว่าหนังสือหรือเว็บไซต์ที่ระบุว่า "ทำสิ่งนี้เพราะมันเป็นวิธีที่ถูกต้องเป็นส่วนใหญ่"

ในทำนองเดียวกันก็มีการแลกเปลี่ยนสแต็คพัฒนาเกม มีสถานที่ไม่มากที่จะโพสต์รหัสเพื่อรับการตรวจทาน แต่เพื่อถามเกี่ยวกับแนวคิด / แนวคิดที่คุณกำลังดิ้นรน อีกครั้งสถานที่นั้นมีประโยชน์มหาศาลสำหรับทุกคนที่เกี่ยวข้อง

คุณอาจเคยเห็นทั้งสองเว็บไซต์นี้มาก่อน ฉันแค่ต้องการให้แน่ใจว่าพวกเขาเป็นส่วนหนึ่งของชุดเครื่องมือของคุณ


2

มันฟังดูไร้ความหวัง ฉันอาจจะยอมแพ้และไปต่อถ้าฉันรู้สึกเกี่ยวกับมันในขณะที่คุณทำ; มีเวลาเดินจากไปอย่างแน่นอนและคุณอาจจะอยู่ที่นั่น

หากคุณยังไม่พร้อมที่จะเดินจากไปคุณต้องหาวิธีที่จะทำให้ข้อตกลงที่ดีขึ้นเกี่ยวกับกระบวนการของคุณ ดูเหมือนว่าคุณมีมาตรฐานการเข้ารหัส แต่ไม่ได้มาตรฐานที่ตกลงกันไว้ ครั้งต่อไปที่คุณมาถึงทางแยกในครั้งต่อไปที่คุณต้องการลิงด้วยรหัสเล็กน้อยและเพื่อนของคุณต้องการที่จะทิ้งมันไว้คนเดียวยิงเพื่อการสนทนาตามบรรทัดต่อไปนี้:

ดักลาส: ฉันต้องการเปลี่ยนเพราะ X ซึ่งอยู่ที่นี่ในแนวทางของเรา

บัดดี้: ไม่เป็นไร

ดักลาส: คุณกำลังบอกว่าเราควรเปลี่ยนแนวทางหรือไม่?

บัดดี้: ไม่ฉันแค่คิดว่ามันโอเคแล้ว

ดักลาส: อะไรคือแนวทางสำหรับ

บัดดี้: ฉันไม่รู้ - คุณเขียนมัน

ดักลาส: แนวทางอะไรที่คุณจะเขียน?

บัดดี้: ฉันจะไม่เขียนแนวทาง มันเสียเวลา

ดักลาส: ดังนั้นเราควรทิ้งแนวทางและเขียนอึอะไรก็ตามที่เราคิดในเวลานั้น?

บัดดี้: นี่มันไม่ได้อึ

ดักลาส: มันสมบูรณ์แบบหรือเปล่า? มันเหมาะไหม

บัดดี้: ทำงานให้เสร็จ มาดูคุณสมบัติต่อไปกันเถอะ

ดักลาส: มีอะไรที่เราเห็นด้วย X นั้นดีรหัสและ Y เป็นรหัสไม่ดี?

บัดดี้: ปล่อยฉันไว้ตามลำพัง ฉันแค่ต้องการโค้ด!

มันไม่เป็นไปด้วยดีใช่ไหม? ฉันเดาว่าความรู้สึกที่ฉันมีคือคุณและบัดดี้ต้องการสิ่งที่แตกต่าง หากมีสิ่งใดที่คุณสามารถเห็นด้วยได้ เริ่มจากตรงนั้นและสร้างมันขึ้นมา แต่คุณไม่สามารถทำให้เขาเห็นด้วยที่จะต้องการสิ่งที่คุณต้องการ - มากกว่าที่คุณสามารถทำให้ตัวเองต้องการในสิ่งที่เขาต้องการ หากคุณพบว่าความต้องการทั่วไปนั้นและมาถึงข้อตกลงร่วมกันจากที่นั่นคุณอาจทำงานร่วมกันได้

douglas: คุณต้องการอะไร

บัดดี้: ฉันแค่ต้องการโค้ด

ดักลาส: ฉันต้องการโค้ดด้วย แต่ฉันรู้สึกภาคภูมิใจในโค้ดของฉัน

บัดดี้: ฉันภูมิใจในรหัสของฉัน

douglas: นี่คือฟังก์ชั่นที่ฉันภูมิใจ - คุณคิดยังไงกับมัน?

บัดดี้: ก็โอเค แต่คุณไม่ควรคำนวน X ภายในลูป; มันไม่มีประสิทธิภาพ

ดักลาส: คุณกำลังบอกว่าเราควรคำนวณค่าคงที่นอกลูปเสมอหรือไม่?

บัดดี้: เอ่อ!

ดักลาส: คุณคิดว่าควรจะอยู่ในแนวทางของเราหรือไม่?

บัดดี้: แน่นอน

ดักลาส: ตกลงฉันจะเพิ่มไปยังหลักเกณฑ์ของเราและฉันจะอัปเดตโค้ดของฉัน ...

douglas: ตอนนี้เป็นไงบ้าง?

บัดดี้: สบายดี

ตอนนี้บัดดี้มีส่วนร่วมในแนวทาง (แต่โดยอ้อม) ดังนั้นเขาจึงมีความรู้สึกเป็นเจ้าของ บางที - บางที - เขาจะเริ่มจริงจังกับพวกเขามากขึ้น ฉันคิดว่าฉันมีแนวโน้มที่จะเช็ดกระดานชนวนและเริ่มต้นแนวทางใหม่โดยให้พวกเขาส่วนใหญ่หรือทั้งหมดมาจากบัดดี้ในตอนแรก ไปข้างหน้าและเขียนรหัสอึเพื่อให้เขารู้สึกว่าจำเป็นต้องเพิ่มแนวทาง; ปล่อยให้พวกเขามาจากเขา บางทีเขาอาจจะเริ่มเข้าใจเหตุผลสำหรับพวกเขา

แต่ถ้าคุณอยากจะยอมแพ้และเดินหน้าต่อไป - นั่นอาจไม่ใช่ตัวเลือกที่แย่เช่นกัน


2

สมมติว่าคุณตัดสินใจที่จะละทิ้งโครงการ:

  • แยกรหัสและ refactor มันใช้เป็นรายการ 'ก่อน / หลัง'
  • เนื่องจากเป้าหมายคือ (ส่วนใหญ่หรือบางส่วน) ในการเรียนรู้การเขียนโปรแกรมและเนื่องจากการเรียนรู้บางสิ่งนั้นใช้เวลา 2-4 เท่าตราบเท่าที่คุณทำสิ่งที่คุณรู้อยู่แล้วงานนั้นจึงไม่สูญเปล่า
  • 'Sunk Cost Attach' (การลงทุนที่คุณได้ทำไปแล้วก่อนที่จะเรียนรู้ว่ามันเป็นความคิดที่ไม่ดี) เป็นหนึ่งในข้อผิดพลาดที่พบบ่อยที่สุดของมนุษย์ในการตัดสินใจ
  • เพื่อรักษามิตรภาพให้กรอบการตัดสินใจของคุณเป็นการจัดลำดับความสำคัญมิตรภาพมากกว่าการเขียนโปรแกรม

1

tl; dr คุณควรละทิ้งโครงการ

โดยที่คุณไม่ได้รู้อะไรเกี่ยวกับสิ่งนี้อีกแล้วคุณบอกเราแล้วฉันจะคาดการณ์ว่าความเสียดทานที่คุณพบนั้นเกี่ยวข้องกับประสบการณ์

แม้ว่าคุณจะไม่ได้เป็นโปรแกรมเมอร์โดยมืออาชีพในฐานะมืออาชีพด้านไอทีที่คุณอาจได้เรียนรู้วิธีการทำสิ่งที่ถูกต้องในครั้งแรกการอ้างอิงถึงตัวคุณในอนาคตของคุณบ่งชี้ว่าคุณได้ทำให้เขา / เธอล้มเหลวในอดีต ไม่ไป

นักเรียน CS ชั้นปีที่ 2 ของคุณแม้ว่าจะมีพรสวรรค์ แต่ก็ขาดมุมมองในการทำเช่นนั้น (ถ้าคุณชอบฉันซ้ำ ๆ :)

เขา / เธอจะไม่เชื่อในคุณค่าของการแก้ไขสิ่งต่าง ๆ ตามที่คุณไปจนกว่าเขา / เธอจะมีรอยแผลเป็นจากความล้มเหลวในการทำเช่นนั้นหรือเป็นที่ปรึกษาในวัฒนธรรมที่มีวินัยทางวิศวกรรมที่ยอดเยี่ยมหรือทั้งสองอย่าง

บุคคลนี้อาจเป็นเพียร์การเขียนโปรแกรมของคุณ แต่ไม่ใช่เพียร์โครงการของคุณดังนั้นการทำเกมนี้เนื่องจากโปรเจ็กต์เพียร์อาจเป็นสาเหตุที่หายไป ถ้าคุณไม่พร้อมที่จะกินต้นทุนในอนาคต บางทีความสัมพันธ์อาจมีค่าพอสำหรับคุณ ในกรณีนั้นให้ผูกเชือกพอที่จะแขวนคอตัวเองและก้าวเข้าไปช่วยทำความสะอาดเมื่อคนนั้นถูกบังคับให้รับรู้ปัญหา

มิฉะนั้นประกันตัวและทำโครงการกับเพียร์หรือทำโครงการที่ปรึกษา / พี่เลี้ยงที่เป็นแบบไดนามิกจากเริ่มแรก


1

วิธีเพิ่มคะแนนเพิ่มเติมให้กับคำตอบที่ยอดเยี่ยมทั้งหมด:

  • ต้องใช้ความพยายามมากเท่าไรจึงจะทำให้โครงการเสร็จสิ้น? โปรดทราบว่าการตกแต่ง "10% สุดท้าย" นั้นใช้เวลานานกว่าที่ผู้คนคาดไว้มาก นั่นรวมถึงการทดสอบการเล่น / การปรับแต่งความสามารถในการใช้งานการรับมือกับแพลตฟอร์มเป้าหมายที่หลากหลายปล่อย ... ถ้าเป็นเกม iOS ก็จะมีการเซ็นรหัสและรับการตรวจสอบของ Apple สุจริตการตกแต่งอาจใช้เวลานานเท่ากับ "90%" ครั้งแรก และมันจะยากมากถ้ารหัสนั้นแย่ตามที่คุณแนะนำ (คุณสามารถเริ่มเล่นทดสอบได้ไหม)
  • ในความเป็นจริงแล้วผู้คนจะสนุกกับเกมของคุณมากแค่ไหน?
  • ระวัง "การลดต้นทุนการเรียนรู้ด้วยตนเอง" ประเมินว่าการลงทุน 10,000 บรรทัดของรหัสในแง่ของภาพใหญ่มองย้อนกลับไปที่ผลิตภัณฑ์สำเร็จรูปและไม่มีการมองในแง่ดีเกินควร
  • คุณสามารถทำต่อไปได้ถ้าใช้เวลาอีก 3 ปี? คุณสองคนมีรูปแบบการพัฒนาที่แตกต่างกัน (ไม่ใช่การจับคู่ทีมที่ดี) ดูเหมือนว่าคุณใกล้จะหมดความอดทนแล้วและถ้าคุณยังคงทำต่อไปมันคงเป็นการยากที่จะเป็นเพื่อนกัน

3
"10% สุดท้าย" ใช้เวลานานกว่านี้หากรหัส 90% เป็นขยะ :-(
gnasher729

0

คุณควรทำโค้ดในแบบที่คุณคิดว่าถูกต้องพร้อมแสดงความคิดเห็นและทำสำเนาของรหัสเวอร์ชั่น (ในกรณีที่เขาเปลี่ยนรหัสของคุณ)

อย่าต่อสู้อย่าโกรธแค่ยิ้มเมื่อคุณเห็นการตัดสินใจที่ไม่ดีของเขา

บ่นในฐานะผู้ใช้เท่านั้นหากใช้งานได้อย่าบ่น

อย่ายอมแพ้เช่นกันเป็นสิ่งสำคัญที่จะต้องคุ้นเคยกับคนที่แตกต่างจากคุณซึ่งจะเกิดขึ้นในงานจริง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.