ฉันมีความคิดที่ผิดเกี่ยวกับวิศวกรรมซอฟต์แวร์หรือไม่? [ปิด]

ฉันมีคำถามที่ถูกยกขึ้นโดยงานล่าสุดของฉัน (ค่อนข้างฝึกงาน)

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

สิ่งที่ฉันต้องทำคือสร้างเครื่องมือภายในบางอย่างโดยใช้การผสมผสานของเทคโนโลยี - ส่วนใหญ่คือ AWS / Java / Bash - คุณจะได้ภาพ ทุกอย่างโอเคฉันทำงานของฉัน แต่ฉันไม่มีความสุข ทำไม - เพราะฉันคาดว่าจะทำงานในเรื่องโฆษณา นั่นคือการสร้างสิ่งต่าง ๆ ได้อย่างรวดเร็วโดยไม่ต้องใช้เวลาในการออกแบบ ผู้จัดการของฉันบอกอย่างชัดเจนว่ามันคาดว่าจะ "เร่งด่วน" ผ่านปัญหาที่เกิดขึ้นและพวกเราก็สำคัญ ผลก็คือปรากฎว่าสิ่งที่จะต้องทำใหม่และวิศวกรอีกครั้งและพวกเขายังไม่สมบูรณ์ เท่าที่เกี่ยวข้องกับการทดสอบ - ให้น้อยที่สุดตราบใดที่มันดูเหมือนว่าทำงานแล้วมันก็โอเค

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

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

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

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

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

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

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

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

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

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

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

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

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

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

หากการเพิ่มขึ้นดังกล่าวเกิดขึ้นหลักฐานของผลลัพธ์สุทธิจะอยู่เล็กน้อย

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

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

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

หากคุณสามารถผลิตแอปพลิเคชันใน 3 ชั่วโมง (หรือวัน) ที่ทำในสิ่งที่มันควรทำทำไมต้องใช้เวลามากขึ้นในการออกแบบล่วงหน้า คุณแค่เสียเงิน การเสียเงินเป็นเรื่องปกติไม่ใช่ Good Idea ™

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

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

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

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

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

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

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

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

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

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

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

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

สิ่งที่ฉันหมายถึงโดยที่คุณพูดว่า:

“ สิ่งที่ฉันต้องทำคือสร้างเครื่องมือภายในโดยใช้เทคโนโลยีที่ผสมผสานกันส่วนใหญ่คือ AWS / Java / Bash”

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

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

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

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

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

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

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

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

แม้ว่ามันจะมีความสำคัญต่อการวิจัย แต่ก็เป็นสิ่งสำคัญเช่นกัน หากคุณไม่ได้ส่งมอบสิ่งที่ดีจริงๆคุณ? Duct Tape โปรแกรมเมอร์จะเป็นตัวอย่างของการทำสิ่งต่าง ๆ ที่นี่

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

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

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

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