ฉันถูกบังคับให้เขียนรหัสไม่ดี ฉันจะบันทึกใบหน้าของฉันได้อย่างไร [ปิด]

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

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

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

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

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

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

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

ดังนั้น ... เขียนรหัสที่ไม่ถูกต้อง ... จำนวนมาก ... รหัสที่ใช้งานได้จริงและจากนั้นทำซ้ำ การวนซ้ำทุกครั้งดีขึ้นเล็กน้อย!

ไม่มีใครเขียนคำตอบที่สมบูรณ์แบบในครั้งแรก

* อันนี้มันสั้นกว่านี้ไหมถ้าเป็นความคิดเห็น

ความคิดเห็นเกี่ยวกับรหัสคือเพื่อนของคุณที่นี่

เมื่อใดก็ตามที่คุณรู้สึกว่าคุณต้องเขียนแฮ็คราคาถูกเพราะความกดดันเพียงพูดอะไรทำนองนี้ "รหัสนี้ทำ X เนื่องจากข้อ จำกัด ด้านเวลาในอุดมคติแล้วฉันจะทำ Y แทน - Ashamed One, 5 กรกฎาคม 2011"

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

ขึ้นอยู่กับว่าพวกเขาบังคับคุณอย่างไร

จากประสบการณ์ของฉันมีความเป็นไปได้สองอย่าง:

คุณรู้สึกว่าถูกบังคับโดยกำหนดเวลาที่เข้มงวดรหัสดั้งเดิม ฯลฯ

ในกรณีนี้คำตอบอื่น ๆ ส่วนใหญ่พูดแล้วมันขึ้นอยู่กับคุณที่จะ 'เพิ่มประสิทธิภาพเพื่อความเย็น' คุณอาจไม่มีเวลาที่จะเขียน codebase เป็น MVC แต่เป็นขั้นตอนแรกคุณสามารถหยุดกาว SQL ของคุณด้วยมือและแทนที่จะเขียนดีexecute_sql($query, $params)ที่วางรากฐานสำหรับ abstractions เช่นfetch_customer($filter_params)ฯลฯ จำไว้ว่าสิ่งที่ดีที่สุด ในที่สุดก็มีวิธีปฏิบัติที่เจ้านายของคุณได้รับผลิตภัณฑ์ก่อนหน้านี้ดังนั้นจึงมีเพียงความขัดแย้งในระยะเวลาที่จะลงทุนในอนาคตเทียบกับในปัจจุบัน

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

คุณได้รับคำสั่งให้ใช้งานอย่างชัดเจนในแบบที่คุณไม่เห็นว่าเหมาะสม

ความพยายามในการแยกมุมมองจากแบบจำลองไม่สามารถอยู่รอดจากการตรวจทานได้เพราะ 'มันซับซ้อนเกินไปทำไมคุณไม่ลองคำสั่ง sql ธรรมดา' คุณexecute_sqlได้รับการบรรจุกระป๋องเพราะ 'coder ที่มีวินัยไม่จำเป็นต้องใช้'

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

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

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

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

หากทุกอย่างล้มเหลวให้ไปหางานอื่น

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

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

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

รหัสที่ดีที่สุดในโลกไม่สำคัญว่าจะล้าสมัยก่อนที่จะเผยแพร่หรือไม่

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

ต้องใช้ประสบการณ์มากมาย (มากกว่าตัวเข้ารหัสส่วนใหญ่ที่เคยมี) เพื่อให้ได้สมดุลนี้ มันง่ายมากที่จะไปให้ไกลที่สุด การหาทางกลางนั้นยากกว่า

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

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

ฉันต้องการเพิ่มว่าคุณไม่ควรดำเนินการต่อเหมือนตอนนี้โดยไม่พูดอะไรและแค่แฮ็คและแฮ็ค

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

ฉันแน่ใจว่ามีเครื่องมือมากมายให้ใช้งานฟรีสำหรับการวิเคราะห์โค้ด php http://en.wikipedia.org/wiki/Code_analysis

นอกจากนี้แน่นอนhttp://en.wikipedia.org/wiki/Code_smellนี้

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

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

HTH

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

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

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

เพื่อเป็นตัวอย่างของฉันฉันเคยไปถึงกลางโครงการด้วยแอปพลิเคชั่น Perl / CGI ที่ HTML ทั้งหมดอยู่ในรหัส แอปทั้งหมดอยู่ในไฟล์เดียวโดยไม่มีโครงสร้างที่ชัดเจน ไม่มีอะไรเป็นเวอร์ชัน ฉันเริ่มต้นด้วยการกำหนดค่า CVS repo (ไม่มี SVN ให้บริการในเวลานั้น) ใส่เว็บอินเตอร์เฟสไว้ให้ลูกค้า ตอนแรกฉันจัดการกับข้อผูกพันจากเพื่อนร่วมงานด้วยตัวเอง จากนั้นฉันแบ่งวิธีทั้งหมดเป็นโมดูล (ไฟล์) ที่แตกต่างกัน เมื่อถึงตอนนั้นเพื่อนร่วมงานก็เริ่มนำ CVS มาใช้ จากนั้นฉันย้าย HTML ออกจากรหัส จากนั้นทุกครั้งที่ฉันต้องทำการเปลี่ยนแปลงบางส่วนของรหัสฉันใช้เวลาสักครู่เพื่อปรับโครงสร้างบางส่วนของมัน ในที่สุดความเร็วการพัฒนาเพิ่มขึ้นมากจนลูกค้ามีความสุขมาก พวกเขาจะขอเปลี่ยนแปลงเครื่องสำอางและแทนที่จะบอกพวกเราว่า "จะใช้เวลา 2 วัน"

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

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

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