เลือกความพยายามในการออกแบบรหัสหรือความเกียจคร้านในโลกธนาคาร

ฉันทำงานเป็นเวลาสองปีในวาณิชธนกิจที่ยิ่งใหญ่

ฉันทำโครงการด้านเทคนิคบางอย่างด้วยความปรารถนาที่จะสร้างโค้ดที่มีประสิทธิภาพสูงสุดโดยคำนึงถึงรูปแบบการออกแบบที่ดีที่ปรับได้หลักการ SOLID กฎหมายของ demeter และหลีกเลี่ยงรหัสที่ซ้ำกันทุกประเภท ...

เมื่อส่งมอบในการผลิต => ศูนย์ข้อบกพร่องทั้งหมดเกิดขึ้นตามที่คาดไว้

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

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

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

หรือในทางตรงกันข้ามพวกเขาควรเรียนรู้หลักการ OO ขั้นพื้นฐานและแนวปฏิบัติที่ดีที่สุดเพื่อปรับตัวให้เข้ากับรหัสของฉันหรือไม่?

ผู้จัดการโครงการของฉันบอกว่าฉันผิดจริง ๆ และเป็นนักอุดมคติในโลกของธนาคาร

GTFO!

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

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

ใช่ฉันรู้ว่านี่ไม่ใช่คำตอบปกติของฉัน แต่จริง ๆ แล้วถ้าคุณไม่สามารถเล่นเกมการเมืองใน บริษัท นี้ GTFO

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

ฉันจะไม่ทำงานให้ บริษัท ที่ต้องการให้ฉันแก้ปัญหาที่ไม่ดี ฉันต้องการแกะสลักชื่อของฉันลงในซอฟต์แวร์ ฉันต้องการที่จะภาคภูมิใจของมัน ฉันไม่ได้เขียนแอพพลิเคชั่นขั้นตอนเป็นภาษาตามกระบวนทัศน์ OO ฉันเชื่อในซอฟต์แวร์คุณภาพสูงและหาก บริษัท ไม่ทำฉันจะ GTFO! หวังว่าคุณจะมีเงินมากพอ

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

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

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

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

มันเกิดขึ้นกับคุณได้มั้ย

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

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

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

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

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

สถานที่เดียวที่คุณใส่ใจในรายละเอียดและราคาเริ่มต้นจึงเป็นที่ยอมรับได้คือระบบวิกฤตชีวิตระดับ 1 เช่น Avionics / Aerospace, ยานยนต์, ทหารและการแพทย์

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

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

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

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

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

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

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

ยังดีกว่าไปที่ InfoQ และดูการพูดคุยของ Rich Hickey ใน"Simple Made Easy"

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

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

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

รหัสของคุณอาจมีคุณภาพสูง (ความเป็นจริง unproven) แต่พวกเขามีนโยบาย (แน่นอนว่าเป็นความจริงนรก)

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

อย่างไรก็ตามเพื่อนร่วมห้องมือถือของคุณยินดีที่จะได้ยินว่าคุณเดินเตร่เกี่ยวกับการขาดความอยากรู้อยากเห็นของเพื่อนร่วมงานเก่าของคุณ

(จากนั้นอีกครั้ง บริษัท ของคุณอาจไม่มีนโยบายภายในกับการออกแบบ OO แต่วิศวกรที่ผ่านการฝึกอบรมอย่าง COBOL ที่เงอะงะที่จะพยายามแก้ไขรหัสของคุณจะทำให้บางขึ้นจากอากาศและ IMHO ในสถานการณ์กรณีที่เลวร้ายที่สุดเขา ' จะมีโอกาส 40% ในการทำคะแนนการโจมตีคริติคอล)

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