วิศวกรรมซอฟต์แวร์

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

103 skills 

อะไรคือความแตกต่างที่สำคัญระหว่างวิศวกรซอฟต์แวร์และโปรแกรมเมอร์?

103 skills 

ฉันเข้าใจถึงคุณค่าของการทดสอบอัตโนมัติและใช้งานได้ทุกที่ที่ปัญหามีการระบุไว้อย่างดีพอที่จะทำให้เกิดกรณีทดสอบที่ดี ฉันสังเกตเห็นว่าบางคนที่นี่และใน StackOverflow เน้นการทดสอบเพียงหน่วยเดียวไม่ใช่การพึ่งพา ที่นี่ฉันไม่เห็นประโยชน์ การเยาะเย้ย / การขัดถูเพื่อหลีกเลี่ยงการทดสอบการพึ่งพาเพิ่มความซับซ้อนให้กับการทดสอบ มันเพิ่มความยืดหยุ่นในการประดิษฐ์ / การแยกชิ้นส่วนข้อกำหนดในรหัสการผลิตของคุณเพื่อรองรับการเยาะเย้ย (ฉันไม่เห็นด้วยกับใครก็ตามที่บอกว่าสิ่งนี้ส่งเสริมการออกแบบที่ดีเขียนโค้ดพิเศษแนะนำสิ่งต่าง ๆ เช่นกรอบการฉีดพึ่งพาหรือเพิ่มความซับซ้อนให้กับโค้ดเบสของคุณเพื่อให้สิ่งที่ยืดหยุ่น / pluggable / extensible / decoupled การออกแบบที่ดี.) ประการที่สองการทดสอบการพึ่งพาหมายความว่ารหัสระดับต่ำที่สำคัญที่ใช้ในทุกที่ได้รับการทดสอบด้วยอินพุตนอกเหนือจากที่ผู้เขียนการทดสอบคิดอย่างชัดเจน ฉันได้พบข้อบกพร่องมากมายในการทำงานระดับต่ำโดยใช้การทดสอบหน่วยในการทำงานระดับสูงโดยไม่ต้องเยาะเย้ยการทำงานระดับต่ำที่มันขึ้นอยู่กับ โดยหลักการแล้วสิ่งเหล่านี้จะถูกค้นพบโดยการทดสอบหน่วยสำหรับฟังก์ชั่นระดับต่ำ แต่กรณีพลาดมักเกิดขึ้นเสมอ ด้านนี้คืออะไร? เป็นสิ่งสำคัญจริง ๆ ที่การทดสอบหน่วยไม่ได้ทดสอบการพึ่งพาของมันด้วย? ถ้าเป็นเช่นนั้นทำไม แก้ไข: ฉันสามารถเข้าใจคุณค่าของการเยาะเย้ยการพึ่งพาภายนอกเช่นฐานข้อมูลเครือข่ายบริการเว็บ ฯลฯ (ขอบคุณ Anna Lear สำหรับการจูงใจให้ฉันชี้แจงสิ่งนี้) ฉันหมายถึงการพึ่งพาภายในเช่นคลาสอื่น ๆ ฟังก์ชั่นคงที่ ฯลฯ ที่ไม่มีการพึ่งพาภายนอกโดยตรง

103 testing  unit-testing  dependency-injection  mocking 

ฉันใช้การเขียนโปรแกรมเมตาจำนวนมากเพื่อหลีกเลี่ยงงานซ้ำ ๆ และสร้าง abstractions ที่ปลอดภัยต่อการใช้งาน ฉันเพิ่งย้ายไปทำงานใหม่ที่ฉันทำงานในทีมที่ใหญ่กว่าและสิ่งนี้ทำให้เพื่อนร่วมงานของฉันกังวลเพราะพวกเขาไม่เข้าใจ ฉันพยายามยกระดับความสามารถของภาษาอย่างเต็มที่ แต่เพื่อนร่วมงานของฉันบางคน (ไม่ใช่ทั้งหมด) เข้าใจว่าเป็นความเสี่ยง (บางคนยินดีต้อนรับวิธีการ) ฉันยอมรับว่ามันเป็นปัญหาในการเขียนโค้ดที่ไม่มีใครในทีมสามารถเข้าใจได้ ในทางกลับกันเราเป็นนักพัฒนา C ++ มืออาชีพและฉันคิดว่าเราควรจะมีมาตรฐานที่สูงกว่าการเขียน C ด้วยคลาส คำถามของฉันคือใครถูกต้องฉันควรทำอย่างไร การชี้แจง: การ พยายามยกระดับศักยภาพของภาษาอย่างเต็มที่ไม่ได้หมายความว่าฉันจะใช้ TMP ในทุกปัญหา C ++ เป็นกล่องเครื่องมือและสำหรับฉันความสามารถ C ++ นั้นเกี่ยวกับความสามารถในการใช้เครื่องมือทั้งหมดจากกล่องและเกี่ยวกับการเลือกเครื่องมือที่เหมาะสมสำหรับงานเฉพาะ

102 c++  meta-programming 

ฉันทำงานที่งานของฉันประมาณหนึ่งปี ฉันทำงานเป็นหลักในอินเทอร์เฟซ GUI ของเราซึ่งใช้วิธีการจากแบ็กเอนด์ C แต่โดยทั่วไปฉันไม่ต้องจัดการกับพวกเขายกเว้นค่าตอบแทน GUI ของเรามีโครงสร้างที่ค่อนข้างสมเหตุสมผลโดยมีข้อ จำกัด ของเรา ฉันได้รับมอบหมายให้เพิ่มฟังก์ชั่นในส่วนบรรทัดคำสั่งของโปรแกรม ฟังก์ชั่นเหล่านี้ส่วนใหญ่มีความยาว 300 บรรทัดและใช้งานยาก ฉันพยายามรวบรวมชิ้นส่วนเหล่านั้นเพื่อรับข้อมูลสัญญาณเตือนเฉพาะและฉันมีปัญหาในการจัดการ ฉันรู้ว่าฉันกำลังทำการทดสอบที่ซับซ้อนมากขึ้นด้วยการทำมันในฟังก์ชั่นยาว ๆ ฉันควรเก็บทุกอย่างไว้ในฟังก์ชั่นขนาดใหญ่ตามสไตล์ของฟังก์ชั่นที่มีอยู่หรือฉันควรสรุปแคปปลุกในฟังก์ชั่นของตัวเองหรือไม่? ฉันไม่แน่ใจว่าเหมาะสมหรือไม่ที่จะขัดกับอนุสัญญาการเข้ารหัสปัจจุบันหรือว่าฉันควรกัดสัญลักษณ์แสดงหัวข้อย่อยและทำให้รหัสสับสนมากขึ้นสำหรับฉันในการเขียน โดยสรุปฉันกำลังเปรียบเทียบ showAlarms(){ // tons of code } ต่อต้าน showAlarms(){ alarm1(); alarm2(); return; } alarm1(){ ... printf(...); return; } แก้ไข: ขอบคุณสำหรับคำแนะนำทุกคนฉันตัดสินใจว่าฉันจะออกแบบรหัสของฉันเป็นตัวประกอบและจากนั้นถามสิ่งที่พวกเขาต้องการและถ้าพวกเขาต้องการมันทั้งหมดในที่เดียวฉันสามารถตัดจากรหัสตัวประกอบของฉันและเปลี่ยนกลับเป็น 1 ฟังก์ชั่นใหญ่ นี่ควรให้ฉันเขียนและทดสอบได้ง่ายขึ้นแม้ว่าพวกเขาต้องการรหัสทั้งหมดในคำจำกัดความเดียว UPDATE: พวกเขาจบลงด้วยความสุขกับรหัสที่แยกเป็นสัดส่วนและมีคนมากกว่าหนึ่งคนที่ขอบคุณฉันสำหรับการตั้งค่าแบบอย่างนี้

102 coding-style  conventions 

ฉันพยายามทำตามหลักการของDRYอย่างเคร่งครัดในที่ทำงานเสมอ ทุกครั้งที่ฉันทำซ้ำรหัสจากความเกียจคร้านมันกัดอีกครั้งในภายหลังเมื่อฉันต้องการรักษารหัสนั้นในสองแห่ง แต่บ่อยครั้งที่ฉันเขียนวิธีเล็ก ๆ (อาจเป็นรหัส 10 - 15 บรรทัด) ที่ต้องนำมาใช้ซ้ำในสองโครงการที่ไม่สามารถอ้างอิงซึ่งกันและกัน วิธีอาจเป็นสิ่งที่ต้องทำกับระบบเครือข่าย / สาย / MVVM ฯลฯ และเป็นวิธีที่มีประโยชน์โดยทั่วไปไม่เฉพาะเจาะจงกับโครงการที่ตั้งอยู่ในตอนแรก วิธีมาตรฐานในการนำรหัสนี้มาใช้ซ้ำจะเป็นการสร้างโครงการที่เป็นอิสระสำหรับรหัสที่ใช้ซ้ำได้และอ้างอิงโครงการนั้นเมื่อคุณต้องการ ปัญหาเกี่ยวกับสิ่งนี้คือเราจบลงในหนึ่งในสองสถานการณ์ที่ไม่เป็นอุดมคติ: เราจบลงด้วยโครงการเล็ก ๆ นับสิบ / ร้อยคน - แต่ละหลังมีชั้นเรียน / วิธีการเล็ก ๆ น้อย ๆ ซึ่งเราจำเป็นต้องนำมาใช้ซ้ำ มันคุ้มค่าที่จะสร้างรหัสใหม่.DLLเพียงเล็กน้อยหรือไม่? เราจบลงด้วยโครงการเดียวที่รวบรวมวิธีและชั้นเรียนที่ไม่เกี่ยวข้องเพิ่มมากขึ้น วิธีนี้เป็นสิ่งที่ บริษัท ที่ฉันเคยทำงานด้วย พวกเขามีโปรเจ็กต์base.commonที่มีโฟลเดอร์สำหรับสิ่งต่าง ๆ เช่นที่ฉันกล่าวถึงข้างต้น: เครือข่าย, การจัดการสตริง, MVVM ฯลฯ มันมีประโยชน์อย่างเหลือเชื่อ แต่การอ้างอิงมันลากโดยไม่จำเป็นด้วยรหัสที่ไม่เกี่ยวข้องทั้งหมดที่คุณไม่ต้องการ ดังนั้นคำถามของฉันคือ: ทีมซอฟต์แวร์ทำงานอย่างไรดีที่สุดเกี่ยวกับการนำรหัสขนาดเล็กไปมาระหว่างโครงการ ฉันสนใจเป็นพิเศษหากใครก็ตามที่ทำงานใน บริษัท …

102 project-management  code-reuse  projects-and-solutions  dry 

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

102 interview 

การแก้ไขข้อผิดพลาดเมื่อเร็ว ๆ นี้ทำให้ฉันต้องใช้รหัสที่เขียนโดยสมาชิกในทีมคนอื่นซึ่งฉันพบสิ่งนี้ (เป็น C #) return (decimal)CostIn > 0 && CostOut > 0 ? (((decimal)CostOut - (decimal)CostIn) / (decimal)CostOut) * 100 : 0; ตอนนี้การอนุญาตให้มีเหตุผลที่ดีสำหรับการปลดเปลื้องเหล่านี้ยังคงเป็นเรื่องยากมากที่จะติดตาม มีข้อบกพร่องเล็กน้อยในการคำนวณและฉันต้องแก้ให้หายยุ่งเพื่อแก้ไขปัญหา ฉันรู้ว่ารูปแบบการเขียนโค้ดของบุคคลนี้จากการตรวจสอบโค้ดและวิธีการของเขาก็คือสั้นกว่านั้นเกือบจะดีกว่าเสมอ และแน่นอนว่ามันมีคุณค่าอยู่ที่นั่น: เราทุกคนได้เห็นกลุ่มของตรรกะที่มีเงื่อนไขที่ซับซ้อนโดยไม่จำเป็น แต่เขาเก่งกว่าฉันมากในตอนต่อไปของเครือข่ายผู้ประกอบการที่อัดแน่นไปด้วยคำพูดเดียว แน่นอนว่านี่เป็นเรื่องของสไตล์ แต่มีอะไรที่เขียนหรือค้นคว้าเกี่ยวกับการตระหนักถึงจุดที่ความพยายามในการกระชับรหัสหยุดที่มีประโยชน์และกลายเป็นอุปสรรคต่อความเข้าใจ? สาเหตุของการปลดเปลื้องคือ Entity Framework db จำเป็นต้องเก็บสิ่งเหล่านี้เป็นชนิดที่ไม่สามารถใช้ได้ ทศนิยม? ไม่เทียบเท่ากับทศนิยมใน C # และจำเป็นต้องร่าย

102 c#  coding-style  code-quality  clean-code 

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

101 debugging 

ฉันกำลังอ่านซอร์สโค้ดของเฟรมเวิร์กโอเพนซอร์ซซึ่งฉันเห็นตัวแปร "น้ำหนักบรรทุก" กล่าวถึงหลายครั้ง แนวคิดใดที่ "payload" ย่อมาจาก?

101 terminology  variables 

Antipattern " Reinvent the wheel " เป็นสิ่งที่พบได้ทั่วไป - แทนที่จะใช้วิธีแก้ปัญหาพร้อมเขียนตัวคุณเองตั้งแต่เริ่มต้น รหัสฐานเติบโตขึ้นโดยไม่จำเป็นอินเทอร์เฟซที่แตกต่างกันเล็กน้อยที่ทำสิ่งเดียวกัน แต่แตกต่างกันเล็กน้อยมากเวลาเสียเวลาในการเขียน (และดีบัก!) ฟังก์ชั่นที่พร้อมใช้งาน เราทุกคนรู้เรื่องนี้ แต่มีบางอย่างที่ปลายด้านตรงข้ามของสเปกตรัม เมื่อแทนที่จะเขียนฟังก์ชั่นของคุณเองซึ่งเป็นโค้ดสองบรรทัดคุณจะต้องนำเข้าเฟรมเวิร์ก / API / ไลบรารี่สร้างอินสแตนซ์กำหนดค่าแปลงบริบทให้เป็นประเภทข้อมูลตามที่เฟรมเวิร์กยอมรับแล้วเรียกว่าหนึ่งฟังก์ชันเดียว ตรรกะทางธุรกิจสองบรรทัดภายใต้กิกะไบต์ของเลเยอร์นามธรรม จากนั้นคุณต้องทำให้ไลบรารีทันสมัยจัดการการพึ่งพาสร้างเก็บลิขสิทธิ์ในซิงค์และรหัสของการเริ่มต้นของมันนานกว่าสิบเท่าและซับซ้อนกว่าถ้าคุณเพิ่ง "reinvented wheel" เหตุผลอาจแตกต่างกันไป: การจัดการต่อต้าน "การคิดค้นใหม่ของวงล้อ" อย่างเคร่งครัดไม่ว่าจะมีค่าใช้จ่ายใครก็ตามที่ผลักดันเทคโนโลยีที่พวกเขาโปรดปรานแม้จะมีความเหลื่อมล้ำกับความต้องการ ใช้งานเฟรมเวิร์กซึ่งไม่เคยมาถึงหรือเพียงแค่เข้าใจผิดว่า "น้ำหนัก" คำแนะนำการนำเข้า / รวม / โหลดสองอย่างที่มี "เบื้องหลัง" มีชื่อสามัญสำหรับ antipattern ประเภทนี้หรือไม่? (ฉันไม่ได้พยายามที่จะเริ่มการสนทนาเมื่อมันถูกหรือผิดหรือถ้ามันเป็นปฏิปักษ์จริงหรือความคิดเห็นอะไรก็ตามนี่เป็นคำถามง่าย ๆ ที่ตรงไปตรงมาและมีวัตถุประสงค์) แก้ไข: ข้อเสนอแนะ "ซ้ำ" พูดถึงการเอารหัสของตนเองมาใช้เพื่อให้ "พร้อมสำหรับทุกอย่าง" นอกเหนือจากระบบภายนอก สิ่งนี้อาจเกิดขึ้นในบางกรณี แต่โดยทั่วไปแล้วมันเกิดจาก …

101 naming  anti-patterns 

ในขณะนี้ฉันสร้างการเชื่อมต่อฐานข้อมูลเมื่อหน้าเว็บของฉันถูกโหลดครั้งแรก จากนั้นฉันจะประมวลผลหน้าเว็บและเรียกใช้แบบสอบถามใด ๆ กับ conection นั้น นี่เป็นวิธีที่ดีที่สุดในการทำหรือฉันควรสร้างการเชื่อมต่อฐานข้อมูลทุกครั้งที่ฉันเรียกใช้แบบสอบถามหรือไม่ ปล. ฉันรู้สึกดีกว่าที่จะสร้างการเชื่อมต่อ 1 ครั้งและใช้งานได้ แต่ฉันไม่รู้ว่าจะทำให้เกิดปัญหาอื่น ๆ หรือไม่ ฉันใช้ C # (ASP.NET) กับ MSSQL

101 c#  database  sql-server 

ฉันมักจะเห็นในรหัส C และ C ++ การประชุมต่อไปนี้: some_type val; val = something; some_type *ptr = NULL; ptr = &something_else; แทน some_type val = something; some_type *ptr = &something_else; ตอนแรกฉันคิดว่านี่เป็นนิสัยที่เหลือจากวันที่คุณต้องประกาศตัวแปรท้องถิ่นทั้งหมดที่ด้านบนของขอบเขต แต่ฉันเรียนรู้ที่จะไม่เลิกนิสัยนักพัฒนามืออาชีพอย่างรวดเร็ว ดังนั้นมีเหตุผลที่ดีสำหรับการประกาศในหนึ่งบรรทัดและกำหนดในภายหลังหรือไม่

101 c++  c 

หนึ่งในสิ่งที่ฉันต่อสู้คือไม่ได้ใช้สัญกรณ์ฮังการี ฉันไม่ต้องการที่จะไปที่คำนิยามตัวแปรเพียงเพื่อดูว่ามันคืออะไร เมื่อโปรเจ็กต์ขยายขอบเขตมันก็ดีที่สามารถดูตัวแปรนำหน้าด้วย 'บูล' และรู้ว่ามันกำลังมองหาจริง / เท็จแทนที่จะเป็นค่า0/1 ฉันทำงานหนักมากใน SQL Server ฉันเติมคำนำหน้ากระบวนงานที่เก็บไว้ด้วย 'sp' และตารางของฉันด้วย 'tbl' ไม่ต้องพูดถึงตัวแปรทั้งหมดของฉันในฐานข้อมูลตามลำดับ ฉันเห็นทุกที่ที่ไม่มีใครต้องการใช้สัญกรณ์ฮังการีถึงจุดที่พวกเขาหลีกเลี่ยง คำถามของฉันคืออะไรประโยชน์ของการไม่ใช้สัญกรณ์ฮังการีและทำไมนักพัฒนาส่วนใหญ่จึงหลีกเลี่ยงปัญหาเช่นภัยพิบัติ

101 coding-style  coding-standards  naming 

ขณะนี้ฉันกำลังทำการตรวจสอบโค้ดและหนึ่งในสิ่งที่ฉันสังเกตเห็นคือจำนวนข้อยกเว้นที่ดูเหมือนว่าข้อความข้อยกเว้นจะย้ำตำแหน่งข้อยกเว้นที่เกิดขึ้น เช่น throw new Exception("BulletListControl: CreateChildControls failed."); ทั้งสามรายการในข้อความนี้ฉันสามารถทำงานได้จากข้อยกเว้นที่เหลือ ฉันรู้ชั้นเรียนและวิธีการจากการติดตามสแต็กและฉันรู้ว่ามันล้มเหลว (เพราะฉันมีข้อยกเว้น) ฉันทำให้ฉันคิดถึงข้อความที่ฉันใส่ไว้ในข้อความยกเว้น ก่อนอื่นฉันสร้างคลาสยกเว้นถ้าไม่มีอยู่แล้วด้วยเหตุผลทั่วไป (เช่นPropertyNotFoundException- สาเหตุ ) จากนั้นเมื่อฉันโยนมันข้อความจะระบุสิ่งที่ผิดพลาด (เช่น "ไม่สามารถหาคุณสมบัติ 'IDontExist' บนโหนด 1234 "- อะไร ) StackTraceที่อยู่ใน เมื่ออาจจะจบลงในบันทึก (ถ้ามี) วิธีสำหรับนักพัฒนาที่จะทำงานออก (และแก้ไข) คุณมีเคล็ดลับอื่น ๆ ในการขว้างข้อยกเว้นหรือไม่? โดยเฉพาะเกี่ยวกับการสร้างชนิดใหม่และข้อความข้อยกเว้น

101 exceptions