คุณจัดการการกระโดดที่ซับซ้อนได้อย่างไร


13

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

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

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

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

แก้ไข: คำตอบของ Crazy Eddie รวมถึง "คุณดูดมันและหาวิธีที่แพงที่สุดในการใช้ความซับซ้อนใหม่" นั่นทำให้ฉันคิดถึงบางสิ่งที่แฝงอยู่ในคำถาม แต่ฉันไม่ได้เจาะจงเฉพาะ

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

คำตอบ:


8

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

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


6

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

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

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

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

แนวคิดบางประการเกี่ยวกับวิธีรับมือกับสิ่งเหล่านี้นอกเหนือจากคำตอบอื่น ๆ ที่กล่าวถึงแล้ว:

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

ฉันเดาว่าฉันสามารถไปเรื่อย ๆ วิชาที่น่าสนใจมาก :)


ดู (หรือการศึกษา) ชีววิทยาหรือสังคมวิทยาว่าระบบที่ซับซ้อนทำงานอย่างไร - C'mon คำตอบที่เหลือของคุณนั้นมั่นคง แต่นี่มีแอปพลิเคชันต่อพ่วงที่มีปัญหาที่อธิบายไว้
จิมจี

1
@Jim G. อาจจะ ชีววิทยาจะไม่ช่วยเพิ่มประสิทธิภาพสำหรับลูปของคุณ แต่ถ้าคุณต้องการหามุมมองใหม่ข้อมูลเชิงลึกหรือนามธรรมที่มีประสิทธิภาพ (ในการพัฒนาซอฟต์แวร์) มันจะช่วยให้ก้าวออกจากกล่องทรายของตัวเอง การพิสูจน์ว่าชีววิทยา (หรือสังคมวิทยา) ไม่มีส่วนเกี่ยวข้องกับการเขียนโปรแกรม แต่มีเพียงไม่กี่อย่างที่จะต้องพิจารณาว่าOOPหรือรูปแบบการออกแบบไม่มีส่วนเกี่ยวข้องกับการเขียนโปรแกรม ตัวอย่างเช่น: OOP : ชีววิทยา -> Alan Kay -> OOP / Smalltalk หรือรูปแบบการออกแบบ : สังคมวิทยา -> การออกแบบชุมชนเมือง -> Christopher Alexander -> ภาษารูปแบบ -> รูปแบบการออกแบบ
Maglob

@Jim G. ต่อ คำพูดบางอย่าง Alan Kay: "ฉันคิดว่าวัตถุเป็นเหมือนเซลล์ชีวภาพและ / หรือคอมพิวเตอร์แต่ละเครื่องในเครือข่ายสามารถสื่อสารกับข้อความเท่านั้น" และ Wikipedia: "[รูปแบบการออกแบบ] แนวคิดนี้ได้รับการแนะนำโดยสถาปนิก Christopher Alexander ใน สาขาสถาปัตยกรรม [1] และได้รับการปรับให้เหมาะกับสาขาวิชาอื่น ๆ รวมถึงวิทยาการคอมพิวเตอร์ "
Maglob

Alright ฉันให้ +1 กับคุณเพื่อพยายามเต็มที่เพื่อหลีกเลี่ยงสถานะที่ไม่แน่นอนและนักเก็ตอื่น ๆ ประเด็นของฉันคือถ้าผู้จัดการของคุณมอบหมายให้คุณลดความซับซ้อนคุณจะต้องนำมีดโกนของ Occam ไปใช้กับปัญหาและไปทำงาน ฉันไม่คิดว่าคุณหรือคนอื่นจะ "มองหาชีววิทยา" เพื่อขอความช่วยเหลือในปัญหาที่เกิดขึ้นทันที
Jim G.

2

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

คำถามของ OP เป็นคำถามที่ดีและพูดถึงปัญหาที่ร้านค้าพัฒนาซอฟต์แวร์หลายแห่งมี

นี่คือวิธีที่ฉันจะจัดการกับปัญหา:

  1. ปฏิบัติตามคำแนะนำของเฟร็ดบรูกส์และการจัดระเบียบนักพัฒนาของคุณเช่นทีมผ่าตัด
  2. เลือกศัลยแพทย์ผู้เชี่ยวชาญที่ชาญฉลาดและ“ ใจดี” ที่สามารถทั้งคู่: ก) สะสมความไว้วางใจและความเคารพจากเพื่อนร่วมงานของเขา / เธอ; และ B) การตัดสินใจที่ยากลำบากในเวลาที่เหมาะสม
  3. คาดหวังว่าศัลยแพทย์หลักจะลดความซับซ้อนที่ส่วนหน้าและส่วนท้ายของกระบวนการพัฒนา

เพิ่มเติมเกี่ยวกับจุด # 3:

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

IMHO ในกรณีของ OP พวกเขาควรจะเริ่มทดสอบก่อนหน้านี้เพื่อเปิดเผยว่าสถาปัตยกรรมของพวกเขาทำงานอย่างไรภายใต้สถานการณ์ในชีวิตจริง Btw โดยบอกจะมี "ต้นแบบศัลยแพทย์" คุณดูเหมือนจะพื้นบ่งบอกว่ามีเป็นคนที่สามารถล่วงรู้ความเสี่ยงทางด้านเทคนิคของโครงการ - จุดที่แน่นอนคุณอ้างว่าไม่เห็นด้วยกับ
PéterTörök

@ PéterTörök: ... โดยการแนะนำให้มี "ศัลยแพทย์ตกแต่ง" คุณดูเหมือนจะบอกเป็นนัยว่ามีคนที่สามารถคาดการณ์ความเสี่ยงทางเทคนิคของโครงการ : ไม่ฉันไม่ได้ ฉันกำลังบอกว่าคนเหล่านี้มีทั้ง: A) เหมาะสมที่สุดในการหลีกเลี่ยงความซับซ้อนในตอนแรก; และ B) เหมาะสมที่สุดในการขุดทีมออกจากความซับซ้อนหลังจากที่รหัสจัดส่งแล้ว
จิมจี

IMHO เรากำลังพูดถึงสิ่งเดียวกัน ประสบการณ์ที่ช่วยให้ "ศัลยแพทย์ผู้เชี่ยวชาญ" ของคุณเลือกโซลูชันที่ง่ายที่สุดซึ่งอาจเป็นไปได้นั้นถูกสร้างขึ้นจากความทรงจำของโครงการและโซลูชั่นที่ผ่านมาและการรู้ว่าโซลูชันใดที่ทำงานได้ (หรือไม่ได้) ในกรณีเฉพาะ กล่าวอีกนัยหนึ่งเขามองหาวิธีการแก้ไขปัญหาที่เฉพาะเจาะจงและประเมินผลประโยชน์และความเสี่ยงที่อาจเกิดขึ้น นี่คือสิ่งที่จะช่วยให้เขา / เธอเลือกหนึ่งที่เหมาะสมสำหรับสถานการณ์ปัจจุบันจึงหลีกเลี่ยงเส้นทางที่มีความเสี่ยงสูง
PéterTörök

1
สิ่งนี้ทำให้ฉันนึกถึงคำพูดจากผู้ฝึกม้าที่ยอดเยี่ยม Ray Hunt: "คุณจะได้รับการตัดสินที่ดีได้อย่างไรประสบการณ์คุณจะได้รับประสบการณ์ได้อย่างไร? การตัดสินที่ไม่ดี"
ลนนาตรอน

1

รหัสไปยังส่วนต่อประสาน

เมื่อเขียนฟังก์ชันใหม่ที่เชื่อมต่อกับฟังก์ชันอื่น ๆ ให้สร้างขอบเขตในรูปแบบของอินเทอร์เฟซ (ชนิด Java) ที่ผ่านทั้งหมด นี่จะ

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

0

หนึ่งสามารถเริ่มต้นด้วยหลักฐานที่เรียบง่ายและรูปแบบและทันใดนั้นมีการเพิ่มความซับซ้อนในการพัฒนาโครงการ

ไม่น่าแปลกใจ

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

มีพื้นตรงกลางเล็กน้อย

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

วิธีจัดการสิ่งนี้?

  1. มีความคาดหวังที่สมจริง คุณกำลังคิดค้นสิ่งใหม่ มีต้องเป็นชิ้นส่วนที่คุณไม่เข้าใจ

  2. มีความคาดหวังที่สมจริง หากดูเหมือนว่าจะทำงานได้ดีในครั้งแรกคุณมองข้ามบางสิ่งบางอย่าง

  3. มีความคาดหวังที่สมจริง ถ้ามันง่ายคนอื่นจะทำมันก่อนและคุณก็สามารถดาวน์โหลดโซลูชันนั้นได้

  4. มีความคาดหวังที่สมจริง คุณไม่สามารถทำนายอนาคตได้เป็นอย่างดี


2
รอดังนั้นสิ่งที่คุณพูดคือ: มีความคาดหวังที่สมจริง?
ล็นทรอน

0

การออกแบบและรหัสด้วยความล้าสมัยในใจ สมมติว่าสิ่งที่คุณรหัสในวันนี้จะต้องถูกตัดออกและแทนที่ในวันพรุ่งนี้


0

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


0

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

อย่างไรก็ตามมีโฮสต์ของปัจจัยเฉพาะที่อาจเข้ามาเล่นที่นี่เช่น:

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

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

  • เป้าหมายของทีม มันเป็นมากกว่า "ทำตอนนี้ที่ค่าใช้จ่ายใด ๆ " หรือ "ขอทำมัน" สิ่งที่ชนิด?

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

  • ความเข้าใจปัญหาของคุณ เหตุใดโซลูชันก่อนหน้านี้จึงไม่ทำงาน

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

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

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