การเขียนโปรแกรมที่ไม่ดีเป็นเรื่องปกติในอุตสาหกรรมซอฟต์แวร์หรือไม่? [ปิด]

ฉันเพิ่งเริ่มงานแรกในฐานะนักพัฒนาซอฟต์แวร์เมื่อหนึ่งเดือนก่อน ทุกอย่างที่ฉันได้เรียนรู้เกี่ยวกับ OOP, SOLID , แห้ง , YAGNI, รูปแบบการออกแบบ, SRP , ฯลฯ สามารถถูกโยนออกไปนอกหน้าต่าง

พวกเขาใช้เว็บฟอร์ม C # .NET และทำเกือบทุกอย่างภายใน Code Behind ด้วยคลาสภายนอกน้อยมากซึ่งไม่ได้เรียกว่าออบเจ็กต์ พวกเขาใช้การควบคุมที่กำหนดเองและนำมาใช้ใหม่ เกี่ยวกับวัตถุเท่านั้นที่ใช้โดยEntity Framework พวกเขาใช้ Code Behinds ซ้ำสำหรับลูกค้าแต่ละราย พวกเขามีวิธีการที่ยาว 400 บรรทัดในการทำสิ่งของทุกประเภท สำหรับลูกค้าใหม่พวกเขาใช้ aspx และ aspx.cs และดึงรหัสลูกค้าออกและเริ่มเพิ่มรหัสเฉพาะลูกค้าใหม่

ข้อแก้ตัวแรกของพวกเขาคือมันจะเพิ่มการบำรุงรักษาเพิ่มเติมและรหัสเพิ่มเติมคือการบำรุงรักษาเพิ่มเติม มันเป็นร้านค้าเล็ก ๆ ของนักพัฒนาสามคนรวมถึงตัวฉันด้วย นักพัฒนาซอฟต์แวร์หนึ่งคนมีประสบการณ์มากกว่า 30 ปีและอีกหนึ่งคนมีประสบการณ์มากกว่า 20 ปี หนึ่งเคยเป็นนักพัฒนาเกมและคนอื่น ๆ ได้ทำงานใน C และ C ++

สิ่งนี้มีอยู่ทั่วไปในอุตสาหกรรมซอฟต์แวร์หรือไม่ ฉันจะมั่นใจได้อย่างไรว่าฉันอยู่เหนือ OOP และหลักการที่เกี่ยวข้อง ฉันฝึกฝนในเวลาว่างและฉันรู้สึกว่าฉันต้องทำงานภายใต้นักพัฒนาที่มีประสบการณ์มากขึ้นเพื่อให้ดีขึ้นที่ OOP

1. หลักการที่คุณอ้างถึงในคำถามของคุณเป็นเพียง ... หลักการ พวกเขาไม่ใช่เอกสารกฎหมายหรือคำสั่ง
2. ในขณะที่ผู้คนที่สร้างหลักการเหล่านี้ฉลาดมากพวกเขาไม่ใช่ผู้มีอำนาจเด็ดขาด พวกเขาเป็นเพียงผู้คนที่นำเสนอข้อมูลเชิงลึกและคำแนะนำ
3. ไม่มีวิธี "ที่ถูกต้อง" ในการเขียนโปรแกรม นี่คือหลักฐานตามข้อเท็จจริงที่ว่า "ยอมรับ" วิธีที่เราทำเปลี่ยนแปลงและยังคงเปลี่ยนแปลงอย่างรุนแรงตลอดเวลา
4. การจัดส่งผลิตภัณฑ์มักจะมีความสำคัญมากกว่าการทำในสิ่งที่ "ถูกต้อง" นี่เป็นวิธีปฏิบัติที่แพร่หลายที่มีชื่อ: หนี้ทางเทคนิค

5. สถาปัตยกรรมซอฟต์แวร์บางตัวที่ใช้งานทั่วไปไม่เหมาะ แนวทางปฏิบัติที่ดีที่สุดกำลังพัฒนาไปจากแอพพลิเคชั่นขนาดใหญ่เสาหินไปสู่ชุดของโมดูล

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

ดังนั้นคุณจะทำตามเส้นทาง "ถูกต้อง" เป็นเส้นทางที่มีหลักการอย่างไรเพื่อที่คุณจะได้โผล่ออกมาจากถิ่นทุรกันดาร?

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

3. ศึกษาตลอดกาล มีหลักการบางอย่างที่ยืนหยัดต่อการทดสอบของเวลาและจะเกี่ยวข้อง ระบบประเภทนั้นเป็นสากล ฟังก์ชั่นชั้นหนึ่งเป็นสากล โครงสร้างข้อมูลเป็นสากล

4. เรียนรู้ปฏิบัตินิยม การปฏิบัติเป็นสิ่งสำคัญ ความบริสุทธิ์ทางคณิตศาสตร์สถาปัตยกรรมคริสตัลมหาวิหารและหลักการหอคอยงาช้างนั้นไร้ประโยชน์หากคุณไม่สามารถจัดส่งได้

5. เป็นช่างฝีมือไม่กระตือรือร้น นักพัฒนาซอฟต์แวร์ที่ดีที่สุดคือคนที่รู้กฎและรู้วิธีทำลายพวกเขาเมื่อเหมาะสม พวกเขาเป็นคนที่ยังรู้วิธีแก้ปัญหาและคิดด้วยตัวเอง พวกเขาใช้หลักการเพื่อแจ้งและชี้แนะทางเลือกไม่ใช่บอกให้พวกเขา
6. เขียนรหัส มันเยอะมาก หลักการออกแบบซอฟต์แวร์เป็นการปรับให้เหมาะสมก่อนเวลาจนกว่าคุณจะเขียนโค้ดจำนวนมากและพัฒนาสัญชาตญาณวิธีการใช้อย่างถูกต้อง

มันไม่ใช่เรื่องแปลก สิ่งหนึ่งที่ต้องตระหนักคืออุตสาหกรรมซอฟต์แวร์นั้นมีความหลากหลายอย่างไม่น่าเชื่อ บาง บริษัท มีความทันสมัย มหาวิทยาลัยชั้นนำและ บริษัท ซอฟต์แวร์ที่มีนวัตกรรม (แม้จะมีห้องแล็บในห้องใหญ่!) รวมถึงบุคคลหรือกลุ่มที่ได้รับพรเช่นแก๊งค์สี่คนวิเคราะห์ปัญหาที่เกิดขึ้นด้วยวิธีการทั่วไปในการทำสิ่งต่าง ๆ และคิดค้นภาษาใหม่ ๆ บริษัท ใหม่ ๆ มักจะแยกกิจการหรือแยกออกพยายามที่จะใช้ในเชิงพาณิชย์และบางครั้งก็ประสบความสำเร็จอย่างน่าทึ่ง คิดว่า Facebook หรือ Google

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

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

ใช่แล้ว: สิ่งที่คุณเรียนในมหาวิทยาลัยนั้นไม่ใช่เรื่องธรรมดาในหลาย ๆ ด้าน

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

พวกเขาใช้ C # .Net Webforms และทำเกือบทุกอย่างภายใน Code Behind ด้วยคลาสภายนอกน้อยมาก

มีคำอธิบายของคุณอยู่ตรงนั้น หากคุณไม่ทราบรหัสเว็บฟอร์มที่ออกนอกกรอบนั้นค่อนข้างตรงกันข้ามกับOOP, SOLID, DRY, YAGNI, รูปแบบการออกแบบ, SRP , ฯลฯ แม้แต่ตัวอย่างที่เป็นทางการของ Microsoft จากไม่กี่ปีหลัง จะทำให้คุณประจบประแจงในวันนี้

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

และนี่เป็นเรื่องที่พบได้บ่อยในพื้นที่เว็บฟอร์ม. NET btw

สิ่งนี้มีอยู่ทั่วไปในอุตสาหกรรมซอฟต์แวร์หรือไม่

พบบ่อยมาก เกี่ยวกับความเหมือนกันของช่างประปาที่ทำลายช่างประปาช่างไม้ที่ส่งขยะหรือช่างตัดเสื้อราคาถูกสร้างชุดที่ไม่เหมาะสม คือมนุษย์ทุกคน

มีเหตุผลที่ดีว่าทำไมสิ่งนี้เกิดขึ้น: คนที่ไม่ได้รับการฝึกฝนจริง ๆ (หรือไม่กระตือรือร้น) ต้องใช้บางสิ่งภายใต้ความกดดัน

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

หรือบางคนที่ยอดเยี่ยมในโดเมน แต่ไม่ใช่โปรแกรมเมอร์อาจแฮ็กแอปพลิเคชั่น VBA เป็นต้นเพราะดูเหมือนจะเป็นเรื่องง่ายในตอนแรก

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

ฉันจะมั่นใจได้อย่างไรว่าฉันอยู่เหนือ OOP และหลักการที่เกี่ยวข้อง ฉันฝึกฝนในเวลาว่างและรู้สึกว่าฉันต้องการทำงานภายใต้นักพัฒนาที่มีประสบการณ์มากขึ้นเพื่อให้ดีขึ้นที่ OOP

มีสองคำตอบที่เป็นไปได้:

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

หากคำตอบที่สองฟังดูถูกเหยียดหยามคุณเกินไปให้ฉันรับรองคุณว่าไม่ใช่ ช่างไม้ที่มีร้านขายไม้อยู่ที่บ้านแน่นอนที่สุดจะเป็นช่างไม้ที่ดีกว่าคนที่ไม่มี

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

ที่นำไปพัฒนาที่มีการฝึกอบรมให้คุณได้ค่อนข้างเรียนรู้สิ่งที่อยู่ในตรงทางนี้ ...

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

ความล้มเหลวของคนที่มีประสบการณ์เหล่านี้ไม่เคยได้รับการแก้ไข: แทนที่จะมุ่งเน้นเพียงเพื่อให้งานสำเร็จลุล่วง เป็นผลให้มีการสะสมแนวทางปฏิบัติที่ผิดมากขึ้นเรื่อย ๆ ในรหัส

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

อีกครั้งโปรแกรมเมอร์ที่ไม่มีประสบการณ์ถูกนำไปทำงานในเทคโนโลยีใหม่นั้นไม่มีใครวิจารณ์โค้ดและวงกลมจะถูกปิดอีกครั้ง .... ตลอดไปและตลอดไป ....

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

บางครั้งคุณจะเห็นโปรแกรมเมอร์ที่กดเวลาโดยใช้ทางลัดและรูปแบบการต่อต้านที่ต้องการจานหม้อไอน้ำน้อยกว่าโซลูชั่นที่มีคุณภาพ

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

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

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

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

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

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

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

ฉันเข้าใจว่าคุณรู้สึกอย่างไร อย่าตกใจ คุณจะต้องการสิ่งที่คุณรู้บางทีอาจจะไม่ทันที แต่มันจะช่วยคุณ อาจจะอยู่ในสถานที่ทำงานที่แตกต่างกันบางทีในบางโอกาส คุณมีเวลาก่อนที่จะไปต่อ