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

ถาม - ตอบสำหรับมืออาชีพนักวิชาการและนักเรียนที่ทำงานในวงจรการพัฒนาระบบ

22
ทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎีและการปฏิบัติ? [ปิด]
เมื่อเปรียบเทียบกับวิศวกรรมซอฟต์แวร์กับวิศวกรรมโยธาฉันรู้สึกประหลาดใจที่สังเกตวิธีการคิดที่แตกต่าง: วิศวกรโยธาคนใดรู้ว่าถ้าคุณต้องการสร้างกระท่อมเล็ก ๆ ในสวนคุณก็จะได้วัสดุและสร้างมันในขณะที่ถ้าคุณต้องการสร้าง บ้าน 10 ชั้น (หรือบางอย่างเช่นนี้ ) คุณต้องทำคณิตศาสตร์เพื่อให้แน่ใจว่ามันจะไม่พัง ในทางตรงกันข้ามการพูดกับการเขียนโปรแกรมบางส่วนหรืออ่านบล็อกหรือฟอรั่ฉันมักจะพบความเห็นในวงกว้างที่สามารถนำสูตรมากหรือน้อยดังต่อไปนี้: ทฤษฎีและวิธีการอย่างเป็นทางการสำหรับนักคณิตศาสตร์ / นักวิทยาศาสตร์ในขณะที่การเขียนโปรแกรมเป็นเรื่องเกี่ยวกับการทำสิ่งต่างๆ สิ่งที่บอกเป็นนัยก็คือการเขียนโปรแกรมเป็นสิ่งที่ใช้งานได้จริงและแม้ว่าวิธีการอย่างเป็นทางการคณิตศาสตร์ทฤษฎีอัลกอริทึมภาษาโปรแกรมสะอาด / เชื่อมโยงกัน ฯลฯ อาจเป็นหัวข้อที่น่าสนใจพวกเขามักไม่จำเป็นถ้าทุกคนต้องการได้สิ่ง เสร็จแล้ว จากประสบการณ์ของฉันฉันจะบอกว่าในขณะที่คุณไม่จำเป็นต้องใช้ทฤษฎีมากในการรวบรวมสคริปต์ 100 บรรทัด (กระท่อม) เพื่อพัฒนาแอปพลิเคชันที่ซับซ้อน (อาคาร 10 ชั้น) คุณต้องมีการออกแบบที่มีโครงสร้าง - วิธีการกำหนดภาษาการเขียนโปรแกรมที่ดีหนังสือข้อความที่ดีที่คุณสามารถค้นหาอัลกอริทึม ฯลฯ ดังนั้น IMO (ปริมาณที่เหมาะสมของ) ทฤษฎีเป็นหนึ่งในเครื่องมือสำหรับการทำสิ่งต่างๆ คำถามของฉันคือทำไมโปรแกรมเมอร์บางคนคิดว่ามีความแตกต่างระหว่างทฤษฎี (วิธีการที่เป็นทางการ) และการฝึกฝน ซอฟต์แวร์วิศวกรรม (ซอฟท์แวร์อาคาร) ถูกมองว่าเป็นเรื่อง ง่ายเมื่อเทียบกับวิศวกรรมโยธา (บ้านอาคาร)? หรือทั้งสองสาขาแตกต่างกันจริงๆ (นอกเหนือจากซอฟต์แวร์ที่มีความสำคัญต่อภารกิจแล้วความล้มเหลวของซอฟต์แวร์นั้นเป็นที่ยอมรับได้มากกว่าการสร้างความล้มเหลว) ฉันพยายามสรุปสิ่งที่ฉันเข้าใจจากคำตอบแล้ว ตรงกันข้ามกับวิศวกรรมซอฟต์แวร์ในสาขาวิศวกรรมโยธามันมีความชัดเจนมากขึ้นว่าจำนวนของทฤษฎี (การสร้างแบบจำลองการออกแบบ) เป็นสิ่งจำเป็นสำหรับงานบางอย่าง …

10
มีสิ่งใดที่มีฟังก์ชั่น / เมธอดส่วนตัวมากเกินไปหรือไม่?
ฉันเข้าใจถึงความสำคัญของรหัสที่มีเอกสารดี แต่ฉันก็เข้าใจถึงความสำคัญของรหัสการจัดทำเอกสารด้วยตนเอง ยิ่งง่ายต่อการอ่านฟังก์ชั่นโดยเฉพาะยิ่งเราสามารถเดินหน้าได้เร็วขึ้นในระหว่างการบำรุงรักษาซอฟต์แวร์ ด้วยที่กล่าวว่าฉันชอบที่จะแยกฟังก์ชั่นใหญ่เป็นคนเล็ก ๆ แต่ฉันทำจนถึงจุดที่ชั้นเรียนสามารถมีมากกว่าห้าคนเพื่อรับใช้วิธีการเดียวเท่านั้น ทีนี้คูณวิธีการส่วนตัวห้าวิธีด้วยวิธีสาธารณะห้าวิธีและคุณจะได้วิธีซ่อนเร้นประมาณยี่สิบห้าวิธีซึ่งอาจเรียกได้โดยสาธารณะเหล่านั้นเพียงครั้งเดียว แน่นอนว่าตอนนี้การอ่านวิธีสาธารณะนั้นง่ายขึ้น แต่ฉันอดไม่ได้ที่จะคิดว่าการมีฟังก์ชั่นมากเกินไปนั้นเป็นการฝึกฝนที่ไม่ดี [แก้ไข] มีคนถามฉันว่าทำไมฉันคิดว่าการมีฟังก์ชั่นมากเกินไปนั้นเป็นการฝึกฝนที่ไม่ดี คำตอบง่าย ๆ : มันเป็นความรู้สึกทางเดินอาหาร ความเชื่อของฉันไม่ใช่เพียงหนึ่งบิตที่ได้รับการสนับสนุนจากประสบการณ์ด้านวิศวกรรมซอฟต์แวร์นานนับชั่วโมง มันเป็นความไม่แน่นอนที่ทำให้ฉัน "บล็อกนักเขียน" แต่สำหรับโปรแกรมเมอร์ ในอดีตที่ผ่านมาฉันเพิ่งจะเขียนโปรแกรมโครงการส่วนบุคคล เมื่อไม่นานมานี้ฉันได้ย้ายไปยังโครงการที่ทำงานเป็นทีม ตอนนี้ฉันต้องการให้แน่ใจว่าคนอื่นสามารถอ่านและเข้าใจรหัสของฉันได้ ฉันไม่แน่ใจว่าจะปรับปรุงความชัดเจนได้อย่างไร ในมือข้างหนึ่งฉันกำลังคิดที่จะแยกฟังก์ชั่นใหญ่หนึ่งอันออกเป็นฟังก์ชันย่อยที่มีชื่อที่เข้าใจได้ แต่มีอีกด้านหนึ่งของฉันบอกว่ามันซ้ำซ้อน ดังนั้นฉันขอให้สิ่งนี้สอนตัวเองเพื่อเลือกเส้นทางที่ถูกต้อง [แก้ไข] ด้านล่างฉันรวมสองรุ่นว่าฉันสามารถแก้ปัญหาของฉันได้อย่างไร คนแรกแก้มันโดยไม่แยกชิ้นใหญ่ของรหัส คนที่สองไม่สิ่งที่แยกจากกัน รุ่นแรก: public static int Main() { // Displays the menu. Console.WriteLine("Pick your option"); Console.Writeline("[1] Input and display a polynomial"); Console.WriteLine("[2] …

3
&& และ || ไม่ได้เป็นตรรกะ แต่ผู้ประกอบการตามเงื่อนไข?
ฉันเป็นบิตสับสนโดยเอกสาร # MSDN C ซึ่งระบุว่า&และ|ผู้ประกอบการเชิงตรรกะและที่&&และ||ผู้ประกอบการที่มีเงื่อนไข ฉันให้โทร&&, ||และ!ดำเนินการทางตรรกะดังนั้นผมผิดหรือเปล่า?

4
กลุ่มเธรดคืออะไร
หนึ่งจะใช้ threadpool ได้อย่างไร ฉันได้อ่านวิกิพีเดียเกี่ยวกับ "threadpool" แต่ฉันก็ยังไม่สามารถคิดได้ว่าสิ่งใดที่ควรทำเพื่อแก้ปัญหานี้ ใครช่วยอธิบายฉันเป็นภาษาอังกฤษธรรมดาว่า threadpool คืออะไรและใครจะตอบคำถามนี้ได้บ้าง?

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

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

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

15
มีเหตุผลใดที่จะไม่ไปจาก Javascript ฝั่งไคลเอ็นต์โดยตรงกับฐานข้อมูลหรือไม่?
สำเนาซ้ำที่เป็นไปได้: เขียนแอปพลิเคชัน“ เซิร์ฟเวอร์น้อยกว่า” บนเว็บ ดังนั้นสมมติว่าฉันจะสร้างโคลน Exchange Stack และฉันตัดสินใจที่จะใช้สิ่งที่ต้องการ CouchDB เป็นที่เก็บแบ็กเอนด์ของฉัน หากฉันใช้การพิสูจน์ตัวตนในตัวและการอนุญาตระดับฐานข้อมูลมีเหตุผลใดที่จะไม่อนุญาตให้ Javascript ฝั่งไคลเอ็นต์เขียนโดยตรงไปยังเซิร์ฟเวอร์ CouchDB ที่เปิดเผยสู่สาธารณะ เนื่องจากนี่เป็นแอปพลิเคชั่น CRUD และตรรกะทางธุรกิจประกอบด้วย "ผู้เขียนเท่านั้นที่สามารถแก้ไขโพสต์ของพวกเขา" ฉันไม่เห็นความต้องการมากที่จะมีเลเยอร์ระหว่างสิ่งที่ฝั่งไคลเอ็นต์และฐานข้อมูล ฉันเพียงแค่ใช้การตรวจสอบด้าน CouchDB เพื่อให้แน่ใจว่าไม่มีใครใส่ข้อมูลขยะและตรวจสอบให้แน่ใจว่ามีการตั้งค่าการอนุญาตอย่างถูกต้องเพื่อให้ผู้ใช้สามารถอ่านข้อมูล _user ของตนเองได้ การเรนเดอร์จะทำได้โดยฝั่งไคลเอ็นต์โดยบางสิ่งเช่น AngularJS โดยพื้นฐานแล้วคุณสามารถมีเซิร์ฟเวอร์ CouchDB และหน้าแบบ "คงที่" และคุณก็พร้อมที่จะไป คุณไม่จำเป็นต้องมีการประมวลผลด้านเซิร์ฟเวอร์ใด ๆ เพียงแค่สิ่งที่สามารถแสดงหน้า HTML ได้ การเปิดฐานข้อมูลของฉันสู่โลกดูเหมือนผิด แต่ในสถานการณ์นี้ฉันไม่สามารถคิดได้ว่าทำไมตราบใดที่การตั้งค่าการอนุญาตถูกต้อง มันขัดกับสัญชาตญาณของฉันในฐานะนักพัฒนาเว็บ แต่ฉันไม่สามารถคิดได้ด้วยเหตุผลที่ดี เหตุใดจึงเป็นความคิดที่ไม่ดี แก้ไข: ดูเหมือนว่ามีการสนทนาที่คล้ายกันที่นี่: การเขียนเว็บ "เซิร์ฟเวอร์น้อยกว่า" แอปพลิเคชัน แก้ไข: การอภิปรายที่น่าประทับใจจนถึงตอนนี้และฉันขอขอบคุณข้อเสนอแนะของทุกคน! ฉันรู้สึกว่าฉันควรเพิ่มสมมติฐานทั่วไปสองสามข้อแทนที่จะเรียกเฉพาะ …

7
วิธีจัดการกับคลาสยูทิลิตี้สแตติกเมื่อออกแบบเพื่อทดสอบ
เราพยายามออกแบบระบบของเราให้สามารถทดสอบได้และส่วนใหญ่พัฒนาโดยใช้ TDD ขณะนี้เรากำลังพยายามแก้ไขปัญหาต่อไปนี้: ในสถานที่ต่าง ๆ เราจำเป็นต้องใช้วิธีการช่วยเหลือแบบคงที่เช่น ImageIO และ URLEncoder (ทั้ง Java API มาตรฐาน) และห้องสมุดอื่น ๆ อีกมากมายที่ประกอบด้วยวิธีคงที่ส่วนใหญ่ (เช่นไลบรารี Apache Commons) แต่มันยากมากที่จะทดสอบวิธีการเหล่านั้นที่ใช้คลาสตัวช่วยแบบคงที่ ฉันมีความคิดหลายอย่างสำหรับการแก้ปัญหานี้: ใช้เฟรมเวิร์กจำลองที่สามารถจำลองคลาสแบบคงที่ (เช่น PowerMock) นี่อาจเป็นทางออกที่ง่ายที่สุด แต่ก็รู้สึกอยากยอมแพ้ สร้างคลาส wrapper ทันทีที่มีรอบยูทิลิตี้คงที่เหล่านั้นเพื่อให้พวกเขาสามารถฉีดเข้าไปในชั้นเรียนที่ใช้พวกเขา ดูเหมือนว่าจะเป็นคำตอบที่ค่อนข้างสะอาด แต่ฉันกลัวว่าเราจะจบลงด้วยการสร้างคลาส wrapper เหล่านั้น แยกการเรียกคลาสผู้ช่วยแบบคงที่เหล่านี้ลงในฟังก์ชันที่สามารถแทนที่ได้และทดสอบคลาสย่อยของคลาสที่ฉันต้องการทดสอบจริง ๆ แต่ฉันคิดอยู่เสมอว่านี่จะเป็นปัญหาที่หลายคนต้องเผชิญเมื่อทำ TDD - ดังนั้นจะต้องมีวิธีแก้ไขปัญหานี้อยู่แล้ว กลยุทธ์ที่ดีที่สุดในการรักษาคลาสที่ใช้ตัวช่วยคงที่สามารถทดสอบได้คืออะไร

3
ทำไมเราต้องใส่สมาชิกส่วนบุคคลไว้ในหัว?
ตัวแปรส่วนตัวเป็นวิธีการซ่อนความซับซ้อนและรายละเอียดการใช้งานให้กับผู้ใช้ของชั้นเรียน นี่เป็นฟีเจอร์ที่ค่อนข้างดี แต่ฉันไม่เข้าใจว่าทำไมใน c ++ เราต้องใส่ไว้ในส่วนหัวของชั้นเรียน ฉันเห็นข้อเสียที่น่ารำคาญสองประการนี้: มันตัดส่วนหัวจากผู้ใช้ มันบังคับให้รวบรวมไคลเอนต์ไลบรารีทั้งหมดใหม่ทุกครั้งที่มีการแก้ไข internals มีเหตุผลทางแนวคิดเบื้องหลังข้อกำหนดนี้หรือไม่ มันเป็นเพียงเพื่อความสะดวกในการทำงานออกคอมไพเลอร์?
62 c++  headers 

6
การรวมวัตถุเป็นเทคนิคที่เลิกใช้หรือไม่?
ฉันคุ้นเคยกับแนวคิดของการรวมวัตถุและฉันพยายามที่จะใช้มันให้มากที่สุด นอกจากนี้ฉันมักจะคิดว่าการรวมวัตถุเป็นบรรทัดฐานมาตรฐานที่ฉันสังเกตเห็นว่า Java เองรวมถึงกรอบงานอื่น ๆ ที่ใช้ร่วมกันมากที่สุด เมื่อเร็ว ๆ นี้แม้ว่าฉันจะอ่านอะไรบางอย่างที่เป็นของใหม่ การรวมกำไรนั้นทำให้ประสิทธิภาพของโปรแกรมแย่ลงโดยเฉพาะในแอปพลิเคชันที่เกิดขึ้นพร้อมกันและขอแนะนำให้สร้างอินสแตนซ์newวัตถุแทนเนื่องจากใน JVM รุ่นใหม่การสร้างอินสแตนซ์ของวัตถุนั้นเร็วมาก ฉันอ่านสิ่งนี้ในหนังสือ: Java Concurrency in Practice ตอนนี้ฉันเริ่มคิดว่าถ้าฉันเข้าใจบางสิ่งบางอย่างที่นี่ตั้งแต่ส่วนแรกของหนังสือแนะนำให้ใช้Executorsซ้ำนั้นThreadแทนที่จะสร้างอินสแตนซ์ใหม่ การรวมวัตถุได้กลายเป็นที่นิยมในปัจจุบัน?

4
วัตถุประสงค์ของลูกศรคืออะไร?
ฉันกำลังเรียนรู้การเขียนโปรแกรม functionnal กับ Haskell และฉันพยายามคว้าแนวคิดโดยการทำความเข้าใจก่อนว่าทำไมฉันถึงต้องการมัน ฉันต้องการทราบเป้าหมายของลูกศรในภาษาโปรแกรมที่ใช้งานได้ พวกเขาแก้ปัญหาอะไร ฉันจะตรวจสอบhttp://en.wikibooks.org/wiki/Haskell/Understanding_arrowsและhttp://www.cse.chalmers.se/~rjmh/afp-arrows.pdf ทั้งหมดที่ฉันเข้าใจคือพวกเขาใช้เพื่ออธิบายกราฟสำหรับการคำนวณและพวกเขาอนุญาตให้เขียนโค้ดในรูปแบบจุดฟรีได้ง่ายขึ้น บทความสมมติว่าสไตล์ฟรีพอยต์นั้นโดยทั่วไปง่ายต่อการเข้าใจและเขียน ดูเหมือนว่าฉันจะคิดแบบนี้ ในบทความอื่น ( http://en.wikibooks.org/wiki/Haskell/StephensArrowTutorial#Hangman:_Main_program ) มีการนำเกมแฮงก์แมนมาใช้ แต่ฉันไม่เห็นว่าลูกศรทำให้การติดตั้งนี้เป็นธรรมชาติอย่างไร ฉันสามารถหาเอกสารจำนวนมากที่อธิบายแนวคิด แต่ไม่มีอะไรเกี่ยวกับแรงจูงใจ ฉันกำลังคิดถึงอะไร

15
ฉันจะโน้มน้าวให้โปรแกรมเมอร์คาวบอยใช้การควบคุมแหล่งที่มาได้อย่างไร
อัพเดท ฉันทำงานกับทีม devs เล็ก ๆ 4 คน พวกเขามีการควบคุมแหล่งที่ใช้ทั้งหมด ส่วนใหญ่ไม่สามารถควบคุมแหล่งที่มาและเลือกที่จะไม่ใช้แทน ฉันเชื่อมั่นอย่างยิ่งว่าการควบคุมแหล่งข้อมูลเป็นส่วนที่จำเป็นในการพัฒนาวิชาชีพ ปัญหาต่าง ๆ ทำให้ยากต่อการโน้มน้าวใจให้ใช้ตัวควบคุมแหล่งที่มา: ทีมที่ไม่ได้ใช้ในการใช้TFS ฉันมีการฝึกอบรม 2 ครั้ง แต่ได้รับการจัดสรรเพียง 1 ชั่วโมงเท่านั้นซึ่งไม่เพียงพอ สมาชิกในทีมปรับเปลี่ยนรหัสบนเซิร์ฟเวอร์โดยตรง สิ่งนี้จะทำให้รหัสไม่ซิงค์กัน ต้องการการเปรียบเทียบเพื่อให้แน่ใจว่าคุณกำลังทำงานกับรหัสล่าสุด และปัญหาการรวมที่ซับซ้อนเกิดขึ้น การประเมินเวลาที่นักพัฒนาซอฟต์แวร์นำเสนอไม่รวมเวลาที่ต้องใช้ในการแก้ไขปัญหาเหล่านี้ ดังนั้นถ้าฉันบอกว่าไม่ใช่จะใช้เวลานานกว่า 10 เท่า ... ฉันต้องอธิบายปัญหาเหล่านี้อย่างต่อเนื่องและเสี่ยงตัวเองเพราะตอนนี้ผู้บริหารอาจมองฉันว่า "ช้า" ฟิสิคัลไฟล์บนเซิร์ฟเวอร์แตกต่างกันในวิธีที่ไม่รู้จักมากกว่า ~ 100 ไฟล์ การผสานต้องการความรู้เกี่ยวกับโครงการในมือและดังนั้นความร่วมมือของนักพัฒนาซอฟต์แวร์ซึ่งฉันไม่สามารถทำได้ โครงการอื่น ๆ หลุดออกจากกัน นักพัฒนายังคงมีความไม่ไว้วางใจในการควบคุมแหล่งที่มาและทำให้เกิดปัญหาโดยไม่ได้ใช้ตัวควบคุมแหล่งที่มา นักพัฒนาให้เหตุผลว่าการใช้การควบคุมแหล่งที่มานั้นสิ้นเปลืองเพราะการผสานนั้นเกิดข้อผิดพลาดได้ง่ายและยาก นี่เป็นจุดที่ยากที่จะโต้แย้งเนื่องจากเมื่อการควบคุมแหล่งที่มานั้นไม่ถูกต้องใช้อย่างไม่ถูกต้องและการควบคุมแหล่งที่มาข้ามอย่างต่อเนื่องมันเป็นข้อผิดพลาดได้ง่ายแน่นอน ดังนั้นหลักฐาน "พูดเพื่อตัวเอง" ในมุมมองของพวกเขา นักพัฒนายืนยันว่าการปรับเปลี่ยนรหัสเซิร์ฟเวอร์โดยตรงการเลี่ยง TFS จะช่วยประหยัดเวลา นี่เป็นเรื่องยากที่จะโต้แย้ง เนื่องจากการรวมที่จำเป็นในการซิงโครไนซ์รหัสที่จะเริ่มต้นนั้นใช้เวลานาน …

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.