زمانی که دانشجو بودم، که بر می‌گرده به سال ۸۲ تا ۸۷!، آن موقع‌ها پدیده‌ای به نام «برنامه‌نویسی وب» امروزی وجود نداشت. نوکیا ۶۶۰۰ آیفون امروزی بود و بازار داغ «داداش بلوتوث جدید چی اومده؟» بین دانشجویان و هم پالکی‌های ما برقرار بود. خبری از کانال‌های تلگرامی نبود و جریان اطلاعات با این حجم وجود خارجی نداشت. مزیت اینترنت ADSL به اینترنت دیال آپ این بود که خط تلفن اشغال نمی‌شد! مبتدی‌های مثل من، دنبال ابزارهای آماده‌ای بودند که کارشان را سریع‌تر راه بیاندازد (یادم می‌آید به انواع مختلف Visual PHP IDE را سرچ می‌کردم.)
توسعه جنگایی (Jenga Driven Development)
هر چه بیشتر آموختم، متوجه شدم که بنداز و بفروش (Drag and Sell) در برنامه‌نویسی، کار من را راه نمی‌اندازد. مدلی که برنامه نویسی می‌کردم، شبیه به بازی جنگا بود، پروژه هرچقدر طولانی‌تر می‌شد، تمام کردنش سخت‌تر می‌شد. به نظرم می‌رسید این مدل کار نمی‌کند، اما راه‌حلی برایش نداشتم. به خصوص که فاکتورهایی که باید رعایت می‌کردم، روز به روز بیشتر و بیشتر می‌شد. آنقدر این جمله‌ها را شنیده و گفته بودم، دیگر خسته‌کننده بود:
آن موقع‌ها، شرکت کوچکی داشتم و تلاش می‌کردم مشتری‌ها را راضی نگه دارم. غافل از اینکه طولانی شدن پروژه‌ها و نرسیدن به ددلاین‌ها، خالی بودن و کم بودن ظرف تجربه‌ام و کم توانی در نگه‌داری پروژه‌های قدیمی‌تر (به دلیل نداشتن برنامه صحیح برای به‌روز نگه‌داشتن آنها) باعث شد فعالیتش را متوقف کنم. دنیای فریلنسینگ هم به آن سادگی‌ها که می‌گفتند نبود و اعتمادبنفس اندک من را افزایش نمی‌داد. نتیجه آن شد که بخش اندکی از پروژه‌هایی که در طول ۶ سال اول دهه ۲۰ سالگی‌ام انجام دادم را می‌توانستم به فرد دیگری بگویم و حیثیتم نرود. نیاز به پویشی داشتم که شخصیت حرفه‌ای‌ام را در قدم اول بازسازی و بعد بهبود دهد.
تعصب زیادی روی php داشتم، یادم می‌آید ساعات بیشماری را با دوستانم به بحث تعصبی می‌پرداختیم بر سر اینکه php بهتر است یا Java یا ASP (که آن موقع‌ها زنده بود.) آن موقع‌ها فکر می‌کردم استفاده از تکنولوژی بهتر، به صورت جادووار و خودکار من را برنامه‌نویس بهتری می‌کند.
در همان زمان بود که متوجه شدم مفاهیم دیگر زندگی بیرون مانیتور، نه‌تنها می‌تواند روی زندگی حرفه‌ای من تاثیر بگذارد، بلکه منبع بسیار فوق‌العاده‌ای برای یادگیری است. مدل کوبلر راس برای من شباهت خیلی زیادی به مدل قبول تغییر پیدا کرد. دانستن اینکه عقل و عواطف ما می‌تواند فرموله شود، نگاه گسترده‌تری به من داد تا با تغییرات جدید در حوزه برنامه‌نویسی مهربان‌تر باشم. پتریک وینستون، در کلاسی که در MIT برگزار کرده، می‌گوید مراحل کسب مهارت در یک حوزه، می‌تواند بسیار ساده‌تر از آن چیزی باشد که می‌پنداریم:
در مواجهه با پدیده‌ی ناشناخته، شاید نخستین گام، یافتن نامی برای آن باشد. وقتی بتوانیم چیزی را صدا کنیم، یعنی دانشی بر آن داریم، و اگر این دانش را گسترش دهیم، بر آن پدیده تسلط خواهیم داشت.
-- پتریک وینستون
البته این نقل قول بالا را شاید دامبلدور به شیوه‌ی دیگری گفته باشد:
“Sir?” said Harry. “I’ve been thinking… sir — even if the Stone’s gone, Vol-, I mean, YouKnow-Who —”
“Call him Voldemort, Harry. Always use the proper name for things. Fear of a name increases fear of the thing itself.”
-- Philosopher's Stone, Chapter 17 - The Man With Two Faces
مسیر پرتلاطم خودسازی
با ورود کامپوزر، تازه فهمیدم که چطور می‌توان پکیج‌های دیگر را به شیوه درست نصب کرد. یادم می‌آید آن موقع‌ها از CMSای بر مبنای CakePHP استفاده می‌کردم به نام Croogo که در داکیومنتیشن آن، برای کسانی که نمی‌دانستند کامپوزر چیست، توضیح داده بود پکیج‌ها را بدون کامپوزر چطور نصب کنند! بعدتر و تا زمان لاراول ۴.۲، این فریم‌ورک را نمی‌شناختم، و اولین پروژه لاراول ۴.۲ ام را با کلی زحمت تمام کردم. بر خلاف Cake، لاراول ابدا هیچ عقیده‌ای را تحمیل نمی‌کرد (دست کم در نگاه اول) اوضاع گیج کننده بود. بیرون آمدن از معماری MVC (هر چند که می‌شد MVC هم کار کرد) تبدیل شده بود به اتاقی تاریک بدون دیوار. به لطف لاراکستس جفری وی موفق شدم مفاهیم اصلی را درک کنم. همین جفری وی، توی لاراکان اروپای ۲۰۱۵ ارائه‌ی فوق‌العاده‌ای داد و چراغ را برای من روشن کرد.
هزینه‌ی درست کار کردن
تا عرضه‌ی لاراول ۵ و ۵.۱، میزان مصرف‌کردن کدهای بقیه‌ام آنقدر زیاد بود که شاید می‌شد گفت، برای تولید یه اپلیکیشن و گرفتن پول، خودم ۵ درصد کد رو می‌نوشتم و باقی درآمدم، از ۹۵٪ کدهای آماده شکل گرفته بود. حرف حقیر را اشتباه برداشت نکنید، در دهه‌ی دوم قرن بیست و یکم، احتمالا جور دیگری نمی‌شود کار کرد. اما آن موقع‌ها بود که تصمیم گرفتم اولین کانتریبیوشن را به دنیای اوپن سورس بکنم. و نتیجه، فاجعه بار بود:
توی این مرج ریکوئست، تلاش کردم زبان فارسی را به لایبرری فوق‌العاده‌ی Carbon اضافه کنم. که طبعا رد شد، چرا؟ برای اینکه دانشم در git ناکافی بود و متوجه شدم برای فعالیت در حوزه‌ی Open Source، دقت بسیار بیشتری نیازه. (کامنت پاسخ مرج‌ریکوئست را بخوانید!) بماند که همان موقع مرج‌ریکوئست دیگری برای زبان فارسی عرضه شد و آن موقع هم بلد نبودم کامیت‌هایم را Squash کنم و در نتیجه، مرج‌ریکوئست اول، با آبرو ریزی تمام بسته شد. :)
دومین مرج‌ریکوئست من، برای پکیج laravel-translatable بود. برای پروژه‌هامان از این پکیج استفاده می‌کردیم تا از همان اول، تمام Eloquent Modelهامون، چند زبانه باشد تا بعدا دردسر چند زبانه کردن را نداشته باشیم. موقعی که به خطا خوردم و آن هم این بود که می‌خواستم Price را چند زبانه کنم (که مثلا برای ایرانی‌ها عددها به ریال باشد، و برای زبان انگلیسی به دلار). دیگر اعتقادم به جادو را کامل از دست داده بودم. ساعت‌ها وقت گذاشتم تا متوجه و مطمئن شوم که ایراد از کدی که من دارم نیست و از پکیجی است که مصرف می‌کردم. آنجا بود که متوجه شدم می‌توانم ایراد پکیج را رفع کنم. برای این مرج‌ریکوئست، هر چه در طول سال گذشته می‌دانستم به کار گرفتم، تا دست کم آبرو ریزی نشود. هر چند ۳ کامیت بعد از این کامیت طول کشید تا استایل کد را تصحیح کنم. ولی مرج ریکوئست موفقیت آمیزی بود.
سومین مرج ریکوئستم را با موفقیت بیشتری انجام دادم، در اینجا بود که متوجه شدم نمی‌توان برای رفع مشکلاتم و درخواست‌هایم، به دنبال پکیج‌های آماده بگردم. این درک را پیدا کردم که خیلی وقت‌ها چیزهایی که دوست داریم به کودک درونمان کادو بدهیم، حاضر و آماده نیست.
در طول این سال‌ها، متوجه شده‌ام که بهترین تجربیاتم، ارتباطی به تکنولوژی ندارند. فهمیدن اینکه کجای کد، چرا، و به چه دلیل کار نمی‌کند، بعد از نام‌گذاری صحیح، یکی از سخت‌ترین بخش‌های دیباگ اپلیکیشن است. یادم می‌آید که قدیم‌ترها که یک کدی می‌نوشتیم، با دعا به درگاه php، بروزر را ریفرش می‌کردیم بلکی چیزی که نوشتم کار کند. بدترین اتفاق هم ارورهای 500 بود، سمت سرور، یک اتفاقی افتاده بود و صفحه‌ی Blank بروزر هیچ کمکی نمی‌کرد. بعدها فهمیدم این مدل کارکردن من، Programming by Coincidence نام دارد. برای جلوگیری از آن، متوجه شدم که تست‌نویسی در برنامه‌نویسی صرف نظر از اینکه با چه تکنولوژی و ددلاینی کار می‌کنیم، یکی از مهم‌ترین بخش‌های تولید کد است. یکی دو سال است که بدون تست‌نویسی، نمی‌توانم بگویم کدی که نوشتم کار می‌کند.
آن موقع‌ها که جوانتر بودم بیشتر به جادو در برنامه‌نویسی اعتقاد داشتم اما هر چه در عمق تکنولوژی مورد علاقه‌مان فرو رفتم و بیشتر از پیچ و مهره‌های درونی آن با خبر شدم، بیشتر به ماهیت «انسانی» تولیدکننده‌اش پی بردم. لاراول ۴.۲ برای من یک فریم‌ورک جادویی بود، Eloquent Modelها واقعا خیلی از کارها را جادویی انجام می‌دادند و من هم نمی‌دانستم چرا می‌توانم attributeهای دیتابیسم را بدون ذره‌ای کدنویسی، با Object Attribute صدا کنم!
پروژه‌ای بعد از پروژه‌ی دیگر و با پیچیده‌تر شدن کارهایی که باید انجام می‌دادم. متوجه شدم که جادویی در کار نیست و کدی برای این موضوع نوشته شده که می‌توان بسیار در موردش صحبت کرد. مراجعه به این کد، بسیار کمک کننده است:
// If the attribute exists in the attribute array or has a "get" mutator we will
// get the attribute's value. Otherwise, we will proceed as if the developers
// are asking for a relationship's value. This covers both types of values.
if (array_key_exists($key, $this->attributes) ||
$this->hasGetMutator($key)) {
return $this->getAttributeValue($key);
}
// Here we will determine if the model base class itself contains this given key
// since we do not want to treat any of those methods are relationships since
// they are all intended as helper methods and none of these are relations.
هر خط کامنت کدها، سه کاراکتر از خط بعدی بیشتر است! این دقت در نوشتن کامنت، نشان می‌دهد چقدر تمیزی کد برای تیلر آتول، خالق لاراول اهمیت دارد. خود او در توییتش این موضوع را بهتر توضیح می‌دهد:
با مراجعه به کد Eloquent متوجه شدم که ماجرا فقط در داکیومنت‌نویسی تر و تمیز خلاصه نمی‌شود. دقت او در کد تمیز و خوانا را کمتر جایی دیدم. هر جا که فانکشنی بیش از یکی دوتا عبارت if داشت، کامنت داخل فانکشنی به کار رفته بود. نام‌گذاری‌ها به شیوه‌ای بود که حتی اگر بخشی از کد را نمی‌دانستی، می‌توانستی اسم تابع را پیش‌بینی کنی. نتیجه این که فریم‌ورک لاراول هم اکنون بیشترین ستاره‌ی گیت‌هاب در پروژه‌های پی‌اچ‌پی را دارد: بالاتر از سمفونی.
جادو یا تکنولوژی پیشرفته‌ی ناشناخته؟
این شوخی (بی‌مزه) درون‌شرکتی را داریم که مشتریانمان فکر می‌کنند ما هری پاتر هستیم با یک چوب جادو و هر کاری کلا ده دقیقه زمان می‌گیرد. چرا که از دیدگاه فردی که حرفه‌ی ما را نمیشناسد، این نقل قول از آرتور سی کلارک صادق است:
Any sufficiently advanced technology is indistinguishable from magic
-- Arthur C. Clarke
... و طبعا انتظار دارند که پیچیده‌ترین کارها را با یک کپی پیست ساده انجام دهیم.
در طول این سال‌ها هر چه بیشتر سطح را خراشیدم، بیشتر متوجه شدم که پکیج‌هایی که استفاده می‌کنیم، کار چوب جادو نیستند، ساعت‌های بی‌شمار و آخرهفته‌هایی که می‌توانست به پارتی و خوش گذرانی بگذرد، مصرف شده تا پکیجی باشد که امروزه با یک دستور نصب و از آن برای کسب درآمد استفاده می‌کنیم.
با شناخت از چرخه‌ی تغییر، در حال تمرینم که نمودار رولرکستر بالایی را با سرعت بیشتری سپری کنم. بدانم چه زمانی در منجلاب تاریک ناامیدی گرفتار شدم، و برای بیرون آمدن از آن خودم را آماده کنم. باورم به تعریف جادویی که در جوانی از برنامه‌نویسی داشتم، کاملا از بین رفته و تعریف جدیدی از جادو را در ذهن مجسم کرده‌ام. برنامه‌هایی که می‌سازیم، دیگر مثل محاسب فاکتوریل نیستند. برنامه‌های امروز ما، تاثیر بسیار بیشتری بر زندگی مردم دارند.
کوین هنلی در این کنفرانس، بیان می‌کند اشتباهات نرم‌افزاری، می‌تواند تمام تلاش‌های گروهی از مردم برای انجام کاری را مختل کند. دقتی که در تولید نرم‌افزار سالم باید بخرج دهیم، بسیار با اهمیت‌تر از تکنولوژی و زیبایی ظاهری آن است.
بعد از مدت‌های زیادی اقدام به نوشتن بلاگ کردم، اگر چنانچه متن به نظر شما زنگ‌زده و کهنه‌است عذرخواهی می‌کنم. ضمنا اگر به نظر شما نگارنده زیادی مته به خشخاش می‌گذارد، یا نظر دیگری در این باب دارید، در بخش کامنت‌های زیر بنویسید.
