بی‌شعوری

شاید جای این نوشته در این وبلاگ نباشد ولی مگر نه این که معضلات اجتماعی در محل کار نیز آزار دهنده است؟

تازگی‌ها به طور اتفاقی از طریق یکی از خوانندگان همین وبلاگ کتابی به دستم رسیده است به نام «بی‌شعوری» نوشته خاویر کرمنت ترجمه محمود فرجامی. این کتاب به خاطر لحن تند و بی‌پرده‌اش هرگز موفق به اخذ مجوز از وزارت فرهنگ و ارشاد نشده است ولی در عوض به صورت یک کتاب الکترونیکی منتشر شده و از خیلی از سایت‌های اینترنتی قابل دریافت است.

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

آیا شما هم در شرکت یا تیم‌تان با چنین افرادی برخورد داشته‌اید؟ برنامه‌نویسی که به غلط موفقیت یک پروژه را با حماقتش در کدنویسی، همکاری تیمی افتضاح و انگیزش انفعالی به چالش می‌کشد؟ طراح و تحلیل‌گری که تمام توانش را در تولید یک documentation بی‌ارزش و به درد نخور مصرف می‌کند؟ گرافیستی که همه هنرش فقط کپی ناشیانه و بلامصرفش از جستجوهای ناشیانه‌تر اینترنتی است؟ مدیر پروژه یا مدیر فنی که با نادانی تمام همه اصول ضروری را زیر پا گذاشته و فقط بر اساس تجربیات و حدسیات غلط خودش کار را جلو می‌برد؟ مدیر عاملی که تمام هم و غمش زرنگ‌بازی در امور قراردادها، کاهش مزایا و سو استفاده از حق و حقوق کارمندانش است؟ اگر فکر می‌کنید برخورد نداشته‌اید کمی بیشتر دقت کنید…

پ.ن.: نگاهی هم به این لینک بیندازید.

‫روش برنامه‌نویسی Forum Driven Development

تا حالا به فوروم‌های (انجمن‌های) برنامه‌نویسی ایرانی علی الخصوص «سایت برنامه‌نویس» مراجعه کرده‌اید؟ به سوالات آن هم دقت کرده‌اید؟ تا حالا دیده‌اید که مثلاً شخصی تا حالا یک بار هم Socket Programming کار نکرده و هیچ علاقه‌ای هم به کار کردن با آن ندارد اما چون در یک پروژه به آن نیاز دارد به دنبال یک راهنمایی فقط برای رفع نیاز فعلی‌اش بدون فهم یا استفاده درست از آن راهنمایی است؟ تازه بعد از مدتی اعلام می‌کند که کار پروژه‌اش را با آن تیکه کد یا اسمبلی راه انداخته است؟ تا حالا دقت کرده‌اید که تا یک نفر جواب یک سوال خیلی ساده را می‌دهد چقدر به او استاد استاد گفته می‌شود یا این که تا بحثی در باب بهتر بودن یک روش یا تکنولوژی باب می‌شود چقدر بحث‌های متعصبانه و گاه اشتباه در می‌گیرد؟

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

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

اندر معایب چند شغله بودن

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

یکی از بدترین مشکلات این قضیه این است که نرم افزار و برنامه نویسی همیشه نیاز به مطالعه و به روز بودن دارد. به عبارت دیگر یک شخص نوعی که در شرکت «الف» کار می‌کند مجبور است مقداری از وقت آزادش را هر چند به طور اندک به مطالعه راجع به روش و فناوری‌های مورد استفاده در شرکت «الف» اختصاص دهد. حال اگر این مجبور باشد با شرکت «ب» و شرکت «ج» هم همکاری داشته باشد باید مقداری وقت آزاد هم برای آنها پیدا کند تا بتواند راجع به روش‌ها و فناوری‌های آنها هم کسب اطلاعات کند. به این ترتیب تمام وقت شبانه‌روز، به جز ۶-۷ ساعت خواب شبانه، مصروف کار گردیده و اینجاست که هم صدای اهل خانواده در می‌آید و هم فرد مورد نظر دچار مشکلات متعدد ناشی از کار زیاد می‌گردد.

تسلیم می‌شویم

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

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

۱- قبل از صدور دستور commit، فایل‌های تغییر یافته‌شان را save کنند،

۲- حذف و اضافه فایل به پروژه در ویژوال استودیو نیاز به Save all یا اقلاً یک Rebuild Solution دارد،

۳- اگر دو نفر یک جای یکسان از یک فایل واحد را تغییر دهند، merge conflictی به وجود می‌آید که خود git نمی‌تواند آن را به طور خودکار resolve (حل) کند. و این از منطق کار تیمی و منطق فکری نشات می‌گیرد و جز نقایص git یا هر سورس کنترل دیگری نیست،

۴- ساختار پروژه در ویژوال استودیو خودش در یک فایل خاص با پسوند csproj نگهداری می‌شود پس به وجود آمدن merge conflict در آنجا هم امکان‌پذیر است،

۵- برای پیشگیری از merge conflict اول هر روز کاری یا حتی دو سه بار در روز، قبل از شروع کار باید اول تغییرات دیگران را دریافت کرد،

۶- نگهداری فایل یک کلاس یا winform با بیش از ۱۵۰۰ خط کار درستی در یک محیط تیمی و تحت سورس کنترل نیست،

۷- …

تنها فرق حالت اول و دوم این است در که در حالت اول خود ویژوال استودیو همه کارها را انجام می‌دهد. مثلاً قبلاً از check-in شما را مجبور می‌کند که همه فایل‌ها را save کنید. بنابراین کسی مجبور نیست از معدن گچش استفاده کرده و حواسش به save فایل‌ها قبل از ارسال به سرور باشد.

این است که دست‌هایمان را به نشانه تسلیم بالا برده و اجازه می‌دهیم دوستان به جای استفاده از git، سورس مشترکشان را روزی ده بار از طریق usb flash با هم به اشتراک بگذارند و خودشان نقش سورس کنترل را بازی کنند.

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

.
.
.
.

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

An open letter to oDesk from an Iranian software developer

Dear oDesk managers,

I’m an Iranian software developer living and working in Tehran/Iran. Recently I opened an account in oDesk and started to bid on oDesk projects as a contractor. But unfortunately oDesk has suspended my account just because I’m an Iranian.

I can’t realize why I can’t work in oDesk like many other people all around the world including Pakistan, Latin America, Egypt, Ukraine, India, etc? What is difference between them and us? I know about Iran Sanctions Act (ISA), but we, the people of Iran not the government, do not deserve it. In Iran, a very few software developers work directly for government or government organizations. While American and Iranian politicians hate each other, why we, the people of Iran must be sacrificed? Why we must pay for it?

Please watch software developers of Iran more carefully, we don’t program for nuclear weapons, mass destruction weapons or anything else dangerous for people of world. Main stream of software development in Iran is LOB applications deployed in boring offices manipulating personal data, banking data, accounting data and any none military data. Why you are think these poor and peaceful software developers are dangerous to other people?

I beg you think twice…

Best Regards,
A peaceful Iranian software developer,
Afshar Mohebbi

جایگزینی اصول مهندسی نرم‌افزار با ابداعات و روش‌های نادرست و رنج حاصله

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

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

به عنوان مثال آنها مثل من و مدیران من نگران تغییرات در نرم‌افزار نیستند. چون از چیزی به اسم unit test استفاده کرده و این unit testها را هم به نحوی به ابزار buildی مثل TeamCity یا TFS معرفی کرده‌اند. هر وقت که check-inی در سورس کنترل برنامه اتفاق بیفتد، نتیجه تغییر حاصله در تمام unit testها بررسی شده و درست بودن یا نبودن تغییر بلافاصله مشخص می‌شود. حال من برنامه‌نویس ایرانی از همه جا بی‌خبر هم می‌خواهم مثل اونها در برنامه‌ام تغییر ایجاد کنم بدون داشتن این همه ترس. اما نمی‌توانم. چون آن‌ها ساختار و روش‌شان را برای استفاده از unit test آماده کرده‌اند. مثلاً بدنه متودها را کوچک نگه داشته‌اند، اصل Separation of Concern را رعایت کرده‌اند، در صورت لزوم از Mocking استفاده کرده‌اند و غیره و غیره. از این دست مثال‌ها زیاد می‌توان پیدا کرد.

این روزها این رنج را بیش از بیش احساس می‌کنم. اما نمی‌دانم با آن چه کنم. آیا چاره کار Freelance شدن است؟ آیا چاره کار عوض کردن شغل است؟ آیا چاره کار همکاری با پروژه‌های Open Source و در نیاوردن پول است؟ آیا چاره کار مهاجرت است؟ آیا چاره کار تاسیس شرکت شخصی و قبول همه مصائب شرکت‌داری است و پروژه گرفتن است؟ آیا …؟

خلاقیت کور

یکی از مشکلاتی که همیشه به عنوان یک مهندس نرم‌افزار در شرکت‌های مختلف داشته‌ام مبارزه با خلاقیت کور، خلاقیت افسار گسیخته یا خلاقیت بی‌پایه بوده است. امروز بعد از بحثی که در رابطه با «رفتار بر اساس اصول در برابر خلاقیت‌گرایی» در شرکت داشتیم به ذهنم رسید که کمی بیشتر راجع به آن فکر کنم:

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

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
..
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

.
.

تولید نرم‌افزار یا تحقیق و توسعه؟

خیلی وقت‌ها (نه بعضی وقت‌ها) حس می‌کنم کارم به عنوان یک مهندس نرم‌افزار به جای تولید نرم‌افزار (software development) تبدیل شده به تحقیق و توسعه (R and D). البته فکر می‌کنم این فقط مشکل من نباشد. فقط کافی است به بعضی شرکت‌ها سر زده و نگاهی به مانیتور افراد بیندازید. خیلی‌ها را پیدا می‌کنید که از صبح تا شب یا در حال PDF خوانی هستند یا همیشه در حال کار روی پروژه‌های تستی و آزمایشی هستند.

تحقیق و توسعه (R and D) لزوماً چیز بدی نیست. اما اولاً که برنامه‌نویس‌ها معمولاً برای درست برنامه‌نویسی آموزش دیده‌اند نه R and D و ثانیاً این که تاکید زیاد به R and D می‌تواند نشانه‌ای از آموزش غلط برنامه‌نویسان یا کم سوادی تصمیم‌گیرندگان شرکت باشد.

آیا نرم‌افزار تجارت کثیفی است؟

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

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

این طور مسائل هم باعث می‌شود سازمان‌ها و افراد دید چندان مثبتی نسبت به کار نرم‌افزار نداشته باشند و هم باعث می‌شود رقابت در بین شرکت‌های نرم‌افزاری کمی کثیف شود.

از این شرکت به اون شرکت

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

در بعضی شرکت‌ها رفت و آمد پروژه و پول خیلی خوب است اما تیم فنی خیلی ضعیف است. در بعضی شرکت‌ها تیم فنی خیلی خوب کار می‌کند اما مدیریت شرکت ضعیف است. در بعضی شرکت‌ها انضباط (Disipline) بسیار خوبی حاکم است اما بعضی تصمیم گیری‌های تکنولوژیک کار را به بیراهه می‌کشاند. در بعضی شرکت‌ها پول، نیروی انسانی خوب و شهرت کافی وجود دارد اما بی‌نظمی کار را خراب می‌کند. در بعضی شرکت‌ها…

واقعاً چرا؟