การจัดการกับเพื่อนร่วมงานเมื่อมีการพัฒนาต้องการคำแนะนำ [ปิด]


20

ผมพัฒนาสถาปัตยกรรมโครงการปัจจุบันของเราและเริ่มพัฒนามันในตัวเอง(บางสิ่งบางอย่างถึงชอบ )revision 40

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

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

ตอนนี้สิ่งที่ทำ:

  • ฉันเริ่มต้นการใช้งานอินเทอร์เฟซที่เกี่ยวข้องบางอย่างย้ายบางไลบรารีที่สะดวกและเขียนส่วนการปรับใช้สำหรับบางส่วนของแอปพลิเคชัน
  • ฉันมีเอกสารที่อธิบายถึงรูปแบบการเข้ารหัสและตัวอย่างของการใช้รูปแบบการเข้ารหัสนั้น (รหัสที่เป็นลายลักษณ์อักษรของฉันเอง)
  • ฉันบังคับให้ใช้C++เทคนิคการพัฒนาที่ทันสมัยมากขึ้นหรือน้อยลงรวมถึงno-deleteโค้ด (ซึ่งพันผ่านตัวชี้อัจฉริยะ) และอื่น ๆ
  • ฉันบันทึกวัตถุประสงค์ของการใช้งานอินเทอร์เฟซที่เป็นรูปธรรมและวิธีการใช้งาน
  • การทดสอบหน่วย(ส่วนใหญ่เป็นการทดสอบการรวมเนื่องจากไม่มีรหัส "จริง" จำนวนมาก)และชุด mocks สำหรับ abstractions หลักทั้งหมด

ฉันขาดเป็นเวลา 12 วัน


สิ่งที่เรามีตอนนี้ (โครงการพัฒนาโดยสมาชิก 4 คนในทีม):

  • ที่แตกต่างกัน 3 รูปแบบการเข้ารหัสทั่วโครงการ(ฉันเดาสองของพวกเขาตกลงที่จะใช้รูปแบบเดียวกัน :) , เช่นเดียวกับการตั้งชื่อของแนวคิดของเรา(เช่นCommonPathData.h, SubwaySchemeStructures.h)ที่มีพื้นส่วนหัวประกาศโครงสร้างข้อมูลบางส่วน
  • ไม่มีเอกสารประกอบสำหรับชิ้นส่วนที่เพิ่งนำมาใช้อย่างสมบูรณ์
  • สิ่งที่ฉันสามารถเรียกว่าsingle-purpose-abstractionตอนนี้จัดการกับเหตุการณ์ที่แตกต่างกันอย่างน้อย 2 ชนิดมีการมีเพศสัมพันธ์อย่างแน่นหนากับส่วนอื่น ๆ และอื่น ๆ
  • ครึ่งหนึ่งของอินเทอร์เฟซที่ใช้มีตัวแปรสมาชิก(sic!)แล้ว
  • การใช้ตัวชี้แบบ Raw เกือบทุกที่
  • การทดสอบหน่วยถูกปิดใช้งานเนื่องจาก " (Rev.57) They are unnecessary for this project"
  • ... (ที่อาจจะไม่ได้ทุกอย่าง)

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

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


ในกรณีนี้มีอะไรที่เป็นไปได้บ้างไหม

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

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


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

คุณช่วยปรับปรุงชื่อคำถามของคุณได้ไหม ชื่อปัจจุบันนั้นคลุมเครือและไม่ได้ระบุลักษณะคำถามของคุณ
Robert Harvey

1
สวัสดี Yippie-Kai-Yay มันไม่ชัดเจนจากคำถามของคุณว่าปัญหาในทางปฏิบัติและแก้ไขได้ที่คุณกำลังขอให้เราคืออะไร Programmers.SE ไม่ใช่กระดานสนทนาที่คุณสามารถคุยโวเกี่ยวกับปัญหาของวัน: คุณสามารถระบุปัญหาเฉพาะที่คุณต้องการความช่วยเหลือจากโปรแกรมเมอร์ผู้เชี่ยวชาญและถามเกี่ยวกับสิ่งนั้นได้หรือไม่?

1
@ Mark ฉันคิดว่าถ้าอย่างน้อย 12 คนคิดว่าหัวข้อนี้มีประโยชน์และมีบางอย่างที่จะพูดคุยการปิดเป็นเรื่องแปลก
Yippie-Kai-Yay

1
ฉันคิดว่าสิ่งนี้สามารถสร้างเป็นคำถามที่เกี่ยวข้องได้ (แทนที่จะถูกปิดเพียงอย่างเดียว) ซึ่งเกี่ยวข้องกับการจัดการโครงการและการทำงานเป็นทีมซึ่งเป็นส่วนสำคัญของการเขียนโปรแกรมและการพัฒนา
Ross

คำตอบ:


18

Refactor อย่างไร้ความปราณีที่จะออกจากความวุ่นวาย!

ใช้รูปแบบการเข้ารหัสที่คำนึงถึงลักษณะส่วนใหญ่ที่สามารถใช้งานได้และใช้สำหรับโครงการนี้

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

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


ฉันคิดว่านี่เป็นคำตอบที่แท้จริงเพียงสถานการณ์เดียว
Robert Harvey

เมื่อฉันมีการทดสอบที่มั่นคงฉันไม่ลังเลที่จะทำลายทุกอย่างเมื่อรหัสที่ไม่เหมาะสมถูกส่ง มันเป็นกุญแจสำคัญในการรักษาโครงการ
deadalnix

@dead: อืมนั่นหมายความว่ายังไงเหรอ?
Robert Harvey

@ Robert การทดสอบหน่วยการเขียนที่ถูกต้องนั้นดีมากสำหรับการ refactoring เพราะคุณสามารถเปลี่ยนแปลงสิ่งต่างๆได้อย่างง่ายดายและยังมั่นใจได้ว่าโปรแกรมของคุณถูกต้อง
Yippie-Kai-Yay

@ Robert> ซึ่งหมายความว่าคุณไม่ควรลังเลที่จะใส่รหัสลงในถังขยะเมื่อมันไม่ดีพอ หากคุณมีการทดสอบที่แน่นหนาคุณสามารถเติมโค้ดที่มีคุณภาพดีขึ้นและตรวจสอบให้แน่ใจว่ามันจะทำงานในลักษณะเดียวกันกับส่วนที่เหลือของโปรแกรม
deadalnix

10

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

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

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

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

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


ความคิดที่ดีฉันอาจต้องคิดใหม่บางอย่าง ขอขอบคุณ,.
Yippie-Kai-Yay

8

คู่.

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

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


2
ฉันเคยได้ยินเรื่องการจับคู่กันมากมาย แต่ฉันไม่เคยได้ยินใครทำจริง ๆ และได้รับประโยชน์
Robert Harvey

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

มันได้ผล. มันใช้งานได้หากนักพัฒนามีประสบการณ์และความสามารถในการเปรียบเทียบและทำงานได้กับทั้งนักพัฒนาหากทักษะไม่ตรงกัน มันน่าทึ่งที่นักวิจารณ์เรื่องการจับคู่ดูเหมือนจะไม่เคยลองเลย ฉันได้ทำมัน; ฉันทำมัน. มันได้ผล.
Carl Manaster

@Carl Manaster> มันทำงานกับคู่ที่เหมาะสม ฉันทำมันสำเร็จหลายครั้ง แต่ตอนนี้ฉันช้าลงและสร้างรหัสที่แย่กว่ากับคู่ที่แท้จริงของฉันมากกว่าโซโล ดังนั้นจึงเป็นเรื่องสำคัญที่จะจับคู่กับคนที่ใช่
deadalnix

@Carl Manaster - ฉันประหลาดใจเสมอที่ผู้คนยืนยันที่จะลองอะไร - ทางทีวีวิทยุฟอรั่มลัทธิทางศาสนา ฯลฯ การพยายามหรือที่รู้จักกันในชื่อหลักฐานทางประวัติศาสตร์ไม่ใช่วิธีการพิสูจน์อะไร ทำกรณีตรงประเด็นก่อนจากนั้นคุณสามารถพูดคุยเกี่ยวกับการทดลอง
Gene Bushuyev

7

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


3

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

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

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

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


2

สิ่งหนึ่งที่ฉันไม่ได้เห็นกล่าวถึง แต่เมื่อเร็ว ๆ นี้ที่ฉันทำงานอยู่ที่ปัญหาของ "นักพัฒนาไซโล" และ "ซื้อใน"

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

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

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

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


1

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

เนื่องจากคุณกำลังเผชิญกับเส้นตายที่เข้มงวดคุณอาจต้องจัดส่งรหัสตามที่เป็นอยู่และ refactor (rewrite?) หลังจากการเปิดตัวของคุณ

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

แก้ไข:

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

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


1

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

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

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

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