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

ฉันรู้ว่าบางคนกำลังทำงานในโครงการสำหรับกองทัพสหรัฐฯ (ระดับความปลอดภัยต่ำข้อมูลประเภททรัพยากรมนุษย์ที่ไม่ต่อสู้) สถานะเริ่มต้นของรหัสโครงการถูกส่งไปยังทหารเพื่อตรวจสอบและพวกเขาก็เรียกใช้โปรแกรมผ่านเครื่องมือวิเคราะห์ความปลอดภัยบางประเภท จะส่งคืนรายงานปัญหาความปลอดภัยที่ทราบในรหัสและการเปลี่ยนแปลงที่จำเป็นซึ่งจำเป็นต้องนำไปใช้ก่อนส่งมอบผลิตภัณฑ์ขั้นสุดท้าย หนึ่งในรายการที่จำเป็นต้องได้รับการแก้ไขคือการลบส่วนหนึ่งของโครงการที่เขียนในRubyเนื่องจากเป็นภาษาแบบไดนามิก พื้นหลัง / เหตุผลในการไม่อนุญาตให้ใช้ภาษาไดนามิกในการตั้งค่าความปลอดภัยคืออะไร นี่เป็นรัฐบาลที่นำเทคโนโลยีใหม่มาใช้ช้าหรือไม่? หรือภาษาไดนามิกมีความเสี่ยงด้านความปลอดภัยเพิ่มเติมเมื่อเทียบกับภาษาแบบคงที่ (ala C ++หรือJava ) หรือไม่

120 code-security  dynamic-languages  government 

พิจารณาฟังก์ชั่นแบบไม่มีพารามิเตอร์ ( แก้ไข:ไม่จำเป็น) ที่ดำเนินการรหัสบรรทัดเดียวและถูกเรียกเพียงครั้งเดียวในโปรแกรม (แม้ว่าจะเป็นไปไม่ได้ที่จะต้องใช้อีกครั้งในอนาคต) มันสามารถทำการสืบค้นตรวจสอบค่าบางอย่างทำบางสิ่งที่เกี่ยวข้องกับ regex ... อะไรที่คลุมเครือหรือ "แฮ็ค" เหตุผลเบื้องหลังสิ่งนี้คือการหลีกเลี่ยงการประเมินที่อ่านยาก: if (getCondition()) { // do stuff } ซึ่งgetCondition()เป็นฟังก์ชั่นหนึ่งบรรทัด คำถามของฉันคือ: นี่เป็นการปฏิบัติที่ดีหรือไม่? ดูเหมือนจะไม่เป็นไรสำหรับฉัน แต่ฉันไม่รู้เกี่ยวกับระยะยาว ...

120 functions 

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

120 communication  estimation  release-management 

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

119 version-control  git  development-process 

ตามที่รายงานเมื่อเร็ว ๆ นี้ที่นี่ : Xamarin ได้แยก Cocos2D-XNA ซึ่งเป็นกรอบการพัฒนาเกม 2D / 3D สร้างห้องสมุดข้ามแพลตฟอร์มที่สามารถรวมไว้ในโครงการ PCL อย่างไรก็ตามผู้ก่อตั้งโครงการที่ถูกแยกออกพูดว่า : วัตถุประสงค์ของใบอนุญาต MIT คือการยกเลิกการใช้งานอย่างเป็นธรรมของคุณ ไม่สนับสนุนให้คุณใช้ซอฟต์แวร์เปลี่ยนโฉมให้เป็นของคุณเองแล้ว "นำไปในทิศทางใหม่" ตามที่คุณพูด ในขณะที่ไม่ผิดกฎหมายก็ผิดจรรยาบรรณ ดูเหมือนว่าหน้า GitHub ของโครงการใหม่ไม่ได้ระบุว่ามันเป็นทางแยกในลักษณะ GitHub ทั่วไปการเลือกสำหรับส่วนประวัติที่ถอดออกได้อย่างง่ายดายแทน (ดูด้านล่าง) ดังนั้นคำถามของฉันคือ: การกระทำของ Xamarin และวิธีการกระทำนั้นถูกต้องตามหลักจริยธรรมหรือไม่? เป็นไปได้หรือไม่ที่จะหลีกเลี่ยงสถานการณ์เช่นนี้หากคุณเป็นผู้พัฒนาเดี่ยวหรือกลุ่มนักพัฒนาขนาดเล็กที่ไม่มีเงินทุน? ฉันหวังว่านี่อาจเป็นคำถามแบบ wiki หรือจะมีคำตอบที่ตรงตามวัตถุประสงค์บนพื้นฐานจริยธรรม / ปรัชญา OSS ที่ทันสมัย

119 open-source  ethics  mit-license  philosophy  forking 

ชุดรูปแบบที่เกิดขึ้นซ้ำ ๆ ใน SE ที่ฉันสังเกตเห็นในคำถามหลายข้อเป็นข้อโต้แย้งอย่างต่อเนื่องว่า C ++ นั้นเร็วกว่าและ / หรือมีประสิทธิภาพมากกว่าภาษาระดับสูงกว่าอย่าง Java ข้อโต้แย้งคือ JVM หรือ CLR ที่ทันสมัยสามารถมีประสิทธิภาพได้เช่นเดียวกับ JIT และอื่น ๆ สำหรับงานที่เพิ่มมากขึ้นและ C ++ นั้นมีประสิทธิภาพมากขึ้นถ้าคุณรู้ว่าคุณกำลังทำอะไรและทำไมการทำสิ่งต่าง ๆ จะเพิ่มประสิทธิภาพการทำบุญ นั่นชัดเจนและสมเหตุสมผลดี ฉันต้องการทราบคำอธิบายพื้นฐาน (หากมีสิ่งนั้น ... ) ว่าทำไมและอย่างไรงานบางอย่างจะเร็วขึ้นใน C ++ กว่า JVM หรือ CLR? มันเป็นเพราะ C ++ ถูกคอมไพล์เป็นรหัสเครื่องในขณะที่ JVM หรือ CLR ยังคงมีโอเวอร์เฮดของการประมวลผลของการคอมไพล์ JIT ณ รันไทม์? เมื่อฉันพยายามที่จะศึกษาหัวข้อทั้งหมดที่ฉันพบคือข้อโต้แย้งเดียวกับที่ฉันระบุไว้ข้างต้นโดยไม่มีข้อมูลรายละเอียดใด ๆ …

119 java  c++  performance  jit 

ฉันรู้สึกเหมือนถูกไฟไหม้ถึงแม้ว่าฉันจะออกจากวิทยาลัยเป็นเวลา 5 ปีเท่านั้น ในช่วง 3 ปีแรกของอาชีพการงานของฉัน ฉันไม่เคยมีอะไรพิเศษในโรงเรียน แต่ฉันรู้สึกพิเศษที่ บริษัท ของฉัน เมื่อมองย้อนกลับไปฉันสามารถบอกได้ว่าฉันทำทุกสิ่งอย่างถูกต้องแล้ว: ฉันพยายามปรับปรุงตัวเองทุกวัน ฉันทำจุดของการช่วยเหลือทุกคนที่ฉันสามารถทำได้ ฉันทำประเด็น (และอ่านหนังสือเกี่ยวกับ) เป็นสมาชิกทีมที่ดี ฉันสนุก. หลังจาก 3 ปีติดต่อกันในฐานะที่ได้รับการจัดอันดับให้เป็นพนักงานระดับสูงฉันได้แปลงทุนทางการเมืองนั้นเป็นการเลือกที่จะทำงานในโครงการที่น่าสนใจและมีเสน่ห์โดยมีนักพัฒนาเพียง 2 คนเท่านั้น: ฉันและผู้นำด้านเทคนิคอาวุโสที่น่านับถือ ฉันทำงานหนักในโครงการนั้นและมันก็ประสบความสำเร็จอย่างมาก คุณภาพสูงมีข้อบกพร่องต่ำไม่มีความล่าช้า ฯลฯ หัวหน้าฝ่ายเทคโนโลยีอาวุโสได้รับการโปรโมตครั้งสำคัญและโบนัส GIGANTIC ฉันไม่ได้อะไรเลย. ฉันผิดหวังมากที่ฉันหยุดใส่ใจ ในปีที่ผ่านมาฉันเพิ่งลอยไป ในช่วง 4 ปีแรกของฉันฉันรู้สึกมีพลังหลังจากผ่านไป 10 วัน ตอนนี้ฉันแทบจะไม่ใส่ใจที่จะทำงาน 6 ชั่วโมงต่อวัน คำแนะนำใด ๆ? ฉันไม่รู้ด้วยซ้ำว่าฉันถามอะไร ฉันแค่หวังว่าคนฉลาดจะเห็นสิ่งนี้และส่งสติปัญญาบางส่วนให้ฉัน

119 productivity 

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

118 design-patterns  architecture  dependency-injection 

มีเหตุผลด้านวิศวกรรมใด ๆ ทำไมมันเป็นเช่นนั้น? ฉันสงสัยในกรณีของ RDBMS ว่ามีบางอย่างเกี่ยวกับการแสดงเนื่องจาก "YEAR" มีความเฉพาะเจาะจงมากกว่า "MONTH" เช่นคุณมีเพียงหนึ่งปี 2000 แต่ทุกปีมี "มกราคม" ซึ่งจะทำให้ง่ายขึ้น / เร็วขึ้นในการกรอง / เรียงลำดับบางสิ่งบางอย่างในปีแรกและนั่นเป็นสาเหตุที่ปีนี้มาก่อน แต่ฉันไม่รู้ว่ามันสมเหตุสมผลจริงหรือ ... มีเหตุผลอะไรบ้าง?

118 sql  engineering  rdbms  date-format 

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

118 project-management  version-control  development-process 

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

118 programming-languages  language-design 

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

118 design  language-agnostic  error-handling 

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

118 refactoring  clean-code 

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

118 anti-patterns  code-generation 

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

117 version-control  branching  solo-development