آموزش: چگونه مثل یک برنامه نویس خوب کد بنویسیم [بایگانی]

View Full Version : آموزش: چگونه مثل یک برنامه نویس خوب کد بنویسیم

javanerd

پنج شنبه 19 فروردین 1389, 09:52 صبح

از همه‌ی افراد دعوت می‌کنم که مباحث مربوط به اصولی کد نوشتنن رو توی این تاپیک مطرح کنند.

mazdadoost

شنبه 21 فروردین 1389, 14:33 عصر

از همه‌ی افراد دعوت می‌کنم که مباحث مربوط به اصولی کد نوشتنن رو توی این تاپیک مطرح کنند.

خیلی کلی مطرح کردین.یه مقداری ریز ترش کنید.
مرسی.

javanerd

یک شنبه 22 فروردین 1389, 09:24 صبح

خیلی کلی مطرح کردین.یه مقداری ریز ترش کنید.

هدفم بیشترمطرح کردن موضوعاتی بود که به بحث‌هایی است که در لینک‌های زیر مطرح شده‌ان شبیه باشند.

http://javanerd.wordpress.com/2010/04/07/how-to-select-names-for-identifiers
http://javanerd.wordpress.com/2010/04/09/scope-of-vaiables
(http://javanerd.wordpress.com/2010/04/09/scope-of-vaiables/C#%E2%80%8Eomments)

mazdadoost

یک شنبه 22 فروردین 1389, 19:16 عصر

هدفم بیشترمطرح کردن موضوعاتی بود که به بحث‌هایی است که در لینک‌های زیر مطرح شده‌ان شبیه باشند.

http://javanerd.wordpress.com/2010/04/07/how-to-select-names-for-identifiers
http://javanerd.wordpress.com/2010/04/09/scope-of-vaiables (http://javanerd.wordpress.com/2010/04/09/scope-of-vaiables/C#‎omments)

دوست عزیز :
لینکه دوم خطا میده.
در لینکه اول موضوعه مطرح شده بیشتر به نظر من به آنچنان به برنامه نوس خوبی شده ربطی نداره و بیشتر یک اصل اولیه هست برای کد نوسی.
ضمنا با توجه به این که عنوان تاپیک ربطه مستقیم با java نداره و یک موضوع عمومی هست توصیه میکنم یا عنوان تاپیک رو عوض کنید یا منتقل بشه .
از طرفی به نظر بنده برای جواب این سوال که چطور میشه برنامه نویس خوبی در زمینه جاوا شد یک مرجع آلی وجود داره که و اون هم Effective Java هستش.(که خودم بارها مطالعش کردم و میکنم.)

شاید بشه بعضی از مطالب اون کتاب رو در این تاپیک مطرح کرد.
و در ادامه هم به مزیت های Test Unit-Code Coverage -Logging - Testing-Profiling - و... در بهبود کیفیت توسعه و طراحی نرم افزار پرداخت .موفق باشید.

javanerd

یک شنبه 22 فروردین 1389, 23:26 عصر

لینکه دوم خطا میده.

به خاطر اشکالی که توی لینک دوم وجود داشت متاسفم، درستش کردم. ممنون به خاطر گوشزد کردن

ضمنا با توجه به این که عنوان تاپیک ربطه مستقیم با java نداره و یک موضوع عمومی هست توصیه میکنم یا عنوان تاپیک رو عوض کنید یا منتقل بشه .

من هم با شما موافقم. شاید بهتر باشه که به یکی از زیر تاپیک‌ها مهندسی نرم‌افزار منتقل بشه.

از طرفی به نظر بنده برای جواب این سوال که چطور میشه برنامه نویس خوبی در زمینه جاوا شد یک مرجع آلی وجود داره که و اون هم Effective Java هستش.(که خودم بارها مطالعش کردم و میکنم.)

شاید بشه بعضی از مطالب اون کتاب رو در این تاپیک مطرح کرد.

من بیشتر هدفم این بود که بحث‌هایی از کتاب‌های The pragmatic programmer و The Psychology of Computer Programming و Code Complete مطرح بشه. خودم کتاب Effective Java رو نخوندم. ولی با این توضیحی که شما در موردش دادید خوندنش لازم شد. اگر شما مطالب رو از اون کتاب بگذارید خیلی لطف بزرگی خواهید کرد. احتمالا کتاب‌های خیلی خوب دیگه‌ای هم وجود داره که دیگران خوانده‌اند.

javanerd

یک شنبه 22 فروردین 1389, 23:40 عصر

و در ادامه هم به مزیت های Test Unit-Code Coverage -Logging - Testing-Profiling - و...
ترجیحا توی این تاپیک فقط در مورد کد نوشتن بحث بشه. بحث testing اونقدر گستره هست که پیشنهاد می‌دهم اگر قرار هست در موردش صحبت بشه توی یک تاپیک مجزا در موردش بحث بشه. به نظرم مباحث کامل‌تر رو میشه از یک کتاب مختص testing مثل کتاب The art of software testing. اگر کسی کتاب خوب دیگه‌ای توی این زمینه سراغ داره لطفا پیشنهاد بده.

mazdadoost

دوشنبه 23 فروردین 1389, 00:18 صبح

خوب توی همون کتاب :
Item 56:Adher Togenerally accepted naming convections فکر میکنم شروعه خوبی باشه.

javanerd

دوشنبه 23 فروردین 1389, 17:56 عصر

خوب توی همون کتاب :
Item 56:Adher Togenerally accepted naming convections فکر میکنم شروعه خوبی باشه.
من همین چند ساعت پیش این بحثی که شما پیشنهاد داده بودید رو خوندم، خیلی عالی بود. ولی چیزهایی که من قصد دارم در موردشون بحث کنم خیلی فراتر از مطالبی هست که توی این بحث بهشون شااره شده بود.
مثلا من قصد دارم در مورد موارد زیر بحث کنم

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

mazdadoost

چهارشنبه 25 فروردین 1389, 10:42 صبح

سلام:
دوست عزیز طبق تجربیات بنده :
1-بسته به اینکه متغیر کلاس باشه یا محلی :
اگر کلاس باشه آخره فایل .
اگر محلی باشه در نزدیکترین جایی که استفاده قراره بشه (ترجیحا تعریف و استفاده در یک خط).
2-کلا متغیر ها به نظر من باید در OOP معرف چیزی باشند که نگهدار ی میکنند نه نوعشون (نوعشون هم با مفهومشون معلوم میشه مثلا count احتمالا یک شمارست یا name که یک رشته میتونه باشه).
3-(کجای برنامه متغیرها رو مقداردهی کنیم بهتره.) و (وقتی که می‌خواهیم که یک متغیر خاص (مثل شمارنده‌ی حلقه، اندیس آرایه، متغیری که نتیجه‌ی بازگشتی تابع در آن ذخیره می‌شود و ...) تعریف کنیم، چطور تعریف کنیم بهتره.) به نظرم این دو مورد یا بیان همون دو مورد اولی هستند یا من فرقی نمیبینم.
4-psychological distance و تست تلفن رو اگر میشه بیشتر توضیح بدین .
ممنون.

javanerd

دوشنبه 30 فروردین 1389, 14:57 عصر

4-psychological distance و تست تلفن رو اگر میشه بیشتر توضیح بدین .
ممنون.

توی این پست در مورد psychological distance توضیح می‌دهم. در مورد تست تلفن هم سر فرصت توضیح می‌دهم. منتها قبل از اینکه بریم سراغ بحث psycholagical distance اول باید یک مقدمه‌ی کوچک باید بگم. به کد زیر که برای جمع کردن دو تا ماتریس (آرایه دو بعدی) نوشته شده نگاه کنید

for (int i=0; i <100; i++){
for (int j=0; j <100; i++){
a[i,j] = b[i,j] + c[i,j];
}
}

توی این مقدمه و در ادامه‌ی پست به این کد ارجاع خواهم داد.

موقع خوندن یک متن، کتاب یا کد برنامه،‌ چشم آدم‌ها همیشه چیزی که نوشته شده رو نمی‌خونه، بلکه بعضی وقت‌ها چیزی رو می‌خونه که دوست داره بخونه. برای مثال شما احتمالا کمی بالاتر متوجه نشدید که یک بار کلمه‌ی psychological‌ به اشتباه psycholagical نوشته شده، چون شما انتظار داشتید که کلمه‌ی psychological رو با املای درست ببینید (من عمدا جای حرف o رو با حرف a عوض کردم).

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

برای اینکه این مشکل کم بشه چند تا راه حل وجود داره یکی از راه حل‌ها استفاده از نام‌های مناسب برای متغیرهاست. در مورد این موضوع که نام یک متغیر باید نشان دهنده‌ی کاری باشه که متغیر انجام میده و سایر بحث‌های مشابه توی همین تاپیک توضیح داده شده.
ولی وقتی می‌خواهیم برای یک متغیر یک نام انتخاب کنیم باید یک نکته‌ی دیگه هم مد نظرمون باشه. اسمی که برای متغیر انتخاب می‌کنیم باید طوری باشه که شبیه به سایر اسم‌های انتخاب شده برای متغیرها نباشه. به عبارت دیگه با یک نگاه باید بشه تشخیص داد که متغیر کدوم متغیر هست.
برای مثال form به تنهایی یک نام خوب برای یک متغیر هست. ولی اگرتوی برنامه یا تابعی که متغیر form‌ تعریف یا استفاده شده یک متغیر دیگه به اسم from هم وجود داشته باشه اونوقت همین نام تبدیل به یکی از بدترین نام‌های ممکن میشه. چون در این صورت برنامه نویس باید بخشی از وقت و تمرکزش رو صرف تمایز قایل شدن بین این متغیر بشه.

چند تا مثال دیگه می‌زنم.
شما احتمالا باید خیلی سعی کنید تا فرق بین length و Iength و 1ength.
همین طور تفاوت بین یک ZERO و ZER0 رو متوجه بشید‌(این یکی واقعا سخت بود).
یا xttxtt و xttxxt (اگر یک نفر رو دید که همچین اسم‌هایی برای متغیرهاش انتخاب کرده به عقلش شک کنید.)
یا width‌ و widht.

در کل هر چقدر ساده‌تر بشه تفاوت بین دوتا متغیر رو تشخیص داد به اصطلاح psychological‌ distance‌ بین این دو تا متغیر بیشتره. اگر بخواهیم تحت الفظی ترجمه کنیم میشه فاصله‌ی دو تا متغیر از دید روانشناسی! به هر حال بهتره که این فاصله به اندازه‌ی کافی زیاد باشه طوری که برنامه‌نویس به درسر نیفته. معمولا پارامترهای زیر نقش اساسی توی مقدار این فاصله دارند.
تعداد حرف‌های مشترک بین نام‌های دو متغیر
سه چهار حرف اول و سه چهار حرف آخر نام متغیرها
تعداد دفعات استفاده از حرف‌های مشابه مثل l (حرف ال کوچک انگلیسی) و I (حرف آی بزرگ انگلیسی) و 1 (عدد یک انگلیسی)

خوب حالا که همه‌ی این تفاوت‌ها رو تشخیص دادید یک بار دیگه برگردیم سراغ کدی که اول این پست گذاشتم.
واقعیت این هست که احتمال اینکه مثال‌هایی که من چند خط بالا زدم توی کی کد ظاهر بشه خیلی کمه، ولی مثالی که اول این پست زدم (دو تا حلقه‌ی تو در تو) توی خیلی از برنامه‌ها ظاهر میشه.
احتمالا شما متوجه نشدید که کد بالا دارای یک اشکال هست، البته شما مقصر نیستید. کسی که کد رو نوشته باید بهتر کد می‌نوشت. توی این کد توی حلقه‌ی دوم به جای j به اشتباه i نوشته شده (شرط می‌بندم که خود شما هم تا حالا چند بار توی این اشتباه گیر افتادید و کلی از وقت شما به خاطر همین اشکال ساده هدر رفته).
شاید اگر برنامه‌نویس یک اسم‌های بهتری برای متغیر‌های i و j‌ انتخاب می‌کرد خیلی ساده‌تر این اشکال کشف می‌شد (برای مثال rowInex به جای i و colIndex به جای j).

mazdadoost

سه شنبه 31 فروردین 1389, 00:01 صبح

توی این پست در مورد psychological distance توضیح می‌دهم. در مورد تست تلفن هم سر فرصت توضیح می‌دهم. منتها قبل از اینکه بریم سراغ بحث psycholagical distance اول باید یک مقدمه‌ی کوچک باید بگم. به کد زیر که برای جمع کردن دو تا ماتریس (آرایه دو بعدی) نوشته شده نگاه کنید

for (int i=0; i <100; i++){
for (int j=0; j <100; i++){
a[i,j] = b[i,j] + c[i,j];
}
}

توی این مقدمه و در ادامه‌ی پست به این کد ارجاع خواهم داد.

موقع خوندن یک متن، کتاب یا کد برنامه،‌ چشم آدم‌ها همیشه چیزی که نوشته شده رو نمی‌خونه، بلکه بعضی وقت‌ها چیزی رو می‌خونه که دوست داره بخونه. برای مثال شما احتمالا کمی بالاتر متوجه نشدید که یک بار کلمه‌ی psychological‌ به اشتباه psycholagical نوشته شده، چون شما انتظار داشتید که کلمه‌ی psychological رو با املای درست ببینید (من عمدا جای حرف o رو با حرف a عوض کردم).

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

برای اینکه این مشکل کم بشه چند تا راه حل وجود داره یکی از راه حل‌ها استفاده از نام‌های مناسب برای متغیرهاست. در مورد این موضوع که نام یک متغیر باید نشان دهنده‌ی کاری باشه که متغیر انجام میده و سایر بحث‌های مشابه توی همین تاپیک توضیح داده شده.
ولی وقتی می‌خواهیم برای یک متغیر یک نام انتخاب کنیم باید یک نکته‌ی دیگه هم مد نظرمون باشه. اسمی که برای متغیر انتخاب می‌کنیم باید طوری باشه که شبیه به سایر اسم‌های انتخاب شده برای متغیرها نباشه. به عبارت دیگه با یک نگاه باید بشه تشخیص داد که متغیر کدوم متغیر هست.
برای مثال form به تنهایی یک نام خوب برای یک متغیر هست. ولی اگرتوی برنامه یا تابعی که متغیر form‌ تعریف یا استفاده شده یک متغیر دیگه به اسم from هم وجود داشته باشه اونوقت همین نام تبدیل به یکی از بدترین نام‌های ممکن میشه. چون در این صورت برنامه نویس باید بخشی از وقت و تمرکزش رو صرف تمایز قایل شدن بین این متغیر بشه.

چند تا مثال دیگه می‌زنم.
شما احتمالا باید خیلی سعی کنید تا فرق بین length و Iength و 1ength.
همین طور تفاوت بین یک ZERO و ZER0 رو متوجه بشید‌(این یکی واقعا سخت بود).
یا xttxtt و xttxxt (اگر یک نفر رو دید که همچین اسم‌هایی برای متغیرهاش انتخاب کرده به عقلش شک کنید.)
یا width‌ و widht.

در کل هر چقدر ساده‌تر بشه تفاوت بین دوتا متغیر رو تشخیص داد به اصطلاح psychological‌ distance‌ بین این دو تا متغیر بیشتره. اگر بخواهیم تحت الفظی ترجمه کنیم میشه فاصله‌ی دو تا متغیر از دید روانشناسی! به هر حال بهتره که این فاصله به اندازه‌ی کافی زیاد باشه طوری که برنامه‌نویس به درسر نیفته. معمولا پارامترهای زیر نقش اساسی توی مقدار این فاصله دارند.
تعداد حرف‌های مشترک بین نام‌های دو متغیر
سه چهار حرف اول و سه چهار حرف آخر نام متغیرها
تعداد دفعات استفاده از حرف‌های مشابه مثل l (حرف ال کوچک انگلیسی) و I (حرف آی بزرگ انگلیسی) و 1 (عدد یک انگلیسی)

خوب حالا که همه‌ی این تفاوت‌ها رو تشخیص دادید یک بار دیگه برگردیم سراغ کدی که اول این پست گذاشتم.
واقعیت این هست که احتمال اینکه مثال‌هایی که من چند خط بالا زدم توی کی کد ظاهر بشه خیلی کمه، ولی مثالی که اول این پست زدم (دو تا حلقه‌ی تو در تو) توی خیلی از برنامه‌ها ظاهر میشه.
احتمالا شما متوجه نشدید که کد بالا دارای یک اشکال هست، البته شما مقصر نیستید. کسی که کد رو نوشته باید بهتر کد می‌نوشت. توی این کد توی حلقه‌ی دوم به جای j به اشتباه i نوشته شده (شرط می‌بندم که خود شما هم تا حالا چند بار توی این اشتباه گیر افتادید و کلی از وقت شما به خاطر همین اشکال ساده هدر رفته).
شاید اگر برنامه‌نویس یک اسم‌های بهتری برای متغیر‌های i و j‌ انتخاب می‌کرد خیلی ساده‌تر این اشکال کشف می‌شد (برای مثال rowInex به جای i و colIndex به جای j).

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

javanerd

سه شنبه 31 فروردین 1389, 08:22 صبح

میدونی من معمولا وقتی پای یک کد مینشینم برام دو حالت داره یا خودم نوشتم یا غیر خودم .وقتی خودم نوشتم که معمولا قواعد کلی رو رعایت میکنم تا وقتی بدونم الان و در آینده قرار نیست دست و پاگیرم بشه

حتی اگر کد رو یک نفر دیگه نوشته باشه، شما میتونید با اعمال کردن یک سری refactoring خیلی خیلی بهبودش بدهید.

jlover

چهارشنبه 01 اردیبهشت 1389, 22:09 عصر

...
یا xttxtt و xttxxt (اگر یک نفر رو دید که همچین اسم‌هایی برای متغیرهاش انتخاب کرده به عقلش شک کنید.)
...

ببینید یادم میاد یه زمانی یه پروژه ای با ++C نوشته بودم و از اینجور اسامی زیاد داشتم :
اسامی اختصاری که اختصاری منطقی داشتند ! مثلن :
chb - به عنوان نام تابعی که اگر قرار بود در جاوا باشه میشد : changeBook یا chu بجای changeUser
و کلن هرچیزی که با ch شروع میشد، قرار بود یه چیزی رو تغییر بده و ...

خب چرا اینکار رو میکردم؟
یا محیط توسعه ای که ازش استفاده میکردم قابلیت بسیار ارزشمند code completion رو نداشت یا من ازش بی اطلاع بودم و اگر قرار بود از نامهای طولانی استفاده میکردم یا باید مرتب به copy/paste رو میآوردم یا باید تایپ میکردم .برای پروژه ای که دور و بر1500 خط بود و حداقل نصفش کاملن متمایز بود، ممکن بود کار طاقتفرسایی باشه
(البته من جلو اعلان هر متغیر خطوط توضیحات بکار میبردم)

و اینطور نامگزاریها هنوز که هنوزه هم در خانواده ی C متداول هست !

JaguarXF

جمعه 03 اردیبهشت 1389, 07:19 صبح

java
http://java.sun.com/docs/codeconv/CodeConventions.pdf

.net
http://msdn.microsoft.com/en-us/library/czefa0ke(v=VS.71).aspx

seriously? really ?

javanerd

جمعه 03 اردیبهشت 1389, 15:16 عصر

ببینید یادم میاد یه زمانی یه پروژه ای با ++C نوشته بودم و از اینجور اسامی زیاد داشتم :
اسامی اختصاری که اختصاری منطقی داشتند ! مثلن :
chb - به عنوان نام تابعی که اگر قرار بود در جاوا باشه میشد : changeBook یا chu بجای changeUser
و کلن هرچیزی که با ch شروع میشد، قرار بود یه چیزی رو تغییر بده و ...

خب چرا اینکار رو میکردم؟
یا محیط توسعه ای که ازش استفاده میکردم قابلیت بسیار ارزشمند code completion رو نداشت یا من ازش بی اطلاع بودم و اگر قرار بود از نامهای طولانی استفاده میکردم یا باید مرتب به copy/paste رو میآوردم یا باید تایپ میکردم .برای پروژه ای که دور و بر1500 خط بود و حداقل نصفش کاملن متمایز بود، ممکن بود کار طاقتفرسایی باشه
(البته من جلو اعلان هر متغیر خطوط توضیحات بکار میبردم)

و اینطور نامگزاریها هنوز که هنوزه هم در خانواده ی C متداول هست !

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

نحوه‌ی مختصر کردن نام‌ها قانون‌مند باشه و همه‌ی افراد درگیر در برنامه این قوانین رو بدونند (و رعایت کنند).

در صورتی که نام‌های اختصاری جا افتاده باشند (مثل http به جای Hyper Text Transfer Protocol)

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

در صورتی که مختصر سازی واقعا به صرفه باشه. یعنی مختصر کردن نام‌ها منجر به این نشه که فقط یک یا دو حرف از طولشون کاسته بشه (طرف باید خیلی عجله داشته باشه که بخواهد فقط یک یا دو حرف نام‌ها رو کوتاه‌تر کنه)

jeus

یک شنبه 19 اردیبهشت 1389, 14:11 عصر

دوستان از توضیحات شما عزیزان ممنونم اما نکته دیگر اینجاست که من گاهی اوقات نامگذاری هایی اینگونه را پیشنهاد می کنم و اونه هم زمانی است که خودتان بخواهید کودهایتان را Obfuscate کنید مثلا یکی از برنامه هایی که من نوشتم از این روش نامگذاری استفاده کرده ام a____ این اسم یکی از متغییرامه و a___ هم اسم یکی دیگشه
و کل متغییر ها و کلاسها و نمونه های گرفته شده از کلاسهای من همینجوری نامگذاری شدن جوری که اگر خودم هم بخواهم بفهمم چه کردم 2 ساعتی طول میکشه و دیگر متغییر های من .

l____l
l_____l
l___l
I____I
L____l
l_____ البته این یکی از ترفندهایی است که من برای obfuscate کردن برنامه هام استفاده می کنم .
موفق باشید .

javaphantom

چهارشنبه 22 اردیبهشت 1389, 12:22 عصر

از این بحث خوشم اومد

به نظر من برنامه نویس یا به اعبارتی Developer کسی هست که باید یک مباحث مربوط به Clean Code و بعد از او Test بلد باشه بنویسه. در غیر این صورت توهم داره که developer هست.

برای اینکه بیشتر وارد بحث بشیم در مورد این دو قسمت دوست دارم بیشتر بحث بشه

javanerd

یک شنبه 26 اردیبهشت 1389, 15:26 عصر

javanerd

یک شنبه 26 اردیبهشت 1389, 16:33 عصر

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

void saveWeight(){
weight = 150; // 150 kilo gram
wait = false;
answer = computeAnswer(weight);
if (answer == rightAnswer){
if (writeAnswer){
writeAnswerToFile();
} else if (answer == wrongAnswer){
showErrorMessage();
}
} else {
if (wait) {
answer= reCompute(weight);
}
}
...
اگر شما بخواهید در مورد این کد با یک برنامه‌نویس دیگر صحبت کنید باید کلی از وقت خودتان را صرف این موضوع کنید که وقتی می‌گویید متغیر «ویت» چه کاری انجام می دهد منظورتان weight است یا wait؟ دقت کنید که psychological distance این دو متغیر آنقدر زیاد هست که هیچکس موقع نگاه کردن به کد آن‌ها را با هم اشتباه نمی‌گیرد، ولی وقتی یک نفر کلمه‌ی «ویت» را می‌شنود نمی‌تواند تشخیص ده که منظور شما کدام‌یک از این دو متغیر است. این موضوع در مورد متغیرهای writeAnswer و rightAnswer هم صدق می کند.
نوشتن برنامه کار پیچیده‌ای است و نیاز به تمرکز دارد. اگر هر چند خط یک‌بار تمرکز شما به خاطر اینکه می‌خواهید مطمئن شوید مخاطبتان متوجه منظور شما شده است یا خیر، به هم بخورد بازدهی شما بسیار پایین می‌آید. (فکر کنم توی پست‌های قبلی توضیح داده‌ام که چرا اگر هر بیست دقیقه یکبار تمرکز برنامه‌نویس به هم بخورد بازدهی‌اش به صفر می‌رسد.)

اگر دوست دارید بیشتر در مورد تست تلفن بدانید به کتاب The Elements of Programming Style نوشته‌ی Brian W. Kernighan و P. J. Plauger مراجعه کنید. البته اگر سوالی داشتید در خدمت هستم.

jlover

یک شنبه 26 اردیبهشت 1389, 21:46 عصر

...
...
(فکر کنم توی پست‌های قبلی توضیح داده‌ام که چرا اگر هر بیست دقیقه یکبار تمرکز برنامه‌نویس به هم بخورد بازدهی‌اش به صفر می‌رسد.)
...
البته اگر سوالی داشتید در خدمت هستم.
درود دوست عزیز
ظاهرا در اینباره قبلا نفرمودید، میتونه شنیدنی باشه ...

یه مسئله ای هم مربوط به پستهای قبلیتون (حالا که این بحث دوباره باز شد):

* شما با ذکر دلایلی بسیار منطقی نشون دادین که _بطور مثال در یک سری حلقه ی تودرتو_ استفاده از متغیرهایی با نامهای rowIndex و colIndex بجای i و j ، چقدر میتونه مفید باشه و حتی گاهی اوقات واجب !
خب گاهی اوقات حلقه های تو درتو توی پرشماری ممکنه داشته باشیم (مثلا چهار تا یا بیشتر!) و استفاده از نامهای تک حرفی میتونه به خوانا تر شدن قسمتهای درون بدنه ی حلقه کمک کنه...
من واقعا فکر میکنم تو بعضی حلقه ها که ساختارهای پیچیده ای رو پیاده سازی میکنند (یعنی بسادگی پیمایش در یک سطر و ستون نیستند!) حتی پیدا کردن یک نام مناسب غیر تک حرفی کار دشواری هم میتونه باشه و تازه یک دفعه ای میبینیم خود جمله ی قبل از شروع بدنه در یک حلقه ی for اونچنان طولانی میشه که ممکنه خواننده درش غرق بشه! یعنی اصل منطقی که در بدنه پیاده میشه تحت الشعاع قرار بگیره
مثلا در این مورد اگه قصد رسوندن شیوه ی محاسبه ی درون حلقه رو به مخاطب داشته باشیم، میشه از همون نامهای اختصاری استفاده کرد و در ابتدای حلقه توضیحی واضح در مورد شیوه ی انجام محاسبات درون اون حلقه قرار داد

در نهایت هم یک مسئله ی کلی در این خصوص ذهن منو به خودش مشغول داشته:
اگه قرار نیست که کدها جایی ارایه بشه، واقعا فرصتی که برنامه نویس صرف انتخاب نامهای مناسب میکنه به مراتب هزینه برتر هست !
(به نظر من)
با تشکر

javanerd

سه شنبه 28 اردیبهشت 1389, 14:29 عصر

درود دوست عزیز
ظاهرا در اینباره قبلا نفرمودید، میتونه شنیدنی باشه ...

یه مسئله ای هم مربوط به پستهای قبلیتون (حالا که این بحث دوباره باز شد):

* شما با ذکر دلایلی بسیار منطقی نشون دادین که _بطور مثال در یک سری حلقه ی تودرتو_ استفاده از متغیرهایی با نامهای rowIndex و colIndex بجای i و j ، چقدر میتونه مفید باشه و حتی گاهی اوقات واجب !
خب گاهی اوقات حلقه های تو درتو توی پرشماری ممکنه داشته باشیم (مثلا چهار تا یا بیشتر!) و استفاده از نامهای تک حرفی میتونه به خوانا تر شدن قسمتهای درون بدنه ی حلقه کمک کنه...
من واقعا فکر میکنم تو بعضی حلقه ها که ساختارهای پیچیده ای رو پیاده سازی میکنند (یعنی بسادگی پیمایش در یک سطر و ستون نیستند!) حتی پیدا کردن یک نام مناسب غیر تک حرفی کار دشواری هم میتونه باشه و تازه یک دفعه ای میبینیم خود جمله ی قبل از شروع بدنه در یک حلقه ی for اونچنان طولانی میشه که ممکنه خواننده درش غرق بشه! یعنی اصل منطقی که در بدنه پیاده میشه تحت الشعاع قرار بگیره
مثلا در این مورد اگه قصد رسوندن شیوه ی محاسبه ی درون حلقه رو به مخاطب داشته باشیم، میشه از همون نامهای اختصاری استفاده کرد و در ابتدای حلقه توضیحی واضح در مورد شیوه ی انجام محاسبات درون اون حلقه قرار داد

در نهایت هم یک مسئله ی کلی در این خصوص ذهن منو به خودش مشغول داشته:
اگه قرار نیست که کدها جایی ارایه بشه، واقعا فرصتی که برنامه نویس صرف انتخاب نامهای مناسب میکنه به مراتب هزینه برتر هست !
(به نظر من)
با تشکر

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

در مورد سوالی که پرسیده بودید من احساس می‌کنم مشکل جای دیگه‌ای هست. قول می‌دهم توی یک پست جدا در موردش بیشتر توضیح بدهم. ولی فعلا به نظر من (که ممکنه کاملا اشتباه باشه) مشکل اینه که تعداد حلقه‌های تو در تو زیاد شده. من شخصا پیشنهاد می‌دهم که هیچ‌وقت اجازه ندهید که تعداد حلقه‌های تو در تو در یک برنامه از دو (چون شما هستید از سه) بیشتر بشه (مگر اینکه دلیلی دارید که کد رو ساده‌تر می‌کنه). هرجا که تعداد حلقه‌های تو در تو زیاد شد بهتر که با یک refactoring حلقه‌های داخلی‌تر رو به تابع‌های جدید منتقل کرد.

باز روی یک نکته تاکید می‌کنم. نوشتن برنامه‌های کامپیوتری کار پیچیده‌ای هست. هدف انجام دادن کارهایی هست که تا حد ممکن به این پیچیدگی چیزهای جدیدی اضافه نکند.

jlover

سه شنبه 28 اردیبهشت 1389, 15:34 عصر

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

در مورد سوالی که پرسیده بودید من احساس می‌کنم مشکل جای دیگه‌ای هست. قول می‌دهم توی یک پست جدا در موردش بیشتر توضیح بدهم. ولی فعلا به نظر من (که ممکنه کاملا اشتباه باشه) مشکل اینه که تعداد حلقه‌های تو در تو زیاد شده. من شخصا پیشنهاد می‌دهم که هیچ‌وقت اجازه ندهید که تعداد حلقه‌های تو در تو در یک برنامه از دو (چون شما هستید از سه) بیشتر بشه (مگر اینکه دلیلی دارید که کد رو ساده‌تر می‌کنه). هرجا که تعداد حلقه‌های تو در تو زیاد شد بهتر که با یک refactoring حلقه‌های داخلی‌تر رو به تابع‌های جدید منتقل کرد.

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

پیچیدگی بیشتر کد منبع == بازدهی بیشتر / خوانایی کمتر کد منبع
پیچیدگی کمتر کد منبع == بازدهی کمتر / خوانایی بیشتر کد منبع

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

با تشکر

javanerd

شنبه 01 خرداد 1389, 18:00 عصر

فشارهایی روانی که هنگام حل کردن یک مساله (دشوار) به یک برنامه‌‌نویس وارد می‌شود.
قبل ازاین‌که به این موضوع بپردازم، لازم است که یک مقدمه کوتاه بیان کنم. این مقدمه خیلی جذاب و در عین حال ساده و سرراست است. علیرغم این سادگی کاربرهای بسیار فراوانی در زندگی روزمره دارد. اجازه دهید با چند مثال جالب از زندگی روزمره شروع کنیم تا سر فرصت به دنیای برنامه‌نویس‌ها برسیم.
مثال 1
شما که فردی مجرد هستید و به دنبال یک شریک (برای زندگی) می‌گردید. در یک مهمانی، جلسه، یا هر جای دیگری با دو دخترکه با هم دوست هستند آشنا می‌شوید. یکی از دخترها یک دختر معمولی است. دختر دوم یک دختر فوق‌العاده است که هر فردی در زندگی آرزو دارد با او هم‌صحبت و دوست شود. بعد از مهمانی تصمیم می‌گیرید که یکی از این دو نفر را انتخاب کنید و به او پیشنهاد بدهید. کدام یک را انتخاب می‌کنید؟ واقعیت این است که بیشتر افراد (درصد خیلی بالایی) دختر رویایی را کنار می‌گذارند و سراغ دختر معمولی می‌روند. (تعجب نکنید، این اتفاقی است که در واقعیت رخ می‌دهد، با این وجود که کاملا احمقانه است).
مثال 2
از دو گروه پنجاه نفره از زنان که همه مخالف به کار بردن خشونت علیه زنان هستند می‌خواهند که هر کدام یک انشا بنویسند و در آن توضیح دهند که به کاربردن خشونت علیه زنان چه آثار مثبتی می‌تواند برای افراد و جامعه داشته باشد. به هر یک از اعضای گروه اول مبلغ هزار تومان و به هریک از اعضای گروه دوم مبلغ صدهزار تومان به عنوان دست‌مزد پرداخت می‌شود. اعضای کدام‌یک از این دو گروه انشاهای بهتری می‌نویسند؟ شاید باور نکنید ولی افرادی که پول کمتری می‌گیرند به مراتب انشاهای بهتری می‌نویسند.‌
مثال 3
سایر برنامه‌نویس‌ها معمولا با برنامه‌نویس‌هایی که در تیم تست کار می‌کنند مشکل دارند. سایر برنامه‌نویس‌ها صرف نظر از اینکه افراد گروه تست چه شخصیتی دارند، آن‌ها را جز دوستان صمیمی خود به حساب نمی‌آورند، با هم غذا نمی‌خورند، با هم بیرون نمی‌روند و ... (شاید این یک مورد را سر کار احساس کرده باشید)
مثال 4
کدی که یک برنامه‌نویس نوشته‌است دارای یک اشکال است. وقتی که همکار او اشکال را پیدا می‌کند و به او گوشزد می‌کند برنامه‌نویس بلافاصله جواب می‌دهد که دیشب دیروقت این کد را نوشته است و موقع نوشتن کد خواب‌آلود بوده است (یا یک بهانه‌ی مشابه می‌آورد). دلیل این رفتارها را به صورت خیلی خلاصه می‌توان توضیح داد.
دلیل این پدیده‌ها و پدیده‌های مشابه دیگر را می‌توان با تئوری ساده‌ی زیر توضیح داد.
هر انسانی تصوری از خود دارد که در آن خود را یک انسان کامل می بینید. در این تصور هر کس خود را مهربان، قوی، باهوش، زیرک، سیاستمدار و ... تصور می‌کند. به طور کلی در این تصور هر شخصی تمام ویژگی‌ها و صفت‌های مثبت را به خود نسبت می‌دهد.
اما در دنیای واقعی گاهی انسان‌ها درشرایطی قرار می‌گیرند که این تصویر خدشه‌دار می‌شود. برای مثال پدری که خود را فرد مهربان و دلسوزی تصور می‌کند بچه‌اش را کتک می‌زند، یا ورزشکار که خود را قوی تصور می‌کند در یک مسابقه شکست می‌خورد، یا برنامه‌نویسی که خود را باهوش تصور می‌کند نمی‌تواند یک مساله را حل کند. در این صورت فردی که این شرایط قرار گرفته است دچار احساس ناراحتی می‌شود. برای اینکه فرد از این احساس ناراحتی رهایی پیدا کند دو راه حل وجود دارد. راه حل اول این است که تصوری که به یک انسان تمام و عیار از خود دارد را کنار بگذارد و بپذیرد که پدری نامهربان، حریفی ضعیف، برنامه‌نویسی کندذهن و یا ... است. البته اکثر افراد این کار را نمی‌کنند.
راه حل دوم این است که فرد واقعیت را تحریف کند و خود را گول بزند طوری که دیگر با تصور کاملی که از خود دارد ناسازگار نباشد. در این حالت پدر واقعیت را تغییر می‌دهد طوری که در به خود این باور را بدهد که کتک زدن بچه کاری از روی سنگدلی نیست. ورزشکار واقعیت را طوری تغییر می‌دهد که شکست را به گردن چیزهای دیگر مانند شانس می‌اندازد و نه نالایق بودن خودش؛ و برنامه‌نویس نیز واقعیت را تغییر می‌دهد تا ناتوانی خود برای حل کردن مساله را گردن عوامل دیگر بیندازد و نه ناکارآمدی خودش.
اجازه دهید که مثال‌هایی که در ابتدای این نوشته آمده‌اند را یکبار دیگر با استفاده از این تئوری بررسی کنیم.
مثال 1
هر انسانی در تصوری که از خود دارد خود را فردی جذاب، گیرا، دوست‌داشتنی و ... تصور می‌کند. در این تصور فرد به هرکسی که پیشنهاد بدهد جواب رد نمی‌شنود. زیرا جواب رد شندیدن از یک فرد به این معنی است که در او عیبی وجود داشته که طرف مقابل دست رد به سینه‌ی او زده است. این تصور در دنیای واقعی برقرار نیست و احتمال آن وجود دارد که یک نفر در پاسخ به یک پیشنهاد برای دوستی جواب رد بشنود به خصوص اگر فردی که به از او درخواست دوستی می‌کند. برای اینکه فرد در این شرایط قرار نگیرد راه دوم را انتخاب می‌کند. یعنی اینکه واقعیت را اینطور تحریف می‌کند (فرض کنید x دختر جذاب و y دختر معمولی باشد): «من یک آدم جذاب هستم که هر کسی آرزو دارد با من هم‌صحبت و دوست شود. اولش به نظرم ط خیلی دختر خوبی است ولی الان که بهتر فکر می‌کنم میبینم که آنقدرها هم دختر خوبی نیست. ما زیاد به درد هم نمی‌خوریم. به نظرم y دختر خوبی است. بیشتر از x به من می‌خورد. راستش خیلی خیلی از x بهتر است»
مثال 2
هر فردی در تصوری که از خود دارد خود را یک فرد منطقی می‌بیند. یک فرد منطقی به نتایجی که منطقا به دست‌آورده است عمل می‌کند. با این حال فردی که در زندگی به این نتیجه رسیده است که به کار بردن خشونت علیه زنان کار درستی نیست و الان دارد یک انشا در این مورد می‌نویسد که کتک زدن زن‌ها چه نتایج خوبی می‌تواند داشته باشد در یک تناقض قرار می‌گیرد. برای خارک ج شدن از این تناقض باید واقعیت را تحریف کند. فردی که صدهزار تومان برای نوشتن انشا می‌گیرد خود را اینطور فریب می‌دهد: «من می‌دانم که کتک زدن زن‌ها کار درستی نیست. ولی الان دارم به خاطر پول این انشا را می‌نویسم. من همچنان مخالف سرسخت اعمال خشونت علیه زنان هستم و این فقط یک انشای صوری است.»
ولی فردی که فقط هزار تومان برای نوشتن انشا می‌گیرد نمی‌تواند پول را بهانه کند. این فرد خود را این‌طور فریب می‌دهد: «من مخالف اعمال خشونت علیه زنان هستم. ولی الان دارم یک انشا مخالف با عقیده‌ام می‌نویسم. راستش الان که دارم این انشا را می‌نویسم تازه می‌فهم که اعمال خشونت علیه زنان آن‌قدرها هم کار بدی نیست. حتی بعضی وقت‌ها این کار لازم است. بعضی از زن‌ها واقعا لیاقت چیزی جز کتک خوردن را ندارند.» (توجه کنید که همه‌ی این اتفاقات به صورت ناخودآگاه رخ می دهند).
مثال 3
هر برنامه‌نویس خود را باهوش می‌داند. اما وقتی که یک نفر دیگر یک اشکال در برنامه‌ای که او نوشته است پیدا می‌کند به جای قبول کردن این واقعیت که آنقدرها هم فرد باهوشی نیست، دست به تحریف واقعیت می‌زند. در این حالت واقعیت را برای خود اینطور تغییر می‌دهد: «من برنامه‌نویس باهوش و خبره‌ای هستم و برنامه‌هایی که می‌نویسم فاقد اشکال هستند. منتهای این فردی که در تیم تست کار می‌کند با من دشمنی دارد و فقط می‌خواهد من را جلوی بقیه همکار‌هایم کوچک کند. برای همین اشکال‌های بی‌خود و غیر مهم در کد من پیدا می‌کند. از سر دشمنی با من این کار را می‌کند.»
مثال 4
این بار برنامه‌نویس واقعیت را این‌طور تحریف می‌کند: «من برنامه نویس باهوش و کارکشته‌ای هستم. ولی دیروز که داشتم این کد را می‌نوشتم خیلی خواب‌آلود بودم. اگر خوابم نمی‌آمد حتما کدی می‌نوشتم که این اشکال را نداشت.»
برای اینکه این مشکل‌ها در بین برنامه ‌نویس‌ها به وجود باید همه‌ی این واقعیت را بپذیرند که «هیچ کس انسان کاملی نیست. هر برنامه‌نویسی اشتباه می‌کند (قطعا اشتباه می‌کند نه اینکه ممکن است اشتباه کند). این موضوع که یک برنامه‌نویس اشتباه می‌کند اصلا مهم نیست، بلکه موضوع مهم این است که وقتی اشتباه کرد جسارت لازم برای پذیرفتن آن و رفع کردن آن را داشته باشد.»

دوست دارم بازم بنویسم ولی فعلا وقت نیست. توی یک پست دیگه مفصلتر توضیح می‌دهم.

اگر دوست داشتید بیشتر در این مورد بدانید عبارت زیر را توی گوگل جست‌و‌جو کنید
Cognitive dissonance

javaphantom

یک شنبه 02 خرداد 1389, 02:01 صبح

فشارهایی روانی که هنگام حل کردن یک مساله (دشوار) به یک برنامه‌‌نویس وارد می‌شود.

فشار روانی به هنگام کار برای هر نوغ عشری از کار بوجود می آید ربطی به برنامه نویس نداره. اگر یک جراح بودم چه می کردم؟

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

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

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

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

کدی که یک برنامه‌نویس نوشته‌است دارای یک اشکال است. وقتی که همکار او اشکال را پیدا می‌کند و به او گوشزد می‌کند برنامه‌نویس بلافاصله جواب می‌دهد که دیشب دیروقت این کد را نوشته است و موقع نوشتن کد خواب‌آلود بوده است (یا یک بهانه‌ی مشابه می‌آورد). دلیل این رفتارها را به صورت خیلی خلاصه می‌توان توضیح داد.
دلیل این پدیده‌ها و پدیده‌های مشابه دیگر را می‌توان با تئوری ساده‌ی زیر توضیح داد.

در دنیای حرفه ای ها وقتی کدی توسط شخص یا گروی نوشته می شه و در یک مثلا ورژن کنترلی قرار میگیره، دیگه اون کد متعلق به اون شخص یا گروه نیست. بلکه متعلق به تمام افرادی هست که بعد بخواهند روی اون تغییر یا به عبارتی refactor کنند. امید وارم که قسمت بشه برای همه که بتونند روی یک پروژ open source کار کنند و ببینند که حرفه ای ها کد رو برای خودشون نمی نویسن و از اینکه روی کد هم تغییر بکنه ناراحت نمی شن.

صحبت از واقعیت کردی.

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

واقعیت چی هست؟ یک طاووس از روی زمین درخت رو قهویه ای می بینه ولی یک عقاب از بالا درخت رو سبز می بینه. هر دو واقعیت رو می بینند. مهم اینکه آدم ها بتونند علاوه بر دیدن واقعیت های خودشون، واقعیت های دیگران رو هم ببینند.

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

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

در هر صورت مرسی از نوشته هاتون خیلی برای من جذاب و خنده دار و پندآموز بود

javanerd

یک شنبه 02 خرداد 1389, 10:23 صبح

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

فشار روانی به هنگام کار برای هر نوغ عشری از کار بوجود می آید ربطی به برنامه نویس نداره. اگر یک جراح بودم چه می کردم؟

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

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

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

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

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

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

اینم از اون حرفها بود که من شنیدم. توی ایران کجا تست می نویسن که حالا بخواد یکسری افراد بخاطرش منزوی بشن.

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

بعدش این چه تیمی هست که یک سری می نویسن تست و یک سری نمی نویسن. تست نویسی دوستان من جزو واجبات هست مگر اینکه بخواهیم آشغال بجای محصول به مشتری بدهیم.

تست یک نرم‌افزار توی سطح‌های مختلفی انجام مشه. توی اولین سطح همه‌ی برنامه‌نویس‌ها باید کدی که می‌نویسند رو تست unit کنند وگرنه همون طور که شما گفتید به جای محصول آشغال تحویل می‌دهند. ولی فقط unit testing کافی نیست. بخش‌های مختلفی که توسط برنامه‌نویس‌های مختلف نوشته می‌شوند باید integrate بشن. اینجا دیگه یک تیم مشخص باید مسئول انجام integration test باشه. سایر تست‌ها مثل usability test و stress test و security test و ... هم همین طور (حتی اگر توی ایران و 90 درصد از شرکت‌های دنیا انجام نشوند).

در دنیای حرفه ای ها وقتی کدی توسط شخص یا گروی نوشته می شه و در یک مثلا ورژن کنترلی قرار میگیره، دیگه اون کد متعلق به اون شخص یا گروه نیست. بلکه متعلق به تمام افرادی هست که بعد بخواهند روی اون تغییر یا به عبارتی refactor کنند. امید وارم که قسمت بشه برای همه که بتونند روی یک پروژ open source کار کنند و ببینند که حرفه ای ها کد رو برای خودشون نمی نویسن و از اینکه روی کد هم تغییر بکنه ناراحت نمی شن.

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

صحبت از واقعیت کردی.

واقعیت چی هست؟ یک طاووس از روی زمین درخت رو قهویه ای می بینه ولی یک عقاب از بالا درخت رو سبز می بینه. هر دو واقعیت رو می بینند. مهم اینکه آدم ها بتونند علاوه بر دیدن واقعیت های خودشون، واقعیت های دیگران رو هم ببینند.

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

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

در هر صورت مرسی از نوشته هاتون خیلی برای من جذاب و خنده دار و پندآموز بود

به هر حال این نوشته‌ها حرف‌های من نیست. من این‌ها رو توی کتاب
The Social Animal (نوشته‌ی Elliot Aronson) و کتاب The Psychology of Computer Programming (نوشته‌ی Gerald M. Weinberg) خونده بودم.