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

นี่เป็นเรื่องอวดรู้เล็กน้อย แต่ฉันเคยเห็นบางคนใช้Idใน: private int userId; public int getUserId(); และอื่น ๆ ใช้: private int userID; public int getUserID(); หนึ่งในนั้นเป็นชื่อที่ดีกว่าชื่ออื่นหรือไม่? ทำไม? ฉันเคยเห็นสิ่งนี้ทำกันอย่างไม่สอดคล้องในโครงการขนาดใหญ่ ถ้าฉันจะตั้งมาตรฐานที่คนส่วนใหญ่จะคุ้นเคยกับ? มาตรฐานดั้งเดิมคืออะไร?

126 coding-style  naming  variables 

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

126 interview 

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

126 programming-practices  project-management 

มีใครคิดบ้างไหมว่าทำไมเราหลายคนจึงทำซ้ำรูปแบบเดียวกันนี้โดยใช้ชื่อตัวแปรเดียวกัน for (int i = 0; i < foo; i++) { // ... } ดูเหมือนว่ารหัสที่สุดที่ผมเคยมองที่เคยใช้i, j, kและอื่น ๆ เป็นตัวแปรซ้ำ ฉันคิดว่าฉันเลือกมันมาจากที่ไหนสักแห่ง แต่ฉันสงสัยว่าทำไมสิ่งนี้ถึงแพร่หลายมากในการพัฒนาซอฟต์แวร์ มันเป็นสิ่งที่เราทุกคนหยิบขึ้นมาจาก C หรืออะไรทำนองนั้น? แค่คันที่ฉันมีอยู่พักหนึ่งที่หลังศีรษะ

126 programming-practices  coding-style  coding-standards 

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

125 event-programming 

นี่เป็นปัญหาที่ฉันพบเจอในสองสามครั้ง ลองนึกภาพคุณมีบันทึกที่คุณต้องการจัดเก็บลงในตารางฐานข้อมูล ตารางนี้มีคอลัมน์ DateTime ที่ชื่อ "date_created" หนึ่งในเร็กคอร์ดนี้ถูกสร้างขึ้นมานานแล้วและคุณไม่แน่ใจจริงๆเกี่ยวกับวันที่แน่นอน แต่คุณรู้ปีและเดือน บันทึกอื่น ๆ ที่คุณรู้เพียงแค่ปี บันทึกอื่น ๆ ที่คุณรู้ว่าวันเดือนและปี คุณไม่สามารถใช้ฟิลด์ DateTime ได้เนื่องจาก "May 1978" ไม่ใช่วันที่ที่ถูกต้อง หากคุณแบ่งออกเป็นหลายคอลัมน์คุณจะไม่สามารถสืบค้นได้ มีคนอื่นวิ่งเข้าไปในนี้ถ้าเป็นเช่นนั้นคุณจัดการกับมันได้อย่างไร? เพื่อชี้แจงระบบที่ฉันกำลังสร้างมันเป็นระบบที่ติดตามคลังข้อมูล เนื้อหาบางส่วนได้ถูกผลิตมานานแล้วและสิ่งที่เรารู้คือ "พฤษภาคม 1978" ฉันสามารถจัดเก็บเป็นวันที่ 1 พฤษภาคม 1978 แต่มีเพียงวิธีที่จะแสดงว่าวันนี้มีความถูกต้องเฉพาะกับเดือน ด้วยวิธีนี้หลายปีต่อมาเมื่อฉันเรียกคืนไฟล์เก็บถาวรนั้นฉันไม่สับสนเมื่อวันที่ไม่ตรงกัน เพื่อจุดประสงค์ของฉันมันเป็นสิ่งสำคัญที่จะต้องแยก "วันที่ไม่รู้จักในเดือนพฤษภาคม 2521" กับ "1 พฤษภาคม 2521" นอกจากนี้ฉันไม่ต้องการเก็บสิ่งที่ไม่รู้จักเป็น 0 เช่น "0 พฤษภาคม 1978" เพราะระบบฐานข้อมูลส่วนใหญ่จะปฏิเสธว่าเป็นค่าวันที่ที่ไม่ถูกต้อง

125 database  date-format 

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

125 clean-code 

เมื่อใดก็ตามที่ฉันพบว่าตัวเองเขียนตรรกะเดียวกันมากกว่าหนึ่งครั้งฉันมักจะติดมันในฟังก์ชั่นดังนั้นมีเพียงที่เดียวในแอปพลิเคชันของฉันฉันต้องรักษาตรรกะนั้น ผลข้างเคียงคือบางครั้งฉันก็จบลงด้วยฟังก์ชั่นหนึ่งหรือสองบรรทัดเช่น: function conditionMet(){ return x == condition; } หรือ function runCallback(callback){ if($.isFunction(callback)) callback(); } นี่มันขี้เกียจหรือเป็นการฝึกที่ไม่ดีเหรอ? ฉันแค่ถามเพราะสิ่งนี้ส่งผลให้มีการเรียกใช้ฟังก์ชันจำนวนมากขึ้นสำหรับตรรกะชิ้นเล็ก ๆ

125 programming-practices  coding-standards 

ตัวเลือกหุ้นไม่สมเหตุสมผลเนื่องจาก บริษัท เป็นส่วนตัว [มันยังคงเป็นเช่นนั้นถ้าคุณเป็นเฟซบุ๊กและระบบกฎระเบียบอนุญาตให้ไซต์เช่นตลาดรอง แต่ฉันพูดนอกเรื่อง] ฉันคิดได้บ้าง: ประโยชน์ด้านสุขภาพต่อผู้ปกครองและผู้ปกครองในกฎหมาย สนับสนุนจักรยานประหยัดน้ำมันเพื่อขับไปยังสำนักงาน บัตรของขวัญสำหรับโอกาสเช่นการให้บริการครบ 1, 3, 5 ปี ฉันสามารถทำอะไรกับคำแนะนำเพิ่มเติมได้ที่นี่ แก้ไข: ขอบคุณทุกคนสำหรับการตอบสนอง เพื่อสรุปนี่เป็นสิ่งเพิ่มเติมที่ HR ของฉันสามารถทำได้: การจับคู่สมทบกับกองทุนเพื่อการเกษียณอายุของพนักงานหากพนักงานมีส่วนร่วม ทุนการศึกษาต่อเนื่องหลักสูตรวิชาชีพ ฯลฯ การสมัครสมาชิก บริษัท ACM, IEEE, Safari Books ฯลฯ บัตรกำนัลอาหาร เป็นสมาชิกของโรงยิม โฮสต์ห้องสันทนาการที่สำนักงาน โบนัสสปอต หมดเวลาสำหรับการเพิ่มรหัสในการจดจำการสนับสนุนแต่ละรายการ คบหา

125 management 

สมมติว่าฉันมีเอนทิตีที่มีแอตทริบิวต์ "ประเภท" อาจมีประเภทที่เป็นไปได้มากกว่า 20 รายการ ตอนนี้ฉันขอให้ใช้สิ่งที่จะอนุญาตให้เปลี่ยนประเภทจาก A-> B ซึ่งเป็นกรณีการใช้งานเท่านั้น ดังนั้นฉันควรใช้สิ่งที่อนุญาตให้มีการเปลี่ยนแปลงประเภทโดยพลการตราบเท่าที่พวกเขาเป็นประเภทที่ถูกต้อง? หรือฉันควรอนุญาตให้เปลี่ยนจาก A-> B ตามความต้องการและปฏิเสธการเปลี่ยนแปลงประเภทอื่นเช่น B-> A หรือ A-> C ฉันเห็นข้อดีและข้อเสียของทั้งสองฝ่ายซึ่งวิธีการแก้ปัญหาทั่วไปจะหมายถึงการทำงานน้อยลงในกรณีที่ความต้องการที่คล้ายกันเกิดขึ้นในอนาคต แต่มันก็หมายถึงโอกาสที่จะผิดพลาดมากขึ้น (แม้ว่าเราจะควบคุมผู้โทร 100% จุด). วิธีแก้ปัญหาเฉพาะนั้นมีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยลง แต่ต้องการงานมากขึ้นในอนาคตหากมีข้อกำหนดที่คล้ายกันเกิดขึ้น ฉันได้ยินมาว่านักพัฒนาที่ดีควรพยายามคาดการณ์การเปลี่ยนแปลงและออกแบบระบบเพื่อให้สามารถขยายได้ง่ายในอนาคตซึ่งดูเหมือนว่าโซลูชันทั่วไปเป็นหนทางไปสู่อะไร แก้ไข: การเพิ่มรายละเอียดเพิ่มเติมในตัวอย่างที่ไม่เฉพาะของฉัน: โซลูชัน "ทั่วไป" ในกรณีนี้ต้องใช้งานน้อยกว่าโซลูชัน "เฉพาะ" เนื่องจากโซลูชันเฉพาะต้องมีการตรวจสอบความถูกต้องกับประเภทเก่าและชนิดใหม่ในขณะที่โซลูชันทั่วไป จะต้องตรวจสอบประเภทใหม่เท่านั้น

124 programming-practices  api-design  requirements 

ฉันทำงานกับโปรแกรมตัวเลข / คณิตศาสตร์บ่อยครั้งมากซึ่งผลลัพธ์ที่แน่นอนของฟังก์ชั่นนั้นยากที่จะทำนายล่วงหน้า ในการพยายามใช้ TDD กับรหัสประเภทนี้ฉันมักจะพบว่าการเขียนรหัสภายใต้การทดสอบง่ายกว่าการเขียนการทดสอบหน่วยสำหรับรหัสนั้นอย่างมีนัยสำคัญเพราะวิธีเดียวที่ฉันรู้ในการค้นหาผลลัพธ์ที่คาดหวังคือการใช้อัลกอริทึมเอง หัวกระดาษหรือโดยคอมพิวเตอร์) สิ่งนี้รู้สึกผิดเพราะฉันใช้รหัสภายใต้การทดสอบเพื่อตรวจสอบการทดสอบหน่วยของฉันอย่างมีประสิทธิภาพแทนที่จะเป็นวิธีอื่น มีเทคนิคที่รู้จักกันสำหรับการเขียนการทดสอบหน่วยและการใช้ TDD เมื่อผลลัพธ์ของรหัสภายใต้การทดสอบนั้นยากที่จะทำนายหรือไม่? ตัวอย่างโค้ด (จริง) ที่ยากต่อการคาดการณ์ผลลัพธ์: ฟังก์ชั่นweightedTasksOnTimeที่ได้รับจำนวนเงินของงานที่ทำต่อวันworkPerDayในช่วง (0, 24], เวลาปัจจุบันinitialTime> 0 และรายชื่อของงานtaskArrayแต่ละที่มีเวลาที่จะเสร็จสมบูรณ์คุณสมบัติtime> 0 วันที่ครบกำหนดdueและความคุ้มค่าความสำคัญimportance; ผลตอบแทน ค่าปกติอยู่ในช่วง [0, 1] เป็นตัวแทนของความสำคัญของงานที่สามารถจะแล้วเสร็จก่อนของพวกเขาdueวันถ้าแต่ละงานถ้าเสร็จสมบูรณ์ในการสั่งซื้อที่กำหนดโดยเริ่มต้นที่taskArrayinitialTime ขั้นตอนวิธีการที่จะใช้ฟังก์ชั่นนี้ค่อนข้างตรงไปตรงมา: taskArrayย้ำกว่างานใน สำหรับแต่ละงานเพิ่มเพื่อtime initialTimeหากเวลาใหม่ < dueเพิ่มimportanceไปยังแอคคูมูเลเตอร์ ปรับเวลาด้วย inverse workPerDay ก่อนที่จะส่งคืนตัวสะสมหารด้วยผลรวมของความสำคัญของงานเพื่อทำให้ปกติ function weightedTasksOnTime(workPerDay, initialTime, taskArray) { let simulatedTime = initialTime let accumulator = 0; …

124 unit-testing  tdd 

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

124 scrum  planning 

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

124 design-patterns  dependency-injection 

ในช่วงไม่กี่ปีที่ผ่านมาการโฆษณารอบ ๆ Git เพิ่มขึ้นอย่างมาก ทุกคนรู้เกี่ยวกับ Git ไม่มีใครรู้เกี่ยวกับทางเลือก คนอื่น ๆ เช่น Mercurial ดูเหมือนจะไม่มีใครสังเกตเห็น ทั้งสองได้รับการปล่อยตัวในปี 2005 และมีฟังก์ชั่นที่คล้ายกัน ยิ่งไปกว่านั้น Mercurial ได้รับการพิจารณาว่าใช้งานได้ง่ายขึ้นใช้งานง่ายกว่าเดิม ดังนั้นจึงสามารถสันนิษฐานได้ว่าสิ่งนี้จะเป็นทางเลือกยอดนิยมโดยเฉพาะอย่างยิ่งสำหรับผู้ที่เพิ่งเริ่มการควบคุมเวอร์ชันแบบกระจาย ถึงกระนั้นดูเหมือนว่าคนส่วนใหญ่จะไม่รู้จักซึ่งแตกต่างจาก Git ที่ประสบความสำเร็จค่อนข้างดี จุดสำคัญของโพสต์นี้คือพยายามทำความเข้าใจปรากฏการณ์นี้ให้ดีขึ้น Git มาได้อย่างไรส่วนหนึ่งของเค้ก? พวกเขาใช้การตลาดที่ดีกว่าอย่างใด? เป็นเพราะชุมชนของมันมีมากขึ้น ... อะแฮ่ม ... "verbose"? เป็นเพราะชื่อ "Linus" หรือไม่? เป็นเพราะภาพลักษณ์ที่เกินบรรยายหรือไม่? ความคิดเห็นของคุณคืออะไร

124 version-control  git  mercurial 

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

123 code-quality  recursion