ฉันจะทำให้คนหยุดการขับรถมอเตอร์ไซค์ (เน้นเรื่องเล็ก ๆ น้อย ๆ ) ได้อย่างไร?


139

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

Why is that named that? (2 นาทีเพื่ออธิบายสาเหตุที่ตั้งชื่อนั้นใหม่ 10 นาทีอภิปรายชื่อใหม่)

Why is that an abstract base class rather than an interface? (เพื่ออธิบาย 2 นาที, 10+ นาทีอภิปรายถึงข้อดีของการตัดสินใจนี้)

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

ดังนั้นเราจึงลองอีกครั้งในภายหลัง (หรือส่วนอื่นของ codebase) และเนื่องจากผู้คนไม่ได้รับความรู้เพียงพอที่จะเอาชนะเอฟเฟกต์การปั่นจักรยาน

ฉันได้พยายามกลุ่มเล็กกลุ่มใหญ่รหัส whiteboarding ไดอะแกรม Visio กำแพงยักษ์ของข้อความให้พวกเขาเพียงแค่เถียงมันให้ตายตัดข้อโต้แย้งสั้นทันที ... บางช่วยให้มากกว่าคนอื่น ๆ แต่ไม่มีอะไรงาน นรกฉันยังลองให้คนอื่นจากทีมอธิบายเพราะฉันคิดว่าอาจเป็นเพราะฉันอธิบายสิ่งต่าง ๆ ไม่ดี

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


44
ฉันเกลียดที่จะพูด แต่ฟังดูเหมือนว่าปรากฏการณ์นี้กำลังแสดงให้เห็นปัญหาของโค้ดเบสมากกว่าผู้ที่มาใหม่
นิโคล

30
คุณลองชะลอคำถามไปจนสิ้นสุดหรือไม่ "รออีกสักครู่แล้วฉันจะอธิบายได้ในตอนท้าย" จากนั้นก็ผลักดันเนื้อหาที่เหลือ บางทีคำถามเหล่านี้บางคำถามอาจตอบตัวเองด้วย
jozefg

21
@ NickC ฉันเชื่อว่ารหัสนั้นดีหรือไม่เกี่ยวข้องกับวิธีที่คุณเข้าใจวิธีการจัดการเพื่อให้ได้ภาพรวมที่ชัดเจน เสียเวลากับรายละเอียดเล็ก ๆ น้อย ๆ จากการเดินทางโดยไม่ต้องสละเวลาเพื่อให้ได้ภาพใหญ่เริ่มต้นที่ไม่ดีและจะไม่ช่วยในการแก้ไขรหัสที่ไม่ดีที่อาจเกิดขึ้น
Shivan Dragon

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

56
มีคำแนะนำที่ดีในคำตอบเหล่านี้ ฉันจะเพิ่มสั้น ๆ : พิจารณาใช้ "กระบวนการ" เป็นพันธมิตรของคุณ เมื่อมีคนพูดว่า "การออกแบบนี้ไม่ดี" การตอบสนองที่ถูกต้องคือ "ยอดเยี่ยมฉันดีใจที่คุณสังเกตเห็นว่าหลังจากการประชุมนี้โปรดป้อนข้อผิดพลาดในฐานข้อมูลการติดตามพร้อมคำอธิบายโดยละเอียดของปัญหาและการแก้ไขที่เสนอของคุณทีม triage จะตรวจสอบข้อเสนอของคุณจัดลำดับความสำคัญกับส่วนที่เหลือของรายการงานและกำหนดให้กับนักพัฒนาที่เหมาะสมในการแก้ไขเมื่อรายการลำดับความสำคัญสูงกว่าได้รับการแก้ไขแล้วย้าย ... "
Eric Lippert

คำตอบ:


159

ฉันคิดว่าปัญหาคือภารกิจ: "ฉันได้รับมอบหมายให้สอน codebase ใหม่ให้กับทีมอื่น"

คุณได้รับงานที่ผิดหรืออาจตีความผิดงานที่คุณได้รับ

โดยการนำเสนอที่ระดับรหัสคุณเชิญการคิดระดับรหัส

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

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

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

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


3
ฉันได้ทำการสอนการออกแบบระดับสูงเล็กน้อยก่อนเช่นเดียวกับการฝึกอบรมเกี่ยวกับเทคโนโลยีใหม่ / ที่ไม่คุ้นเคย (คอนเทนเนอร์ IoC, พลวัต) เพื่อช่วยในการเตรียมตัว การฝึกนั้นผ่านไปค่อนข้างดี มันเป็นจุดที่ดีที่จะยกระดับ
Telastyn

+1 fot ไม่พยายามต่อสู้กับผู้คนที่มี "แฮ็กพลังจิต" เช่น "ฉันจะตอบคำถามนอกหัวข้อในและในเวลาของคุณ!" แต่จะเปลี่ยนมุมมองแทน
Buksy

3
คำตอบที่ยอดเยี่ยม ฉันชอบข้อเสนอแนะโดยเฉพาะอย่างยิ่งในการทำให้โฟกัสเป็น 'สิ่งที่มันทำ' มากกว่า 'สิ่งที่ส่วนประกอบภายในของมันมีชื่อว่า'
Daniel Hollinrake

66

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


8
+1 ด้วยวิธีนี้ผู้คนรู้สึกว่าพวกเขาไม่ถูกเพิกเฉย
andy256

ฉันเห็นด้วยกับสิ่งนี้ หากปัญหาการอภิปรายสิ่งที่ไม่เกี่ยวข้องนานเกินไปแล้วไม่ได้หารือเกี่ยวกับสิ่งที่ไม่เกี่ยวข้อง ...
คริส

7
บางทีแทนที่จะสละเวลาของทุกคนด้วยการเขียนคำถาม OT บนไวท์บอร์ดขอให้ผู้ถามจดบันทึกไว้ (ในหน้า wiki ที่กำหนดปัญหา JIRA ไม่ว่าที่ไหนก็ตาม)
LarsH

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

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

21

กำหนดความคาดหวังอย่างถูกต้องและซื่อสัตย์เปิดเผยและตรงไปตรงมา

ตรวจสอบให้แน่ใจว่าเป้าหมายของคุณเปิดกว้างและโปร่งใส

เริ่มการสนทนาด้วยมุมมองระดับสูงตามที่ได้รับการสนับสนุนโดย andy256 (+1) แต่ต้องแน่ใจว่าคุณรวมวัตถุประสงค์ของคุณไว้เช่น

"... เมื่อเราดูที่ปัญหานี้ขอให้แน่ใจว่าเราไม่ได้มุ่งเน้นที่ x, y และ z นอกจากนี้ตรวจสอบให้แน่ใจว่าเราไม่ได้ดูรายละเอียดการใช้งานเช่น a, b, c หรือรายละเอียดเล็กน้อย เช่น j, k, l. ฉันรู้ว่ามีรายละเอียดมากมายในโค้ดและรายละเอียดที่สามารถแก้ไขปรับปรุงหรือสร้างมาตรฐานได้มากขึ้น แต่ลองมาดูสิ่งที่บรรลุในระดับที่สูงขึ้นก่อน "


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

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

17

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

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

กุญแจสำคัญในการประชุมที่ดีคือให้ทุกคนรู้ว่า:

  • ทำไมคุณถึงมีการประชุมและ
  • สิ่งที่คุณหวังว่าจะได้จากมัน
  • มันควรจะนานแค่ไหน

ระบุสิ่งเหล่านี้ไว้ล่วงหน้าอย่างชัดเจนและอธิบายเป้าหมาย

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

จากนั้นเมื่อมีหัวข้อเกิดขึ้นอาจเป็นเช่นนี้:

คนใหม่: "เหตุใด FooWidget จึงถูกนำไปใช้เป็นรูปแบบซุ้มได้"

คุณ: "ฉันคิดว่าเป็นเพราะ (คำอธิบายสั้น ๆ เกี่ยวกับการตัดสินใจออกแบบ)" หรือ "ฉันไม่รู้"

หากคำตอบนั้นเพียงพอนั่นยอดเยี่ยมมาก ถ้าไม่เช่นนั้นมันจะดำเนินต่อไป:

NP: "คุณไม่คิดว่ามันจะทำได้ดีกว่าในฐานะซิงเกิล?"

คุณ: "ฉันไม่ได้คิดอย่างนั้นจริงๆ แต่ฉันอยากจะเดินหน้าต่อไปพร้อมกับอธิบายว่า FooWidget ทำงานอย่างไร"

NP: "แต่ถ้ามันทำแบบซิงเกิลเราทำได้ -"

คุณ: "ฉันขอโทษที่ต้องขัดจังหวะ แต่ฉันต้องให้ความสำคัญกับวิธีการทำงานของ FooWidget การประชุมนี้มีกำหนดเวลาจนถึง 11:00 และเรามีจำนวนมากที่ต้องผ่านการอภิปรายการออกแบบจะต้องรออีกครั้ง ."

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

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


1
มันง่ายที่จะบอกเมื่อผู้นำเสนอไม่สนใจความคิดเห็น การประชุมเหล่านั้นดำเนินไปอย่างรวดเร็ว ไม่มีใครสนใจ.
chux

4

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

เปรียบเทียบกับการแก้ปัญหาที่เกิดขึ้นจริงการคิดเชิงนามธรรมและการตัดสินใจเกี่ยวกับปัญหาที่ยากลำบากซึ่งพวกเขาอาจต้องรับผิดชอบต่อผลที่ตามมาในภายหลังและพนักงานหลายคนมีน้ำหนักมากในด้านของการพยายามปั่นจักรยานให้มากที่สุด

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

นี่เป็นเรื่องยากที่จะทำเพราะคนอาวุโสมักจะไม่เข้าใจเทคโนโลยีที่เกิดขึ้นไม่สนใจและน่าเสียดายที่ควบคุมวัตถุดิบ: เวลาของพนักงาน จ้าง & ไฟ, การเมืองในห้องประชุม, โปรโมชั่น, ฯลฯ อย่างจริงจังและอื่น ๆ เพื่อที่


3

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

นอกจากนี้ยังไม่จำเป็นต้องไปหาคำอธิบายรายละเอียดอย่างละเอียดของ codebase ทั้งหมดเพราะรายละเอียดจะถูกลืมไปนานก่อนที่พวกเขาจะได้ทำงานกับมัน

จากแนวคิดสองข้อนี้ฉันขอแนะนำให้แบ่งฐานรหัสออกเป็นหน่วยและผู้เรียนเป็นกลุ่มสองคน สำหรับรหัสแต่ละหน่วยแต่ละกลุ่มจะใช้เวลา 25 นาที (ขึ้นอยู่กับLOCของหลักสูตร) ​​เพื่อให้สามารถใช้เวลา 5-10 นาทีในการบอกรหัสแก่คนอื่น ๆ คำถามสามนาทีแล้วทำซ้ำกับบทต่อไป อธิบายเป็นคำสำคัญ; พวกเขาต้องทำให้แน่ใจว่าคนอื่น ๆ เข้าใจมันทั้งหมด

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

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

ขออภัยถ้าคุณได้ลองแล้ว ...


1

คุณเคยลองทำบทเรียนที่คนดูเป็นรายบุคคลหรือไม่?

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

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

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


13
Nooo ....... ไม่ใช่วิดีโอ ..... "Death By Powerpoint" ถูกแทนที่ด้วยชะตากรรมที่เลวร้ายยิ่ง ...... ถึงแม้ว่ามันจะมีผลที่ต้องการในการหยุดคำถาม - ขู่พวกเขาด้วย วิดีโอเพิ่มเติมที่ใช้เวลา 10 นาทีเพื่ออธิบายสิ่งที่สามารถอ่านได้ใน 30 และเข้าใจในไม่กี่วินาที ....
mattnz

6
+1 mattnz ปัญหาการสื่อสารไม่น่าจะได้รับการปรับปรุงด้วยการโต้ตอบทางเดียว
Michael Durrant

1
ฉันไม่ต้องการที่จะหยุดชั่วคราวแม้ว่าฉันจะอยู่ในวิดีโอ! รูปแบบวิดีโอ / ตัวแปลงสัญญาณใดที่ปิดใช้งานการหยุดชั่วคราว :) :) :)
Kaz

1

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

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

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