10 نکته برای نوشتن بهتر توضیحات در سورس کد

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

1) توضیحات را مرتب و پشت سر هم بنویسید : هنگامی که برای چند خط کد به صورت متوالی کامنت می نویسید بهتر است تمام کامنت ها در یک ستون عمودی تراز شوند تا خواناتر به نظر برسند.

List<User> users = User.GetAll(); //Get all available users
users.Add(aUser);                 //Add a User

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

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

4) به شعور خواننده توهین نکنید! : از توضیح بدیهیات پرهیز کنید. نوشتن توضیحاتی شبیه به توضیحات زیر را کنار بگذارید :

if(CanSave == true) //if User can Save
SaveToFile();       //then Save it to file!

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

5) از یک استاندارد مشخص پیروی کنید : مخصوصاً وقتی با یک تیم برنامه می نویسید این مورد را حتماً رعایت کنید. کامنت کردن کدها بر اساس استاندارد و استفاده از ابزارهای مربوطه بسیار توصیه می شود. به طور مثال در C# استفاده از توضیحات XML مرسوم است و کار شما را آسان می کند.

6) توضیحات را همزمان با نوشتن کد بنویسید : زمانی که شروع به کد نویسی می کنید ذهن شما بر روی مسئله جاری متمرکز شده است و بهترین زمان برای نوشتن توضیحات در مورد کد مورد نظر است. اگر نوشتن توضیحات را به زمان دیگری موکول کنید ممکن است توضیحاتی که بعداً می نویسید همانی نباشد که در ابتدا در ذهن شما بوده است.

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

8 ) با تغییر کدها، توضیحات را تغییر دهید : همیشه کامنت ها را به صورت موازی با کدهای خود تغییر دهید. اگر کدهای خود را تغییر دهید اما توضیحاتش را آپدیت نکنید، به جای اینکه این توضیحات در آینده سودمند باشند، نگهداری کد را سخت تر خواهند کرد. نداشتن توضیحات در سورس کد بهتر از داشتن توضیحات غلط در آن است. حواستان به ابزارهای Refactoring باشد که کدها را به صورت خودکار تغییر می دهند اما توضیحات را بدون تغییر رها می کنند.

9) از برچسب های معنی دار استفاده کنید : زمانی که در یک تیم کار می کنید، سعی کنید از برچسب های معنی دار و قراردادی بین اعضای تیم برای منظورهای مختلف استفاده کنید. به طور مثال بسیاری از برنامه نویس ها از برچسبی مثل «//TODO :» استفاده می کنند تا مشخص کنند قسمتی از کد نیاز به کار اضافی دارد و یا از برچسبی مثل «Temp» جهت نوشتن کدهای موقت که بعداً باید حذف یا جایگزین شوند استفاده می کنند. شاید برچسب ها توضیحی در مورد کد نباشند، اما به جای آن پیغامی را به شما و دیگر هم تیمی های شما یادآوری می کنند.

10) کد خوب، خودش را توضیح می دهد : همیشه بخاطر داشته باشید که کد خوب بهترین داکیومنت برای خودش است. اگر دوست ندارید یا حوصله ندارید برای کدهایتان کامنت بنویسید بهتر است کدهایی بنویسید که خودشان را توضیح می دهند. برای نوشتن چنین کدهایی باید نام متغیرها، کلاس ها، متدها و پراپرتی ها را کاملاً معنی دار انتخاب کنید. به طور مثال شما نیازی به نوشتن کامنت برای متد زیر ندارید :

AddUserToDatabase(User user)

هر کسی با مشاهده متد بالا متوجه می شود که کار آن اضافه کردن یک کاربر به دیتابیس است.

 

منبع : 13 Tips to Comment Your Code

استفاده از jQuery UI Dialog در ASP.NET

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

خوشبختانه کتابخانه jQuery UI دارای یک کامپوننت Dialog مناسب برای استفاده در محیط وب است که با تمامی مرورگرهای مدرن سازگاری کامل دارد و به علت اینکه بر روی کتابخانه jQuery کار می کند در تمام پلت فرم های توسعه وب قابل استفاده است.

برای استفاده از این Dialog در یک صفحه ASP.NET باید کتابخانه های jQuery و jQuery UI را دانلود کنید و در صفحه مورد نظر خود به آن ها ارجاع اسکریپتی بدهید. در این مطلب یک مثال ساده در مورد استفاده از jQuery UI Dialog  را توضیح خواهیم داد. پروژه مثال این مطلب را از اینجا دریافت کنید. قصد ندارم تمام کدهای نوشته شده در این پروژه مثال را توضیح بدهم، فقط نکات مهم مربوط به موضوع بحث را خواهید خواند. خواندن سورس کد و مشاهده مثال بهتر از توضیحات متنی به شما کمک می کند.

پس از دانلود و اجرای پروژه، با یک صفحه ساده مواجه خواهید شد که یک دکمه با عنوان Set Values در آن وجود دارد. با کلیک کردن بر روی این دکمه یک دیالوگ jQuery شبیه به تصویر زیر خواهید داشت :

دکمه Cancel دیالوگ را می بندد و دکمه OK برچسب های روی صفحه را با مقادیر تکست باکس ها هماهنگ می کند. jQuery UI Dialog در حالت معمول بعد از تگ form در ASP.NET رندر می شود که این باعث می شود تا دکمه های موجود در دیالوگ هیچ Post Backی به صفحه نداشته باشند که البته این مشکل به راحتی حل می شود. برای اینکه دکمه های موجود در دیالوگ بدون رفرش شدن صفحه کار خود را انجام بدهند، محتویات دیالوگ را درون یک UpdatePanel قرار می دهیم. مهمترین کدهایی که در مورد آن ها بحث می کنیم، کدهای جاوا اسکریپت زیر هستند :

<script type="text/javascript">
 $(document).ready(function () {
 $('#divValues').dialog({
 autoOpen: false,
 draggable: true,
 maxHeight: 440,
 width: 400,
 modal: true,
 title: "Enter values",
 open: function (type, data) {
 $(this).parent().appendTo("form");
 }
 });
 });

 function openDialog(id) {
 $('#' + id).dialog("open");
 }

 function closeDialog(id) {
 $('#' + id).dialog("close");
 }

 </script>

در واقع این کدهای بالا هستند که دیالوگ jQuery را می سازند و آن را باز و بسته می کنند. علامت $ که در ابتدای کد بکار رفته نشان دهنده این است که در حال استفاده از توابع کتابخانه jQuery هستیم. تابع اول دیالوگ را با خصوصیات مشخص شده مقدار دهی می کند. لیست کامل این خصوصیات را می توانید اینجا مشاهده کنید و بر اساس نیاز خود تغییر دهید. بعد از اجرای برنامه، تا زمانی که تابع openDialog صدا زده نشود، دیالوگ ما هم نشان داده نخواهد شد و در واقع jQuery آن را از دید کاربر مخفی نگه خواهد داشت. محتویات یک دیالوگ باید در یک div قرار بگیرند که نام آن باید برای dialog مشخص شود. نکته ای که شما به عنوان یک برنامه نویس ASP.NET در این مورد باید بدانید این است که حتماً UpdatePanel دیالوگ را داخل این div قرار دهید تا کدهایتان به درستی کار کند.

ویژگی خوب کتابخانه jQuery UI سبک بودن و سازگار بودن با اکثر مرورگرهای مدرن امروزی است. برای تغییر ظاهر دیالوگ هم دست شما بسیار باز است و می توانید از تم های آماده jQuery UI استفاده کنید و یا حتی استایل خود را برای آن بسازید.

دریافت پروژه مثال

ویژگی جدید Code-first برای Entity Framework

با محبوب شدن NHibernate و کتابخانه های وابسته به آن مثل Castle ActiveRecord و Fluent NHibernate، مایکروسافت به تازگی ویژگی جدیدی را به صورت Preview برای ORM خود یعنی Entity Framework عرضه کرده است که قابلیت هایی جدیدی را به توسعه دهندگان می دهد تا به جای سر و کله زدن با ابزارهای Designer و فایل های نگاشت XML، بر کدهای شیء گرا تمرکز داشته باشند. با این ویژگی شما به راحتی می توانید مدل خود را با استفاده از کلاس های معمولی بسازید و از EF بخواهید تا دیتابیس را از روی مدل نوشته شده توسط شما بسازد.

نسخه ای که به تازگی عرضه شده آخرین نسخه کتابخانه Code first قبل از ارائه نسخه اصلی خواهد بود. برای دانلود این ویژگی جدید به این صفحه از سایت مایکروسافت بروید. بعد از نصب کتابخانه، برای استفاده از این ویژگی پروژه جدیدی از نوع Class Library ایجاد کنید و به فایل EntityFramework.dll در مسیر نصب شده ارجاع دهید. یک کلاس به نام Blog با محتویات زیر بسازید :

using System.Collections.Generic;<br />
using System.ComponentModel.DataAnnotations;<br />
using System.Data.Entity;</p>
<p>namespace BlogModel<br />
{<br />
public class Blog<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Title is required.")]<br />
public string Title { get; set; }</p>
<p>public bool ShowInSearchEngines { get; set; }</p>
<p>public string Description { get; set; }</p>
<p>public IList<Post> Posts { get; set; }<br />
}<br />
}

می خواهیم مدلی بسازیم برای نگهداری اطلاعات یکسری وبلاگ به علاوه پست ها و کامنت های هر کدام. در اینجا شما می توانید کلاس هایی ایجاد کنید که هر کدام نشان دهنده یک موجودیت در دیتابیس شما خواهند بود. این کلاس ها می توانند کلاس های ساده POCO باشند که نیازی ندارند از کلاس دیگری به ارث بروند تا نقش یک Entity را برای شما بازی کنند. این ویژگی به شما کمک می کند تا یک مدل ساده، قابل درک، تمیز و قابل تست برای پروژه خود بسازید. کلاس های مثال ما همگی POCO هستند.

using System.Collections.Generic;<br />
using System.Data.Entity;<br />
using System.ComponentModel.DataAnnotations;</p>
<p>namespace BlogModel<br />
{<br />
public class Post<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Title is required.")]<br />
public string Title { get; set; }</p>
<p>[StringLength(4000)]<br />
[Required(ErrorMessage="Content is required.")]<br />
public string Content { get; set; }</p>
<p>public Blog Blog { get; set; }</p>
<p>public IList<Comment> Comments { get; set; }<br />
}<br />
}

کلاس Post برای نگهداری اطلاعات یک پست وبلاگ نوشته شده است. Post با موجودیت Blog یک رابطه چند به یک و با موجودیت Comment یک رابطه یک به چند دارد که با استفاده از پراپرتی در آن مشخص شده اند. با استفاده از قابلیت های فضای نام DataAnnotations می توان مشخصات یک موجودیت را اعتبار سنجی نمود. این اعتبار سنجی با استفاده از تعریف Attribute بر روی مشخصات انجام می شود. به طور مثال پراپرتی Content در این موجودیت می تواند تا 4000 کاراکتر را در خود ذخیره کند و حتماً باید مقداری برای آن وارد شود وگرنه یک استثنا رخ خواهد داد که باید توسط برنامه نویس هندل شود.

using System.Data.Entity;<br />
using System.ComponentModel.DataAnnotations;</p>
<p>namespace BlogModel<br />
{<br />
public class Comment<br />
{<br />
[Key]<br />
public long ID { get; set; }</p>
<p>[Required(ErrorMessage="Name is required.")]<br />
public string Name { get; set; }</p>
<p>[Required(ErrorMessage="Email is required.")]<br />
public string Email { get; set; }</p>
<p>public string URL { get; set; }</p>
<p>[Required]<br />
public string Content { get; set; }</p>
<p>public Post Post { get; set; }<br />
}<br />
}<br />

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

using System.Data.Entity;</p>
<p>namespace BlogModel<br />
{<br />
public class MyBlogPlatform: DbContext<br />
{<br />
public DbSet<Blog> Blogs { get; set; }<br />
public DbSet<Post> Posts { get; set; }<br />
public DbSet<Comment> Comments { get; set; }<br />
}<br />
}<br />

در واقع این کلاس باعث می شود تا کلاس های ساده ی ما با دیتابیس بوسیله Map کردن کلاس ها به جدوال و پراپرتی ها به فیلدها و رابطه ها  ارتباط برقرار کنند. کدهای بالا تمام کدهای لازمی بود که ما برای ایجاد مدل و لایه دسترسی به داده های خود احتیاج داشتیم. آخرین مرحله قبل از استفاده از این مدل، مشخص کردن Connection String برای ایجاد دیتابیس از روی آن است که می توانید در web.config آن را به صورت زیر مشخص کنید :

<connectionStrings><br />
 <add name="MyBlogPlatform"  connectionString="Data Source=.\SQLEXPRESS;Initial Catalog=MyBlogPlatform;Integrated Security=True"  providerName="System.Data.SqlClient"  />

EF Code first به صورت پیش فرض به دنبال رشته اتصالی در فایل web.config می گردد که با کلاس Context شما همنام باشد. چون کلاس Context ما در این مثال MyBlogPlatform است، EF هم به دنبال رشته اتصالی به همین نام خواهد گشت و از آن برای ایجاد دیتابیس یا اتصال به دیتابیس موجود استفاده خواهد کرد. برای اینکه مطمئن شویم کارمان مشکلی ندارد کدی برای ایجاد یک موجودیت بلاگ در دیتبایس در مکان مناسب (مثل کلیک یک دکمه در صفحه) می نویسیم :

MyBlogPlatform blogPlatform = new MyBlogPlatform();<br />
 Blog blog = new Blog()<br />
 {<br />
 Title = "Farasun",<br />
 ShowInSearchEngines = true,<br />
 Description = "A blog about programming"<br />
 };<br />
 blogPlatform.Blogs.Add(blog);<br />
 blogPlatform.SaveChanges();<br />
 

در این نقطه کار ما به پایان رسیده و شما قادر خواهید بود که با مدل خود کار کنید. EF تمام کارهای مربوط به دیتابیس را انجام خواهد داد و شما فقط باید بر روی قوانین تجاری و رابط کاربری اپلیکیشن خود وقت بگذارید. به طور مثال برای کوئری گرفتن توسط LINQ می توانیم چنین کدی برای مدل خود بنویسیم :

MyBlogPlatform myBlogPlatform = new MyBlogPlatform();<br />
 var query = from x in myBlogPlatform.Posts<br />
 where x.Title.Contains(“Entity Framework”)<br />
 select x;<br />
 

اگر سری آموزش های Castle ActiveRecord در این وبلاگ را دنبال کرده باشید، با این پست غریبه نبوده اید. اینطور که به نظر می رسد تیم Entity Framework راه درستی برای ادامه توسعه این پروژه انتخاب کرده و در آینده ای نزدیک باید شاهد قابلیت های بیشتری در جهت بهبود کارایی این ORM باشیم.

گذاشتن محدودیت برای برنامه نویسان… اما به چه قیمتی!

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

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

محدودیت دسترسی به اینترنت

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

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

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

محدودیت ساعت ورود و خروج

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

محدودیت صحبت با تلفن شخصی

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

محدودیت زمان استراحت

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

این را بخاطر داشته باشید که برنامه نویسی که به طور مداوم کدنویسی می کند و به مانیتور خیره است نه تنها کارایی بالاتری ندارد بلکه مطمئن باشید کیفیت کارش از برنامه نویسی که هم کار می کند و هم استراحت، پایین تر است. می توان با استراحت های دوره ای در حین کار، مثل نوشیدن قهوه، خوردن میان وعده، گپ زدن در مورد مطالب غیر کاری و خواندن یک مطلب خنده دار به همراه همکاران در حال استراحت، کارایی را بالا برد. سخت کار کردن هیچ ربطی به 4-5 ساعت پشت سر هم کد نویسی و نشستن و خیره شدن به مانیتور ندارد! درست کار کردن مهم است.

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

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

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

نتیجه

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

farasun.wordpress.com

خواندن مطلب مرتبط : یک محیط سفارشی شده; تمام چیزی که یک برنامه نویس می خواهد!

مشترک فراسان شويد

پ.ن : ایده این مطلب از مطلب آقای آواژ با عنوان «تفکیک مسائل شخصی از محیط کار» به ذهنم خطور کرد.