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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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