คำถามติดแท็ก maintenance

ฉันหวังว่านี่ไม่ใช่คำถามทั่วไปเกินไป ฉันสามารถใช้คำแนะนำที่ปรุงรสได้จริงๆ ฉันเพิ่งได้รับการว่าจ้างให้เป็น "SW Engineer" แต่เพียงผู้เดียวในร้านค้าเล็ก ๆ ของนักวิทยาศาสตร์ที่ใช้เวลา 10-20 ปีที่ผ่านมาในการปูก้อนกรวดด้วยกันเป็นฐานรหัสที่กว้างใหญ่ (มันถูกเขียนในภาษาที่ล้าสมัยจริง: G2 - คิดว่า Pascal ด้วยกราฟิก) ตัวโปรแกรมเองเป็นแบบจำลองทางกายภาพของโรงงานแปรรูปสารเคมีที่ซับซ้อน ทีมที่เขียนมันมีความรู้เกี่ยวกับโดเมนอย่างไม่น่าเชื่อ แต่มีการฝึกอบรมอย่างเป็นทางการเพียงเล็กน้อยในการเขียนโปรแกรมพื้นฐาน พวกเขาเพิ่งเรียนรู้บทเรียนที่ยากลำบากเกี่ยวกับผลที่ตามมาของการจัดการการกำหนดค่าที่ไม่มีอยู่จริง ความพยายามในการบำรุงรักษาของพวกเขายังถูกขัดขวางอย่างมากจากการสะสม "ตะกอน" ที่ไม่มีเอกสารในรหัสด้วย ฉันจะให้คุณ "การเมือง" ของสถานการณ์ (มีเสมอ การเมือง!) แต่ก็เพียงพอที่จะบอกว่าไม่มีความเห็นเป็นเอกฉันท์เกี่ยวกับสิ่งที่จำเป็นสำหรับเส้นทางข้างหน้า พวกเขาขอให้ฉันเริ่มนำเสนอหลักการบางประการของการพัฒนาซอฟต์แวร์ที่ทันสมัยให้กับทีม พวกเขาต้องการให้ฉันแนะนำวิธีปฏิบัติและกลยุทธ์มาตรฐานอุตสาหกรรมบางประการเกี่ยวกับข้อกำหนดการเข้ารหัสการจัดการวงจรชีวิตรูปแบบการออกแบบระดับสูงและการควบคุมแหล่งที่มา ตรงไปตรงมามันเป็นงานที่ค่อนข้างน่ากลัวและฉันไม่แน่ใจว่าจะเริ่มต้นที่ไหน ในตอนแรกฉันมีแนวโน้มที่จะสอนพวกเขาในบางแนวคิดหลักของThe Pragmatic ProgrammerหรือRefactoringของ Fowler ("Code Smells" ฯลฯ ) ฉันหวังว่าจะแนะนำวิธีการแบบ Agile จำนวนมาก แต่ท้ายที่สุดเพื่อให้มีประสิทธิภาพฉันคิดว่าฉันจะต้องฝึกฝนพื้นฐาน 5-7 หลัก กล่าวอีกนัยหนึ่งอะไรคือหลักการหรือวิธีปฏิบัติที่สำคัญที่สุดที่พวกเขาสามารถเริ่มใช้งานได้อย่างแนบเนียน นั่นคือคำถามของฉัน: สิ่งที่คุณจะรวมไว้ในรายการกลยุทธ์ที่มีประสิทธิภาพที่สุดเพื่อช่วยยืดเส้นสปาเก็ตตี้ออกไป (และป้องกันไม่ให้เกิดขึ้นในอนาคต)

470 project-management  agile  development-process  maintenance  sdlc 

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

368 maintenance 

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

145 source-code  maintenance 

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

86 teamwork  code-reviews  maintenance 

ฉันเป็นผู้ดูแลโครงการที่มีฐานผู้ใช้ที่ไม่ใช่ด้านเทคนิคขนาดใหญ่ ฉันได้ทำการบำรุงรักษามาประมาณ 4 ปีแล้วและเพิ่มคุณสมบัติใหม่ตามที่ได้รับการร้องขอ ฉันต้องการที่จะไปยังโครงการอื่นในตอนนี้และหยุดพัฒนาสำหรับแอปพลิเคชันนี้ เนื่องจากลักษณะที่ไม่ใช่ด้านเทคนิคของผู้ใช้มีการสนับสนุนโค้ดน้อยมากในอดีต ฉันไม่เชื่อว่าฉันจะสามารถหาคนอื่นมาดูแลโครงการแทน ข้อบกพร่องปัญหาคำขอคุณสมบัติ - สิ่งเหล่านี้ยังคงเข้ามาฉันยังคงตอบกลับอีเมลเพื่อขอความช่วยเหลือเนื่องจากฉันไม่แน่ใจว่าควรจะเพิกเฉยต่อพวกเขาหรือไม่บอกพวกเขาว่าฉันไม่ได้ทำงานกับแอปพลิเคชัน อีเมลในบางกรณีเท่านั้น วิธีที่ดีที่สุดในการ 'ละทิ้ง' โครงการนี้ แต่ยังคงให้ผู้ใช้ใช้งานแอปพลิเคชันอยู่ อัปเดต (กรกฎาคม 2559) - ไม่เป็นไปตามแผนที่วางไว้ ฉันประกาศใน README และหลังจากนั้นไม่นานฉันก็เริ่มได้รับเงินบริจาคจากธรรมชาติที่สำคัญกว่านี้ ดึงคำขอด้วยการแก้ไขข้อบกพร่องคุณสมบัติเอกสารประกอบกิจกรรมการออก ตั้งแต่นั้นมาโครงการรู้สึกถึง 'reinvigorated' และตอนนี้ฉันก็มีความสุขในการดูแลมันพร้อมกับโครงการใหม่ ๆ ฉันมีผู้ทำงานร่วมกันเช่นกัน โดยการคาดเดาอาจเป็นผลงานที่ส่งผลต่อมุมมองของฉันเกี่ยวกับโครงการและด้วยการปรับปรุงคุณภาพการมีส่วนร่วมมันไม่ได้รู้สึกว่าเป็นงานที่น่าเบื่ออีกต่อไป

75 open-source  project  maintenance 

ฉันรู้สึกว่าระบบควบคุมเวอร์ชันขจัดความจำเป็นที่จะต้อง "บันทึกการเปลี่ยนแปลง" ถูกฉาบทุกที่ในรหัส ฉันมักจะเห็นการใช้งานอย่างต่อเนื่องของบันทึกการเปลี่ยนแปลงรวมถึงบล็อกยาวขนาดใหญ่ที่จุดเริ่มต้นของขั้นตอนการจัดเก็บที่มีส่วนใหญ่ถูกบล็อกออกสำหรับการเปลี่ยนแปลงในไฟล์และทิ้งรหัสด้วยสิ่งต่าง ๆ เช่น: // 2011-06-14 (John Smith) Change XYZ to ABC to fix Bug #999 และ: // 2009-95-12 (Bob Jones) Extracted this code to Class Foo // <commented-out code here> เหตุผลสำหรับสิ่งนี้ตามที่อธิบายให้ฉันคือการใช้เวลานานเกินไปในการตรวจสอบบันทึก VCS ของเราพยายามค้นหาว่าใครเปลี่ยนอะไรและเพราะอะไรในขณะที่เก็บไว้ในไฟล์รหัสตัวเองไม่ว่าจะอยู่ด้านบนสุดหรือใกล้เคียง การเปลี่ยนแปลงทำให้ง่ายต่อการดูว่าใครเปลี่ยนอะไรและเมื่อไหร่ ในขณะที่ฉันเห็นประเด็นนั้นดูเหมือนว่าจะซ้ำซ้อนและเป็นเพียงแค่ของเล็ก ๆ น้อย ๆ "เอ๋เราไม่เข้าใจวิธีการใช้ VCS ของเราอย่างถูกต้องดังนั้นเราจะไม่สนใจสิ่งนั้นเลย" คุณคิดอย่างไร? คุณใช้ทั้งความคิดเห็นและบันทึกหรือไม่ แค่บันทึก คุณพบว่าการโค้ดง่ายขึ้นเมื่อคุณเห็นโค้ดบล็อกข้างต้นที่ John Smith …

75 version-control  coding-standards  maintenance 

สมมติว่ามีโปรแกรมที่ค่อนข้างใหญ่ (พูด 900k SLOC ใน C #) ทุกความเห็น / บันทึกไว้อย่างละเอียดจัดระเบียบดีและทำงานได้ดี ฐานรหัสทั้งหมดเขียนขึ้นโดยนักพัฒนาอาวุโสคนเดียวซึ่งไม่ได้อยู่กับ บริษัท อีกต่อไป รหัสทั้งหมดนั้นสามารถทำการทดสอบได้เหมือนเดิมและ IoC นั้นถูกใช้ไปตลอด - ยกเว้นด้วยเหตุผลแปลก ๆ บางอย่างที่พวกเขาไม่ได้เขียนการทดสอบหน่วยใด ๆ ตอนนี้ บริษัท ของคุณต้องการแยกรหัสและต้องการเพิ่มการทดสอบหน่วยเพื่อตรวจสอบเมื่อมีการเปลี่ยนแปลงการทำงานหลักของระบบ การเพิ่มการทดสอบเป็นความคิดที่ดีหรือไม่ ถ้าเป็นเช่นนั้นเราจะเริ่มจากสิ่งนี้ได้อย่างไร แก้ไข ตกลงดังนั้นฉันไม่ได้คาดหวังคำตอบที่สร้างข้อโต้แย้งที่ดีสำหรับข้อสรุปที่ตรงกันข้าม ปัญหาอาจจะออกจากมือของฉันอยู่ดี ฉันได้อ่าน "คำถามที่ซ้ำกัน" เช่นกันและฉันทามติทั่วไปคือ "การทดสอบการเขียนเป็นสิ่งที่ดี" ... ใช่ แต่ไม่เป็นประโยชน์ในกรณีนี้โดยเฉพาะ ฉันไม่คิดว่าฉันอยู่คนเดียวที่นี่ในการพิจารณาการทดสอบการเขียนสำหรับระบบเดิม ฉันจะทำตัวชี้วัดว่าใช้เวลาเท่าไรและมีกี่ครั้งที่การทดสอบใหม่ตรวจพบปัญหา (และกี่ครั้งที่พวกเขาไม่ทำ) ฉันจะกลับมาและอัปเดตปีนี้จากผลลัพธ์ของฉัน สรุปผลการศึกษา ดังนั้นจึงปรากฎว่าเป็นไปไม่ได้ที่จะเพิ่มการทดสอบหน่วยในโค้ดที่มีอยู่ด้วยลักษณะของออร์โธดอกซ์ เมื่อโค้ดทำงานคุณจะไม่สามารถทำการทดสอบของคุณได้แสงสีแดง / สีเขียว - เขียวก็มักจะไม่ชัดเจนว่าพฤติกรรมใดที่มีความสำคัญในการทดสอบไม่ชัดเจนว่าจะเริ่มต้นที่ใด ที่จริงแล้วการถามคำถามนี้พลาดประเด็นสำคัญในการเขียนแบบทดสอบในตอนแรก ในกรณีส่วนใหญ่ฉันพบว่ามันง่ายกว่าจริง ๆ …

68 unit-testing  tdd  maintenance 

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

63 programming-practices  maintenance 

ฉันไม่ได้มีประสบการณ์การทำงานในอุตสาหกรรมซอฟต์แวร์มากนักการเรียนรู้ด้วยตนเองและมีส่วนร่วมในโอเพ่นซอร์สก่อนที่จะตัดสินใจทำงาน ตอนนี้ฉันทำงานเพื่อเงินฉันก็ต้องจัดการกับสิ่งที่ไม่พึงประสงค์ซึ่งเป็นเรื่องปกติ เมื่อเร็ว ๆ นี้ฉันได้รับมอบหมายให้เพิ่มการบันทึกลงในโครงการ SharePoint ขนาดใหญ่ซึ่งเขียนโดยโปรแกรมเมอร์บางคนซึ่งเห็นได้ชัดว่ากำลังเรียนรู้ที่จะเขียนโค้ดเกี่ยวกับงาน หลังจาก 2 ปีของการทำงานร่วมกันลูกค้าเปลี่ยนไปใช้ บริษัท ของเรา แต่ความเสียหายเสร็จสิ้นและตอนนี้ฉันต้องการรักษารหัสนี้ไว้ ไม่ใช่ว่ารหัสอ่านยากเกินไป แม้จะมีปัญหา - แต่ละโครงการมีชั้นเรียนหนึ่งที่มีวิธีการคัดลอกวางหลาย, การทำifรังขนาดใหญ่, ระบบฮังการี, การเชื่อมต่อที่ไม่ขาดตอน - มันยังคงอ่านได้ อย่างไรก็ตามฉันพบว่าตัวเองไม่ได้ผลแม้จะทำอะไรง่ายๆแค่เพิ่มการบันทึก โดยทั่วไปฉันแค่ต้องผ่านขั้นตอนของรหัสและเพิ่มการโทรติดตาม แต่ความโง่เขลาของรหัสเป็นที่น่ารำคาญมากที่ฉันได้รับเหนื่อยภายใน 10 นาทีของการเริ่มต้น ในตอนแรกฉันใช้เพื่อเพิ่มusingโครงสร้างลดการซ้อนโดยย้อนกลับifเปลี่ยนชื่อตัวแปรเป็นชื่อที่อ่านได้ - แต่โครงการมีขนาดใหญ่และในที่สุดฉันก็ยอมแพ้ ฉันรู้ว่านี่ไม่ใช่งานที่ฉันควรทำ แต่อย่างน้อยการลดความยุ่งเหยิงก็ทำให้ฉันได้รับรางวัลทางจิตวิทยาบางอย่างเพื่อที่ฉันจะได้ไปต่อ ทีนี้เคล็ดลับก็หยุดทำงานและฉันก็ยังมีงานอีก 60% ที่ต้องทำ ฉันเริ่มมีอาการปวดหัวหลังเลิกงานและฉันไม่ได้รับความพึงพอใจอีกต่อไปที่ฉันเคยได้รับ - ซึ่งมักจะอนุญาตให้ฉันใช้รหัสเป็นเวลา 10 ชั่วโมงตรงและยังรู้สึกสดชื่น นี่ไม่ใช่แค่เสียงโวยวายครั้งใหญ่เพียงเพราะฉันมีคำถามจริง: มีวิธีที่จะรักษาประสิทธิผลและไม่ต่อสู้กับกังหันลมหรือไม่? มีชนิดของเคล็ดลับจิตวิทยาบางอย่างที่จะพักที่เน้นในงานแทนการคิด“วิธีการโง่ที่ ?”ทุกครั้งที่ผมเห็นเคล็ดลับฉลาดอีกโดยโปรแกรมเมอร์ก่อนหน้านี้หรือไม่? ปัญหาของการเพิ่มการบันทึกคือฉันต้องเข้าใจจริงๆว่าโค้ดทำอะไรและการทำเช่นนั้นจะทำให้สมองของฉันเจ็บอย่างไม่เป็นที่พอใจ

63 code-quality  productivity  maintenance 

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

60 architecture  coding-style  coding-standards  coding  maintenance 

ฉันจัดการทีมนักพัฒนาเล็ก ๆ ในแอปพลิเคชันซึ่งอยู่ในช่วงกลางของวงจรชีวิตภายใน บริษัท ใหญ่ น่าเสียดายที่นี่หมายถึงมีการแบ่งงานการเขียนโปรแกรม 30/70 เป็น "งานด้านเทคนิคอื่น ๆ " โดยทั่วไป งานนี้รวมถึง: ทำงานกับทีม DBA / Unix / Network / Loadbalancer ในงานต่างๆ การวางและจัดการคำสั่งซื้อฮาร์ดแวร์หรือโครงสร้างพื้นฐานในภูมิภาคต่างๆ กำลังรันการทดสอบที่ยังไม่ได้ย้ายไปยัง CI การวิเคราะห์ สนับสนุน / สืบสวน มันยุติธรรมที่จะบอกว่านักพัฒนาทุกคนชอบที่จะเขียนโค้ดมากกว่าที่จะทำภารกิจทางโลกมากกว่านี้ดังนั้นฉันพยายามแจกงานเขียนโปรแกรมสนุก ๆ ให้กับทีม ทีมส่วนใหญ่ได้รับการว่าจ้างเพราะถึงแม้ว่าพวกเขาอาจไม่มีทักษะการเขียนโปรแกรมยอดเยี่ยมในการเขียนคอมไพเลอร์ / เกมของตัวเอง / ระบบการซื้อขายที่มีความถี่สูง ฯลฯ พวกเขาเป็นนักสื่อสารที่ดี และค่อนข้างนำทางระบบราชการที่ซับซ้อนที่นี่ พวกเขาเป็นนักพัฒนาที่ดี แต่พวกเขาก็เป็นเจ้าหน้าที่เทคนิคที่ดีทุกด้าน อย่างไรก็ตามสมาชิกคนหนึ่งของทีมอาจมีทักษะการเขียนโค้ดโดยเฉลี่ยสูงกว่า แต่ทักษะการสื่อสารต่ำกว่าค่าเฉลี่ย ตามเนื้อผ้าผู้จัดการฝ่ายพัฒนาคนก่อนมีแนวโน้มที่จะให้งานการเขียนโปรแกรมแก่เขาและไม่ใช่งานทางโลกที่มีรายชื่อด้านบน อย่างไรก็ตามฉันไม่รู้สึกว่าสิ่งนี้ยุติธรรมสำหรับคนอื่น ๆ ในทีมที่แสดงความสามารถในการพัฒนาชุดทักษะรอบด้านที่จำเป็นสำหรับแผนกไอทีขนาดใหญ่ของธุรกิจ ฉันควรทำอย่างไรในสถานการณ์เช่นนี้? ถ้าฉันยังคงทำงานเขียนโปรแกรมให้เขาต่อไปฉันรู้ว่ามันจะเสร็จเร็วขึ้น …

52 teamwork  management  communication  maintenance  team-leader 

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

52 maintenance  skills  legacy 

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

50 maintenance  development-methodologies 

ฉันต้องขยายโมดูลที่มีอยู่ของโครงการ ฉันไม่ชอบวิธีที่เคยทำ (มีรูปแบบการต่อต้านจำนวนมากที่เกี่ยวข้องเช่นคัดลอก / วางโค้ด) ฉันไม่ต้องการดำเนินการ refactor แบบสมบูรณ์ด้วยเหตุผลหลายประการ ฉันควร: สร้างวิธีการใหม่โดยใช้การประชุมที่มีอยู่แม้ว่าฉันจะรู้สึกผิดเพื่อหลีกเลี่ยงความสับสนสำหรับผู้ดูแลต่อไปและสอดคล้องกับรหัสฐานหรือไม่ หรือ ลองใช้สิ่งที่ฉันรู้สึกดีขึ้นแม้ว่าจะมีการแนะนำรูปแบบอื่นในรหัสหรือไม่ Precison แก้ไขหลังจากคำตอบแรก: รหัสที่มีอยู่ไม่เป็นระเบียบ มันง่ายที่จะติดตามและทำความเข้าใจ แต่มันก็แนะนำรหัสสำเร็จรูปจำนวนมากที่สามารถหลีกเลี่ยงได้ด้วยการออกแบบที่ดี (รหัสผลลัพธ์อาจกลายเป็นเรื่องยากที่จะปฏิบัติตามแล้ว) ในกรณีปัจจุบันของฉันมันเป็นโมดูล DAO เก่าแก่ของ JDBC (บอร์ดเทมเพลตสปริง) แต่ฉันได้พบปัญหานี้แล้วและฉันกำลังมองหาความคิดเห็น dev อื่น ๆ ฉันไม่ต้องการ refactor เพราะฉันไม่มีเวลา และถึงเวลาจะยากที่จะพิสูจน์ว่าโมดูลที่ทำงานได้อย่างสมบูรณ์แบบนั้นต้องการการปรับโครงสร้างใหม่ ต้นทุนการปรับโครงสร้างจะหนักกว่าประโยชน์ของมัน จำเอาไว้: รหัสไม่ยุ่งหรือซับซ้อนเกิน ฉันไม่สามารถแยกวิธีการไม่กี่ที่นั่นและแนะนำคลาสนามธรรมที่นี่ มันเป็นข้อบกพร่องในการออกแบบมากขึ้น (เพราะ 'Keep It Stupid Simple' สุดขีดฉันคิดว่า) ดังนั้นคำถามที่สามารถถามได้เช่น: คุณในฐานะนักพัฒนาคุณต้องการที่จะรักษาโค้ดที่น่าเบื่องี่เง่าที่ง่ายหรือจะมีผู้ช่วยบางคนที่จะทำโค้ดที่น่าเบื่อแบบโง่ในที่ของคุณหรือไม่? ข้อเสียของความเป็นไปได้ครั้งสุดท้ายที่คุณจะต้องเรียนรู้บางสิ่งและบางทีคุณอาจจะต้องรักษารหัสที่น่าเบื่ออย่างง่าย ๆ ไว้เช่นกันจนกว่าจะทำการรีแฟคเตอร์เสร็จสมบูรณ์)

45 refactoring  coding  maintenance  anti-patterns 

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

42 project-management  programming-practices  refactoring  maintenance