ทำตามเส้นทางของสิ่งที่ฉันรู้จากนั้นลองใช้วิธีการเข้ารหัสที่ถูกต้องหรือเริ่มต้นด้วยวิธีการเข้ารหัสที่ดีและพยายามฝืนวิธีของฉันผ่าน?

ก่อนอื่นฉันอยากจะบอกว่าฉันคุ้นเคยกับการทำ Programming Processural เป็นงานอดิเรกของฉัน - ฉันพยายามเรียนรู้ OOP ในสองภาษาและเข้าใจทฤษฎีไม่ใช่แค่การฝึกฝน

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

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

ฉันตัดสินใจส่วนใหญ่เป็นหลักฐานพิสูจน์แนวคิดในการสร้างแอปในโปรแกรมอื่น (Microsoft Access) และบรรลุเป้าหมายหลักของฉันในเวลาเพียงไม่กี่ชั่วโมง - ยกเว้นส่วนของเว็บ

คำถามของฉันคือฉันควรทำตามเส้นทางของสิ่งที่ฉันรู้จากนั้นลองใช้วิธีการเข้ารหัสที่ถูกต้องหรือฉันควรเริ่มต้นด้วยวิธีการเข้ารหัสที่ดีและพยายามฝืนวิธีของฉันผ่าน? สำหรับโครงการนี้ฉันอยากให้เป็น Open Sourced บน GitHub ดังนั้นฉันจะเปิดให้คนอื่นที่ใช้และเปลี่ยนรหัสของฉัน แต่ฉันก็รู้ว่าถ้าเขียนรหัสไม่ดีมันก็ยากที่จะรวบรวม coders มาช่วย

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

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

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

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

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

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

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

โชคดี

TL; DR

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

และตอนนี้คำตอบยาว ...

1. "ซอฟต์แวร์ที่ใช้งานเป็นมาตรการหลักของความคืบหน้า" ( ประกาศเปรียว )

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

สร้างบางสิ่งบางอย่าง

2. เรียนรู้และทำผิดพลาด แต่อย่าทำสิ่งที่ "ไม่ดี" *

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

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

หากคุณสร้าง CLI เพียงเล็กน้อยสำหรับตัวคุณเอง : ใช้งานได้ตามที่คุณต้องการ

หากคุณเขียนเว็บพอร์ทัลของธนาคาร: Surround ตัวเองด้วยมากพัฒนาที่มีประสบการณ์

3. "แนวปฏิบัติที่ดีที่สุด" ควรเขียนด้วยคำพูดและพูดด้วยวิ้ง

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

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

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

อืม ...

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

เรียกใช้POAP ! ^{(ใช่บล็อกของฉัน)}

หลักการรูปแบบและการปฏิบัติไม่ใช่จุดประสงค์สุดท้าย

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

(POAP ไม่ได้รับการยกเว้นจาก POAP)

ตัวอย่างเช่นคุณอาจไม่เข้าใจความแตกต่างเล็กน้อยของ DI ทุกประการ แต่ถ้าคุณเข้าใจเจตนาคุณจะรู้ว่าถ้าคุณ "ควร" ใช้ DI และคุณจะเข้าใจ DI โดยปริยายมากขึ้น

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

การอ่านโบนัส / ค่อนข้างเกี่ยวข้อง:

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

คุณอาจจะรู้สึกเหมือน coder

^{* จริง ๆ แล้วคุณจะทำผิดพลาดถ้าคุณทำอะไรที่สำคัญ แต่คุณเป็นมนุษย์ฉันคิดเอาเอง ดังนั้นเราให้อภัยคุณล่วงหน้า ... หรืออย่างน้อยฉันก็ทำ อาจจะ. ... อืม ... เราจะเห็น}

คำถามของฉันคือฉันควรทำตามเส้นทางของสิ่งที่ฉันรู้จากนั้นลองใช้วิธีการเข้ารหัสที่ถูกต้องหรือฉันควรเริ่มต้นด้วยวิธีการเข้ารหัสที่ดีและพยายามฝืนวิธีของฉันผ่าน?

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

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

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

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

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

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

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

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

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

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

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

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

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

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