จะอธิบายได้อย่างไรว่าทำไมตัวเลือกการออกแบบถึงดี? [ปิด]


26

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

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

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


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

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

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

2
@DanielB ฉันคิดว่านั่นเป็นปัญหาฉันใช้อาร์กิวเมนต์ที่สองของคุณในการเลือกการออกแบบในอดีตและได้พบกับการตอบสนองของ "นั่นไม่ใช่ KISS" นักพัฒนาซอฟต์แวร์บางคนไม่ทราบว่าทำไมสิ่งที่คุณเพิ่งพูดถึงจึงดีกว่า
Jimmy Hoffa

1
การอ่านที่แนะนำ: ฉันจะอธิบาย $ {some} ถึง $ {someone} ได้อย่างไร - ริ้นตั้งแต่ต้น
rwong

คำตอบ:


41

สิ่งนี้อาจไม่ตอบคำถามของคุณโดยตรง แต่อาจนำคุณไปในทิศทางที่น่าสนใจ

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

สำหรับ CEO เวลาออกสู่ตลาดของคุณอาจเป็นกุญแจสำคัญสำหรับผู้จัดการของคุณมันอาจเป็นตารางเวลาที่คาดการณ์ได้มากขึ้นสำหรับเพื่อนร่วมงานการเขียนโปรแกรมของคุณมันอาจจะเข้ารหัสได้เร็วขึ้น (หรือทดสอบได้ง่ายขึ้น / เอกสาร / debugging อาจจะ ... ?

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


5

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

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

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

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

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

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

4

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

ถ้ามันเป็นสิ่งที่ประกอบขึ้นมาจากการสืบทอดคุณอาจจะต้องบอกว่าในปัจจุบันบางที 90% ของนักพัฒนาจะคิดว่าวิธีปฏิบัติที่ดีที่สุด (การคาดเดาที่ดีขึ้นอยู่กับความจริงที่ว่า 100% ของนักพัฒนาเห็นด้วย เห็นด้วยและยินดีที่จะเข้าไปสู่สาเหตุ

ฉันพยายามที่จะซื่อสัตย์เท่าที่ฉันสามารถเกี่ยวกับสิ่งที่ขัดแย้งและร้อยละของนักพัฒนาจะเห็นด้วยกับฉัน

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

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

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


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

@Telastyn - ฉันคิดว่ามีห้องพักสำหรับ "คนที่ได้รับการศึกษาดีกว่าที่จะทำงานร่วมกับ" คำตอบ :)
PSR

3

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

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

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

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


0

ขึ้นอยู่กับผู้ชม! ในฐานะนักพัฒนาเราได้พัฒนาปรีชาสำหรับรหัสที่ดีและไม่ดีและใช้เงื่อนไขทางอารมณ์ที่คลุมเครือเช่น "โค๊ดกลิ่น", "โค้ดน่าเกลียด", "วิธีแก้ปัญหาที่สวยงาม" ใช้งานได้เมื่อสื่อสารกับผู้พัฒนารายอื่นด้วยความคิดเดียวกัน พยายามอธิบาย CEO ที่ไม่ใช่ด้านเทคนิคของคุณว่าคุณควรลงทุน x ชั่วโมงทำงานในการสร้างรหัส "สวยกว่า" คุณจะล้มเหลวอย่างงดงาม

คุณต้องสามารถสร้างกรณีที่การปรับปรุงการออกแบบใด ๆ ก็ตาม

  • ประหยัดเงินให้กับ บริษัท
  • ทำเงินให้กับ บริษัท

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

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