نود و هفت چیزی که هر برنامه‌نویسی باید بداند‍:

نود و هفت چیزی که هر برنامه‌نویسی باید بداند‍

خلاصه:

نود و هفت چیزی که هر برنامه‌نویسی باید بداند:

1. بدهی فنی

2.به‌کارگیری اصولی از توابع در برنامه‌نویسی

3.نیاز کاربر چیست؟

4.استاندارهای کدنویسی

5.ساده زیباست

6.آشنایی با مفهوم ریفکتورینگ در کدنویسی

7.نظافت را رعایت کنید!

8.پیش از آن که دیگران را متهم کنید، کد خود را چک کنید!

9.انتخاب ابزار مناسب

10. برنامه‌های خود را به زبان مشتریان بنویسید!

11. طرح‌های خود را بی‌نقص کنید

12. به چیدمان کدها توجه کنید!

13. نقد و بررسی کدها

14. کامنت‌گذاری را فراموش نکنید

15. تنها توضیحاتی را بنویسید که کدهایتان قادر به شرح آن‌ها نباشند!

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

17. همواره در حال یادگیری موضوعات جدید باشید

18. ویژگی‌های یک API با طراحی مناسب

19. از ابتدای کار توسعهٔ اپلیکیشن خود روی فرآیند نصب و دیپلوی آن به طور پیوسته کار کنید.

20. مدیریت اکسپشن‌ها

21. تمرین آگاهانه لازمهٔ حرفه‌ای شدن است!

22. پشت هر خط از کد شما می‌بایست یک منطق وجود داشته باشد!

23. DSL چیست و چرا آشنایی با آن در حوزهٔ برنامه‌نویسی اهمیت دارد؟

24. از ساختارشکنی نترسید!

25. برای تست نرم‌افزار از دیتای واقعی استفاده کنید.

26. حتی یک ارور را هم نادیده نگیرید!

27. فرهنگ استفاده از یک زبان برنامه‌نویسی را در کنار سینتکس آن بیاموزید.

28. اکسپش‌ها را به راحت‌ترین شکل ممکن هَندل کنید.

29. فرایند توسعه یک نرم‌افزار خوب اصلاً شانسی نیست.

30. آشنایی با قانون DRY

31. آشنایی با مراحل توسعهٔ نرم‌افزار

32. به‌کارگیری درست از اصول برنامه‌نویسی شیٔ‌گرا

33. اعداد اعشاری با خطای محاسباتی در کامپیوتر ذخیره می‌شوند.

34. با مشارکت در پروژه‌های اپن‌سورس، حس جاه‌طلبی خود را ارضاء کنید!

35. قانون طلایی طراحی API

36. کسی که چند سال است کدنویسی می‌کند، اصلاً علامهٔ دهر نیست!

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

38. چگونه به یک باگ نگاه کنیم؟

39. با حذف کدهای اضافی، سورس‌کد خود را بهبود بخشید.

40. برنامه‌هایی که می‌نویسید را کاربرپسند کنید.

41. فرایندهای برون برنامه‌ای، زمان پاسخگویی نرم‌افزار را تحت‌الشعاع خود قرار می‌دهند.

42. Build اصولی ارائه کنید (به طور کلی، در شاخه ی برنامه‌نویسی و توسعه ی نرم‌افزار، Build به فرایندی گفته می‌شود که در آن سورس‌کد به برنامه یی قابل‌اجرا و قابل استفاده مبدل می‌گردد که معمولاً با یک شناسه -مثلا ۱۷- شناخته می‌شود که قبل از انتشار نهایی نرم‌افزار و در فرایند تست نرم‌افزار ایجاد می‌گردد. یکی از فرایندهای مهم در بیلد کردن، کامپایل کردن سورس‌کد است که در این فرایند سورس‌کد نرم‌افزار به کدهای قابل‌اجرا توسط ماشین تبدیل می‌شوند.).

43. استفادهٔ بهینه از ابزارهای کامندلاینی

44. یادگیری هم‌زمان بیش از یک زبان برنامه‌نویسی(در پایان هم می‌باید این نکته را یادآور شد که یادگیری یک زبان صرفاً به یادگیری سینتکس اش و نوشتن یک برنامه ی Hello World خلاصه نمی‌شود بلکه نیاز به ماه‌ها کار مستمر و نوشتن پروژه‌های مختلف با آن زبان و درگیر شدن با بخش‌های مختلف زبان دارد.).

45. IDE خود را مثل موم در دست بگیرید (شاید در ابتدای راه استفاده ی صرف از کلیدهای میانبر کمی سخت باشد و به خاطر سپردن آن‌ها کاری دشوار، اما در طول زمان کدنویسی برایمان به مراتب لذت بخش تر خواهد شد.).

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

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

48. آشنایی با نحوهٔ به‌کارگیری دیتابیس‌های رابطه‌ای MySQL

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

50. خود را با مهارت تخمین زدن تجهیز کنید!

51. IDE یا Editor مسئله‌این است!( در کل، IDEها بسیار خوب هست اما به‌نظر می‌رسد که در ابتدای راه کدنویسی،‌ بیش از آن‌که مفید باشند و در دراز مدت کمک برنامه‌نویس کنند، وی را تنبل و وابسته بار می‌آورند؛ لذا توصیه آن است که در حین یادگیری اصول کدنویسی و یا مبانی یک زبان برنامه‌نویسی، همواره از ادیتورهای ساده‌ای مثل موارد فوق‌الذکر استفاده نمایید تا اصول و زیروبم زبان مد نظر در ذهنتان نهادینه شود سپس زمانی‌که احساس کردید به‌خوبی می‌دانید که مثلاً فانکشن‌های مختلف به‌ چه شکلی نوشته می‌شوند، ارتباط بخش‌های مختلف یک زبان‌ برنامه‌نویسی خاص به چه شکل است و غیره، در آن موقع می‌توانید برای آن‌که سرعت کدنویسی خود را افزایش دهید -که خود این مسئله هم به‌نوعی حاکی از حرفه‌ای بودن است- می‌توانید به استفاده از یک IDE روی آورید.).

52. ارسال پیام خطا به دولوپر توسط نرم‌افزار(به‌طورکلی، لاگ‌ها اطلاعات بسیار ارزشمندی از نحوهٔ کارکرد نرم‌افزار در اختیار دولوپر قرار می‌دهند و این درحالی است که بسیاری از دولوپرها اصلاً توجهی به این دست اطلاعات ارزشمند نمی‌کنند! ما به‌سادگی و با استفاده از لاگ‌های نرم‌افزارمان می‌توانیم روزبه‌روز دست به بهبود سورس‌کد زده و باگ‌ها، خطا‌ها و اکسپشن‌ها را به حداقل برسانیم).

53. چیزهای اضافی را لود نکنید!( در صنعت توسعهٔ نرم‌افزار منظور از اصطلاح Third Party، کامپوننت‌های توسعه داده شده توسط هر تیم توسعه، شرکت و یا گروهی به‌غیر از توسعه‌‌دهندهٔ اصلی یک محصول (لایبرری، زبان‌برنامه‌نویسی، فریمورک و غیره) است که چنین کامپوننت‌هایی یا به‌صورت اپن‌سورس و رایگان و یا به‌صورت پولی عرضه می‌گردند. به‌طورکلی، تمیز بودن سورس‌کد پروژه -که نبود لایبرری‌ها، ماژول‌ها، کلاس‌ها و فانکشن‌های بلااستفاده در آن به‌نوعی مرتبط با تمیز بودن است- نشان از حرفه‌ای بودن دولوپرش دارد اما این تمیزی سورس‌کد بیش از هر چیزی، کمک به دیگر دولوپرهایی خواهد کرد که ممکن است در آینده بخواهند روی چنین پروژه‌ای کار کنند).

54. چه‌موقع و چگونه از راه‌کارهای موقتی در کدنویسی استفاده کنیم؟

55. استفادهٔ نادرست از اینترفیس‌ها را غیرممکن سازید

56. تا حد ممکن همه‌ چیز را شفاف‌سازی کنید.

57. ضرورت آشنایی با مفاهیم کانکارنسی و پاراللیزم

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

(به‌طور خلاصه، یک دولوپر خوب کسی است که کدی بنویسد که از ویژگی‌های زیر برخوردار باشد:
- اسامی کلاس‌ها، فانکشن‌ها، متغیرها و … قابل‌فهم اما درعین‌حال ساده باشند.
- ساختار فولدرها و فایل‌ها همگون و سرراست باشند.
- استاندارد کدنویسی یکسانی در جای‌جای پروژه اِعمال شده باشد.
- به‌گونه‌ای کدنویسی کند که به‌جای کامنت‌گذاری، خود سورس‌کد گویای ماهیتش باشد.
- و درنهایت کدنویسی‌اش طوری باشد که اگر یک برنامه‌نویس تازه‌کار هم به مرور سورس‌کد پرداخت، بتواند ارتباط بین اجزای مختلف کد را درک کند.

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

59. دولوپری که نداند Polymorphism چیست، دولوپر نیست!( این اصطلاح در برنامه‌نویسی شیٔ‌گرایی به الگویی اشاره دارد که بر آن اساس، کلاس‌های مختلف با عملکردهای مجزا از یکدیگر می‌توانند از ساختار و کاربری یکسانی بهره‌مند گردند. در حقیقت، چندشکلی یا پالیمورفیزم این‌گونه تفسیر می‌شود که ما فانکشنی ثابت داریم تحت‌عنوان ()calcArea اما این درحالی است که این فانکشن بسته به این‌که در کدام کلاس قرار گرفته باشد، عملکردی متفاوت از خود نشان خواهد داد و به‌نوعی خود را در چند شکل مختلف عرضه می‌کند.

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

60. تستر‌های نرم‌افزار دشمن دولوپرها نیستند!

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

62. فقط سورس‌کد است که حرف اول و آخر را می‌زند (فقط سورس‌کد است که حرف اول و آخر را می‌زند).

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

64. اهمیت برنامه‌نویسی دونفره

65. آشنایی با تفاوت Static Typing و Dynamic Typing در برنامه‌نویسی (در اینجا منظور از Type، نوع داده‌ای است که با آن سرورکار خواهیم داشت. به‌طورکلی، زبانی که به‌اصطلاح Statically Typed است در آن نوع متغیرها در زمان کامپایل شدن (Compile Time) برنامه‌ مشخص می‌گردد که از آن جمله می‌توان به زبان‌های جاوا، اسکالا، سی‌شارپ، سی و سی‌پلاس‌پلاس اشاره کرد و همین مسئله منجر به این خواهد گشت که پرفورمنس برنامه بالا رود چرا که هر دفعه که برنامه اجرا می‌گردد، دیگر نیازی به چک کردن نوع متغیرها نخواهد بود. زبانی هم که به‌اصطلاح Dynamically Typed است در آن نوع متغیرها در حین اجرای برنامه‌ (Run Time) مشخص می‌شود و دولوپر در حین کدنویسی نیازی به مشخص کردن دیتاتایپ‌ متغیر نخواهد داشت که از آن جمله می‌توان به زبان‌های پایتون، جاوااسکریپت و پی‌اچ‌پی اشاره کرد).

66. تا حد ممکن از نمایش ارورها برای کاربر اجتناب کنید!

67. به چه برنامه‌نویسی حرفه‌ای می‌گویند؟

68. از ورژن کنترل غافل نشوید!( از جمله پلتفرم‌های ورژن کنترل رایج می‌توان به Git و SVN اشاره کرد).

69. ماوس و کیبورد را کنار بگذارید!( به‌عنوان راه‌کاری عملی، می‌توان گفت که پس از گیر کردن در یافتن یک باگ و یا به‌طورکلی پس از چندین ساعت کدنویسی، کمی استراحت کردن شامل گوش دادن به ماوسیقی مورد علاقه،‌ نوشیدن چای یا قهوه و کارهایی از این دست می‌تواند انرژی مورد نیاز برای ادامهٔ کارمان را تأ‌مین سازد. به‌عبارت دیگر، گاهی‌اوقات بهترین روش حل مسئله، کنار گذاشتن ماوس و کیبورد است.).

70. کدخوانی کنید!

71. تعاملات اجتماعی کلید موفقیت است!( به‌طورکلی، دولوپرهایی که در پروژه‌های اپن‌سورس شرکت می‌کنند، در رویدادهای کدنویسی مشارکت دارند و دانسته‌های خود را با دیگر دولوپرهای غالباً تازه‌کار به اشتراک می‌گذارند، وبلاگ‌نویسی می‌کنند و به هر شکلی به تعامل با دیگر افراد می‌پردازند، تأثیر به‌مراتب بیشتری در صنعت نرم‌افزار می‌توانند داشته باشند. درنتیجه، همواره به‌خاطر داشته باشیم که در صنعت توسعهٔ نرم‌افزار تعملات اجتماعی همچون هر حرفه‌ٔ دیگری دارای اهمیت بسیار بالایی است؛ از تعامل ما مشتریان گرفته تا مدیر پروژه، تستر نرم‌افزار و دیگر دولوپرها، همواره می‌بایست روی مهارت ارتباطات و مذاکره کار کرده و در این حوزه هم علاوه بر مهارت‌های کدنویسی تسلط یابیم).

72. تا حد ممکن دست به اختراع مجدد چرخ نزنید!

73. تا حد ممکن از Singleton Pattern استفاده نکنید.

74. وابستگی‌های زیاد دشمن ریفکتورینگ هستند!( برای جلوگیری از مشکلاتی این چنین، می‌بایست در حین طراحی معماری نرم‌افزار تا حد ممکن میزان وابستگی‌ها را به حداقل رساند. گرچه به صفر رساندن میزان وابستگی عملاً غیرممکن است، اما هرچه میزان وابستگی مابین بخش‌های مختلف سورس‌کد کمتر باشد، و یا این وابستگی‌ها حداقل در حوزهٔ یک ماژول باشند و نه بیشتر، ریفکتورینگ کد به مراتب راحت‌تر خواهد شد.).

75. هرچه تعداد خطوط کد کمتر، بهتر!

76. آشنایی با قانون Single Responsibility (یکی از خصیصه‌های معماری نرم‌افزاری خوب این است که «چیزهایی که ماهیت مشابهی داشته، به دلایل یکسانی دستخوش تغییر می‌شوند و در یک کلام، به یک خانواده تعلق دارند را باید در کنار یکدیگر قرار داد و الباقی را مجزا ساخت.» از دید فنی، به چنین قابلیتی Single Responsibility Principle (اصل تک وظیفه‌ای) یا به طور خلاصه SRP گفته می‌شود. به عبارت دیگر، این اصل حاکی از آن است که یک ماژول، کلاس، فانکشن یا هر چیزی می‌بایست وظیفه‌ای واحد داشته، متمرکز بر یک تَسک بوده و صرفاً به یک دلیل تغییر یابند نه این که به محض مواجه با یک نیاز در هر بخشی از نرم‌افزار، نیاز داشته باشیم تا آن را دستخوش تغییر سازیم.).

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

78. تا حد ممکن همه‌ چیز را خودکار کنید.

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

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

81. تست‌ها علاوه بر صحیح بودن، می‌بایست دقیق هم باشند (به‌طورکلی ۲ راه برای طراحی معماری یک نرم‌افزار وجود داره؛ راه اول این‌که آن‌قدر آن‌را ساده طراحی کنی که هیچ نقصی در آن وجود نداشته باشه و راه دوم این‌که آن‌قدر آن‌را پیچیده طراحی کنی که هیچ نقصی آشکارا در آن دیده نشه! با این تفاسیر، به این نتیجه می‌رسیم که تست نرم‌افزاری در صنعت برنامه‌نویسی که روز به روز شاهد اپلیکیشن‌های پیچیده‌‌تری در آن هستیم الزامی است اما این در حالی است که تست‌ها علاوه بر سنجش صحت نرم‌افزار یا اپلیکیشن، می‌بایست دقیق هم باشند.).

82. تست نرم‌افزار و سورس‌کد را آخر شب‌ها و آخر هفته‌ها انجام دهید!

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

84. از نوشتن کدهای اضافی پرهیز کنید.

85. اهمیت برنامه‌نویسی دونفره در کدنویسی را هرگز نادیده نگیرید.

86. منفی در مفنی می‌شود مثبت!

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

88. ابزارهای یونیکسی دوست دولوپرها هستند!

89. استفادهٔ درست از الگوریتم‌ها و دیتا استراکچرها

90. با لاگ‌گیری Verbose دچار دردسر خواهید شد!( به طور کلی، منظور از Verbose Loggin نوعی از لاگ‌گیری است که در آن اطلاعاتی بیش از آنچه لازم است ذخیره خواهیم ساخت (Verbose در لغت به معنای «استفاده از واژگان بیش از حد» است). در واقع، Verbose Loggin زمان به کار می‌آید که نیاز به موشکافی دقیق یک سیستم نرم‌افزاری داشته باشیم و بخواهیم آن را دیباگ کنیم و در حالت عادی غیرفعال می‌گردد چرا که منجر به ایجاد لاگ فایل‌های بسیار حجیم خواهد شد.)

91. درک تفاوت مفاهیم DRY و WET در کدنویسی بهینه (به طور کلی، مزیت DRY نسبت به WET علاوه بر پرفورمنس بالاتر و سورس‌کد تمیزتر، امکان دیباگ کردن سریع‌تر سورس‌کد خواهد بود که این مسأله در پروژه‌های بزرگ بسیار حیاتی است).

92. تعامل مابین دولوپرها و تسترها

93. طوری کد بزنید که گویی قرار است تا آخر عمر سورس‌کدتان را ساپورت کنید! (به خاطر داشته باشیم کدی که ما به عنوان دولوپر می‌نویسیم، به نوعی جزو رزومهٔ ما محسوب می‌گردد و دیگر دولوپرهایی که با کدهای ما کار خواهند کرد، از روی نحوهٔ کدنویسی ما به میزان حرفه‌ای بودن ما نیز پی خواهند برد و در دراز مدت ایماژی مثبت یا منفی نسبت به ما شکل خواهد گرفت).

94. تا حد ممکن فانکشن‌های کوچک بنویسید.

95. برای دولوپرها تست بنویسید نه برای ماشین‌ها!

96. مراقب سورس‌کد باشید!( به طور کلی، اگر قصد دارید حرفه‌ای به نظر برسید، بایستی کدهای حرفه‌ای بنویسید و برای نوشتن کدهای حرفه‌ای هم می‌توانید استراتژی‌های زیر را مد نظر قرار دهید: - تحت هر شرایطی، صرفاً به کار کردن کد تحت شرایط عادی رضایت ندهید؛ بلکه تمام تلاش خود را به‌کارگیرید تا تمامی جوانب کار را بسنجید. در واقع، از سالم بودن کد (قابل‌اجرا بودن کد تحت هر شرایطی) اطمینان حاصل کنید. - کدی بنویسید که از یکسو هر دولوپر دیگری بتواند از آن سر در بیاورد و از سوی دیگر، قابل پشتیبانی و گسترش باشد. - امروزه کمتر دولوپر موفقی را می‌توان یافت که به تنهایی کار کند؛‌ اکثراً یا در شرکت‌های نرم‌افزاری مشغول به کار هستند و یا اگر هم در منزل روی پروژه‌های اپن‌سورس کار می‌کند، با دیگر دولوپرهای سراسر دنیا در تعامل هستند. در همین راستا، روی مهارت‌های ارتباطی خود با دیگر همکاران فنی/غیرفنی نیز کار کنید. - هر موقعی که با کدی برخورد کردید، تمام تلاش خود را به‌کارگیرید تا حتی اگر شده‌اندکی آن را بهبود بخشید (اگر توانستید که ساختار را بهبود بخشید و اگر امکان‌پذیر نبود، حداقل با کامنت‌گذاری درک آن را بهبود بخشید). - گرچه دولوپرها همواره در معرض تکنولوژی‌های جدیدی هستند اما این هرگز بدان معنا نیست که در هر پروژه‌ای باید از جدیدترین تکنولوژی‌ها استفاده کنید بلکه بایستی نیاز پروژه را درک کرده و بسته به ماهیت، نیازها و زیرساخت پروژه اقدام به استفاده از زبان‌ برنامه‌نویسی، لایبرری، فریمورک و یا ابزار مناسب کنید.).

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