Frank Borland
begin
احتمالا نام فرانک بورلند برای بعضی از شما که از اعضای قدیمی جامعه ی بورلند ! هستید آشناست اما قطعاً همه ی دوستان جدید با فرانک آشنایی کافی ندارند.
اما Frank Borland کیست؟ از کجا آمده ؟ شغل او چه بوده و چه هست؟ این تاریخچه ی کوتاه (در ادامه ی مطلب) تا حدودی پاسخ این سوالات را دربرخواهد داشت.
begin
Embarcadero از محصول جدیدش Rad Server رونمایی کرد.
این ابزار میتواند جهت تولید سریعتر یک Back-end برای توسعه ی نرم افزار های موجود به شما کمک شایانی بنماید.به این ترتیب میتوانید پلتفرم های جدیدتر (همچون موبایل) که در نظر دارید تا به Application خود بیافزایید را در کوتاه ترین زمان طراحی و آماده نمایید.
Multi tier در حد آب خوردن!
UI توسط Rad Studio طراحی میشود و سرویس هایی(REST/JSON) سمت سرور توسط Rad Server جهت ارتباط با کلاینت ها و همچنین لایه ی ارتباط با دیتابیس طراحی و در یک سرور عادی و یا در سرویس های Cloaud انتشار میابد و در نهایت با حداکثر سرعت کلاینت شما آماده است!
end.
Apply Functional Programming Principles
begin
استفاده ی اصولی از قواعد برنامه نویسی تابعی
تجربه ی جناب مهندس Edward Garson !
Functional Programming این اواخر طرفداران بسیاری پیدا کرده است. این مدل عبارت است از روشی که در آن منطق به کار گرفته شده در برنامه مشابه مبحث منطق در توابع ریاضی در نظر گرفته می شوند. اگر شما درک عمیقی از این مدل داشته باشید و آن را به کار ببرید طراحی های شما دارای یک شفافیت ازجاعی (Referential transparency) خواهد بود و به عبارتی در سطح بالاتری از کیفیت قرار میگیرند.
Referential transparency یک ویژگی بسیار مطلوب است و دلالت بر این دارد که توابع ، به شکل با ثباتی میتوانند در شرایط یکسان (ورودی های یکسان) همیشه به یک شکل کار کنند و خروجی مورد نظر را فراهم نمایند صرفنظر از اینکه از کجا و در چه زمانی Call شوند.استفاده از توابع اجازه میدهد وظایف بزرگ به وظایف کوچک تر تبدیل شوند و Debug کردن به شکل فزاینده ای آسان شود.
از معایب این روش نیز استفاده ی بی رویه از پارامترها در تابع میباشد به شکلی که یک ابَر تابع میسازید که ده ها وظیفه ی مختلف را انجام میدهد و تعداد زیادی پارامتر دارد که با تغییر یکی رفتار برنامه زیر و رو میشود! (ابن مورد یک بدهی فنی محسوب و اصلا توصیه نمیشود!)
end.
begin
Design Pattern چیست و به چه دردی میخورد! سوال همینجاست که آیا واقعاً بدون دانستن الگوهای طراحی شما نمیتوانید یک طراح نرم افزار موفق باشید؟
در پاسخ به این سوال باید گفت که خیر! شاید هم بله... !
واقعیت اینست که تعداد قابل توجهی از نرم افزارهای تولید شده ( حد اقل در ایران) الگوهای طراحی را رعایت نمی نمایند و جزو نرم افزارهای موفق هم شناخته میشوند! اما در پس این جریان تولید و توسعه و نگهداری و حتی پشتیبانی چه خبر بوده است؟ چه مسیری طی شده است و چه مسیری واقعا باید طی میشد؟هرینه های توسعه و نگهداری این سیستم ها چگونه است؟
کسی که ادعا میکند که یک مهندس نرم افزار است باید توانایی طراحی مبتنی بر الگو را داشته باشد. الگوهای طراحی در ارتباط تنگاتنگ با OOP (برنامه نویسی شی گرا)هستند و دربسیاری موارد مشکلات OOP را برطرف مینمایند! بله OOP علارغم اینکه به برنامه نویسی در سال های اخیر جانی دوباره بخشید ناگزیر مشکلات خاص خود را نیز به دنبال داشت.
استفاده صحیح از الگوهای طراحی در زیرساخت برنامه ها ، میتواند سرعت روند توسعه را دوچندان نماید و از به وجود آمدن کدهای موسوم به Code Smells و مشکلی به نام بدهی های فنی جلوگیری نماید. استفاده مجدد از ماژول ها و بخش های مختلف به آسانی صورت میگیرد و در نهایت توسعه به واقع اصولی ، آسان و سریع تر انجام میشود.
در مقابل ، استفاده ی بی رویه و اجباری از الگوهای طراحی نیز در جایی که طراحی ساده شی گرا کفایت میکند توصیه نمیشود.
در ادامه مطلب با انواع الگوهای طراحی آشنا خواهیم شد.
begin
اگر شما از آن دسته از افرادی هستید که هنگام کدنویسی برای حذف صداهای اطرافتان یک هدست همیشه به سر دارید ! ابزار آنلاین Noisli احتمالا برایتان جذاب خواهد بود.
در این سایت شما میتوانید با ترکیب صداهای مختلف ریتم مورد علاقه خود را جهت آرامش و یا انرژی گرفتن ساخته و حتی ذخیره و یا در شبکه های اجتماعی با دوستان خود Share کنید. البته به شرطی که در سایت ثبت نام کنید امکانات اضافی تر را خواهید داشت. مثلا Nosili یک تایمر هم در اختیار شما قرار میدهد به این شکل که زمان های کاری خود را به بازه های کاری 30 دقیقه یی تقسیم‌بندی کرده، و بین آن‌ها آنتراک های مثلا 5 دقیقه یی در نظر گرفته و پس از چند بازه ی کاری، چیزی در حدود نیم ساعت رفع خستگی کنید.
سایت فوق در آدرس www.noisli.com در دسترس میباشد.
end.
begin
چیز یک : تجربه ی جناب Seb Rose
بدهی فنی ...
پیش می‌آید که باید بین «انجام اصولی یک پروژه» و «انجام سریع یک پروژه» یکی را انتخاب کنیم و در ابتدای کار سرعت بخشیدن به فرایند طراحی جذاب‌تر به نظر میرسد با این استدلال که بعداً هم میشود مجدد به کدها سر زد و اگر مشکلی داشت آن ها را از بین برد! اما تجربه نشان داده است زمانی که در بر گیرنده واژه ی بعداً است، خود حاوی بسیاری باگ ها و مشکلات خواهد بود که برنامه نویس مجبور است بیشتر تمرکز خود را روی آن‌ها بگذارد و از توجه به مشکلات -هرچند جزئی- گذشته باز می ماند.
چنین سیاستی در برنامه نویسی اصطلاحاً Technical Debt گفته میشود که به صورت تحت الفظی می‌توان آن را به «بدهی فنی» ترجمه کرد . این بدهی فنی اصلاً چیز خوبی نیست و گاهی اوقات منجر به بوجود آمدن فجایعی در تولید نرم افزار می شود. برای روشن شدن این مسأله مثالی می زنیم. بدهی فنی همچون وام گرفتن است که در کوتاه مدت کار ما را راه می‌اندازد اما غافل از این که در آینده می بایست با بهره ای که روی آن می‌آید -n درصد بیشتر- قرض خود را پرداخت کنیم.
در برنامه نویسی هم قضیه دقیقاً به همین صورت است. اگرچه گاهی اوقات می‌توان از راه کارهایی استفاده کرد که به کدنویسی ما سرعت بخشند اما این در حالی است که در آینده اضافه کردن ویژگی‌های جدیدی به پروژه را دشوار می‌سازد و به اصطلاح نمی‌توان به سادگی کدهای خود را Refactor کرد. جالب اینجا است که هرچه از زمان ایجاد این دست مشکلات بیشتر می گذرد، یافتن راه‌کار هم برای آن‌ها دشوارتر خواهد شد. اما اگر ما از زمان بندی پروژه عقب باشیم و مجبور باشیم سرعت عمل را بر کیفیت ترجیح دهیم چطور؟ توصیه ما این است که هرگز سیاست فدا کردن کیفیت کار به خاطر سرعت بخشیدن به آن را دنبال نکنید اما اگر واقعاً مجبور هستید، پس این کار را انجام دهید و حتماً به خاطر داشته باشید که شما با این کار یک بدهی فنی برای خود ایجاد کرده‌اید که می بایست در اولین فرصت این بدهی خود را صاف کنید. برای این منظور هم، حتماً در مستندات پروژه این قضیه را ذکر کنید تا فراموش نشود که در غیر این صورت ممکن است مجبور شوید بهای گزافی بابت آن بپردازید. (مطلب بعدی: چیز 2!)
end.
begin
مقدمه)
در سال 2010 انتشارات Oreilly کتابی با عنوان
Ninety Seven Things Every Programmer Should Know عرضه نمود.
در کتاب فوق 97 نکته ی کاربردی با توجه به تجربیات برنامه نویسان برتر دنیا (تا آن روز!) ارائه شد.در ادامه و در آینده طی 97 مطلب جداگانه ، تک تک این Best Practice ها را بررسی خواهم نمود. (دانلود کتاب اصلی) برو به مطلب بعدی : چیز1 !
end.
جوئل اسپولسکی، یهودی ساکن آمریکا است که از جمله سوابقش مدیریت پروژه MS Excel v5 است. او نظریات منحصر به فرد و جالبی در زمینه تولید نرم افزار دارد و امروزه در شرکت خودش، Fog Creek Software مشغول به کار است. متن زیر که توسط وی در اوت 2000 منتشر شده است مشخصه های ارزیابی یک تیم نرم افزاری را به زبان ساده و تا حدی طنز گونه بیان میکند. در ترجمه این متن سعی شده است اصطلاحات فنی به صورتی که بین برنامه نویسان حرفه ای در ایران مصطلح است به کار رود.
begin
مفهوم اصطلاح Bad Code Smell چیست ؟
اصطلاح Code Smell که گاهی Bad Smell هم اطلاق میشود در واقع به بخش هایی از سورس کد گفته میشه که پتانسیل این را دارند که مشکلات عمیقی برای سیستم به وجود بیاورند. Code Smell ها ساختارهای خاصی از کد هستند که اصول اساسی طراحی را نقض و تاثیر منفی در کیفیت طراحی میگذارند. این به این معنی است که نفر بعدی که سورس به دستش میرسد هر لحظه ممکن است خودکشی نماید یا سر از تیمارستان در بیاورد...!!!
Code Smell ها بطور معمول باگ نیستند و از لحاظ فنی و دستوری در آن زبان خطا ندارند و جلوی اجرا و کارایی عادی برنامه رو نمیگیرند. در عوض با ضعف عجیبی که در طراحی ایجاد میکنند میتوانند باعث کند شدن سرعت توسعه ، بالا رفتن ریسک ایجاد باگ های منطقی و یا شکست و واماندگی در آینده ای نزدیک شوند.
