فکر کردن و توسعه نرم‌افزار
تفکر بیش از انجام کارها همواره یک اصل ساده و جدایی ناپذیر برای ما انسانها بوده است. به صورتی که یکی از جنبه‌های تمایز انسان با سایر موجودات همین توانایی تفکر در مورد مسائل ریز و درشت است. اما این فکر کردن در دنیای نرم‌افزار به چه صورت می‌تواند متبلور شود؟ چگونه و چه زمان و چه موقع در مورد توسعه نرم‌افزار فکر می‌کنیم؟
-
چرا فکر می‌کنیم؟
به یه دلیل ساده. چون فکر کردن کمک می‌کنه که خیلی از چیز‌ها رو بتونیم انجام بدیم. بدون فکر کردن در مورد خیلی از چیز‌ها، امکان انجام دادنشون وجود نداره. کارهایی مثل دست به انقلاب زدن. ساخت یه خونه. نوشتن یک نرم‌افزار.
-
اما چه موقع باید فکر کنیم؟
این یک سوال اساسی است. خب به مثال‌های بالا نگاه کنیم.
فرض کنید میخواید انقلاب کنید؟
منبع تصویر:https://education.nationalgeographic.org/resource/revolution
خب قبل از حرکتی مثل بیرون اومدن از خونه برای اعتراض، یا تحسن کردن و … به موضوع فکر می‌کنیم. بخوام رو راست باشم باید خیلی فکر کنیم!
در مورد ساخت یه خونه چطور؟
منبع تصویر: https://www.mydomaine.com/traditional-style-house-5203912
قبل از اینکه شروع به ساخت و ساز کنیم. بعید میدونم شما بخواید که قبل از اینکه زیر زمین و محل سرویس بهداشتی و … رو بدونید و بهش فکر کنید، شروع به ساخت خونه کنید. نتیجه اینکه شروع به فکر کردن در مورد چیزی که میخواید انجام بدید می‌کنید.
اما توسعه یک نرم‌افزار چی؟
منبع تصویر: https://news.mit.edu/2020/brain-reading-computer-code-1215
بله؛ قبل از نوشتن هر قطعه کدی باید بهش فکر کنیم!
- اما چطور فکر می‌کنیم؟
“Writing is a nature’s way of letting you know how slopping your thinking is”
خب برای فکر کردن نیاز داریم که افکارمون رو منسجم کنیم. بهترین راه برای اینکار اینه که بنویسیم. فکرمون رو روی کاغذ بیاریم. اگر فکر کردن ما بدون آوردن اون روی کاغذ باشه، در حقیقت ما فکر می‌کنیم که فکر می‌کنیم. خودمون رو گول می‌زنیم!
-
ولی چه چیزی رو باید بنویسیم؟
خب برگردیم به مثال‌های بالا.
انقلاب کردن؟
خب موافقم. در این مورد هنوز کسی براش کاری نکرده. متاسفم. و این به معنی که این کار خیلی خطرناکیه. باید مراقب باشی.
ساخت خونه؟
قبل از ساخت خونه چه چیزی رو روی کاغذ می‌آریم؟ بله درسته، نقشه ساختمون-blueprint. کشیدن blueprint از اون چیزی که از خونه می‌خوایم بعد از اتمام ساخت و ساز داشته باشیم.
توسعه یه برنامه چطور؟
ما باید یک blueprint از برنامه بکشیم و داشته باشیم. اما blueprint برنامه همون چیزیه که بهش Specification می‌گیم.
معمولا با شنیدن Specifications داکیومنت‌های فرمال و رسمی و طولانی به ذهن متبادر میشه. مستنداتی که کسی رغبتی و تلاشی برای خوندنش نمی‌کنه. شما رو مجبور می‌کنه که notationها و سیمبل‌های مختلفی رو بشناسید. معنی مربع و مستطیل و لوزی‌ها رو خوب بدونید. خطوطی که مثل چنگال از یک جای یک مربع خارج میشه و به جایی توی یه مربع دیگه فرو میشه رو بفهمید.
اگر به Blueprint های ساختمون‌ها نگاه کنیم. طیف وسیعی از اشکال ساده تا بسیار پیچیده رو میتونیم مشاهده کنیم. در حقیقت ما طیفی از blueprintها رو از حیث سادگی و پیچیدگی میتونیم متصور بشیم. از اونهایی که با جزئیات بسیار بسیار زیاد هستند و کاملا پیچیده هستن تا اونهایی که بسیار ساده‌تر هستند.
Specification نرم‌افزار نیز دقیقا شامل همین طیف است. در حقیقت ما با یه مسئله فازی سروکار داریم. برخی از برنامه‌ها ساده هستند و Specification انها نیز بسیار ساده می‌تواند باشد. گاهی ما با طیف پیچیده‌ای از برنامه سروکار داریم. از جمله برنامه‌های چند نخی و توزیع شده و برنامه‌هایی که بصورت موازی اجرا بشوند، این برنامه‌ها نیاز به یک specification رسمی نیاز دارد. از اون نوع‌هایی که باید بصورت رسمی توسط محیط توسعه و زبان برنامه‌نویسی پشتیبانی شود. اما روی صحبت ما در اینجا با دامین‌هایی است که وسط این طیف قرار دارد. بله ما نیاز داریم که این specification رو روی کاغذ بیاریم و بنویسیم. چون این بهترین راه برای فکر کردن در مورد برنامه‌ای است که قصد نوشتنش رو داریم. آن هم قبل از شروع به نوشتن کد.
پس ما قبل از نوشتن هر قطعه کدی باید در مورد آن فکر کنیم. برای اینکه به درستی فکر کنیم باید فکرمون رو روی کاغذ بیاریم(بنویسیم یجایی. موافقم توی نت‌پد و … هم میتونیم بنویسیم.). از این فکر و نوشتن به عنوان مکانیزم proof-of-work استفاده می‌کنیم.
Specification by Example یک رویکرد مناسب و کارا برای این نوع طرز تفکر به توسعه نرم‌افزار است. این روش یک رویکرد مبتنی بر همکاری بین افراد مختلف درگیر در توسعه نرم‌افزار است. در این روش outcome سیستمی که قصد توسعه اون رو داریم، در قالب یکسری example مشخص می‌شود. در واقع فرآیند اکتشاف دامین مسئله از طریق example آوردن انجام می‌شود.
Context => Action => Outcome
متن بالا برداشتی از یک سخنرانی مهم آقای لزلی لمپارد بزرگ است.
