คำถามติดแท็ก development-process

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

29 development-process  tdd  refactoring 

เป็นวิธีปฏิบัติที่ดีหรือไม่ที่จะใช้ #ifdef ระหว่างการพัฒนาเพื่อสลับไปมาระหว่างพฤติกรรมประเภทต่าง ๆ ? ตัวอย่างเช่นฉันต้องการเปลี่ยนพฤติกรรมของรหัสที่มีอยู่ฉันมีความคิดหลายอย่างเกี่ยวกับวิธีการเปลี่ยนพฤติกรรมและจำเป็นต้องสลับระหว่างการใช้งานที่แตกต่างกันเพื่อทดสอบและเปรียบเทียบวิธีการที่แตกต่างกัน การเปลี่ยนแปลงรหัสมักจะซับซ้อนและมีผลต่อวิธีการต่าง ๆ ในไฟล์ที่แตกต่างกัน ฉันมักจะแนะนำตัวระบุหลายตัวและทำอะไรแบบนั้น void foo() { doSomething1(); #ifdef APPROACH1 foo_approach1(); #endif doSomething2(); #ifdef APPROACH2 foo_approach2(); #endif } void bar() { doSomething3(); #ifndef APPROACH3 doSomething4(); #endif doSomething5(); #ifdef APPROACH2 bar_approach2(); #endif } int main() { foo(); bar(); return 0; } วิธีนี้ช่วยให้สามารถสลับไปมาระหว่างวิธีการต่าง ๆ ได้อย่างรวดเร็วและทำทุกอย่างในสำเนาของซอร์สโค้ดเดียว มันเป็นแนวทางที่ดีสำหรับการพัฒนาหรือมีแนวปฏิบัติที่ดีกว่านี้หรือไม่?

28 c++  programming-practices  development-process 

ฉันเป็นนักวิชาการมากกว่าโปรแกรมเมอร์และฉันมีประสบการณ์หลายปีในการเขียนโปรแกรม Python สำหรับใช้เองเพื่อสนับสนุนงานวิจัยของฉัน โปรเจ็กต์ล่าสุดของฉันน่าจะมีประโยชน์กับคนอื่น ๆ เช่นฉันและฉันกำลังคิดว่าจะปล่อยมันเป็นไลบรารี่แบบโอเพ่นซอร์ส อย่างไรก็ตามดูเหมือนว่ามีอุปสรรคบางอย่างที่จะข้ามไปจากโครงการส่วนตัวที่ใช้งานได้ไปจนถึงห้องสมุดที่สามารถติดตั้งและใช้งานได้โดยไม่เจ็บปวด คำถามนี้เกี่ยวกับขั้นตอนแรกที่ฉันควรทำเพื่อเริ่มทำงานสู่รุ่นสาธารณะ ขณะนี้ฉันมีที่เก็บคอมไพล์เดียวซึ่งมีรหัสของฉันที่ใช้ไลบรารีรวมทั้งไลบรารีเองและฉันใช้ git เป็นปุ่มเลิกทำฉุกเฉินในกรณีที่มีอะไรผิดพลาด ทั้งหมดนี้ใช้งานได้ดีสำหรับผู้ใช้คนเดียว แต่เห็นได้ชัดว่าไม่เหมาะสมถ้าฉันต้องการปล่อย ที่ฉันต้องการจะจบคือห้องสมุดของฉันอยู่ในที่เก็บแยกต่างหากและสามารถติดตั้งโดยผู้อื่นโดยใช้pipและมี API ที่มั่นคง การเรียนรู้ที่จะใช้ setuptools เป็นต้นอาจไม่ยากเมื่อฉันถึงจุดที่ต้องการเผยแพร่มัน - ปัญหาของฉันคือการรู้ว่าฉันควรทำงานอย่างไรเพื่อที่จะไปถึงจุดนั้น ดังนั้นคำถามของฉันคือขั้นตอนแรกที่ควรทำเพื่อเริ่มเตรียมโครงการห้องสมุด Python สำหรับการบริโภคสาธารณะคืออะไร ฉันจะจัดระเบียบโครงสร้างไดเรกทอรีของฉัน, git repository และอื่น ๆ เพื่อที่จะเริ่มทำงานในที่สาธารณะต่อการเปิดตัวไลบรารี่? โดยทั่วไปแล้วจะมีประโยชน์มากหากมีทรัพยากรที่ทราบว่ามีประโยชน์เมื่อพยายามทำสิ่งนี้เป็นครั้งแรก ตัวชี้ไปยังแนวปฏิบัติที่ดีที่สุดและข้อผิดพลาดที่ควรหลีกเลี่ยง ฯลฯ จะเป็นประโยชน์อย่างมาก การชี้แจงบางอย่าง:คำตอบปัจจุบันกำลังตอบคำถามตามแนวของ "ฉันจะทำให้ห้องสมุด Python ของฉันเป็นที่ดีสำหรับผู้อื่นในการใช้งานได้อย่างไร" สิ่งนี้มีประโยชน์ แต่แตกต่างจากคำถามที่ฉันตั้งใจจะถาม ขณะนี้ฉันกำลังเริ่มต้นการเดินทางที่ยาวนานเพื่อปล่อยโครงการของฉัน แกนกลางของการทำงานของฉัน (และทำงานได้ดีจริงๆ) แต่ฉันรู้สึกท่วมท้นจากจำนวนงานที่ทำอยู่ข้างหน้าของฉันและฉันกำลังมองหาคำแนะนำเกี่ยวกับวิธีนำทางกระบวนการ ตัวอย่างเช่น: ขณะนี้รหัสห้องสมุดของฉันอยู่คู่กับรหัสเฉพาะโดเมนของฉันที่ใช้งาน มันอาศัยอยู่ในโฟลเดอร์ย่อยและแชร์ที่เก็บ git เดียวกัน ในที่สุดมันจะต้องถูกทำให้เป็นไลบรารีแบบสแตนด์อะโลนและใส่ลงในที่เก็บของมันเอง …

28 python  programming-practices  development-process 

ฉันมีปัญหากับเพื่อนร่วมทีม เรื่องสั้นสั้น: เราเป็นนักเรียนสามคนที่ทำงานในโครงการเพื่อการแข่งขัน โครงการประกอบด้วยแอพพลิเคชั่นแยกกัน 2 แอพ: หนึ่งอันสำหรับ Windows (ที่ฉันพัฒนา) และอีกอันสำหรับ Android (เพื่อนร่วมงานของฉันมีหน้าที่รับผิดชอบในการพัฒนา) ฐานรหัสของเราจะไม่ตัดกันแอพจะสื่อสารผ่านเครื่องมือของบุคคลที่สาม ปัญหามีดังนี้ฉันมีประสบการณ์การทำงานเป็นทีมในขณะที่ฉันฝึกงานที่ บริษัท ใหญ่เมื่อปีที่แล้วและฉันพยายามบังคับใช้มาตรฐานการเข้ารหัสสำหรับรหัสของเรา ฉันยังตั้งค่าซอฟต์แวร์ที่เก็บ git / wiki / การทำงานร่วมกันที่เราสามารถใช้เพื่อผลักดันรหัส / เขียนความคิดโปรโตคอลเอกสารและอื่น ๆ แต่ดูเหมือนว่าฉันเป็นคนเดียวที่ใช้เครื่องมือเหล่านี้ ฉันพยายามบอกพวกเขาว่าการเขียนรหัสคุณภาพและการบันทึกทุกขั้นตอนจะเป็นประโยชน์ต่อเราในระยะยาว แต่พวกเขาดูเหมือนจะไม่เห็นประโยชน์ของมัน นอกจากนี้ฉันกำลังคิดที่จะเพิ่มการทดสอบการรวมบางอย่าง แต่จากสิ่งที่ฉันเห็นได้ตราบใดที่พวกเขาไม่ได้ใช้เครื่องมือปัจจุบันเพื่อทำให้ชีวิตของพวกเขาง่ายขึ้นฉันไม่คิดว่าฉันจะสามารถโน้มน้าวให้พวกเขามีประโยชน์ รหัสส่วนใหญ่ของคนรอบข้างอยู่ในคอมพิวเตอร์พวกเขาไม่แชร์ฐานรหัสทั่วไปและเมื่อฉันค้นพบพวกเขารวมชิ้นส่วนของตนโดยการประชุมและแบ่งปันรหัสผ่าน usb stick คำถามของฉันคือ: ฉันรุนแรงเกินไปในเรื่องนี้หรือไม่? ฉันจะบังคับใช้กฎบางอย่างที่ไร้สาระหรือไม่? โปรดทราบว่านี่เป็นโครงการขนาดเล็กข้อกำหนดมีความชัดเจนมาก (ฉันสร้างเอกสารที่ระบุว่าแอปพลิเคชันควรทำอะไร) นักพัฒนาที่มีทักษะสามคนสามารถทำได้ใน 3-4 วันดังนั้นพวกเขาอาจไม่เห็นความซับซ้อนเพิ่มขึ้นในการเขียนคุณภาพ รหัสตราบเท่าที่วิธีการปัจจุบันของพวกเขาใช้งานได้ มีวิธีใดบ้างที่ฉันสามารถแสดงให้พวกเขาเห็นถึงประโยชน์ของการจัดทำรหัสการใช้ git และอื่น ๆ ?

28 programming-practices  development-process  teamwork 

บางครั้งเมื่อฉันมีปัญหาที่ต้องแก้ไขฉันพบว่าวิธีที่ง่ายที่สุดในการแก้ปัญหาคือการเขียนโปรแกรมเล็ก ๆ เป็นเครื่องมือส่วนตัว ฉันไม่ได้ทำให้มันใช้งานได้ดีหรือแข็งแกร่งมากเท่าที่ฉันเป็นคนเดียวที่จะใช้มันและฉันไม่มีเวลาที่จะปรับแต่งและทดสอบอย่างละเอียด จากนั้นเพื่อนร่วมงานจะเห็นโปรแกรมและถามหาเพราะเขาพบปัญหาเดียวกันและเครื่องมือสามารถช่วยได้ ฉันบอกเขาว่า "มันไม่สวย แต่มันจะทำให้งานสำเร็จ" ข้อจำกัดความรับผิดชอบและปล่อยให้เขาได้รับมัน สิ่งต่อไปที่ฉันรู้ผู้บังคับบัญชาของฉันโทรหาฉันบอกฉันว่าเขากำลังพยายามทำให้ซอฟต์แวร์ทำงานบนคอมพิวเตอร์ของลูกค้า แต่มันแสดงข้อความข้อผิดพลาด X วะ ?? ซอฟต์แวร์ดังกล่าวยังไม่พร้อมสำหรับการเปิดตัวและฉันไม่ได้บอกว่ามันต้องพร้อมสำหรับการเปิดตัว แต่ด้วยเหตุผลบางอย่างหัวหน้าของฉันคิดว่ามันดีพอและเปิดตัวโดยไม่บอกนักพัฒนาดั้งเดิม MessageBox.Show("DO NOT GIVE TO CLIENTS!");ตอนนี้ปัญหานี้โดยเฉพาะอย่างยิ่งเป็นเรื่องง่ายที่จะแก้ไขด้วย อย่างไรก็ตามปัญหาดังกล่าวบ่งบอกถึงปัญหาที่ลึกซึ้งยิ่งขึ้น: วัฒนธรรม บริษัท ของเราไม่ราบรื่น ซอฟต์แวร์เลอะเทอะตกลงและกระบวนการเลอะเทอะตกลง ไม่ต้องกังวลเกี่ยวกับอนาคตลองใช้ความพยายามอย่างเต็มที่เพื่อให้มันทำงานได้ไม่เต็มที่วางไบนารีในไฟล์. zip แล้วส่งไป ดีพอสำหรับงานราชการ นี่เป็น บริษัท เล็ก ๆ ที่มีพนักงานเต็มเวลา 10 คนกำลังเติบโตและได้อยู่พักหนึ่ง อย่าเข้าใจฉันผิด ฉันรักการทำงานที่นี่และฉันรัก บริษัท อย่าบอกให้ฉันวิ่ง ฉันต้องการเป็นส่วนหนึ่งในการทำให้ บริษัท ดีขึ้น คุณจะเริ่มนำการเปลี่ยนแปลงที่ดีมาสู่วัฒนธรรมประเภทนี้ได้อย่างไร?

28 development-process  communication  business-process 

ฉันกำลังทำงานในโครงการซอฟต์แวร์ขนาดใหญ่ซึ่งได้รับการปรับแต่งอย่างดีสำหรับลูกค้าที่หลากหลายทั่วโลก ซึ่งหมายความว่าเราอาจมีรหัส 80% ซึ่งเป็นเรื่องปกติระหว่างลูกค้าหลายราย แต่ยังมีรหัสจำนวนมากที่ต้องเปลี่ยนจากลูกค้ารายหนึ่งเป็นลูกค้ารายอื่น ในอดีตที่ผ่านมาเราทำการพัฒนาของเราในที่เก็บแยกต่างหาก (SVN) และเมื่อโครงการใหม่เริ่มต้น (เรามีน้อย แต่ลูกค้าขนาดใหญ่) สร้างพื้นที่เก็บข้อมูลอื่นตามโครงการที่ผ่านมามีพื้นฐานรหัสที่ดีที่สุดสำหรับความต้องการของเรา สิ่งนี้ได้ผลในอดีต แต่เราพบปัญหาหลายประการ: ข้อบกพร่องที่ได้รับการแก้ไขในที่เก็บหนึ่งจะไม่ได้รับการแก้ไขในที่เก็บอื่น ๆ นี่อาจเป็นปัญหาขององค์กร แต่ฉันพบว่ามันยากที่จะแก้ไขและแก้ไขข้อบกพร่องในที่เก็บ 5 แห่งที่แตกต่างกันโดยคำนึงว่าทีมที่ดูแลพื้นที่เก็บข้อมูลนี้อาจอยู่ในอีกส่วนหนึ่งของโลกและเราไม่มีสภาพแวดล้อมการทดสอบ ไม่ทราบกำหนดการหรือข้อกำหนดที่ต้องมี ("ข้อบกพร่อง" ในประเทศหนึ่งอาจเป็น "คุณสมบัติ" ในอีกประเทศหนึ่ง) คุณสมบัติและการปรับปรุงที่ทำไว้สำหรับโครงการหนึ่งซึ่งอาจเป็นประโยชน์สำหรับโครงการอื่นหายไปหรือหากใช้ในโครงการอื่นมักทำให้เกิดอาการปวดหัวขนาดใหญ่รวมจากรหัสฐานหนึ่งไปยังอีกโครงการหนึ่ง (เนื่องจากทั้งสองสาขาอาจได้รับการพัฒนาอย่างอิสระเป็นเวลาหนึ่งปี ) Refactorings และการปรับปรุงรหัสที่ทำในสาขาการพัฒนาหนึ่งอาจสูญหายหรือก่อให้เกิดอันตรายมากกว่าดีถ้าคุณต้องรวมการเปลี่ยนแปลงทั้งหมดเหล่านี้ระหว่างสาขา ขณะนี้เรากำลังพูดถึงวิธีการแก้ปัญหาเหล่านี้และในขณะนี้ได้มีแนวคิดต่อไปนี้เกี่ยวกับวิธีการแก้ไขปัญหาดังกล่าว: ทำการพัฒนาในสาขาที่แยกกันแต่จัดระเบียบได้ดีขึ้นด้วยการมีที่เก็บส่วนกลางที่มีการแก้ไขข้อบกพร่องทั่วไปและรวมโครงการทั้งหมดเข้าด้วยกันการเปลี่ยนแปลงจากที่เก็บส่วนกลางนี้เป็นของตัวเองเป็นประจำ (เช่นทุกวัน) เรื่องนี้ต้องมีวินัยอย่างมากและมีความพยายามอย่างมากในการผสานระหว่างสาขา ดังนั้นฉันไม่มั่นใจว่ามันจะทำงานได้และเราสามารถรักษาวินัยนี้โดยเฉพาะอย่างยิ่งเมื่อเวลากดดัน ละทิ้งการพัฒนาแยกสาขาและมีที่เก็บรหัสกลางที่รหัสของเราทั้งหมดอยู่และทำการปรับแต่งของเราโดยมีโมดูลที่เสียบได้และตัวเลือกการกำหนดค่า เรากำลังใช้คอนเทนเนอร์การพึ่งพาการพึ่งพาเพื่อแก้ไขการพึ่งพาในรหัสของเราและเรากำลังติดตามรูปแบบ MVVM ในรหัสส่วนใหญ่ของเราเพื่อแยกตรรกะทางธุรกิจออกจาก UI ของเราอย่างหมดจด วิธีที่สองดูเหมือนจะสง่างามกว่า แต่เรามีปัญหาที่ยังไม่คลี่คลายในแนวทางนี้ ตัวอย่างเช่นวิธีจัดการกับการเปลี่ยนแปลง / การเพิ่มเติมในแบบจำลอง / ฐานข้อมูลของคุณ เราใช้. NET กับ …

28 design  architecture  development-process  database-design  code-organization 

ปิด คำถามนี้เป็นคำถามความคิดเห็นตาม ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้สามารถตอบข้อเท็จจริงและการอ้างอิงได้โดยแก้ไขโพสต์นี้ ปิดให้บริการใน6 ปีที่ผ่านมา การตรวจสอบการป้อนข้อมูลเป็นเรื่องยากสำหรับฉัน ในการเพิ่มกรอบความปลอดภัยและรหัสจริงลงในโครงการเขียนแอปพลิเคชันดั้งเดิมของเรา (ซึ่งตอนนี้ค่อนข้างจะรักษารหัสรักษาความปลอดภัยดั้งเดิมและการตรวจสอบความถูกต้องของข้อมูล) ฉันสงสัยอีกครั้งว่าควรจะตรวจสอบมากแค่ไหน ที่ไหน ฯลฯ ตลอด 5 ปีที่ฉันเป็นนักพัฒนา Java มืออาชีพฉันได้สร้างและปรับปรุงกฎส่วนบุคคลของฉันสำหรับการตรวจสอบความถูกต้องของข้อมูลและมาตรการรักษาความปลอดภัย เมื่อฉันต้องการปรับปรุงวิธีการของฉันฉันอยากได้ยินความคิดเห็นจากพวกคุณ กฎและโพรซีเดอร์ทั่วไปนั้นใช้ได้ดีและจาวาเฉพาะก็เช่นกัน สรุปนี่คือแนวทางของฉัน (เปิดเผยในรูปแบบเว็บแอปพลิเคชัน 3 ระดับ) พร้อมคำอธิบายสั้น ๆ : ฝั่งไคลเอ็นต์ชั้นที่ 1 (เบราว์เซอร์): การตรวจสอบความถูกต้องน้อยที่สุด, กฎที่ไม่เปลี่ยนแปลงเท่านั้น (ฟิลด์อีเมลบังคับ, ต้องเลือกหนึ่งรายการ, และอื่น ๆ ที่คล้ายกัน); การใช้การตรวจสอบเพิ่มเติมเช่น "ระหว่าง 6 ถึง 20 ตัวอักษร" น้อยลงเนื่องจากจะเป็นการเพิ่มการบำรุงรักษาในการเปลี่ยนแปลง (อาจเพิ่มเมื่อรหัสธุรกิจมีเสถียรภาพ); ฝั่งเซิร์ฟเวอร์ระดับที่ 1 (การจัดการการสื่อสารผ่านเว็บ "ตัวควบคุม"): ฉันไม่มีกฎสำหรับอันนี้ …

28 development-process  language-agnostic  security  data  validation 

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

27 development-process  code-quality  source-code  code-smell  code-ownership 

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

27 development-process 

มีใครสามารถอธิบายเกี่ยวกับวิธีการแบบเปรียวในประโยคง่ายๆ

27 development-process  agile 

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

26 development-process  code-reviews 

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

26 programming-practices  development-process  documentation  source-code  sdlc 

ฉันไม่แน่ใจว่านี่เป็นสถานที่สำหรับถามคำถามเชิงแนวคิดต่อไปนี้ (Stackoverflow ไม่แน่นอน) ฉันเห็นคำถามนี้ในการสอบแบบปรนัย (คำตอบเดียว) คล้ายกับการสอบISTQB : เหตุใดจึงไม่แนะนำให้รายงานข้อบกพร่องต่าง ๆ ในปัญหา / ตั๋วเดียวกัน เพื่อให้รายงานมีความกระชับและชัดเจน ข เนื่องจากผู้พัฒนาอาจแก้ไขข้อบกพร่องเพียงข้อเดียว ค เนื่องจากผู้ทดสอบกลุ่มทดสอบได้รับการจัดอันดับตามจำนวนข้อบกพร่องที่พบ d ระบบการจัดการข้อบกพร่องไม่สนับสนุนคุณสมบัตินี้ของข้อบกพร่องหลายรายการ ความเห็นของฉันaคือคำตอบที่ถูกต้อง b- ไม่สามารถทำได้เนื่องจากการแก้ไขข้อเสนอแนะที่แก้ไขแล้วปิดควรหลีกเลี่ยงกรณีดังกล่าว c- ผิดอย่างชัดเจน d - ปลั๊กอิน Redmine / Trac รองรับหลายฟิลด์ bคำตอบตามแผ่นคำตอบคือ มีคนอธิบายได้ไหม ความคิดเห็นที่มีความคิดเห็นเกี่ยวกับคำตอบยินดีต้อนรับ

26 testing  development-process  bug-report 

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

26 project-management  development-process  time  estimation  sdlc 

การใช้รหัสซ้ำเป็นปัญหา ฉันคิดเกี่ยวกับคำถามนี้ในการส่งมอบซอฟต์แวร์และผมเก็บไว้กลับไปที่ปัญหาของการเข้ามาทำซ้ำและ / หรือการทำซ้ำ มันสำคัญเพราะถ้าคุณไม่ทำซ้ำโครงการมันจะยากขึ้นในการปรับปรุงกระบวนการที่คุณใช้ในการสร้างโครงการ วิศวกรรมเกี่ยวข้องกับการปรับปรุงกระบวนการที่เกี่ยวข้องกับการออกแบบและการก่อสร้างอย่างต่อเนื่องเพื่อผลิตโครงการที่มีคุณภาพสูงขึ้น ซอฟต์แวร์สามารถพึ่งพาอย่างหนักเมื่อนำมาใช้ใหม่เนื่องจากรูปแบบดิจิทัล แทนที่จะเขียนโมดูลเราเพียงเรียกมันอีกครั้งหรือคัดลอกไปยังระบบอื่น ตัวอย่างบางส่วนคือการรับรองความถูกต้อง / เข้าสู่ระบบหรืออาจเป็นฟังก์ชั่นการบันทึก มีตัวอย่างมากมายที่เป็นที่รู้จักกันดีสำหรับประเภทเหล่านั้นและภูมิปัญญาดั้งเดิมคือการนำสิ่งที่มีอยู่กลับมาใช้ใหม่ การเปรียบเทียบบางสาขากับสาขาอื่น การก่อสร้าง ในทางตรงกันข้ามการก่อสร้างระบบทางกายภาพ (อาคารสะพาน) ไม่ได้อยู่ใกล้แค่นำมาใช้ซ้ำ เป็นความจริงที่ว่าพิมพ์เขียวของบ้านสามารถนำกลับมาใช้ซ้ำได้หลายครั้งเพื่อสร้างสำเนาบ้านเดียวกัน แต่การก่อสร้างจะต้องดำเนินการทุกครั้ง ตัดและวางไม่ทำงานอย่างนั้นในโลกอะนาล็อก พิมพ์เขียว Bridge เป็นการนำกลับมาใช้ใหม่ได้น้อยกว่าเนื่องจากสภาพของไซต์จะแตกต่างกันไป ผู้สร้างต้นแบบเป็นผู้เชี่ยวชาญที่ได้รับการยอมรับว่ามีการออกแบบและ / หรือสร้างสิ่งของหลายสิบหลายร้อยหรือหลายพันรายการ ยกตัวอย่างเช่นFrank Lloyd Wrightdesigned more than 1,000 structures and completed 532 worksโลกสถาปนิกที่มีชื่อเสียงและนักออกแบบ เปรียบเทียบกับAnders Hejlsbergผู้ออกแบบ“ just” ห้าภาษา (Turbo Pascal; Delphi; J ++; C #; Typescript) เป็นการเปรียบเทียบที่ไม่ยุติธรรมเนื่องจากหลายโดเมนแตกต่างกัน …

25 development-process  code-reuse