สิ่งที่ทำให้นักพัฒนาซอฟต์แวร์ช้าลงได้บ้าง [ปิด]

สิ่งใดที่มีแนวโน้มที่จะทำให้นักพัฒนาช้าลง

โปรดพยายามอย่าโพสต์คำตอบที่:

• ช้าในขณะนี้ แต่มีประโยชน์ในคุณสมบัติ (TDD การสร้างใหม่ ... )
• รายการสิ่งที่ทำให้ไขว้เขว

โอ้คนนี้ง่าย:

1. การประชุม
2. การประชุมเพิ่มเติม
3. การประชุมเกี่ยวกับการประชุมครั้งล่าสุด
4. การประชุมเพื่อเตรียมพร้อมสำหรับการประชุมที่จะมาถึง
5. การพัฒนาการนำเสนอจุดไฟสำหรับการประชุม
6. การพัฒนางานนำเสนอจุดไฟสำหรับการประชุมการหารือคุณสมบัติที่ไม่ได้ดำเนินการไม่ควรดำเนินการและด้วยเหตุผลใดก็ตามที่ผู้ชายจากการขายจะกระโดดไปทั่ว ฉันไม่สามารถคาดเดาเอกสารที่คุณต้องการแสดงในแอพตามตำแหน่งปัจจุบันของคุณโดยไม่ต้องเชื่อมต่ออินเทอร์เน็ตหรือเข้าถึงฮาร์ดไดรฟ์ของคุณ ไม่จริงเพียงแค่ยอมแพ้ขอเช่นกัน

คอมพิวเตอร์ช้า

สิ่งใดที่ทำให้เกิดการเปลี่ยนบริบท

StackOverflow, programmers.stackexchange.com ฯลฯ :)

ฉันจะบอกว่าเหนื่อยหน่าย

ความพยายามใด ๆ ที่จะปฏิบัติตามกระบวนการที่ไม่เหมาะสมกับงานในมือ

นี่อาจเป็นสิ่งต่าง ๆ แต่สิ่งที่ฉันเห็นโดยทั่วไป ได้แก่ :

• วิธีการทดสอบที่ไม่พอดีกับรหัสที่กำลังทดสอบ
• กระบวนการที่มีความคล่องตัวหรือแบบดั้งเดิมมากกว่าการรับประกันที่ส่งมอบ
• แนวทางที่มีไว้สำหรับชุดเครื่องมือที่แตกต่างจากชุดเครื่องมือที่เลือก
• หลักการออกแบบที่ไม่ตรงตามความต้องการของโครงการ
• ใช้ชุดเครื่องมือที่ไม่เหมาะกับงาน

สิ่งเหล่านี้ทั้งหมดมีคุณค่าอย่างมากในบางโครงการหรือในบางสถานการณ์ แต่บางองค์กรพยายามทำทุกอย่างทางเดียวและนำไปสู่ความไม่ดีในโครงการอื่น ๆ

การเมือง

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

บทสนทนาของคนอื่น

และเสียงทั่วไป

คำตอบมากมายพูดคุยเกี่ยวกับการสลับบริบทและการออกนอกเขตและเสียงโดยเฉพาะการสนทนาเป็นหนึ่งในสิ่งเหล่านั้นที่นำไปสู่สิ่งที่ฉัน

ใน Cubeworld ของฉันฉันถูกล้อมรอบด้วยเสียงและการสนทนาทุกด้าน แถวหนึ่งเหนือกว่าทีมเมนเฟรมจะจัดการประชุมวางแผนอย่างต่อเนื่องในแถวคิวบ์ บางครั้งพวกเขาจะพบกับที่ปรึกษาในสำนักงานตามแนวกำแพงและมีแนวโน้มที่จะนำไปสู่เสียงดัง hootin 'และ hollerin' และ laughin 'และฉันต้องข้ามไปและขอให้พวกเขาปิดประตู

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

คำตอบที่ชัดเจนและชัดเจนของ " คุณไม่เพียงแค่ได้รับหูฟังตัดเสียงรบกวน" ไม่สามารถช่วยได้เมื่อสิ่งที่คุณต้องการเงียบ

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

ถ้าคุณต้องการให้โปรแกรมเมอร์ทำงานที่พวกเขาต้องทำซึ่งส่วนใหญ่คิดและไตร่ตรองและพิจารณาอยู่แล้วพวกเขาต้องการสภาพแวดล้อมที่พวกเขาสามารถทำได้

การเขียนโค้ดจำนวนมากเกินไปโดยไม่มีการทดสอบที่เพียงพอ

ขาดกาแฟคุณภาพสูง

ต้องมีการประเมินที่สมบูรณ์แบบที่ต้องไม่ถูกเบี่ยงเบนจากการพัฒนาเมื่อเริ่มต้นมันเป็นสถานการณ์ไก่ไข่ในความคิดของฉัน

แก้ไขโครงสร้างที่เสียหายของคนอื่น

การประชุมที่ไม่มีวาระ

เครื่องช้า

ไม่มีจอภาพที่สอง

เมาส์เก่าที่มีลูกบอลแทนที่จะเป็นลูกใหม่ที่ดี

ขาดการเข้าถึงอินเทอร์เน็ตบนเครื่องทำให้การสืบค้น MSDN / stackoverflow / etc เป็นเรื่องที่เจ็บปวด

ใช้เวลาเขียนโปรแกรมมากเกินไป

แม้ว่าคุณจะชอบการเขียนโปรแกรม แต่การใช้เวลามากเกินไปในที่สุดก็จะทำให้คุณเบื่อ ...

หลีกเลี่ยงทุกสิ่งที่ทำให้คุณออกจาก "โซน" นั่นหมายถึงกล่องจดหมายอีเมลของคุณแอปพลิเคชั่นป๊อปอัปทวิตเตอร์การแชทขององค์กร ฯลฯ

การมีสภาพการทำงานที่เงียบหมายถึงการหลีกเลี่ยงเสียงรบกวนของเดสก์ท็อปด้วย

การร้องขอการเปลี่ยนแปลงใด ๆ ที่จะนำมาใช้ได้ง่ายขึ้นถ้าคุณรู้เรื่องนี้มาก่อนมือ

รหัสไม่ดี

การต้องเขียนส่วนของคนอื่นที่สามารถทำงานได้ตั้งแต่แรกคือเวลาที่ยิ่งใหญ่ที่สุดที่ฉันจินตนาการได้

The Much That Slows You Downเป็นโพสต์บล็อกที่ดีสำหรับเรื่องนี้

...

หลายโครงการทำซ้ำคุณสมบัติระดับโครงสร้างพื้นฐานหลักซ้ำ ๆ กันทำให้ธุรกิจนั้นช้าลงในการนำเสนอคุณสมบัติที่สร้างความแตกต่างทางธุรกิจจากคู่แข่ง

...

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

...

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

ตอบคำถามบน stackexchange.com เช่นนี้

แม้ว่าคุณจะขอร้องไม่ให้แสดงสิ่งรบกวน แต่มันก็เป็นปัจจัยสำคัญ ดูสภาพแวดล้อมการทำงานของพวกเขาตรวจสอบเพื่อดูว่าพวกเขาถูกขัดจังหวะบ่อยครั้งหรือขอให้ทำสิ่งอื่น ๆ ที่ไม่เกี่ยวข้องกับโครงการ

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

ขาดข้อกำหนดที่กำหนดไว้อย่างชัดเจนซึ่งทำให้พวกเขาต้องคิดออกหรือตัดสินใจ

• ต้องรอประมาณ 15 นาทีเพื่อให้พีซีบูตเข้าสู่สถานะใช้งานได้
• กำลังรอพีซีเพื่อสลับแอปพลิเคชัน
• เป็นคนเดียวในสำนักงานที่ต้องทำชา / กาแฟของตนเอง
• แป้นพิมพ์เสีย (แก้ไข!)
• การทำงานนอกสำนักงานของกรรมการผู้จัดการ (US CEO) (และไม่ได้อยู่ในออฟฟิศด้วย) โดยมีเพียงพาร์ทิชันระหว่าง (โดยเฉพาะเมื่อมีการประชุม)
• เจ้านายเข้าถึงได้ทางอีเมลเท่านั้น แต่ทุกคนอยู่ในอาคาร
• ไม่ได้รับอนุญาตให้ใช้ VCS - เห็นได้ชัดว่าควรอยู่ในสมองของฉัน
• หน้าจอขนาดเล็ก
• ไม่อนุญาตให้มีเวลาพักนอกเหนือจากอาหารกลางวัน
• ต้องทำการสำรองข้อมูลเซิร์ฟเวอร์ระยะไกลแม้จะมีดูแลระบบในอาคาร
• ถูกบอกให้ทำสำรองข้อมูลดังกล่าวด้วยตนเอง
• ถูกบังคับให้ใช้ระบบการจัดการเวลาที่โง่ที่ไม่จำเป็น
• เพียงแค่ได้รับความคิดที่คลุมเครือของข้อกำหนดสองเดือนในงาน

ฉันสามารถไปต่อได้ แต่เป็นวันศุกร์และฉันอยากจะลืมเรื่องงาน

• ขาดเอกสาร (ระบบ บริษัท ฯลฯ )
• ไม่มีรหัสที่แสดงความคิดเห็น
• ความเข้าใจที่ไม่สมบูรณ์ของระบบ
• การเมือง (เช่นการประชุมที่ไม่จำเป็นเอกสารอุปสรรคโดยการจัดการ ... )
• เอกสารข้อกำหนดที่ไม่สมบูรณ์
• Facebook!
• นอนมากเกินไป?

มีคนมากเกินไปในโครงการ

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

ดังนั้นคุณจะไปจากปลายเดือนเพราะความเร็วไม่เพียงพอ / มากเกินไปที่จะไม่ส่งเลยเพราะคุณใช้งบประมาณไปกับคนพิเศษเหล่านั้นทั้งหมด

นอกเหนือจากสิ่งที่กล่าวถึงโดยคนอื่น ๆทางยาวระหว่างการตัดสินใจที่จะรวบรวมและเรียกใช้รหัสของคุณและได้รับในเชิงบวก / ผลลบ เป็นการดีที่RTTนี้จะเป็นเพียงวินาที แต่ฉันได้เห็นตัวอย่างของชั่วโมง BTW การทดสอบหน่วยพยายามจัดการกับปัญหานี้

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

• เอกสารที่มากเกินไป

• มีการพึ่งพาคนที่ไม่เคยอยู่มาก่อน (เช่นเจ้านายของคุณ - ถ้าคุณต้องการถามคำถาม แต่เขาอยู่ในการประชุมเสมอ)

• เครื่องมือและอุปกรณ์ไม่เพียงพอ

• ผู้คนกำลังพายเรือของพวกเขาโดยไม่มีเหตุผล (การเปลี่ยนแปลงใด ๆ ที่มองเห็นได้ของ UI อยู่ภายใต้เรื่องนี้) หรือเพียงแค่เถียงโต้เถียงเกี่ยวกับสิ่งเล็กน้อย

• เครื่องชงกาแฟแตก

• การได้รับมอบหมายงานที่ผิด

เครื่องปรับอากาศไม่ทำงาน

ดังนั้นอุณหภูมิในสำนักงานจะสูงถึง 40 องศาในฤดูร้อนที่ -5 ในฤดูหนาว

-5 ไม่ดีสำหรับการพิมพ์เนื่องจากฉันไม่สามารถสวมถุงมือและประเภทได้ 40, เพียงแค่ความคิดของฉันช้าลง

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

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

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

รับสิ่งที่ทำงานได้อย่างรวดเร็วและปรับปรุง

บล็อกของโปรแกรมเมอร์ : ไม่เหมือนกับดาวน์ช้าอื่น ๆ อันนี้ยากที่จะแก้ไข