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

แจ้งให้ทราบว่าฉันเป็นแฟนตัวยงของการฉีด (DI) และการทดสอบอัตโนมัติ ฉันสามารถพูดได้ทั้งวันเกี่ยวกับเรื่องนี้ พื้นหลัง เมื่อเร็ว ๆ นี้ทีมงานของเราเพิ่งได้รับโครงการขนาดใหญ่ที่จะสร้างขึ้นใหม่ทั้งหมด มันเป็นแอปพลิเคชั่นเชิงกลยุทธ์ที่มีความต้องการทางธุรกิจที่ซับซ้อน แน่นอนฉันต้องการให้มันดีและสะอาดซึ่งสำหรับฉันหมายถึง: บำรุงรักษาและทดสอบได้ ดังนั้นฉันต้องการใช้ DI ความต้านทาน ปัญหาเกิดขึ้นในทีมของเรา DI คือข้อห้าม มันถูกนำขึ้นมาสองสามครั้ง แต่พระเจ้าไม่เห็นด้วย แต่นั่นก็ไม่ได้ทำให้ฉันท้อแท้ ย้ายของฉัน สิ่งนี้อาจฟังดูแปลก แต่ห้องสมุดบุคคลที่สามมักไม่ได้รับการอนุมัติจากทีมสถาปนิกของเรา (คิดว่า: "อย่าพูดถึงUnity , Ninject , NHibernate , MoqหรือNUnitเพื่อมิให้ฉันตัดนิ้ว" ดังนั้นแทนที่จะใช้คอนเทนเนอร์ DI ที่สร้างไว้ฉันจึงเขียนคอนเทนเนอร์ที่แสนง่าย โดยทั่วไปจะเชื่อมโยงการพึ่งพาทั้งหมดของคุณเมื่อเริ่มต้นใช้งานฉีดการพึ่งพาใด ๆ (คอนสตรัคเตอร์ / คุณสมบัติ) และกำจัดวัตถุที่ใช้แล้วทิ้งใด ๆ ที่ส่วนท้ายของคำขอเว็บ มันเบามากและทำในสิ่งที่เราต้องการ จากนั้นฉันก็ขอให้พวกเขาทบทวนมัน การตอบสนอง ดีที่จะทำให้มันสั้น ฉันได้พบกับการต่อต้านอย่างหนัก อาร์กิวเมนต์หลักคือ "เราไม่จำเป็นต้องเพิ่มความซับซ้อนของเลเยอร์นี้ลงในโครงการที่มีความซับซ้อนอยู่แล้ว" นอกจากนี้ …

95 dependency-injection 

ถ้าใช่ฉันควรระวังอะไรบ้าง?

95 licensing 

ฉันพยายามออกแบบฐานข้อมูลเพื่อให้สอดคล้องกับแนวคิดโครงการและพบกับสิ่งที่ดูเหมือนว่าจะเป็นประเด็นถกเถียงกันอย่างถึงพริกถึงขิง ฉันได้อ่านบทความไม่กี่คำและ Stack Overflow บางคำตอบที่ระบุว่าไม่เคย (หรือเกือบจะไม่เคย) ตกลงในการจัดเก็บรายการ ID หรือสิ่งที่ชอบในฟิลด์ - ข้อมูลทั้งหมดควรมีความสัมพันธ์ ฯลฯ อย่างไรก็ตามปัญหาที่ฉันพบคือฉันกำลังพยายามมอบหมายงาน ผู้คนจะสร้างงานมอบหมายให้คนหลายคนและมันจะบันทึกลงในฐานข้อมูล แน่นอนถ้าฉันบันทึกงานเหล่านี้ทีละรายการใน "บุคคล" ฉันจะต้องมีคอลัมน์ "TaskID" หลอกตานับสิบ ๆ ตัวและจัดการแบบไมโครเพราะจะมีงานมอบหมายให้บุคคลหนึ่งถึง 0 ถึง 100 จากนั้นอีกครั้งถ้าฉันบันทึกงานในตาราง "งาน" ฉันจะต้องมีคอลัมน์ "PersonID" หลอกตานับสิบ ๆ ตัวและจัดการกับมันแบบไมโคร - ปัญหาเช่นเดียวกับเมื่อก่อน สำหรับปัญหาเช่นนี้จะเป็นการดีไหมที่จะบันทึกรายการ ID ที่ใช้รูปแบบเดียวหรืออีกรูปแบบหนึ่งหรือฉันไม่คิดวิธีอื่นที่ทำได้โดยไม่ต้องทำลายหลักการ?

94 database  database-design  sql  relational-database 

เมื่อทำการเขียนโปรแกรมแบบอะซิงโครนัสแบบเธรดเดียวมีสองเทคนิคหลักที่ฉันคุ้นเคย ที่พบมากที่สุดคือการใช้การเรียกกลับ นั่นหมายถึงการส่งผ่านไปยังฟังก์ชั่นที่ทำหน้าที่โทรกลับ - ฟังก์ชั่นแบบอะซิงโครนัสเป็นพารามิเตอร์ เมื่อการดำเนินการแบบอะซิงโครนัสจะเสร็จสิ้นการเรียกกลับจะถูกเรียก 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); }); ดังนั้นคำถามของฉันคือจริง ๆ แล้วมีความแตกต่างจริง ๆ ความแตกต่างนั้นดูเหมือนจะเป็นการสร้างประโยคอย่างหมดจด มีเหตุผลใดที่ลึกซึ้งยิ่งขึ้นในการใช้เทคนิคหนึ่งเหนืออีกเทคนิคหนึ่ง?

94 language-agnostic  asynchronous-programming  callbacks  promises 

ในระหว่างการประชุมเกี่ยวกับการย้อนกลับของ SDK ของบุคคลที่สามจากรุ่นล่าสุดมีการบันทึกไว้ว่านักพัฒนาของเราตั้งค่าสถานะไว้แล้วในประวัติการส่งมอบที่ไม่ควรใช้เวอร์ชันล่าสุด นักพัฒนาบางคนแย้งว่านี่เป็นวิธีปฏิบัติที่ไม่ดีและควรมีการบันทึกไว้ในไฟล์ต้นฉบับ (เช่น// Don't upgrade SDK Version x.y.z, see ticket 1234) หรือในREADMEไฟล์ระดับโครงการแทน คนอื่นแย้งว่าเนื่องจากประวัติการกระทำเป็นส่วนหนึ่งของเอกสารโครงการจึงเป็นที่ยอมรับสำหรับข้อมูลดังกล่าวเนื่องจากเราทุกคนควรอ่านมันต่อไป ควรใช้ประวัติการส่งข้อมูลเพื่อส่งข้อมูลสำคัญไปยังผู้พัฒนารายอื่นหรือควรทำซ้ำข้อมูลดังกล่าวไปยังตำแหน่งอื่นเช่นโครงการREADMEหรือความคิดเห็นในไฟล์ต้นฉบับที่เกี่ยวข้อง?

94 version-control  documentation 

ฉันเกลียดการอ้างอิงเนื้อหาที่ชำระเงินแล้ว แต่วิดีโอนี้แสดงสิ่งที่ฉันกำลังพูดถึง 12 นาทีอย่างแม่นยำใน Robert Martin ดูที่นี่: และกล่าวว่า "หนึ่งในสิ่งที่ฉันชอบทำคือกำจัดวงเล็บปีกกาที่ไร้ประโยชน์" เมื่อเขาเปลี่ยนมันเป็นสิ่งนี้: เมื่อนานมาแล้วในการศึกษาที่อยู่ห่างไกลฉันถูกสอนว่าอย่าทำเช่นนี้เพราะมันทำให้มันง่ายที่จะแนะนำข้อผิดพลาดโดยการเพิ่มอีกบรรทัดเยื้องคิดว่ามันถูกควบคุมโดยifเมื่อมันไม่ได้ เพื่อความเป็นธรรมกับลุงบ๊อบเขาได้ทำการปรับเปลี่ยนวิธีการจาวาแบบยาวลงไปสู่ฟังก์ชั่นเล็ก ๆ น้อย ๆ ที่ผมเห็นว่าสามารถอ่านได้ง่ายขึ้น เมื่อเขาเปลี่ยนมันเสร็จ (22.18) ดูเหมือนว่า: ฉันสงสัยว่าควรจะตรวจสอบการลบวงเล็บหรือไม่ ฉันคุ้นเคยกับแนวทางปฏิบัติที่ดีที่สุดแล้ว ลุงบ๊อบจะถูกท้าทายในประเด็นนี้หรือไม่? ลุงบ๊อบปกป้องความคิดนี้หรือไม่?

94 java  coding-style 

แนวคิดพื้นฐานที่อยู่เบื้องหลัง OOP คือข้อมูลและพฤติกรรม (ตามข้อมูลนั้น) แยกออกไม่ได้และพวกเขาจะถูกควบคู่ไปกับแนวคิดของวัตถุของคลาส วัตถุมีข้อมูลและวิธีการที่ทำงานกับ (และข้อมูลอื่น ๆ ) เห็นได้ชัดว่าตามหลักการของ OOP วัตถุที่เป็นเพียงข้อมูล (เช่นโครงสร้างของ C) นั้นถือว่าเป็นรูปแบบการต่อต้าน จนถึงตอนนี้ดีมาก ปัญหาคือฉันสังเกตว่ารหัสของฉันดูเหมือนจะเพิ่มมากขึ้นเรื่อย ๆ ในทิศทางของรูปแบบการต่อต้านเมื่อเร็ว ๆ นี้ ดูเหมือนว่ายิ่งฉันพยายามที่จะบรรลุข้อมูลที่ซ่อนอยู่ระหว่างคลาสและการออกแบบที่คู่กันอย่างหลวม ๆ ยิ่งคลาสของฉันได้รับการผสมของข้อมูลที่บริสุทธิ์มากขึ้นเท่านั้นไม่มีคลาสพฤติกรรมและพฤติกรรมทั้งหมดไม่มีคลาสข้อมูล โดยทั่วไปฉันออกแบบคลาสในวิธีที่ลดการรับรู้ของการมีอยู่ของคลาสอื่นและลดความรู้ของอินเทอร์เฟซของคลาสอื่น ฉันบังคับใช้สิ่งนี้โดยเฉพาะอย่างยิ่งจากบนลงล่างชั้นเรียนระดับล่างไม่ทราบเกี่ยวกับชั้นเรียนระดับสูงกว่า เช่น: สมมติว่าคุณมี API เกมการ์ดทั่วไป Cardคุณได้เรียน ตอนนี้Cardคลาสนี้จำเป็นต้องกำหนดทัศนวิสัยให้กับผู้เล่น วิธีหนึ่งคือการมีboolean isVisible(Player p)ในCardชั้นเรียน อีกอย่างคือให้มีboolean isVisible(Card c)ในPlayerชั้นเรียน ฉันไม่ชอบวิธีแรกโดยเฉพาะอย่างยิ่งในขณะที่มันมอบความรู้เกี่ยวกับระดับที่สูงกว่าPlayerระดับให้อยู่ในระดับที่ต่ำกว่าCardระดับ แต่ฉันเลือกใช้ตัวเลือกที่สามที่เรามีViewportคลาสซึ่งให้ a Playerและรายการการ์ดกำหนดว่าจะมองเห็นการ์ดใด อย่างไรก็ตามวิธีนี้ปล้นทั้งสองCardและPlayerคลาสของฟังก์ชั่นสมาชิกที่เป็นไปได้ เมื่อคุณทำสิ่งอื่นนอกเหนือจากการมองเห็นการ์ดแล้วคุณจะเหลือCardและPlayerคลาสที่มีข้อมูลล้วนๆเนื่องจากมีการใช้งานฟังก์ชั่นทั้งหมดในคลาสอื่นซึ่งส่วนใหญ่เป็นคลาสที่ไม่มีข้อมูลเช่นเดียวกับวิธีการViewportข้างต้น ชัดเจนว่าเป็นแนวคิดหลักของ OOP วิธีใดถูกต้อง ฉันควรจะทำอย่างไรในการลดการพึ่งพาซึ่งกันและกันของชั้นเรียนและลดความรู้และการมีเพศสัมพันธ์ให้น้อยที่สุด แต่ไม่มีการออกแบบแปลก ๆ …

94 object-oriented 

ฟีเจอร์หนึ่งที่ฉันพลาดจากภาษาที่ใช้งานได้คือความคิดที่ว่าโอเปอเรเตอร์เป็นแค่ฟังก์ชั่นดังนั้นการเพิ่มโอเปอเรเตอร์ที่กำหนดเองมักจะง่ายเหมือนการเพิ่มฟังก์ชั่น ภาษาเชิงโพรซีเดอร์จำนวนมากอนุญาตให้โอเปอเรเตอร์โอเวอร์โหลดดังนั้นในบางโอเปอเรเตอร์จะยังคงใช้งานได้ (นี่เป็นความจริงในDที่โอเปอเรเตอร์ถูกส่งเป็นสตริงในพารามิเตอร์เทมเพลต) ดูเหมือนว่าที่อนุญาตให้ผู้ประกอบการมากเกินไปก็มักจะเล็กน้อยเพื่อเพิ่มผู้ประกอบการที่กำหนดเองเพิ่มเติม ฉันพบโพสต์บล็อกนี้ซึ่งระบุว่าตัวดำเนินการที่กำหนดเองไม่ได้ทำงานได้ดีกับสัญกรณ์ของ infix เนื่องจากกฎที่มีมาก่อน แต่ผู้เขียนให้วิธีการแก้ไขปัญหาหลายประการ ฉันมองไปรอบ ๆ และไม่พบภาษาที่ใช้ในการดำเนินการใด ๆ ที่รองรับตัวดำเนินการที่กำหนดเองในภาษานั้น มีแฮ็ก (เช่นมาโครใน C ++) แต่แทบจะไม่เหมือนกับภาษาที่รองรับ เนื่องจากคุณสมบัตินี้ค่อนข้างง่ายต่อการนำไปใช้ทำไมจึงไม่เป็นเรื่องปกติ ฉันเข้าใจว่ามันอาจนำไปสู่โค้ดที่น่าเกลียด แต่ที่ไม่ได้หยุดนักออกแบบภาษาในอดีตจากการเพิ่มคุณสมบัติที่มีประโยชน์ที่สามารถถูกทำร้ายได้ง่าย (มาโครผู้ประกอบการที่ประกอบไปด้วยตัวชี้ที่ไม่ปลอดภัย) กรณีการใช้งานจริง: ใช้โอเปอเรเตอร์ที่หายไป (เช่น Lua ไม่มีโอเปอเรเตอร์ bitwise) Mimic D's ~(การต่อข้อมูลอาร์เรย์) DSLs ใช้|เป็นไวยากรณ์น้ำตาลแบบ Unix pipe (ใช้ coroutines / generators) ฉันมีความสนใจในภาษาที่ทำให้ผู้ประกอบการที่กำหนดเอง แต่ฉันสนใจมากขึ้นในเหตุผลที่จะได้รับการยกเว้น ฉันคิดถึงการใช้ภาษาสคริปต์เพื่อเพิ่มโอเปอเรเตอร์ที่ผู้ใช้กำหนด แต่หยุดตัวเองเมื่อฉันรู้ว่าฉันไม่เห็นมันเลยดังนั้นอาจมีเหตุผลที่ดีที่นักออกแบบภาษาฉลาดกว่าที่ฉันไม่อนุญาต

94 programming-languages  operators  procedural 

ฉันต้องการใช้ห้องสมุดที่มีลิขสิทธิ์ LGPL ในแอพของฉันสำหรับตลาดแอพของ Microsoft ไม่เป็นไร?

94 lgpl 

พื้นหลังเล็กน้อย วันนี้ฉันอายุ 28 และฉันไม่เคยได้รับการฝึกอบรมอย่างเป็นทางการในการพัฒนาซอฟต์แวร์ แต่ฉันมีวุฒิการศึกษาระดับสูงกว่าปริญญาตรีสาขาการประชาสัมพันธ์และบริหารธุรกิจมหาบัณฑิตสาขาบริหารธุรกิจที่เน้นการบริหารโครงการ ฉันเคยทำงานในสาขาเหล่านั้นมาแล้วประมาณ 6 ปีและเมื่อ 2,5 ปีก่อนฉันลาออกจากงานและตัดสินใจเปลี่ยนทิศทาง หลังจากผ่านไปหนึ่งเดือนฉันก็ตัดสินใจที่จะเริ่มพัฒนาเว็บไซต์เล็ก ๆ ในเวิร์ดเพรส ฉันเรียนรู้วิธีการของฉันด้วยตนเองและวันนี้ฉันสามารถพูดได้ว่าฉันใช้รูปแบบการพัฒนาอาชีพและประสบความสำเร็จต่ำต้อยและปลั๊กอินตั้งแต่ต้นสำหรับลูกค้าของฉัน - หน่วยงานส่วนใหญ่จ้างงาน dev บางส่วนสำหรับเว็บไซต์ขนาดกลาง / ใหญ่ แต่บางครั้งฉันก็รู้สึกว่าการเรียนวิชาคณิตศาสตร์ไม่เพียงพอหรือไม่มีความเข้าใจอย่างเป็นทางการเกี่ยวกับสิ่งต่าง ๆ ที่ทำให้ฉันรู้สึกล้าหลังเมื่อฉันต้องแข่งขันหรือทำงานกับนักพัฒนาที่มีประสบการณ์มากกว่า ฉันมักจะมองหาวิธีการเรียนรู้เพิ่มเติมอย่างต่อเนื่อง แต่ดูเหมือนว่าฉันขาดพื้นฐาน น่าเสียดายที่การใช้เวลาอีก 4 ปีในวิทยาการคอมพิวเตอร์ไม่ได้เป็นตัวเลือกในขณะนี้ดังนั้นฉันพยายามเรียนรู้ทุกอย่างที่ทำได้จากหนังสือและแหล่งข้อมูลออนไลน์ วิธีนี้จะไม่ทำให้นาซ่าจ้างฉัน แต่ตอนนี้ฉันไม่สนใจจริงๆ เป้าหมายของฉันคือการผ่านแถบแรกและเพื่อให้สามารถเรียกตัวเองว่าโปรแกรมเมอร์จริง ๆ ขณะนี้ฉันใช้เวลาว่างศึกษาJava สำหรับโปรแกรมเมอร์ (เพื่อให้เข้าใจภาษาที่ทุกคนพูดว่าเป็นเรื่องยาก / เรียกร้อง) อ่านข้อความที่ตัดตอนมาของCode Complete (เพื่อให้ได้แนวปฏิบัติที่ดีที่สุด) และCode: ภาษาที่ซ่อนอยู่ของคอมพิวเตอร์ ฮาร์ดแวร์และซอฟต์แวร์ (เพื่อให้เข้าใจการทำงานภายในของคอมพิวเตอร์) TL; DR ดังนั้นสถานการณ์ปัจจุบันของฉันคือ: โดยทั่วไปฉันสามารถเขียนระบบที่สมบูรณ์ใน PHP (ด้วยความช่วยเหลือของ …

94 skills 

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

94 tdd 

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

94 skills  experience  organization 

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

94 books  methodology 

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

94 development-process  methods  initialization 

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

93 code-reviews