بایگانی دسته: دسته‌بندی نشده

شرکت شما یک محصول است

شرکت شما یک محصول است

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

ادامه مطلب

دیوانگی در کار لازم نیست

این دیوانگی در کار است

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

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

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

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

این موضوع محدود به سازمان‌ها نیست. افراد عادی، پیمانکارها و کارآفرینان تنها هم به شکلی کاملا مشابه، خودشان را نابود می‌کنند.

ممکن است فکر کنید که با این زمانی که آدم‌ها صرف کار می‌کنند و با وعده‌های فناوری ‌های پیشرفته، حجم کار کمتر شده باشد اما این طور نیست. هر روز حجم کار بیشتر و سنگین‌تر می‌شود.

ادامه مطلب

هزینه‌ی بددانستن از ندانستن بیشتر است

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

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

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

چرا تست و آزمون؟

۱. آزمون‌نویسی سرعت توسعه‌ی کد را به شدت زیاد می‌کند چرا که شرایط مد نظر برای بررسی موضوع خاصی رو خیلی سریع و تکراری فراهم می‌کند
۲. آزمون نوشتن توسط اعضای تیم انتظارات آنها از هم را به شدت واضح می‌کند
۳. آزمون‌نویسی کمک می‌کند جنبه‌های هرچه بیشتری از کد و برنامه بررسی شود.
۴. آزمون‌نویسی به ما اطمینان می‌دهد با هر تغییری در یک بخش از کد، سایر بخش‌ها رفتار پیش‌بینی‌نشده نمی‌دهند (ممکن است رفتار سایر بخش‌ها تغییر کند که با اجرای آزمون، مشخص خواهد شد و ما تصمیم می‌گیریم رفتار آزمون را تغییر دهیم یا رفتار کد را)

یکی از ایرادهای ماژول‌های جاوااسکرپیت

در چند سال اخیر در جاوااسکریپت می‌توان ماژول تعریف کرد. ماژول‌ها کمک خوبی هستند اما نحوه مدیریت کردن آن دستکم یک مشکل را به وجود آوده است. فرض کنید شما یک ماوژل با چند خروجی (export) دارید که یکی از آنها می‌تواند خروجی پیش‌فرض باشد (export default). یکی از مشکلاتی که خیلی رخ می‌دهد وارد کردن (import) خروجی پیش‌فرض به عنوان خروجی معمولی و یا برعکس است که عملا باعث می‌شود برنامه به مشکل بخورد. بدتر اینکه در صورتی که خروجی پیش‌فرض را به عنوان خروجی معمولی، وارد کنید، (یا برعکس) جاوااسکریپت خطا نمی‌گیرد

شما از چه ابزاری برای پروتوتایپ استفاده می‌کنید؟

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

ادامه مطلب

۸-قانون «بوی اسکات»

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

اگر ما قانونی مشابه این را در کدنویسی داشته باشیم چه اتفاقی می‌افتد: «همیشه وقتی یک ماژول را تحویل می‌دهی تمیزتر از وقتی باشد که آن را تحویل می‌گیری»؟ بدون توجه به این که نویسنده اولیه آن ماژول چه کسی بوده است، چی می‌شود اگر ما مقداری (هر چند ناچیز) تلاش کنیم تا آن را بهبود بدهیم؟ نتیجه چه خواهد شد؟

ادامه مطلب

۶- قبل از بازنویسی کد

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

ادامه مطلب

۵- زیبایی در سادگی است

نقل قولی از افلاطون است که من فکر می‌کنم خصوصا برای توسعه دهندگان مناسب است و باید آن را در نزدیک قلبشان نگه دارند:

«زیبایی متن و هماهنگی و ظرافت و جذابیت و موزونی بسته به سادگی است.»

این گفته همه آن چیزی که ما به عنوان توسعه دهنده نرم‌افزار در آرزوی آن هستیم را در یک جمله بیان می‌کند.

چیزهایی هستند که ما تلاش می‌کنیم در کد خود داشته باشیم:

  • خوانا بودن
  • قابل نگهداری بودن
  • سرعت در توسعه
  • زیبایی کیفی

ادامه مطلب

۴- استانداردهای کدنویسی را به صورت خودکار اعمال کن

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

ادامه مطلب