بایگانی برچسب: s

زور خوابیده در جلسات فنی

چند وقتی هست درگیر چندتا تیم هستم که از نظر فنی بهشون اوکی بدم برای پروژه های مختلف و از این بابت  گروهها یا اشخاصی که خودشون ما رو پیدا میکنند یا ما اونها رو پیدا میکنیم بایستی پروپوزال بدن و از بعد فنی ارزیابی بشن.

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

داستان از کجا شروع میشه؟

ما دنبال تیمی هستیم که برروی فناوری یا تکنیک اکس کار کرده باشه از طرفی من بعنوان مشاور فنی تو همون زمینه هم کار کردم ولی بنا به دلایلی نمیتونم کل پروژه رو انجام بدم پس باید کار برونسپاری بشه و من مشاوره بدم و ارزیابی کنم.

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

حالا نوبت منه که دونه دونه از ریز کار اعم از اینکه با فلان مدل برنامه نویسی یا فلان الگو طراحی کار کردن و … بپرسم تا جایی که دقیق بشم تو فناوری اکس دقیقاً اینجاست که خیلی از مجریان فنی نمیخوان جواب بدن ۲ دلیل داره معمولاً :

۱-دلیل اول : اینطور سوالات فنی مجری رو به این فکر وا میداره که نکنه ما کار رو بلد نیسیتم یا اصلاً نمیدونم و میخواهیم اونها رو تخلیه اطلاعاتی بکنیم.

۲-به غایت مرز بلد بودن تیم فنی رسیدیم و بیشتر از این دیگه جواب نمیده!

در مورد اول : معمولاً کارهایی که بیش از یکبار در دنیا توسط بیش از یک تیم انجام شده باشه دست یافتن بهشون خیلی سخت نیست پس همونطوری که شما بهش دسترسی پیدا کردی(در بیشتر مواقع) ما هم میتونیم بهش دسترسی پیدا کنیم حالا با کمی جستجو بیشتر یا کمتر پس وقتی وارد یک جلسه ارزیابی فنی شدید اصلاً به این نکته فکر نکنید که قراره تخلیه اطلاعاتی بشید کما اینکه  از نوع سوالاتی که قراره پرسیده بشه کاملاً مشخص میشه که در کدوم جهت جلسه در حال حرکته. و وفتی شما امتناع میکنید یا طفره میرید از جواب دادن دقیق به سوالات وارد فاز “زور خوابیده زدن” میشید و طبعاً جزو آخرین کسانی خواهید بود که شاید بشه با اونها کار کرد که معمولاً هم این اتفاق نمیفته.

در مورد دوم : این دسته دوباره به دو دسته تقسیم میشه دسته اول آدمای خوبی هستن و مثلاً میگن روی این موضوع کار نکردیم یا خیلی ساده نمیدونم در واقع راه حل صادقانه رو پیش میگیرن که اتفاقاْ خیلی هم خوبه و جواب میده و امکان همکاری هنوز با این دسته وجود داره.

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

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

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

از کلاسهای concrete (پایین دست) برای پاس دادن پارامتر استفاده نکنید!

یکی از بدیهات برنامه نویسی شی گرا پاس دادن یک نوع کلاس بین کلاس ها میباشد که معمولاً دیده میشه برنامه نویسان بدون آینده نگری کلاسی که نیاز دارند رو دقیقاً همون رو پاس میدهند برای روشنتر شدن قضیه به شبه کد زیر توجه کنید :

class TestActivity extends Activity { ……..}

class Test {

public Test(TestActivity ta){}

}

در اینجا کلاس Test بعنوان مصرف کننده کلاس TestActivity فقط و فقط میتواند کلاس TestActivity را بعنوان ورودی بگیرد، حال میتوان حالتی را در نظر گرفت که کلاس Test میخواهد کارآیی خود را افرایش داده و همه نوع کلاسهایی که از جنس Activity هستند را در بر بگیرد در این حالت باید دست به جراحی عمده در کلاس Test بزنیم و هرکجا از TestActivity استفاده برده ایم آنرا تغییر به کلاس بالاتر خود یعنی Activity دهیم.

این کار شاید در برخی مواقعی بعنوان technical debt قابل قبول باشد اما بصورت کلی این نوع کار کرد به هیچ عنوان حتی بصورت چابک (در این حالت بخوانید عجله ایی) هم توصیه نمیشود و حتماً باید از کلاس بالاتر و یا interface مخصوص به کلاس استفاده برد.

مثال دنیای واقعی :

 

import java.util.Calendar;
import java.util.Date;
import java.util.HashMap;
import java.util.Map;

import android.widget.TextView;

import com.github.praytimes.Clock;
import com.github.praytimes.Coordinate;
import com.github.praytimes.PrayTime;
import com.github.praytimes.PrayTimesCalculator;

import cal.Main_Calendar;

/**
* Pray time helper. It is like an aspect for activity class somehow
*
* @author ebraminio
*/
public class PrayTimeActivityHelper {
private final Utils utils;

private final Main_Calendar calendarActivity;
private Date date = new Date();
private final TextView prayTimeTextView;

public PrayTimeActivityHelper(Main_Calendar calendarActivity) {
this.calendarActivity = calendarActivity;
this.utils = calendarActivity.utils;
prayTimeTextView = (TextView) calendarActivity
.findViewById(R.id.today_praytimes);
}

public void setDate(int year, int month, int dayOfMonth) {
Calendar c = Calendar.getInstance();
c.set(year, month, dayOfMonth);
date = c.getTime();
}

public static Map<PrayTime,Clock> prayTimeClockMap = new HashMap<PrayTime, Clock>();
public String getPrayTime(PrayTime pt)
{
Coordinate coord = utils.getCoordinate(calendarActivity);
PrayTimesCalculator ptc = new PrayTimesCalculator(
utils.getCalculationMethod(calendarActivity));
Map<PrayTime, Clock> prayTimes = ptc.calculate(date, coord);
prayTimeClockMap = prayTimes;
char[] digits = utils.preferredDigits(calendarActivity);
switch (pt)
{
case Imsak:
return utils.clockToString(prayTimes.get(PrayTime.Imsak), digits);
case Sunrise:
return utils.clockToString(prayTimes.get(PrayTime.Sunrise), digits);
case Dhuhr:
return utils.clockToString(prayTimes.get(PrayTime.Dhuhr), digits);
case Sunset:
return utils.clockToString(prayTimes.get(PrayTime.Sunset), digits);
case Maghrib:
return utils.clockToString(prayTimes.get(PrayTime.Maghrib), digits);
case Midnight:
return utils.clockToString(prayTimes.get(PrayTime.Midnight), digits);
default:
return “”;
}
}

منبع  سورس بالا :

https://github.com/ebraminio/DroidPersianCalendar/blob/master/PersianCalendar/src/main/java/com/byagowi/persiancalendar/PrayTimeActivityHelper.java

(خدایا چقدر باید refactor کرد حتی کدهای خوب رو!!!)

هنر تنبلی یا چطور یاد بگیریم اول کار رو انجام بدیم!

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

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

اما تو همه این رفت و آمدها و تعامل با انسانهای متفاوت تجربه خیلی متفاوتی رو همین هفته گذشته شاهد بودم، تو دوره فشرده آموزشی که برای یک شرکت تولید نرم افزار داشتم، شاهد این بودم که پروژه های متوسط رو به بزرگی را با رویکرد بزن در رو به جلو سوق داده بودن و بدون اینکه فکر کنن میتونن یک شالوده(framework) مشترک بین چند ده پروژه خودشون داشته باشن و دقیقاً از کانسپتهایی استفاده میکنند که Robert C. Martin در کتاب Clean Code خودش بعضاً اونها رو به توسعه گرها توصیه میکنه مثل استفاده از امکانات IDE (به دلیل رعایت اخلاق حرفه ایی قصد شرح تکنیکهاشون رو ندارم).

جالبه همین شرکت با همین نگاه پیش پا افتاده به مهندسی نرم افزار یا بهتره بگیم تولید نرم افزار موفق به جذب بالای هزار مشتری برای خودش در طول زمانی کمتر از ۵ سال شده و این دقیقاً اون چیزیه که Jeff Atwood هم به اون اشاره داره، یعنی هنر انجام یک کار و این یعنی اثبات حرف Robert Martin در عمل یعنی استفاده از ابزار موجود برای پیشبرد کار.

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

یادم میاد سال اول دانشگاه تو هندوستان سر درس برنامه نویسی سیستم و الکترونیک وقتی استاد تمرین میداد، فارغ از هرگونه تفکر به محدودیتهای استفاده از رجیسترها، و اینکه مصرف برق هم میتونه یک فاکتور مهم در صنایع باشه برنامه مینوشتم  و اتفاقاً با کمترین اتلاف وقت برنامه رو تحویل میدادم، اما به مرور زمان که دید وسیعتری نسبت به نرم افزار پیدا کردم زمان تفکرم بیشتر از زمان کد نویسیم بوده و این یعنی خروجی کمتر!

نتیجه اخلاقی

با توجه به تعداد شرکتهایی که از نرم افزار شرکت مذکور در حال استفاده هستند به جدّ میتونم به این نتیجه برسم که OOP یا FP فاکتورهای مناسبی برای استاندارد کد زدن نیستن، اگر به فاکتور رضایت مشتری توجه بیشتری بکنیم شاید به این نتیجه برسیم که مشتری راضی به اسپاگتی کدی هست که کار کنه و نه کلاسهای پیچیده ایی که هر روز یک باگ جدید در اونها کشف بشه!

من به انجام اولیه کار به هر روشی، میگم تنبلی و باهوش بازی درنیاوردن بابت انجام کار، که این خودش یه هنره!

سوالات بی جواب

آیا میتوان آینده ایی ورای OOP ،FP و یا MDA برای صنعت نرم افزار متصور بود که در اون مسائل حول محور دامنه بیزنس حل بشوند و نه حول محور مهندسی نرم افزار؟(DDD هم براساس OOP هست آیا رویکرد جدیدتری وجود داره؟)

آیا ۴GL مبحثی نبود که صنعت نرم افزار میبایست طی میکرد و آنرا به حد اعلای خود میرساند؟

آبا فریم ورکهایی مانند RoR مسکنهای موضعی برای درد مشتری مداری هستند؟ و وقت آنها هم به سر خواهد آمد؟

————————– آپدیت————————–

آفتاب آمد دلیل آفتاب، همین الان مصاحبه STLPORT با A. Stepanov مخترع STL رو خوندم که اتفاقاً ایشون با اینکه خودش STL رو برروی C plus plus پیاده کرده خودش مخالف OOP هست و از نظر درستی اون رو رد کرده.

http://www.stlport.org/resources/StepanovUSA.html