ปัญหาที่เกิดขึ้นในกระบวนการผลิตกำลังค่อยๆได้รับความสนใจจากผู้บริหารระดับกลางและระดับสูง ไม่ว่าคุณจะเป็นนักพัฒนาหรือสถาปนิก คุณควรใส่ใจกับสิ่งต่อไปนี้ให้เพียงพอเพื่อหลีกเลี่ยงไม่ให้ตกอยู่ในสถานการณ์ที่น่าอับอายในอนาคต คุณยังสามารถใช้เป็นบันทึกการแก้ไขปัญหาได้
#1 อย่าส่งออกคุณสมบัติการกำหนดค่าภายนอกในไฟล์คุณสมบัติหรือไฟล์ XML ตัวอย่างเช่น จำนวนเธรดที่ใช้โดยการประมวลผลแบบแบตช์ไม่ได้ตั้งค่าให้กำหนดค่าได้ในไฟล์คุณสมบัติ โปรแกรมแบตช์ของคุณสามารถทำงานได้อย่างราบรื่นไม่ว่าจะในสภาพแวดล้อม DEV หรือสภาพแวดล้อม UAT (การทดสอบการยอมรับของผู้ใช้) แต่เมื่อปรับใช้บน PROD เมื่อใช้เป็นโปรแกรมแบบมัลติเธรดเพื่อประมวลผลชุดข้อมูลขนาดใหญ่ IOException จะถูกส่งออกไป อาจเนื่องมาจากเวอร์ชันไดรเวอร์ JDBC ที่แตกต่างกัน หรือเนื่องจากปัญหาที่กล่าวถึงใน #2 หากสามารถกำหนดค่าจำนวนเธรดในไฟล์คุณสมบัติได้ จะทำให้เป็นเรื่องง่ายมากที่จะทำให้เป็นแอปพลิเคชันแบบเธรดเดียว เราไม่จำเป็นต้องปรับใช้และทดสอบแอปพลิเคชันซ้ำๆ เพื่อแก้ไขปัญหาอีกต่อไป วิธีนี้ยังเหมาะสำหรับการกำหนดค่า URL เซิร์ฟเวอร์และหมายเลขพอร์ต ฯลฯ
#2. ขนาดของชุดข้อมูลที่ใช้ในการทดสอบไม่เหมาะสม ตัวอย่างเช่น สถานการณ์ทั่วไประหว่างการใช้งานจริงคือการใช้เพียง 1 ถึง 3 บัญชีสำหรับการทดสอบ เมื่อจำนวนควรเป็น 1,000 ถึง 2,000 เมื่อทำการทดสอบประสิทธิภาพ ข้อมูลที่ใช้ต้องเป็นข้อมูลจริงและไม่ได้ครอบตัด การทดสอบประสิทธิภาพที่ไม่ได้ใกล้เคียงกับสภาพแวดล้อมจริงอาจทำให้เกิดปัญหาด้านประสิทธิภาพ การขยาย และมัลติเธรดที่คาดเดาไม่ได้ มีเพียงการทดสอบแอปพลิเคชันกับชุดข้อมูลที่มีขนาดใหญ่กว่าเท่านั้น คุณจึงมั่นใจได้ว่าแอปพลิเคชันทำงานได้อย่างถูกต้องและเป็นไปตาม SLA (มาตรฐานระดับบริการ) สำหรับแอตทริบิวต์ที่ไม่สามารถใช้งานได้
#3 เชื่ออย่างไร้เดียงสาว่าบริการภายนอกและภายในที่ถูกเรียกในแอปพลิเคชันนั้นมีความน่าเชื่อถือและพร้อมใช้งานอยู่เสมอ การไม่อนุญาตให้มีการหมดเวลาการเรียกบริการและลองใหม่จะส่งผลเสียต่อความเสถียรและประสิทธิภาพของแอปพลิเคชัน จำเป็นต้องมีการทดสอบการหยุดให้บริการที่เหมาะสม นี่เป็นสิ่งสำคัญเนื่องจากแอปพลิเคชันในปัจจุบันส่วนใหญ่เป็นแบบกระจายและเน้นการบริการ ซึ่งต้องการบริการเครือข่ายจำนวนมาก การร้องขอบริการที่ไม่สามารถใช้งานได้อย่างไม่มีที่สิ้นสุดอาจเป็นอันตรายต่อแอปพลิเคชันของคุณ นอกจากนี้ โหลดบาลานเซอร์ยังต้องได้รับการทดสอบเพื่อให้แน่ใจว่าทำงานได้อย่างถูกต้องเพื่อให้แต่ละโหนดมีความสมดุล
#4. ไม่ปฏิบัติตามข้อกำหนดด้านความปลอดภัยขั้นต่ำ ตามที่กล่าวไว้ข้างต้น บริการเครือข่ายมีอยู่ทั่วไปทุกหนทุกแห่ง ทำให้แฮกเกอร์สามารถใช้ประโยชน์จากบริการเหล่านี้เพื่อการโจมตีแบบปฏิเสธการให้บริการได้อย่างง่ายดาย ดังนั้น เมื่อใช้ Secure Sockets Layer คุณต้องทำการตรวจสอบขั้นพื้นฐานให้เสร็จสิ้นและทำการทดสอบการเจาะระบบโดยใช้เครื่องมือ เช่น Google Skipfish แอปพลิเคชันที่ไม่ปลอดภัยไม่เพียงแต่คุกคามเสถียรภาพของตนเองเท่านั้น แต่ยังส่งผลเสียต่อชื่อเสียงของบริษัทเนื่องจากปัญหาความสมบูรณ์ของข้อมูล เช่น สถานการณ์ที่ลูกค้า "A" สามารถดูข้อมูล "B" ของลูกค้าได้
#5 ไม่มีการทดสอบความเข้ากันได้ข้ามเบราว์เซอร์ เว็บแอปพลิเคชันในปัจจุบันส่วนใหญ่เป็นแอปพลิเคชันหน้าเดียวที่สมบูรณ์ซึ่งใช้ภาษาการเขียนโปรแกรม JavaScript และเฟรมเวิร์ก เช่น เชิงมุม js เพื่อให้เว็บไซต์ที่คุณสร้างทำงานได้อย่างราบรื่นบนอุปกรณ์และเบราว์เซอร์ต่างๆ คุณต้องใช้การออกแบบที่เกี่ยวข้อง ดังนั้นเพื่อให้แน่ใจว่าแอปของคุณทำงานได้กับทุกอุปกรณ์และเบราว์เซอร์ จึงต้องมีการทดสอบความเข้ากันได้
#6. ไม่ละเมิดกฎเกณฑ์ทางธุรกิจที่อาจเปลี่ยนแปลงบ่อยครั้ง ตัวอย่างเช่น กฎหมายภาษี ข้อกำหนดที่เกี่ยวข้องกับรัฐบาลหรืออุตสาหกรรม การจัดหมวดหมู่ ฯลฯ คุณสามารถใช้กลไกเช่น Drools เพื่อประมวลผลกฎเกณฑ์ทางธุรกิจ ซึ่งช่วยให้คุณนำกฎเกณฑ์ทางธุรกิจเหล่านี้ไปใช้ภายนอกได้โดยการเก็บไว้ในฐานข้อมูลหรือ Excel เมื่อองค์กรต่างๆ เชี่ยวชาญกฎเกณฑ์ทางธุรกิจเหล่านี้แล้ว พวกเขาจะสามารถตอบสนองกฎหมายภาษีหรือข้อกำหนดที่เกี่ยวข้องได้อย่างรวดเร็วโดยมีการเปลี่ยนแปลงและทดสอบเพียงเล็กน้อย
#7. ไม่มีเอกสารดังต่อไปนี้
นอกจาก COS (เงื่อนไขของความพึงพอใจ) ซึ่งเป็นแบบฟอร์มที่สร้างโดย MindMap แล้ว ยังมีแบบฟอร์มเอกสารหลักสองรูปแบบใน การพัฒนาแบบ Agile คือ 1 และ 2
#8. ไม่มีแผนการกู้คืนระบบที่เหมาะสมและกลยุทธ์การติดตามและการเก็บถาวร เมื่อใกล้ถึงกำหนดเวลาของโครงการ สิ่งเหล่านี้มักจะพลาดไปในการเร่งรีบในการปรับใช้โครงการ การไม่มีการตรวจสอบระบบที่เหมาะสมกับ Nagios และ Splunk ไม่เพียงแต่คุกคามความเสถียรของแอปพลิเคชันของคุณเท่านั้น แต่ยังขัดขวางการวินิจฉัยในปัจจุบันและความพยายามในการปรับปรุงในอนาคตอีกด้วย
#9 ไม่มีการออกแบบคอลัมน์ที่สะดวกสำหรับตารางฐานข้อมูล เช่น create_datetm, update_datetm, create_by, added_by และ timestamp นอกจากนี้ยังไม่มีคอลัมน์บันทึกการลบอย่างเป็นระเบียบ เช่น คอลัมน์ 'deleted' ที่สามารถรับ 'Y' หรือ 'N' หรือคุณสามารถใช้คอลัมน์ 'record_status' ของ 'Active' หรือ 'Inactive'
#10. ความล้มเหลวในการพัฒนาแผนการย้อนกลับที่เหมาะสม เป็นผลให้เมื่อระบบล้มเหลว ไม่มีทางที่จะกู้คืนระบบไปสู่สถานะที่เสถียรก่อนที่จะนำไปใช้งาน แผนนี้จะต้องได้รับการพิจารณาอย่างรอบคอบและลงนามโดยทีมงานที่เกี่ยวข้อง แผนต่างๆ รวมถึงการย้อนกลับไปใช้ซอฟต์แวร์เวอร์ชันก่อนหน้า ลบข้อมูลทั้งหมดที่แทรกลงในฐานข้อมูล และรายการทั้งหมดในไฟล์คุณสมบัติ
#11. ความล้มเหลวในการพัฒนาแผนกำลังการผลิตก่อนที่โครงการจะเริ่มต้น ทุกวันนี้ เมื่ออธิบายข้อกำหนดของแพลตฟอร์ม พูดง่ายๆ ว่า "ต้องใช้คอมพิวเตอร์ Unix, เซิร์ฟเวอร์ฐานข้อมูล Oracle และเซิร์ฟเวอร์แอปพลิเคชัน JBoss" ยังไม่เพียงพอ คำขอของคุณต้องชัดเจน
#12 ด้านล่างมาจากความคิดเห็นของ "David DeCesare" จาก "java.dzone"
#12 “อย่าใช้เครื่องมือที่ดีที่สุดสำหรับงาน” ในหลายกรณี นักพัฒนาจะใช้ภาษาหรือเครื่องมือที่ต้องการเรียนรู้ในระบบที่ใช้งานจริง โดยปกติแล้วนี่ไม่ใช่ตัวเลือกที่ดีที่สุด ตัวอย่างเช่น การใช้ฐานข้อมูล NoSQL สำหรับข้อมูลที่มีความสัมพันธ์กันจริงๆ แล้ว โปรดจำไว้ว่า ไม่ว่าคุณจะใช้เครื่องมือใด คุณจะต้องรักษาผลิตภัณฑ์ของคุณไว้เป็นเวลา 3 ถึง 5 ปี (หรือนานกว่านั้น)
#13. ขาดความรู้เพียงพอใน 16 ด้านทางเทคนิคที่สำคัญ พื้นที่เหล่านี้ประกอบด้วยการระบุและแก้ไข 1) "ปัญหาการทำงานพร้อมกัน" 2) ปัญหาธุรกรรม และ 3) ปัญหาด้านประสิทธิภาพ ในการสัมภาษณ์หลายครั้ง ฉันอาศัยความรู้ทั้งสามด้านนี้เพื่อรับสัญญาใหม่