ความคิดและการออกแบบก่อนการเข้ารหัส: ความจริงเรื่องนี้มีเท่าใด? [ปิด]


14

ฉันเรียนที่โรงเรียนเช่นเดียวกับที่ฉันอ่านทุกที่ว่าวิธีการพัฒนาที่ดีต้องมีความคิดและการออกแบบก่อนที่จะเขียนโค้ดอย่างถูกต้อง

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

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

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



@ คาดลิงค์ที่คุณให้ไว้ที่นี่อาจเป็นคำตอบสำหรับคำถามของฉัน ฉันไม่คิดว่านี่เป็นคำถามที่ซ้ำกัน


13
ไม่มีแผนใดที่จะรอดชีวิตจากการสัมผัสกับศัตรู แต่นั่นไม่ได้หมายความว่าคุณไม่ควรมีมัน เริ่มต้นด้วยแผน แต่อย่ากลัวที่จะแก้ไขในภายหลัง
Richard Tingle

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

คำตอบ:


5

ฉันคิดว่าคำตอบต้องเป็น: วางแผนให้มากที่สุดเท่าที่จะทำได้ แต่ไม่มากไปกว่านั้น

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

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

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


30

มันเป็นเรื่องจริงอย่างแน่นอน ความต้องการที่ใหญ่และซับซ้อนมากขึ้นยิ่งเป็นจริง

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

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

มีตัวเลือกอื่น ๆ มากมายระหว่างสองขั้ว

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

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


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

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

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

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

แต่นี่เป็นเหตุผลว่าทำไมจึงเรียกว่านุ่ม -ware และไม่ยาก -ware มันอ่อนและสามารถเปลี่ยนแปลงได้


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

9

ฉันเรียนที่โรงเรียนเช่นเดียวกับที่ฉันอ่านทุกที่ว่าวิธีการพัฒนาที่ดีต้องมีความคิดและการออกแบบก่อนที่จะเขียนโค้ดอย่างถูกต้อง

นี่เป็นเรื่องจริง

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

และมีปัญหาของคุณ

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

ดังนั้นจึงเป็นจริงอย่างแน่นอนว่าคุณจะต้องดำเนินการออกแบบก่อนเวลา แต่มันก็ยังเป็นความจริงว่ามันเป็นไปไม่ได้เพียง แต่การออกแบบก่อนเวลา


5

คุณจะต้องมีการออกแบบบางอย่างก่อนที่จะเข้ารหัส

เหตุผลก็คือตรงไปตรงสวย - ถ้าคุณไม่ได้มีการออกแบบใด ๆ , คุณไม่ได้รู้ว่าสิ่งที่คุณกำลังทำ

คุณต้องมีรหัสบางอย่างก่อนที่การออกแบบจะถือเป็นที่สิ้นสุด

เหตุผลนั้นค่อนข้างตรงไปตรงมา - การออกแบบจะเปลี่ยนไปและการพัฒนาส่วนต่าง ๆ ของการออกแบบจะเปิดเผยคำถามโอกาสและความท้าทายที่คาดไม่ถึงโดยไม่ต้องเริ่มหาทางแก้ปัญหา

การพัฒนาซ้ำแล้วซ้ำอีก

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

ลองมากกว่าหนึ่งวิธี

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


1

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

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

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

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

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

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


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

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

การออกแบบ / รหัส: "ให้เบราว์เซอร์โฮสต์ตัวออกแบบ HTML พร้อมคุณสมบัติดังกล่าวและรหัสแบ็กเอนด์ใน Java เพื่อให้สามารถทำงานบนเซิร์ฟเวอร์ที่มีอยู่ใด ๆ กำหนดโครงสร้างข้อมูลและ UX สำหรับการสืบค้นหรือแก้ไขตามความจำเป็นแผนสำหรับการกู้คืนระบบ การรายงานการบันทึกการตรวจสอบการควบคุมเวอร์ชันแผนการควบคุมการเข้าถึงแผน; .... "- ยิ่งรายการที่ไม่สมจริงยิ่งขึ้นก็คือการคาดการณ์ทั้งหมด

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


0

ฉันมักจะจัดสรรเวลาดังนี้:

  1. 1/3 การออกแบบ
  2. 1/3 การพัฒนา
  3. 1/3 การทดสอบ

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

การพัฒนา: เมื่อคุณรู้ชิ้นส่วนแล้วให้เขียนโค้ด จากนั้นคุณรวมพวกเขา

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

นอกเหนือจากแง่มุมเหล่านี้โปรดทราบว่าโครงการยังมี 3 ขั้นตอนด้านบนของขั้นตอนเหล่านี้

  1. ความพยายามครั้งแรกภายใต้วิศวกรรม
  2. ความพยายามครั้งที่สองที่เกินความคาดหมายจากบทเรียนที่เรียนรู้จากความพยายามครั้งที่ 1
  3. ความพยายามครั้งที่ 3 ที่ออกแบบมาอย่างเหมาะสม

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

ฉันเป็นนักพัฒนาซอฟต์แวร์และผู้จัดการฝ่ายพัฒนาซอฟต์แวร์สำหรับโครงการพัฒนาภายในและภายนอก บริษัท


-1

มีสมมติฐานที่ไม่ถูกต้องที่นี่ คุณจะไม่สามารถออกแบบที่ดีโดยไม่ต้องเขียนโค้ดก่อน (โรงเรียนจะไม่สอนสิ่งนี้) กระนั้นโรงเรียนก็ถูกต้องที่คุณจะไม่ได้รหัสที่ดีถ้าขาดการออกแบบ

ทางออกคือ:

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

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

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


1
มีเหตุผลที่ถูกต้องมากมายที่จะไม่ทิ้งรหัสเก่า คุณช่วยกรุณาอ้างอิงบางส่วนเพื่อสำรองย่อหน้าสุดท้าย
mattnz

+1 ไม่ทราบว่าทำไมสิ่งนี้จึงถูกลดระดับลง "สร้างที่จะโยนทิ้ง" เป็นคำแนะนำคลาสสิกของ Fred Brooks
nikie

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

-3

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

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

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

จากนั้นเลือกสแต็กที่ดีที่สุด

ฉันเป็นผู้พัฒนา LAMP

ดังนั้นฉันมักจะ จำกัด คำถามกับกรอบ php ที่ฉันจะใช้ และสคริปต์ส่วนหน้าฉันจะต้องทำให้มันทำทุกสิ่งที่ฉันต้องการให้ทำในวิธีที่เหมาะ

เพื่อเพิ่มสิ่งนี้เรียนรู้การใช้กรอบ MVC, ZEND และ CAKEPHP เป็นกรอบการพัฒนาที่รวดเร็วที่สุด (PHP)


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