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

คำเตือน: ความคิดเห็นที่แสดงเป็นของฉันเท่านั้นและไม่ได้แสดงความคิดเห็นหรือความคิดเห็นของนายจ้างของฉัน ฉันทำงานให้กับ บริษัท ขนาดเล็กซึ่งมีเพียงไม่กี่คนที่เป็นนักพัฒนาและคนอื่น ๆ คือ QA / Test และ 1 เป็นผู้จัดการ ฉันเข้าร่วม บริษัท นี้เมื่อ 1.5 ปีที่แล้ว นักพัฒนาอาวุโส 3 คนมีประสบการณ์มากกว่า 8 ปี นี่คือข้อสังเกตที่ฉันทำเกี่ยวกับหัวหน้าทีม (คิดว่าฉันเป็นคนที่มีประสบการณ์น้อยกว่าเมื่อเทียบกับพวกเขาในทุกด้าน) พวกเขาไม่เคยพูดถึง 1: 1 หรือพวกเขาไม่พิจารณาข้อเสนอแนะของผู้อยู่ใต้บังคับบัญชา (ฉันเห็นด้วยว่าขึ้นอยู่กับพวกเขาไม่ว่าพวกเขาจะยอมรับหรือไม่อย่างน้อยพวกเขาควรพิจารณาความเห็น) ในฐานะหัวหน้าทีมอาวุโสพวกเขาสามารถพยายามปรับโครงสร้าง codebase ด้วยเทคโนโลยีใหม่ (รวมถึงปัจจัยในการเปิดตัวเทคโนโลยีใหม่ที่เป็นไปได้และผู้พัฒนาและโครงสร้างพื้นฐานอื่น ๆ ก็พร้อม) แต่ผู้นำทีมเหล่านี้รู้สึกไม่ปลอดภัยในการทำงานกับเทคโนโลยีใหม่ พวกเขาไม่ทันสมัย (เหตุผลที่ฉันบอกพวกเขาไม่ทราบว่าแนวโน้มการเขียนโปรแกรมปัจจุบัน * (เช่นโครงการโอเพ่นซอร์สยอดนิยมเช่น modernizr, bootstrap และอื่น ๆ อีกมากมาย) ใน codebase ของเรามากขึ้นกว่า 10000+ …

44 self-improvement  teamwork  junior-programmer  team-leader 

เมื่อทำงานกับโค้ดฉันต้องเผชิญกับความท้าทายหลายอย่างที่เพื่อนร่วมทีมของฉันทำและฉันได้เขียนฟังก์ชั่นและชั้นเรียนที่มีประโยชน์ หากมีการสื่อสารที่ดีฉันจะได้ยินเกี่ยวกับสิ่งที่ยอดเยี่ยมที่ใครบางคนรวบรวมไว้และอีกหกเดือนต่อมาเมื่อฉันต้องการฉันอาจจำได้และเรียกใช้ฟังก์ชันนั้นประหยัดเวลา หากฉันจำไม่ได้หรือไม่เคยรู้เรื่องนี้ฉันอาจจะประดิษฐ์วงล้อขึ้นใหม่ มีวิธีปฏิบัติที่เฉพาะเจาะจงในการบันทึกสิ่งเหล่านี้หรือไม่? คุณทำให้พวกมันหาง่ายได้อย่างไร? หากทีมของคุณไม่มีเอกสารดังกล่าวคุณจะรู้ได้อย่างไรว่าล้อของคุณมีอยู่แล้ว? แก้ไข: ทั้งหมด แต่หนึ่งในคำตอบที่เกี่ยวข้องกับสถานการณ์ในอุดมคติดังนั้นขอสรุปการแก้ปัญหาเหล่านั้น: เอกสาร & การสื่อสาร; wikis, stand-up meetings เป็นต้นสิ่งเหล่านี้ล้วน แต่เป็นสิ่งที่ยอดเยี่ยม แต่พวกเขาต้องพึ่งพาโปรแกรมเมอร์ที่มีเวลา (และทักษะ) ในการเขียนเอกสารและเข้าร่วมการประชุมและจดบันทึกและจดจำทุกสิ่ง คำตอบที่ได้รับความนิยมมากที่สุดจนถึงปัจจุบัน (Caleb's) เป็นคำตอบเดียวที่โปรแกรมเมอร์สามารถใช้งานได้ซึ่งไม่สามารถจัดทำเอกสารและการประชุมได้ การเขียนโปรแกรมเป็นสิ่งที่โปรแกรมเมอร์ทำและใช่โปรแกรมเมอร์ที่ยอดเยี่ยมสามารถเขียนเอกสารประกอบการทดสอบหน่วย ฯลฯ แต่มาดูกัน - พวกเราส่วนใหญ่ชอบเขียนโปรแกรมเพื่อจัดทำเอกสาร วิธีแก้ปัญหาของเขาคือที่โปรแกรมเมอร์จำรหัสที่ใช้ซ้ำได้และดึงมันออกไปยังคลาสหรือพื้นที่เก็บข้อมูลของตัวเองหรืออะไรก็ตามและโดยความจริงที่ว่ามันถูกแยกออกมันจะกลายเป็นความสามารถในการเรียนรู้ . และนี่คือความสำเร็จโดยการเขียนโปรแกรม ในแบบที่ฉันเห็นมันเป็นแบบนี้: ฉันเพิ่งเขียนสามหน้าที่และมันเกิดขึ้นกับฉันที่คนอื่นควรรู้เกี่ยวกับพวกเขา ฉันสามารถจัดทำเอกสารเขียนบันทึกประกาศในที่ประชุม ฯลฯ - ซึ่งฉันทำได้ แต่ไม่ใช่จุดแข็งของฉัน - หรือ .... ฉันสามารถแยกพวกเขาออกจากชั้นเรียนตั้งชื่อให้ดีทำให้พวกเขาทำงานได้ กล่องดำและติดไว้ที่ไฟล์คลาสอื่น ๆ จากนั้นอีเมลสั้น ๆ ประกาศว่าเป็นเรื่องง่าย นักพัฒนาซอฟต์แวร์คนอื่นสามารถสแกนโค้ดและเข้าใจได้ดีกว่าฟังก์ชั่นแยกที่ใช้ในโค้ดที่พวกเขาไม่เข้าใจ - บริบทนั้นจะถูกลบ …

43 documentation  teamwork  team  code-reuse 

ปัจจุบัน บริษัท ของเราพัฒนาแอพพลิเคชั่นที่ประกอบด้วยเวลาส่วนใหญ่ใน Ruby on Rails เว็บเซิร์ฟเวอร์และไคลเอนต์ REST ที่แตกต่างกันตั้งแต่ระบบ kiosk ใน Java ไปจนถึงอุปกรณ์ฝังตัวใน C / C ++ (นอกเหนือจากอินเตอร์เฟสสำหรับเว็บเบราว์เซอร์มาตรฐาน) เราจำเป็นต้องขยายทีมของเราและเมื่อล้มเหลวในการหาโปรแกรมเมอร์อาวุโสที่ดีเราตัดสินใจที่จะใช้ความพยายามในการฝึกอบรมโปรแกรมเมอร์อาวุโสที่จะเติบโตไปด้วยกันกับ บริษัท เราได้มอบหนังสือ Ruby และ Rails ให้พวกเขาแล้วและขอให้พวกเขาสร้างโปรแกรมของเล่นบางส่วน แต่ตอนนี้ฉันรู้แล้วว่าเส้นโค้งการเรียนรู้ที่สูงชันสำหรับสถานะของการเขียนโปรแกรมเว็บในปัจจุบันเป็นอย่างไร เมื่อฉันเริ่มเขียนโปรแกรม 15 ปีที่แล้วฉันใช้เฉพาะ Delphi และ Source Safe และสามารถผลิตซอฟต์แวร์ที่ใช้ได้ตั้งแต่ต้น ทั้งสองเป็นเครื่องมือง่าย ๆ และง่ายต่อการเจาะลึกถึงผลงานภายในของสิ่งแวดล้อม ช้าฉันเริ่มใช้เฟรมเวิร์กของบุคคลที่สามได้เปลี่ยนเป็น CVS, SVN และ Git ในที่สุดได้เรียนรู้สิ่งต่าง ๆ ที่ทำให้เว็บของวันนี้เช่น HTTP, JavaScript, CSS, REST และอื่น …

39 web-development  teamwork  ruby-on-rails  training  junior-programmer 

ฉันเพิ่งเริ่มต้นเป็นนักพัฒนารุ่นน้อง เช่นเดียวกับการเป็นหนึ่งในคนที่มีประสบการณ์น้อยที่สุดในทีมฉันก็เป็นผู้หญิงคนหนึ่งซึ่งมาพร้อมกับความท้าทายทุกประเภทของตัวเองที่ทำงานในสภาพแวดล้อมที่เป็นชาย ฉันมีปัญหาเมื่อเร็ว ๆ นี้เพราะฉันรู้สึกว่าฉันได้รับคำวิจารณ์เชิงวิพากษ์วิจารณ์มากเกินไปในงานของฉัน ผมขอยกตัวอย่างสิ่งที่เกิดขึ้นเมื่อเร็ว ๆ นี้ หัวหน้าทีมยุ่งเกินไปที่จะผลักดันในบางสาขาที่ฉันทำดังนั้นเขาจึงไม่ไปถึงพวกเขาจนกว่าจะถึงสุดสัปดาห์ ฉันตรวจสอบเมลของฉันไม่ได้มีความหมายว่าจะทำงานใด ๆ และพบว่าทั้งสองสาขาของฉันถูกปฏิเสธโดยใช้ชื่อตัวแปรทำให้ข้อความแสดงข้อผิดพลาดมีความหมายมากขึ้นและย้ายค่าบางอย่างไปยังไฟล์ปรับแต่ง ฉันไม่รู้สึกว่าการปฏิเสธสาขาของฉันบนพื้นฐานนี้มีประโยชน์ ผู้คนจำนวนมากทำงานในช่วงสุดสัปดาห์และฉันไม่เคยบอกว่าจะทำงาน อย่างมีประสิทธิภาพบางคนอาจถูกบล็อกเพราะฉันไม่มีเวลาทำการเปลี่ยนแปลงและส่งอีกครั้ง เรากำลังทำงานในโครงการที่มีความอ่อนไหวต่อเวลามากและดูเหมือนว่าสำหรับฉันแล้วมันไม่ได้มีประโยชน์อะไรเลยที่จะปฏิเสธรหัสทันทีตามสิ่งต่าง ๆ ที่โปร่งใสสำหรับลูกค้า ฉันอาจจะผิด แต่ดูเหมือนว่าสิ่งเหล่านี้ควรได้รับการจัดการในประเภทปะแก้เมื่อฉันมีเวลา ตอนนี้ฉันเห็นแล้วว่าในบางสภาพแวดล้อมนี่จะเป็นบรรทัดฐาน อย่างไรก็ตามการวิจารณ์ไม่ได้กระจายเท่ากันซึ่งเป็นสิ่งที่นำไปสู่ปัญหาต่อไปของฉัน พื้นฐานของปัญหาเหล่านี้ส่วนใหญ่เกิดจากความจริงที่ว่าฉันอยู่ใน codebase ที่คนอื่นเขียนและพยายามที่จะบุกรุกน้อยที่สุด ฉันเลียนแบบชื่อตัวแปรที่ใช้ที่อื่นในไฟล์ เมื่อฉันพูดถึงสิ่งนี้ฉันก็บอกอย่างตรงไปตรงมาว่า "อย่าเลียนแบบคนอื่นทำในสิ่งที่ถูกต้อง" นี่อาจเป็นสิ่งที่มีประโยชน์น้อยที่สุดที่ฉันบอกได้ หากรหัสที่เช็คอินแล้วไม่สามารถยอมรับได้ฉันควรจะบอกได้อย่างไรว่าอะไรถูกและผิด? หากพื้นฐานของความสับสนนั้นมาจากรหัสพื้นฐานฉันไม่คิดว่า ' ฉันรู้สึกโดดเดี่ยวและผิดหวังมากในสถานการณ์นี้ ฉันได้รับสิ่งที่ดีกว่ามากเกี่ยวกับการทำตามมาตรฐานที่คาดไว้และฉันรู้สึกหงุดหงิดเช่นเมื่อฉันสร้างรหัสใหม่เพื่อตรวจสอบข้อผิดพลาดของ ADD ที่หายไปก่อนหน้านี้ฉันบอกเพียงว่าฉันไม่ได้ ทำให้เกิดข้อผิดพลาดอย่างเพียงพอ (และสาขาถูกปฏิเสธบนพื้นฐานนี้) จะเกิดอะไรขึ้นถ้าฉันไม่เคยเพิ่มลงไปเพื่อเริ่มต้น มันจะเริ่มต้นอย่างไรในรหัสเพื่อเริ่มต้นถ้ามันผิดดังนั้น? นี่คือเหตุผลที่ฉันรู้สึกแยกออกจากกัน: ฉันพบกับรหัสปัญหาที่มีอยู่นี้อย่างต่อเนื่องซึ่งฉันเลียนแบบหรือปรับเปลี่ยนใหม่ เมื่อฉันเลียนแบบมันเป็น "ผิด" และถ้าฉัน refactor มันฉัน chided สำหรับทำไม่เพียงพอ (และถ้าฉันไปตลอดทางแนะนำแมลง …

39 code-quality  self-improvement  teamwork  code-reviews 

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

38 project-management  teamwork  team 

ฉันพบคำถาม (รหัสโคบาลของทีม) แต่มันเกี่ยวข้องกับ "Ninja Coder" มากกว่าปัญหาที่ฉันมี ฉันมีสมาชิกในทีมที่เป็นตัวอย่างชีวิตที่บริสุทธิ์ของ " คาวบอยโคเดอร์ " ฉันเข้าใจว่าไม่มีใครเปลี่ยนคนได้ แต่เป็นวิธีที่ทำให้เขาหยุดทำตัวเหมือน "โคบาลโคด" หรือไม่? เขาปฏิเสธที่จะฟังทีมและเมื่อเร็ว ๆ นี้เขาได้หยุดการตรวจสอบโค้ดการทดสอบหน่วยการแบ่งปันรายละเอียดการใช้งาน ฯลฯ ใช่เขา "รหัส" เร็ว แต่รหัสของเขาเป็นเพียงตัวสร้างบั๊ก สมาชิกในทีมคนอื่น ๆ และฉันอยู่ใน "ขั้นตอนการแก้ไขข้อบกพร่อง" และ 80% ของข้อบกพร่องมาจากรหัสของเขา ฉันไม่ต้องการแก้ไขข้อบกพร่องของเขา และผู้บริหารก็ตาบอดหรือไม่ต้องการเห็นสิ่งนี้หรือบางทีพวกเขาอาจชอบความเร็วของเขา มีวิธีใดบ้างที่ฉัน (ในฐานะเพื่อนร่วมงานอายุน้อยกว่าไม่ใช่เจ้านายของเขา) สามารถทำอะไรกับมันได้บ้าง? ฉันจะปลดอาวุธโคบาลโคบาลนี้ได้อย่างไร ฉันรู้สึกเหมือนฉันเป็นคนสุดท้ายที่ใส่ใจโครงการอย่างแท้จริง

37 development-environment  teamwork  communication  cowboy-coding 

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

36 teamwork  knowledge-transfer 

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

35 version-control  git  teamwork 

ฉันทำงานในกลุ่มพัฒนาขนาดเล็กที่มีนักพัฒนา 3 คน เรามีการจัดการที่เข้มงวดและไม่มีโครงสร้างให้กับทีม ไม่มีหัวหน้าทีมที่ได้รับมอบหมายและผู้จัดการก็ถูกส่งมอบอย่างเป็นธรรม นักพัฒนาอาวุโสอยู่กับ บริษัท มา 4 ปีในเวลานั้นเขามีมือขนาดใหญ่ในการตั้งค่าระบบและทำให้พวกเขาทำงานต่อไป เขาไม่ได้เป็นนักพัฒนาที่ดีมาก แต่เป็นโคเดอร์โคบาลที่ดีและเข้าใจเครือข่ายในแบบที่ฉันไม่เคยทำได้ เขาได้รับบทบาทของ "ผู้พัฒนานำ" และ "สถาปนิกระบบ" เพราะเขามีความอาวุโสและรู้สึกว่าเขาดีกว่างานของเขามากกว่าพวกเราที่เหลือ ปัญหาของฉันคือเขาขู่ว่าจะลาออกตลอดเวลา เมื่อวานนี้เขาแจ้งฉันว่าภายใน 6 สัปดาห์เขาจะเลื่อนระดับขึ้นอีกระดับในโปรแกรมการมอบสิทธิ์ 401k และวางแผนที่จะออกเดินทางหลังจากนั้น เมื่อฉันถามเขาว่าทำไมเขาบอกว่าเป็นเพราะผู้จัดการของเรา (ชาย) และทีม (ทีมที่เป็นฉัน) กำลัง“ ทำลายล้าง” เขา เขารู้สึกว่าเขา "สมควร" ได้รับการแต่งตั้งให้เป็นผู้จัดการฝ่ายพัฒนาตามระดับอาวุโสของเขา เขาไม่ชอบฉันเพราะฉันผลักดันสิ่งต่าง ๆ เช่นซอฟต์แวร์ติดตามข้อผิดพลาด / ปัญหาและเพราะฉันทำงานของฉันได้ดี ครั้งล่าสุดที่เขาขู่ว่าจะลาออกฉันก็จริงจังกับเขาและเริ่มวางแผนงานของเขาที่จะจากไป จากนั้นเขาเปลี่ยนใจและบอกฉันว่างานที่ฉันทำคือความรับผิดชอบของเขา เขาอารมณ์เสียกับฉันและความตึงเครียดก็สูงมากชั่วขณะหนึ่ง นี่คือวิธีที่แตกต่างกันที่ฉันได้เข้าหาสถานการณ์: เพียงทำในสิ่งที่เขาถาม: สิ่งนี้ช่วยลดความตึงเครียด แต่ก็ไม่มีอะไรเกิดขึ้นและผู้ใช้ก็อารมณ์เสีย ควบคุมและจัดการสิ่งต่าง ๆ ให้เสร็จ: สิ่งนี้ทำให้ผู้ใช้มีความสุข แต่จากนั้นเขาก็โกรธฉันและปิดตัวลงเขาจะไม่พูดคุยกับฉันหรือทำงานกับฉันเพื่อทำสิ่งต่าง …

35 teamwork  management 

มีค่าใช้จ่ายที่เกี่ยวข้องกับการบูรณาการอย่างต่อเนื่องเช่นการตั้งค่าการฝึกอบรมใหม่กิจกรรมการรับรู้การหยุดเพื่อแก้ไข "ข้อบกพร่อง" ที่กลายเป็นปัญหาข้อมูลการบังคับใช้รูปแบบการเขียนโปรแกรมที่เกี่ยวข้องเป็นต้น การรวมระบบอย่างต่อเนื่องเป็นสิ่งที่จุดสำหรับตัวเอง? แก้ไข: นี่คือการค้นพบของฉัน การตั้งค่าคือ CruiseControl.Net กับ Nant อ่านจาก VSS หรือ TFS นี่คือสาเหตุบางประการของความล้มเหลวซึ่งไม่มีส่วนเกี่ยวข้องกับการตั้งค่า: ค่าใช้จ่ายในการตรวจสอบ : เวลาที่ใช้ในการตรวจสอบว่าแสงสีแดงเกิดจากความไม่สอดคล้องของตรรกะในรหัสคุณภาพของข้อมูลหรือแหล่งอื่นเช่นปัญหาโครงสร้างพื้นฐาน (เช่นปัญหาเครือข่ายการหมดเวลาอ่านจากการควบคุมแหล่งที่มา ลง ฯลฯ ฯลฯ ) ค่าใช้จ่ายทางการเมืองบนโครงสร้างพื้นฐาน : ฉันถือว่าการตรวจสอบ "โครงสร้างพื้นฐาน" สำหรับแต่ละวิธีในการทดสอบการทำงาน ฉันไม่มีวิธีแก้ไขปัญหาการหมดเวลายกเว้นเพื่อแทนที่การสร้างเซิร์ฟเวอร์ เทปสีแดงเข้ามาขวางทางและไม่มีการแทนที่เซิร์ฟเวอร์ ค่าใช้จ่ายในการแก้ไขการทดสอบหน่วย : ไฟสีแดงเนื่องจากปัญหาคุณภาพข้อมูลอาจเป็นตัวบ่งชี้การทดสอบหน่วยที่เขียนไม่ดี ดังนั้นการทดสอบหน่วยขึ้นอยู่กับข้อมูลจึงถูกเขียนขึ้นใหม่เพื่อลดโอกาสที่แสงสีแดงจะเกิดขึ้นเนื่องจากข้อมูลที่ไม่ดี ในหลายกรณีข้อมูลที่จำเป็นถูกแทรกเข้าไปในสภาพแวดล้อมการทดสอบเพื่อให้สามารถทำการทดสอบหน่วยได้อย่างถูกต้อง มันสมเหตุสมผลที่จะบอกว่าการทำให้ข้อมูลมีความแข็งแกร่งมากขึ้นแล้วการทดสอบจะมีประสิทธิภาพมากขึ้นถ้ามันขึ้นอยู่กับข้อมูลนี้ แน่นอนมันใช้งานได้ดี! ค่าใช้จ่ายของความครอบคลุมเช่นการเขียนการทดสอบหน่วยสำหรับรหัสที่มีอยู่แล้ว : มีปัญหาของการครอบคลุมการทดสอบหน่วย มีวิธีการนับพันที่ไม่มีการทดสอบหน่วย ดังนั้นจำเป็นต้องมีจำนวนวันคนจำนวนมากเพื่อสร้างสิ่งเหล่านั้น เนื่องจากมันจะยากเกินไปที่จะสร้างกรณีธุรกิจจึงมีการตัดสินใจว่าการทดสอบหน่วยจะใช้สำหรับวิธีการสาธารณะใหม่ ๆ ผู้ที่ไม่มีการทดสอบหน่วยถูกเรียกว่า 'อาจเป็นสีแดง' จุดที่น่าสนใจที่นี่คือวิธีการแบบคงที่เป็นจุดที่สงสัยในวิธีที่จะเป็นไปได้ที่จะกำหนดว่าวิธีการแบบคงที่ที่เฉพาะเจาะจงล้มเหลวได้อย่างไร ค่าใช้จ่ายในการเผยแพร่ bespoke : …

34 teamwork  continuous-integration 

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

32 teamwork  code-reviews  estimation  project-planning 

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

31 teamwork 

ฉันพบว่าตัวเองอยู่ในจุดที่ยากลำบากของสาย เคยทำงานในเกมกับเพื่อนเขียนโปรแกรมมาเกือบ 8 เดือนแล้ว เราทั้งคู่เริ่มต้นในฐานะผู้มาใหม่ในการเขียนโปรแกรมประมาณเดือนสิงหาคมของปีที่แล้วเขาเป็นนักเรียน CS ปีที่ 2 ฉันเป็นผู้ให้การสนับสนุนด้านเทคโนโลยีโดยการค้าและเป็นโปรแกรมเมอร์ที่สอนตัวเองด้วยหนังสือมากมายและการสมัครสมาชิกออนไลน์ ปัญหาที่ฉันเห็นอยู่ตลอดเวลาคือเมื่อเราเขียนโค้ดจำนวนหนึ่งบ่อยครั้งที่มันจะถูกแฮ็กเข้าด้วยกันมีความล้มเหลวมากมายและหากเป็นแนวคิดใหม่เอี่ยมสำหรับเราหนึ่งคนที่เต็มไปด้วยโซลูชั่นไร้เดียงสา นี่เป็นสิ่งที่ดีเรากำลังเรียนรู้ฉันคาดหวังว่าโค้ดทั้งสองของเราจะถูกแฮ็กเข้าด้วยกันในภาคเรียนหรือรอบที่สอง ปัญหานำเสนอตัวเองเมื่อมันมาถึงการแก้ไขและ refactoring พฤติกรรมที่แฮ็กด้วยกัน คู่ของฉันจะยึดติดกับก้อนกรวดที่สดใหม่ของเขาด้วยกันอย่างโจ๋งครึ่มปฏิเสธที่จะเห็นข้อผิดพลาดใด ๆ ในขณะที่มันเริ่มทำงาน การอ้างถึงความสมบูรณ์แบบจากชิ้นส่วนของโครงสร้างฉันไม่สามารถแม้แต่จะใช้แม้ว่ามันจะมีความคิดเห็นและวิธีการและฟิลด์ที่ตั้งชื่อไว้อย่างเหมาะสมก็ตาม ไม่ว่าฉันจะพยายามแค่ไหนฉันก็ไม่สามารถทำให้เขาเห็นข้อบกพร่องที่เห็นได้ชัดซึ่งจะป้องกันไม่ให้เกิดการเปลี่ยนแปลงหรือการขยายตัวของพฤติกรรมโดยไม่ทำลายมันและทุกอย่างที่มันเชื่อมโยงกับพวกเขาอาจจะอยู่ในชั้นเดียวกัน โซลูชันที่ถูกแฮ็กตลอดเวลาจะถูกแฮ็กอยู่ตลอดและคิดว่าการออกแบบที่ไม่ดีจะยังคงอยู่ในแบบที่พวกเขาคิด ฉันใช้เวลาไปกับการดูแลรหัสใหม่ให้มากขึ้นเพราะฉันเขียนด้วยตัวเองฉันเสียสิ่งที่ต้องทำ คู่ของฉันสูญเสียมันไปคืนนี้และทำให้ชัดเจนว่าไม่ว่าอะไรก็ตามไม่ว่าจะเป็นมาตรฐานไม่ว่าจะเป็นเรื่องธรรมดาการปฏิบัติไม่ว่าจะเป็นข้อพิสูจน์ที่หักล้างไม่ได้ก็ตามรหัสของเขาจะยังคงอยู่ในแบบที่เขาทำ แม้ว่าหนังสือทั้งเล่มจะถูกเขียนขึ้นเกี่ยวกับสาเหตุที่คุณต้องการหลีกเลี่ยงการทำอะไรเขาจะปฏิเสธที่จะยอมรับความถูกต้องของพวกเขาโดยอ้างว่าเป็นเพียงความเห็นของใครบางคน ฉันมีความสนใจในโครงการของเรา แต่ฉันไม่แน่ใจว่าฉันจะสามารถทำงานร่วมกับคู่ค้าของฉันได้หรือไม่ ฉันดูเหมือนจะมีสามตัวเลือกให้ฉันเปิด หยุดการดูแลเกี่ยวกับการทำงานของ codebase ที่ผ่านจุดรวบรวมและเพียงจัดการกับการพยายามที่จะรักษาและแยกวิเคราะห์พฤติกรรมที่แทบจะไม่คลานไปมา หวังว่าเมื่อสิ่งต่าง ๆ เริ่มสลายอย่างจริงจังเขาจะเห็นและพยายามทำมากกว่าแค่ใส่ bandaid เหนือการออกแบบที่มีข้อบกพร่องพื้นฐาน ติดตามข้อถกเถียงที่ไม่รู้จบเกี่ยวกับปัญหาที่เกิดขึ้นเมื่อทศวรรษที่แล้วโดยบุคคลที่มีความสามารถมากกว่า หยุดเขียนโปรแกรมในโครงการนี้ทิ้งโค้ดของฉันเกือบ 10,000 บรรทัดและใช้เวลาหลายชั่วโมงในการออกแบบและลองหาโปรเจคใหม่ด้วยตัวเอง ฉันจะใช้วิธีการใดเพื่อตรวจสอบว่าโครงการนี้ดำเนินต่อกับบุคคลนี้ได้หรือไม่ หรือปัจจัยใดที่ควรมีอิทธิพลต่อการตัดสินใจของฉัน เราได้เขียนโค้ดจำนวนมากและฉันไม่ต้องการยอมแพ้เว้นแต่จะจำเป็น

30 code-quality  refactoring  teamwork  maintenance 

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

30 management  teamwork  team-leader 

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

30 self-improvement  teamwork  team-leader