خیلی وقت پیش در شرکتی شروع به کار کردم که تقریباً هر کسی هر جور دلش می خواست کد می نوشت. در تیم برنامه نویسی حتی استفاده از سورس کنترل هم رایج نبود (البته آن زمان، استفاده از سورس کنترل در شرکت های خیلی خیلی کمی در ایران رایج بود). سوراخ سنبه های کامپیوترها و سرورها پر از کدهای تکراری بود. باگ ها نه یک بار، بلکه چند بار رفع می شدند. کد پروژه ها حاوی مقدار قابل توجهی بلاک بودند که اصلاً هیچ وقت امکان اجرا پیدا نمی کردند.
مدیریت تصمیم گرفت سر و سامانی به اوضاع بدهد. استفاده از سورس کنترل اجباری شد، همه تیم اجایل و اسکرام یاد گرفتند، برای همه چیز قاعده در نظر گرفته شد. برای هر چیزی حتی یک موضوع کم اهمیت هم جلسه تشکیل می شد و موضوع به بحث گذاشته می شد. حتی آب خوردن های دولوپرها بدون تعریف تسک غیر ممکن شد. نام گذاری هیچ چیزی بدون در نظر گرفتن متود رسمی شرکت امکان پذیر نبود. و خلاصه سلسه مراتب شرکت از نظم ارتش هم جلوتر زد.
خلاصه این که از یک آش بی نمک به یک آش شور رسیدیم. قبلاً کد تکراری و غیر قابل فهم داشتیم، بعدش سربار زیادی برای تیم توسعه ایجاد شد. به نحوی که برای عوض کردن یک بلاک IF هم باید جلسه برگزار می شد. همین بورکراسی به منطق کد هم منتقل و باعث کند شدن برنامه شد. از چاله به چاه نیفتادیم، بلکه از یک چاله به یک چاله دیگر افتادیم. چاله جدید گوی کمتری داشت ولی به هر حال با ایده آلی که لازم بود، خیلی تفاوت داشت.
جالب اینجاست که این الگو را در تیم های دیگر هم دیده و هنوز هم می بینم. تصمیم گیرندگان به قصد نظم بخشی و بهبود کیفیت کدی که واقعاً هم نیاز به تقویت ساختار دارد، آنچنان قواعد مختلف، تو در تو و سخت گیرانه ای تعریف می کنند که این بار از آن طرف بام می افتند. صد تا interface برای پروژه تعریف می کنند در حالی که هیچ کدام از آنها قرار نیست بیش از یک بار implement شوند. Repository روی Repository تعریف می شود و کلی فیلد یکسان به همه جداول اضافه می شود با این توجیه که پروژه باید یک دست باشد.
من هنوز نفهمیدم که قصه چیست. چرا نمی شود حد وسط را انتخاب کرد؟ آیا تیم Refactoring می خواهد با پیچیده سازی کد، نبوغش را به رخ بکشد؟ آیا از بس که کد بی ساختار دیده اند خسته شده اند و تصمیم گرفته اند برای هر دری، یک دربان و ده تا قفل و کلید بگذارند؟
Comments
ما که هر چی میکشیم از بی برنامه بودن هستش
سلام آقای محبی
ممنون بخاطر مطالب زیبا و جذابتون
سه ساله که در یک شرکت خصوصی در زمینه خانه هوشمند در قسمت مربوط به برنامه نویسی مشغول به کار هستم,از اونجایی که رشته ی من الکترونیک بود ,به اصطلاح خودم برنامه نویسی سخت افزار میکنم (برنامه نویسی برای سیستم های جاسازی شده یا همون میکروکنترلر ها نمیدونم اصطلاحم درسته یا نه -:) ). قبل از من برنامه نویسانی بودند که وقتی من اومدم رفته بودند.
از اونجایی که هیچ چهارچوبی برای برنامه نویسی در این شرکت وجود نداشت و ندارد , با انواع و اقسام روش و سبک های کد نویسی (از کد هایی که هیچ کامنت یا داکیومنتی ندارند تا کد های که برای هر تابع یک صفحه کامنت دارند و ….) برخورد کردم .
بعد از سه سال کد زدن و اصلاح کد دیگران ,به کوهی از کد های درهم و برهم برخوردم که دیگه خودم هم نمیدونم کدوم به کدوم ربط داره (تا اونجایی که تونستم پوشه بندی ,نام گذاری و داکیومنت نویسی کردم).
تا اینکه به این نتیجه رسیدم که باید کار چهارچوب داشته باشه ,پس راه افتادم دنبال ابزار ها و راه های چهارچوب گذاری :
اول از همه یک VCS انتخاب کردم (git) ,داشتم داکیومنت های مربوط به اون رو میخوندم که رسیدم به واژه ی issu-tracking system ,داشتم دنبال یک ابزار مناسب برای issue-tracking میگشتم که به وبلاگ زیبای شما برخورد کردم.
با خوندن چند تا از پست هاتون متوجه این شدم که فردی با تجربه هستید که میتونه دغدغه من رو پاسخگو باشد.
با دیدن این پست ناگهان ترسیدم و گفتم نکنه من هم دچار این اتفاق بشم ,پس هر چه بیشتر مطمعن شدم به یک فرد با تجربه مثل شما نیاز دارم تا کمکم کنه.
پس در قدم اول لطفا کمکم کنید در مسیر نظم بخشیدن به بخش برنامه نویسی در این شرکت قرار گرفته ام ,چگونه در دچار پدیده ی (بی نظمی و نظم زیادی) نشم.
سعی میکنم تمام پست های مرتبط با دغدغه های ذهنیم رو در وبلاگتون بخونم و از کمک های شما استفاده کنم.
ممنون
Author
سلام. از لطف شما سپاسگزارم.
من خودم بیشتر از آن دسته افرادی هستم که جزییات بیشتر را به سادگی ترجیح می داده اند. اما با این حال فکر می کنم زیادی پیچیده و پر جزییات بودن کمک زیادی به ما نمی کند.
پیدا کردن یک نقطه امن که نه زیادی بی نظم باشد و نه زیادی منظم، کار ساده ای نیست واقعا. فکر می کنم یک مقدار از این موضوع با سعی و خطا و تعامل با افراد تیم و در نظر گرفتن افرادی که در آینده به تیم خواهند پیوست مشخص می شود. یکی از دلایل وجود افراط در نظم و پیچیدگی، این است که افراد می خواهند باهوش بودن و آینده نگر بودنشان را به رخ بکشند. یکی از دلایل تفریط هم این است که افراد می خواهند برای خودشان امنیت شغلی ایجاد کنند یا این که انرژی کافی برای انجام کار صرف نمی کنند. به نظرم توجه کردن به انگیزه های هر کدام از دو سر طیف می تواند به حفظ تعادل کمک کند.
من همیشه سعی می کنم خودم را جای نفر بعدی بگذارم که قرار است کد من یا سیستم من را دنبال کند. از خودم می پرسم این حد از نظم و پیچیدگی به او کمک خواهد کرد که سیستم را بهتر بفهمد یا نه.