“สวัสดี อามีโก้!”

"สวัสดี บิลาโบ!"

"วันนี้ฉันจะบอกคุณเกี่ยวกับวิธีการพัฒนาโปรแกรมโดยทั่วไป"

"ในศตวรรษที่ 20 เมื่อไอทีสมัยใหม่ยังอยู่ในช่วงเริ่มต้น ทุกคนดูเหมือนจะคิดว่าการเขียนโปรแกรมก็เหมือนการก่อสร้างหรือการผลิต"

"สิ่งต่าง ๆ มักจะเป็นเช่นนี้:"

" ลูกค้าจะอธิบายประเภทของโปรแกรมที่เขาต้องการ — สิ่งที่ควรทำและควรทำอย่างไร"

" นักวิเคราะห์ธุรกิจจะฟังเขาและจัดทำรายการข้อกำหนดของโปรแกรมทั้งหมดตามสิ่งที่เขาพูด"

"จากนั้นผู้จัดการโครงการจะแบ่งข้อกำหนดเหล่านี้ออกเป็นงานต่างๆ และจะกำหนดด้วยว่าโปรแกรมเมอร์คนใดจะทำงานอะไรและเรียงลำดับอย่างไร"

"จากนั้นโปรแกรมเมอร์จะได้ทำงาน บางครั้งพวกเขาอาจทำงานหลายปี (!)"

"เมื่อเสร็จแล้ว โปรแกรมก็มอบให้กับผู้ทดสอบ"

" ผู้ทดสอบจะต้องปฏิบัติตามข้อกำหนดแต่ละข้อของโปรแกรมเพื่อตรวจสอบว่ามีการใช้งานจริงและโปรแกรมทำงานตามที่ควรจะเป็น"

"หากเกิดข้อผิดพลาด ผู้ทดสอบจะบันทึกข้อบกพร่องและส่งไปยังโปรแกรมเมอร์"

"จากนั้นโปรแกรมเมอร์จะแก้ไขข้อบกพร่องและส่งโปรแกรมที่แก้ไขแล้วกลับไปยังผู้ทดสอบ และวงจรก็จะวนซ้ำ"

"เมื่อจุดบกพร่องหลักได้รับการแก้ไขแล้ว โปรแกรมจะถูกส่งให้กับลูกค้า"

“เป็นอย่างนั้นจริงๆ เหรอ?”

"แน่นอนว่าฉันได้ทำให้ง่ายขึ้นมาก แต่นั่นก็ค่อนข้างใกล้เคียงกับวิธีการทำสิ่งต่างๆ"

"และโครงการอาจใช้เวลาหนึ่งปีครึ่งถึงสองปีจริง ๆ จึงจะเสร็จสมบูรณ์"

"บางครั้งหากการพัฒนาโครงการใช้เวลานานมาก พวกเขาจะแยกออกเป็นรุ่นย่อยๆ ทุก 3-6 เดือน นักพัฒนาต้องสร้างส่วนเฉพาะของฟังก์ชันการทำงานของโปรแกรม ทดสอบ แก้ไขจุดบกพร่องทั้งหมด และแสดงต่อ ลูกค้า."

Java university

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

“จ่ายต่อไหม”

"ในสมัยนั้น การพัฒนามักใช้เวลานานกว่าที่วางแผนไว้ 2-3 เท่า และเนื่องจากโปรแกรมเมอร์มักได้รับค่าจ้างรายชั่วโมง โปรแกรมจึงมีราคาแพงขึ้น 2-3 เท่า ยิ่งไปกว่านั้น ผลประโยชน์ยังลดลงอีกด้วย เพราะทุกวันนี้ สิ่งที่ลูกค้าต้องการ อาจไม่ต้องการเงิน 100,000 ดอลลาร์ใน 3 ปี — โดยเฉพาะอย่างยิ่งในราคาที่สูงกว่าสามเท่า”

“ลูกค้าปฏิเสธการจ่ายเงินบ่อยไหม?”

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

"แต่ทำไม?"

"อย่างแรก เรารู้น้อยเกินไปในระหว่างขั้นตอนการวางแผน บ่อยครั้งกว่านั้น ในตอนเริ่มต้น ไม่มีใครสามารถคาดเดาปัญหาที่โปรแกรมเมอร์จะเผชิญได้"

"แต่โปรแกรมเมอร์ที่มีประสบการณ์ควรจะสามารถคาดการณ์ทุกอย่างได้ใช่ไหม"

"คุณเห็นไหมว่าการเขียนโปรแกรมเป็นอาชีพที่ไม่เหมือนใคร"

"คนงานทั่วไปมักจะทำงานเดิมๆ ซ้ำแล้วซ้ำอีก ช่างทำนาฬิกา ทำนาฬิกา พ่อครัวทำอาหาร ครูสอน หมอรักษา ฯลฯ"

"มืออาชีพเหล่านี้แต่ละคนทำสิ่งเดิมๆ วันแล้ววันเล่า ผลก็คือ พวกเขาเริ่มทำงานได้ดีขึ้นเรื่อย ๆ ในหน้าที่การงาน"

"ในการเขียนโปรแกรม แนวทางจะแตกต่างออกไป ทันทีที่โปรแกรมเมอร์ต้องเผชิญกับงานเดิมๆ ทุกวัน เขาจะเขียนฟังก์ชัน โมดูล หรือโปรแกรมเพื่อดำเนินการ และจะไม่กลับมาทำมันอีก"

"โปรแกรมเมอร์แต่ละคนมักจะแก้งานแต่ละอย่างได้เพียงครั้งเดียวในชีวิต"

"บางอย่างเช่นนักวิทยาศาสตร์หรือวิศวกรออกแบบที่ประดิษฐ์สิ่งต่างๆ"

"อ่า หน้าที่ที่สำคัญที่สุดในโครงการคืออะไร"

“อืม ฉันจะตอบยังไงดี พูดง่ายๆ ว่าสิ่งไหนสำคัญที่สุด แต่การระบุสิ่งที่สำคัญน้อยที่สุดนั้นยาก”

" งานหลักของผู้ทดสอบ ( Q uality  A ssurance, QA ) คือการตรวจสอบสถานะของโปรแกรมและรายงานจุดบกพร่องโดยทันที ยิ่งผู้ทดสอบพบจุดบกพร่องมากเท่าใดก็ยิ่งสามารถแก้ไขได้มากเท่านั้น  ผู้ทดสอบที่ดีมีอิทธิพลต่อคุณภาพของผลิตภัณฑ์มากกว่า โปรแกรมเมอร์ที่ดีทำได้ "

"ทำไมโปรแกรมเมอร์ถึงทดสอบโปรแกรมของตัวเองไม่ได้ ท้ายที่สุดแล้ว พวกเขาไม่รู้ดีกว่านักทดสอบหรอกว่าอะไรทำงานได้และไม่ได้ผล"

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

"นอกจากนี้ ผู้ทดสอบจะไม่ทดสอบสิ่งที่ยังใช้งานไม่ได้ ผู้ทดสอบจะทดสอบการทำงานหรือส่วนต่างๆ ของโปรแกรมที่โปรแกรมเมอร์บอกว่าทำงานได้เกือบจะสมบูรณ์แบบอยู่แล้ว"

"และเมื่อผู้ทดสอบพบข้อบกพร่องมากมายในฟังก์ชันการทำงานนั้น และโปรแกรมเมอร์แก้ไขข้อบกพร่องนั้น ผลิตภัณฑ์ก็จะเข้าใกล้ความสมบูรณ์แบบมากขึ้น"

" งานหลักของโปรแกรมเมอร์ ( S oftware  D eveloper  E ngineer,  D eveloper ,  SDE )คือการนำฟังก์ชันใหม่ไปใช้ หรือพูดง่าย ๆ ก็คือ เพื่อทำงานที่ได้รับมอบหมาย เมื่อโปรแกรมเมอร์ได้รับมอบหมายงานด้วยคุณสมบัติใหม่ พวกเขาทำมัน เมื่อได้รับมอบหมายข้อบกพร่อง พวกเขาแก้ไขข้อบกพร่อง"

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

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

"นอกจากนี้ หากสถาปัตยกรรมประสบความสำเร็จและโปรแกรมออกมาดีเยี่ยม ลูกค้าอาจจะต้องการใช้สถาปัตยกรรมนี้เป็นพื้นฐานสำหรับเวอร์ชันใหม่ของโปรแกรม"

"นี่คือสิ่งที่ฉันได้รับ"

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

"นี่คือตัวอย่างที่ดี"

"ลูกค้าขอให้คุณสร้างอาคาร 5 ชั้น คุณจึงออกแบบสถาปัตยกรรมและสร้างบ้าน"

"แล้วลูกค้าก็ขอเพิ่มอีกเรื่อง แล้วก็อีกเรื่อง"

"แต่ผนังชั้น 1 ไม่ได้ออกแบบมาให้รับน้ำหนักมากขนาดนั้น และไม่ใช่ฐานรากด้วย ดังนั้นทุกอย่างจึงต้องทำใหม่ทั้งหมด"

“แต่หลังจากสร้างตึก 5 ชั้นเสร็จแล้ว ถ้าลูกค้าตัดสินใจทันทีว่าต้องการตึก 50 ชั้นล่ะ”

"จะเป็นการง่ายกว่าที่จะรื้อโครงสร้างที่มีอยู่แล้วสร้างใหม่ทั้งหมดตั้งแต่เริ่มต้น..."

"แต่ฉันมีคำแนะนำสำหรับคุณเกี่ยวกับสถาปัตยกรรม"

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

" งานหลักของผู้จัดการโครงการคือการตัดสินใจ ผู้จัดการโครงการคือผู้ที่มองเห็นภาพรวมและตัดสินใจตามมุมมองนั้น"

"สมมติว่าในระหว่างการพัฒนา เห็นได้ชัดว่างานบางอย่างจะไม่สำเร็จตามแผน ผู้จัดการโครงการสามารถ:"

" ก)  พยายามเจรจากับลูกค้าเพื่อแก้ไขงาน"

" b)  จัดสรรเวลาให้กับงานมากขึ้น"

" c)  นำโปรแกรมเมอร์ที่มีประสบการณ์มากกว่าจากโครงการอื่นเข้ามา"

"และมีความเป็นไปได้อื่น ๆ อีกมากมาย"

"แต่ละตัวเลือกต้องการให้คุณเสียสละบางสิ่ง และ งานของผู้จัดการคือลดการสูญเสียทั้งหมดจากการเสียสละเหล่านี้ให้เหลือน้อยที่สุด "

"ตัวอย่างเช่น สมมติว่าคู่แข่งขโมยหัวหน้าโปรแกรมเมอร์โดยเสนอเงินให้เขาสองเท่า"

"ผู้จัดการโครงการสามารถ:"

" ก)  ไม่ต้องทำอะไรเลย โปรแกรมเมอร์จะออกไป และโครงการอาจล้าหลังและมีบทลงโทษ"

" b)  เพิ่มเงินเดือนของเขาเป็นสองเท่า จากนั้นทุกคนในทีมก็ต้องการขึ้นเงินเดือนด้วย หากคุณให้เงินเพิ่มทั้งหมด ต้นทุนของโครงการก็จะเพิ่มขึ้นและอาจไม่ได้ประโยชน์"

" c)  ตัวเลือกอื่น ๆ ที่คุณคิดขึ้น

"ฉันเห็น."

"เมื่อมีผู้จัดการโครงการที่ไม่ดี ทีมที่ดีมักจะทำให้โครงการยาวขึ้น แต่ก็ไม่เสมอไป"

"ผู้จัดการที่ดีที่มีทีมโปรแกรมเมอร์ธรรมดาๆ มักจะทำโปรเจกต์ให้เสร็จได้เร็วกว่าผู้จัดการที่แย่ๆ ที่มีทีมโปรแกรมเมอร์ที่ยอดเยี่ยม"

"ฉันเห็น."

“เอาล่ะ พักสักครู่ แล้วเราจะไปกันต่อ”