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

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

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

بهرحال با گذر از swagger تصمیم گرفتم مستقیما سراغ تهیه پروتوتایپ بروم. پروتوتایپ به مفهوم پیش‌نمایش صفحات، پرسشنامه‌ها، فرم‌ها، فهرست‌ها و روابط بین هرکدام از این عناصر هست. پروتوتایپ در واقع به شما و هر کس دیگه‌ای که لازم باشد، نشان خواهند داد که سیستم چطوری باید باشد و شما به عنوان توسعه‌گر، یک نمای کلی از سیستم را خواهید داشت. برای تهیه پروتوتایپ ابزارهای زیادی هست. من ابزارهای آنلاین خوبی را بررسی کردم. شامل https://moqups.com و http://mockflow.com. این دو ابزار تقریبا خوب هستند. منتهی یکی دو ایراد دارند. اول اینکه راست به چپ نیستند و مهم‌تر اینکه رایگان نیستند یا نسخه‌ی رایگان‌شان، خیلی محدود هستند و بدتر اینکه امکان خرید دلاری برای ما فراهم نیست (حتی اگر قرار بود ماهی ۱۳ دلار، معادل حدودا ۱۵۰ هزار تومان پرداخت کنیم که بازهم رقم بالایی برای ما محسوب می‌شود)

ابزارهای آفلاینی هم هست. مثلا Sketch که البته برای Mac هست و من نتونستم بررسی کنم. همچنین Adobe XD

متاسفانه ابزارهای آفلاین ظاهرا خیلی ناقص هستند. قبلا هم تجربه‌ی کار با Visio را داشتم. به نظرم ابزارها، چه آنلاین و چه آفلاین باید ویژگی‌های زیر را داشته باشند:

  • باید ابعاد صفحه‌ی نامحدود داشته باشند. دستکم در یک وجه. اگرچه صفحه‌های واقعی، محدودن و مثلا نمی‌توان هزاران پیکسل را در یک صفحه‌ی آیفون نمایش داد، ولی اسکرول وجود دارد. اما اسکرول در زمان طراحی، سخت است. بنابراین به راحتی می‌توان یک صفحه‌ی نامحدود در نظر گرفت که با اسکرول ترکیب خواهد شد
  • باید جعبه‌ابزار آماده داشته باشد. یکی از اهداف پروتوتایپ، پیش‌نمایش زیبای پرسشنامه‌ها و فهرست‌هاست. منتهی بعضی از ابزارها، آنچنان مینی‌مال یا خلاصه‌گرا شده‌اند که حتی عناصری مانند دکمه و تیک را ندارند!!! مثلا Adobe XD تقریبا هیچ ابزار آماده‌ای ندارد. نه دکمه، نه تیک، نه رادیو، نه تقویم، نه سربرگ و نه هیچ چیز دیگر! البته راه حلی برای این موضوع در نظر گرفته‌اند. فایلی حاوی عناصر بوت‌استرپ، گوگل متریال و سیستم مک درست کرده‌اند که بایستی دانلود شده و سپس باز شود (امکان ورود ندارد) و سپس مثلا دکمه‌ی مد نظر را از فایل بوت‌استرپ در فایل خود، کپی کنید!
  • ابزار خوب، می‌داند اغلب پروتوتایپ‌ها شامل پرسشنامه و فهرست هستند. بنابراین و برای کاهش زمان طراحی، باید چندین پرسشنامه و فهرست نمونه باشد
  • ابزار خوب، به شما خواهد گفت برای چه دکمه‌هایی کاربرد تعریف نشده است
  • ابزار خوب به شما امکان افزودن راهنما و مستندات برای هر حرکتی را خواهد داد. مثلا نمایش اینکه دکمه‌ی ایکس فقط زمانی قابل کلیک خواهد بود که دستکم تیک یکی از سطرها زده باشد را شاید نباید در پروتوتایپ پیاده کرد. اما یک راهنمای ساده می‌تواند برای سایر افراد تیم راهگشا باشد
  • ابزار خوب امکان تکرار صفحه را دارد. مثلا صفحه‌ای در پرتال ما وجود که الگوی پیامک و ایمیل ارسالی در زمان خاصی را می‌توان تعریف کرد. این پرسشنامه، الگوی پیام‌های ارسالی در زمان تغییر رمز، ایجاد کاربر، تایید پرداخت و خرید و خیلی کارهای دیگر را انجام می‌دهد. این پرسشنامه چند سربرگ دارد و خودش به تنهایی نیاز به پروتوتایپ جداگانه دارد! بنابراین قرار نیست به ازای هر الگوی تعریفی، (که در صفحه‌ی جداگانه‌ای قرار می‌گیرد) کلی صفحه‌ به پروتوتایپ افزود. بایستی فقط گفت «این صفحه نسخه‌از پرسشنامه تنظیم الگو هست که در اینجا برای ویرایش الگوی پیام تغییر رمز به کار می‌رود»

خلاصه اینکه تجربه من در استفاده از Adobe XD واقعا آزاردهنده بود. منتهی هنوز هیچ ابزار خوبی پیدا نکرده‌ام. لطفا بگویید از چه ابزاری برای تهیه پروتوتایپ استفاده می‌کنید؟

شرکت خانواده نیست

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

ادامه مطلب

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

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

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

ادامه مطلب

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

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

ادامه مطلب

آموزش جاوا، فصل یازدهم: ساختار کلاس ها در جاوا

همانطور که در فصل قبل گفتیم کلاس ها سنگ بنای برنامه نویسی شی گرا هستند. یک برنامه جاوا از تعدادی کلاس ساخته می شود. اشیا از روی کلاس ها ساخته می شوند و ارتباط اشیا با هم مسأله را حل می کند. حالا اگر قدری دقیق تر به کلاس ها نگاه کنیم، می بینیم که خود کلاس ها از اجزای کوچکتری ساخته می شوند. بار دیگر به ویژگی های برنامه های شی گرا از دید Alan Kay دقت کنید:

  1. هر چیزی یک شی است.
  2. یک برنامه مجموعه‌ای از اشیا است که با استفاده پیام‌رسانی به یکدیگر می‌گویند که چه کار باید بکنند.
  3. هر شیء‌ای دارای حافظه‌ای است که از سایر اشیا ساخته شده است.
  4. هر شیء‌ای یک «نوع» دارد.
  5. تمام اشیای همنوع می‌توانند پیام‌های یکسانی دریافت کنند.

ادامه مطلب

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

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

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

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

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

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

ادامه مطلب

فیلم‌های آموزشی اندروید

سلام به همراهان همیشگی اسمارت‌لب

قصد دارم فیلم‌های آموزشی جاوا، کاتلین و اندروید تولید کنم. سرفصل‌ها و مطالبی که قرار است در این آموزش‌ها بیاید را مشخص کرده‌ام و به زودی می‌خواهم کار را آغاز کنم. در این زمینه به کمک شما نیاز دارم.

اگر موضوعی مد نظر دارید برای آموزش زیر همین مطلب کامنت بگذارید و اگر با نرم‌افزارهای ویرایش فیلم مانند corel videostudio pro کار کرده‌اید و تمایل دارید در این موضوع با من همکاری کنید لطفا یک ایمیل به info در اسمارت لب بفرستید و از تجربه‌هایتان برایم بنویسید. لطفا در ایمیل دستمزد مورد انتظار و نیز میزان ساعات همکاری را هم بنویسید.

متشکرم

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

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

ادامه مطلب

۳- بپرس «کاربر چه کار خواهد کرد؟» (تو کاربر نیستی)

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

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

ادامه مطلب

۱-با احتیاط عمل کن

«هر کاری که به عهده می‌گیری، با احتیاط عمل کن و نتایج آن را در نظر داشته باش» -آنون

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

ادامه مطلب