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


29

ฉันมีงานจริงครั้งแรกของฉันในฐานะโปรแกรมเมอร์ แต่ฉันไม่สามารถแก้ปัญหาใด ๆ ได้เพราะใช้รูปแบบการเข้ารหัส รหัสที่นี่:

  • ไม่มีความคิดเห็น
  • ไม่มีฟังก์ชั่น (เรียงตามลำดับ 50, 100, 200, 300 หรือมากกว่า)
  • ใช้ข้อความมากมายที่ifมีเส้นทางจำนวนมาก
  • มีตัวแปรที่ทำให้รู้สึกไม่ (เช่น .: cf_cfop, CF_Natop, lnom, r_procod)
  • ใช้ภาษาเก่า (Visual FoxPro 8 จากปี 2002) แต่มีรุ่นใหม่จากปี 2007

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

แก้ไข : คำตอบทั้งหมดดีมาก สำหรับความหวังของฉัน (un) ปรากฏว่ามีฐานรหัสประเภทนี้มากมายทั่วโลก จุดที่กล่าวถึงคำตอบทั้งหมดคือ refactor รหัส ใช่ฉันชอบที่จะทำมัน ในโครงการส่วนบุคคลของฉันฉันทำเช่นนี้เสมอ แต่ ... ฉันไม่สามารถกำหนดรหัสซ้ำได้ โปรแกรมเมอร์จะได้รับอนุญาตให้เปลี่ยนไฟล์ในงานที่ออกแบบมาเท่านั้น

ทุกการเปลี่ยนแปลงในรหัสเก่าจะต้องเก็บไว้ในรหัส (แม้จะมีการโค่นล้มเป็นตัวควบคุมรุ่น) รวมทั้งข้อมูล meta (วันที่โปรแกรมเมอร์งาน) ที่เกี่ยวข้องกับการเปลี่ยนแปลงนั้น (กลายเป็นระเบียบมีรหัสที่มี 3 บรรทัดที่ใช้และ 50 บรรทัดเก่าแสดงความคิดเห็น) ฉันคิดว่าไม่เพียง แต่ปัญหารหัส แต่เป็นการจัดการปัญหาการพัฒนาซอฟต์แวร์


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

12
คุณไม่ได้หายไปมากโดยไม่ได้ใช้ความคิดเห็น หากมีคนมากเกินไปพวกเขา
JohnFx

22
@JohnFx ไม่เห็นด้วยกับคุณ แต่ต้องเผชิญกับอึอึที่ไม่มีความคิดเห็นมากกว่าสองสามข้อฉันจะบอกว่าฉันชอบความคิดเห็นที่ซ้ำซ้อน / ล้าสมัยมากกว่าที่จะไม่มีความคิดเห็นเลย
yannis

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

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

คำตอบ:


0

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

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

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

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


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

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

1
@Ramhound รหัสมรดกก็โอเค การเขียนรหัสดั้งเดิมวันนี้ไม่เป็นไร
Renato Dinhani

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

อัปเดตหลังจาก 6 ปี: ฉันออกจาก บริษัท นั้นไม่กี่วันหลังจากโพสต์คำถามนี้และมองย้อนกลับไปมันเป็นการตัดสินใจที่ดีที่สุดที่ฉันทำ ฉันมีโอกาสได้ทำงานในโครงการอื่น ๆ อีกหลายแห่งใน บริษัท อื่น ๆ และพวกเขาไม่มีการปฏิบัติที่ไม่ดีเหมือนกันหรือขาดคุณภาพที่ฉันพบในงานแรก การอยู่บ้านการเรียนรู้สถานะของตลาดงานในปัจจุบันทำให้ฉันสามารถทำงานในโครงการที่น่าสนใจและ บริษัท ที่ดีกว่า
Renato Dinhani

35

สไตล์การเข้ารหัสนี้ (ถ้าคุณต้องการเรียกมันว่าสไตล์ใดก็ได้ ) เป็นสไตล์การเขียนโค้ดที่ไม่ดี

หนึ่งสามารถเขียนฟังก์ชั่นสั้น ๆ ที่มีชื่อตัวแปรอธิบายและการควบคุมการไหลของสติในภาษาที่ทันสมัยที่สุด (Visual FoxPro เป็นทันสมัยใช่)

ปัญหาที่คุณมีอยู่กับฐานรหัสไม่ดีไม่มีอะไรมากไม่น้อยไปกว่านี้

รหัสฐานนั้นมีอยู่จริงและมีอยู่มากมาย - ความจริงที่ว่าคุณกำลังมีปัญหากับพวกเขายืนยันว่าพวกเขาเลว (และคุณได้รับการฝึกฝนที่ดี)

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

ฉันอยู่ในโครงการ C # ที่มีโครงสร้างไม่ดีมากไม่ห่างจากสิ่งที่คุณอธิบาย เพียงรวมฟังก์ชั่นแยกต่างหาก 12 ฟังก์ชั่น (คัดลอกอย่างชัดเจน) ลงในฟังก์ชันที่ใช้พารามิเตอร์เดียว


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

9
@ tp1 - ใช่ แต่คุณต้องยอมรับว่า codebase แรกที่คุณพบอาจทำให้ระบบตกใจ
Oded

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

13
@ RenatoDinhaniConceiçãoฉันไม่เคยคิดที่จะจ้างนักพัฒนาเพื่อทำการออกแบบดั้งเดิมที่ไม่ได้ทำเวลาของเขาหรือเธอในการบำรุงรักษาคุณไม่สามารถเป็นนักออกแบบที่ดีโดยไม่ต้องมีประสบการณ์นี้ (ความล้มเหลวในการทำสิ่งนี้เป็นหนึ่งใน ประสบการณ์ของฉัน). คุณไม่สามารถเป็นโปรแกรมเมอร์ที่ดีและไม่ดีต่อการบำรุงรักษา คุณอาจไม่ชอบ แต่จำเป็นต้องเข้าใจวิธีการออกแบบให้ดี และความสามารถในการทำงานหนักอย่างหนักนั้นเป็นลักษณะของโปรแกรมเมอร์ที่ดีด้วย ถ้ามันง่ายพวกเขาคงไม่ต้องการเรา
HLGEM

8
@ tp1 การทำงานควรสนุกและเกมไม่อย่างนั้นคุณทำผิด
Kevin McCormick

18

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

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

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

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


4
"วิธีการออกแบบที่ดีนั้นไม่ได้รับความนิยมเสมอไป" มันไม่ได้เกี่ยวกับความนิยม การออกแบบที่ดีหรือการปฏิบัติที่ดีที่สุดนั้นถือเป็นสิ่งที่ดี เป็นสิ่งที่ควรคำนึงถึงเมื่อดูรหัสเก่า
Burhan Ali

@BurhanAli, abosiolutely, สิ่งที่เป็นแนวปฏิบัติที่ดีในปี 2000 เมื่อใบสมัครของเราได้รับการออกแบบ orginally ไม่ได้เป็นวิธีปฏิบัติที่ดีในขณะนี้ นักพัฒนาซอฟต์แวร์อายุน้อยมักไม่รู้ว่าสิ่งที่พวกเขาได้รับการสอนเป็นแนวปฏิบัติที่ดีที่สุดอาจไม่มีอยู่ในขณะที่เขียนโค้ดหรืออาจไม่สามารถใช้งานได้กับภาษาเก่าที่ซอฟต์แวร์ใช้
HLGEM

2
ฉันไม่คิดว่าฟังก์ชั่น 500 บรรทัดถือว่าเคย "ดี" ... หนังสือหลักที่ฉันได้เรียนรู้การประกอบจากด้านหลังในยุค 80 กล่าวว่าคุณควรจะแยกสิ่งต่าง ๆ ออกเป็นรูทีนย่อยเมื่อพวกมันเริ่มใหญ่เกินไปจนแตกกิ่ง เพื่อเริ่มต้น ที่อยู่ระหว่าง 40-120 บรรทัดบนโปรเซสเซอร์นั้น (6502)
mjfgates

11
  • ไม่มีความคิดเห็น - แก้ไขเมื่อคุณเรียนรู้
  • ไม่มีฟังก์ชั่น (เรียงตามลำดับ 50, 100, 200, 300 หรือมากกว่า)

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

  • ใช้ข้อความมากมายที่มีเส้นทางมากมาย - จริง ๆ แล้วฉันไม่แน่ใจว่าคุณหมายถึงอะไรที่นี่
  • มีตัวแปรที่ไม่สมเหตุสมผล (เช่น: cf_cfop, CF_Natop, lnom, r_procod) -

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

  • ใช้ภาษาที่ฉันไม่คุ้นเคยกับ (Visual FoxPro 8 จากปี 2002) - นี่คือปัญหาของคุณไม่ใช่รหัส

7
1: นี่คือปัญหาของคุณไม่ได้ :) ของรหัส
aleroot

จุดสุดท้ายของเขาไม่ถูกต้องตามหลักไวยากรณ์ ฉันไม่เข้าใจความหมายดั้งเดิมของเขา ฉันเดาและฉันอาจเดาผิดดังนั้นเขาอาจไม่ได้หมายความว่าเขาไม่คุ้นเคยกับ Visual FoxPro
Myrddin Emrys

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

3
@ RenatoDinhaniConceiçãoเป็นเรื่องปกติที่จะไม่อัปเกรดผลิตภัณฑ์ฐานข้อมูลเนื่องจากการอัปเกรดทำลายสิ่งที่ใช้งานได้ในปัจจุบันและไม่มีเงินหรือเวลาที่จะใช้ในการเปลี่ยนแปลงที่คุณไม่จำเป็นต้องทำหากคุณรักษาเวอร์ชันเก่าไว้ นี่คือตัวเลือกธุรกิจ
HLGEM

1
@renato แอปพลิเคชันฐานข้อมูลส่วนใหญ่ไม่สามารถใช้งานร่วมกับระบบย้อนหลังได้อย่างง่ายดาย
HLGEM

11

เสียงนี้กับผมเหมือนโอกาส

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

ตอนนี้มันจะไม่ช่วยคุณถ้าคุณเดินไปหานายจ้างและบอกเขาว่าทุกอย่างต้องเปลี่ยน ดังนั้นเคล็ดลับคือการเล่นไปซักพักถามคำถามมากมายและเมื่อคุณจำเป็นต้องเขียนโค้ดคุณจะต้องเล่นตามกฎของพวกเขาพร้อมกับความคิดเห็นอื่น ๆ ทั้งหมดเนื่องจากคุณจะต้องให้นักพัฒนาคนอื่น ๆ แจ้งการใช้ระบบใดก็ตามที่พวกเขาต้องการในขณะนี้ในเวลาเดียวกันคุณสามารถแนะนำ refactorings ที่เหมาะสมที่จะไม่เสี่ยงคุณอะไร คุณสามารถแยกวิธีการได้สองวิธีและหากภาษาของคุณรองรับให้แนะนำการทดสอบหน่วยสองสามข้อ เมื่อถูกถามว่าทำไมคุณถึงทำแบบนี้หรือถ้าบอกว่าคุณกำลังทำอะไรผิดพลาดให้หลีกเลี่ยงการรับหรือโต้แย้งในขณะที่ทำการนำเสนอตำแหน่งของคุณสำหรับรูปแบบการเข้ารหัสที่คุณต้องการ ตัวอย่างเช่น, คุณสามารถอ้างถึงหนังสืออย่างเช่น Clean Code ของ Bob Martin หรือคุณสามารถอ้างถึงหนังสือบทความหรือคำถามและคำตอบอื่น ๆ ที่คุณพบใน Programmers.SE อะไรก็ตามที่คุณสามารถเป็นประโยชน์ในการสนับสนุนตำแหน่งของคุณด้วยข้อเท็จจริงที่อาจเกินกว่าประสบการณ์ของคุณในสายตาของคนที่คุณทำงานด้วย

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

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


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

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

1
@deadalnix งานแรกไม่ค่อยมีโอกาสเลือกคนที่คุณทำงานด้วย บ่อยครั้งที่คุณไม่ทราบว่ามีคนสนใจเรื่องคุณภาพของรหัสมากน้อยเพียงใดจนกว่าคุณจะได้ทำงานกับพวกเขามาระยะหนึ่งแล้ว คำตอบของฉันช่วยให้ OP เข้าใจสิ่งนี้ คำแถลงเกี่ยวกับการไม่สามารถทดสอบหน่วยของคุณก่อนที่จะทำการเปลี่ยนสถานะใหม่นั้นผิดปกติ พยายาม refactor ก่อนทดสอบหน่วยเพิ่มความเสี่ยงโดยรวม การติดตามบั๊กที่ไม่มีการทดสอบนั้นไม่มีประสิทธิภาพและทำให้หมดแรง ผู้ที่ใส่ใจเกี่ยวกับคุณภาพของรหัสมุ่งเน้นที่การทดสอบและเทคนิคการเขียนโค้ดที่สะอาด ฉันไม่ได้รับการคัดค้านโดยนัยของคุณมีความสุขที่จะพูดคุยเกี่ยวกับเรื่องนี้ออฟไลน์ :-)
S.Robins

@ S.Robins ข้อผิดพลาดในการไล่ล่าที่ไม่มีการทดสอบนั้นไม่มีประสิทธิภาพและการหลบหนีและการทำให้กลับเป็นซ้ำโดยไม่ต้องมีความเสี่ยงน้อยมาก (และทั้งสองอย่างรวมกันอย่างดี) นี่คือสาเหตุที่สถานการณ์เช่นนี้เป็นฝันร้าย รหัสฐานข้อมูลขนาดใหญ่แบบดั้งเดิมมักไม่สามารถใช้ได้ (เต็มไปด้วยสถานะสากล, การพึ่งพา hardcoded ในระบบการผลิตหรือในระบบอื่น ๆ , ไม่มีการแยกข้อกังวล, การทำซ้ำรหัสจำนวนมาก, ฯลฯ .) คุณจะต้องโยนรหัสการเปลี่ยนผ่านครั้งแรกเพื่อให้รหัสไม่สามารถต้านทานได้ ฉันคิดว่าเราทั้งคู่เห็นด้วยกับเรื่องการเขียนโค้ดของปัญหา แต่เข้าใจผิดกัน
deadalnix

1
นอกจากนี้ยังเป็นโอกาสในการรวบรวมเนื้อหาสำหรับthedailywtf.com
Arkh

8

ยินดีต้อนรับสู่ป่า !

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

คำแนะนำของฉันคือ:

  1. เริ่มเรียนรู้และทำความคุ้นเคยกับ: ภาษาโปรแกรมที่ใช้ (Clipper / dBase) และสภาพแวดล้อม (Visual FoxPro)

  2. อ่านและวิเคราะห์ฐานรหัสและเริ่มแสดงความคิดเห็น

  3. การจัดระเบียบ / การ refactoring รหัส (การจัดการปัญหาของบรรทัดมากเกินไปดำเนินการตามลำดับ)

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


7

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

ฤดูร้อนปีที่แล้วฉันทำงานเป็นฝึกงานเพื่อพัฒนาแอปพลิเคชันที่จะใช้โดยทีมงาน QA ที่แนบกับแผนกเฉพาะ ทีมงาน QA ใช้สคริปต์แบบสแตนด์อโลนจำนวนมาก (VBScript, Perl, Bash) เพื่อทดสอบกับฐานข้อมูลและพวกเขาต้องการรวมพวกมันทั้งหมดไว้ในแอปพลิเคชันเดียว อย่างไรก็ตามปัญหาเกี่ยวกับเรื่องนี้คือสคริปต์เหล่านั้นถูกใช้งานที่อื่นใน บริษัท (ดังนั้นชื่อฟังก์ชัน / ตัวแปรหลักไม่สามารถเปลี่ยนแปลงได้) และรหัสนั้นถูก "เพิ่มไปยัง" เป็นเวลาเกือบ 10 ปี อึมากมายได้สร้างขึ้น

สิ่งที่คุณสามารถทำได้มีดังนี้:

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

ตราบใดที่คุณลักษณะภายนอกของโค้ดทำงานอย่างเหมาะสมมันก็ไม่สำคัญว่า internals จะทำงานอย่างไร


+1 สำหรับ "ขอความช่วยเหลือ" การทำงานเป็นทีมช่วยเพิ่มค่าใช้จ่าย แต่ก็นำประโยชน์

7

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

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

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

หวังว่านี่จะช่วยได้


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

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

5

หนึ่งในสิ่งที่โดดเด่นคือความคิดเห็นที่คุณแก้ไข

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

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

ฉันจับสำเนา scx ของเครื่องมือ Paul McNett http://paulmcnett.com/scX.phpและรวมเข้ากับวงจรการพัฒนาของฉัน มันทำงานได้ค่อนข้างดีในการแยกรหัส FoxPro ไบนารีไปเป็นรูปแบบข้อความที่สามารถใส่ลงในแหล่งเก็บข้อมูลต้นฉบับได้เช่น Subversion, Mercurial หรือแม้แต่คอมไพล์ (คุณอาจพบโครงการ SubFox ได้ที่http://vfpx.codeplex.comมีประโยชน์

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


4

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

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

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

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

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

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

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

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

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

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

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