https://virgool.ir/feed/@ali.karimi.elctبرنامه نویس ، توسعه دهنده و تحلیلگر نرم افزارfa2026-11-12 10:47:38https://files.virgool.ir/upload/users/86403/avatar/L07PXb.pnghttps://virgool.ir/@ali.karimi.elcthttps://virgool.ir/@ali.karimi.elct/چرا-prototype-می-سازیم-hxutpdxuczwbیک نمونه ی اولیه می تواند نکات نادیدنی را نسبت به یک طرح ساده آشکار نمایداهداف طراحی prototype:1.واضح و ملموس شدن فرآیند ها برای کارفرما 2.مرور بهتر فرآیند ها در قالبی نزدیک به واقعیت 3.اشتراک گذاری با ذینفعان جهت ارزیابی و نظرسنجی از لحاظ کاربرد و تعامل طراحی مورد نظر با کاربر 4.درک بهتر عملکرد نرم افزار و ارزیابی از لحاظ رفع نیازها 5.بررسی نرم افزار از لحاظ UX/UI (واسط کاربری و تجربه کاربری)6.کمک به طراحان و تیم پیاده سازی کننده نرم افزار و مشخص شدن طرح کلی نرم افزاری که باید پیاده سازی شود. 7.کمک به کاهش تغییرات در مرحله پیاده سازی نرم افزار یا بعد از آن و به همان نسبت کاهش هزینه ها.یک prototype یک نمونه و طرح اولیه از پیاده سازی نرم افزار است که قالب و طرح کلی نرم افزاری که قرار است پیاده سازی شود را مشخص میکند و از آنجا که نمونه تصویری و قابل مشاهده میتواند معنای بیشتری نسبت به نمودارهای فنی برای کاربران نرم افزار داشته باشد، Prototype کمک می کند تا کاربران و ذینفعان پروژه درک بهتری نسبت به فرآیند های نرمافزار پیدا کنند و چه بسا برخی از نیازهای نادیده گرفته شده در فرآیند ها در این مرحله مشخص شود. یک نمونه ی اولیه می تواند نکات نادیدنی را نسبت به یک طرح ساده آشکار نماید.اعمال تغییرات در فرآیندها و رابط کاربری و اطمینان از صحت آنها به مراتب راحت تر و کم هزینه تر از اصالح نرم افزاری است که پیاده سازی شده، در نتیجه دقت در ارزیابی و تایید نمونه اولیه برای ادامه پروژه مهم است.ارزیابی Prototypeبعد از ساخت prototype ، باید آن را از لحاظ تجربه کاربری )راحتی در استفاده، سادگی استفاده در عین رفع نیاز ها( و از لحاظ فنی )روش های پیاده سازی ، زمان و هزینه الزم برای آن( ، و همچنین مطابقت با فرآیند های طراحی شده یا در صورت الزم تغییر و اصالح فرآیندها بررسی کرد.1. بررسی Prototype با فرآیندهای نرم افزار برای اطمینان از تطابق آنها با یکدیگر2. نظرسنجی و بررسی بازخورد کارفرمایان نسبت به طرح اولیه و اصالح طراحی یا حتی فرآیند ها در صورت لزومبرای مثال : ممکن است ، کارفرما بعد از مشاهده و کار با نمونه اولیه به نظرش برسد که اگر در فرم ثبت نام همزمان با ورود نام ، تلفن همراه هم وارد شود بهتر از این است که اول تلفن وارد شده و در مرحله بعد نام وارد شود.3. بررسی نمونه اولیه از لحاظ رابط کاربری و مو ارد طراحی مثل رنگ و اندازه فونت ها و غیرهبرای مثال ممکن است کارفرما نظرش این باشد که موجودی کاربر فقط در منو قابل رویت باشد نه در باالی صفحه اصلی یا نظرش این باشد که رابط کاربری رنگ بندی دیگری داشته باشد و غیره.نتیجه حاصل از Prototypeبعد از طراحی Prototype و ارزیابی و تایید آن ، سندی در دسترس خواهد بود که تیم پیادهسازی کننده از طریق آن تا حدی از مسائل طراحی فارغ شده و می توانند با اتکا به این سند نرم افزار را پیاده سازی کنند و همچنین کارفرما به کمک Prototype میتواند تا حد زیادی نسبت به نرم افزاری که قرار است پیاده سازی شود ذهنیت پیدا کرده و همچنین بعد از پیاده سازی، سندی برای ارزیابی و بررسی نرم افزار پیاده سازی ش ده برای تطابق با خواسته های خود داشته باشد.علی کریمیعلی کریمیFri, 07 Jan 2022 01:57:37 +0330https://virgool.ir/@ali.karimi.elct/نکاتی-درباره-domain-driven-design-u35fad79kczkاز زمانی که با Domain driven design آشنا شده ام هر روز با مطالب جدیدتری در این حوزه آشنا شده و تجارب بیشتری کسب می کنم. آشنایی با یک مفهوم بزرگ مثل Domain driven design صرفا خواندن کتاب نیست و استفاده از آن به تجربه نیاز دارد . با افراد زیادی در این خصوص صحبت کرده ام ، از افراد تازه کار در حوزه توسعه نرم افزار گرفته تا کسانی که چندین سال در این زمینه سابقه و تجربه دارند. با این حال هنوز در بین صحبت های همه این افراد برداشت های نادرست و تعابیر غلطی وجود دارد که سبب اشتباهات رایجی می شود و شخصا نیز بارها درگیر آنها شده ام ، که نشان از عدم درک درست از Domain driven design در جامعه توسعه دهندگان نرم افزار است.بنابراین سعی کردم تا چند نکته مهم و کاربردی را در خصوص Domain driven design جمع آوری کرده و در غالب این مطلب بازگو نمایم . در Domain driven design مهمترین مساله شناخت دقیق کسب و کار و دامنه آن است ، یعنی همان چیزی که پروژه برای تحقق آن شروع شده و پیش می رود .1- طراحی مبتنی بر دامنه (DDD) یک معماری نرم افزار نیست.2- طراحی مبتنی بر دامنه یک رویکرد و مجموعه ای از مفاهیم است که در تمام فاز های چرخه توسعه کاربرد دارد مانند TDD و EDD .3- برای مسائل و پروژه های کوچک و ساده نیازی به استفاده از آن نیست. (یا حداقل نیازی به استفاده کامل و جامع از آن نیست)4- از DDD برای تحلیل و پیشبرد پروژه های بزرگ و پیچیده استفاده می شود.5- هر کدی که لایه Domain model را جدا کرده بود لزوما DDD را رعایت نکرده ، همانطور که اگر برای یک پروژه تست نوشته شده باشد لزوما TDD را رعایت نکرده .6- استفاده از معماری های Domain centric مثل Onion و Clean لزوما به معنای این نیست که ما پروژه را با رویکرد DDD پیش می بریم.7- در DDD اصل موضوع ، روش تحلیل و برخورد با صورت مسئله و روش شناسایی نیازمندی ها و دانش دامنه کسب و کار و روش های استراتژیک آن است ، نه روش های پیاده سازی .8- در DDD ، درخصوص معماری مورد استفاده در پیاده سازی اجباری نیست و فقط پیشنهاداتی برای آن دارد.9- رویکرد DDD را میتوان با معماری Onion یا Clean یا هر معماری Domain centric دیگر پیاده سازی کرد.10- مهمترین اصل DDD در مرحله پیاده سازی ، پیاده سازی با زبان دامنه و کسب و کار و فارغ از تکنولوژی بودن دامنه پروژه است.11- در DDD برای نحوه صحبت کردن با صاحب محصول هم روش و استراتژی وجود دارد.12- وقتی کد های یک پروژه که به روش DDD پیاده سازی شده را می خوانید باید بتوانید تشخیص دهید که این کدها مربوط به چه کسب و کاری است و به راحتی از کد ، به کسب و کار پشت آن پی ببرید.(کد باید با آدم حرف بزنه)13- تشخیص و جداسازی درست Aggregate ها در DDD کمک میکند تا در آینده خیلی راحت تر بتوان پروژه را توسعه داد ، scale out کرد یا هر کدام از Aggregate ها را به طور مستقل توسعه داد.14- استفاده از DDD کمک میکند تا نیاز کمتری به نوشتن داکیومنت برای کدها ، ای پی آی ها و غیره داشته باشیم. مستندات کسب و کار و فرآیند ، مهم تر هستند.15- برای DDD مهم نیست که شما از معماری Clean , Onion , N-Layer یا غیره استفاده میکنید ، اگرچه پیاده سازی آن با معماری Clean در حال حاظر اوج هنرمندی در دنیای توسعه نرم افزار است.15- زمان ، هزینه ، توانایی تیم توسعه و امکانات در اختیار را ، باید برای انتخاب رویکرد DDD در نظر گرفت.16- اگر پروژه را با رویکرد Domain driven design پیش می بریم ، باید Context map کاملی از کسب و کار و پروژه داشته باشیم ، که همه اعضای تیم توسعه ، کنترل پروژه ، مدیریت و صاحب محصول از آن اطلاع داشته باشند.17- بدون شناخت و تحلیل درست کسب و کار و دانش دامنه ، ادامه راه DDD و ورود به مرحله پیاده سازی صحیح نیست.18- اگر عضو جدیدی وارد تیم توسعه می شود ابتدا باید با کسب و کار و دامنه پروژه آشنا شود تا بداند که برای چه چیزی کار میکند و چگونه ارزش آفرینی کند.علی کریمیعلی کریمیFri, 29 Jan 2021 17:49:17 +0330https://virgool.ir/CodeLovers/مقدمه-کتاب-کد-تمیز-راهنمای-مهارت-های-چابک-ساخت-نرم-افزار-بخش-دوم-cokxg5y52j3gدر بخش اول این مقدمه در خصوص اهمیت توجه به جزئیات و اصول 5S خواندید با ما باشید تا در این بخش مقدمه این کتاب را به پایان برسانیمدر جستجوی دیگران که خانه خدا را به عنوان جزئیات توصیف می کنند ، ما در جمع خوب نویسنده فرانسوی قرن نوزدهم گوستاو فلوبر قرار داریم. پل والری شاعر فرانسوی به ما توصیه می کند که شعری هرگز ساخته نمی شود و به طور مداوم به کار نیاز دارد، و متوقف کردن کار بر روی آن، متروکه رها کردن است. چنین دغدغه ای با جزئیات در همه تلاشهای تعالی مشترک است. بنابراین شاید در اینجا چیز جدیدی وجود نداشته باشد ، اما در خواندن این کتاب شما را به چالش می کشند که رشته های خوبی را که مدتها پیش در مورد آنها تسلیم بی علاقگی یا تمایل به خود بینی و فقط "پاسخ دادن به تغییر" شده اید ، بپذیرید.ساده بودن این اعمال به معنای ساده انگاری بودن آنها نیست و به سختی به معنای آسان بودن آنهاست.متأسفانه ، ما معمولاً چنین نگرانی هایی (کد نویسی تمیز و توجه به جزئیات) را به عنوان ارکان اصلی هنر برنامه نویسی نمی دانیم. ما کد خود را زود رها می کنیم ، نه به این دلیل که کار روی آن انجام شده و تمام شده است ، بلکه به این دلیل است که سیستم ارزش ما بیشتر به ظاهر متمرکز است تا به ذات آنچه ما تحویل می دهیم. این بی توجهی در نهایت برای ما هزینه دارد. با توجه به روزهای کاری خود در سازمان تحقیقات تولید نرم افزار آزمایشگاه های بل (تولید ، واقعاً!) .حرفه ای بودن مدیون تسلط بر ابزارها و روش های طراحی عالی است، جهان بینی ژاپنی، ارزش حیاتی کارگران روزانه و بیشتر از آن ، سیستم های توسعه را مدیون فعالیت های ساده روزانه این کارگران می داند. کیفیت نتیجه یک میلیون مراقبت ایثارگرانه است - نه فقط از هر روش عالی که از آسمان نازل می شود. ساده بودن این اعمال به معنای ساده انگاری بودن آنها نیست و به سختی به معنای آسان بودن آنهاست. با این وجود آنها حاصل عظمت و بیشتر از آن زیبایی در هر تلاش انسانی هستند. نادیده گرفتن آنها هنوز کاملاً انسانی نیست.سیستم ارزش ما بیشتر به ظاهر متمرکز است تا به ذات آنچه ما تحویل می دهیم.این کتاب پیام لطیفی دارد که نباید عمق آن را دست کم گرفت.البته ، من هنوز طرفدار تفکر در دامنه وسیع تر و به ویژه ارزش رویکردهای معماری هستم که ریشه در دانش عمیق حوزه کاربرد نرم افزار دارد. این کتاب در این مورد نیست - یا حداقل بدیهی است که در این مورد نیست. این کتاب پیام لطیف تری دارد که نباید عمق آن را دست کم گرفت. این با ضرب المثل کنونی افراد واقعاً مبتنی بر کد مانند پیتر سامرلاد ، کوولین هنی و جیووانی آسپونی متناسب است. "کد ، طراحی است" و "کد ساده" سروده آنها است. در حالی که باید توجه داشته باشیم که رابطهای برنامه است که ساختارهای آن در مورد ساختار برنامه ما حرفهای زیادی برای گفتن دارند ، اما اتخاذ موضع فروتنانه ای که طراح در کد دارد ، بسیار مهم است. و در حالی که دوباره کاری در استعاره ساخت منجر به هزینه می شود ، دوباره کاری در طراحی منجر به ارزش می شود. ما باید کد خود را به عنوان بیان زیبایی از تلاش های اصیل طراحی بدانیم - طراحی به عنوان یک فرآیند ، نه یک نقطه پایان ایستا. این در کدی است که معیارهای اتصال و انسجام معماری را نشان می دهد. اگر به لاری کنستانتین در توصیف اتصال و انسجام گوش دهید ، او با توجه به کد صحبت می کند - نه مفاهیم مجرد انتزاعی که ممکن است در UML پیدا کند. ریچارد گابریل در مقاله خود ، "Abcraction Descant" به ما توصیه می کند که انتزاع شیطانی است. کد ضد شیطان است و کد پاک شاید الهی باشد.ما باید کد خود را به عنوان بیان زیبایی از تلاش های اصیل طراحی بدانیمریچارد گابریل در مقاله خود ، "Abcraction Descant" به ما توصیه می کند که : انتزاع شیطانی است. کد ضد شیطان است و کد پاک شاید الهی باشد.با نگاهی دوباره به جعبه کوچک Ga-Jol ، فکر می کنم مهم است که توجه داشته باشیم که حکمت دانمارکی به ما توصیه می کند : نه تنها به چیزهای کوچک توجه کنیم ، بلکه در کارهای کوچک نیز صادق باشیم. این به معنای صادق بودن با کد ، صادق بودن با همکاران درمورد وضعیت کد ما و بیش از همه ، با خود صادق بودن در مورد کد خود است. آیا ما تمام تلاش خود را کرده ایم؟ آیا ما قبل از ورود به سیستم کد شما را اصلاح کردیم؟ اینها نگرانی های پیرامونی نیستند بلکه نگرانی هایی هستند که کاملاً در مرکز ارزشهای چابک قرار دارند. این یک روش توصیه شده در اسکرام است که فاکتورسازی مجدد بخشی از مفهوم "انجام شده (Done) " باشد. نه معماری و نه کد تمیز بر کمال تأکید ندارند ، فقط به صداقت و بهترین کاری که می توانیم انجام دهیم. خطا كردن کار انسان است؛ بخشش ، الهی. در Scrum ، همه چیز را قابل مشاهده می کنیم. ما در مورد وضعیت کد خود صادق هستیم زیرا کد هرگز کامل نیست. ما کاملاً انسانی تر می شویم ، شایسته الهی ترینیم و در جزئیات به آن عظمت نزدیکتر می شویم. در حرفه خود ، ما به شدت به همه کمکی که می توانیم بگیریم نیاز داریم. اگر کف تمیز مغازه ها برخود ها و تصادفات را کاهش می دهد و ابزارهای منظم فروشگاهی باعث افزایش بهره وری می شود ، من هم طرفدار آنها هستم. در مورد این کتاب ، این بهترین کاربرد عملی اصول ناب در نرم افزار است که تاکنون چاپ شده است. این قبل از اینکه عمو باب نسخه خطی را برای من بفرستد ، کمی بهتر از آنچه من پیدا کردم ، دنیا را ترک می کند. پس از اتمام این تمرین با بینش عالی ، می خواهم میز کار خود را تمیز کنم.نه تنها به چیزهای کوچک توجه کنیم ، بلکه در کارهای کوچک نیز صادق باشیم. این به معنای صادق بودن با کد ، صادق بودن با همکاران درمورد وضعیت کد ما و بیش از همه ، با خود صادق بودن در مورد کد خود است. آیا ما تمام تلاش خود را کرده ایم؟James O. CoplienMørdrup, Denmarkعلی کریمیعلی کریمیTue, 22 Dec 2020 00:47:18 +0330https://virgool.ir/CodeLovers/مقدمه-کتاب-کد-تمیز-راهنمای-مهارت-های-چابک-ساخت-نرم-بخش-اول-افزار-bwy8fslmzhk7وقتی کتاب Clean code نوشته Robbert C.martin را خواندم ، مقدمه آن را جا انداخته بودم ، یک روز تصمیم گرفتم جهت سرگرمی مقدمه این کتاب را بخوانم ، خواندن این مقدمه باعث شد تا دوباره کتاب را با دید عمیق تر بخوانم . خواندن مقدمه این کتاب را به همه مهندسان نرم افزار پیشنهاد می کنم. تصمیم گرفتم این کتاب رو به طور عمقی بخوانم و ترجمه آن را در اینجا بنویسم . با مقدمه این کتاب شروع میکنیم و برای جلوگیری از خستگی خوانندگان آن را در دو یا سه بخش ارائه خواهم کرد.کد تمیز : راهنمای مهارت های چابک ساخت نرم افزارنوشته Robbert C.martinمقدمهماموریت این مجموعه بهبود وضعیت هنر توسعه نرم افزار است. کتاب های این مجموعه فنی ، عملی و اساسی هستند. نویسندگان آن ، درمورد آنچه در عمل انجام می شود نوشته اند ، بر خلاف آنچه که تنها در تئوری می تواند کار کند. در واقع شما در مورد آنچه که نویسنده انجام داده می­خوانید نه در مورد آنچه که فکر میکند شما باید انجام دهید. کتاب ، مربوط به برنامه نویسی است پس نمونه های زیادی کد داخل آن هست و نمونه های زیادی از پروژه های واقعی دارد.این سری کتاب هایی هستند که همه شاغلان جدی در حوزه برنامه نویسی آنها را در کتابخانه خود دارند. این کتاب ها ، کتاب هایی هستند که به دلیل تغییر و راهنمایی افراد حرفه ای برای تبدیل شدن به یک استادکار واقعی به یادگار می مانندنوشتن کد تمیز کاری است که باید انجام دهید، تا خودتان رو حرفه ای بدانید . هیچ عذر و منطقی برای انجام کاری کمتر از بهترین کار شما وجود ندارد. بسیاری از نامگذاری هایی که تولیدکنندگان و فروشندگان برای تمایز محصولات خود از آنها استفاده می کنند ، به عنوان علامت­های تجاری قلمداد می شوند.پیش گفتاریکی از آب نبات های مورد علاقه ما در اینجا در دانمارک Ga-Jol است که بخارات شیرین بیان قوی آن مکمل مناسبی برای آب و هوای مرطوب و اغلب سرد است. بخشی از جذابیت Ga-Jol برای ما دانمارکی ها سخنان خردمندانه یا شوخ طبعی است که بر روی فلپ هر جعبه چاپ شده است.صداقت در کارهای کوچک چیز کمی نیست. " این جمله خوب مطابق با آنچه می خواستم اینجا بگویم بود. چیزهای کوچک مهم هستند. این کتابی درباره نگرانی های کوچیک است با این وجود ارزش آنها کم نیست.لودویگ میس ون در روهه (Ludwig Mies van der Rohe) گفت : خدا در جزئیات است. این نقل قول بحث های معاصر درباره نقش معماری در توسعه نرم افزار را به یاد می آورد و به ویژه در جهان چابک من و باب (Uncle Bob) گهگاه می بینیم که با شور و اشتیاق درگیر این گفتگو هستیم. و بله ، میس ون در روهه مارا متوجه سودمندی و بی انتهایی آن ساخت ، که زمینه ساز معماری عالی بود. از طرف دیگر ، او شخصاً هر دستگیره درب را برای هر خانه ای که طراحی کرده انتخاب کرده است. چرا؟ زیرا کوچکترین چیزها هم مهم هستند.لودویگ میس ون در روهه - معمار آلمانی - آمریکایی خدا در جزئیات استدر "بحث" مداوم ما در مورد TDD ، من و باب کشف کردیم که ما توافق داریم که معماری نرم افزار از جایگاه مهمی در توسعه برخوردار است ، هرچند که ما احتمالاً دیدگاه های متفاوتی از معنای دقیق آن داریم. چنین ابهاماتی نسبتاً مهم نیستند ، زیرا ما مسلماً می توانیم قبول کنیم که متخصصان مسئول ، در ابتدای پروژه ، مدتی را به تفکر و برنامه ریزی اختصاص دهند. مفاهیم طراحی اواخر دهه 1990 که فقط توسط آزمونها و کد ارائه می شدند ، مدتهاست که از بین رفته اند. حتی با این وجود یکی از مهمترین پایه ها و اساس حرفه ای بودن توجه به جزئیات است. اولا تمرین در موضوعات کوچک است که حرفه ای ها مهارت و اعتماد به عمل در سطح بزرگ را کسب می کنند. دوما کوچکترین نامرتبی در ساخت و ساز ، دربی که محکم بسته نمی شود، کاشی ای که اندکی کج است یا حتی یک میز آشفته ، کاملا جذابیت بزرگتر کل را از بین می برد. این در مورد همان کد تمیز است. هنوز هم معماری فقط یک استعاره از توسعه نرم افزار است بویژه برای آن بخش که محصول اولیه ای را ارائه می کنیم ، همانند معماری که ساختمان بکری را تحویل می دهد.این روزها اسکرام و چابکی بر روی تحویل سریع محصول به بازار تمرکز دارند. ما می خواهیم کارخانه با حداکثر سرعت برای تولید نرم افزار کار کند، کارخانه های انسانی : تفکر و احساس کد نویسانی که از یک پس زمینه محصول (Backlog) یا داستان کاربر (User story) برای ایجاد محصول استفاده می کنند. استعاره ساخت و ساز در چنین تفکری بسیار قدرتمند است. بخش اعظم جنبه های تولید و ساخت اتوموبیل های ژاپنی از اسکرام الهام میگیرد.بیشتر کار نه در تولید بلکه در تعمیر و نگهداری یا اجتناب از آن استحتی در صنعت اتومبیل سازی ، بیشتر کار نه در تولید بلکه در تعمیر و نگهداری یا اجتناب از آن است. در نرم افزار ، 80٪ یا بیشتر آنچه که ما انجام می دهیم کاملاً "تعمیر و نگهداری" نامیده می شود. به جای اینکه از تمرکز معمول غربی در تولید نرم افزارهای خوب استقبال کنیم ، باید بیشتر شبیه تعمیرکاران خانه در صنعت ساختمان یا مکانیک خودرو در زمینه خودرو باشیم. مدیریت ژاپن در این باره چه می گوید؟در حدود سال 1951 ، رویکردی با کیفیت به نام Total Productive Maintenance (TPM) در صحنه ژاپن ظاهر شد. تمرکز آن بر تعمیر و نگهداری است تا تولید. یکی از ارکان اصلی TPM مجموعه اصول 5S است. 5S مجموعه ای از رشته ها است و در اینجا من اصطلاح "رشته" را به طور آموزنده استفاده می کنم. این اصول 5S در واقع در پایه های Lean - کلید واژه دیگری در صحنه غرب و سخنان فزاینده برجسته در محافل نرم افزاری است. این اصول یک گزینه نیست. همانطور که Uncle bob در مورد موضوعات اصلی خود بیان می کند ، نرم افزار خوب به چنین نظم و انضباطی نیاز داردتمرکز ، حضور ذهن و تفکر ، همیشه فقط کار کردن مهم نیست ، فشار دادن تجهیزات کارخانه برای تولید با سرعت بهینه مهم نیست. فلسفه 5S شامل این مفاهیم است:اصل 1 - Seiri - سازماندهی (یا مرتب سازی) : دانستن اینکه مکان ها از رویکرد هایی مثل نامگذاری درست استفاده میکنند .فکر می کنید نامگذاری شناسه ها مهم نیست؟ ادامه در فصل های بعدی.اصل 2 - Seiton یا نظافت (فکر کنید "به انگلیسی" systematize ). یک جمله قدیمی آمریکایی وجود دارد: مکانی برای هر چیزی ، و همه چیز در جای خود. قطعه ای از کد باید همان جایی باشد که انتظار دارید آن را پیدا کنید.اصل 3 - Seiso یا نظافت (به انگلیسی "shine" فکر کنید): محل کار را از سیم های آویز ، چربی ، ضایعات و ضایعات دور نگه دارید. نویسندگان اینجا درباره پر کردن کد شما با نظرات و خطوط کد نظر داده شده که تاریخ یا آرزوهای آینده را ضبط می کنند ، چه می گویند؟ از شر آنها خلاص شوید.اصل 4 - Seiketsu یا استاندارد سازی: این گروه در مورد نحوه تمیز نگه داشتن محل کار به توافق می رسند. آیا فکر می کنید این کتاب در مورد داشتن یک سبک برنامه نویسی و مجموعه ای از اقدامات مداوم در گروه چیزی گفته است؟ این استانداردها از کجا آمده است؟ ادامه مطلب در فصل های بعدی.اصل 5 - Shutsuke یا نظم و انضباط (خود انضباطی). این بدان معنی است که نظم و انضباطی برای پیروی از روش ها و تأمل مکرر در کار خود داشته باشید.خوانایی کد شما به همان اندازه قابلیت اجرای آن اهمیت دارد.در اینجا ، ما در نهایت به ریشه های حرفه ای مسئولیت پذیری، در حرفه ای می پردازیم که مربوط به چرخه عمر یک محصول است. همانطور که ما اتومبیل ها و ماشین آلات دیگر را تحت TPM نگهداری می کنیم ، اشکال در تعمیر و نگهداری و انتظار برای بروز اشکالات سطحی، از این قاعده مستثنی است. در عوض ، ما یک سطح بالا می رویم: ماشین ها را هر روز بازرسی می کنیم و قطعات پوسیده را قبل از شکستن تعمیر می کنیم ، یا روغن 10،000 مایلی را برای جلوگیری از سایش و پارگی تعویض میکنیم. خوانایی کد شما به همان اندازه قابلیت اجرای آن اهمیت دارد.روش نهایی که از سال 1960 در محافل TPM معرفی شده ، تمرکز بر راه اندازی کامل ماشین های جدید یا جایگزینی ماشین های قدیمی است. همانطور که فرد بروکس به ما هشدار می دهد ، ما احتمالاً باید هر هفت سال یکبار قسمتهای اصلی نرم افزار را از ابتدا توسعه دهیم تا مشکلاتی که باعث می شوند زیر و بم نرم افزار را تغییر دهیم را از بین ببریم. شاید ما باید ثابت زمان بروکس را به جای سالها به ترتیب چند هفته ، روز یا ساعت به روز کنیم. این جایی است که جزئیات نهفته است. (این ثابت زمانی را میزان توجه به تجزئیات تعیین میکند)قدرت زیادی در جزئیات است . هنوز چیزی عمیق در مورد این رویکرد زندگی وجود دارد، همانطور که از هر روشی که ادعای ریشه ژاپنی را داشته باشد ، به طور کلیشه ای انتظار داریم. اما این فقط یک نگاه شرقی به زندگی نیست. خرد عامیانه انگلیسی و آمریکایی هم پر از چنین پندهایی است. نقل قول Seiton از قلم وزیر اوهایو سرچشمه می گرفت که به معنای واقعی کلمه آراستگی "به عنوان دارویی برای هر درجه از شر" بود. Seiso چطور؟ نظافت در کنار خداپسندی است. به همان زیبایی خانه ،که میز تحریر شلوغ جلال و شکوه آن را می رباید. Shutsuke در این مسائل کوچک چطور؟ کسی که در مسائل کوچک وفادار و مراقب باشد ، در خیلی چیزها وفادار است. چطوره که بجای به تعویق انداختن تصمیم در زمان مسئولیت خودتان ، مشتاق به تغییرات برای قوی شدن برای تصمیمات بزرگ آتی باشید؟ یک بخیه به موقع خیلی مهم است، کاری که امروز می توانید انجام دهید را به فردا موکول نکنید. در مورد کالیبره کردن مکان تلاش های کوچک و فردی در یک کل عام چطور؟ بلوط های قدرتمند از بلوط های کوچک رشد می کنند. یا ادغام کارهای پیشگیرانه ساده در زندگی روزمره چطور؟ هر اونس پیشگیری ارزش یک پوند درمان را دارد. مصرف یک سیب در هر روز شما را از دکتر دور نگه می دارد. کد تمیز ریشه های عمیق خرد را در زیر فرهنگ گسترده ما ، یا فرهنگ ما همانطور که قبلاً بوده یا باید باشد ، ارج می نهد و می تواند با دقت به جزئیات باشد.آراستگی "به عنوان دارویی برای هر درجه از شر" حتی در ادبیات عظیم معماری نیز ضرب المثل هایی را می یابیم که به این جزئیات مفروض بازمی گردند. به دستگیره های درب mies van der Rohe فکر کنید، این Seiri است. توجه به هر نام متغیر. شما باید یک متغیر را با استفاده از همان مراقبتی که با آن فرزند اول خود را نام گذاری می کنید، نامگذاری کنید.همانطور که هر صاحب خانه ای می داند ، چنین مراقبت ها و پالایش های مداوم هرگز به پایان نمی رسند. معمار کریستوفر الكساندر - پدر الگوها و زبانهای الگو - خود هر عمل طراحی را به عنوان یك عمل ترمیم كوچك می داند. او اشکالات ظریف را برای برطرف کردن به دست استادکاران می دهد و می گوید میتوان اشکالات بزرگ را با الگو ها بدست ساکنین نیز سپرد. نه تنها با افزودن یک اتاق جدید به یک خانه ، بلکه همیشه توجه به نقاشی ، جایگزینی فرشهای فرسوده یا به روزرسانی سینک ظرفشویی آشپزخانه همیشه در حال انجام است. بیشتر هنرها احساسات مشابه را تکرار می کنند. اشکالات ظریف را برای برطرف کردن به دست استادکاران دهید ، میتوان اشکالات بزرگ را با الگو ها بدست ساکنین نیز سپرد.ادامه در بخش دومعلی کریمیعلی کریمیFri, 18 Dec 2020 23:25:25 +0330https://virgool.ir/@ali.karimi.elct/تفکیک-نگرانی-ها-separation-of-concerns-قسمت-اول-kyhdrikayf7lتفکیک نگرانی هاتفکیک نگرانی ها (SOC) ، یک اصل مهم در مراحل برنامه ریزی ، معماری و طراحی است. هدف ، درک ، طراحی و مدیریت موثر سیستم هایی با وابستگی های پیچیده است. به طوری که عملکردها بتوانند استفاده مجدد بشوند و به طور مستقل از سایر عملکردها بهبود داده بشوند و توسعه پیدا کنند و از خرابی های بلقوه عملکردهای دیگر ایزوله باشند و در امان بمانند.در علوم کامپیوتر، SOC یک اصل طراحی برای جداسازی برنامه به بخش های مجزا است ، به طوری که هر بخش به جداسازی یک نگرانی بپردازد . نگرانی یا Concern مجموعه ای از اطلاعات است که میتوانند بر کد برنامه کامپیوتری اثر بگذارند.یک نگرانی میتواند جزئیات سخت افزاری باشند که کد را برای سازگاری با آن بهینه کرده ایم یا جزئیات برقراری ارتباط با دیتابیسی خاص و… .به برنامه ای که SOC را به خوبی رعایت کرده باشد ، برنامه ماژولار می گویند . در همچین برنامه ای شما میتوانید خیلی از نگرانی ها را تغییر داده و یا پیاده سازی آنها را تغییر دهید بدون آنکه نیازی به تغییر قسمت های دیگر برنامه داشته باشید. برای مثال فرض کنید که برنامه ما در حال حاظر برای کار با دیتابیس SQL Server نوشته شده باشد و قرار باشد دیتابیس را به Oracle تغییر دهند . اگر کدهای مربوط به این بخش را به خوبی جدا کرده باشیم (در کلاس ها یا پکیج های مشخص ) به راحتی میتوانیم با تغییر بخش مورد نظر نرم افزار را برای کار با دیتابیس Oracle تغییر دهیم . اما اگر کدهای مربوطه به درستی جداسازی نشده باشند و در کل پروژه پخش باشند مجبوریم کل پروژه را بگردیم و کدها را تغییر دهیم که فرآیندی زمان بر و هزینه بر است همچنین ممکن است برخی از قسمت ها از قلم بیفتند و باگ هایی ایجاد کنند .ماژولار کردن برنامه از طریق جمع آوری اطلاعات و کدهای مرتبط به یک موضوع و نگرانی در یک بخش جدا که دارای رابط مشخصی است بدست می آید. کپسوله سازی (Encapsulation) ، که برای پنهان سازی اطلاعات استفاده میشود ، کاربرد زیادی در جداسازی نگرانی ها دارد . همچنین معماری ها و الگوهای طراحی مختلف یکی دیگر از روش های رعایت SOC است.تفکیک نگرانی ها (SOC) ، در طراحی ، توسعه و استفاده از نرم افزار برای ما درجات آزادی بیشتری را فراهم میکند. در میان این موارد درجات آزادی بیشتر در ساده سازی و نگهداری کد از تاثیرات مهم SOC است.وقتی جداسازی نگرانی ها به خوبی انجام شده باشد ، درجه آزادی بیشتری برای استفاده مجدد ، توسعه ماژول و ارتقا آن بدست می آید. از آنجا که ماژول ها جزئیات نگرانی های خود را در پشت رابط ها پنهان می کنند، آزادی بیشتری برای بهبود و تغیرات یک بخش از نگرانی ها را بدون دانستن جزئیات و بدون تغییر در بخش های دیگر فراهم میکند . همچنین هر ماژول میتواند نسخه های مختلف رابط (Interface) را ارئه کند تا بتواند به راحتی عملکردهای خود را به شکل های مختلف ارائه کند یا برای هر بخشی عملکردهای مختص آن را ارئه کند و این مسئله بویژه در سیستم های بزرگ و پیچیده باعث افزایش آزادی ارتقا بخش های مختلف میشود.تفکیک نگرانی ها ، شکلی از انتزاء است . مانند خیلی از انتزاء های دیگر باید رابط ها (Interface) اضافه شوند تا کد داخل هر بخش به شکل خالص تری اجرا شود (یعنی برای اجرا کمترین وابستگی را به بخش های دیگر و جزئیات آنها داشته باشد).بنابراین با وجود مزایای بالای SOC ، شما باید جریمه ایجاد ارتباطات و رابط ها را بپردازید. البته مطمئن باشید که ارزشش را دارد.تفکیک نگرانی های تجاری و سیستمیپیاده سازی :در زبان های برنامه نویسی ، مکانیسم هایی برای برنامه نویسی شیئ گرا و ایجاد SOC ارئه شده است. برای مثال در زبان های شیئ گرا مثل #C و ++C و Java و امثال آن از آبجکت ها برای جداسازی استفاده میکنند و همچنین توسط الگوهای معماری مانند MVC و MVP ، مدل محتوا ، نحوه ارائه آن و پردازش آن را جدا میکنند. طراحی سرویس گرا (Service oriented design) نگرانی ها را در سرویس ها جدا میکند. زبان های ساخت یافته ، مثل C و پاسکال نگرانی ها را تنها در Function ها و Procedure ها جدا میکنند . زبان های برنامه نویسی جنبه گرا(Aspect Oriented) میتوانند نگرانی ها را در آبجکت ها و جنبه ها (Aspect) جدا کنند.تفکیک نگرانی به شکل عمودی و افقیتفکیک نگرانی ها (SOC) ، یک اصل مهم در مراحل برنامه ریزی ، معماری و طراحی است. هدف ، درک ، طراحی و مدیریت موثر سیستم هایی با وابستگی های پیچیده است. به طوری که عملکردها بتوانند استفاده مجدد بشوند و به طور مستقل از سایر عملکردها بهبود داده بشوند و توسعه پیدا کنند و از خرابی های بلقوه عملکردهای دیگر ایزوله باشند و در امان بمانند.در علوم دیگر : اصل SOC نه تنها در علوم کامپیوتر، بلکه در بسیاری از علوم و فعالیت های دیگر نیز کاربرد دارد. برای مثال جدا کردن یک فضای کلی به اتاق های مختلف که فعالیت عده ای در یک اتاق مزاحم فعالیت عده ای در اتاق دیگر نشود یا جدا کردن مدار الکتریکی بخاری برقی و روشنایی به طوری که بتوان هر کدام را مستقل کنترل کرد و روشن و خاموش کردن یکی به دیگری ربطی نداشته باشد و همچنین بتوان لامپ روشنایی را با هر مدلی جایگزین کرد بدون آنکه فرقی به حال بخاری برقی داشته باشد.مثال اتاق ها نمونه ای از کپسوله سازی است ، به طوری که اتفاقات درون اتاق برای اتاق های دیگر در دسترس نیست مگر از طریق رابط آن ، که همان درب آن است. به همین ترتیب در مثال مدارهای الکتریکی ، اتفاقات هر ماژول الکتریکی و مدار آن به ماژول های دیگر و مدارهای دیگر مربوط نیست.منشا :اصطلاح و لفظ SOC احتمالا توسط Edsger W. Dijkstra در مقاله او در سال ۱۹۷۴ درباره نقش اندیشه علمی ، ابداع شده است. SOC فقط مختص به رشته نرم افزار و برنامه نویسی نیست و در همه علوم کاربرد دارد به طور کلی SOC میگوید که اگر بخواهید مسئله ای را حل کنید باید از جنبه های مختلف به آن نگاه کنید و آن را بررسی کنید. شما نمیتوانید روی همه جنبه های مسئله به طور همزمان تمرکز کنید خصوصا که ممکن است هر کدام از آنها نیاز به تخصص خاصی داشته باشند . شما باید بر روی هر جنبه آن مسئله به طور خاص تمرکز کنید، آن را حل کنید و بعد سراغ جوانب دیگر بروید، حتی ممکن است لازم شود تا بررسی برخی از جوانب مسئله را به افراد دیگر بسپارید. این اصل در خیلی از علوم قرار دارد و به ویژه در علوم کامپیوتر راه پیدا کرده است.۱۵ سال بعد بدیهی بود که ، SOC به یک ایده مورد قبول تبدیل شد. در سال ۱۹۸۹، کریس رید کتابی با عنوان «عناصر برنامه ریزی کاربردی» را نوشت، که تفکیک نگرانی ها را توصیف می کند.برنامه نویس مجبور است در یک زمان چندین کار انجام دهد، یعنی :1- توصیف آنچه که محاسبه می شود.2- سازماندهی ترتیب محاسبات در مراحل کوچکتر.3- سازماندهی مدیریت حافظه ، در زمان محاسبات.تفکیک نگرانی ها در زمینه مدیریت پروژه و توسعه نرم افزار:درحالت ایده آل ، برنامه نویس باید روی مورد اول تمرکز کند بدون آنکه درگیر و نگران دو مورد دیگر باشد یا درگیر کارهای اداری و مدیریتی شود. قطعا مدیریت مهم است ولی با جداسازی آن از وضیفه اصلی ، با فعالیت های مدیریتی خودکار (منظور فعالیت های مدیریتی سیستم عامل و فریم ورک ها و کامپایلرها مثل مدیریت حافظه ، استثناها و … است ) ما میتوانیم به راحتی برای مشکلات برنامه ریزی کنیم و نتایج قابل اعتماد تری دریافت کنیم و خودمان را درگیر این مسایل نکنیم.علی کریمیعلی کریمیWed, 02 Dec 2020 00:11:41 +0330