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

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

50 sql  orm  entity-framework 

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

50 project-management  code-ownership 

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

50 open-source 

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

50 issue-tracking  workflows  svn 

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

50 agile  planning 

ฉันเริ่มเรียน Scheme ด้วยวิดีโอ SICP และฉันต้องการย้ายไปยัง Common Lisp ต่อไป ภาษาดูเหมือนจะน่าสนใจมากและผู้คนส่วนใหญ่เขียนหนังสือเกี่ยวกับภาษานั้นเพื่อสนับสนุนว่ามีพลังในการแสดงออกที่ไม่มีใครเทียบ CL ดูเหมือนว่าจะมีไลบรารีมาตรฐานที่ดี ทำไม Lisp ไม่แพร่หลายมากขึ้น? ถ้ามันมีพลังจริงๆผู้คนควรจะใช้มันให้จบ แต่มันแทบจะเป็นไปไม่ได้เลยที่จะหาพูดว่า Lisp job jobs ฉันหวังว่ามันจะไม่ใช่แค่วงเล็บเพราะมันไม่ได้เป็นปัญหาใหญ่หลังจากผ่านไปสักครู่

50 programming-languages  lisp  usage 

ฉันพบว่าตัวเองล้าหลังในเรื่องทักษะเทคนิคคุณสมบัติทางภาษา ฯลฯ และฉันกำลังหาเวลาที่จะทำเช่นนั้น ระหว่างการทำงานความเป็นมืออาชีพความเป็นส่วนตัวและความผูกพันในครอบครัวฉันโชคดีที่พบเวลาจรจัดไม่กี่ชั่วโมงที่นี่และที่นั่นเพื่อมุ่งเน้นไปที่เทคโนโลยีใหม่ ๆ หรือการอ่านที่ฉันต้องการหรือจำเป็นต้องทำ ฉันทำให้กลุ่มผู้ใช้ในท้องถิ่นที่เกี่ยวข้องมีความเกี่ยวข้อง แต่บางครั้งก็ยากที่จะเข้าถึง ดังนั้นฉันคิดว่าฉันจะถามชุมชนที่ไหนหรือเมื่อไหร่คุณหาเวลาให้ความสำคัญกับการสร้างเสริมทักษะหรือเรียนรู้สิ่งใหม่ ๆ หรือไม่? คุณจัดตารางเวลาหรือไม่? ละทิ้งการนอนหลับในช่วงสัปดาห์หรือวันหยุดสุดสัปดาห์? นอนไม่หลับ? อื่น ๆ อีก? แก้ไขฉันอยากจะขอบคุณทุกท่านที่ใช้เวลาในการตอบและเสนอคำแนะนำของคุณ มีบางสิ่งที่ฉันรู้หรือนึกถึงและมีบางสิ่งที่ฉันไม่ได้พิจารณาว่าเป็นตัวเลือกจนกว่าคุณจะแสดงความเห็นใหม่ แก้ไข 2:ในการพยายามค้นหาคำตอบที่ดีที่สุดที่ฉันยอมรับฉันไปกับ @ Paddyslacker's เนื่องจากเป็นสิ่งที่ฉันรู้สึกว่าเหมาะสมที่สุดสำหรับสถานการณ์ปัจจุบันของฉันแม้ว่าทุกคนมีนักเก็ตที่ดีมากเช่น @ Elisha @Martin หรือ @ dash-tom-bang

50 learning  free-time 

ฉันได้รับความกระตือรือร้นอย่างมากเกี่ยวกับภาษาการเขียนโปรแกรมที่ใช้งานได้เมื่อไม่นานมานี้เกี่ยวกับ Scala, Clojure และ F # ฉันเพิ่งเริ่มเรียน Haskell เพื่อเรียนรู้กระบวนทัศน์ของ FP ฉันรักมันสนุกจริงๆและเหมาะกับพื้นหลังคณิตศาสตร์ของฉัน แต่มันจะสำคัญหรือไม่ เห็นได้ชัดว่ามันเป็นความคิดใหม่แทบจะไม่ นี่คือคำถามของฉัน: อะไรเป็นสาเหตุของความกระตือรือร้นของ FP เมื่อเร็ว ๆ นี้? เป็นเพียงความเบื่อหน่ายกับ OO หรือมีบางสิ่งบางอย่างเปลี่ยนไปเพื่อให้ FP ต้องการมากกว่าเดิมหรือไม่? สิ่งนี้บ่งบอกถึงอนาคตของ FP หรือไม่ หรือนี่คือแฟชั่นเช่นฐานข้อมูล Object Object หรือไม่ ในคำอื่น ๆ ทุกคนสามารถช่วยให้ฉันเข้าใจว่าสิ่งนี้มาจากไหนและมันอาจจะไปที่ไหน

50 functional-programming 

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

50 maintenance  development-methodologies 

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

50 self-improvement  problem-solving 

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

50 agile  pair-programming 

ผมกำลังมองไปที่ WPF MVVM กรอบCaliburn.Microและอ่านที่มากของสิ่งที่มาตรฐานจะขึ้นอยู่กับการตั้งชื่อ ตัวอย่างเช่นการโยงคุณสมบัติโดยอัตโนมัติใน View to properties ใน ViewModel แม้ว่าสิ่งนี้จะสะดวก (เอารหัสสำเร็จรูปบางส่วนออกไป) แต่ปฏิกิริยาแรกของฉันคือว่ามันไม่ชัดเจนนักกับโปรแกรมเมอร์ใหม่ที่จะอ่านรหัสนี้ กล่าวอีกนัยหนึ่งฟังก์ชันการทำงานของแอปพลิเคชันไม่ได้อธิบายอย่างสมบูรณ์ด้วยรหัสของตัวเอง แต่ยังรวมถึงเอกสารประกอบของกรอบงานด้วย แก้ไข: ดังนั้นวิธีนี้เรียกว่าการประชุมเรื่องการตั้งค่า เนื่องจากฉันไม่พบคำถามใด ๆ เกี่ยวกับเรื่องนี้ฉันจึงเปลี่ยนคำถามของฉัน: คำถามของฉันคือ: การประชุมผ่านการตั้งค่าเป็นวิธีที่ถูกต้องในการทำให้สิ่งต่าง ๆ ง่ายขึ้นหรือเป็นการละเมิดหลักการเขียนโปรแกรมบางอย่าง (และถ้าเป็นเช่นนั้นข้อใด)

50 patterns-and-practices 

บางคนสามารถอธิบายเหตุผลที่เป็นรูปธรรมได้ว่าทำไม BDFL จึงเลือกที่จะสร้าง Python lambdas บรรทัดเดียว? ดีจัง: lambda x: x**x ซึ่งส่งผลให้เกิดข้อผิดพลาด: lambda x: x**x ฉันเข้าใจว่าการสร้างแลมบ์ดาหลายบรรทัดจะ "รบกวน" กฎการเยื้องตามปกติและจะต้องเพิ่มข้อยกเว้นเพิ่มเติม แต่นั่นไม่คุ้มกับผลประโยชน์หรือไม่ ดูจาวาสคริปต์เช่น เราจะอยู่ได้อย่างไรถ้าไม่มีฟังก์ชั่นที่ไม่ระบุชื่อ พวกมันขาดไม่ได้ Pythonistas ไม่ต้องการกำจัดการตั้งชื่อฟังก์ชั่นหลายบรรทัดทุกบรรทัดเพื่อส่งผ่านการโต้แย้งใช่ไหม

50 lambda  python 

เมื่อคุณใช้เครื่องมือเช่นjsdocsมันจะสร้างไฟล์ HTML แบบคงที่และสไตล์ของมันใน codebase ของคุณตามความคิดเห็นในรหัสของคุณ ควรตรวจสอบไฟล์เหล่านี้ในที่เก็บ Git หรือไม่หรือควรละเว้นด้วย. gitignore

49 git  documentation 

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

49 java  reflection