เคล็ดลับเกี่ยวกับวิธีการแพร่กระจายแนวปฏิบัติที่เน้นวัตถุ [ปิด]

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

คำถามของฉันคือคุณสามารถแนะนำวิธีกระจายความรู้ประเภทนี้ได้อย่างไร

ฉันรู้ว่าพื้นผิวของปัญหาคือแอปพลิเคชันเหล่านี้มีสถาปัตยกรรมและการออกแบบที่ไม่ดี อีกปัญหาคือมีนักพัฒนาบางคนที่ต่อต้านการเขียนการทดสอบใด ๆ

บางสิ่งที่ฉันทำเพื่อเปลี่ยนแปลงสิ่งนี้ (แต่ฉันล้มเหลวหรือการเปลี่ยนแปลงเล็กเกินไป)

• ใช้งานนำเสนอเกี่ยวกับหลักการออกแบบ (SOLID, clean code, ฯลฯ )
• การประชุมเชิงปฏิบัติการเกี่ยวกับ TDD และ BDD
• ทีมการฝึกสอน (ซึ่งรวมถึงการใช้โซนาร์, findbugs, jdepend และเครื่องมืออื่น ๆ )
• การพูดถึง IDE & Refactoring

บางสิ่งที่ฉันคิดว่าจะทำในอนาคต (แต่ฉันกังวลว่าพวกเขาอาจจะไม่ดี)

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

.

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

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

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

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

ลองดูว่าคุณสามารถลงทุนในการสร้างจิตสำนึกเพื่อการบำรุงรักษาและความสง่างามหรือไม่ ท้ายที่สุดเป้าหมายหลักของ OOP ไม่ได้แตกต่างไปจากกลยุทธ์การจัดการความซับซ้อนอื่น ๆ (ซึ่งเป็นกระบวนทัศน์การเขียนโปรแกรมที่เป็นจริงทั้งหมดเกี่ยวกับ): encapsulation, modulatisation, coupling หลวมระดับต่ำของการพึ่งพาซึ่งกันและกันรักษาสถานะที่ไม่แน่นอนและขอบเขต ขั้นต่ำ ฯลฯ ฯลฯ OOP แน่นอนไม่ใช่กระบวนทัศน์เดียวที่ให้เครื่องมือที่คุณต้องการเพื่อให้บรรลุ

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

TL; DR: ถ้าคุณต้องการประกาศข่าวประเสริฐทุกอย่างปล่อยให้มันเป็นแนวทางปฏิบัติที่ดีในการเขียนโปรแกรม (ไม่เชื่อเรื่องพระเจ้า) ไม่ใช่กระบวนทัศน์หรือวิธีการเฉพาะ

คุณไม่สามารถเปลี่ยนแปลงใครก็ได้ที่ยังไม่ต้องการเปลี่ยน นี่คือเหตุผลที่ทีมที่คุณโค้ชได้เปลี่ยนกลับเป็นวิธีเก่า

ดังนั้นคำถามของคุณควรจะ "ฉันจะทำให้นักพัฒนาต้องการเปลี่ยนวิธีการ OO ได้อย่างไร"

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

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

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

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

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

ความคิดเห็นของคุณเกี่ยวกับทีมตรวจสอบและผู้เผยแพร่ศาสนา OO เป็นคนดี มันจะต้องเป็นมากกว่าแค่คุณที่ผลักดันวาระนี้

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

จัดตั้งทีมของผู้เผยแพร่ศาสนา OO ผู้เผยแพร่วิธีคิด OO ในทีม differet (คนเหล่านี้จะต้องเปลี่ยนทีมทุกสองสามเดือน)

เป็นความคิดที่ดี สิ่งนี้ควรละเอียดและควรพูดคุยเกี่ยวกับ OO ตั้งแต่ต้นจนจบ เมื่อฉันเรียนรู้เกร็ดเล็กเกร็ดประวัติศาสตร์ OO ช่วยได้มาก

ฉันอยากจะแนะนำ

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

ฉันเห็นด้วยกับ Shuvo Naser มันเป็นอุปสรรคใหญ่ดังนั้นให้ปฏิบัติเหมือนการปีน การเรียนรู้วิธีออกแบบแอปพลิเคชันทั้งหมดโดยใช้ OOP นั้นต้องใช้เวลา

1. ระบุผู้ที่เข้าใจ OOP และนำพวกเขาเข้าใกล้กับหัวหน้าทีมผู้ฝึกสอนนักออกแบบผู้ตรวจสอบโค้ด ฯลฯ
2. ใช้โครงการที่มีอยู่เป็นข้อมูลอ้างอิงการฝึกอบรม อาจเป็นไปได้ว่าใน # 1 อยู่ในทีมนั้น
3. Refactor โครงการที่มีอยู่บางส่วน สิ่งนี้สามารถช่วยให้บางคนสร้างสะพานเชื่อมระหว่างรหัสขั้นตอนกับรหัส OO เริ่มต้นด้วยพื้นฐาน พวกเขาต้องดูว่าคุณจะใช้หลักการเหล่านี้เมื่อใดที่ไหนและทำไม
4. ให้พวกเขามีส่วนร่วมในการออกแบบกับผู้ที่รู้ว่าพวกเขากำลังทำอะไรอยู่
5. วางพวกเขาไว้ในทีม dev กับคนที่สามารถให้คำแนะนำการออกแบบและตรวจสอบให้แน่ใจว่าโครงการยึดหลักการ OO (สมมติว่าเหตุผลที่คุณต้องการทำสิ่งนี้ในตอนแรกคือเพราะจะปรับปรุงการพัฒนา)

การยอมรับมักไม่ค่อยเห็นประโยชน์ เรากำลังพูดถึงเกี่ยวกับการออกแบบที่ซับซ้อนและไม่ได้ใช้แผ่นพีเอสรายงานปก

คุณมีความคิดที่ดีอยู่แล้ว

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

เปรียวหรือ Object Oriented?

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

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

ปัญหาในการเอาชนะ

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

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

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

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

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

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

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

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

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

นี่ควรเป็นความคิดเห็น แต่เนื่องจากเห็นได้ชัดว่าฉันยังไม่สามารถแสดงความคิดเห็นในสิ่งต่างๆได้อาจเป็นคำตอบ

สิ่งที่สำคัญที่สุดที่เคยมีในชนิดของนวัตกรรมนี้ (ไม่ว่าจะเป็นตัวผู้ป่วยเองหรือกระบวนทัศน์ขยับการพูด, การเขียนโปรแกรมการทำงานอื่น ๆ หรือสิ่งที่ออกมาในปีถัดไป) เป็นความคิดเห็น DO รหัสและ PEER PROGRAMMING มากับพวกเขาเดินทีมเป็นวิธีอื่นในการทำสิ่งต่าง ๆ ที่จะช่วยพวกเขา

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

extern float clients_total;

void client_add(float sum);  
void client_substract(float sum);
float client_get_total();

(โปรดทราบว่า clients_total อาจซ้ำซ้อนทั้งหมดเป็นตัวอย่างที่วางแผนไว้ไม่ดีโดยเฉพาะ)

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

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

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