คุณอธิบายการแยกข้อกังวลให้ผู้อื่นได้อย่างไร

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

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

1. คุณต้องเปลี่ยนรหัสเท่าไร
2. การเปลี่ยนแปลงนั้นง่ายเพียงใด
3. คุณมีแนวโน้มที่จะแตกคุณลักษณะที่มีอยู่ซึ่งลูกค้าอื่นใช้
4. คุณสามารถใช้โมเดล / สถาปัตยกรรมเดิมที่มีอยู่อีกครั้ง

การแยกข้อกังวลช่วยให้คุณได้รับคำตอบในเชิงบวกมากขึ้นสำหรับคำถามเหล่านี้

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

ดูที่โรงพยาบาลและคิดเกี่ยวกับบทบาทที่แตกต่างกันทั้งหมดที่เกี่ยวข้องกับการดูแลผู้ป่วย: พยาบาลแพทย์พยาบาลผู้ช่วยแพทย์เทคเจ้าหน้าที่ธุรการโรงอาหาร ฯลฯ

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

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

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

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

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

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

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

มุมมองนักพัฒนา JavaScript ทางเทคนิค

NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own      architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.

มุมมองตัวออกแบบ UX / UI

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.

มุมมองของทีม

NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working    directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

นอกจากนี้ในหน้ายังมีลิงก์ไปยังงานนำเสนอที่น่าสนใจจาก Pete Hunt ของ Facebook ซึ่งเขาพูดถึงส่วนประกอบที่ไม่ใช่แม่แบบและแยกข้อกังวลในแอปพลิเคชันภาษาแทนที่จะแยกข้อกังวลของกรอบงานเช่นแม่แบบ css และ javascript เป็นต้น

ในการแยกข้อกังวลของคุณในภาษาของแอปพลิเคชันของคุณสิ่งนี้อาจเกี่ยวข้องกับการใช้รูปแบบต่าง ๆ เพื่อแยกหรือแยกรหัสของคุณออกเป็นรูปแบบโมดูลาร์ที่สามารถทดสอบหน่วยเป็นต้น

ดังนั้นการสรุปการแยกข้อกังวลอาจขึ้นอยู่กับบทบาทหรือมุมมองของคุณ