จะทำอย่างไรเมื่อคุณเผชิญกับงานเขียนโปรแกรมที่คุณไม่เคยทำ?

ฉันเริ่มต้นอาชีพด้วยการเป็นนักพัฒนา. NET 3 เดือนที่ผ่านมาและหลังจากแผนการฝึกอบรมที่ยาวนานเกี่ยวกับเทคโนโลยีที่หลากหลายรูปแบบและแนวคิดที่นักพัฒนาที่ดูแลฉันได้ตัดสินใจว่าฉันพร้อมที่จะเข้าร่วมหนึ่งในหลาย ๆ โครงการที่ บริษัท จัดการ

ฉันตื่นเต้นมากที่ในที่สุดสามารถเริ่มการเข้ารหัสได้ ทีมที่ฉันเข้าร่วมนั้นค่อนข้างเล็กเพราะตอนนี้เริ่มต้นด้วยโครงการใหม่ซึ่งดีมากเพราะฉันได้มีส่วนร่วมในวงจรชีวิตทั้งหมดของโครงการ มันเป็นโครงการสปาบนเว็บที่ได้รับการสนับสนุนที่ใช้ ASP.NET MVC / ASP.NET Web API และ Front-end เฟรมเวิร์ก Durandal และไลบรารีที่เกี่ยวข้อง

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

ฉันไม่เคยทำงานที่สร้างขึ้นมาก่อนและฉันไม่รู้ว่าฉันควรดำเนินการอย่างไร

ตัวอย่างหนึ่งในภารกิจที่สร้างขึ้นคือการสร้างกลไกการจัดการข้อผิดพลาดทั่วไปสำหรับแอปพลิเคชันทั้งหมด

ปกติแล้วจะดำเนินการอย่างไรเมื่อเผชิญกับงานที่เขาไม่เคยทำ?

มีหลายสิ่งที่คุณสามารถทำได้และควรทำเพื่อเตรียมงาน:

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

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

นี่คือเหตุผลที่ฉันเป็นวิศวกร ฉันชอบที่จะคิดออกสิ่งใหม่

ไม่หยุดเรียนรู้สิ่งใหม่ ๆ การเรียนรู้คือสิ่งที่ทำให้คุณดีขึ้น

ไม่มีวิธีแก้ปัญหาที่สมบูรณ์แบบ แต่บางสิ่งที่อาจช่วยได้:

• แบ่งงานออกเป็นหน่วยที่เล็กที่สุดเท่าที่จะทำได้ - แยกงานเหล่านั้นออกจนกว่าคุณจะมีสิ่งที่คุณสามารถทำได้

• แจ้งงานหรือปัญหาที่เกิดขึ้นทันทีเพื่อให้แน่ใจว่าคุณเข้าใจจริงๆ จากนั้นทำการวิเคราะห์และทำซ้ำ

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

• ขอความช่วยเหลือในการเลือกงานที่ถูกต้องและวิธีการในการเริ่มต้น

• หาที่ปรึกษาที่สามารถให้คำติชมคงที่ (ทุกวัน) เป็นเวลาหนึ่งหรือสองสัปดาห์

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

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

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

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

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

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

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

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

=================

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

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

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

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

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

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

มันเป็นเรื่องตลกเก่าแก่เกี่ยวกับแพทย์ที่ยังคง "ฝึกฝน" ยา พวกเขาไม่มีคำตอบทั้งหมดเช่นกัน

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

กระบวนการส่วนตัวของฉันเป็นอะไรแบบนี้:

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

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