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

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

12 testing  development-process 

ฉันเป็นนักพัฒนาซอฟต์แวร์ที่ทำงานใน บริษัท ระบบฝังตัว เรามีผู้จัดการโครงการที่ดูแลกำหนดการโครงการโดยรวม (รวมถึงไฟฟ้าคุณภาพซอฟต์แวร์และการผลิต) ดังนั้นกำหนดการซอฟต์แวร์ของเขาจึงสั้นมาก เรายังมีผู้จัดการซอฟต์แวร์ซึ่งเป็นหัวหน้าของฉัน เขาทำให้ฉันเขียนและบำรุงรักษากำหนดการซอฟต์แวร์เอกสารการออกแบบ (การออกแบบระดับสูงและต่ำ) SRS การจัดการการเปลี่ยนแปลงแผนการตรวจสอบและรายงานการจัดการการเปิดตัวการทบทวนและหลักสูตรซอฟต์แวร์ เรามีวิศวกรทดสอบเพียงคนเดียวสำหรับทีมซอฟต์แวร์ทั้งหมด (สมาชิก 10 คน) และในเวลาใดก็ตามมีโครงการสองโครงการเกิดขึ้น ฉันใช้เวลา 80% ในการทำเอกสารเหล่านี้ เจ้านายของฉันมาจากพื้นฐานกระบวนการและเชื่อว่าสิ่งที่เราต้องการคือเอกสารที่ดีกว่าในการปรับปรุงซอฟต์แวร์: เขาคิดว่าการออกแบบเป็นสิ่งสำคัญยิ่งการเข้ารหัสคือ "เพียงแค่เขียนการออกแบบ" มันไม่ควรใช้เวลานานเกินไปและ "รหัสทั้งหมดควรจะเขียนก่อนที่ฮาร์ดแวร์จะพร้อม" ไม่เข้าใจความแตกต่างระหว่างตัวควบคุม Central & Distributed Version แม้ว่าเราจะบอกเขาว่ามันง่ายกว่าที่จะทำงานร่วมกับแบบจำลองการกระจาย ไม่เข้าใจรหัสและต้องการเข้าใจทุกข้อบกพร่องและแนวทางแก้ไขที่เสนอ การตรวจสอบความเชื่อควรทำโดยนักพัฒนาและการตรวจสอบโดยผู้ทดสอบ สิ่งที่เป็นอยู่การตรวจสอบของเราเพียงตรวจสอบว่าการใช้งานถูกต้อง (เราไม่ได้เขียนการทดสอบหน่วยมันไม่เคยพิจารณาในตาราง) และการตรวจสอบคือการทดสอบกล่องดำดังนั้นการทดสอบหน่วยจะหายไป ฉันสับสนจริงๆ ฉันต้องรับผิดชอบในการดูแลรักษาเอกสารเหล่านี้ทั้งหมดหรือไม่ มันทำให้ฉันรู้สึกว่าฉันกำลังทำ Software Management Management เป็นหลัก ฉันใช้ได้กับเอกสารทางเทคนิค แต่ฉันเชื่อว่านักพัฒนาไม่ควรทำตามกำหนดเวลา / การวางแผน ฉันไม่ชอบการสร้างเอกสารฉันต้องการแก้ปัญหาและเขียนรหัส จากประสบการณ์ของฉันการสร้างเอกสารการออกแบบจะช่วยเท่าที่ไม่เคยแก้ปัญหาของรหัสที่ดีขึ้นหรือเร็วขึ้น ฉันรู้สึกว่าเจ้านายไม่ได้ใส่ใจกับการสร้างผลิตภัณฑ์ที่ดีกว่า แต่เกี่ยวกับการเป็นผู้จัดการที่ดีในสายตาของผู้บริหาร …

12 design  project-management  development-process  documentation 

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

12 development-process  scrum  development-methodologies 

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

12 development-process  code-quality  quality 

ข้อความเหล่านี้ดูเหมือนว่าเกี่ยวข้อง แต่สมองของฉันเริ่มละลายพยายามคิดผ่าน: P นายจ้างของฉันเพิ่งเริ่มใช้การควบคุมแหล่งที่มาส่วนใหญ่เป็นเพราะก่อนที่พวกเขาจะจ้างนักพัฒนามากขึ้น "ที่เก็บ" คือฮาร์ดไดรฟ์ของ dev ที่โดดเดี่ยวซึ่งทำงานจากที่บ้านเป็นหลัก ทั้งหมดของรหัส .NET เขาต้องการเขียนได้รับการตรวจสอบในว่อนและมีเป็นจำนวนมากของการทำซ้ำ (อ่าน: คัดลอกวาง) ฟังก์ชั่น ตอนนี้ระบบ SCM ของเราได้รับการเชิดชูข้อมูลสำรอง ฉันต้องการดึงรหัสที่ซ้ำกันบางส่วนลงในห้องสมุดสาธารณะ ฉันปล่อยให้ repo ดั้งเดิมอยู่คนเดียวเพื่อที่เราจะได้ไม่ทำลายสิ่งใด - เราสามารถย้ายและ / หรือปรับโครงสร้างโค้ดที่มีอยู่เดิมและเมื่อจำเป็น ดังนั้นฉันจึงตั้งค่า repo สำหรับรหัสใหม่รวมถึงไลบรารี ปัญหาของฉันเกี่ยวกับการกำหนดเวอร์ชันไลบรารี่โดยไม่ทำให้เรายุ่งเหยิงในกระบวนการที่มากเกินไป: โดยยอมรับว่าเราต้องการแนวทางที่สอดคล้องกันมากขึ้นด้วย devs ทั้งหมดที่เขียนโค้ดที่คล้ายกันมากการจัดการและ devs อื่น ๆ เปิดเพื่อจัดระเบียบใหม่ ลงไปได้ด้วยดีถ้าการแก้ปัญหาเริ่มส่งผลกระทบต่อผลผลิต ทางออกที่ดีที่สุดในใจของฉันคือการสร้างห้องสมุดแยกจากกันโดยแต่ละโครงการขึ้นอยู่กับรุ่นที่เลือกและเข้ากันได้โดยเจตนา ด้วยวิธีนี้เรารู้ว่าลูกค้ารายใดมีไลบรารีรุ่นใดที่สามารถทำซ้ำข้อบกพร่องได้อย่างน่าเชื่อถือรักษาสาขาการปล่อยอิสระสำหรับผลิตภัณฑ์และไลบรารีและไม่ทำลายโครงการของกันและกันเมื่อเปลี่ยนรหัสที่ใช้ร่วมกัน สิ่งนี้ทำให้การอัปเดตห้องสมุดยุ่งยากโดยเฉพาะอย่างยิ่งสำหรับผู้ที่ทำงานจากที่บ้าน ฉันคาดว่าห้องสมุดจะเปลี่ยนแปลงอย่างรวดเร็วอย่างน้อยในขั้นต้นเมื่อเรา (ในที่สุด) ดึงบิตทั่วไปเข้าด้วยกัน มีความเป็นไปได้ค่อนข้างมากที่ฉันคิดอย่างถี่ถ้วนและเราก็สามารถสร้างทุกอย่างให้สอดคล้องกับความมุ่งมั่นล่าสุดของห้องสมุดได้ แต่อย่างน้อยฉันก็ควรเตรียมตัวให้พร้อมสำหรับวันที่เราตัดสินใจว่าส่วนประกอบบางอย่างต้องเป็นรุ่นที่เป็นอิสระและ กระจาย ความจริงที่ว่าบางไลบรารีจะต้องติดตั้งใน GAC ทำให้การกำหนดเวอร์ชันมีความสำคัญเป็นพิเศษ ดังนั้นคำถามของฉันคืออะไรฉันหายไปไหน …

12 development-process  version-control  release  versioning 

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

12 development-process  terminology 

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

12 development-process  product-design 

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

12 development-process  management  configuration 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา แอปคอนโซล (รายการโปรด), รูปแบบรวดเร็ว & เลอะเทอะ, MS Paint (สำหรับ GUI); อะไรที่ได้ผลดีที่สุดสำหรับแอปพลิเคชั่นมาตรฐาน ทำไม?

12 development-process  testing 

ฉันเป็นนักพัฒนาซอฟต์แวร์ในทีมเปรียวขนาดใหญ่พอสมควร (เรามีนักพัฒนาแปดคนทำการเปลี่ยนแปลงที่เก็บรหัสเดียว) ทุกสองสัปดาห์เราจะผลักดันซอฟต์แวร์เวอร์ชันใหม่ให้ผลิต นี่คือขั้นตอนการทำงานปัจจุบันของเรา: เมื่อเริ่มงานใหม่นักพัฒนาจะสร้าง "ฟีเจอร์บรานช์" จากสาขาการพัฒนาหลัก (เราใช้คอมไพล์ ) และทำงานนอกสาขาใหม่นี้ เมื่อนักพัฒนาซอฟต์แวร์ทำงานเสร็จแล้วพวกเขาจะรวมสาขาฟีเจอร์ของพวกเขากลับเข้าไปในสาขาการพัฒนา ผู้พัฒนาผสานสาขาการพัฒนาเข้ากับสาขา QA บิลด์จะถูกทริกเกอร์จากสาขา QA ผลลัพธ์ของโครงสร้างนี้ถูกปรับใช้ในสภาพแวดล้อม QA ของเราเพื่อให้ผู้ทดสอบเริ่มการทดสอบ เป็นเรื่องปกติที่ผู้ทดสอบของเราจะพบปัญหาเกี่ยวกับคุณสมบัติใหม่เหล่านี้ซึ่งได้รวมเข้ากับสาขา QA ซึ่งหมายความว่าในเวลาใดก็ตามสภาพแวดล้อม QA อาจมีคุณสมบัติใหม่หลายประการ - บางส่วนผ่านการทดสอบและปราศจากข้อบกพร่องและบางส่วนเสีย สิ่งนี้ทำให้การปล่อยทำได้ยากเพราะหายากที่ QA build อยู่ในสถานะพร้อมใช้งานการผลิต เพื่อบรรเทาปัญหานี้เราได้พยายามเริ่มต้น "การหยุด QA" ซึ่งหมายความว่านักพัฒนาไม่รวมสาขาการพัฒนาของเราเข้ากับสาขา QA สองสามวันก่อนการเปิดตัว การแก้ไขข้อบกพร่องของสภาพแวดล้อม QA นั้นเกิดขึ้นโดยตรงกับสาขา QA และรวมเข้ากับสาขาการพัฒนา ในทางทฤษฎีสิ่งนี้ทำให้คุณสมบัติใหม่แตกออกจาก QA ในขณะที่ยังช่วยให้เราสามารถแก้ไขปัญหาที่มีอยู่แล้วใน QA ในขณะที่แนวคิด "QA freeze" ประสบความสำเร็จเพียงบางส่วน แต่ก็ยากที่จะประสานงานและผู้คนมักสับสนว่าพวกเขาได้รับอนุญาตให้รวมกับ QA …

12 agile  version-control  development-process  branching  release-management 

เดิมทีมันเป็นหน้าที่ของนักพัฒนาในการเขียนการทดสอบ แต่ฉันสังเกตเห็นว่าในหลายกรณี / นักพัฒนา e-mature กรณีเหล่านั้นจะไม่ให้ความคุ้มครองถึง 80% ฉันมีคน QA ที่ทุ่มเทให้กับการเขียนการทดสอบทั้งหมดสำหรับโครงการที่กำหนดแทนที่จะเป็นนักพัฒนาได้อย่างไร มีข้อเสียใด ๆ หรือไม่?

12 development-process  tdd 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา พื้นหลังเล็กน้อย: ฉันมีโครงการโอเพ่นซอร์สขนาดเล็กที่ฉันได้เริ่มทำมาซึ่งเป็นกรอบพื้นฐานที่ให้วิธีการเชิงวัตถุในการสร้างโค้ด HTML (เนื่องจากฉันไม่ชอบ HTML จริงๆและฉันชอบ PHP) . มีแหล่งเผยแพร่และการดาวน์โหลดไม่กี่ครั้ง แต่โดยหลักแล้วโครงการนี้เหมาะสำหรับฉันส่วน Open Source เป็นเพียงผลประโยชน์ด้านเดียวเท่านั้น โครงการดั้งเดิมที่ทำให้ฉันสามารถพัฒนาในโครงการนี้ส่วนใหญ่ได้เข้าสู่โหมดไฮเบอร์เนตในขณะนั้นซึ่งหมายความว่าการพัฒนาทั้งหมดที่ฉันได้รับในขณะนี้เป็นเวลาส่วนตัวเท่านั้น น่าเสียดายที่ฉันกำลังศึกษาต่อระดับปริญญาตรีของฉันกำลังเรียนเพื่อขอใบรับรองและฉันมีลูกสามเดือนที่บ้าน ในระยะสั้นโดยเวลาที่ฉันได้รับ "เวลาฉัน" ฉันไม่ค่อยรู้สึกเหมือนทำงาน แต่มักจะรู้สึกเหมือนเพิ่งทำใจให้สบาย ดังนั้นหากมีคนอื่นที่อยู่ที่นั่นรู้สึกว่าพวกเขาอยู่ในตำแหน่งที่คล้ายกันคุณใช้กลยุทธ์อะไรในการทำให้ตัวเองมีแรงบันดาลใจในการทำงานในโครงการ อย่างน้อยฉันก็อยากจะทำงานกับเรื่องนี้จนกว่าฉันจะได้รับข้อมูลจำเพาะ 100% แต่ฉันไม่ได้แหล่งข้อมูลที่มุ่งมั่นในเดือน ใครบ้างที่สามารถช่วยเหลือได้

12 development-process  open-source 

ความเป็นมา:ฉันเพิ่งรับช่วงโปรเจ็กต์ชุดหนึ่งที่ บริษัท ของฉันและฉันพยายามแยกแยะปัญหาพื้นฐานบางอย่างเกี่ยวกับวิธีการจัดการ กล่าวคือนักพัฒนาก่อนหน้านี้ (ซึ่งไม่ได้อยู่กับ บริษัท อีกต่อไป) ไม่ได้ใช้การควบคุมแหล่งที่มาในรูปแบบใด ๆ ทำเอกสารเพียงเล็กน้อยและไม่มีกระบวนการพัฒนาที่ดีเกิดขึ้นจริง ดังนั้นตอนนี้ฉันมีสามเซิร์ฟเวอร์ที่มีมูลค่าโครงการ (การพัฒนาการจัดเตรียมการผลิต) ซึ่งประกอบด้วยเว็บไซต์และแอพพลิเคชั่นและเครื่องมือส่วนใหญ่ที่สร้างขึ้นสำหรับแอปพลิเคชันบุคคลที่สามและ APIs ที่เราใช้ ความคิดแรกของฉันคือนำสิ่งทั้งหมดนี้เข้าสู่ Git ก่อนที่จะทำการเปลี่ยนแปลงและแก้ไข แต่ฉันมีช่วงเวลาที่ยากลำบากในการหาวิธีที่ดีที่สุดที่จะทำ มีการพัฒนาก่อนหน้านี้จำนวนมากบนเซิร์ฟเวอร์ที่ใช้งานจริงซึ่งสร้างการแบ่งระหว่างรหัสฐานของเซิร์ฟเวอร์แต่ละเครื่อง ไม่ชัดเจนในทันทีที่ความแตกต่างอยู่ - ฉันเห็นการแก้ไขข้อบกพร่องในด้านการผลิตที่ไม่ได้ดำเนินการเกี่ยวกับการพัฒนา / การจัดเตรียมรวมถึงคุณสมบัติใหม่ในการพัฒนาที่ไม่ได้ย้ายไปสู่การจัดเตรียม / การผลิต . คำถาม:วิธีที่ดีที่สุดสำหรับฉันในการจัดระเบียบและย้ายสิ่งเหล่านี้ไปยัง Git คืออะไร? ฉันจะจัดโครงสร้าง repos / สาขาของฉันเพื่อรองรับความแตกต่างในรหัสได้อย่างไร ฉันได้พิจารณาการพัฒนาอย่างต่อเนื่องจากการโคลนรหัสเซิร์ฟเวอร์การผลิตและการรักษาฐานการพัฒนา / การแสดงละครเป็นการอ้างอิงทางประวัติศาสตร์ นี่อาจเป็นจุดเริ่มต้นโดยพิจารณาว่าฉันไม่รู้เกี่ยวกับโค้ด dev / การ staging หรือไม่ ฉันสามารถสร้าง repos ของเซิร์ฟเวอร์ที่ใช้งานจริงสำหรับแต่ละเว็บไซต์เครื่องมือชุดสคริปต์ ฯลฯ สร้างสาขาสำหรับรหัส dev …

11 web-development  git  development-process  github  project-structure 

ใน บริษัท ของฉันเป็นเรื่องปกติที่จะไม่ทำบิลด์ขั้นกลางใด ๆ เพื่อตรวจสอบว่าแต่ละฟีเจอร์ / สาขาแก้ไขข้อผิดพลาดรวมอยู่ใน dev มีบิลด์รายวันเท่านั้นซึ่งจะทำให้การทดสอบล้มเหลวและสร้างข้อผิดพลาดได้เสมอ ฉันได้รับการบอกว่ามันไม่สมเหตุสมผลที่จะสร้างสำหรับการผสานแต่ละครั้งสำหรับนักพัฒนามากกว่า 1,000 คน ดังนั้นฉันจึงค้นหาวิธีการจัดระเบียบ CI ใน บริษัท ที่มีนักพัฒนาจำนวนมากหรือมากกว่านั้น (Microsoft, Facebook) และไม่พบอะไรเลย บางทีคนวงในสามารถบอกฉันได้?

11 development-process  continuous-integration  large-scale-project 

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

11 development-process  estimation