การช่วยคนที่ไม่ได้เป็นและไม่เคยเป็นนักเขียนโปรแกรมมืออาชีพที่สามารถอ่านและใช้งานและตีความได้ง่ายกว่า [ปิด]

ฉันคือ Elvis พยายามอย่างหนักที่จะเรียนรู้ที่จะเป็น Einstein ฉันทำงานให้มอร์ท

คนบ้านี้มันบ้าอะไรกันเนี่ย!?!? (คุณจะต้องอ่านสองสามย่อหน้าแรก)

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

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

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

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

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

แทนที่จะบ่นเกี่ยวกับนักวิทยาศาสตร์และคาดว่าพวกเขาจะเปลี่ยนแปลงเพียงแค่ตระหนักว่าคุณไม่ควรคาดหวังว่านักวิทยาศาสตร์จะสนใจ "คุณภาพของรหัส" มากนัก บ่อยครั้งที่ยากนักที่จะให้นักพัฒนาซอฟต์แวร์รายอื่นสนใจเกี่ยวกับ "คุณภาพของรหัส" ให้กับคนที่มีความสนใจหลักอยู่ในโดเมน

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

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

เป็นส่วนหนึ่งของกระบวนการทดสอบของคุณ:

1. เริ่มเปลี่ยนอัลกอริทึมเป็นสิ่งที่เข้าใจง่ายขึ้น (เช่นไดอะแกรม, PDL, สัญกรณ์คณิตศาสตร์)
2. เรียนรู้ที่จะเข้าใจอัลกอริทึม
3. ต้องแน่ใจว่าได้ระบุตัวเรือนขอบ
4. ถามนักวิทยาศาสตร์ว่าการแสดง "ทางเลือก" แบบง่าย ๆ ของคุณนั้นถูกต้องหรือไม่
5. และระบุปัญหาที่คุณพบอย่างสำคัญที่สุด และไม่มีการฟัง "กล่าวหา" พูดอะไรบางอย่างเช่น "ฉันกำลังดูอัลกอริธึมและสังเกตว่า XYZ ควรทำเช่นนี้หรือว่าควรทำอย่างนั้น?" ไม่มีอะไรจะได้รับความมั่นใจดีกว่ากระสุนนี้

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

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

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

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

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

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

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

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

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

หากเป้าหมายของคุณคือ:

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

2. ช่วย บริษัท ของคุณ? สถานการณ์ปัจจุบันกำลังคุกคามผลประกอบการหรือไม่? กำหนดเวลามีความเสี่ยงหรือไม่? ผู้บริหารระดับสูงกำลังเพิ่มความร้อนหรือไม่? ถ้าไม่เช่นนั้นก็ให้มันได้ (นี่คือประเด็นสำคัญที่ Jimmy Hoffa แสดงความคิดเห็นในโพสต์ต้นฉบับของคุณ) อย่างไรก็ตามหากสถานการณ์ปัจจุบันในความเป็นจริงแล้วเป็นความเสี่ยงที่ยอมรับไม่ได้สำหรับแผนก / บริษัท ของคุณการเปลี่ยนแปลงของกระบวนการจะเป็นไปตามลำดับ ในกรณีนี้ฉันขอแนะนำให้คุณนั่งลงและร่างที่แตกต่างกันการแบ่งงาน กุญแจสำคัญในที่นี้คือเพื่ออธิบายว่าเวลาที่คุณใช้ refactoring code ของเจ้านายของคุณจะดีกว่าการเขียนโค้ดใหม่ คุณบอกว่าคุณไม่มีเวลาเขียนด้วยตัวเองทั้งหมด แต่นั่นไม่ใช่สิ่งที่ฉันแนะนำ คุณต้องหาวิธีเพิ่มความแข็งแกร่งให้กับคุณ หยุดคิดถึงเขาในฐานะ Mort และคิดว่าเขาเป็นนักพัฒนารุ่นน้องที่มีความรู้ด้านโดเมนที่เหนือกว่า ที่เป็นมากการจัดเรียงการทำงานร่วมกันในอุตสาหกรรมและมันจะ behoove คุณเรียนรู้วิธีที่จะเจริญเติบโตอยู่ในนั้น ตัวอย่างเช่นตรวจสอบให้แน่ใจว่าเขารู้ว่าคุณรู้ว่าความเชี่ยวชาญของเขานั้นสำคัญเพียงใด (ทำซ้ำขั้นตอนนี้บ่อยครั้ง) และจากนั้นแนะนำกลยุทธ์ต่อไปนี้ (หรือบางอย่างที่คล้ายกัน) อย่างถ่อมใจเพื่อให้ได้ความรู้สู่ตลาด: (a) แบ่งงานออกเป็น "เปรียว" เปรย (b) ร่วมมืออย่างหนักล่วงหน้า (ในแต่ละการวิ่ง) กำหนดมากกว่า - ข้อกำหนดและสถาปัตยกรรมทั้งหมด (c) ให้เขาลงไปและสร้างต้นแบบเพื่อตัดสินใจเรื่องอัลกอริทึมทั้งหมดในขณะที่คุณสร้างโครงสร้างพื้นฐานที่คุณเห็นด้วยในขั้นตอนก่อนหน้า (d) ใช้อัลกอริทึมของเขาในโครงสร้างของคุณในขณะที่เขาสร้างการทดสอบเพื่อตรวจสอบ (e) ดำเนินการ V&V ของคุณร่วมกันในสภาพแวดล้อมการเขียนโปรแกรมแบบเพื่อน (เช่น "การทดสอบนี้ล้มเหลวเพราะเหตุใดข้อผิดพลาดเชิงตรรกะของอัลกอริทึมหรือการเข้ารหัสผิดพลาด"; ทำซ้ำที่นี่)

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

ฉันไม่แน่ใจว่าฉันจะเพิ่มบางอย่างในการสนทนานี้ แต่ต้องทำงานในสถานการณ์ที่คล้ายกันซึ่งการละเมิดการเข้าถึงถูกกดที่บรรทัดที่ShowMessage('Hello');คล้ายกันหรือเพียงเพื่อดูว่าบรรทัดเดียวกันมีรหัสมากกว่าออกจากหน้าจอไปที่ ขวา,

ฉันเชื่อว่าคุณมีสองตัวเลือกพื้นฐาน:

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