ช่วงพักดื่มกาแฟ #13: สิ่งที่มือใหม่หัดเขียนโปรแกรมควรรู้ 4 วิธีในการรวมแนวคิดการออกแบบเข้ากับกระบวนการพัฒนาของคุณ

สิ่งที่มือใหม่หัดเขียนโปรแกรมควรรู้

ที่มา: Stackoverflow ในฐานะนักพัฒนา คุณจะได้ยินทฤษฎีต่างๆ มากมายเกี่ยวกับลักษณะของโค้ดที่ควรจะเป็น บางคนเชื่อว่ายิ่งโค้ดในแอปพลิเคชันมีบรรทัดน้อยเท่าใดก็ยิ่งอ่านได้ง่ายขึ้นเท่านั้น แต่นี่เป็นความจริงเพียงบางส่วนเท่านั้น ฉันต้องการประเมินคุณภาพโค้ดโดยใช้เกณฑ์ต่อไปนี้:

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

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

การอ่านโค้ดของคนอื่นเป็นเรื่องยาก

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

คุณจะไม่มีวันเขียนโค้ดที่ "สมบูรณ์แบบ"

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

คุณไม่ควรเขียนโค้ดวันละ 8 ชั่วโมง

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

• การเรียนรู้เครื่องมือ ฟังก์ชัน แอปพลิเคชันใหม่ๆ
• หารือเกี่ยวกับกระบวนการทำงานกับเพื่อนร่วมงาน
• ช่วยเหลือเพื่อนร่วมงานที่ประสบปัญหาในการทำงาน
• การวางแผนงาน
• การวิเคราะห์โค้ด
• การประชุมทางธุรกิจ/การประชุม

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

4 วิธีในการรวมแนวคิดการออกแบบเข้ากับกระบวนการพัฒนาของคุณ

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

1. มีส่วนร่วมตั้งแต่เริ่มต้น

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

2. เรียนรู้กระบวนการ UX

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

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

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

3. ติดตามการพัฒนาการออกแบบ

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

4. ตกลงว่าโครงการจะแสดงให้คุณเห็นในขั้นตอนใด

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