ในตอนแรก เป็นเรื่องยากเสมอที่จะเข้าใจโครงการขนาดใหญ่และเก่า สถาปัตยกรรมเป็นหนึ่งในกิจกรรมของการประเมินสถาปนิก โดยปกติแล้วคุณจะต้องทำงานกับโปรเจ็กต์เก่าๆ ขนาดใหญ่ และต้องส่งมอบผลลัพธ์ภายในหนึ่งสัปดาห์
วิธีประเมินโปรเจ็กต์ที่มีโค้ด 100 บรรทัดขึ้นไปในหนึ่งสัปดาห์โดยที่ยังคงให้ผลลัพธ์ที่เป็นประโยชน์ต่อลูกค้าอย่างแท้จริง
สถาปนิกและผู้นำด้านเทคนิคส่วนใหญ่ต้องเผชิญกับการประเมินโครงการที่คล้ายคลึงกัน สิ่งนี้อาจดูเหมือนเป็นกระบวนการกึ่งทางการหรือเป็นบริการแยกต่างหากเช่นเดียวกับที่ทำในบริษัทของเรา ไม่ทางใดก็ทางหนึ่งที่พวกคุณส่วนใหญ่ได้จัดการกับเรื่องนี้
ต้นฉบับเป็นภาษาอังกฤษสำหรับเพื่อนที่พูดภาษารัสเซียไม่ได้อยู่ที่นี่: .
แนวทางของบริษัทเรา
ฉันจะบอกคุณว่ามันทำงานอย่างไรในบริษัทของเรา และวิธีที่ฉันปฏิบัติในสถานการณ์ที่คล้ายคลึงกัน แต่คุณสามารถเปลี่ยนแนวทางนี้ได้อย่างง่ายดายตามความต้องการของโครงการและบริษัทของคุณ
การประเมินสถาปัตยกรรมมีสองประเภท
ภายใน – ปกติเราจะทำเพื่อโครงการภายในบริษัท โครงการใด ๆ อาจขอการประเมินสถาปัตยกรรมด้วยเหตุผลหลายประการ:
- ทีมงานคิดว่าโปรเจ็กต์ของตนสมบูรณ์แบบและนี่เป็นเรื่องที่น่าสงสัย เรามีกรณีเช่นนี้และบ่อยครั้งในโครงการดังกล่าวทุกอย่างยังห่างไกลจากอุดมคติ
- ทีมงานต้องการทดสอบโครงการและแนวทางแก้ไข
- ทีมงานรู้ดีว่ามีสิ่งไม่ดี พวกเขาอาจระบุถึงปัญหาและสาเหตุหลัก แต่ต้องการรายการปัญหาและข้อเสนอแนะทั้งหมดเพื่อการปรับปรุงโครงการ
ภายนอก เป็นกระบวนการที่เป็นทางการมากกว่าการประเมินภายใน ลูกค้ามักจะมาในกรณีเดียวเท่านั้น เมื่อทุกอย่างแย่ - แย่มาก โดยปกติแล้วลูกค้าจะเข้าใจว่ามีปัญหาระดับโลก แต่ไม่สามารถระบุสาเหตุได้อย่างถูกต้องและแยกย่อยออกเป็นส่วนประกอบต่างๆ
การประเมินสถาปัตยกรรมสำหรับไคลเอนต์ภายนอกเป็นกรณีที่ซับซ้อนมากขึ้น กระบวนการควรเป็นทางการมากขึ้น โครงการมีขนาดใหญ่และเก่าอยู่เสมอ พวกเขามีปัญหา ข้อบกพร่อง และโค้ดที่คดเคี้ยวมากมาย รายงานเกี่ยวกับงานที่ทำเสร็จแล้วควรพร้อมภายในไม่กี่สัปดาห์สูงสุด ซึ่งควรรวมปัญหาหลักและคำแนะนำในการปรับปรุง ดังนั้น หากเราจัดการกับการประเมินภายนอกของโครงการ การประเมินภายในก็จะกลายเป็นเรื่องง่าย ลองพิจารณากรณีที่ยากที่สุด
การประเมินสถาปัตยกรรมโครงการองค์กร
โครงการทั่วไปที่ต้องประเมินคือโครงการระดับองค์กรขนาดใหญ่และเก่าที่มีปัญหามากมาย ลูกค้ามาหาเราและขอให้เราแก้ไขโครงการของเขา มันเหมือนกับภูเขาน้ำแข็ง ลูกค้ามองเห็นเพียงปลายปัญหาของเขา และไม่รู้ว่ามีอะไรอยู่ใต้น้ำ (ในส่วนลึกของโค้ด)
ปัญหาที่ลูกค้าอาจร้องเรียนและอาจทราบ:
- ปัญหาด้านประสิทธิภาพ
- ปัญหาการใช้งาน
- การใช้งานระยะยาว
- ขาดหน่วยและการทดสอบอื่น ๆ
ปัญหาที่ลูกค้ามักไม่ทราบ แต่อาจมีอยู่ในโครงการ:
- ปัญหาด้านความปลอดภัย
- ปัญหาการออกแบบ
- สถาปัตยกรรมไม่ถูกต้อง
- ข้อผิดพลาดอัลกอริทึม
- เทคโนโลยีที่ไม่เหมาะสม
- หนี้ทางเทคนิค
- กระบวนการพัฒนาที่ไม่ถูกต้อง
กระบวนการตรวจสอบสถาปัตยกรรมอย่างเป็นทางการ
นี่เป็นกระบวนการอย่างเป็นทางการที่เราปฏิบัติตามในฐานะบริษัท แต่คุณสามารถปรับแต่งได้ขึ้นอยู่กับบริษัทและโครงการของคุณ
คำขอจากลูกค้า
ลูกค้าขอให้ประเมินสถาปัตยกรรมของโครงการปัจจุบัน ผู้รับผิดชอบฝ่ายเรารวบรวมข้อมูลพื้นฐานเกี่ยวกับโครงการและเลือกผู้เชี่ยวชาญที่จำเป็น เหล่านี้อาจเป็นผู้เชี่ยวชาญที่แตกต่างกันขึ้นอยู่กับโครงการ
สถาปนิกโซลูชั่น – บุคคลหลักที่รับผิดชอบในการประเมินและประสานงาน (และมักเป็นคนเดียว)
รวบรวมผู้เชี่ยวชาญเฉพาะด้าน – .Net, Java, Python และผู้เชี่ยวชาญด้านเทคนิคอื่นๆ ขึ้นอยู่กับโครงการและเทคโนโลยี
ผู้เชี่ยวชาญด้านคลาวด์ – สิ่งเหล่านี้อาจเป็นสถาปนิกระบบคลาวด์ Azure, GCP หรือ AWS
โครงสร้างพื้นฐาน – DevOps ผู้ดูแลระบบ ฯลฯ
ผู้เชี่ยวชาญอื่นๆ – เช่น ข้อมูลขนาดใหญ่ การเรียนรู้ของเครื่อง วิศวกรประสิทธิภาพ ผู้เชี่ยวชาญด้านความปลอดภัย หัวหน้าฝ่ายควบคุมคุณภาพ
รวบรวมข้อมูลเกี่ยวกับโครงการ
คุณควรรวบรวมข้อมูลเกี่ยวกับโครงการให้ได้มากที่สุด คุณสามารถใช้เทคนิคต่างๆ ได้ขึ้นอยู่กับสถานการณ์:
- แบบสอบถามและวิธีการสื่อสารอื่น ๆ ทางไปรษณีย์ วิธีที่ไร้ประสิทธิภาพที่สุด
- การประชุมออนไลน์
- เครื่องมือพิเศษสำหรับการแลกเปลี่ยนข้อมูล เช่น Google doc, Confluence, repositories เป็นต้น
- การประชุม "สด" ในสถานที่ วิธีที่มีประสิทธิภาพและแพงที่สุด
สิ่งที่คุณควรได้รับจากลูกค้า?
ข้อมูลพื้นฐาน. โครงการเกี่ยวกับอะไร? วัตถุประสงค์และคุณค่าของมัน เป้าหมายหลักและแผนงานสำหรับอนาคต เป้าหมายและกลยุทธ์ทางธุรกิจ ปัญหาหลักและผลลัพธ์ที่ต้องการ
ข้อมูลโครงการ. สแต็กเทคโนโลยี เฟรมเวิร์ก ภาษาการเขียนโปรแกรม การปรับใช้ในสถานที่หรือบนคลาวด์ หากโปรเจ็กต์อยู่ในระบบคลาวด์ จะใช้บริการใดบ้าง ใช้รูปแบบสถาปัตยกรรมและการออกแบบอะไร
ข้อกำหนดที่ไม่สามารถใช้งานได้. ข้อกำหนดทั้งหมดที่เกี่ยวข้องกับประสิทธิภาพ ความพร้อมใช้งาน และความง่ายในการใช้งานของระบบ ข้อกำหนดด้านความปลอดภัย ฯลฯ
กรณีการใช้งานพื้นฐานและกระแสข้อมูล
การเข้าถึงซอร์สโค้ด. ส่วนที่สำคัญที่สุด! คุณควรเข้าถึงพื้นที่เก็บข้อมูลและเอกสารประกอบเกี่ยวกับวิธีการสร้างโครงการได้อย่างแน่นอน
การเข้าถึงโครงสร้างพื้นฐาน. คงจะดีไม่น้อยหากสามารถเข้าถึงโครงสร้างพื้นฐานของขั้นตอนหรือการผลิตเพื่อทำงานกับระบบที่ใช้งานจริงได้ จะถือเป็นความสำเร็จที่ยิ่งใหญ่หากลูกค้ามีเครื่องมือสำหรับตรวจสอบโครงสร้างพื้นฐานและประสิทธิภาพ เราจะพูดถึงเครื่องมือเหล่านี้ในหัวข้อถัดไป
เอกสาร. หากลูกค้ามีเอกสารประกอบ นี่ก็ถือเป็นการเริ่มต้นที่ดี มันอาจจะล้าสมัย แต่ก็ยังเป็นการเริ่มต้นที่ดี อย่าเชื่อถือเอกสารประกอบ - ทดสอบกับไคลเอนต์บนโครงสร้างพื้นฐานจริงและในซอร์สโค้ด
กระบวนการประเมินผลสถาปัตยกรรม
เราจะประมวลผลข้อมูลจำนวนมากในเวลาอันสั้นได้อย่างไร ก่อนอื่นให้ทำงานแบบขนาน
DevOps ควรพิจารณาที่โครงสร้างพื้นฐาน เทคโนโลยีนำไปสู่รหัส วิศวกรประสิทธิภาพเพื่อดูตัวชี้วัดประสิทธิภาพ ผู้เชี่ยวชาญด้านฐานข้อมูลควรเจาะลึกเข้าไปในโครงสร้างข้อมูล
แต่นี่เป็นกรณีที่ดีเมื่อคุณมีทรัพยากรจำนวนมาก โดยทั่วไปแล้ว บุคคลหนึ่งถึงสามคนจะประเมินโครงการ คุณสามารถดำเนินการประมาณการได้ด้วยตัวเอง ซึ่งมักเป็นเช่นนั้นหากคุณมีความรู้และประสบการณ์ที่เหมาะสมในทุกด้านของโครงการ ในกรณีนี้ คุณต้องทำให้กระบวนการทั้งหมดเป็นอัตโนมัติให้ได้มากที่สุด
ขออภัย คุณจะต้องอ่านเอกสารด้วยตนเอง ด้วยประสบการณ์ที่เหมาะสม คุณจะเข้าใจคุณภาพของเอกสารได้อย่างรวดเร็ว สิ่งที่เป็นจริงและสิ่งที่ชัดเจนไม่สอดคล้องกับความเป็นจริง บางครั้งคุณอาจเห็นสถาปัตยกรรมในเอกสารที่ไม่เคยได้ผลในชีวิตจริง นี่เป็นตัวกระตุ้นให้คุณคิดเกี่ยวกับวิธีการทำจริงในโครงการ
เครื่องมือที่มีประโยชน์ในการประเมินโครงการโดยอัตโนมัติ
การประเมินโค้ดเป็นแบบฝึกหัดง่ายๆ คุณสามารถใช้ตัววิเคราะห์โค้ดแบบคงที่ซึ่งจะแสดงการออกแบบ ประสิทธิภาพ และปัญหาด้านความปลอดภัย นี่คือบางส่วนของพวกเขา:
เป็นเครื่องมือที่ยอดเยี่ยมสำหรับสถาปนิก โดยจะแสดงภาพรวม การขึ้นต่อกันระหว่างโมดูลและพื้นที่ที่เป็นไปได้สำหรับการปรับโครงสร้างใหม่ เช่นเดียวกับเครื่องมือที่ดีอื่นๆ มันมีค่าใช้จ่ายที่ดี แต่คุณสามารถใช้ประโยชน์จากเวอร์ชันทดลองใช้งาน 30 วันได้
- เครื่องมือเก่าที่ดี เครื่องมือสำหรับการวิเคราะห์โค้ดแบบคงที่ ช่วยให้คุณสามารถระบุโค้ดที่ไม่ถูกต้อง จุดบกพร่อง และปัญหาด้านความปลอดภัยสำหรับภาษาการเขียนโปรแกรมมากกว่า 20 ภาษา
ผู้ให้บริการคลาวด์ทุกรายมีเครื่องมือตรวจสอบโครงสร้างพื้นฐาน สิ่งนี้จะช่วยให้คุณสามารถประเมินประสิทธิภาพของโครงสร้างพื้นฐานของคุณในแง่ของต้นทุนและประสิทธิภาพได้อย่างเหมาะสม สำหรับ AWS นี่คือ . เป็นเรื่องง่ายสำหรับ Azure .
การตรวจสอบและบันทึกประสิทธิภาพเพิ่มเติมจะช่วยค้นหาปัญหาด้านประสิทธิภาพในทุกระดับ เริ่มต้นจากฐานข้อมูลที่มีการสืบค้นที่ไม่มีประสิทธิภาพ แบ็กเอนด์และลงท้ายด้วยส่วนหน้า แม้ว่าไคลเอนต์จะไม่ได้ติดตั้งเครื่องมือเหล่านี้มาก่อน คุณสามารถรวมเข้ากับระบบที่มีอยู่ได้อย่างรวดเร็วเพื่อระบุปัญหาด้านประสิทธิภาพ
เช่นเคย เครื่องมือที่ดีย่อมคุ้มค่า ฉันสามารถแนะนำเครื่องมือที่ต้องชำระเงินสองสามอย่างได้ แน่นอนว่าคุณสามารถใช้โอเพ่นซอร์สได้ แต่จะใช้เวลานานกว่านั้น และควรทำล่วงหน้า ไม่ใช่ในระหว่างกระบวนการประเมินสถาปัตยกรรม
– เครื่องมือสำหรับประเมินประสิทธิภาพของแอปพลิเคชัน
– บริการตรวจสอบระบบคลาวด์
มีเครื่องมือมากมายสำหรับการทดสอบความปลอดภัย ครั้งนี้ผมจะแนะนำเครื่องมือสแกนระบบฟรีให้กับคุณ
– เครื่องมือสำหรับสแกนเว็บแอปพลิเคชันให้เป็นไปตามมาตรฐานความปลอดภัย
มารวมทุกอย่างเข้าด้วยกันเป็นหนึ่งเดียว
การจัดทำรายงาน
เริ่มรายงานของคุณด้วยข้อมูลที่คุณรวบรวมจากลูกค้า อธิบายเป้าหมายของโครงการ ข้อจำกัด ข้อกำหนดที่ไม่สามารถใช้งานได้ หลังจากนี้ ข้อมูลอินพุตทั้งหมดควรถูกกล่าวถึง: ซอร์สโค้ด เอกสารประกอบ โครงสร้างพื้นฐาน
ขั้นตอนต่อไป. ระบุปัญหาใดๆ ที่คุณพบด้วยตนเองหรือใช้เครื่องมืออัตโนมัติ วางรายงานขนาดใหญ่ที่สร้างขึ้นอัตโนมัติไว้ที่ส่วนท้ายของส่วนแอปพลิเคชัน ควรมีหลักฐานที่สั้นและกระชับเกี่ยวกับปัญหาที่พบ
จัดลำดับความสำคัญของปัญหาที่พบในข้อผิดพลาด คำเตือน ระดับข้อมูล คุณสามารถเลือกขนาดของคุณเองได้ แต่นี่คือขนาดที่ยอมรับโดยทั่วไป
ในฐานะสถาปนิกที่แท้จริง ถือเป็นความรับผิดชอบของคุณในการให้คำแนะนำเพื่อแก้ไขปัญหาที่พบ อธิบายการปรับปรุงและมูลค่าทางธุรกิจที่ลูกค้าจะได้รับ วิธีแสดงมูลค่าธุรกิจจาก เราคุยกันก่อนหน้านี้
เตรียมแผนงานโดยมีการทำซ้ำเล็กน้อย การทำซ้ำแต่ละครั้งควรประกอบด้วยเวลาในการทำให้เสร็จสิ้น คำอธิบาย จำนวนทรัพยากรที่จำเป็นสำหรับการปรับปรุง คุณค่าทางเทคนิค และมูลค่าทางธุรกิจ
เราทำการประเมินสถาปัตยกรรมให้เสร็จสิ้นและจัดทำรายงานให้กับลูกค้า
อย่าเพิ่งส่งรายงานทางไปรษณีย์ อาจอ่านไม่ได้เลยหรืออาจอ่านและทำความเข้าใจไม่ได้หากไม่มีคำอธิบายที่ถูกต้อง กล่าวโดยสรุป การสื่อสารสดช่วยขจัดความเข้าใจผิดระหว่างผู้คน คุณควรกำหนดเวลาการประชุมกับลูกค้าและพูดคุยเกี่ยวกับปัญหาที่พบ โดยเน้นไปที่ปัญหาที่สำคัญที่สุด เป็นการคุ้มค่าที่จะดึงความสนใจของลูกค้าไปยังปัญหาที่เขาอาจไม่รู้ด้วยซ้ำ เช่นปัญหาด้านความปลอดภัยและอธิบายว่าจะส่งผลกระทบต่อธุรกิจได้อย่างไร แสดงแผนงานของคุณพร้อมการปรับปรุงและหารือเกี่ยวกับตัวเลือกต่างๆ ที่เหมาะกับลูกค้ามากขึ้น นี่อาจเป็นเวลา ทรัพยากร ปริมาณงาน
เพื่อสรุปการประชุมของคุณ ให้ส่งรายงานของคุณไปยังลูกค้า
ในข้อสรุป
การประเมินสถาปัตยกรรมเป็นกระบวนการที่ซับซ้อน เพื่อดำเนินการประเมินได้อย่างเหมาะสม คุณต้องมีประสบการณ์และความรู้เพียงพอ
คุณสามารถมอบผลลัพธ์ที่เป็นประโยชน์ต่อเขาและธุรกิจให้กับลูกค้าได้ภายในเวลาเพียงหนึ่งสัปดาห์ ถึงแม้จะทำคนเดียวก็ตาม
จากประสบการณ์ของฉัน มีการดาวน์โหลดการปรับปรุงหลายอย่างไว้ตรงกลาง และบางครั้งก็ไม่เคยเริ่มต้นเลย ผู้ที่เลือกค่าเฉลี่ยสีทองสำหรับตนเองและทำการปรับปรุงเพียงบางส่วนที่มีประโยชน์มากที่สุดสำหรับธุรกิจโดยมีค่าแรงน้อยที่สุดทำให้คุณภาพของผลิตภัณฑ์ของตนดีขึ้นอย่างมาก ผู้ที่ไม่ทำอะไรเลยสามารถปิดโครงการทั้งหมดได้หลังจากผ่านไปสองสามปี
เป้าหมายของคุณคือการแสดงให้ลูกค้าเห็นถึงการปรับปรุงสูงสุดในราคาขั้นต่ำ
บทความอื่น ๆ จากส่วน คุณสามารถอ่านได้ในยามว่าง
ฉันขอให้คุณทำความสะอาดโค้ดและการตัดสินใจทางสถาปัตยกรรมที่ดี
กลุ่ม Facebook ของเรา - .
ที่มา: will.com