คำถามติดแท็ก productivity

ผลผลิตเป็นตัวชี้วัดผลผลิตจากกระบวนการผลิตต่อหน่วยของการป้อนข้อมูล

7
จะให้โครงการย่อยใหม่แยกต่างหากจากนักพัฒนาที่มีประสบการณ์ช่วยให้มือใหม่เพิ่มขึ้นเร็วขึ้นหรือไม่
เรามีนักพัฒนา 7 คนในทีมและต้องเพิ่มความเร็วในการพัฒนาเป็นสองเท่าในช่วงเวลาสั้น ๆ (ประมาณหนึ่งเดือน) ฉันรู้ว่ามีกฎสามัญสำนึกที่ว่า "หากคุณจ้างนักพัฒนามากขึ้นคุณจะสูญเสียประสิทธิภาพในช่วงสองสามเดือนแรก" โครงการดังกล่าวเป็นบริการเว็บอีคอมเมิร์ซและมีโค้ดประมาณ 270K บรรทัด ความคิดของฉันในตอนนี้คือการแบ่งโครงการในโครงการย่อยอิสระสองโครงการมากขึ้นหรือน้อยลงและปล่อยให้ทีมใหม่ทำงานในโครงการย่อยขนาดเล็กสองโครงการในขณะที่ทีมปัจจุบันทำงานในโครงการหลัก กล่าวคือทีมใหม่จะทำงานในการชำระเงินซึ่งในที่สุดจะกลายเป็นบริการเว็บอิสระเพื่อลดข้อต่อ ด้วยวิธีนี้ทีมใหม่ทำงานในโครงการที่มีโค้ดเพียง 100K บรรทัด คำถามของฉันคือ: วิธีการนี้จะช่วยให้นักพัฒนามือใหม่สามารถปรับตัวเข้ากับโครงการใหม่ได้ง่ายหรือไม่? มีวิธีอื่นในการขยายทีมพัฒนาอย่างรวดเร็วโดยไม่ต้องรอสองเดือนจนกว่ามือใหม่จะเริ่มผลิตซอฟต์แวร์มากขึ้น ======= UPDATE องค์กรนี้ล้มเหลวอย่างสมบูรณ์ แต่ไม่ใช่เหตุผลที่คุณพูดถึง ก่อนอื่นฉันเข้าใจผิดเกี่ยวกับขนาดและความสามารถของทีมใหม่ ฉันควรประเมินตนเอง ประการที่สองการจ้างงานกลายเป็นงานหนักที่ไซต์นั้น ที่ตั้งของสำนักงานใหญ่การจ้างงานนั้นง่ายกว่ามาก แต่ในเมืองของทีมที่สองดูเหมือนจะมีนักพัฒนาไม่เพียงพอที่มีคุณสมบัติที่ต้องการ ดังนั้นแทนที่จะคาดการณ์ 1.5 เดือนงานขยายไปถึงประมาณ 4.5 เดือนและถูกยกเลิกในช่วงกลางของมันโดยผู้บริหารระดับสูง ข้อผิดพลาดอีกอย่างที่ฉันทำ (และถูกเตือนเกี่ยวกับเรื่องนี้โดย Alex D) คือฉันพยายามขายการปรับโครงสร้างให้ผู้บริหารระดับสูง คุณไม่เคยขาย refactoring เฉพาะฟีเจอร์เท่านั้น การเริ่มต้นจะประสบความสำเร็จอยู่ดี การปรับโครงสร้างที่ไม่เคยเกิดขึ้นกลายเป็นหนี้ทางเทคนิค: ระบบกลายเป็นเสาหินมากขึ้นและบำรุงรักษาได้น้อยลงผลผลิตของผู้พัฒนาลดลงเรื่อย ๆ ฉันไม่ได้อยู่ในทีมตอนนี้ แต่ฉันหวังว่าพวกเขาจะสำเร็จในอนาคตอันใกล้ มิฉะนั้นฉันจะไม่ให้เงินกับการอยู่รอดของโครงการ

1
มีการศึกษาเกี่ยวกับความสัมพันธ์ระหว่างการทดสอบซอฟต์แวร์กับประสิทธิภาพของนักพัฒนาหรือไม่? [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา มีการศึกษาเกี่ยวกับความสัมพันธ์ระหว่างการทดสอบซอฟต์แวร์ (หน่วยและ / หรือการทดสอบการรวม) และการพัฒนาของนักพัฒนาหรือไม่?

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

8
ช่วงเวลาการทำงานใดที่ให้ผลดีกว่า: สั้นหรือยาว [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน4 ปีที่แล้ว เซสชันการทำงานใดมีประสิทธิผลมากขึ้นสำหรับการเขียนโปรแกรม: สั้น (<= 30 นาที), กลางยาวหรือยาว (> = 2 ชั่วโมง) ในกรณีใด (พิจารณาการเขียนโค้ดฟังก์ชั่นใหม่ทำการปรับเปลี่ยนเล็กน้อยปรับแต่ง UI ปรับโครงสร้างใหม่ตรวจแก้จุดบกพร่องเรียนรู้ API พยายามเข้าใจรหัสของผู้อื่น) คุณสามารถบอกอะไรได้บ้างจากประสบการณ์ของคุณ? ยินดีต้อนรับข้อมูลจากการศึกษาและแนวปฏิบัติที่ดีที่สุด แม้ว่ามันจะเป็นการดีที่ได้เห็นลิงก์หรือการอ้างอิง ข้อมูลที่เชื่อถือได้เป็นที่ต้องการมากกว่าคำตอบที่สมบูรณ์ ประเด็นที่มีคุณค่า: การคิดที่มุ่งเน้นเป็นเป้าหมายสูงสุดที่นี่ โดยทั่วไปแล้วงานที่ไม่มีการขัดจังหวะ> 2-3 ชั่วโมงจะทำให้สูญเสียการโฟกัสและหมอกลง เมื่อคุณอยู่ในสภาวะที่ดีควรปล่อยให้ตัวเองทำงาน 1-2 ชั่วโมง ควรลองฝึกเทคนิคของ Pomodoro เพื่อช่วยในการเอาชนะความเฉื่อยและการผัดวันประกันพรุ่งเพื่อให้ได้เวลาที่ดีขึ้น โดยเฉพาะอย่างยิ่งสามารถช่วยในการเริ่มทำสิ่งที่คุณไม่ชอบทำมาก เมื่อใช้ซอฟต์แวร์ 'การจัดการการแบ่ง' คุณสามารถอนุญาตให้ตัวเองมีความยืดหยุ่นมากขึ้นเช่นข้ามการหยุดพัก 1 ครั้ง แต่ไม่มาก สิ่งนี้ช่วยให้คุณสามารถปรับตัวเข้ากับสถานการณ์: อยู่ในกระแสเมื่อมีการไหลอยู่จัดการได้เมื่อไม่ไหล อากาศบริสุทธิ์การผ่อนคลายและการออกกำลังกายในช่วงพักสามารถช่วยให้มีส่วนร่วมในซีกขวาเพื่อรับแนวคิดและวิธีการแก้ไขใหม่ ๆ ลองใช้เครื่องมือซอฟต์แวร์สำหรับ …

10
ทำไมบางครั้งไม่คิดเกี่ยวกับบั๊กช่วยให้คุณแก้ปัญหาได้? [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน5 ปีที่ผ่านมา เมื่อวานนี้ฉันใช้เวลาช่วงบ่ายในการแก้ไขข้อบกพร่องซึ่งฉันคิดว่าไม่สำคัญ ฉันเดินวนเป็นวงกลมโดยไม่มีเงื่อนงำสิ่งที่ผิด การเขียนซ้ำส่วนใหญ่ของรหัส ตรวจสอบ SO ยังไม่มีความสุข ดังนั้นฉันกลับบ้านเดินสุนัขดูทีวีเล็ก ๆ และก่อนที่ฉันจะเข้านอนบิงโกฉันตระหนักถึงความผิดพลาดที่เห็นได้ชัดที่ฉันทำ เช้านี้มันใช้เวลาประมาณ 10 นาทีในการแก้ไข ในขณะที่ฉันอยู่ที่บ้านฉันไม่ได้คิดถึงปัญหาอย่างแข็งขัน แต่การพาตัวเองออกจากสถานการณ์ทำให้ฉันสามารถแก้ไขได้ มันไม่ใช่ครั้งแรกที่มันเกิดขึ้นและฉันรู้ว่ามันเป็นวิธีที่ใช้กันทั่วไปในการแก้ปัญหาการเขียนโปรแกรม ฉันเคยได้ยินคนที่ฝันถึงคำตอบ ทำไมจึงใช้งานได้ บางทีสิ่งที่สำคัญกว่านั้นคือมีคำแนะนำที่ดีเกี่ยวกับเวลาที่คุณควรหยุดพักจากปัญหาระยะเวลาที่ควรหยุดพักและหลังจากทิ้งระยะเวลานานเท่าใดที่ปัญหาจะหยุดมีประสิทธิภาพ ฉันคิดว่าฉันกำลังพยายามหาวิธีเพิ่มประสิทธิภาพการประมวลผลจิตใต้สำนึก (หรือสิ่งที่เกิดขึ้น)

3
Visual Studio เป็นเพียง IDE หรือไม่?
สำหรับการพัฒนา Windows ฉันหมายถึง ดูคำถามอื่น ๆ ที่มีทางเลือกในการ VS แต่พวกเขาดูเหมือนจะเป็นเว็บที่ใช้ซึ่งเป็นเรื่องปกติหรือคุณสามารถเขียนโปรแกรมเว็บไซต์. net ทั้งหมดใน notepad ควรกระตุ้นให้คุณ แต่มีมากกว่านั้นสำหรับ IDE สำหรับการพัฒนา Windows หรือไม่ IE เป็นไปได้ไหมที่ฉันจะสร้างแอปพลิเคชั่นใน notepad เพียงอย่างเดียวคอมไพเลอร์ส่วนหนึ่งของ Visual Studio หรือแยกออกจากกันซึ่งสามารถเรียกได้ผ่านทางบรรทัดคำสั่งหรืออะไรบางอย่าง ฉันไม่ต้องการที่จะไม่ใช้ VS ฉันมีความสุขกับมันทำในสิ่งที่ฉันต้องการ ฯลฯ และอื่น ๆ อีกมากมายที่ฉันอยากรู้

6
เครื่องมือ / ส่วนเสริมประสิทธิภาพสูงสุดสำหรับนักพัฒนาซอฟต์แวร์สำหรับ Java ใน Eclipse คืออะไร
ล็อคแล้ว คำถามและคำตอบของคำถามนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ฉันใช้ CodeRush ใน Visual Studio 2010 เพื่อทำการปรับโครงสร้างเขียนรหัสได้เร็วขึ้นด้วยเทมเพลตและนำทางรหัสของฉันเร็วกว่าหุ้น VS ถึง 10 เท่า เมื่อเร็ว ๆ นี้ฉันได้ทำงานกับแอพ Android อื่นและต้องคิดว่า ... ปลั๊กอินเสริมประสิทธิภาพสูงสุดสำหรับ Eclipse คืออะไร ฟรีโดยเฉพาะอย่างยิ่ง ฉันกำลังมองหาปลั๊กอินที่ช่วยเขียนใน Java ไม่ใช่ PHP หรือ Rails หรือภาษาอื่น ๆ ที่ Eclipse รองรับ

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

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

1
มีการศึกษาเชิงประจักษ์เกี่ยวกับผลกระทบของการคอมเม้นท์ซอร์สโค้ดต่อคุณภาพของซอฟต์แวร์ความสามารถในการบำรุงรักษาและประสิทธิภาพของนักพัฒนาหรือไม่? [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน6 ปีที่ผ่านมา ฉันเป็นผู้สนับสนุนให้ความเห็นเกี่ยวกับซอร์สโค้ดและการทำเอกสารผลิตภัณฑ์ซอฟต์แวร์ มันเป็นประสบการณ์ส่วนตัวและการสังเกตของฉันว่าการทำงานกับซอร์สโค้ดที่แสดงความคิดเห็นอย่างจริงจังได้ช่วยฉันในรูปแบบที่แตกต่างกันเมื่อฉันต้องเติบโตซอฟต์แวร์หรือบำรุงรักษามัน อย่างไรก็ตามมีอีกค่ายหนึ่งที่กล่าวว่าการแสดงความคิดเห็นนั้นไร้ค่าในที่สุดหรือคุณค่าของมันนั้นน่าสงสัย ผู้เสนอการเข้ารหัสจำนวนมากโดยไม่แสดงความเห็นแย้งว่า: หากโค้ดหนึ่งชิ้นเขียนได้ดีก็จะเป็นการอธิบายตนเองและไม่จำเป็นต้องแสดงความคิดเห็น หากโค้ดหนึ่งชิ้นไม่สามารถอธิบายตัวเองได้ให้ทำการรีแฟคเตอร์ใหม่และทำให้มันอธิบายได้ด้วยตนเองเพื่อที่ว่ามันจะไม่ต้องการความคิดเห็นใด ๆ ชุดทดสอบของคุณคือเอกสารสด เมื่อเวลาผ่านไปรหัสและความคิดเห็นไม่ซิงค์กันและจะกลายเป็นแหล่งที่มาของอาการปวดหัว Agile กล่าวว่ารหัสการทำงานสำคัญกว่ากองเอกสารดังนั้นเราจึงสามารถละเว้นการเขียนความคิดเห็นได้อย่างปลอดภัย สำหรับฉันนี่เป็นเพียงความเชื่อ อีกครั้งการสังเกตส่วนตัวของฉันคือซอฟต์แวร์ที่เขียนโดยทีมนักพัฒนาที่ชาญฉลาดและมีประสบการณ์ท้ายที่สุดก็จบลงด้วยรหัสจำนวนมากที่ไม่ได้อธิบายตัวเอง อีกครั้งที่ Java API, Cocoa API, Android API ฯลฯ แสดงว่าหากคุณต้องการเขียนและดูแลรักษาเอกสารที่มีคุณภาพเป็นไปได้ การพูดถึงสิ่งเหล่านี้การสนทนาเกี่ยวกับข้อดีข้อเสียของการจัดทำเอกสารและการแสดงความคิดเห็นในซอร์สโค้ดที่อิงตามความเชื่อส่วนตัวมักจะไม่จบลงและนำไปสู่ข้อสรุปที่ไม่พึงพอใจ ดังนั้นฉันกำลังมองหาเอกสารทางวิชาการและการศึกษาเชิงประจักษ์เกี่ยวกับผลกระทบของเอกสารประกอบซอฟต์แวร์โดยเฉพาะการแสดงความคิดเห็นซอร์สโค้ดต่อคุณภาพและการบำรุงรักษารวมถึงผลกระทบต่อประสิทธิภาพการทำงานของทีม คุณได้สะดุดกับบทความดังกล่าวและสิ่งที่เป็นผลของพวกเขาถ้ามี?

8
แลปท็อปที่มีความละเอียดสูงแสดงว่าสำคัญสำหรับโปรแกรมเมอร์หรือไม่ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ปิดให้บริการใน5 ปีที่ผ่านมา ล็อคแล้ว คำถามและคำตอบของคำถามนี้ถูกล็อคเนื่องจากคำถามอยู่นอกหัวข้อ แต่มีความสำคัญทางประวัติศาสตร์ ขณะนี้ไม่ยอมรับคำตอบหรือการโต้ตอบใหม่ ฉันกำลังซื้อแล็ปท็อปเครื่องใหม่ที่ฉันจะใช้เป็นหลักในการเขียนโปรแกรม สองตัวเลือกที่น่าสนใจจริงๆสำหรับฉันคือAsus Zenbook UX31AและRetina Macbook Proใหม่ เห็นได้ชัดว่าจอแสดงผลความละเอียดสูงบนแล็ปท็อปเหล่านี้มีประโยชน์สำหรับความบันเทิงการแก้ไขภาพและอื่น ๆ คำถามของฉันคือ: จอแสดงผลเหล่านี้มีประโยชน์สำหรับโปรแกรมเมอร์หรือไม่? จอแสดงผลเหล่านี้สร้างรหัสให้อ่านง่ายขึ้นหรือไม่ พวกเขาจะสบายตาหรือหลังจากมองไปที่หน้าจอทั้งวัน?

3
ฉันสามารถใช้เหตุผลอะไรในการ "ขาย" แนวคิด BDD ให้กับทีมที่ไม่เต็มใจยอมรับมัน
ฉันเป็นแกนนำของวิธีการขับเคลื่อนการพัฒนาพฤติกรรม (BDD) ฉันใช้ BDD มาสองสามปีแล้วและได้ปรับใช้StoryQเป็นกรอบทางเลือกของฉันเมื่อพัฒนาแอพพลิเคชั่น DotNet แม้ว่าฉันได้ทำการทดสอบหน่วยมาหลายปีแล้วและก่อนหน้านี้ได้เปลี่ยนวิธีการทดสอบเป็นครั้งแรก แต่ฉันก็พบว่าฉันได้รับประโยชน์มากขึ้นจากการใช้กรอบการทำงานของ BDD เนื่องจากการทดสอบของฉันจับความต้องการของความต้องการค่อนข้าง ชัดเจนภาษาอังกฤษภายในรหัสของฉันและเนื่องจากการทดสอบของฉันสามารถดำเนินการยืนยันหลายโดยไม่สิ้นสุดการทดสอบครึ่งทาง - หมายถึงฉันสามารถดูว่าการยืนยันที่เฉพาะเจาะจงผ่าน / ล้มเหลวได้อย่างรวดเร็วโดยไม่ต้องแก้จุดบกพร่องเพื่อพิสูจน์มัน นี่เป็นส่วนเล็ก ๆ ของภูเขาน้ำแข็งสำหรับฉันอย่างที่ฉันสังเกตเห็นว่าฉันสามารถดีบักทั้งรหัสทดสอบและการติดตั้งในลักษณะที่ตรงเป้าหมายมากขึ้นด้วยผลลัพธ์ที่ทำให้ประสิทธิภาพการทำงานของฉันเติบโตขึ้นอย่างมีนัยสำคัญ กำหนดได้อย่างง่ายดายว่ามีข้อผิดพลาดเกิดขึ้นที่ใดหากมีปัญหาเกิดขึ้นเพื่อให้สามารถสร้างการรวมได้เนื่องจากเอาท์พุทที่เข้าสู่บันทึกการสร้าง นอกจากนี้ StoryQ api มีไวยากรณ์ที่ไพเราะน่ารักซึ่งง่ายต่อการเรียนรู้และสามารถนำไปใช้ได้หลายวิธีโดยไม่ต้องพึ่งพาภายนอกเพื่อใช้งาน ดังนั้นด้วยผลประโยชน์ทั้งหมดนี้คุณจะคิดว่ามันง่ายที่จะแนะนำแนวคิดให้กับทีมอื่น ๆ น่าเสียดายที่สมาชิกในทีมคนอื่น ๆ ยังลังเลที่จะดู StoryQ เพื่อประเมินมันอย่างถูกต้อง (ให้ความบันเทิงกับความคิดในการใช้ BDD) และเชื่อมั่นซึ่งกันและกันเพื่อลองและลบองค์ประกอบของ StoryQ ออกจากกรอบการทดสอบหลักของเราเอง แม้ว่าในตอนแรกพวกเขาจะสนับสนุนการใช้ StoryQ และแม้ว่ารหัสที่พวกเขาต้องการลบจะไม่ส่งผลกระทบต่อส่วนอื่น ๆ ของระบบการทดสอบของเรา การทำเช่นนั้นจะเป็นการเพิ่มปริมาณงานโดยรวมอย่างมีนัยสำคัญและขัดต่อธัญพืชจริง ๆ เพราะฉันเชื่อมั่นในประสบการณ์จริงว่าเป็นวิธีที่ดีกว่าในการทำงานในลักษณะการทดสอบครั้งแรกในสภาพแวดล้อมการทำงานเฉพาะของเราและสามารถนำไปสู่ การปรับปรุงคุณภาพของซอฟต์แวร์ของเราเนื่องจากฉัน เราพบว่าง่ายต่อการติดกับการทดสอบครั้งแรกโดยใช้ BDD เพื่อชี้แจงเพิ่มเติมส่วนใหญ่ของการทดสอบหน่วยที่เรามีแนวโน้มที่จะค่อนข้างเปราะบางและยากที่จะรักษาเป็นโฮลดิ้งจากปีของการทดสอบที่ใช้ไม่ดีที่ไม่เต็มใจที่จะยึดติดกับกระบวนการทดสอบขับเคลื่อนได้เห็นนักพัฒนาถอยกลับ ทำการทดสอบทั้งหมดเมื่อสิ้นสุดโครงการ (บุคคลเดียวกันนี้อ้างว่าเป็น Agile!) …

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

2
ใช้ประโยชน์จากความคิดสร้างสรรค์ด้วย“ เวลาว่าง”
บริษัท บางแห่งค้นพบความประหลาดใจและผลกำไรของพวกเขาว่าโปรแกรมเมอร์เป็นคนที่มีความคิดสร้างสรรค์มาก ตัวอย่างเช่นฉันคิดถึง Google และAtlassianที่อนุญาตให้มีการใช้งานปกติ (รายเดือน) "วันว่าง" ที่ผู้เขียนโปรแกรมจะทำงานในสิ่งที่พวกเขาต้องการ (ด้วยการอนุมัติ) และ บริษัท ได้รับรางวัลใหม่ ตัวอย่างที่อ้างถึงคือผลิตภัณฑ์ใหม่การแก้ไขข้อผิดพลาดที่ไม่มีใครต้องการแก้ไขก่อนสร้างทีมใหม่ ฯลฯ ผลลัพธ์อื่น (และอาจเป็นเป้าหมายดั้งเดิม) ก็คือสำหรับวันที่เหลือระหว่างเวลาว่างโปรแกรมเมอร์มีแรงจูงใจมากขึ้น มีการสนับสนุนทฤษฎีนี้มากขึ้นหรือไม่ว่าการปล่อยให้ความคิดสร้างสรรค์แบบ "ควบคุม" นั้นดีต่อแรงจูงใจและขวัญกำลังใจหรือเป็นตัวอย่างของความสำเร็จด้วยแนวทางนี้

13
คุณอนุญาตให้โปรแกรมเมอร์ของคุณใช้ Messenger และเครือข่ายสังคมเช่น Facebook หรือไม่ [ปิด]
ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา ฉันมีหัวหน้าหลายคนแต่ละคนมีวิธีการที่แตกต่างกันเกี่ยวกับการอนุญาตหรือไม่ใช้ Windows Live Messenger, Facebook และเว็บไซต์อินเทอร์เน็ตอื่น ๆ แน่นอนว่าอินเทอร์เน็ตจำเป็นต้องมีการวิจัยเกี่ยวกับวิธีที่ดีที่สุดในการแก้ปัญหาเฉพาะงาน บางครั้งคุณอาจมีเพื่อนทางออนไลน์เช่นเดียวกับโปรแกรมเมอร์ที่รู้ดีเกี่ยวกับบางสิ่งบางอย่าง สำหรับผู้จัดการบางคนการเข้าถึงอินเทอร์เน็ตจะชะลอความคืบหน้าของโครงการและในทางกลับกันทำให้ผู้คนสามารถโต้ตอบและค้นหาโซลูชันใหม่ล่าสุด คุณจะทำอย่างไร

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