คำถามติดแท็ก language-agnostic

แท็กนี้มีไว้สำหรับคำถามที่ไม่เฉพาะกับภาษาการเขียนโปรแกรมหรือสภาพแวดล้อม

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

20
`การแตก 'และ` การปฏิบัติการ' ที่แย่ ๆ
เจ้านายของฉันพูดถึงอย่างเมินเฉยว่าโปรแกรมเมอร์ที่ไม่ดีใช้breakและcontinueวนซ้ำ ฉันใช้มันตลอดเวลาเพราะมันสมเหตุสมผล ให้ฉันแสดงแรงบันดาลใจ: function verify(object) { if (object->value < 0) return false; if (object->value > object->max_value) return false; if (object->name == "") return false; ... } จุดที่นี่คือก่อนอื่นฟังก์ชันตรวจสอบว่าเงื่อนไขถูกต้องจากนั้นดำเนินการฟังก์ชันการทำงานจริง IMO เช่นเดียวกับลูป: while (primary_condition) { if (loop_count > 1000) break; if (time_exect > 3600) break; if (this->data == "undefined") continue; if (this->skip == …

18
มีข้อแก้ตัวสำหรับชื่อตัวแปรสั้น ๆ หรือไม่?
สิ่งนี้กลายเป็นความสับสนอย่างใหญ่หลวงกับโค้ดเบสที่ฉันกำลังทำงานอยู่ ชื่อตัวแปรหลายชื่อของเรานั้นสั้นและไม่มีคำอธิบาย ฉันเป็นนักพัฒนาเพียงคนเดียวที่เหลืออยู่ในโครงการและไม่มีเอกสารเกี่ยวกับสิ่งที่พวกเขาส่วนใหญ่ทำดังนั้นฉันต้องใช้เวลาเพิ่มเติมเพื่อติดตามสิ่งที่พวกเขาเป็นตัวแทน ตัวอย่างเช่นฉันอ่านโค้ดบางตัวที่อัพเดตนิยามของผิวหน้าออปติคัล ตัวแปรที่ตั้งไว้ที่จุดเริ่มต้นมีดังนี้: double dR, dCV, dK, dDin, dDout, dRin, dRout dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1)); dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1)); ... and so on อาจจะเป็นเพียงฉัน แต่มันก็บอกฉันว่าไม่มีอะไรเกี่ยวกับสิ่งที่พวกเขาเป็นตัวแทนซึ่งทำให้การทำความเข้าใจโค้ดยากขึ้น ทั้งหมดที่ฉันรู้คือมันเป็นตัวแปรที่แยกวิเคราะห์เฉพาะแถวจากตารางที่ระบุที่ไหนสักแห่ง หลังจากการค้นหาบางฉันพบสิ่งที่พวกเขาหมายถึง: dR = radius dCV = curvature dK = conic constant dDin = inner aperture dDout = outer aperture dRin = inner radius dRout …

10
เป็นความคิดที่ดีที่จะบังคับให้มีการรวบรวมขยะเมื่อใด
ดังนั้นผมอ่านคำถามเกี่ยวกับการบังคับให้ C # เก็บขยะในการทำงานที่เกือบทุกคำตอบเดียวเหมือนกัน: คุณสามารถทำมัน แต่คุณไม่ควร - ยกเว้นบางกรณีที่หายากมาก น่าเศร้าที่ไม่มีใครมีรายละเอียดเกี่ยวกับกรณีเช่นนี้ คุณช่วยบอกฉันได้ไหมว่ามันเป็นความคิดที่ดีหรือสมเหตุสมผลในการจัดเรียงขยะ? ฉันไม่ได้ขอเฉพาะกรณี C # แต่ทุกภาษาโปรแกรมที่มีตัวเก็บขยะ ฉันรู้ว่าคุณไม่สามารถบังคับให้ GC กับทุกภาษาเช่น Java ได้ แต่ลองสมมติว่าคุณทำได้

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

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

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

1
มีความแตกต่างพื้นฐานระหว่างการโทรกลับและสัญญาหรือไม่
เมื่อทำการเขียนโปรแกรมแบบอะซิงโครนัสแบบเธรดเดียวมีสองเทคนิคหลักที่ฉันคุ้นเคย ที่พบมากที่สุดคือการใช้การเรียกกลับ นั่นหมายถึงการส่งผ่านไปยังฟังก์ชั่นที่ทำหน้าที่โทรกลับ - ฟังก์ชั่นแบบอะซิงโครนัสเป็นพารามิเตอร์ เมื่อการดำเนินการแบบอะซิงโครนัสจะเสร็จสิ้นการเรียกกลับจะถูกเรียก jQueryรหัสทั่วไปบางอย่างออกแบบด้วยวิธีนี้: $.get('userDetails', {'name': 'joe'}, function(data) { $('#userAge').text(data.age); }); อย่างไรก็ตามโค้ดประเภทนี้สามารถทำให้เกิดความยุ่งเหยิงและซ้อนกันได้สูงเมื่อเราต้องการเรียก async เพิ่มเติมอีกอันหนึ่งเรียกอีกอย่างหนึ่งเมื่อรหัสก่อนหน้านี้เสร็จสิ้น ดังนั้นวิธีที่สองคือใช้สัญญา คำมั่นสัญญาเป็นวัตถุที่แสดงถึงค่าที่อาจยังไม่มี คุณสามารถตั้งค่า callback บนมันซึ่งจะถูกเรียกเมื่อค่าพร้อมที่จะอ่าน ความแตกต่างระหว่างคำสัญญาและวิธีการเรียกกลับแบบเดิมคือวิธีการแบบอะซิงก์ตอนนี้ส่งคืนออบเจ็กต์คำสัญญาซึ่งลูกค้าตั้งค่าการเรียกกลับ ตัวอย่างเช่นรหัสที่คล้ายกันโดยใช้สัญญาใน AngularJS: $http.get('userDetails', {'name': 'joe'}) .then(function(response) { $('#userAge').text(response.age); }); ดังนั้นคำถามของฉันคือจริง ๆ แล้วมีความแตกต่างจริง ๆ ความแตกต่างนั้นดูเหมือนจะเป็นการสร้างประโยคอย่างหมดจด มีเหตุผลใดที่ลึกซึ้งยิ่งขึ้นในการใช้เทคนิคหนึ่งเหนืออีกเทคนิคหนึ่ง?

7
การประเมินการลัดวงจรมันเป็นการปฏิบัติที่ไม่ดีเหรอ?
สิ่งที่ฉันรู้จักมาระยะหนึ่ง แต่ไม่เคยพิจารณามาก่อนคือภาษาส่วนใหญ่มีความเป็นไปได้ที่จะให้ความสำคัญกับผู้ประกอบการในคำสั่ง if ตามคำสั่งของพวกเขา ฉันมักจะใช้สิ่งนี้เป็นวิธีในการป้องกันข้อยกเว้นอ้างอิงเป็นโมฆะเช่น: if (smartphone != null && smartphone.GetSignal() > 50) { // Do stuff } ในกรณีนี้รหัสจะส่งผลในการตรวจสอบครั้งแรกว่าวัตถุไม่เป็นโมฆะและจากนั้นใช้วัตถุนี้รู้ว่ามันมีอยู่ ภาษานั้นฉลาดเพราะรู้ว่าถ้าคำสั่งแรกถ้าเป็นเท็จก็ไม่มีประโยชน์ที่จะประเมินคำสั่งที่สองและดังนั้นจึงไม่มีข้อยกเว้นการอ้างอิงโมฆะ สิ่งนี้ใช้งานได้เหมือนกันสำหรับตัวดำเนินการandและor สิ่งนี้มีประโยชน์ในสถานการณ์อื่น ๆ เช่นการตรวจสอบว่าดัชนีอยู่ในขอบเขตของอาเรย์และเทคนิคดังกล่าวสามารถทำได้ในหลายภาษาตามความรู้ของฉัน: Java, C #, C ++, Python และ Matlab คำถามของฉันคือ: รหัสประเภทนี้เป็นตัวแทนของการปฏิบัติที่ไม่ดีหรือไม่? การปฏิบัติที่ไม่ดีนี้เกิดขึ้นจากปัญหาทางเทคนิคที่ซ่อนอยู่หรือไม่ (เช่นนี้อาจส่งผลให้เกิดข้อผิดพลาด) หรือนำไปสู่ปัญหาความสามารถในการอ่านสำหรับโปรแกรมเมอร์อื่น ๆ หรือไม่? มันอาจสร้างความสับสนได้ไหม

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

6
การรวบรวมขยะทำงานในภาษาที่เรียบเรียงอย่างไร
หลังจากการเรียกดูคำตอบหลายกองมากเกินก็เป็นที่ชัดเจนว่าบางภาษาเรียบเรียงโดยกำเนิดมีการเก็บขยะ แต่มันก็ไม่ชัดเจนสำหรับฉันว่ามันจะทำงานอย่างไร ฉันเข้าใจว่าการรวบรวมขยะสามารถทำงานกับภาษาที่ตีความได้อย่างไร ตัวรวบรวมขยะจะทำงานพร้อมกับล่ามและลบวัตถุที่ไม่ได้ใช้และไม่สามารถเข้าถึงได้ออกจากหน่วยความจำของโปรแกรม พวกเขาทั้งสองทำงานร่วมกัน สิ่งนี้จะทำงานกับภาษาที่คอมไพล์ได้อย่างไร? ความเข้าใจของฉันคือเมื่อคอมไพเลอร์ได้รวบรวมซอร์สโค้ดไปยังรหัสเป้าหมาย - โดยเฉพาะรหัสเครื่องดั้งเดิม - ก็เสร็จแล้ว งานเสร็จสิ้นแล้ว ดังนั้นโปรแกรมที่คอมไพล์แล้วจะเก็บขยะได้อย่างไร? คอมไพเลอร์ทำงานร่วมกับ CPU ในบางวิธีในขณะที่โปรแกรมทำงานเพื่อลบวัตถุ "ขยะ" หรือไม่ หรือคอมไพเลอร์มีตัวรวบรวมขยะน้อยที่สุดในการปฏิบัติการของโปรแกรมที่คอมไพล์แล้วหรือไม่ ฉันเชื่อว่าคำสั่งหลังของฉันจะมีความถูกต้องมากกว่าเดิมเนื่องจากข้อความที่ตัดตอนมาจากคำตอบนี้ใน Stack Overflow : ภาษาโปรแกรมหนึ่งนั้นคือไอเฟล คอมไพเลอร์ไอเฟลส่วนใหญ่สร้างรหัส C สำหรับเหตุผลในการพกพา รหัส C นี้ใช้เพื่อสร้างรหัสเครื่องโดยคอมไพเลอร์ C มาตรฐาน Eiffel implementations ให้ GC (และบางครั้งก็แม่นยำ GC) สำหรับโค้ดที่คอมไพล์นี้และไม่จำเป็นสำหรับ VM โดยเฉพาะอย่างยิ่ง VisualEiffel คอมไพเลอร์สร้างรหัสเครื่อง x86 พื้นเมืองโดยตรงกับการสนับสนุน คำสั่งสุดท้ายดูเหมือนจะบ่งบอกว่าคอมไพเลอร์มีบางโปรแกรมในปฏิบัติการสุดท้ายซึ่งทำหน้าที่เป็นตัวเก็บรวบรวมขยะในขณะที่โปรแกรมกำลังทำงาน หน้าบนเว็บไซต์D ภาษาเกี่ยวกับการรวบรวมขยะ - ซึ่งถูกรวบรวมไว้อย่างเป็นธรรมชาติและมีที่เก็บขยะทางเลือก …

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

17
วิธีฝึกตัวเองให้หลีกเลี่ยงการเขียนรหัส“ ฉลาด” [ปิด]
คุณรู้หรือไม่ว่าความรู้สึกนั้นเมื่อคุณต้องการที่จะแสดงให้เห็นถึงเคล็ดลับใหม่ที่มีExpressions หรือวางแนวทางที่แตกต่างกันสามขั้นตอน? สิ่งนี้ไม่จำเป็นต้องอยู่ในระดับสถาปัตยกรรมนักบินอวกาศและในความเป็นจริงอาจเป็นประโยชน์ แต่ฉันอดไม่ได้ที่จะสังเกตเห็นว่าคนอื่นจะใช้คลาสเดียวกันหรือแพ็คเกจเดียวกันอย่างชัดเจนตรงไปตรงมา (และบางครั้งน่าเบื่อ) ฉันสังเกตว่าฉันมักจะออกแบบโปรแกรมด้วยการแก้ไขปัญหาบางครั้งก็จงใจและบางครั้งก็เบื่อ ไม่ว่าในกรณีใดฉันมักจะเชื่อโดยสุจริตว่าโซลูชันของฉันนั้นใสและสง่างามจนกระทั่งฉันเห็นหลักฐานที่ตรงกันข้าม แต่โดยปกติแล้วมันจะสายเกินไป นอกจากนี้ยังมีส่วนหนึ่งของฉันที่ชอบสมมติฐานที่ไม่มีเอกสารในการทำสำเนารหัสและความฉลาดในการเรียบง่าย ฉันจะทำอะไรได้บ้างที่จะต่อต้านการกระตุ้นให้เขียนรหัส“ ฉลาด”และเสียงกระดิ่งที่ฉันควรทำเมื่อใด ปัญหาคือการผลักมากขึ้นขณะที่ฉันกำลังทำงานกับทีมนักพัฒนาที่มีประสบการณ์และบางครั้งความพยายามของฉันในการเขียนรหัสสมาร์ทดูเหมือนโง่เง่าแม้แต่กับตัวเองหลังจากเวลาผ่านไปภาพลวงตาของความสง่างาม

10
เป็นการดีหรือไม่ที่จะแทนที่การหารด้วยการคูณเมื่อทำได้
เมื่อใดก็ตามที่ฉันต้องการการแบ่งตัวอย่างเช่นการตรวจสอบเงื่อนไขฉันต้องการ refactor การแสดงออกของการหารเป็นการคูณ: รุ่นเดิม: if(newValue / oldValue >= SOME_CONSTANT) เวอร์ชั่นใหม่: if(newValue >= oldValue * SOME_CONSTANT) เพราะฉันคิดว่ามันสามารถหลีกเลี่ยง: การหารด้วยศูนย์ ล้นเมื่อoldValueมีขนาดเล็กมาก นั่นถูกต้องใช่ไหม? มีปัญหาสำหรับนิสัยนี้หรือไม่?

16
/ มีวิธีการที่ถูกต้องในการบอกผู้บริหารว่ารหัสของเราแย่แค่ไหน?
รหัสของเราไม่ดี มันอาจจะไม่ได้รับการพิจารณาที่ไม่ดีเสมอไป แต่มันก็ไม่ดีและจะตกต่ำเท่านั้น ฉันเริ่มต้นใหม่จากวิทยาลัยน้อยกว่าหนึ่งปีที่ผ่านมาและสิ่งต่าง ๆ ในปริศนารหัสของเราฉันเกินความเชื่อ ตอนแรกฉันคิดว่าเป็นคนใหม่ฉันควรปิดปากจนกว่าฉันจะได้เรียนรู้เพิ่มเติมเล็กน้อยเกี่ยวกับรหัสฐานของเรา แต่ฉันเห็นมากมายที่จะรู้ว่ามันไม่ดี ไฮไลท์บางส่วน: เรายังคงใช้เฟรม (ลองนำบางสิ่งออกจากการสืบค้นซึ่งเป็นไปไม่ได้เกือบ) VBScript แหล่งที่มาที่ปลอดภัย เรา 'ใช้'. NET - โดยที่ฉันหมายถึงเรามี. wrappers สุทธิที่เรียก COM DLLs ทำให้แทบเป็นไปไม่ได้ที่จะตรวจแก้จุดบกพร่องได้อย่างง่ายดาย ทุกอย่างนั้นเป็นฟังก์ชั่นใหญ่อย่างหนึ่ง รหัสไม่สามารถบำรุงรักษาได้ แต่ละหน้ามีหลายไฟล์ที่สร้างขึ้นทุกครั้งที่มีการสร้างหน้าใหม่ หน้าหลักโดยทั่วไปจะไม่ Response.Write () หลายครั้งเพื่อแสดง HTML (runat = "server"? no way) หลังจากนั้นอาจมีตรรกะจำนวนมากในฝั่งไคลเอ็นต์ (VBScript) และในที่สุดหน้าก็จะส่งไปยังตัวเอง (มักจะเก็บสิ่งต่าง ๆ ในเขตข้อมูลที่ซ่อนอยู่) ซึ่งมันจะโพสต์ไปยังหน้าการประมวลผลซึ่งสามารถทำสิ่งต่าง ๆ เช่นบันทึก data ไปยังฐานข้อมูล ข้อมูลจำเพาะที่เราได้รับนั้นน่าหัวเราะ บ่อยครั้งที่พวกเขาเรียกหาสิ่งต่าง ๆ …

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