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

[Programmer 1]

سلام به همه دوستان،

واقعا سر در گم شدم وظیفه یک برنامه نویس دات نت در ایران چیه؟ باید چه مباحثی رو یاد داشته باشه؟

طرف نوشته مسلط به C#‎‎‎, SQL Server و مسلط به دات نت.

آیا یک فرد مسلط به سی شارپ باید با همه مباحث زیر آشنا باشه:

دات نت فریم ورک به صورت کامل تا سطح بررسی کد IL اسمبلی ها و کالبد شکافی فایل های PE
Socket Programming
Ado.net
Linq
Entity Framework
NHibernate
Wpf
Wcf
Crystal report
.Net Security
Xml Serialization
Registry Managment
Graphic 2D & 3D in some case
آشنایی با امکانات مختلف IDE به عنوان مثال Dotfuscator و ...
و خیلی از موارد دیگه


حالا همه اینها به کنار، به عنوان یک برنامه نویس باید آیا اینها رو هم بلد باشیم؟
مباحث مهندسی نرم افزار مثل:
آشنایی با مباحث تست نرم افزار مشابه تست آزمایش واحد، آزمایش جامعیت و ...
روش نسخه گذاری برنامه.
روش مدیریت فایل های پروژه
آشنایی با نرم افزارهای کنترل نسخه شبیه subversion
آشنایی با متد های Agile مثلا اسکرام در توسعه کار به صورت تیمی
آشنایی با مباحث مدیریت پروژه برای برنامه نویسان
آشنایی با Design Pattern ها
آشنایی با معماری نرم افزار
استانداردهای کد نویسی
آشنایی با مباحث طراحی واسط کاربری (و جدیدا تجربه کاربری یا UX)
و هزار و یک چیز دیگه.

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

واقعا نمیشه استاندارد کد نویسی رو رعایت نکرد و گفت کد من مرتبه.
واقعا نمیشه گفت بدون آشنایی با الگوهای طراحی برنامه نوشتن ، از شی گرایی استفاده میکنیم.
واقعا نمیشه بدون آشنایی با اصول طراحی تجربه کاربری، کار چشم گیری ارائه داد.
بدون wpf نمیشه بعضی زیبایی سازیها رو انجام داد.
بدون unit testing گسترش برنامه و تغییر های احتمالی آینده خیلی ریسک زیادی داره و با کوچکترین تغییر کلی ممکنه مشکل به وجود بیاد که نتونیم حتی ظرف ماه ها مشکل رو پیدا کنیم.
بدون استفاده از نرم افزارهای کنترل نسخه ، ممکنه کل اطلاعاتمون بپره!
بدون آشنایی با مباحث مدیریتی نمی تونیم پروژه امون رو به خوبی مدیریت کنیم و یا در تیم کار کنیم.
بدون آشنایی با Entity Framework و یا ado.net نمی تونیم برنامه های پایگاه داده ی کارا و پربازدهی بنویسیم.

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

حالا واقعا چه جوری به خودمون جرات بدیم که با دونستن یک ado.net ناقص و آشنایی سطحی با entity framework و چند تا متد و کلاس سوکت پروگرمینگ و کمی هم استفاده از اصول نامگذاری لهستانی و استفاده نیمه و ناقص از یک کنترل نسخه و ... خودمون رو یک برنامه نویس دات نت حرفه ای و مسلط خطاب کنیم.

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

ما باید به چی قانع باشیم؟ چی یاد بگیریم؟ و وظیفه اصلی ما به عنوان یک برنامه نویس چیه؟

دوستان با تجربه ، پاسخ های شما واقعا دلگرم کننده خواهد بود. (پاسخ هایی که واقعا در خور قانع کردن دغدغه های این تاپیک باشه).

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

با سپاس/.

[Arash_janusV3]

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

[JaVa]

من پست اول رو که خوندم آسمون تو سرم خراب شد.

تموم شد رفت

[veniz2008]

سلام.
منم اگر لیستی رو که تو تهیه کردی جلو خودم بذارم وحشت میکنم. قرار نیست توی همه این مسائل تسلط داشته باشی. وقتی وارد بازار کار میشی شما فقط بخشی از چرخه تولید نرم افزار میشی نه همه کاره. همونطور که آرش عزیز هم اشاره کرد در حد آشنایی با مفاهیم کافیه ولی در یک یا دو مورد باید تسلط داشته باشید. الان خیلی ها فقط کارشون تحلیل کردن سیستم هاست. خیلی ها میخندن و میگن مگه تحلیل سیستم کاری داره. طرف ماهی چند میلیون میگیره و فقط متخصص sql server هست. بهترین کار اینه که اول علاقه خودتون رو بسنجید که به چه مبحثی علاقه دارید و تمرکزتون رو بیشتر بر روی اون بذارید و با یک برنامه ریزی دقیق شروع به مطالعه کنید. به شدت از این پرهیز کنید که یه لیست بلندبالا بذارید جلو چشتون و هر روز بگید این مبحث جدید رو کار کنم. پراکندگی به نفع یک برنامه نویس نیست. سنتون هم که 26 ساله و هنوز جوونی. امروز اگه شروع کنی 1 سال دیگه میتونی همینجا یه تاپیک دیگه بزنی و از موفقیتت بگی.
موفق باشی دوست من.

[FastCode]

بعضیهاشون مهم نیست Entity Framework NHibernate Wpf Wcf Crystal report بقیشون رو باید کامل بلد باشی

[behrozi.ir]

بعضیهاشون مهم نیست Entity Framework NHibernate Wpf Wcf Crystal report بقیشون رو باید کامل بلد باشی

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




بهروزی | بهزاد

[Programmer 1]

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

کتابی در زمینه سی شارپ مطالعه می کنم ، فصل اولش در مورد چارچوب دات نته، خب، من وقتی مطالعه میکنم معمولا به صورت موازی از اینترنت هم کمک میگیریم ، مثلا جاهایی از مفاهیم دات نت فریم ورک رو که متوجه نمیشم رجوع میکنم به اینترنت و در اون زمینه مطالعه بیشتری میکنم ، مثلا فرض کنید که کتاب مورد مطالعه در مورد تبدیل کد به کد IL توضیح داده شده و توضیح بیشتری در مورد کدهای IL و ساختار فایل های pe تولیدی داده نشده، من رجوع میکنم به اینترنت بعد از کلی این طرف و اون طرف رفتن به کتاب Clr Via C#‎ برخورد می کنم ، و می بینم که در مورد دات نت با عمق خیلی بیشتری داره توضیح میده ، حالا به خودم می گم که تا زمانی که چارچوب دات نت رو خوب متوجه نشدم ادامه نمی دم پس به دست از مطالعه کتاب قبلی بر می دارم و می آم سراغ این کتاب جدید.

یا مثلا وقتی دارم کد می نویسم ناگهان برام سوال پیش می آد که این اسلش های سه تایی به عنوان کامنت چیه؟ یه جستجویی میکنم تو اینترنت می بینیم که اینها xml documenating هستند، کد نویسی رو رها میکنم و می رم دنبال یاد گرفتن این موضوع ، در اثنای این یادگیری با نرم افزارهای تولید خودکار xml documenating برخورد می کنم میرم سراغ یاد گیری اسکریپت هاش.

حالا به هر دلیلی سر از سایت dotnettip در آوردم ، گذرم می خوره به unit testing و مقاله خوبی که در این باره نوشته شده، شروع میکنم به مطالعه این مقاله و درگیر تست آزمایش واحد می شم، رجوع میکنم به آمازون برای جستجوی یک کتاب با موضوع unit testing ، کتابی پیدا میکنم دانلودش می کنم شروع می کنم به مطالعه.

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

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

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

[FastCode]

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




بهروزی | بهزاد

ولی بدون EF هم میشه زندگی کرد.
بدون LInQ نمیشه.

[FastCode]

ولی بدون EF هم میشه زندگی کرد.
بدون LInQ نمیشه.

اون چند تا رو پشت سر هم انتخاب کردم.
خیلی های دیگشون هم هستن که احتمالا تا آخر عمرت هم استفاده نمیکنی.مثل registry.
نری همه رو یاد بگیری.بعد پس فردا بگی فلانی گفت.

در ضمن اگر این متن رو خودت نوشتی(کپی نکردی) اول باید انگلیسی یاد بگیری.من هنوز ندیدم کسی بدون انگلیسی واقعا برنامه نویس بشه.

[mze666]

خیلی از این چیزهایی که گفتید نیاز نیست (بعضی هاش رو اگه بلد بودید که چه بهتر، اما بعضی هاش اصلاً به درد نمیخوره)
شما برای ORM باید یک مورد خوب مثل Entity Framework (چون هم ORM خیلی خوبی هست و هم بازار کارش خوبه) رو یاد بگیرید.
برای برنامه های ویندوزی WPF رو یاد بگیرید (توجه کنید که WPF فقط زیبایی ظاهری نیستش، نکته مهم WPF بحث Data Binding فوق العادش هست) پس شما هم خیلی نمیخواد خودتو درگیر انیمیشن و سه بعدی و ... در WPF بکنی
برای برنامه های تحت وب ASP.NET MVC رو یاد بگیرید (چون ASP.NET Web Form در حال مرگ هستش و بر عکس MVC هر روز پیشرفته تر و بهتر میشه)
در مورد گزارش گیری در برنامه ها (هم وب و هم ویندوز) به جای Crystal Report از Stimulsoft Report (غیر رایگان) یا کتابخانه PdfReport (رایگان) آقای نصیری استفاده کنید

Socket Programming خوبه ولی کارایی چندانی نداره پس میتونید اصلاً سراغش نرید
WCF ، Registery، Crystal Report، 2D 3D Graphic ، Dotfuscator ، Net Security ، ADO.NET رو کلآً بزارید کنار و به هیچ وجه سمتشون نرید. این لینک هم نگاه کنید (بررسی فناوری ها از دیدگاه مرگ و زندگی)
آشنایی با IDE که خیلی کاری نداره و چند روزه میتونید کامل محیط رو یاد بگیرید

روش نسخه بندی نرم افزار آنچنان کارایی برای شما نداره ولی اگر اینطور فکر نمیکنید یاد گرفتنش هم اصلاً کار سختی نیست (کافیه اینجا رو بخونید)
استاندارد های کدنویسی هم به مرور یاد میگیرید و با نصب Resharper میتونید خیلی چیزها در این مورد یاد بگیرید شما فقط سعی کنید تا حد امکان کد رو ساده و خوانا بنویسید و اینکه از قواعد نام گذاری درستی استفاده کنید چون این موارد واقعاً مهم هستند
استفاده از یک کنترل نسخه مثل TFS یا Svn یا GIT خیلی خوبه حتی اگر تیمی کار نمیکنید (من خودم TFS رو ترجیح میدم)
Agile و کار تیمی هم بیشتر در محیط کار باید یاد بگیرید وگرنه هر چقدر هم بخونید ولی یه کار تیمی انجام ندید کامل متوجه نمیشید.
Unit Test خیلی چیز خوبیه ولی واقعآً بعضی مواقع کار فوق العاده سختی هستش (من خودم هم خیلی دوست دارم یاد بگیرم!)

آشنایی با مباحث طراحی واسط کاربر معمولاً در محیط کار بر عهده گرافیست هستش و به هیچ وجه وظیفه برنامه نویس نیست (هر چند تو ایران معمولاً همه کارها بر عهده برنامه نویس هست، از کد نویسی تا بازاریابی و فروش!)

مباحث مهندسی نرم افزار مثل Design Pattern و ... مهمه ولی اینکه بدونید کجا ازشون استفاده کنید و کجا نباید استفاده کرد هم باید توجه داشت. این مباحث یه مقدار فهمش و مخصوصاً پیاده سازیش سخت هستش و معمولآً توی شرکت های بزرگ کار شخص برنامه نویس نیست. چند مورد Design Pattern معروف و مفید هست که باید یاد بگیرید (MVVM برای پروژه های ویندوزی -> WPF و MVC برای پروژه های تحت وب -> ASP.NET MVC)
زبان انگیسی هم هیمنطور که دوستان گفتن خیلی مهمه.

ولی اینکه میرید همه چیزها رو تا تهش یاد میگیرید کارتون رو خیلی خیلی سخت میکنه پس حواستون باشه. مثلاً XML Documentation اصلاً واجب نیست شما بدونید داره پشت صحنه چکار میکنه و ... که خودتون توضیح دادید. توی بعضی موارد مثل خود C#‎‎ مطالعه عمقی شاید خوب باشه ولی در اکثر موارد کار بیهوده ای هستش (با توجه به زمان).

[Programmer 1]

در ضمن اگر این متن رو خودت نوشتی(کپی نکردی) اول باید انگلیسی یاد بگیری.من هنوز ندیدم کسی بدون انگلیسی واقعا برنامه نویس بشه.

حالا نمی دونم چی باعث شده که شما فکر کنید این متن کپی شده شده، برای سوال کردن هم کپی و پیست؟ در هر حال خیر، متن رو خودم نوشتم.

[Programmer 1]

خیلی از این چیزهایی که گفتید نیاز نیست (بعضی هاش رو اگه بلد بودید که چه بهتر، اما بعضی هاش اصلاً به درد نمیخوره)
شما برای ORM باید یک مورد خوب مثل Entity Framework (چون هم ORM خیلی خوبی هست و هم بازار کارش خوبه) رو یاد بگیرید.
برای برنامه های ویندوزی WPF رو یاد بگیرید (توجه کنید که WPF فقط زیبایی ظاهری نیستش، نکته مهم WPF بحث Data Binding فوق العادش هست) پس شما هم خیلی نمیخواد خودتو درگیر انیمیشن و سه بعدی و ... در WPF بکنی
برای برنامه های تحت وب ASP.NET MVC رو یاد بگیرید (چون ASP.NET Web Form در حال مرگ هستش و بر عکس MVC هر روز پیشرفته تر و بهتر میشه)
در مورد گزارش گیری در برنامه ها (هم وب و هم ویندوز) به جای Crystal Report از Stimulsoft Report (غیر رایگان) یا کتابخانه PdfReport (رایگان) آقای نصیری استفاده کنید

Socket Programming خوبه ولی کارایی چندانی نداره پس میتونید اصلاً سراغش نرید
WCF ، Registery، Crystal Report، 2D 3D Graphic ، Dotfuscator ، Net Security ، ADO.NET رو کلآً بزارید کنار و به هیچ وجه سمتشون نرید. این لینک هم نگاه کنید (بررسی فناوری ها از دیدگاه مرگ و زندگی)
آشنایی با IDE که خیلی کاری نداره و چند روزه میتونید کامل محیط رو یاد بگیرید

روش نسخه بندی نرم افزار آنچنان کارایی برای شما نداره ولی اگر اینطور فکر نمیکنید یاد گرفتنش هم اصلاً کار سختی نیست (کافیه اینجا رو بخونید)
استاندارد های کدنویسی هم به مرور یاد میگیرید و با نصب Resharper میتونید خیلی چیزها در این مورد یاد بگیرید شما فقط سعی کنید تا حد امکان کد رو ساده و خوانا بنویسید و اینکه از قواعد نام گذاری درستی استفاده کنید چون این موارد واقعاً مهم هستند
استفاده از یک کنترل نسخه مثل TFS یا Svn یا GIT خیلی خوبه حتی اگر تیمی کار نمیکنید (من خودم TFS رو ترجیح میدم)
Agile و کار تیمی هم بیشتر در محیط کار باید یاد بگیرید وگرنه هر چقدر هم بخونید ولی یه کار تیمی انجام ندید کامل متوجه نمیشید.
Unit Test خیلی چیز خوبیه ولی واقعآً بعضی مواقع کار فوق العاده سختی هستش (من خودم هم خیلی دوست دارم یاد بگیرم!)

آشنایی با مباحث طراحی واسط کاربر معمولاً در محیط کار بر عهده گرافیست هستش و به هیچ وجه وظیفه برنامه نویس نیست (هر چند تو ایران معمولاً همه کارها بر عهده برنامه نویس هست، از کد نویسی تا بازاریابی و فروش!)

مباحث مهندسی نرم افزار مثل Design Pattern و ... مهمه ولی اینکه بدونید کجا ازشون استفاده کنید و کجا نباید استفاده کرد هم باید توجه داشت. این مباحث یه مقدار فهمش و مخصوصاً پیاده سازیش سخت هستش و معمولآً توی شرکت های بزرگ کار شخص برنامه نویس نیست. چند مورد Design Pattern معروف و مفید هست که باید یاد بگیرید (MVVM برای پروژه های ویندوزی -> WPF و MVC برای پروژه های تحت وب -> ASP.NET MVC)
زبان انگیسی هم هیمنطور که دوستان گفتن خیلی مهمه.

ولی اینکه میرید همه چیزها رو تا تهش یاد میگیرید کارتون رو خیلی خیلی سخت میکنه پس حواستون باشه. مثلاً XML Documentation اصلاً واجب نیست شما بدونید داره پشت صحنه چکار میکنه و ... که خودتون توضیح دادید. توی بعضی موارد مثل خود C#‎‎ مطالعه عمقی شاید خوب باشه ولی در اکثر موارد کار بیهوده ای هستش (با توجه به زمان).

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

[FastCode]

حالا نمی دونم چی باعث شده که شما فکر کنید این متن کپی شده شده، برای سوال کردن هم کپی و پیست؟ در هر حال خیر، متن رو خودم نوشتم.

بیش از حد فارسی بود.

واقعا برای فهمیدن بعضی کلمات چند ثانیه فکر کردم.مثل کنترل نسخه. یا الگوی طراحی یا چند تای دیگه.
vcs و design pattern واژه های مشترک بین برنامه نویسهای دنیا هستن.بهتره با کلمات انگلیسی کار کنید که چشم و گوشتون باهاشون آشنا بشه.

نظر شخصی من اینه که متوجه نشدن یک کلمه فنی فارسی اشکالی نداره.ولی بلد نبودن یک کلمه انگلیسی داره.

[Arash_janusV3]

یک نکته ای را یاد آوری می کنم شاید مفید باشه
من مخالفه این هستم که برنامه نویس باید چیزهایی را یاد بگیره که بهشون نیاز داره
خوب اگر این واقعا درست باشه که بر اساس نیازهامون شروع به یاد گیری کنیم
به محضی که مثلا سی شارپ و sql را یاد گرفتیم دیگه می ریم تو بازار کار و در همون سطح دانش لنگری می اندازیم و شروع به کسب درآمد می کنیم
و به قول خودمون دیگه وقت نمی کنیم چیزی یاد بگیریم و سراغ مسائل جدید بریم که با این حرف خودمون رو گول می زنیم
یکی از دوستای قدیمی من که حدود 40 سال سن داره و به جرأت می گم کدنویس قدرتمندیه دچار همین اشکال شده
و جالب اینجاست که هنوز داره FoxPro کار می کنه تمام برنامه هاش هم تحت Dos هستش
حالا من این را نگفتم که همش مباحث جدید را یاد بگیریم
ولی حداقل های اون را بدونیم
یا بهتره یک مثال دیگر هم بزنم
چند سال پیش که برا برنامه نویسی آموزش می دیدم یکی از هم دوره ای ها از VB متنفر بود و هیچی یاد نمی گرفت همه کلاسها را اومد اما چیزی یاد نگرفت
تا اینکه به طور تصادفی با sql 2000 آشنا شد و بعد از چندوقت متوجه شدم که رفته به سمت پیاده سازی بانک اطلاعات (سرعت , امنیت , پایگاه داده , شبکه و ...)
تمام این مباحث را در پایگاه داده پیاده سازی می کرد البته به طور تخصصی و به قول خودش عاشق این کارش هست
منظورم از گفتن این مطلب این بود که شاید یاد گیری مطالب جدید می تونه به پیدا کردن تواناییها و استعدادهامون منجر بشه و یک مسیر موفقی را انتخاب کنیم
ولی جالب اینجاست که این مسیر تصادفی هستش و از قبل برنامه ریزی شده نیست
مگر یاد گرفتنه حداقل یک مبحث جدید در حد مقدماتی چقدر زمان می بره؟
به طور مثال سی شارپ در حد مقدماتی شاید 20 ساعت و اگر کسی از قبل برنامه نویسی را بدونه برای اون شاید 5 ساعت (نه به طور دقیق اما تا حدودی)
و غیر از این مطالب ما می تونیم با یادگیری های مطالب جدید الگوهای خوبی برای پروژه هامون پیدا کنیم
من یک مشکلی داشتم در ویندوز فرم که نمی تونستم فرمها را بر اساس رزولوشن سایز بندی کنم
تا اینکه یک روز Html می خوندم و دیدم که سایز جداول را بر اساس درصد که مقدار دهی کنیم به طور خودکار سایز با رزولوشن هماهنگ می شه و ظاهر بد ترکیب نمی شه
خوب این برای من الگو بود و اومدم روی ویندوز فرم این را پیاده کردم
که سایز واقعی فرم را از جدول پاس می دادم و رزولوشن ویندوز را هم گرفتم و درصد سایز واقعی را محاسبه می کردم و به فرمم پاس می دادم
یا به طور مثال من از کامپوننت تلریک استفاده نمی کنم ولی وقتی بخوام فرمم را طراحی کنم از دموی اون الگو می گیرم و همین مسئله باعث شد هم فرمها ظاهر خوبی پیدا کنند هم با تمام امکانات تلریک آشنا بشم و الان هم براحتی می تونم از تلریک در پروژه هام استفاده کنم در صورتی اصلا بهشون نیاز ندارم

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

موفق باشید

[C#‎‎_best_Programmer]

ببین داشم اینارو دیر یا زود یاد میگیری ولی چیزی که مهم فکر آدم لطفا بام تماس بگیر 09307875950

[linux]

سلام به همه دوستان،

واقعا سر در گم شدم وظیفه یک برنامه نویس دات نت در ایران چیه؟ باید چه مباحثی رو یاد داشته باشه؟

طرف نوشته مسلط به C#‎‎‎, SQL Server و مسلط به دات نت.
...
با سپاس/.

برای افراده تازه کار و کسانی که تازه از دانشگاه آمدند.
چیزی که برای من مهم هست و به عنوان مصاحبه فنی تا حالا با افراد مختلف کردم برای جذب نیروی کار برای سازمانمان این هست که افرادی که به عنوان برنامه نویس سی شارپ جذب می شوند این مباحث را بلد باشند
۱- شی گرایی: بدانند : کلاس چی هست، اینترفیس چی هست ، overriding , over loading را بدونند ارث بری را بلد باشند و ... بتوانند توضیح بدهند مثلا فرق کلاس و ساختار چی هست.
۲- آشنایی با کلاس های و فضای نام‌های دات نت داشته باشند. البته بصورت کلی.
۳- کلمه الگوهای طراحی به گوشش خورده باشد، بتونند ۲-۳ تا از الگوهای پر کاربرد را اسم ببرد.
۴- یک چیزهایی در مورد mvc بداند.
۵- در مورد مباحث نرم‌افزاری UML مقداری بلد باشد خصوصا کلاس دیاگرام‌ها را.
۶- در مورد sql هم همینقدر که بلد باشد جدول بسازه و ارتباط تعریف کند و یک کوئری بین دو تا جدول بنویسد کفایت می کند.
البته علاقمندی و تیزهوشی هم مهم هست.
بقیه مسایل در طول مدت یاد گرفته و پیش برده می‌شود.
برای مثلا با ۱۰ دقیقه توضیح و یک نمونه کار کوچک کار با tfs یا svn در حد مبتدی آموزش داده می‌شود و بقیه موارد در طول زمان به مرور یادگرفته می‌شود.

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

[Programmer 1]

فرض کنید یک پروژه در حال انجام دارید ، در اثنای انجام پروژه با مفاهیم جدیدی آشنا میشید ، برخوردتون چه جوریه؟ مخصوصا اگه موضوعات جدید در پروژتون پرفورمنس بالایی ایجاد میکنند و یا مثلا امنیتش رو بالاتر می برند و ...
مثلا فرض کنید در حال پیاده سازی یک برنامه انبارداری هستید، بعد از مدتی سرو کله زدن با پایگاه داده متوجه می شید که معماری سه لایه ای وجود داره که خیلی کار توسعه رو راحت تر می کنه؟ ولی این رو زمانی متوجه شدید که کلی متد و کلاس و ... نوشتید و سه لایه کردن برنامه کلی تغییر مخرب در پی داره؟ واکنشتون چیه؟ موکول می کنید به پروژه های بعدی یا پروژه تون رو آپدیت می کنید ؟
یا مثلا اومدید با کلی زجمت پروژه تون رو سه لایه کردید ، بعد از مدتی متوجه شدید که به جای استفاده مستقیم از ado.net می تونستید از orm هایی شبیه entity framework استفاده کنید؟
یا وقتی میبینید که تست کردن هر متد اینقدر طول میکشه؟ unit test ای هست که کار تست متد ها رو خیلی راحت می کنه.

اصولا برخورد شما با این نوع تغییرات چیه؟ چه راه حلی اتخاذ می کنید؟

[linux]

فرض کنید یک پروژه در حال انجام دارید ، در اثنای انجام پروژه با مفاهیم جدیدی آشنا میشید ، برخوردتون چه جوریه؟ مخصوصا اگه موضوعات جدید در پروژتون پرفورمنس بالایی ایجاد میکنند و یا مثلا امنیتش رو بالاتر می برند و ...
مثلا فرض کنید در حال پیاده سازی یک برنامه انبارداری هستید، بعد از مدتی سرو کله زدن با پایگاه داده متوجه می شید که معماری سه لایه ای وجود داره که خیلی کار توسعه رو راحت تر می کنه؟ ولی این رو زمانی متوجه شدید که کلی متد و کلاس و ... نوشتید و سه لایه کردن برنامه کلی تغییر مخرب در پی داره؟ واکنشتون چیه؟ موکول می کنید به پروژه های بعدی یا پروژه تون رو آپدیت می کنید ؟
یا مثلا اومدید با کلی زجمت پروژه تون رو سه لایه کردید ، بعد از مدتی متوجه شدید که به جای استفاده مستقیم از ado.net می تونستید از orm هایی شبیه entity framework استفاده کنید؟
یا وقتی میبینید که تست کردن هر متد اینقدر طول میکشه؟ unit test ای هست که کار تست متد ها رو خیلی راحت می کنه.

اصولا برخورد شما با این نوع تغییرات چیه؟ چه راه حلی اتخاذ می کنید؟

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

[sohil_ww]

برای افراده تازه کار و کسانی که تازه از دانشگاه آمدند.
چیزی که برای من مهم هست و به عنوان مصاحبه فنی تا حالا با افراد مختلف کردم برای جذب نیروی کار برای سازمانمان این هست که افرادی که به عنوان برنامه نویس سی شارپ جذب می شوند این مباحث را بلد باشند
۱- شی گرایی: بدانند : کلاس چی هست، اینترفیس چی هست ، overriding , over loading را بدونند ارث بری را بلد باشند و ... بتوانند توضیح بدهند مثلا فرق کلاس و ساختار چی هست.
۲- آشنایی با کلاس های و فضای نام‌های دات نت داشته باشند. البته بصورت کلی.
۳- کلمه الگوهای طراحی به گوشش خورده باشد، بتونند ۲-۳ تا از الگوهای پر کاربرد را اسم ببرد.
۴- یک چیزهایی در مورد mvc بداند.
۵- در مورد مباحث نرم‌افزاری UML مقداری بلد باشد خصوصا کلاس دیاگرام‌ها را.
۶- در مورد sql هم همینقدر که بلد باشد جدول بسازه و ارتباط تعریف کند و یک کوئری بین دو تا جدول بنویسد کفایت می کند.
البته علاقمندی و تیزهوشی هم مهم هست.
بقیه مسایل در طول مدت یاد گرفته و پیش برده می‌شود.
برای مثلا با ۱۰ دقیقه توضیح و یک نمونه کار کوچک کار با tfs یا svn در حد مبتدی آموزش داده می‌شود و بقیه موارد در طول زمان به مرور یادگرفته می‌شود.

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

چه طوری تو این سر فصل ها قدرت مند بشیم

در کل چی کار کنیم از اون حد آموزش دانشگاه ارتباط با sql تعریف کوئری بالا تر بریم ؟!

[FastCode]

چه طوری تو این سر فصل ها قدرت مند بشیم

در کل چی مار کنیم از اون حد آموزش دانشگاه ارتباط با sql تعریف کوئری بالا تر بریم ؟!

تمرین
کارآموزی
و از همه مهمتر نیاز

[Programmer 1]

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

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

[FastCode]

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

به همین دلیل به جز برنامه نویس نقش های دیگه مثل طراح و معمار و تحلیلگر هم توی یه تیم برنامه نویسی وجود داره

[Programmer 1]

به همین دلیل به جز برنامه نویس نقش های دیگه مثل طراح و معمار و تحلیلگر هم توی یه تیم برنامه نویسی وجود داره

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

[linux]

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

به همین دلیل شما توی تیمی قرار می گیرید که یکی مثل من که از ۲۰۰۳ برنامه نویسی با سی شارپ را شروع کرده و قبل از آن هم چند سالی با زبانهای دیگر کار کرده ،سرپرست تیم هست و این دانشی که طی این سالها توسط این شخص فراگرفته شده به مرور زمان به شما انتقال داده می شه و شما هم بعد از ۷-۸ سال کارکردند به همون سطح خواهید رسید. تازه این برای یک پروژه کوچک و متوسط هست که سرپرست تیم می تواند هم نقش طراح و تحلیلگر را هم داشته باشد در پروژه‌های بزرگ این نقش‌ها بر عهده افراد مختلفی گذاشته می‌شود.

[بهزاد علی محمدزاده]

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

مقالات ، بخش آموزش ، و پروفایل های متخصص ها رو نگاه کنید . یه گروه هستند که اینها زمینه کاریشون هست :

Evidence-Based User Experience Research, Training, and Consulting

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

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

ما خیال می کنیم ، کسی که سی شارپ و دیتابیس و تحلیل و مباحث مهندسی نرم افزار و کار می کنه ، بعد تو پروفایلشم نوشته UX دیگه واقعا طراح هم هست ؟

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

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

دوستانی که کار تجاری ، طراحی و برنامه نویسی وب انجام میدن ، چقدر این منابع و می شناسید ؟ و دنبالش میرید ؟ و پیاده سازی کردین ؟

واقعیت اینه که ما همه این مباحث رو نمی تونیم درش متخصص بشیم . اکثر پروفایل هایی رو هم که می بینم ، مثل کتاب سازی و مقاله سازی ، پروفایل سازی هستند تا واقعیت . مگر اینکه 24 ساعتش با 24 ساعت ما فرق داشته باشه .

[Programmer 1]

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

مقالات ، بخش آموزش ، و پروفایل های متخصص ها رو نگاه کنید . یه گروه هستند که اینها زمینه کاریشون هست :

Evidence-Based User Experience Research, Training, and Consulting

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

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

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

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

با اینکه خودم پاسخ این سوال رو می دونم ولی مطرح کردن این مسئله در اینجا و صحبت های دوستان حول این محور دلگرم کننده است شما اسمش رو بزارید درد دل!

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

[linux]

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

با اینکه خودم پاسخ این سوال رو می دونم ولی مطرح کردن این مسئله در اینجا و صحبت های دوستان حول این محور دلگرم کننده است شما اسمش رو بزارید درد دل!

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

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

[j_naroogha@yahoo.com]

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

از مهندسی نرم افزار فقط یه اسم هست....
و...
..
..
.
.

[csvbcscp]

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

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

بروسلی هم حرفای قشنگی زده شاید تاثیر گذار باشه !!!

بروسلی:

The style doesn’t make the fighter, the fighter makes the style.
معادل آن در دنیای نرم افزار:

The process doesn’t make the developer, the developer makes the process.

معنا:
پیروی کورکورانه از روش‌ها و شیوه‌های جدید از شما برنامه نویس نخواهد ساخت! “شما” هستید که به کار معنا خواهید داد.
تمرکز بیش از حد بر روی یک روش کاری، دیدگاه شما را محدود ساخته و از بسیاری از موقعیت‌ها و امکانات مهیای دیگر غافل خواهید شد.

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

البته قبلا هم کتاب مقدماتی در مورد سی++ با همین عنوان توسط همسرم، نوشته شده ،،، اما اینبار کتاب جدید سی شارپ با محتوایی متفاوت میاد به کمک علاقه مندان برنامه نویسی

امیدوارم که قبول حق تعالی قرار بگیره

آدرس کتاب سی پلاس پلاس بدون ترس
http://www.ipd.blogfa.com/post/45

[csvbcscp]

مرسی پاسخ جامعی بود

[Programmer 1]

بروسلی:

The style doesn’t make the fighter, the fighter makes the style.
معادل آن در دنیای نرم افزار:

The process doesn’t make the developer, the developer makes the process.

معنا:
پیروی کورکورانه از روش‌ها و شیوه‌های جدید از شما برنامه نویس نخواهد ساخت! “شما” هستید که به کار معنا خواهید داد.
تمرکز بیش از حد بر روی یک روش کاری، دیدگاه شما را محدود ساخته و از بسیاری از موقعیت‌ها و امکانات مهیای دیگر غافل خواهید شد.

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

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

[csvbcscp]

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

I understood that you want to be a developer using .Net.



You listed all important stuff as far as I see. And you already split it up quite nicely:



Technical stuff: you listed all the libraries that are commonly used. For a beginner it is simply not possible to start with all. After the first steps (so you know C#‎‎‎‎ and you was able to write some first small applications) you should read about each technology so you get the overview. What is it and when could it be usefull?



Often you simply have just a few technologies so most work is done by my team with asp.net, EF, Wcf and thats it. We even didn't use Asp.Net MVC for quite long (we had our own library where we had our Model and the view ... So we had something like mvc for very long!).



In a job you often simply work on existing stuff so there is often no need to master a technologie. You just have to understand the parts that are really used.



The next big point are design things. My suggestion is to simply read about object oriented design. Object thinking from ms press was good in my eyes. Do not waste time on patterns. You want to build stuff on your own and not just use some bricks without an understanding. (Get a book that explain patterns if colleagues like to talk about them but i never used them so far in my job. I know lots and on code reviews we use the wordings bsometimes ....)



And next comes the teamwork: teams work different. You simply have to be open minded. And always be a team player. Code reviews are something great but you must see it as a chance to learn. It is not meant as "you did it wrong" .... But that is the hardest point in my eyes but it depends on the colleagues.



Nothing beats experience! You simply need to get your hands on it. Start as an apprentice and work as a developer. There is no way from reading books to be a senior software engineer.



I didn't mention all right now. Tests are important, database design is. But do it as you go forward.



Also important: work on your english skills. In my eyes there is no alternative to that. (I am german and there is a lot of good stuff e.g. a german community and german books and .... But I saw differences so all is on english here.)



And you found a great community! Just be aware that there are a lot of english forums for different topics. But you will find a lot of people that are really helpfull. So come back if you need information or help!

[csvbcscp]

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

کتابی در زمینه سی شارپ مطالعه می کنم ، فصل اولش در مورد چارچوب دات نته، خب، من وقتی مطالعه میکنم معمولا به صورت موازی از اینترنت هم کمک میگیریم ، مثلا جاهایی از مفاهیم دات نت فریم ورک رو که متوجه نمیشم رجوع میکنم به اینترنت و در اون زمینه مطالعه بیشتری میکنم ، مثلا فرض کنید که کتاب مورد مطالعه در مورد تبدیل کد به کد IL توضیح داده شده و توضیح بیشتری در مورد کدهای IL و ساختار فایل های pe تولیدی داده نشده، من رجوع میکنم به اینترنت بعد از کلی این طرف و اون طرف رفتن به کتاب Clr Via C#‎‎ برخورد می کنم ، و می بینم که در مورد دات نت با عمق خیلی بیشتری داره توضیح میده ، حالا به خودم می گم که تا زمانی که چارچوب دات نت رو خوب متوجه نشدم ادامه نمی دم پس به دست از مطالعه کتاب قبلی بر می دارم و می آم سراغ این کتاب جدید.

یا مثلا وقتی دارم کد می نویسم ناگهان برام سوال پیش می آد که این اسلش های سه تایی به عنوان کامنت چیه؟ یه جستجویی میکنم تو اینترنت می بینیم که اینها xml documenating هستند، کد نویسی رو رها میکنم و می رم دنبال یاد گرفتن این موضوع ، در اثنای این یادگیری با نرم افزارهای تولید خودکار xml documenating برخورد می کنم میرم سراغ یاد گیری اسکریپت هاش.

حالا به هر دلیلی سر از سایت dotnettip در آوردم ، گذرم می خوره به unit testing و مقاله خوبی که در این باره نوشته شده، شروع میکنم به مطالعه این مقاله و درگیر تست آزمایش واحد می شم، رجوع میکنم به آمازون برای جستجوی یک کتاب با موضوع unit testing ، کتابی پیدا میکنم دانلودش می کنم شروع می کنم به مطالعه.

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

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

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

the scenario you described is a common one. Once you start something you will always find a lot more things that you could evaluate first.

Regarding the learning: I like to put things on a todo list when I come across it. So with your example you could continue to read the first book and just fill a todo list. So instead of stopping reading the book (Jeff Richters book ablut CLR with C#‎‎ is really good. I read that, too!) you just add more things on it. So if you find something about test driven development you could add a Topic on your list that you want to read about that.

Edit: Posted it by accident - not sure how I did that. Maybe I hit the pad of the Laptop with my Hand and the mouse was on top of the Submit button? Who cares ... here Comes the rest what I wanted to write:

If you do it that way you can continue your learning process. Switching between Topics can be quite hard because you will never come to an end. (I found it usefull to really finish something - so I read a book completly or I took an exam.)

But as I wrote: Practice is also very important. But during the practice it was never something like "Mastering xyz". So when I decided to do something I was doing my design which first didn't involve any technology. When I knew what I wanted to build I was desiding about Technologies e.g. "I will use Windows Forms to create the client." And so on....

When I do my implementation I am just reading what I really need. So I wasn't mastering Entity Framework. When I am using Database First then I would read only how to generate the model from my database and then use the generated stuff. There is no reason to master everything because then I wouldn't write any line of code and my Project would never be done.

But of course: When you do your learning you can Change the priorities. So I droped my studies towards a MCPD certification just to do the SQL Server Developer certification first. Reason was a Project in which the Team had to build a very complex database (e.g. working with XML inside the database including XML schemes) - so that is always possible if required ...

So the 2nd Point are Projects you want to work on - where you should find a way to just read / learn what is really required. That will give you practice but you will not master a Technology.

The last Point that I read in your Point is: "How do I get a Job?". When you want to get a Job as an apprentice then the employer does not expect a Person who knows everything. An Apprentice is not a Person with years of experience in all Topics required. It is a Person who will Need Training. So for us it was always important to find someone who is really interested in learning the Topics that was important for us and that showed that they have some Basic understanding.

And if you read some books already and got a first understanding of important parts then you are a good candidate for an apprentice Job.

Only if you want to apply for a Senior Job you Need to Show that you got a lot of expereince already. So we are really looking into Project lists and we ask candidates what they did in these Jobs. And we ask a lot of details to see if the candidate has deep knowledge. We could even give the candidate a description of Problems we had in the past to hear how he would try to solve it.

But that is completly out of scope for someone who wants a first Job. Nobody expects you to do the work of a Senior engineer :)

So in my eyes it is important that you Show that

- you are interested in learning it

- you learned already something on your own.

- you are interest in building high quality things.

That was just the technical side. Other areas are also important like "Can you work in a team?" or "How do you react in stress situations?" ... But that is the same for all jobs.

I hope that helped a little. I wish that you have success finding a nice Job, that you can continue your learning and most important: That you have a lot of fun in this area! (It can be a lot of fun - my Job is also my Hobby! That is the best Situation you can be in.)

With kind regards

[Programmer 1]

ممنون از زحمتی که کشیدید

Regarding the learning: I like to put things on a todo list when I come across it. So with your example you could continue to read the first book and just fill a todo list. So instead of stopping reading the book (Jeff Richters book ablut CLR with C#‎‎‎‎ is really good. I read that, too!) you just add more things on it. So if you find something about test driven development you could add a Topic on your list that you want to read about that

این تکنیک به دلم نشست، واقعا با همه سادگی به ذهنم نرسیده بود!

So in my eyes it is important that you Show that

- you are interested in learning it

- you learned already something on your own.

- you are interest in building high quality things.

این جمله ها هم، جمله های امیدوار کننده ای بود.

باز هم ممنونم آقای csvbcscp

[FastCode]

So in my eyes it is important that you Show that

- you are interested in learning it

- you learned already something on your own.

- you are interest in building high quality things.

بهتر نیست یک مورد دیگه هم اضافه بشه؟
You can actually read and write in english so you don't screw up with babble words just like you did.

[csvbcscp]

فرض کنید یک پروژه در حال انجام دارید ، در اثنای انجام پروژه با مفاهیم جدیدی آشنا میشید ، برخوردتون چه جوریه؟ مخصوصا اگه موضوعات جدید در پروژتون پرفورمنس بالایی ایجاد میکنند و یا مثلا امنیتش رو بالاتر می برند و ...
مثلا فرض کنید در حال پیاده سازی یک برنامه انبارداری هستید، بعد از مدتی سرو کله زدن با پایگاه داده متوجه می شید که معماری سه لایه ای وجود داره که خیلی کار توسعه رو راحت تر می کنه؟ ولی این رو زمانی متوجه شدید که کلی متد و کلاس و ... نوشتید و سه لایه کردن برنامه کلی تغییر مخرب در پی داره؟ واکنشتون چیه؟ موکول می کنید به پروژه های بعدی یا پروژه تون رو آپدیت می کنید ؟
یا مثلا اومدید با کلی زجمت پروژه تون رو سه لایه کردید ، بعد از مدتی متوجه شدید که به جای استفاده مستقیم از ado.net می تونستید از orm هایی شبیه entity framework استفاده کنید؟
یا وقتی میبینید که تست کردن هر متد اینقدر طول میکشه؟ unit test ای هست که کار تست متد ها رو خیلی راحت می کنه.

اصولا برخورد شما با این نوع تغییرات چیه؟ چه راه حلی اتخاذ می کنید؟

Hi,

I am not sure that I understood you correctly.

When you work on a project, you always have to deal with problems. As soon as a project gets a certain size, you should use some kind of management software to deal with the complexity. For small teams an agile approach is a great thing.

So let us have a look at a scrum like management:

So imagine you have a project and you / your team want to work on it. The first thing you need is a list of features. What should the result do? What is expected? For these things we use story cards. They all have at the front something like
As a ....... I want to ........ so that .....
So imagine we are talking about a car management software. So there could be stories like "As a car driver I want to easily report trouble so that the car can be changed / checked without big management overhead". At the back we list criterias that must be fullfilled so that the story is fullfilled.

Once we have collected the stories the meeting of all stakeholders will set priorities and only the top stories will be in scope. So the end of this meeting will be a small list of stories that should be implemented after the so called sprint.

Now the development team sits together and "plays cards". So first wie divide stories up into tasks. What is required? Then we rate on the tasks. Each person of the team has a cards with numbers - normaly 1 to 8 and a blank one. Each developer has to take one card which tells how much work the implementation should take. That way we get an estimate. If the estimate is to high or couldn't be estimated then the task should be split or it needs at least a more deeper calculation.
(The time will be the estimate * a team factor. We use * 2 but that is always something that depends on the teams. An estimate is normaly simply to low.)

We also go through the open bug list. Is there any change required that should be addressed in this sprint, too? (In a ideal world, a bug would always be fixed. But we live in a world where managers have to keep care of money. So for example we develop for a customer. If the customer wants something fixed, they might need to pay for it. And the customer could say: "Sorry, I do not care about that bug because I have a workaround and it works great!")

So now we have a list of tasks that we have to work on in our sprint. Our management software (We use Team Foundation Server) will give us all reports e.g. open tasks, a so called Sprint Burndown Chart and so on ... That way managers have a good overview if we are on track. These reports are sent on a daily basis and also include a list of so called impediments (e.,g. "Developer a cannot work on the project because he is ill and developer b has to rebuild his computer".)

Now a lot of different things can happen during our work:

a) When I work on a task, I have some problems and I can directly solve it. But the task simply took longer e.g. instead of 2 hours it took 4 hours. The manager will see it on the sprint burndown chart and also in the list of tasks where hs sees a closed task that took 4 hours instead of 2. Something like this happens but other tasks go quicker and often it is simply ok.

b) We encounter real problems. Something cannot be solved how we thought it could be solved. There will be a chat between the main developers where the design is checked. The result can be a changed Task list. These are the strange Sprint burndown charts where it suddenly does not go down but up again. And this is directly reportet to the responsible managers. So we as developers are experts in solving technical issues and give solution possibilities but the decisions if something is done or not is done by managers.

c) Hardest part which can happen: You find out that there is a technical issue that you didn't see in all your planing. In such a case you simply interut the sprint, report it and go towards the next sprint.
These things can happen but they should never ever happen. Never do an estimate if you are not sure about it!
The solutions for that are quite easy: You have to do proove of concepts. I never saw a customer or manager that does not accept that. Managers often talk in different words. They like to talk about risks, what they mean, the chance that they hit, what it will cost, what could be done to reduce the chance that the risk will hit or to reduce the cost ... or maybe the risk can be given to someone else ...

Now we have to face another topic:

You have an existing project and now you simply think "It could be much easier, faster, whatever another way". When we have ideas then we directly enter them into the system as backlock items. That way we do not forget them. When there is another meeting with the stakeholders of the project these topics will be on the table, too.

And then the normal managment stuff hits you: What does it cost? What do we win? And then the decision will be made.

So even if there is a new technology and Microsoft introduced something great new: Often it is out of interest for existing projects.

You mentioned unit tests:
There is no professional work without unit tests. You cannot maintain code that does not have good unit tests. It is a strict fact.

Regarding new technology: Never ever get the idea that there are some nice cool shortcuts. There are a lot of great technologies and when you really mastered them they are even better. But there is no magic stuff in them. So just a simple example: I build up a Lightswitch application because there was no time for a real sprint on a ASP.Net MVC gui for a database somone else build. I played around with Lightswitch and heya - I build a 3tier Silverlight/web application in one day (including the deployment to a server!) which first seemed a good thing but I quiklc had to find the hard points e.g.:
-> No unit tests.
-> Complete garbage when it comes to a database first development. I simply cannot count how often I rebuild screens because LS simply removed stuff!
-> Sometimes user get some error. Some racing conditions can occur and it is simply hard to find. (The forum was usefull but some parts are simply not working correctly!)
And a lot more points. In the end I spend much much more time into this application than a simple ASP.Net website would have been with MVC. And now I even rebuild the frontend with ASP.Net MVC and once I was able to throw out the LS Application then I will finally be able to refactor the database (Something that you simply cannot do with LS because LS does not like database changes!)

Just see it as an example. But one thing I learned (the hard way as you can see) is, that there are no shortcuts. It is nice if a vendor tries to sell a product to build a ocmplete app in 15 min before you go to lunch but that is simply garbage! My hint: Learn it propperly. You can easily build applications quickly if you know what you are doing. And the simple things that products should do in a short time can be done with the core stuff quickly, too. Not in a day but it is straight forwards. That is at least my experience. (And we even dropped 3rd party extensions because you already get al you need with jquery. The Grids was great that could sort and filter and do whatever you want but you can get that with quite siple jquery addons but the core idea is, that we do that in code already. It is much easier to support and there is no need to transmit more data than required to the client.

Ok, at the end I lost the track. I hope that my post was helpfull for you. Not sure that I really covered the points that you try to solve.

Ohh ... one last thing:
Always put stuff where it belongs to. Keep a clean design. That solves a lot of issues. And once you have a clean design you are really flexible. But that is also something that comes with some experience.

With kind regards,

Konrad

[Programmer 1]

Hi,

I am not sure that I understood you correctly.

When you work on a project, you always have to deal with problems. As soon as a project gets a certain size, you should use some kind of management software to deal with the complexity. For small teams an agile approach is a great thing.

So let us have a look at a scrum like management:

So imagine you have a project and you / your team want to work on it. The first thing you need is a list of features. What should the result do? What is expected? For these things we use story cards. They all have at the front something like
As a ....... I want to ........ so that .....
So imagine we are talking about a car management software. So there could be stories like "As a car driver I want to easily report trouble so that the car can be changed / checked without big management overhead". At the back we list criterias that must be fullfilled so that the story is fullfilled.

Once we have collected the stories the meeting of all stakeholders will set priorities and only the top stories will be in scope. So the end of this meeting will be a small list of stories that should be implemented after the so called sprint.

Now the development team sits together and "plays cards". So first wie divide stories up into tasks. What is required? Then we rate on the tasks. Each person of the team has a cards with numbers - normaly 1 to 8 and a blank one. Each developer has to take one card which tells how much work the implementation should take. That way we get an estimate. If the estimate is to high or couldn't be estimated then the task should be split or it needs at least a more deeper calculation.
(The time will be the estimate * a team factor. We use * 2 but that is always something that depends on the teams. An estimate is normaly simply to low.)

We also go through the open bug list. Is there any change required that should be addressed in this sprint, too? (In a ideal world, a bug would always be fixed. But we live in a world where managers have to keep care of money. So for example we develop for a customer. If the customer wants something fixed, they might need to pay for it. And the customer could say: "Sorry, I do not care about that bug because I have a workaround and it works great!")

So now we have a list of tasks that we have to work on in our sprint. Our management software (We use Team Foundation Server) will give us all reports e.g. open tasks, a so called Sprint Burndown Chart and so on ... That way managers have a good overview if we are on track. These reports are sent on a daily basis and also include a list of so called impediments (e.,g. "Developer a cannot work on the project because he is ill and developer b has to rebuild his computer".)

Now a lot of different things can happen during our work:

a) When I work on a task, I have some problems and I can directly solve it. But the task simply took longer e.g. instead of 2 hours it took 4 hours. The manager will see it on the sprint burndown chart and also in the list of tasks where hs sees a closed task that took 4 hours instead of 2. Something like this happens but other tasks go quicker and often it is simply ok.

b) We encounter real problems. Something cannot be solved how we thought it could be solved. There will be a chat between the main developers where the design is checked. The result can be a changed Task list. These are the strange Sprint burndown charts where it suddenly does not go down but up again. And this is directly reportet to the responsible managers. So we as developers are experts in solving technical issues and give solution possibilities but the decisions if something is done or not is done by managers.

c) Hardest part which can happen: You find out that there is a technical issue that you didn't see in all your planing. In such a case you simply interut the sprint, report it and go towards the next sprint.
These things can happen but they should never ever happen. Never do an estimate if you are not sure about it!
The solutions for that are quite easy: You have to do proove of concepts. I never saw a customer or manager that does not accept that. Managers often talk in different words. They like to talk about risks, what they mean, the chance that they hit, what it will cost, what could be done to reduce the chance that the risk will hit or to reduce the cost ... or maybe the risk can be given to someone else ...

Now we have to face another topic:

You have an existing project and now you simply think "It could be much easier, faster, whatever another way". When we have ideas then we directly enter them into the system as backlock items. That way we do not forget them. When there is another meeting with the stakeholders of the project these topics will be on the table, too.

And then the normal managment stuff hits you: What does it cost? What do we win? And then the decision will be made.

So even if there is a new technology and Microsoft introduced something great new: Often it is out of interest for existing projects.

You mentioned unit tests:
There is no professional work without unit tests. You cannot maintain code that does not have good unit tests. It is a strict fact.

Regarding new technology: Never ever get the idea that there are some nice cool shortcuts. There are a lot of great technologies and when you really mastered them they are even better. But there is no magic stuff in them. So just a simple example: I build up a Lightswitch application because there was no time for a real sprint on a ASP.Net MVC gui for a database somone else build. I played around with Lightswitch and heya - I build a 3tier Silverlight/web application in one day (including the deployment to a server!) which first seemed a good thing but I quiklc had to find the hard points e.g.:
-> No unit tests.
-> Complete garbage when it comes to a database first development. I simply cannot count how often I rebuild screens because LS simply removed stuff!
-> Sometimes user get some error. Some racing conditions can occur and it is simply hard to find. (The forum was usefull but some parts are simply not working correctly!)
And a lot more points. In the end I spend much much more time into this application than a simple ASP.Net website would have been with MVC. And now I even rebuild the frontend with ASP.Net MVC and once I was able to throw out the LS Application then I will finally be able to refactor the database (Something that you simply cannot do with LS because LS does not like database changes!)

Just see it as an example. But one thing I learned (the hard way as you can see) is, that there are no shortcuts. It is nice if a vendor tries to sell a product to build a ocmplete app in 15 min before you go to lunch but that is simply garbage! My hint: Learn it propperly. You can easily build applications quickly if you know what you are doing. And the simple things that products should do in a short time can be done with the core stuff quickly, too. Not in a day but it is straight forwards. That is at least my experience. (And we even dropped 3rd party extensions because you already get al you need with jquery. The Grids was great that could sort and filter and do whatever you want but you can get that with quite siple jquery addons but the core idea is, that we do that in code already. It is much easier to support and there is no need to transmit more data than required to the client.

Ok, at the end I lost the track. I hope that my post was helpfull for you. Not sure that I really covered the points that you try to solve.

Ohh ... one last thing:
Always put stuff where it belongs to. Keep a clean design. That solves a lot of issues. And once you have a clean design you are really flexible. But that is also something that comes with some experience.

With kind regards,

Konrad

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

[saman2]

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

[نیما عطایی]

واقعا دلم برای دورانی که با اسمبلی برای میکرو کنترل برنامه مینوشتم و کمی هم برای دوران طلایی VB تنگ شد.
همه ما این مشکلات رو داشته و داریم.
وب یه دنیای نا محدود و به سرعت در حال گسترشه که مثل کائنات تا تهش رو میبینی تازه میفهمی بازم هست.
و البته که ما برنامه نویس ها ، سازندگان این کائنات هستیم.
من به شخصه وقت برای مطالعه عمیق نداشته و ندارم .
ولی هر زمان در هر پروژه جدیدی که بایه چالش جدید مواجه میشم میشینم و فقط همون مقدار که از آموزه های جدید لازم دارم مطالعه میکنم.
به قول یه فیلسوفی برنامه نویس باید یه اقیانوس باشه به عمق چند سانت و هرجایی که لازم بود رو بکنه و چند کیلومتر عمیقش کنه.
اما واقعا دیگه تحمل این حجم بالای اطلاعات جدید رو ندارم و ترجیه میدم راه رفتن کلاغی خودمو ادامه بدم تا توی راه یاد گرفتن راه رفتم طاووس راه رفتن خودمم فراموش کنم.
واقعا برای برنامه های عادی و عمومی که 95% ما مینویسیم چه فرقی میکنه مثلا توابع پردازشی توی پایگاه داده باشه یا انتتی یا ado و در مورد اون 5% باقی مانده هم حتما ارزش وقت گذاشتن و مطالعه عمیق تر برای چند میلی ثانیه ناقابل رو خواهد داشت.
خلاصه دوست من ، من که 11 سال پیش اولین برنامم رو فروختم تا حالا هم جواب خیلی از سوالاتت رو نمیدونم ولی اینو میدونم که هیچوقت 100% که نه حتی 90% از کار خودم راضی نبودم و همیشه بعد یه پروژه با خوندن یه مقاله ، یه پست وبلاگ یا هر چیز دیگه یادم افتاده که شاید میشد بهتر کد نوشت یا از یه راه راحت تر استفاده کرد.

[csvbcscp]

شی گرایی یکی از اولین مفاهیمی است که هر برنامه نویس دات نت به آن احتیاج دارد، خانم زهرا بیات یک کتاب مختصر و مفید با این موضوع نوشته که می تونید از سایت ویکیو دانلود کنید