คำถามติดแท็ก development-process

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ปิดให้บริการใน4 ปีที่แล้ว ล็อคแล้ว คำถามและคำตอบของคำถามนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ฉันเป็นแฟนตัวยงของรายการตรวจสอบ มีรายการตรวจสอบการเดินทาง , การย้ายรายการตรวจสอบและแม้กระทั่งรายการตรวจสอบการแย่งชิงกัน บริบท : คุณได้รับการว่าจ้างจาก บริษัท ขนาดใหญ่และกำหนดภารกิจในการติดตั้งสภาพแวดล้อมการพัฒนาซอฟต์แวร์กระบวนการทีม ฯลฯ คุณมี "carte blanche" คุณจะต้องรับผิดชอบในการสร้างการเพิ่มขึ้นของการทำงานของซอฟต์แวร์ ขนาดโครงการ: 2,000 คน / วัน รายการใดบ้างที่คุณจะเพิ่มในรายการตรวจสอบ (เล็กและไม่สมบูรณ์) ต่อไปนี้: ติดตั้งเซิร์ฟเวอร์การรวมอย่างต่อเนื่อง เขียนกระทรวง เขียนแนวทางการเข้ารหัสหนึ่งหน้า สร้างสินค้าค้าง ติดตั้งระบบติดตามบั๊ก กำหนดเวลาหน้าปกติ

14 project-management  development-process 

codebase ที่ผ่านการทดสอบเป็นอย่างดีมีประโยชน์หลายประการ แต่การทดสอบบางแง่มุมของระบบจะส่งผลให้เป็น codebase ที่ทนทานต่อการเปลี่ยนแปลงบางประเภท ตัวอย่างคือการทดสอบผลลัพธ์เฉพาะ - เช่นข้อความหรือ HTML การทดสอบมักจะเขียน (ไร้เดียงสา?) เพื่อคาดหวังว่าจะมีบล็อกข้อความที่เฉพาะเจาะจงเป็นเอาต์พุตสำหรับพารามิเตอร์ป้อนเข้าบางส่วนหรือเพื่อค้นหาส่วนเฉพาะในบล็อก การเปลี่ยนพฤติกรรมของรหัสเพื่อตอบสนองความต้องการใหม่หรือเนื่องจากการทดสอบการใช้งานได้ส่งผลให้เกิดการเปลี่ยนแปลงในส่วนต่อประสานจำเป็นต้องเปลี่ยนการทดสอบด้วย - บางทีแม้แต่การทดสอบที่ไม่ได้เป็นการทดสอบหน่วยโดยเฉพาะสำหรับรหัสที่กำลังเปลี่ยนแปลง คุณจะจัดการงานในการค้นหาและเขียนการทดสอบเหล่านี้ใหม่ได้อย่างไร? จะทำอย่างไรถ้าคุณไม่สามารถ "เรียกใช้" ทั้งหมดและปล่อยให้กรอบเรียงลำดับออก " ผลการทดสอบภายใต้รหัสอื่น ๆ ประเภทใดในการทดสอบที่เปราะบางเป็นปกติ

14 development-process  tdd 

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

14 development-process  agile 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน2 ปีที่ผ่านมา วิธีการที่เป็นทางการสามารถใช้เพื่อระบุพิสูจน์และสร้างรหัสสำหรับแอปพลิเคชัน นี่เป็นโอกาสที่จะเกิดข้อผิดพลาดได้น้อยซึ่งส่วนใหญ่จะใช้ในโปรแกรมความปลอดภัย / วิกฤติ ทำไมเราไม่ใช้มันบ่อยกว่าสำหรับการเขียนโปรแกรมทุกวันหรือในเว็บแอปพลิเคชัน ฯลฯ ... การอ้างอิง: วิธีการอย่างเป็นทางการ วิธีการ B Hoare Logic

14 development-process  code-quality  formal-methods 

ผมอ่านมาก Programming อธิบาย, Second Editionและในบทที่ 11 "ทฤษฎีของข้อ จำกัด" ผู้เขียนพูดคุยเกี่ยวกับความเก่าและล้าสมัย"ดัน" การพัฒนารูปแบบและวิธีการ XP ที่"ดึง" รูปแบบการพัฒนา ดูเหมือนแนวคิดที่สำคัญ แต่จะมีเพียงย่อหน้าเล็ก ๆ และสองภาพเท่านั้นที่เป็นภาพประกอบของ "น้ำตก" และกระบวนการวนซ้ำไม่มีอะไรเฉพาะเจาะจงเกี่ยวกับโมเดลเหล่านี้ยกเว้นจากคำบรรยายภาพ ฉันค้นหาและไม่ไปเพิ่มเติมเกี่ยวกับเรื่องนี้ในส่วนที่เหลือของหนังสือ ฉันไม่สามารถหาคำอธิบายหรือการอภิปรายเพิ่มเติมในอินเทอร์เน็ตได้เช่นกัน หากความแตกต่างเพียงอย่างเดียวเกี่ยวกับสิ่งนั้นคือหนึ่งคือ"น้ำตก"และอีกอย่างหนึ่งคือซ้ำพวกเขาจะผลักทำไมและดึงทำไม? มีใครบ้างที่เข้าใจว่าอะไรคือความแตกต่างระหว่างทั้งสองกับตัวอย่างที่ดี?

14 agile  development-process  extreme-programming 

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

14 development-process  management 

ฉันเสร็จหนึ่งในโครงการ C ++ ที่เร็วที่สุดซึ่งก็คือ (ตามกรอบ) ที่ควรจะเป็นข้ามแพลตฟอร์ม ฉันพัฒนาโครงการอย่างสมบูรณ์ใน Windows และ Visual Studio โดยคิดว่าเนื่องจากห้องสมุดเป็นแพลตฟอร์มข้ามแพลตฟอร์มทั้งหมดดังนั้นการทำ OSX build "ในภายหลัง" จึงเป็นเรื่องเล็กน้อย สิ่งนี้กลับกลายเป็นว่าไม่ใช่กรณี แต่ "รหัส Windows" ทำงานไม่ถูกต้องและมีข้อผิดพลาดในการรวบรวมเพื่อแก้ไข เทคนิคใดที่มีอยู่ก่อนเพื่อให้แน่ใจว่ารหัสเข้ากันได้กับทุกแพลตฟอร์ม? การพัฒนาแพลตฟอร์มทั้งหมดพร้อมกันดังนั้นจึงทดสอบโค้ดกับทุกแพลตฟอร์มในเวลาเดียวกันเมื่อมีการเพิ่มฟีเจอร์ใหม่แทนที่จะพัฒนาแพลทฟอร์มรุ่นที่แตกต่างกันหลังจากนั้นหรือไม่ (*) มองหาคำแนะนำเฉพาะที่ไม่ได้ขึ้นอยู่กับเครื่องมือ แต่เป็น "กระบวนการพัฒนา" ที่ช่วยให้สามารถทำงานร่วมกันได้ข้ามแพลตฟอร์มโดยไม่คำนึงถึงเครื่องมือที่ใช้ เช่นเดียวกับ (*) ด้านบน โดยเฉพาะฉันกำลังพัฒนาปลั๊กอิน VST ด้วย WDL-OL ( https://github.com/olilarkin/wdl-ol ) และห้องสมุด DSP ข้ามแพลตฟอร์ม โครงการ WDL-OL มีทั้งโครงการ VS และ Xcode ตั้งค่า แต่ฉันเดาว่าปัญหามาจากไลบรารีและจากนั้นความแตกต่างในคอมไพเลอร์

13 c++  development-process  cross-platform 

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

13 development-process  tools  issue-tracking 

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

13 project-management  version-control  development-process  documentation  builds 

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

13 project-management  development-process  product-design  product-development 

รู้เบื้องต้นเกี่ยวกับสถานการณ์ของฉัน ฉันทำงานให้กับ บริษัท พัฒนาเว็บไซต์ขนาดเล็ก เรามีทีมนักพัฒนา ASP.NET สี่คนซึ่งรวมถึงฉันด้วย โครงการของเราเกือบทั้งหมด (> 98%) เป็นโครงการแบบคนเดียวที่ใช้เวลาดำเนินการประมาณ 1-4 สัปดาห์ เราไม่ได้ใช้การควบคุมแหล่งที่มาหรือรุ่น สิ่งเดียวที่เรามีคือโฟลเดอร์แชร์บนเซิร์ฟเวอร์ภายในที่มีแหล่งข้อมูลล่าสุด (== แหล่งที่มาของแอปพลิเคชั่นที่ใช้งานจริง) ของโครงการทั้งหมด ในโอกาสที่หายากที่เราจำเป็นต้องทำงานในโครงการเดียวกันที่มีมากกว่าหนึ่งคนเราใช้ ... นอกเหนือจากการเปรียบเทียบ นักพัฒนาหนึ่งหรือสองครั้งต่อวันถามพวกเขาว่าพวกเขามีรุ่นที่รวบรวมและจากนั้นพวกเขาประสานรหัสของพวกเขาโดยใช้การเปรียบเทียบ เมื่อมีคนเพียงสองคนกำลังทำงานในโครงการนี้ทำงานได้ "ค่อนข้างดี" แต่ทันทีที่นักพัฒนารายที่สามเข้าสู่กระบวนการก็จะกลายเป็นขยะที่ไม่สามารถจัดการได้ โดยเฉพาะอย่างยิ่งเมื่อทุกคนเริ่มทำการเปลี่ยนแปลงฐานข้อมูล ฉัน (และหนึ่งหรือสองของนักพัฒนาเพื่อนของฉัน) ได้บอกเจ้านายของฉันหลายครั้งแล้วว่าเราควรเริ่มใช้รูปแบบของแหล่งที่มาและการควบคุมเวอร์ชันเช่น Git, Mercurial หรือ TFS (หัวหน้าของเราเป็นคนที่มีใจรักของ Microsoft) น่าเสียดายที่เจ้านายของฉันไม่เห็นประโยชน์ของการเปลี่ยนไปใช้ระบบควบคุมแหล่งที่มาและเวอร์ชั่นเพราะในสายตาของเขาทุกอย่างทำงานได้ดีในตอนนี้และเขาไม่ต้องการลงทุนเวลาและเงินในการตั้งค่าระบบใหม่และทำให้แน่ใจว่าทุกคน รู้วิธีการใช้งาน แม้ว่าฉันจะอธิบายข้อดี (เช่นการทำงานร่วมกันที่ง่ายขึ้นแอปพลิเคชันรุ่นต่าง ๆ วิธีที่ปลอดภัยกว่าในการเปลี่ยนรหัส ... ) สำหรับเขาเขายังไม่คิดว่ามันเป็นสิ่งที่เราต้องการ ในบรรดานักพัฒนาทั้งสี่มีเพียงสองคนเท่านั้น (รวมถึงฉัน) ที่มีประสบการณ์กับการควบคุมแหล่งที่มา (Git) และประสบการณ์นั้นมีจำกัดมาก ฉันรู้วิธีโคลนที่เก็บ …

13 development-process  version-control  teamwork 

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

13 development-process  complexity  change 

ตามที่ฉันได้เขียนในคำถามอื่น ๆ ที่นี่โครงการที่ฉันกำลังดำเนินการอยู่ในขณะนี้ไม่มีกระบวนการซอฟต์แวร์ นั่นหมายความว่าไม่มีเอกสาร (รวมทั้งความต้องการคัดลอกยากหรือสเปค)ไม่มีการควบคุมแหล่ง , ไม่มีฐานข้อมูลข้อผิดพลาดข้อบกพร่องเป็น "คงที่" (หวังว่า) และรหัสใหม่จะถูกเพิ่มในเวลาเดียวกันและไม่มีการทดสอบอย่างเป็นทางการ - เราจะล้มเหลวการทดสอบโจเอลแย่มากมันไม่ตลกเลย เมื่อวานนี้ผู้จัดการของฉันขอให้ฉันเขียนเอกสารเกี่ยวกับวิธีเริ่มแก้ไขข้อบกพร่องเหล่านี้ โปรดทราบว่าฉันแค่ฝึกงานที่นี่เป็นเวลา 6 เดือน ฉันจะออกไปในช่วงวันขอบคุณพระเจ้าในเดือนพฤศจิกายนเพื่อกลับไปโรงเรียน อย่างไรก็ตามฉันคิดว่าฉันอาจทำให้โครงการนี้เคลื่อนไหวไปในทิศทางที่ถูกต้อง แต่ฉันไม่แน่ใจว่าจะเริ่มต้นอย่างไร ขณะนี้ฉันกำลังใช้CiteSeerและWikipediaเพื่อพยายามค้นหาเอกสารและอธิบายกระบวนการซอฟต์แวร์และนำไปใช้ แต่คำแนะนำประสบการณ์ส่วนตัวหรือลิงก์ไปยังบล็อกเอกสารบทความ wiki หรืออื่น ๆ จะได้รับการชื่นชมอย่างมาก

13 development-process  specifications 

ในขณะที่อ่านคำตอบสำหรับคำถามที่ชี้แจงเกี่ยวกับแกรมมาร์, Lexers และ Parsersคำตอบดังกล่าวระบุว่า: [... ] ไวยากรณ์ BNF มีกฎทั้งหมดที่คุณต้องการสำหรับการวิเคราะห์คำและการแยกวิเคราะห์ สิ่งนี้เกิดขึ้นกับฉันค่อนข้างแปลกเพราะจนถึงตอนนี้ฉันมักจะคิดเสมอว่า lexer นั้นไม่ได้ยึดหลักไวยากรณ์เลยในขณะที่ parser มีพื้นฐานมาจากหนึ่ง ฉันมาถึงข้อสรุปนี้หลังจากอ่านโพสต์บล็อกจำนวนมากเกี่ยวกับการเขียน lexers และไม่มีใครเคยใช้1 EBNF / BNF เป็นพื้นฐานสำหรับการออกแบบ หาก lexers รวมถึง parsers อิงตามไวยากรณ์ EBNF / BNF แล้วจะมีวิธีการสร้าง lexer โดยใช้วิธีนั้นอย่างไร นั่นคือฉันจะสร้าง lexer โดยใช้ไวยากรณ์ EBNF / BNF ที่กำหนดได้อย่างไร ฉันเคยเห็นโพสต์มากมายที่เกี่ยวข้องกับการเขียนโปรแกรมแยกวิเคราะห์โดยใช้ EBNF / BNF เป็นแนวทางหรือพิมพ์เขียว แต่ฉันเจอมาไม่ถึงตอนนี้ที่แสดงเทียบเท่ากับการออกแบบเล็ก ตัวอย่างเช่นใช้ไวยากรณ์ต่อไปนี้: input = digit| string …

13 design  design-patterns  development-process  grammar  lexer 

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

12 agile  development-process