ในฐานะสถาปนิกซอฟต์แวร์ฉันควรจะให้ความสำคัญกับการวิเคราะห์บันทึกและแก้ไขข้อบกพร่องของคนอื่นหรือไม่

ตั้งแต่เรียนจบ (ปลายปี 2548) ฉันทำงานกับ บริษัท เดียวกันกับวิศวกรซอฟต์แวร์ c ++ ปีที่แล้วฉันได้รับการเลื่อนตำแหน่งเป็นสถาปนิกซอฟต์แวร์ แต่ฉันพบว่าตัวเองมีส่วนร่วมมากขึ้นในด้านคุณสมบัติและการแก้ไขข้อบกพร่องการสนับสนุนระดับ 2

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

ฉันเริ่มเกลียดผลิตภัณฑ์นี้และคิดถึงกลยุทธ์การออกจาก บริษัท นี้

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

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

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

กล่าวอีกนัยหนึ่งชื่อส่วนใหญ่ไม่มีความหมาย

บทความ Wikipedia กำหนดสถาปนิกซอฟต์แวร์เป็น:

โปรแกรมคอมพิวเตอร์ที่ทำให้ตัวเลือกระดับสูงการออกแบบและสั่งมาตรฐานทางเทคนิครวมทั้งซอฟต์แวร์มาตรฐานการเข้ารหัสเครื่องมือหรือแพลตฟอร์ม ...

จากที่ได้กล่าวไว้ข้างต้นการประมาณของคุณ"50% ของเวลาของฉัน ... การวิเคราะห์บันทึกซอฟต์แวร์ ... 30% การแก้ไขข้อบกพร่องของผู้อื่น"ทำให้คุณห่างไกลจากสิ่งที่สถาปนิกซอฟต์แวร์คาดว่าจะทำ

• ฉันจะบอกว่าข้างต้นทำให้ชื่อที่พวกเขาให้คุณเกี่ยวกับการ50+30=80%ปลอม

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

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

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

ในฐานะสถาปนิกซอฟต์แวร์ฉันควรจะให้ความสำคัญกับการวิเคราะห์บันทึกและแก้ไขข้อบกพร่องของคนอื่นหรือไม่

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

คุณควรจะเป็นเชิงรุก:

1. ริเริ่มแผนการศึกษาเพื่อให้ผู้อื่น (dev / support) สามารถยกภาระ "สอนให้คนตกปลา" และแจ๊สทั้งหมดนั้น
2. คิดค้นวิธีและพัฒนาเครื่องมือเพื่อรองรับการวิเคราะห์ข้อบกพร่องที่รวดเร็วและง่ายขึ้นและการแยกสาเหตุที่แท้จริง หากคุณพบว่านักพัฒนาที่น่าเบื่อคนอื่นนักพัฒนาที่มีความสามารถน้อยหรือมีประสบการณ์จะพบว่าสิ่งนี้ไม่เพียง แต่น่าเบื่อ แต่ก็ยากและน่ากลัวด้วยซ้ำ ช่วยให้พวกเขาเอาชนะสิ่งเหล่านี้ได้ด้วยเทคโนโลยี
3. เริ่มต้นความพยายามเพื่อยกระดับคุณภาพของผลิตภัณฑ์ - ทำให้ง่ายขึ้นทำให้เป็นโมดูลสร้างกรอบการทดสอบ - นำโดยตัวอย่างไม่ใช่โดยการครางและขู่ว่าจะเลิก
4. ตรวจสอบให้แน่ใจว่านักพัฒนาซอฟต์แวร์รู้ว่าคุณกำลังทำอะไร แต่ยังรวมถึงผู้จัดการของคุณด้วย บทบาทของสถาปนิกมีความสัมพันธ์กับผู้อื่นมากขึ้นจากนั้นก็คือการเขียนโค้ดและการวิเคราะห์ การเมืองเป็นกุญแจสำคัญที่นี่ ทำให้แน่ใจว่าเพื่อนของคุณเห็นความสำเร็จของคุณทำให้ง่ายต่อการโน้มน้าวใจพวกเขาในภายหลังว่าคุณพูดถูก หากคุณยังไม่ได้ส่งคืนการเรียกร้องของคุณโดยการวิจัยและ POCs
5. หากทุกอย่างล้มเหลวและหลังจากใช้เวลาพยายามทำให้ดีขึ้นให้คุยกับผู้จัดการของคุณ บอกว่าทักษะของคุณใช้ในการวางแผนและออกแบบเฟสได้ดีขึ้นและดูว่าสามารถทำอะไรได้บ้างเพื่อเปลี่ยนแปลงสถานการณ์ปัจจุบัน ผลิตภัณฑ์ของคุณอาจจะเหน็บแนมและคำตอบของผู้จัดการของคุณอาจเป็น "เราต้องการให้คุณทำสิ่งนี้ที่นี่ตอนนี้" ฉันจะยืนยันในแผนระยะยาวว่า - เราจะเปลี่ยนสถานการณ์ปัจจุบันอย่างไร

ฉันเห็นบทบาทของสถาปนิกเป็นสิทธิพิเศษ คุณจะมีอิทธิพลต่อผลิตภัณฑ์ในวิธีที่คนอื่นไม่สามารถทำได้ - เพียงคนเดียวที่มีอิทธิพลมากกว่าในทางทฤษฎีมากกว่าคุณคือเขาเป็นผู้จัดการฝ่ายวิจัยและพัฒนาผลิตภัณฑ์ (และอาจเป็นไปได้ด้านการตลาด) - แต่เขากำลังยุ่งอยู่กับการจัดการ

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

รับสิ่งที่คุณพูด:

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

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

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

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

มันเป็นปัญหาที่ยากที่จะแก้ไข แต่คำแนะนำของฉันคือ:

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

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

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

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

โชคดี.

ไม่คุณมาที่นี่เพื่อจัดการภาพรวม

คุณมีปัญหาด้านการจัดการ: การแก้ไขข้อบกพร่องและการปรับปรุงคุณภาพรหัสเป็นงานของนักพัฒนาในฐานะสถาปนิกที่คุณควรจะออกแนวทางและสถาปัตยกรรมที่แท้จริง (UML หรืออะไรก็ตามที่ลอยอยู่บนเรือของคุณ) จากนั้นให้บทวิจารณ์รหัสปกติ .

อย่างไรก็ตามคุณอาจใช้และแก้ไขข้อบกพร่องในสถาปัตยกรรมหลัก

ตัวอย่าง: คุณจะทำงานกับ PRISM, MEF และอื่น ๆ ในโครงการ WPF / C # แต่คุณจะไม่ทำงานบน XAML เพื่อแสดงสแปลช

คุณต้องการออกแบบ DB แต่คุณจะไม่เขียนโพรซีเดอร์ที่เก็บไว้สำหรับการดำเนินการ CRUD

เป็นต้น

ส่วนหนึ่งของคำตอบคือการหาวิศวกรที่เต็มใจรับภาระนี้

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

ฉันเห็นความเป็นไปได้สองอย่าง

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

2. ชื่อส่วนใหญ่เป็นพิธี - กระดูกโยนให้คุณเพื่อให้คุณไปรอบ ๆ

ในกรณีนี้การจัดการอาจไม่สนใจอย่างมากในการลดภาระการสนับสนุนของคุณ

-

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

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

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

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

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

จุด # 2 : ถ้าคุณเป็นหนึ่งในไม่กี่นักพัฒนาแอพลิเคชันเหล่านี้บน (s) - แล้วชื่อนี้เป็นเพียงน้ำตาลเคลือบอื่นโดยการจัดการของ บริษัท เพื่อให้คุณใน "แก้ไข" บทบาทกับใหม่เหมือนกัน ชื่อแฟนซี

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

ในฐานะสถาปนิกซอฟต์แวร์ฉันควรจะให้ความสำคัญกับการวิเคราะห์บันทึกและแก้ไขข้อบกพร่องของคนอื่นหรือไม่

ในเรื่องของการพูดว่า 'ใช่'

นี่คือวิธีที่ฉันจะทำให้คำตอบของฉันมีคุณสมบัติ:

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

เพิ่มเติมเกี่ยวกับ # 2:

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

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

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