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

สำหรับคำถามเกี่ยวกับกระบวนการพัฒนาซอฟต์แวร์

1
แบ่งการพัฒนาสแต็ค - ตามแนวทแยง?
เรามีโครงการใหม่ที่เกิดขึ้นและในขณะที่นักพัฒนาได้ถูกแบ่งออกเป็นสองทีมทีม A และทีม B โครงการนี้มี 2 ส่วนซึ่งจำเป็นต้องมีการพัฒนาตลอดทั้งกองพัฒนา ตัวอย่างสแต็กของเราที่แสดงด้านล่างง่ายมาก: แต่ละส่วนของโครงการต้องการการพัฒนาข้ามสแต็คทั้งหมดดังนั้นโดยทั่วไปฉันคาดหวังว่าแนวทางการพัฒนาสแต็คเต็มรูปแบบซึ่งเป็นวิธีที่เราแยกย่อยงานของเราภายในทีม B การออกแบบและการโต้ตอบระหว่างส่วนต่าง ๆ อย่างไรก็ตามเมื่อเร็ว ๆ นี้ฉันได้เรียนรู้ว่าทีม A ต้องการรับผิดชอบบางส่วนของสแต็กและพวกเขากำลังเสนอการแบ่งแยกระหว่างสองทีมที่ Data Abstraction Layer (และวางเนื้อหาใน Data layer) ถูกจัดการโดย ตัวเองโดยไม่มีการพัฒนาจากทีม B. การแบ่งจะดูคล้ายกับ: สำหรับฉันแล้วมันรู้สึกไม่เป็นธรรมชาติมาก แต่ละทีมมีวัตถุประสงค์และระยะเวลาที่แตกต่างกันในการบรรลุเป้าหมายเหล่านี้ แต่ทีม B จะต้องพึ่งพาทีม A ในการใช้คุณสมบัติ วิธีแก้ปัญหาที่เสนอคืออินเตอร์เฟสทั่วไปถูกกำหนดไว้ล่วงหน้า (อาจมีระยะเวลา 2 ปีในโครงการเพื่อให้สามารถใช้งานได้จำนวนมาก) ทีม A จะพัฒนาบิตที่ต้องการให้กับอินเทอร์เฟซเหล่านี้ แต่เนิ่นๆแม้ว่าจะมีชุดเป้าหมายเป็นของตัวเองในขณะที่ทีม B จะเรียกสายทั้งหมดในระยะสั้นเพื่อให้พวกเขาสามารถดำเนินการต่อไปได้ ฉันมีความกังวลเกี่ยวกับวิธีการนี้เกี่ยวกับ: อินเทอร์เฟซอาจเปลี่ยนแปลงและทีม A อาจไม่มีแบนด์วิดท์หรือเวลาเพื่อรองรับความต้องการที่เปลี่ยนแปลง ข้อบกพร่องในรหัสของทีม A …

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

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

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

5
ควรสร้างสาขาการพัฒนาเมื่อใด
เรากำลังย้ายทีมงานโครงการของเราจากการใช้สาขาหลัก / ลำต้นเดียวไปยังสาขาการพัฒนา / การทำงานหลายสาขาที่ควรรวมเป็นหลักอย่างสม่ำเสมอ เรากำลังพิจารณากระบวนการใหม่ของเราในบทความนี้และคู่มือการแบ่งสาขาของ TFS (เรากำลังใช้ TFS และ Visual Studio 2010) ขณะนี้มีระหว่าง 1 ถึง 5 คนที่ทำงานในโครงการในเวลาใดก็ได้ หลักต้องมีความเสถียรตลอดเวลาเพราะเราต้องการให้ตัวเลือกที่จะปล่อยเมื่อใดก็ตามที่เราต้องการ เรายังไม่มี sprints คงที่ - อย่างน้อยยังไม่ได้ - และในขณะนี้ปล่อยทุก 1-2 สัปดาห์ ณ จุดนี้ในเวลาที่แต่ละคนกำลังแก้ไขข้อบกพร่องในใบสมัคร ในอีกไม่กี่สัปดาห์เราจะเริ่มพัฒนาส่วนประกอบใหม่ขนาดใหญ่สำหรับแอพ ผสานจุดหนึ่งที่เรากำลังมองหาคือเมื่อสาขาการพัฒนาควรจะสร้าง เราจะใช้เรื่องราวของผู้ใช้หลายคนพร้อมกันขึ้นอยู่กับชุดทักษะของนักพัฒนา เราคิดเกี่ยวกับการสร้างสาขาสำหรับนักพัฒนาแต่ละคน แต่มันก็ไม่สมเหตุสมผลเพราะจะต้องมีการร่วมมือกันในการทำงาน เราไม่สามารถผ่านสาขาการพัฒนาเดียวเพราะเราต้องการที่จะผสานกับหลักในขณะที่งานอื่นเสร็จสมบูรณ์ ใครบ้างมีคำแนะนำเกี่ยวกับเรื่องนี้?

8
คอขวดที่ใหญ่ที่สุดคืออะไรเมื่อพัฒนาโครงการขนาดใหญ่ [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา สมมติว่า บริษัท ของฉันคือการพัฒนาแบบจำลองของ MS Word (เช่นเป็นตัวอย่าง) สิ่งที่จะเป็นคอขวดในกระบวนการพัฒนาสมมติว่ามีเงินสดไม่ จำกัด และองค์กรเช่น Microsoft กล่าวอีกนัยหนึ่งว่าอะไรคืออุปสรรคที่พบบ่อยที่สุดจากการพัฒนาซอฟต์แวร์ดังกล่าวอย่างรวดเร็ว? สมมติว่าข้อกำหนดทั้งหมดอยู่ในสถานที่และองค์กรทำงานอย่างสมบูรณ์แบบดังนั้นเราจึงมุ่งเน้นไปที่การพัฒนาซอฟต์แวร์จนกว่าผลิตภัณฑ์จะพร้อมจัดส่ง ทางเลือกบางอย่างอาจเป็น: - การเขียนโค้ด - การทดสอบการเขียน - การทดสอบผลิตภัณฑ์สุดท้าย - การเขียนโค้ดซ้ำเนื่องจากการออกแบบที่ไม่ดีตั้งแต่แรก - การออกแบบรหัส - การตรวจสอบโค้ดที่ทำโดยนักพัฒนาที่มีประสบการณ์ - การออกแบบ GUI - การออกแบบ GUI / ผลตอบรับผู้ใช้เบต้า - การประมวลผลความคิดเห็นจากผู้ใช้ - รอผลตอบรับจากผู้ใช้อัลฟ่า / เบต้า กรุณาใช้การอ้างอิงในคำตอบของคุณหรือระบุประสบการณ์ของคุณในเรื่อง

3
แนะนำภาษาการเขียนโปรแกรม JVM ใหม่ในสภาพแวดล้อมขององค์กรที่จัดตั้งขึ้น
ลองนึกภาพว่าที่ทำงานปัจจุบันของคุณคือร้านจาวา มีความรู้มากมายเกี่ยวกับภาษาจาวาและมีกระบวนการสร้างและปรับใช้ที่ครอบคลุมเพื่อจัดการทุกอย่างอย่างราบรื่นและคล่องตัว อยู่มาวันหนึ่งโครงการก็มาพร้อมกับเสียงกรีดร้องออกมาว่าทับทิม เฉพาะนักพัฒนาอาวุโสเท่านั้นที่มีเบาะแสเกี่ยวกับ Ruby แต่มีความคิดทั่วไปที่ว่า JRuby นั้นมีอยู่สำหรับ JVM ดังนั้นโครงสร้างพื้นฐานที่มีอยู่จึงยังคงสามารถใช้และสนับสนุนได้ นอกจากนี้ JRuby ยังสามารถแสดงให้เห็นถึงวิธีการที่ดีกว่าในการนำแอปพลิเคชั่นปัจจุบันไปใช้กับรหัสที่น้อยลงดังนั้นนี่อาจเป็นตัวแทนของการย้ายข้อมูลอย่างต่อเนื่อง โปรดจำไว้ว่า JRuby เป็นเพียงตัวอย่างมันอาจเป็น Clojure หรือ Groovy หรืออะไรก็ตามที่วิ่งบน JVM คำถามคือคุณจะแนะนำการเปลี่ยนแปลงแบบนี้อย่างไร - ถ้าใช่?

4
วิธีจัดลำดับความสำคัญของงานเมื่อคุณมีโครงการการเขียนโปรแกรมหลายโครงการทำงานแบบขนาน?
สมมติว่าคุณมีลูกค้า 5 รายคุณพัฒนาโครงการ 2 หรือ 3 โครงการที่แตกต่างกันสำหรับแต่ละโครงการ แต่ละโครงการมีภารกิจX i แต่ละโครงการใช้เวลา 2 ถึง 10 คนต่อสัปดาห์ เนื่องจากมีทรัพยากรน้อยจึงต้องการลดค่าใช้จ่ายในการจัดการให้น้อยที่สุด คำถามสองข้อในสถานการณ์นี้: เครื่องมืออะไรที่คุณจะใช้เพื่อจัดลำดับความสำคัญของงานและติดตามความสำเร็จของพวกเขาในขณะที่มีแนวโน้มที่จะลดค่าใช้จ่าย? เกณฑ์ใดที่คุณจะนำมาพิจารณาในการพิจารณาว่าจะมอบหมายงานใดให้กับทรัพยากรที่มีอยู่ถัดไปเนื่องจากวัตถุประสงค์หลักคือการเพิ่มปริมาณงาน (โครงการเพิ่มเติมเสร็จแล้วต่อหน่วยเวลาวัตถุประสงค์นี้ขัดแย้งกับการเริ่มโครงการหนึ่งและทำมันให้เสร็จ ต่อไป)? ยินดีต้อนรับความคิดเทคนิคการจัดการอัลกอริทึม

4
"นามธรรมก่อนวัยอันควร" คืออะไร?
ฉันได้ยินวลีที่ถูกโยนและฉันมีข้อโต้แย้งที่ฟังดูบ้าอย่างสมบูรณ์ (ขออภัยถ้าฉันกำลังทำฟางอยู่ที่นี่ไม่ใช่ความตั้งใจของฉัน) โดยทั่วไปจะมีบางอย่างตาม: คุณไม่ต้องการสร้างสิ่งที่เป็นนามธรรมก่อนที่คุณจะรู้ว่ากรณีทั่วไปคืออะไรมิฉะนั้น (1) คุณอาจวางสิ่งต่าง ๆ ในสิ่งที่เป็นนามธรรมของคุณหรือ (2) ไม่สนใจสิ่งที่มีความสำคัญ (1) สำหรับฉันนี่ดูเหมือนว่าโปรแกรมเมอร์ไม่ได้ใช้งานได้จริงพวกเขาได้ตั้งสมมติฐานว่าสิ่งต่าง ๆ จะมีอยู่ในโปรแกรมสุดท้ายที่ไม่ได้ทำงานดังนั้นพวกเขาจึงทำงานร่วมกับสิ่งที่เป็นนามธรรมในระดับต่ำปัญหาไม่ใช่ สิ่งที่เป็นนามธรรมก่อนวัยอันควร (2) การทิ้งสิ่งที่มีความสำคัญเป็นสิ่งหนึ่งอาจเป็นไปได้อย่างสิ้นเชิงที่บางสิ่งจะถูกตัดออกจากข้อมูลจำเพาะที่ในภายหลังกลายเป็นเรื่องสำคัญทางออกสำหรับสิ่งนี้ไม่ได้เกิดขึ้นกับการตัดสินใจของคุณและทรัพยากรเสียเปล่า เดาผิดก็เพื่อให้ได้ข้อมูลเพิ่มเติมจากลูกค้า เราควรทำงานจากนามธรรมลงไปถึงข้อตกลงเพราะนี่เป็นวิธีที่จริงจังที่สุดในการทำสิ่งต่าง ๆ และไม่ใช่วิธีอื่น ๆ ถ้าเราไม่ทำเช่นนั้นเราก็เสี่ยงต่อการเข้าใจผิดของลูกค้าและการสร้างสิ่งต่าง ๆ ที่จำเป็นต้องเปลี่ยน แต่ถ้าเราสร้างเพียงนามธรรมที่ลูกค้าได้กำหนดไว้ในภาษาของพวกเขาเองเราก็ไม่เคยตกอยู่ในความเสี่ยงนี้ ภาพหนึ่งในที่มืดโดยมีการสรุปบางอย่าง) ใช่เป็นไปได้ที่ลูกค้าจะเปลี่ยนใจเกี่ยวกับรายละเอียด แต่สิ่งที่พวกเขาเคยใช้ในการสื่อสารสิ่งที่พวกเขาต้องการมักจะยังคงใช้ได้ ต่อไปนี้เป็นตัวอย่างสมมติว่าลูกค้าต้องการให้คุณสร้างหุ่นยนต์ที่บรรจุถุง: public abstract class BaggingRobot() { private Collection<Item> items; public abstract void bag(Item item); } เรากำลังสร้างบางสิ่งจากนามธรรมที่ลูกค้าใช้โดยไม่ต้องลงรายละเอียดเพิ่มเติมกับสิ่งที่เราไม่รู้ นี่คือความยืดหยุ่นอย่างยิ่งฉันเห็นสิ่งนี้ถูกเรียกว่า "นามธรรมก่อนวัยอันควร" เมื่อในความเป็นจริงมันจะเร็วกว่าที่จะคิดว่าวิธีการบรรจุถุงถูกนำไปใช้อย่างไรพูดหลังจากพูดคุยกับลูกค้าที่พวกเขาต้องการ . เพื่ออัปเดตชั้นเรียนของฉันทั้งหมดที่ฉันต้องทำคือเปลี่ยนลายเซ็น …

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

1
การพัฒนาโดยใช้“ รถไฟ” คืออะไร?
ฉันเจอคำศัพท์ใหม่ในวิธีการพัฒนาและฉันไม่สามารถหาคำจำกัดความได้ โดยเฉพาะเรียกว่า "การพัฒนาด้วยรถไฟ" นี่คือตัวอย่างของที่ฉันได้เห็นคำนี้ สัปดาห์ก่อนหน้านี้ฉันขอให้ผู้นำด้านวิศวกรรมและผู้จัดการปล่อยรุ่น Firefox สำหรับ Windows Metro ออกจากรถไฟ (Johnathan Nightingale) https://blog.mozilla.org/futurereleases/2014/03/14/metro/ จากเว็บไซต์อาชีพของ Mozilla: ประสบการณ์ทำงานกับทั้งวิธีการพัฒนาที่คล่องตัวและทีมพัฒนา / ฝึกอบรมโดยใช้รถไฟ ฉันเคยได้ยินเรื่อง "รถไฟ" มาก่อนและไม่ใช่แค่ในบริบทของ Mozilla แต่ฉันไม่สามารถหาข้อมูลที่ดีเกี่ยวกับมันได้ในเน็ต เมื่อฉันค้นหา "การพัฒนาซอฟต์แวร์โดยใช้รถไฟ" ฉันพบข้อมูลน้อยมากในผลการค้นหา สิ่งที่ใกล้เคียงที่สุดที่ฉันสามารถขุดได้ซึ่งแยกรถไฟออกจากเกวียนก็คือ "รถไฟ" กำลังจะทำการเผยแพร่ในช่วงเวลาปกติตามตาราง แต่ก็ดูเหมือนว่า "รถไฟ" เป็นระบบ QA ที่เป็นรูปธรรม ดังนั้น "การพัฒนาโดยใช้รถไฟ" คืออะไร?

5
ซอฟต์แวร์มีลักษณะพิเศษใดบ้างวงจรชีวิตของการโจมตี / เครื่องมือเกี่ยวกับช่องโหว่ของซอฟต์แวร์
ที่มหาวิทยาลัยในท้องถิ่นของฉันมีสโมสรคอมพิวเตอร์ขนาดเล็กสำหรับนักเรียนประมาณ 20 คน สโมสรมีทีมเล็ก ๆ หลายแห่งที่มุ่งเน้นเฉพาะด้านเช่นการพัฒนาอุปกรณ์เคลื่อนที่หุ่นยนต์การพัฒนาเกมและการแฮ็ค / การรักษาความปลอดภัย ฉันแนะนำแนวคิดการพัฒนาแบบเปรียวเบื้องต้นให้กับทีมสองกลุ่มเช่นเรื่องราวของผู้ใช้การประเมินความซับซ้อนของงานและการรวมอย่างต่อเนื่องสำหรับการควบคุมเวอร์ชันและการสร้าง / ทดสอบอัตโนมัติ ฉันคุ้นเคยกับวงจรชีวิตการพัฒนาขั้นพื้นฐานบางอย่างเช่น Waterfall, Spiral, RUP, เปรียว ฯลฯ แต่ฉันสงสัยว่ามีสิ่งใดที่เป็นวงจรการพัฒนาซอฟต์แวร์สำหรับการแฮ็ค / การเจาะระบบรักษาความปลอดภัย แน่นอนแฮกเกอร์กำลังเขียนรหัสคอมพิวเตอร์ แต่วงจรชีวิตของรหัสนั้นคืออะไร ฉันไม่คิดว่าพวกเขาจะกังวลเกี่ยวกับการบำรุงรักษามากเกินไปเมื่อพบการละเมิดและแก้ไขแล้วรหัสที่ใช้ประโยชน์จากการละเมิดนั้นไม่ได้ผล ฉันคิดว่าวงจรชีวิตจะเป็นเช่น: ค้นหาช่องว่างในความปลอดภัย ใช้ประโยชน์จากช่องว่างในการรักษาความปลอดภัย จัดหา payload ใช้ประโยชน์จากส่วนของข้อมูล มีความแตกต่างอะไรบ้าง (ถ้ามี) สำหรับวงจรการพัฒนาของซอฟต์แวร์เมื่อจุดประสงค์ของผลิตภัณฑ์คือการละเมิดความปลอดภัย?

3
ความเห็น XML เป็นเอกสารที่จำเป็นหรือไม่
ฉันเคยเป็นแฟนที่ต้องการแสดงความคิดเห็น XML สำหรับเอกสาร ฉันเปลี่ยนใจเนื่องจากเหตุผลหลักสองข้อ: เช่นเดียวกับรหัสที่ดีวิธีการควรอธิบายด้วยตนเอง ในทางปฏิบัติความคิดเห็น XML ส่วนใหญ่เป็นเสียงที่ไร้ประโยชน์ซึ่งไม่มีค่าเพิ่มเติม หลายครั้งที่เราใช้ GhostDoc เพื่อสร้างความคิดเห็นทั่วไปและนี่คือสิ่งที่ฉันหมายถึงด้วยเสียงไร้ประโยชน์: /// <summary> /// Gets or sets the unit of measure. /// </summary> /// <value> /// The unit of measure. /// </value> public string UnitOfMeasure { get; set; } สำหรับฉันนั่นชัดเจน ต้องบอกว่าถ้ามีคำแนะนำพิเศษที่จะรวมแล้วเราควรใช้ความเห็น XML อย่างแน่นอน ฉันชอบข้อความที่ตัดตอนมาจากบทความนี้ : บางครั้งคุณจะต้องเขียนความคิดเห็น แต่ควรเป็นข้อยกเว้นไม่ใช่กฎ ความคิดเห็นควรใช้เมื่อแสดงสิ่งที่ไม่สามารถแสดงในรหัสได้ หากคุณต้องการเขียนโค้ดที่หรูหราให้พยายามกำจัดความคิดเห็นและเขียนรหัสเอกสารเอง ฉันผิดที่คิดว่าเราควรใช้ความคิดเห็น …

5
การผลิตกับการพัฒนาซอฟต์แวร์ [ปิด]
ตามที่เป็นอยู่ในปัจจุบันคำถามนี้ไม่เหมาะสำหรับรูปแบบคำถาม & คำตอบของเรา เราคาดหวังว่าคำตอบจะได้รับการสนับสนุนจากข้อเท็จจริงการอ้างอิงหรือความเชี่ยวชาญ แต่คำถามนี้อาจเรียกร้องให้มีการอภิปรายโต้แย้งโต้แย้งหรือการอภิปรายเพิ่มเติม หากคุณรู้สึกว่าคำถามนี้สามารถปรับปรุงและเปิดใหม่ได้โปรดไปที่ศูนย์ช่วยเหลือเพื่อขอคำแนะนำ ปิดให้บริการใน7 ปีที่ผ่านมา มีการกล่าวบ่อยครั้งว่าอุตสาหกรรมซอฟต์แวร์ยังไม่บรรลุนิติภาวะเมื่อเทียบกับอุตสาหกรรมการผลิต โดยเฉพาะอย่างยิ่งเกี่ยวกับการขับเคลื่อนกระบวนการ คำถาม : เราในฐานะนักพัฒนาสามารถเรียนรู้จากกระบวนการของอุตสาหกรรมการผลิตได้หรือไม่? การใช้กระบวนการของพวกเขาสามารถเพิ่มอัตราความสำเร็จของการพัฒนาซอฟต์แวร์ได้หรือไม่? สิ่งที่ฉันต้องทำ : ในการผลิตการสร้างผลิตภัณฑ์เป็นกระบวนการที่ขับเคลื่อนอย่างหนัก คุณอาจมีโรงงานที่แต่ละคนมีงานเฉพาะที่พวกเขาติดตาม คนงาน (หรือหุ่นยนต์) อาจขันสกรูได้ทั้งวัน จากนั้นงานต่อไปในกระบวนการจะดำเนินการโดยผู้เชี่ยวชาญคนต่อไป คนงาน (และหุ่นยนต์) ไม่ได้ขัดขวางกระบวนการหรือสร้างบางสิ่งบางอย่าง "ทันที" ชิ้นส่วนปั่นผ่านกระบวนการและผลผลิตเป็นผลิตภัณฑ์สำเร็จรูป มันใช้งานได้ดีและ บริษัท ต่างๆสามารถบรรลุข้อบกพร่อง 99.99966% ของผลิตภัณฑ์ฟรี บริษัท ต่างๆขาดประสิทธิภาพในการผลิตเหล็กเมื่อเวลาผ่านไป นี่เป็นสิ่งที่น่าประทับใจและอาจเป็นสัญญาณบ่งบอกถึงอุตสาหกรรมที่เติบโตเต็มที่ ในการผลิตกระบวนการที่กำหนดอย่างแท้จริงสามารถสร้างผลิตภัณฑ์สำเร็จรูป ฉันไม่คิดว่าเป็นกรณีของซอฟต์แวร์ เราอาจมีกระบวนการสำหรับการควบคุมแหล่งที่มาการตรวจสอบรหัสการตรวจสอบแผ่นงานการรวบรวมความต้องการ SDLC เป็นต้น แต่การดำเนินการกระบวนการเหล่านั้นไม่ได้อยู่ในตัวของมันเองและสร้างผลิตภัณฑ์ที่เสร็จสมบูรณ์แล้ว กระบวนการเหล่านี้อาจเป็นประโยชน์ แต่ตั้งฉากกับการสร้างจริง สมมติว่า บริษัท ของคุณมีสัญญาจ้างเพื่อสร้างซอฟต์แวร์ที่จะค้นหารูปภาพนับล้านภาพเพื่อค้นหาใบหน้าของอาชญากร แม้จะมีสภาพแวดล้อมที่ขับเคลื่อนด้วยกระบวนการที่หนักหน่วงผู้พัฒนาจะต้องมีส่วนร่วมในการสร้างสรรค์สิ่งต่าง ๆ "ในทันที" การทำสิ่งต่าง …

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.