خانه

برنامه نویسی

باورهای اشتباهی که بسیاری از برنامه نویسان دارند!

28 May 2010

خیلی از برنامه‏نویسها باورهای اشتباهی دارند که سبب می‏شود در کارشان پسرفت داشته باشند یا پیشرفت قابل توجهی نکنند. من بر اساس تجارب خودم، برخی از این باورهای اشتباه را فهرست کرده‏ام.

البته باید توجه داشت که برخی از این باورها، الزاما هم ربطی به برنامه‏نویسها ندارد و شاید درباره خیلی‏ها دیگر هم درست باشد. (برای نمونه همین مورد اول)

اصرار بر باور خودمان

این که اصرار داشته باشیم حتما باور ما درست است، سبب می‏شود که سخن بقیه را نشنویم؛ حتی اگر تظاهر به شنیدن آنها بکنیم.

همیشه باید این شک را داشت که شاید راه حل ما یا شیوه تفکر ما نسبت به یک مسئله درست نباشد؛ تا بتوان سخن بقیه را شنید، درک کرد و آن را بی طرفانه سنجید.

مشتری هیچ وقت نمی‏داند که چه می‏خواهد

اگر حتی شش ماه در زمینه برنامه‏نویسی کار کرده باشید، به احتمال زیاد این سخن را بارها و بارها از دوستان، همکاران و یا رئیستان شنیده باشید. در حالی که به نظر من، این مسئله همیشه درست نیست. بعضی وقتها (اگر نگویم خیلی وقتها) مشتری دقیقا می‏داند که چه می‏خواهد. اگر چه شاید بتوان بهبودهایی را به او پیشنهاد کرد.

دلیل این که کد یک نفر را نمی‏توان خواند، درست کد ننوشتن او است

همیشه خواندن کد دشوار است. حتی خواندن بهترین و تمیزترین کدهای نوشته شده به دست بهترین برنامه‏نویسان دنیا. من سه دسته مشخص کد را به شخصه زیر و رو کردم: کدهای Net Framework، کدهای VCL (کتابخانه کنترلهای دیداری دلفی) و کدهای CentOS (یک نگارش مشهور لینوکس که خیلی شبیه به Redhat درست شده ولی رایگان است). همه کدها به شدت تمیز و ساختار مند نوشته شده‏اند ولی با این حال خواندن آنها دشوار بوده و نیاز به تمرکز دارد.

بنابراین این قدر سخت‏گیر نباشید و از کد بقیه ایراد نگیرید. کد فعلی خود شما هم اگر توسط یک برنامه نویس حرفه‏ای‏تر بازبینی شود، شاید کاملا غیر بهینه و زشت به نظر بیاید و او بتواند کد شما را خیلی بهتر و تمیزتر بنویسد. توجه داشته باشید که همه کدها (به نسبت کد بهتر) کثیف هستند. مطمئنا حتی کدهای کتابخانه‏های بالا را که مثال زدم هم می‏شود بهبود داد. همه چیز نسبی است.

برنامه‏نویسی مهمترین و بزرگترین بخش یک پروژه است

این باور کاملا نادرست است. من شخصا از داشتن چنین باوری، بسیار ضرر کردم. حداقل تحلیل و طراحی یک سیستم بخشهای بسیار مهمی هستند که در کنار برنامه‏نویسی قرار می‏گیرند.

تازه همه اینها، بخش فنی کار هستند. مسائلی مانند بازاریابی، جذب مشتری، ارائه درست محصول، کارهای حقوقی (ثبت شرکت، نوشتن قراردادها)، مدیریت درست، طراحی استراتژی درست برای فروش، کارهای خدماتی (نظافت محل کار، فراهم کردن فضای مناسب کاری و ...)، بسته‏بندی درست، طراحی گرافیکی، طراحی وبسایت برای عرضه محصول، تبلیغات درست، تعیین درست بازار هدف، استخدام نیروهای درست برای بخشهای پروژه، زمان‏بندی درست و خیلی کارهای دیگری تعیین کننده هستند.

شما اگر بهترین برنامه‏نویس هم باشید، این را باید بدانید که کار شما تنها 20% (و تازه شاید خیلی هم کمتر) از کل کارهای یک پروژه است. برای راه انداختن یک شرکت نیاز به همه عواملی هست که بر شمردم. داشتن برنامه نویس خوب مثل همان جک مشهور است که فردی یک دکمه برده بود خیاطی و از خیاط می‏خواست که یک کت خوب برای این دکمه بدوزد.

حتما قبلا کسی این کار را کرده است

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

اگر چه کلا حرف درستی است ولی خیلی از مواقع هم سبب عقب راندن شما می‏شود. شما به خیال این که، کدی که می‏خواهید بنویسید قبلا نوشته شده است، کلی در اینترنت می‏گردید و در نهایت چیزی پیدا نمی‏کنید. به نظر من همیشه، همه چیزها را قبلا نوشته نشده است.

هر چه یک کد طولانی‏تر باشد، احتمالا حرفه‏ای تر است

این دیگه از آن باورهای کاملا نادرست است. بر اساس قانون KISS یا «نادون هر چه ساده‏تر بهتر»، روش ساده‏تر برای انجام یک کار، درست‏ترین روش است. تا به حال بسیار پیش آمده که کدی که دو روز سر آن وقت گذاشته‏ام را مرور کردم (که مثلا شده است 1000 خط) و دیده‏ام که چقدر همه چیز را پیچیده کرده‏ام. همه چیز را پاک کرده‏ام و دوباره خیلی بهتر و موثرتر و کم‏باگ تر آن را با 50 خط نوشته‏ام.
این را باید همیشه به خاطر داشت که می‏شود کد را ساده‏تر و بهتر نوشت. این طوری باگها هم کمتر می‏شوند و خطایابی هم آسان‏تر خواهد بود.

برنامه‏نویسی خیلی کار با حال و خفنی است

برنامه‏نویسی جذابیتهای خیلی زیادی دارد. ولی از سوی دیگر مانند همه کارها است. دقیقا مانند همه کارهای دیگر دنیا. آن چنان که فکر هم می‏کنید این کار با حال و خفن نیست.

برنامه‏نویسی پیچیده‏ترین کار دنیا است

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

اینها چیزهایی بود که به ذهن من می‏رسید.

ابزارهای طراحی اینترفیس

21 May 2010

فرهنگ Document کردن کامل یک پروژه پیش از آغاز فاز پیاده‏سازی معمولا کمتر در ایران جا افتاده است. درباره پروژه‏های کوچک تقریبا در ابتدا هیچ مستندی با استفاده هیچ روش مدل‏سازی (مانند SSADM یا روشهای جدیدتر مانند UML) نوشته نمی‏شود. برنامه‏نویس می‏نشیند پای ابزار Development خود و همین طور عشق و الله بختکی اینترفیس برنامه را طراحی می‏کند. بعد ابزار Database خود را باز می‏کنند و Tableهای مربوط به اینترفیسی که روی آن کار می‏کند را درست می‏کند.

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

در این نوشته می‏خواهم چند ابزار طراحی Wireframe یا اینترفیس را معرفی کنم. کاربرد Wireframe این است که اینترفیس یک سایت یا یک برنامه بدون این که وارد زرق و برق‏های گرافیکی شویم، قابل طراحی است. در واقع در این برنامه Layout یک اینترفیس که مهمترین بخش آن نیز هست قابل طراحی است.

MockFlow


MockFlow امکانات کاملی را در اختیار شما قرار می‏دهد. همچون چون با Adobe Flex نوشته شده است، امکان استفاده به صورت Offline با Adobe AIR وجود دارد.

Axure


برنامه خوبی است اگر چه خیلی چشم من را نگرفت. این برنامه افزون بر طراحی Wireframe کارهای دیگری مانند طراحی دیاگرام نیز انجام می‏دهد. به همین خاطر نسبتا برنامه بزرگتری است.

Balsamiq Mockups


این برنامه 75 کنترل در اختیار شما قرار می‏دهد و به همین خاطر تقریبا امکان طراحی هر چیزی با آن هست. این برنامه نیز با Flex طراحی شده و نسخه آنلاین آن رایگان است. ولی برای نسخه Desktop باید پول پرداخت کنید. اگر چه، من دنبال یک ابزار رایگان هستم.

Pencil Project


این یکی واقعا محشر است. Pencil در واقع افزونه Photoshop است و از قابلیتها Canvas جدید در HTML 5 استفاده می‏کند. بسیار سریع، راحت و با امکانات بسیار بالایی است و در مرورگر محبوب شما یعنی Firefox کار می‏کند. نیاز به برنامه جداگانه‏ای نیست.

HotGloo


HotGloo هم کاملا تحت وب است و برنامه قدرتمند و زیبایی است ولی متاسفانه رایگان نیست.

Mockingbird


این برنامه تمرکز زیادی روی Collaboration یا کار تیمی دارد. به شما اجازه می‏‎دهد که با هم تیمی‏های خودتان روی طراحی یک اینترفیس کار کنید، برای هم دیدگاهایتان را بنویسید و آن را تغییر دهید. تمام برنامه با JavaScript نوشته شده است و هیچ خبری از Flash نیست.

Cacoo


این ابزار افزون بر Wireframe، امکان ساخت دیاگرام، UML و چارتهای شبکه را هم به شما می‏دهد.

ProtoShare


این برنامه هم امکانات کار گروهی خوبی را در اختیار شما قرار می‏دهد. از جمله امکان نوشتن دیدگاه بر هر یک از عناصر موجود در Wireframe وجود دارد.

iPlotz


این برنامه با سرعت زیاد امکان ساخت Wireframe را در اختیار شما قرار می‏دهد.

OmniGraffle


این برنامه برای Max OS طراحی شده و فکر می‏کنم به درد کمتر کاربری در ایران بخورد.

مزایای طراحی Wireframe

اگر همه اینترفیسها را در ابتدا طراحی کنیم مزایای زیر را به دست خواهیم آورد:
1- همه اینترفیس‏ها با هم هماهنگ خواهند بود.
2- امکان افزایش Usability اینترفیسها با حذف و یا ادغام و تغییر نحوه عملکرد اینترفیس به سادگی وجود دارد.
3- زمان طراحی Wireframe بسیار کمتر از طراحی اینترفیس در نرم‏افزارهای توسعه است. به این ترتیب پیش از پیاده‏سازی می‏توان Wireframeها را به پیمانکار یا رئیس نشان داد و از او تایید گرفت.

آنگاه که پشته‏ها، سر ریز می‏شوند

30 October 2009

آنگاه که پشته‏ها، سر ریز می‏شوند، برنامه‏نویس‏ها قاطی می‏کنند و کم می‏آورند و به سراغ سایت Stack Overflow می‏روند.
سر و کله سایت Stack Overflow یک سال پیش پیدا شد و خیلی از برنامه‏نویسان را که برای پرسیدن پرسشهای برنامه‏نویسی به سایت Experts Exchange می‏رفتند به سمت خود کشاند.
مهمترین تفاوت سایت Stack Overflow با سایت Experts Exchange مدل تجاری متفاوت این دو سایت است. برای پرسیدن سوال در سایت Experts Exchange باید Point داشت و برای Point داشتن باید پول پرداخت کرد یا به سوال دیگران پاسخ داد ولی مدل کاری سایت Stack Overflow کاملا متفاوت است. برای پرسیدن سوال به Point نیازی نیست و طبیعتا نیازی به پرداخت پول هم نمی‏باشد.

افزون بر این کل سایت Stack Overflow را به شکل یک Wiki فرض کنید. پاسخهای شما به دیگران و حتی سوال شما هم قابل ویرایش هستند.

30 برنامه‏نویس تاثیرگذار

8 October 2009

وبلاگ WebDesignDev نوشته‏ای با نام 30 برنامه‏نویس تاثیرگذار نوشته است و در آن فهرستی از افراد مهم در برنامه‏نویسی را گرد آورده.

افرادی مثل تیم برنرز-لی (طراح وب)، مت مولنوگ (برنامه‏نویس WordPress)، لری پیج و سرجی برین (موسسان گوگل)، لوئیس تروالدز (طراح لینوکس)، دنیس ریچی (آفریننده C)، راسموس لردوف (طراح PHP) و گیدو وَن راسوم (طراح Python) دیده می‏شود.

البته همان طور که افراد زیادی در دیدگاههای این نوشته آورده‏اند، فهرستی که این وبلاگ گردآوری کرده است، اشکالات زیادی دارد. برای نمونه افرادی در آن گنجانده شده‏اند. برای نمونه ظاهرا کسی مثل خانم کثی سیرا تنها برای این منظور در این فهرست آمده است که حداقل یک زن در این فهرست باشد؛ و اگر نه ایشان تنها یک نویسنده کتابهای برنامه‏نویسی است و خیلی سخت می‏شود باور کرد که ایشان یکی از افراد تاثیرگذار در دنیای برنامه‏نویسی باشند؛ یا دست کم نمی‏توان وی را در کنار افرادی مثل لوئیس تروالدز یا فردی مانند راسموس لردوف جای داد.

یا فردی مانند کرگ نیومارک تنها یک پایگاه معمولی که کاری شبیه به کار حراجی‏ها را انجام می‏دهد راه انداخته است. ظاهرا نویسنده نوشته با حضرتشان آبگوشت خورده‏اند که اسم ایشان را در این فهرست آورده‏اند. (-:

اشکال دیگری که در فهرست‏بندی این سایت دیده می‏شود این است که برخی از افرادی که در فهرست هستند اصولا برنامه‏نویسان خوب یا مهم نیستند؛ اگر چه شاید از دیدگاه نویسنده به نظر تاثیرگذار بیایند.

از سوی دیگر اسم افرادی همچون بیل گیتز در این فهرست خالی است. بیل گیتز خالق زبان برنامه‏نویسی Basic (البته منظور Basic مایکروسافت است و اگر نه شرکتهای دیگر هم Basic درست کرده‏اند) است و همه می‏دانند که Basic مایکروسافت یک پدیده و رخداد مهم و تاثیرگذار در دنیای برنامه‏نویسی است.

ولی در هر حال فهرستی که این وبلاگ گردآوری کرده است، برای آشنایی با نام برخی از برنامه‏نویسان و خواندن زندگی مختصری از آنها سودمند است.

گفتنی است که نویسنده وبلاگ، نوشته دیگری با نام 30 فرد تاثیرگذار در طراحی وب نیز نوشته است.

Thread-Safe نبودن عملگر ++ در دات نت

13 February 2009

من نمی‏دانستم که عمگر ++ در دات نت Thread-Safe نیست. اینجا توضیحات کاملی آمده است.

چگونه می‏توان تصاویر رنگی را به طیف خاکستری تبدیل کرد؟

6 February 2009

چند روز پیش در نوشته پیدایش فوتوشاپ نوشتم که توماس پس از خرید کامپیوتر مکنتاش خودش از این که نمی‏تواند تصاویر رنگی را به تصاویر طیف خاکستری تبدیل کند، ناراحت بود و خودش برنامه کوچکی را برای تبدیل تصاویر رنگی به تصاویر طیف خاکستری نوشت.

خوب راستش تابع تبدیل تصاویر رنگی به طیف خاکستری خیلی ساده‏تر از آن چیزی است که به نظر می‏آید. من در این نوشته این تابع را آورده‏ام و درباره آن توضیحاتی هم می‏دهم. اما پیش از این باید توضیحی درباره تصاویر Black and White و تصاویر Grayscale بدهم. تصاویر Black and White یعنی تصاویری که تنها و تنها در ساخت آنها از دو رنگ سیاه و سفید استفاده شده است. اما تصاویر Grayscale تصاویری هستند که رنگهای آن از طیف خاکستری تشکیل شده است. بدبختانه ما در فارسی برای هر دو نوع تصاویر واژه «سیاه و سفید» را به کار می‏گیریم.
به هر روی من در این نوشته تابع تبدیل تصاویر رنگی به تصاویر طیف خاکستری یا Grayscale در C را آورده‏ام:

for(i=0;iw-1;i++){
for(j=0;jh-1;j++){

color=getpixel(temp,i,j);
r=getr32(color);
g=getg32(color);
b=getb32(color);

h=(r+b+g)/3;
putpixel(temp1,i,j,makecol(h,h,h));
}
}

در این تابع با کمک دو حلقه تو در تور تمامی پیکسلها ستون به ستون و سپس پیکسل به پیکسل پیمایش شده است. تابع getpixel رنگ پیکسل فعلی را می‏خواند و سپس رنگ استخراج شده به کمک تابع getr32 و getg32 و getb32 به سه رنگ قرمز، سبز و آبی تجزیه می‏شود. این توابع روی تصاویر 32 بیتی (تصاویری که هر رنگ در 32 بیت نوشته شده است و بنابراین در این تصاویر می‏توان 4,294,967,296 رنگ را به کار گرفت) کار می‏کنند. تابعهای مشابهی برای کار کردن با تصاویر 24، 16، 15، 8، 7، 4 و 2 بیتی هم وجود دارد. بنابراین در این تابع فرض بر این گذاشته شده است که تصویر ورودی 32 بیت است. پس از این Hue رنگ با کمک فرمول ساده r+b+g/3 استخراج شده است. درباره Hue که یکی از ویژگی‏های فضای رنگی HSV یا HSL است اینجا بخوانید.
سپس با به کار گیری تابع MakeCol یک رنگ جدید ساخته شده است و با کمک تابع PutPixel رنگ جدید در تصویر اولیه گنجانده شده است.

مهمترین نکته‏ای که در این کد وجود دارد، روش تبدیل پیکسل رنگی به برابر طیف خاکستری آن است. نخست باید بدانیم که تمامی رنگهای Grayscale دارای مقادیر یکسان RGB هستند. یا به عبارت دیگر هر رنگی که دارای مقادیر یکسان R و G و B باشد یک رنگ Grayscale است. روش به کار رفته در این کد هم بر پایه همین اصل است.

مقادیر RGB تمام رنگهای Grayscale یکسان هستندمقادیر RGB تمام رنگهای Grayscale یکسان هستند

ابتدا مقدار Hue که مهمترین مولفه تشکیل دهنده یک رنگ در فضای رنگی HSV یا HSL است استخراج شده است و رنگی تشکیل شده است که مقدار R و G و B در آن برابر با مقدار Hue استخراج شده است.

Syndicate content