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

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

16 version-control  git  development-process  merging  pull-requests 

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

16 development-process  iterative-development 

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

15 development-process 

ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ฉันเป็นผู้นำในการพัฒนา บริษัท ขนาดเล็กที่ทำงานร่วมกับ C # และ ASP.Net ทีมของเรามีขนาดเล็ก 2-3 คนไม่มีประสบการณ์มากในการพัฒนาและออกแบบ ฉันไม่มีโอกาสที่จะเรียนรู้จากนักพัฒนาอาวุโสมากขึ้นไม่มีใครในทีมของฉันที่จะแนะนำฉันและช่วยฉันเลือกวิธีที่ดีที่สุดเนื่องจากฉันดูแลโครงการส่วนใหญ่ด้วยตนเอง ฉันจะพัฒนาทักษะการพัฒนาซอฟต์แวร์ของฉันในขณะทำงานในโครงการจริงได้อย่างไรหากไม่มีนักพัฒนาที่มีประสบการณ์มากกว่านี้

15 web-development  self-improvement  development-process  experience  design 

พื้นหลังเล็กน้อยที่นี่ - เราเป็นทีมเล็ก ๆ (จาก 5) ของนักพัฒนา RAD ที่รับผิดชอบการพัฒนาซอฟต์แวร์ภายใน บริษัท ที่ไม่ใช่ซอฟต์แวร์ขนาดใหญ่ "ซอฟต์แวร์ภายใน" แตกต่างจากแอพพลิเคชันเดสก์ท็อป. NET ที่ใช้เซิร์ฟเวอร์ MSSQL เป็นแบ็กเอนด์ไปยังสคริปต์ Python ที่ทำงานบนพื้นหลังไปยังเอกสารและแม่แบบ MS Word - สวนสัตว์ของเทคโนโลยี ทีมงานทั้งหมดประกอบด้วยผู้รอบรู้ทุกคนสามารถรับข้อกำหนดจากผู้ใช้รหัสมันทดสอบและปรับใช้ในการผลิต เมื่อซอฟแวร์ในการผลิตมันถูกดูแลโดยทีมอื่น แต่มันมักจะง่ายสำหรับเราที่จะเข้าไปแทรกแซงหากมีอะไรผิดพลาด ทุกอย่างฟังดูดี แต่มีปัญหา - การเป็นทีม RAD ที่เราต้องปล่อยออกมาบ่อยครั้งและไม่มีวันที่เราจะไม่ปล่อยรุ่นใหม่ของแอปพลิเคชั่นหนึ่งหรือสอง (หรืออาจเป็นสคริปต์เอกสารเวิร์ดที่ได้รับการปรับปรุง แอพคอนโซล C ++ ฯลฯ ) ในการผลิต เราทำการทดสอบการพัฒนาและเกี่ยวข้องกับผู้ใช้ปลายทางโดยให้พวกเขาเรียกใช้ซอฟต์แวร์ในสภาพแวดล้อมของเอือด ... ... แต่ข้อบกพร่องกำลังคืบคลานเข้าสู่การผลิตอยู่ดี ผู้ใช้เข้าใจว่าข้อบกพร่องเหล่านี้และความไม่แน่นอนเป็นครั้งคราวคือราคาที่พวกเขาจ่ายเพื่อให้ได้สิ่งที่พวกเขาต้องการได้อย่างรวดเร็ว แต่ในขณะเดียวกันก็ทำให้เราคิด - บางทีเราอาจปรับปรุงการพัฒนาของเราหรือแนวทางปฏิบัติเพื่อปรับปรุงเสถียรภาพของ ซอฟต์แวร์และลดจำนวนข้อบกพร่องที่เราแนะนำเมื่อเพิ่มฟังก์ชันการทำงานใหม่ สิ่งที่ดี - …

15 development-process  release-management  rad 

ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา ตามกฎของ Pareto โปรแกรมเมอร์ใช้เวลาเพียง 20% ในการทำสิ่งที่มีประโยชน์จริงๆ ฉันใช้เวลา 80% ในการดีบักแก้ไขสิ่งเล็ก ๆ เพื่อให้ทุกอย่างทำงานได้ มีวิธีการแก้จุดบกพร่องใช้เวลาน้อยลงหรือไม่

15 productivity  self-improvement  development-process  debugging 

บริษัท ของเราจัดส่งผลิตภัณฑ์เดสก์ท็อปที่หลากหลายสำหรับ Windows และผู้ใช้ Linux จำนวนมากบ่นในฟอรัมที่เราควรจะเขียนเวอร์ชันผลิตภัณฑ์ของเราสำหรับ Linux เมื่อหลายปีก่อนและสาเหตุที่เราไม่ทำเช่นนั้นคือ เราเป็น บริษัท โลภ ผู้เชี่ยวชาญด้านเทคนิคของเราทุกคนมีคุณสมบัติต่ำกว่ามาตรฐาน ผลิตภัณฑ์โดยเฉลี่ยของเรานั้นคล้ายกับรหัส C ++ 3 ล้านบรรทัด การวิเคราะห์ของฉันและเพื่อนร่วมงานของฉันมีดังต่อไปนี้: การเขียนโค้ด C ++ ข้ามแพลตฟอร์มนั้นไม่ใช่เรื่องง่าย การเตรียมแพ็คเกจการกระจายจำนวนมากและการดูแลรักษาให้พร้อมสำหรับ Linux เวอร์ชันที่แพร่หลายทั้งหมดนั้นต้องใช้เวลา การคาดการณ์ของเราคือตลาดลีนุกซ์เป็นอะไรที่ 5-15% ของผู้ใช้ทั้งหมดและผู้ใช้เหล่านั้นจะไม่ต้องการจ่ายเงินสำหรับความพยายามของเรา เมื่อสิ่งนี้เกิดขึ้นการตอบสนองก็เป็นอีกครั้งที่เราโลภไร้เดียงสาที่โง่เขลาและเมื่อทุกอย่างถูกต้องทั้งหมดนี้เป็นเรื่องง่ายและไม่เจ็บปวด การประเมินของเรามีเหตุผลว่าการเขียนโค้ดข้ามแพลตฟอร์มและการบำรุงรักษาแพคเกจการกระจายจำนวนมากใช้ความพยายามมากมาย? เราจะหาบทวิเคราะห์ที่ง่ายและมีรายละเอียดได้อย่างไรจากเรื่องราวชีวิตจริงที่แสดงให้เห็นเหนือเงาแห่งความสงสัยซึ่งต้องใช้ความพยายามเพียงใด?

15 c++  development-process  cross-platform 

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

15 development-process 

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

15 development-process  agile  scrum 

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

15 web-development  project-management  agile  development-process  management 

ขณะนี้ทีมของฉันใช้กระบวนการแยก / ปรับใช้ที่ค่อนข้างง่ายซึ่งมีลักษณะดังนี้: ┌────────┐ ┌────┐ ┌──────┐ Environments: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ Builds: │ DEV │ │ QA │ │ PROD │ └────────┘ └────┘ └──────┘ ▲ ▲ ▲ │ │ │ ┌────────┐ ┌────┐ ┌──────┐ …

14 version-control  git  development-process  deployment  development-environment 

ยกตัวอย่างของแอพพลิเคชั่น Ruby on Rails แบบง่าย ๆ มันสร้างLoggerวัตถุในระหว่างกระบวนการโหลดแอปพลิเคชัน: # in environment.rb config.logger = Logger.new(<STDOUT | file | whatever>) # and in our application we use this object logger.warn "This process is taking too long to process. Optimization needed." คำถามของฉันคือทำไมเราไม่ใช้วิธีการเรียน (หรือวิธีการคงที่) สำหรับการเข้าสู่ระบบ? จะไม่Logger.warnขยายมากกว่าLogger.new.warn? หรืออย่างน้อยดูเหมือนว่าใช้งานง่ายกว่าLogger.warnLogger.new.warn แม้ว่าLogger.newจะเป็นวัตถุซิงเกิลตันมันมีข้อดีอะไรบ้าง?

14 development-process  logging 

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

14 development-process 

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

14 development-process  management 

เป็นการยากที่จะบอกสิ่งที่ถูกถามที่นี่ คำถามนี้คลุมเครือคลุมเครือไม่สมบูรณ์กว้างเกินไปหรือโวหารและไม่สามารถตอบได้อย่างสมเหตุสมผลในรูปแบบปัจจุบัน สำหรับความช่วยเหลือในการทำความเข้าใจคำถามนี้เพื่อที่จะสามารถเปิด, ไปที่ศูนย์ช่วยเหลือ ปิดให้บริการใน9 ปีที่ผ่านมา เมื่อเร็ว ๆ นี้ฉันเข้าร่วมบรรยายโดยGreg Wilson (หัวหน้านักวิทยาศาสตร์ของ Software Carpentry) จากนามธรรม: แนวคิดที่อ้างว่าเกี่ยวกับการพัฒนาซอฟต์แวร์ควรเป็นไปตามหลักฐานยังคงเป็นของต่างประเทศสำหรับนักพัฒนาซอฟต์แวร์ แต่ในที่สุดก็เริ่มมีการเปลี่ยนแปลง: นักวิชาการที่อ้างว่าเครื่องมือหรือแบบฝึกหัดเฉพาะใด ๆ ทำให้การพัฒนาซอฟต์แวร์เร็วขึ้นราคาถูกลง คาดว่าจะสำรองข้อมูลที่อ้างว่ามีการศึกษาเชิงประจักษ์ โดยรวมแล้วการบรรยายนั้นให้ข้อมูลมากและทำให้ฉันคิดอย่างลึกซึ้งเกี่ยวกับแนวทางการพัฒนาของฉัน โดยเฉพาะตอนนี้ฉันพบว่าตัวเองกำลังมองหาการอ้างอิงเพื่อสำรองข้อความจำนวนมาก ก่อนหน้านี้ฉันเคยแอบติดนิสัยของความจริงที่เสนอซ้ำ ๆ โดยอาจจะเป็นโน้ตทางจิตใจที่จะไปตรวจสอบในภายหลัง วางไว้โผงผางฉันถูกใจง่าย นี่คือตัวอย่างที่นำมาจากการบรรยาย: "หากรหัสมากกว่า 25% ต้องการการปรับโครงสร้างใหม่จะสามารถเขียนได้เร็วขึ้น" ฟังดูน่าเชื่อถือ แต่จริงหรือ? การศึกษาสำรองอยู่ที่ไหน จริงหรือไม่สำหรับทุกภาษา? และอื่น ๆ ตกลงเป็นไปได้ค่อนข้างมากที่จะนำสิ่งนี้ไปสู่สุดโต่งและไม่เชื่ออะไรโดยใครนอกจากคุณจะได้รับมาจากหลักการแรก ด้วยวิธีนี้คือความบ้าคลั่ง (หรืออาจเป็นคณิตศาสตร์ ;-)) แต่ถ้ามีใครบางคนเข้ามาหาคุณพร้อมกับแถลงการณ์ตามบรรทัดของ "เฮ้การทำสิ่งนี้ใน [เลือกภาษาของช่วงเวลา] เราจะสามารถเพิ่มประสิทธิภาพการทำงานโดย [เลือกหลาย 10]%" คุณมีแนวโน้มที่จะเพียงแค่ ยอมรับหรือคุณจะขอหลักฐานที่พิสูจน์แล้ว? ถ้าเป็นแบบหลัง (และฉันหวังว่าจะเป็น) …

14 self-improvement  development-process  computer-science