نرم نويس
21 members
1 photo
12 links
گاه نوشته هایی از نرم افزار


🔗 https://narmnevis.github.io


👤 @behrooznobakht
Download Telegram
to view and join the conversation
۹۷ مهارت

برداشت اول - شرط احتیاط بدهی فنی

بدهی فنی (Technical Debt) مانند هر وام دیگری است. در کوتاه مدت مفید است اما تا پایان بازپرداخت هزینه دارد. بازپرداخت بدهی فنی هم با زمان رابطه معکوس دارد. با گذشت زمان، نرخ سود بالاتر رفته و هزینه‌ی بیشتری برای بازپراخت صرف می‌شود. بازپرداخت بدهی فنی را در سیستم‌های مدیریت پروژه و محصول خود بگنجانید تا هزینه تحمیلی بر کسب و کار را نمایان کند و دچار زمان نشود. شرط احتیاط، بازپرداخت بدهی فنی در اولین زمان ممکن است.

نگارنده: Seb Rose

@narmnevis
نرم نويس updated group photo
برداشت دوم - اصول برنامه‌نویسی تابعی

اثرات جانبی (Side Effect) به عنوان یکی از دغدغه‌های اصلی خیلی از سیستم‌های نرم‌افزار شناخته می‌شود. این موضوع ناشی از مقادیر تغییر‌پذیر (Mutable State) است که در ساده‌ترین شکل خود به صورت متغیر‌های برنامه‌نویسی در خیلی از زبان‌های برنامه نویسی دستوری (Imperative) وجود دارد.

برای جلوگیری از اثرات جانبی یکی از روش‌های مهم مورد استفاده، تعریف توابع (Function / Method) به شکلی هست که کارکرد و ورودی و خروجی تابع تا جای ممکن تنها بر پارامتر‌هایی باشد که کمترین اثرپذیری از مقادیر تغییر پذیر را دارند. در نتیجه سیستم متشکل از توابعی می‌شود که مستقل از زمان و مقادیر تغییرپذیر سیستم همیشه به شکل نامتناقضی قابل استفاده و استدلال هستند.

استفاده از چنین توابعی به یک سیستم صفت شفافیت ارجاعی (Referential Transparency) اضافه می‌کند؛ این صفت به این معنی است که رفتار سیستم در زمان‌های مختلف با ورودی‌های مختلف قابلیت پیش‌بینی و استدلال بالاتری از خود نشان می‌دهد چرا که توابع به کار رفته در آن همین اصل را رعایت می‌کنند.

مهم‌ترین اصل برنامه‌نویسی تابعی (Functional Programming) مبتنی بر شفافیت ارجاعی هست که تمام قدرت و ویژگی این سبک برنامه‌نویسی بر روی آن مستقر می‌شود. با این که این اصل به این شکل در سبک شی‌گرا (Object-Oriented Programming) تأکید نمی‌شود، به کار گیری آن در هر سبک برنامه‌نویسی به شدت در طراحی بهتر هر سیستمی تأثیرگذار است.

در عمل: توابع کوچک با ورودی‌های مشخص و با کمترین وابستگی به حوزه‌ی عملیاتی تابع بنویسیم. تابع بر اساس ورودی و خروجی خود کار کند و نیازی به مقادیری از بیرون تابع نداشته باشد. در دنیای شی‌گرا این به معنی است که در هر کلاس حداکثر باید دو یا سه تابع باشند که نیاز به وضعیت کلاس (Object/Class State) داشته باشند و بقیه توابع باید از این اصل تبعیت کنند.

@narmnevis
برداشت سوم - پرسش: کاربر چه می‌کند؟

یکی از پیش‌فرض‌های خیلی رایج در بین همه ما این است که دیگران نیز مثل ما فکر می‌کنند. اما این درست نیست. روانشناسان از این رفتار به عنوان تعصب اجتناب‌ناپذیر (False Consensus Bias) یاد می‌کنند. زمانی که دیگران متفاوت از ما فکر می‌کنند، به طور ناخودآگاه ما به آنها برچسب غلط یا نادرست می‌زنیم.

این نوع رفتار در برنامه‌نویسان نیز بسیار رایج است. به طور خاص این تفاوت را در نظر بگیرید که کاربران لزوما نه شناخت و نه آشنایی درستی از ابزار و سیستم‌های کامپیوتری ندارند، پس ‌نمی‌توان از آنها انتظار داشت که در صورت بروز مشکلی، مانند یک برنامه‌نویس با مهارت‌های حل مسأله به دنبال راه حل باشند.

چگونه می‌توان درک کرد که کاربران چه طور فکر می‌کنند؟ با مشاهده و تماشای آنها. این فرآیند باید بدون انقطاع یا راهنمایی باشد و منبع بسیاری دقیقی برای دریافت و درک رفتار کاربر می‌باشد.

زمانی که کاربران دچار مشکل می‌شوند، سعی بر پیدا کردن راه حلی برای خود می‌کنند. این راه حل هر چند هر چه قدر پیچیده باشد، برای آنها باقی می‌ماند. در نتیجه مهم است که برای هر کاری برای کاربر واقعا روشی که بدیهی‌ست ارائه گردد تا راه‌حل‌های جایگزین متعدد.

معمولا فاصله‌ی محسوس بین آن چیزی که کاربر می‌گوید می‌خواهد و آن‌چه که در یک نرم‌افزار در نهایت انجام می‌دهد وجود دارد. در نتیجه باز مشاهده و تماشای کاربر بهترین راه برای درک آن‌چه واقعا می‌خواهند است. مشاهده بهتر از حدس و خطاست.

-- Giles Colborne

@narmnevis
برداشت چهارم — خودکار سازی استاندارد‌های برنامه‌نویسی


برای شما هم اتفاق افتاده است. در ابتدای هر پروژه عزم‌های جدید و خوبی وجود دارد. مواردی از این‌ها به صورت استاندارد‌های برنامه‌نویسی (Coding Standards) جزیی از پروژه می‌شوند. زمانی که پروژه شروع می‌شود، یکی یکی این موارد ترک شده و در نهایت کار کردن با کد پروژه کاری سخت و طاقت‌فرساست.

کجای کار اشتباه شد؟ احتمال خیلی زیاد از همان جلسه شروع پروژه! بعضی به استاندارد‌ها توجه نکردند؛ برخی موافق نبودند به صورت پنهانی مسیر خود را در پیش گرفتند و بعضی هم درک خوبی نداشتند. اما در جایی از پروژه بالاخره به خاطر حجم و فشار بالا، کسانی هم که معتقد بودند مجبور شدند که کوتاه بیایند. این کار‌ها برای انسان خسته‌کننده است و ارزشی برای مشتری ندارد.

استاندارد‌های برنامه‌نویسی باید تا جای ممکن خودکار شوند؛ به صورت مثال قالب‌بندی کد (Code Formatting) یا تشخیص ضد‌الگوهای برنامه‌نویسی (Anti-Patterns) به راحتی قابلیت خودکارسازی دارند.

خودکارسازی استاندارد‌ها باید جزیی از فرآیند ساخت پروژه (Build) باشد. ساخت پروژه نباید اجازه دهد مواردی که استاندارد‌ها رعایت نشده‌اند، موفق باشد. پروژه در طول زمان تغییر می‌کند و این بعد از پروژه نیز باید با نیاز‌های پروژه تغییر کند.

— Filip van Laenen

@narmnevis
برداشت ۵ — ساده زیباست

افلاطون می‌گوید: «زیبایی شیوه و توازن و ظرافت بر اساس سادگی‌ست.»

ما همیشه در تلاش برای برقراری موارد زیر در کد هستیم
- خوانایی (Readability)
- قابلیت نگهداری (Maintainability)
- سرعت گسترش (Speed of Development)
- کیفیت بی‌نظیر در کد (Code Quality)

جمله افلاطون سرلوحه خوبی‌ست؛ همه این‌ها مبتنی بر سادگی کد است.

کد زیبا چیست؟

پاسخ این سؤال بسیار مبتنی بر نظرات شخصی‌ست. همانند تعریف هنر که بسیار مبتنی بر نظرات معرف آنست. در حین حال می‌توان ادعا کرد که در بسیاری از تعاریف هم‌نظری بسیار قوی بر اساس سادگی کد وجود دارد.

نمی‌توان کد زیبایی پیدا کرد که ساده نباشد؛ سادگی در فهم و سادگی در نوشتار کد بسیار اساسی هستند.

چگونه می‌توان کد ساده نوشت؟

سادگی کد بر مبنای دو چیز است: اول سادگی در مسؤولیت و وظیفه‌ای که کد دارد و دوم سادگی در روابط کد با دیگر اجزای سیستم. این دو ویژگی عمیقا در قابلیت نگهداری و خوانایی کد تأثیر دارند که باعث می‌شود کد هم قابل تست باشد و هم به سرعت قابلیت گسترش داشته باشد.

— Jorn Olmheim

@narmnevis
برداشت ۶ — بازبینی و بازنویسی کد (Refactoring)

بازنویسی کد کاری‌ست که برای همه پیش‌ می‌آید که زمان زیادی می‌طلبد و دردسر‌های مختلفی نیز دارد. روش‌های زیر این فرآیند را بهتر می‌کنند:

- بهترین روش تغییر و بهبود ساختار شناخت و درک خوب از کد نوشته شده و مخصوصا‌ تست‌هاست. این موضوع کمک می‌کند تا نقاط ضعف و قوت سیستم فعلی شناخته شده و خود مسیری برای بهبود باز می‌کند.

- همیشه تمایلی برای بازنویسی کامل (Rewrite) هست که باید از آن خودداری شود. استفاده مجدد (Code Reuse) تا جای ممکن باید استفاده شود چرا که قبلا نوشته و تست شده است. تغییر ساختار باید هماهنگ و تأثیر گرفته از رفتار مورد انتظار از سیستم باشد.

- تغییرات کوچک افزایشی متعدد بهتر از یک تغییر بزرگ است. تغییر افزایشی قدرت مدیریت تأثیرات جانبی را بالا می‌برد. تغییر کوچک قابلیت تشخیص بالاتری در تست‌های سیستم دارد.

- هر تغییری باید از تمام تست‌های سیستم با موفقیت بیرون بیاید. حذف تست‌های قبلی سیستم باید با دقت فراوان انجام شده و در صورت نیاز تست‌های جدیدی به سیستم اضافه شود.

- تمایلات شخصی و منیت در این فرآیند جایگاهی ندارد.

- ظهور فناوری‌ جدید دلیل *کافی* برای انجام بازنویسی نیست. در این مورد حتما باید از تحلیل هزینه-سود برای استدلال و توجیه استفاده کرد.

- انسان جایز الخطاست. هر تغییری در آینده دوباره تغییر خواهد کرد و هیچ تغییری کامل نیست.

— Rajith Attapattu

@narmnevis
برداشت ۷ — اخطاری برای اشتراک کد

یکی از انگیزه‌های معمول در کد جدید یا بازنگاری کد، پیدا کردن الگو‌های مشابه و تبدیل آن‌ها به کد مشترک به صورت کتابخانه (Library) می‌باشد. آیا این کار و این تمرین همیشه مفید است؟

نه!

سیستمی را در نظر بگیرید که از اجزای مختلفی تشکیل شده و هر قسمت قابلیت این را دارد که به تنهایی به صورت مستقل به حیات خود ادامه دهد و ویژگی‌های جدید داشته یا رفتارش تغییر کند. در یک فعالیت تغییر سیستم، شما متوجه می‌شوید که در دو زیر‌سیستم چند خطی کد مشابه هم وجود دارد. بر اساس اصل بالا، این کد مشابه را تبدیل به یک کتابخانه کوچک کرده و در هر دو زیر‌سیستم استفاده می‌کنید.

قبل از این کار، هر زیر‌سیستم در سطحی از عدم وابستگی بود که می‌توان رفتار خود را با کد داخل خود تغییر دهد. بعد از این کار، برای بعضی تغییرات ممکن است نیاز باشد که آن مد مشترک تغییر کند که معلوم هم نیست آیا همه زیر‌سیستم‌ها این تغییر را با موفقیت در خود جا می‌دهند.

زمانی که تعداد خط کد نوشته شده در سیستم پایین می‌آید، به ناچار تعداد وابستگی‌های سیستمی (System Dependencies) بالا می‌رود.

زمینه تغییر (Change Context) بسیار مهم است. اگر این زمینه تأثیر در وابستگی‌های زیر‌سیستمی دارد، مراقب تصمیم‌گیری‌های خود در تغییرات بین زیر‌سیستمی باشید.

زمینه را بررسی کنید و بعد تصمیم به ادامه بگیرید.

— Udi Dahan

https://narmnevis.github.io/blog/2018/03/97-things-07.html
#نرم‌افزار #سیستم

@narmnevis
StackOverflow Survey Results 2018

https://insights.stackoverflow.com/survey/2018/
برداشت ۱۱ — به زبان دامنه

ساختمان‌داده‌ها با زبان دامنه (Domain Language) بهتر و ساده‌تر درک می‌شوند.

@narmnevis

https://t.me/iv?url=https%3A%2F%2Fnarmnevis.github.io%2Fblog%2F2018%2F04%2F97-things-11-domain-lang.html&rhash=61b62d38766193
Forwarded from IPM Data Science
مدرسه تابستانی علم داده (مقدماتی)
🔵 پژوهشگاه دانش‌های بنیادی با همکاری مرکز علوم داده آمستردام
🕖 9 تا 14 تیر 1397

📍ثبت نام و اطلاعات بیشتر در سایت
conf.ipm.ir/elementary-school

@IPMDataScience