วิศวกรซอฟต์แวร์คือใคร? วิศวกรรมซอฟต์แวร์ VS การเขียนโปรแกรมแบบ “เพียง”

เราขอแจ้งให้คุณทราบถึงการดัดแปลงบทความของ Samer Buna เกี่ยวกับความแตกต่างระหว่างวิศวกรรมซอฟต์แวร์และการเขียนโปรแกรม หรือการพัฒนาแนวคิดซอฟต์แวร์แตกต่างจาก "แค่การเขียนโค้ด" อย่างไร วิศวกรซอฟต์แวร์ทุกคนสามารถเขียนโค้ดได้ แต่โปรแกรมเมอร์บางคนไม่สามารถพัฒนาแนวคิดซอฟต์แวร์ได้ บางคนไม่ชอบคำว่า "วิศวกรซอฟต์แวร์" (หรือที่รู้จักในชื่อ Software Engineer) เพราะส่วนใหญ่แล้วเราใช้คำว่า "วิศวกร" เมื่อพูดถึงบางสิ่งที่มีลักษณะทางกายภาพมากกว่า เช่น โครงสร้าง เป็นต้น บทความของเราแน่นอนว่าไม่เกี่ยวกับคำศัพท์นั้นเอง หากจู่ๆ มันทำให้คุณถูกปฏิเสธ ก็สามารถถูกแทนที่ด้วยสิ่งที่เกี่ยวข้องกับความคิดสร้างสรรค์ได้อย่างง่ายดาย “ผู้สร้างซอฟต์แวร์”, “ผู้เขียนซอฟต์แวร์”... หรือแม้แต่ “ผู้สร้างซอฟต์แวร์”! ความสามารถในการเขียนโปรแกรมไม่ได้ทำให้บุคคลนั้นเป็นวิศวกรซอฟต์แวร์โดยอัตโนมัติ ใครๆ ก็สามารถเรียนรู้การเขียนโค้ดได้ และมันง่ายกว่าที่คิดไว้มาก ใครๆ ก็สามารถสร้างโปรแกรมง่ายๆ ไว้ใช้เองได้ แต่ไม่ได้รับประกันว่าโปรแกรมเดียวกันนี้จะใช้ได้กับผู้อื่น ตัวอย่างที่ฉันชอบคือ พวกเราหลายคนร้องเพลงตอนอาบน้ำ แต่อนิจจา การแสดงนี้ไม่คู่ควรกับการแสดงบนเวทีมืออาชีพเสมอไป แน่นอนว่าหากต้องการประสบการณ์ทางดนตรีคุณภาพสูง คุณมักจะกลายเป็นมืออาชีพ คุณต้องการตัวอย่างเพิ่มเติมหรือไม่?

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

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

กรอบความคิดทางวิศวกรรม - ค้นหาแนวทางแก้ไขที่ประยุกต์ใช้

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

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

คุณภาพของโปรแกรมและคุณภาพของโค้ด

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

สภาพแวดล้อมและการทดสอบ

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

ต้นทุนและประสิทธิภาพ

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

มุ่งเน้นไปที่ประสบการณ์ผู้ใช้

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

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

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

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




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

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

ความน่าเชื่อถือความปลอดภัยและความปลอดภัย

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

เครื่องมือที่จำเป็น

ไม่ต้องสงสัยเลยว่าเราต้องการเครื่องมือในการพัฒนาที่แตกต่างและดี บทบาทของพวกเขามักจะถูกประเมินต่ำเกินไป แต่ในความเป็นจริงแล้ว พวกเขาประหยัดเวลาและความพยายามได้มาก ทำให้งานบางอย่างง่ายขึ้นตามลำดับความสำคัญ ลองนึกภาพหากคุณยังต้องอัปโหลดไฟล์ผ่าน FTP เพื่อใช้งาน ซึ่งถือเป็นวิธีที่ล้าสมัย ลองนึกภาพการแก้ไขข้อบกพร่องของเครือข่ายและปัญหาด้านประสิทธิภาพโดยไม่ต้องใช้ Chrome DevTools! และการเขียนโค้ด JavaScript โดยไม่มี ESlit และ Prettier จะไม่มีประสิทธิภาพเพียงใดในทุกวันนี้! เครื่องมือใดๆ ก็ตามที่ช่วยลดเวลาตอบกลับในขณะที่คุณเขียนโค้ดควรได้รับการต้อนรับ เมื่อฉันพบเครื่องมือที่ฉันไม่เคยคุ้นเคยมาก่อน แต่มีประโยชน์และมีประสิทธิภาพอย่างแท้จริง ฉันเสียใจที่ไม่ได้ใช้มันก่อนช่วงเวลาแห่งความสุขนั้น

วิวัฒนาการของวิศวกรรมซอฟต์แวร์

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