ฉันสามารถเขียนรหัส ... แต่ไม่สามารถออกแบบได้ดี ข้อเสนอแนะใด ๆ [ปิด]


83

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

ฉันคิดว่าโรงเรียนและวิทยาลัยทำงานได้ดีในการสอนผู้คนถึงวิธีการแก้ปัญหาทางคณิตศาสตร์ได้ดี แต่ขอยอมรับความจริงที่ว่าแอปพลิเคชันส่วนใหญ่ที่สร้างขึ้นที่โรงเรียนมักมีความยาวประมาณ 1,000 - 2,000 บรรทัดซึ่งหมายความว่าส่วนใหญ่เป็นการฝึกหัดทางวิชาการ ซึ่งไม่ได้สะท้อนความซับซ้อนของซอฟต์แวร์ในโลกแห่งความเป็นจริงโดยเรียงตามบรรทัดโค้ดสองสามแสนถึงล้าน

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

ดังนั้นคำถามของฉันคือฉันจะพัฒนาทักษะการออกแบบได้อย่างไร นั่นคือความสามารถในการออกแบบแอพพลิเคชั่นขนาดเล็ก / ขนาดกลางที่จะเข้าไปในโค้ดสองสามพันบรรทัด? ฉันจะเรียนรู้ทักษะการออกแบบที่จะช่วยให้ฉันสร้างชุดแก้ไข html ที่ดีขึ้นได้อย่างไรหรือโปรแกรมกราฟิกบางอย่างเช่น gimp


1
"ให้ยอมรับความจริงที่ว่าแอปพลิเคชันส่วนใหญ่ที่สร้างขึ้นที่โรงเรียนโดยทั่วไปจะมีความยาวประมาณ 1,000 - 2,000 บรรทัดซึ่งหมายความว่าส่วนใหญ่เป็นการฝึกหัดทางวิชาการที่ไม่สะท้อนความซับซ้อนของซอฟต์แวร์โลกแห่งความจริง": ตอนที่ฉันสอนอยู่ โครงการซอฟต์แวร์ภาคการศึกษาที่ทีมของนักเรียนสิบคนพัฒนาแอพพลิเคชั่นที่ค่อนข้างซับซ้อนในช่วง 6 ถึง 8 เดือน นอกจากนี้หลาย บริษัท (อย่างน้อยในประเทศเยอรมนี) เสนอสัญญาระยะสั้นสำหรับนักเรียนที่ต้องการฝึกฝนก่อนที่จะจบการศึกษา
Giorgio

คำตอบ:


87

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

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

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

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

2
+1 คำตอบที่ดี แต่ฉันพบว่ามันค่อนข้างไม่สมบูรณ์ ฉันเชื่อว่าการมีส่วนร่วมที่สำคัญที่สุดคือการมีความอยากอาหารที่ดีมากสำหรับการปรับโครงสร้างใหม่ เขียนดูที่ทฤษฎีพูด (บทความหนังสือหรือที่ปรึกษา) refactor / rewrite กลับไปที่ทฤษฎี refactor / rewrite - นี่จะทำให้คุณมีเวลาในการมุ่งเน้นที่โครงสร้างขณะทำงานกับโค้ดที่คุ้นเคย เป็นนักวิจารณ์ที่เลวร้ายที่สุดของคุณเอง ฉันก็จะบอกว่ามันเป็นสิ่งสำคัญมากที่คุณไม่เคยสูญเสียความอยากอาหารนี้มาตลอดเพื่อทบทวนการทำงานของคุณเอง
vski

1
@ vski มีแนวคิดมากมายที่ฉันสามารถรวมไว้ได้ แต่คำถามก็คือแนวคิดเหล่านั้นจะเป็นตัวกำหนดเส้นทางที่สมเหตุสมผลในการรับประสบการณ์ที่จำเป็นสำหรับ OP หรือไม่เพื่อพิจารณาว่าเขาเป็นนักออกแบบที่ดีขึ้นหรือไม่ ในขอบเขตของคำตอบของฉันฉันเห็น refactoring เป็นการปฏิบัติ (ตามจุดที่สองของฉัน) ดังนั้นก็คือการฝึกทำความสะอาดรหัสทดสอบครั้งแรก BDD และแนวคิดอื่น ๆ อีกมากมาย ฉันใช้วิธีการที่มีทักษะและประสบการณ์มากมายที่จำเป็นเพื่อพัฒนาจนถึงจุดที่ทักษะการออกแบบจะเกิดขึ้นและเติบโตด้วยประสบการณ์และความรู้ที่ได้รับเมื่อเวลาผ่านไป :)
S.Robins

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

2
"เคยลองแล้วเคยล้มเหลวไม่ว่าลองอีกครั้งล้มเหลวอีกครั้งล้มเหลวได้ดีกว่า" --- ซามูเอล Beckett
ปีเตอร์เค

16

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

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

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

ตอนนี้ฉันทำผิดพลาดใหม่และเรียนรู้จากสิ่งเก่า


10
มีจุดที่ดีที่นี่มีมูลค่าการโทรออก: ทำผิดพลาดใหม่ ๆ ; อย่าทำผิดพลาดเดิมต่อไป - เรียนรู้จากพวกเขาและทำสิ่งใหม่
Bevan

11

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


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

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

ฉันคิดว่าอาจเป็นกรณีนี้ แต่ฉันรู้สึกว่ามันอาจคุ้มค่าที่จะเพิ่มความหมายที่ว่า "การออกแบบล่วงหน้าใด ๆ " จะเลวร้ายยิ่งกว่าสิ่งที่เกิดขึ้นอย่างหมดจด ฉันเห็นด้วยอย่างไรก็ตามวิธีการสร้างประสบการณ์ที่จำเป็น OP กำลังมองหาคือการกังวลน้อยลงในการเริ่มต้นเกี่ยวกับการออกแบบและมุ่งเน้นไปที่การเขียนโค้ดที่ดีและทำความสะอาดแทน :-)
S.Robins

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

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

7

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

ดูhttp://sourcemaking.com/antipatterns/software-development-antipatternsตัวอย่างเช่น

เขียนรหัสเพื่อให้สามารถปรับเปลี่ยนได้อย่างรวดเร็วหากมีการเปลี่ยนแปลงข้อกำหนด (ซึ่งเป็นเรื่องปกติในสภาพแวดล้อมการผลิต)

สงสัยอย่างยิ่งเกี่ยวกับการเพิ่ม "แฮ็คเล็ก ๆ น้อย ๆ เพียงหนึ่งเดียว" อีกหนึ่งที่นี่อีกหนึ่งที่นั่นและรหัสจะกลายเป็นไร้การเปลี่ยนแปลง

ราคาเปิด / ปิดหลักการ

ทดสอบการเขียน (เช่นเดียวกับใน TDD) พวกเขาบังคับให้คุณคิดถึงการออกแบบของคุณก่อนที่คุณจะนำไปใช้จริง

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


4

หลักการหนึ่งที่ฉันพบว่าสำคัญมากสำหรับการออกแบบที่ดีคือการสลายตัว: หากคลาสมีขนาดใหญ่เกินไป (มากกว่า, พูด, โค้ด 300-400 บรรทัด) จะแบ่งออกเป็นคลาสย่อย หากวิธีการมีขนาดใหญ่เกินไป (พูดมากกว่า 50 บรรทัดของรหัส) สลายตัวมัน; ถ้าโครงการมีมากกว่า 50 คลาสให้ย่อยสลาย

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


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

1
@ jer: มันเป็นกฎของหัวแม่มือแน่นอน วิธีการที่เรียก 100 วิธีอื่นคืออย่างที่คุณบอกเพียงแค่การต่อสิ่งต่าง ๆ เข้าด้วยกัน (มันคือการเรียกรายการฟังก์ชั่นย่อย) ฉันคิดเกี่ยวกับวิธีการที่มีตรรกะจริงมากกว่าปกติแล้วมันเป็นสัญญาณที่ไม่ดีถ้าคุณต้องเลื่อนไปมาบ่อยๆเพื่อทำความเข้าใจว่าวิธีการใดที่ทำอยู่ สิ่งเดียวกันถ้าคุณดูคำจำกัดความของคลาสที่มีสมาชิกจำนวนมาก (และคลาสไม่ได้เป็นเพียงแค่กลุ่มของคุณสมบัติขนาดใหญ่)
Giorgio

"โครงการมีมากกว่า 50 คลาสย่อยสลาย" ไม่ร้ายแรง
ไดนามิก

@ yes123: มันมีความหมายที่จะให้ความคิด มันขึ้นอยู่กับสิ่งที่คุณกำลังพัฒนาในภาษาอื่น ๆ
Giorgio

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

0

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

"ดีกว่า"

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

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

และ "ความสุข"

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


-1

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

คุณสามารถค้นหาโครงการโอเพนซอร์ซจำนวนมากเพื่อการวิจัย

อย่างไรก็ตามคุณต้องฝึกฝน


-1

อย่าอยู่ในความหวาดกลัว

มุ่งมั่นเพื่อความเรียบง่าย

ฟังผู้ใช้ของคุณ

ลองไอเดียมากมาย

สร้างบางสิ่งบางอย่างแล้วทำให้ดีขึ้น

ทำงานในสิ่งที่เพิ่มมูลค่าทิ้งสิ่งที่ไม่ทำ


-1

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

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