বিকাশকারীদের জন্য প্রযুক্তিগত লেখা

এইচটিএমএল, সিএসএস, জাভাস্ক্রিপ্ট, পাইথন, পিএইচপি, সি++, ডার্ট—এখানে অনেকগুলি প্রোগ্রামিং ভাষা রয়েছে এবং আপনি হয়ত সেগুলির বেশ কয়েকটিতে সম্পূর্ণ সাবলীল হতে পারেন! কিন্তু আমরা যত বেশি এবং আরও ভাল কোড লেখার লক্ষ্য রাখি, আমরা যেভাবে দৈনন্দিন ভাষায় লিখি এবং যোগাযোগ করি তা আরও বেশি গুরুত্বপূর্ণ হয়ে ওঠে… এবং সম্ভবত উপেক্ষিতও।

আমরা কোড সম্পর্কে এবং তার চারপাশে যেভাবে লিখি তা যুক্তিযুক্তভাবে কোডের মতোই গুরুত্বপূর্ণ। এবং আপনি সেই লাইনে পড়ে গেলেও, আমরা সকলেই একমত হতে পারি যে আমাদের কথায় কোডের কার্যকারিতা এবং আঘাত উভয়ই সাহায্য করার সম্ভাবনা রয়েছে।

এই নিবন্ধে, আমি এই দুটি আপাতদৃষ্টিতে স্বতন্ত্র ক্ষেত্র — প্রোগ্রামিং এবং লেখা — কীভাবে একত্রিত হতে পারে এবং আমাদের বিকাশকারীর দক্ষতাকে পরবর্তী স্তরে নিয়ে যেতে পারে তার রূপরেখা দিতে চাই৷

অপেক্ষা করুন, প্রযুক্তিগত লেখা? হ্যাঁ, আমি ঠিক এটাই বলতে চাইছি। আমি সত্যই বিশ্বাস করি যে আমরা সকলেই কোন না কোন অর্থে লেখক। এবং আমি এখানে আপনাকে লেখার টিপস, পরামর্শ এবং উদাহরণ সহ একটি প্রাইমার দিতে এসেছি কিভাবে এটি আপনাকে একজন ভাল বিকাশকারী এবং যোগাযোগকারী উভয়কেই করে তুলতে পারে।

প্রযুক্তিগত লেখা সর্বত্র আছে

গত বছর, জনপ্রিয় ম্যাক গিট ক্লায়েন্ট, টাওয়ারের পিছনে দলটি 4,000 এর বেশি ডেভেলপারদের জরিপ করা হয়েছে এবং দেখা গেছে যে তাদের প্রায় 50% কোড লিখতে দিনে 3-6 ঘন্টার মধ্যে ব্যয় করে।

এবং হ্যাঁ, এটি একটি সমীক্ষা যা একটি সুন্দর কুলুঙ্গি গোষ্ঠীকে ভোট দেয়, কিন্তু আমি কল্পনা করি আমাদের মধ্যে অনেকেই সেই পরিসরের মধ্যে কোথাও পড়ে যাই। যাই হোক না কেন, একজন বিকাশকারী 24/7 কোড লিখছেন না, কারণ এই পোলটি পরামর্শ দেয়, আমরা অন্যান্য জিনিস করতে প্রচুর সময় ব্যয় করছি।

এতে অন্তর্ভুক্ত থাকতে পারে:

• একটি নতুন বৈশিষ্ট্য প্রদর্শন করা,
• নতুন বৈশিষ্ট্য নথিভুক্ত করা,
• সেই নতুন বৈশিষ্ট্যের সাথে সম্পর্কিত একটি কাজের টিকিট আপডেট করা, বা
• যে নতুন বৈশিষ্ট্য সমর্থন করার জন্য backlogging কাজ.

অবশ্যই, সবসময় বাথরুম বিরতি এবং Wordle জন্য সময় আছে.

যাইহোক, আমরা সাধারণত যে জিনিসগুলি করি তার বেশিরভাগের মধ্যে আপনার টিম, সহকর্মী, ক্লায়েন্ট, ব্যবহারকারী এবং অন্যান্য বিকাশকারীদের মতো লোকেদের সাথে যোগাযোগ করা জড়িত।

তাই আমরা মানুষের সাথে যোগাযোগ করার জন্য আমাদের সময়ের একটি ভাল অংশ ব্যয় করি শব্দ কম্পিউটারের মাধ্যমে আমাদের সাথে যোগাযোগের পাশাপাশি কোড. শব্দগুলি লিখিত ভাষা। এবং যদি আমরা আমাদের কথাগুলি আরও ভালভাবে লিখি তবে আমরা আরও ভাল যোগাযোগ করব। যখন আমরা আরও ভাল যোগাযোগ করি, তখন আমরা যা চাই তা পাওয়ার সম্ভাবনা বেশি।

এটা টেকনিক্যাল রাইটিং 101।

এবং এটি এখানেই শেষ নয়.. কিছু প্রোগ্রামার তাদের নিজস্ব পণ্য তৈরি করতে পছন্দ করে, যার অর্থ তাদের মার্কেটিংকে তাদের কাজের অংশ করতে হবে। এতেও কারিগরি লেখা একটি বিশাল ভূমিকা পালন করে। তাই হ্যা. আমি মনে করি এটি প্রযুক্তিগত লেখা বলা বেশ ন্যায্য প্রকৃতপক্ষে সর্বত্র।

ভাল ব্যাকরণ কি?

সেখানে অনেক প্রোগ্রামিং ভাষা আছে, শেষ জিনিস আমরা চাই অন্য একটি শিখতে হয়.

ব্যাকরণ ইংরেজির একটি অবিচ্ছেদ্য অংশ, এবং এটি যোগাযোগের সম্পূর্ণ সম্ভাবনাকে আনলক করে। এটি আমাদের আরও আনুষ্ঠানিক, পেশাদার এবং সুসঙ্গত করে তোলে।

আমি আপনাকে ভাষার উপর একটি দ্রুত রানডাউন দিতে দিন.

ইংরেজি সিনট্যাক্স

প্রোগ্রামিং ভাষার মতো, ইংরেজির একটি সুনির্দিষ্ট সিনট্যাক্স রয়েছে এবং এটি শব্দ দিয়ে শুরু হয়।

শব্দগুলি ইংরেজির বিল্ডিং ব্লক, এবং তারা আটটি বালতিতে পড়ে:

এই মত চিন্তা UI উপাদানগুলি: এগুলি হল মডুলার টুকরা যা আপনি একটি সম্পূর্ণ এবং শক্তিশালী বাক্য গঠন করতে ঘুরে আসতে পারেন, একইভাবে আপনি একটি সম্পূর্ণ এবং শক্তিশালী বাক্য গঠন করতে পারেন UI. উপাদান সব সময় সব সেখানে থাকা প্রয়োজন? অবশ্যই না! অভিজ্ঞতাটি সম্পূর্ণ করার জন্য আপনার প্রয়োজনীয় অংশগুলির সাথে একটি বাক্য একত্রিত করুন, ঠিক যেমন আপনি একটি ইন্টারফেসের সাথে করবেন।

কণ্ঠস্বর এবং সুর

শব্দভান্ডার, বিরাম চিহ্ন, বাক্যের গঠন এবং শব্দ চয়ন। এগুলো সবই ইংরেজির উপাদান। আমরা ধারণাগুলি ভাগ করতে, আমাদের বন্ধু এবং পরিবারের সাথে যোগাযোগ করতে এবং আমাদের সহকর্মীদের ইমেল পাঠাতে এগুলি ব্যবহার করি।

কিন্তু এটা বিবেচনা করা গুরুত্বপূর্ণ শব্দ আমাদের বার্তাগুলির। এটি আশ্চর্যজনক যে কীভাবে একটি বিস্ময়বোধক বিন্দু একটি বার্তার স্বরকে সম্পূর্ণরূপে পরিবর্তন করতে পারে:

1. আমি প্রোগ্রামিং পছন্দ করি।
2. I মত প্রোগ্রামিং! :)

স্বর জন্য ভয়েস বিভ্রান্ত করা সহজ, এবং তদ্বিপরীত।

কণ্ঠস্বর আমাদের শব্দ চয়নের বিষয় যা প্রেক্ষাপটের উপর নির্ভর করে। উদাহরণস্বরূপ, নতুনদের জন্য একটি টিউটোরিয়াল একটি বন্ধুত্বপূর্ণ ভয়েস বোঝাতে অপবাদ এবং অনানুষ্ঠানিক ভাষা ব্যবহার করার সম্ভাবনা বেশি, যেখানে ডকুমেন্টেশন সরাসরি বিন্দুতে পৌঁছানোর জন্য একটি আনুষ্ঠানিক, গুরুতর এবং পেশাদার পদ্ধতিতে লেখা হতে পারে।

একই বার্তা, দুটি ভিন্ন কণ্ঠে লেখা:

• মজা: "আপনার সামাজিক নেটওয়ার্ক প্রসারিত করুন এবং এখন যা প্রবণতা চলছে সে সম্পর্কে আপডেট থাকুন।"
• গুরুতর: "একটি বৃহত্তম সামাজিক নেটওয়ার্কিং অ্যাপ এবং অনলাইন চাকরির বাজারে চাকরি খুঁজুন।"

ভুলবশত এমন বার্তা লেখা অস্বাভাবিক নয় যেগুলি অবমাননাকর, আপত্তিকর, এবং অ-পেশাদার হিসাবে আসে৷ এই হল যেখানে স্বন খেলার মধ্যে আসে। উচ্চস্বরে আপনার বার্তা পড়ুন, অন্য লোকেদের আপনার জন্য সেগুলি পড়তে বলুন এবং আপনার বিরাম চিহ্ন এবং বাক্যের গঠন নিয়ে পরীক্ষা করুন৷ এভাবেই আপনি আপনার টোনকে শান দেন।

এটি ভাবার আরেকটি উপায় এখানে রয়েছে: আপনার কণ্ঠস্বর কখনই পরিবর্তিত হয় না, তবে আপনার স্বর পরিবর্তন হয়। আপনার কণ্ঠস্বর আপনি একজন ব্যক্তি হিসাবে কে তার সাথে সাদৃশ্যপূর্ণ, যেখানে স্বর হল আপনি একটি প্রদত্ত পরিস্থিতিতে কীভাবে প্রতিক্রিয়া জানান।

সক্রিয় এবং প্যাসিভ ভয়েস

একটি বাক্যে সর্বদা একটি অভিনেতা, একটি ক্রিয়া এবং একটি লক্ষ্য থাকে। যে ক্রমে এগুলি আসে তা নির্ধারণ করে যে বাক্যটি একটি সক্রিয় বা নিষ্ক্রিয় কণ্ঠে লেখা হয়েছে কিনা।

অভিনেতা একটি প্রথম আসে সক্রিয় ভয়েস. যেমন: "CSS ব্যাকগ্রাউন্ড পেইন্ট করে।"

যে বাক্যগুলি একটি সক্রিয় ভয়েস ব্যবহার করে সেগুলি তাদের প্রতিপক্ষের চেয়ে আরও সহজবোধ্য। এগুলি আরও পরিষ্কার, সংক্ষিপ্ত এবং আরও বোধগম্য — আরও পেশাদার ভয়েসের জন্য উপযুক্ত যা সরাসরি পয়েন্টে পৌঁছে যায়।

সঙ্গে একটি প্যাসিভ ভয়েস, অভিনেতা শেষ আসে. (দেখুন আমি সেখানে কী করেছি?) তার মানে আমাদের অভিনেতা — এই ক্ষেত্রে CSS — শেষের দিকে আসে এভাবে: "ব্যাকগ্রাউন্ডটি CSS দ্বারা আঁকা হয়েছে।"

পাঠকরা সাধারণত একটি প্যাসিভ ভয়েসকে তাদের মাথায় একটি সক্রিয় ভয়েস রূপান্তর করে, ফলে প্রক্রিয়াকরণের সময় বেশি হয়। আপনি যদি কখনও শুনে থাকেন যে সক্রিয় কণ্ঠে লেখা ভাল, এটি সাধারণত কারণ। টেক লেখকরা বেশিরভাগ সময় সক্রিয় ভয়েস পছন্দ করেন, খুব কম ব্যতিক্রম যেমন গবেষণার উদ্ধৃতি দিয়ে: "এটি প্রস্তাব করা হয়েছে যে ..."

কিন্তু এর মানে এই নয় যে আপনার সবসময় সক্রিয় ভয়েসের জন্য চেষ্টা করা উচিত। একটি থেকে অন্যটিতে স্যুইচ করা — এমনকি একই অনুচ্ছেদেও — কার্যকরভাবে ব্যবহার করা হলে আপনার বিষয়বস্তু এক বাক্য থেকে অন্য বাক্যে প্রবাহিত করতে পারে৷

ভুল এড়ানো

ব্যাকরণ হল ভাষার গঠন এবং সঠিকতা সম্পর্কে, এবং এটি অর্জনের জন্য আপনার নথির দ্রুত প্রুফরিডিং ছাড়া আর কিছুই নেই। আপনার লেখাগুলিকে বানান ভুল, ব্যাকরণের সমস্যা এবং শব্দার্থগত অসম্পূর্ণতা থেকে মুক্তি দেওয়া খুবই গুরুত্বপূর্ণ।

এই নিবন্ধের শেষে, আমি আপনাকে অমূল্য সরঞ্জামগুলি দেখাব যা পেশাদাররা লেখার ভুল এড়াতে ব্যবহার করে। স্পষ্টতই, আজকাল প্রায় সবকিছুতেই অন্তর্নির্মিত বানান পরীক্ষক রয়েছে; আমাদের কোড এডিটরদের এমনকি ভুল রোধ করতে সাহায্য করার জন্য বানান-পরীক্ষা এবং লিন্টিং প্লাগইন রয়েছে। 

কিন্তু আপনি যদি সমস্ত জিনিসের ব্যাকরণের জন্য একটি ওয়ান-স্টপ টুল খুঁজছেন, Grammarly সবচেয়ে ব্যাপকভাবে ব্যবহৃত সরঞ্জাম এক. আমি এটি বা অন্য কিছুর জন্য একটি কিকব্যাক পাচ্ছি না। এটি সত্যিই একটি দুর্দান্ত সরঞ্জাম যা অনেক সম্পাদক এবং লেখক পরিষ্কার এবং পরিষ্কার বিষয়বস্তু লিখতে ব্যবহার করেন — আপনি কীভাবে পরিষ্কার এবং পরিষ্কার কোড লিখতে Emmet, eslint বা অন্য কোনও লিন্টার ব্যবহার করতে পারেন তার অনুরূপ।

কোড মন্তব্য লেখা

আমরা অন্যান্য বিকাশকারীদের জন্য যে জিনিসগুলি লিখি তা আমাদের কাজের সামগ্রিক মানের উপর একটি বড় প্রভাব ফেলতে পারে, আমরা কোডে যা লিখি, আমরা কীভাবে কোডটি ব্যাখ্যা করি বা আমরা কীভাবে কোডের একটি অংশে প্রতিক্রিয়া জানাই।

এটি আকর্ষণীয় যে প্রতিটি প্রোগ্রামিং ভাষা একটি মন্তব্য লিখতে বৈশিষ্ট্যগুলির একটি স্ট্যান্ডার্ড সেট সহ আসে। কোডটি কী করছে তা তাদের ব্যাখ্যা করা উচিত। এর দ্বারা, আমি এইরকম অস্পষ্ট মন্তব্য বলতে চাই না:

red *= 1.2 // Multiply `red` by 1.2 and re-assign it

পরিবর্তে, আরও তথ্য প্রদান করে এমন মন্তব্যগুলি ব্যবহার করুন:

red *= 1.2 // Apply a 'reddish' effect to the image

এটা প্রসঙ্গ সম্পর্কে সব. "আমি কি ধরনের প্রোগ্রাম তৈরি করছি?" আপনি নিজেকে জিজ্ঞাসা করা উচিত ঠিক প্রশ্ন ধরনের.

মন্তব্য মান যোগ করা উচিত

একটি "ভাল" কোড মন্তব্য কী করে তা দেখার আগে, এখানে অলস মন্তব্যের দুটি উদাহরণ রয়েছে:

const age = 32 // Initialize `age` to 32

filter: blur(32px); /* Create a blur effect with a 32px radius */

মনে রাখবেন যে একটি মন্তব্যের উদ্দেশ্য হল কোডের একটি অংশে মান যোগ করা, এটি পুনরাবৃত্তি করা নয়। আপনি যদি তা করতে না পারেন, তাহলে কোডটি যেমন আছে তেমন রেখে যাওয়াই ভালো। কী এই উদাহরণগুলিকে "অলস" করে তোলে তা হল যে কোডটি স্পষ্টতই কী করছে তা তারা কেবল পুনরুদ্ধার করে। এই ক্ষেত্রে, মন্তব্যগুলি অপ্রয়োজনীয় কারণ তারা আমাদের বলে যে আমরা ইতিমধ্যে কী জানি — তারা মান যোগ করছে না!

মন্তব্য বর্তমান কোড প্রতিফলিত করা উচিত

পুরানো মন্তব্য বড় প্রকল্পে কোন বিরল দৃশ্য নয়; আমি বলতে সাহস সেতু প্রকল্প.

এর কল্পনা করা যাক ডেভিড, একজন প্রোগ্রামার এবং আশেপাশের একজন দুর্দান্ত লোক যার সাথে আড্ডা দেওয়ার জন্য। ডেভিড A থেকে Z বর্ণানুক্রমিকভাবে স্ট্রিংগুলির একটি তালিকা বাছাই করতে চায়, তাই সে জাভাস্ক্রিপ্টে স্পষ্ট করে:

cities = sortWords(cities) // sort cities from A to Z

ডেভিড তখন বুঝতে পারে যে sortWords() আসলে Z থেকে A-তে তালিকা সাজায়। এটা কোন সমস্যা নয়, কারণ সে সহজভাবে আউটপুট বিপরীত করতে পারে:

cities = sortWords(cities) // sort cities from A to Z
cities = reverse(cities)

দুর্ভাগ্যবশত, ডেভিড তার কোড মন্তব্য আপডেট করেনি।

এখন কল্পনা করুন যে আমি আপনাকে এই গল্পটি বলিনি, এবং আপনি যা দেখেছেন তা হল উপরের কোডটি। আপনি স্বাভাবিকভাবেই মনে করবেন যে কোডের সেই দ্বিতীয় লাইনটি চালানোর পরে, `শহর` Z থেকে A তে সাজানো হবে! এই পুরো বিভ্রান্তির ব্যর্থতা একটি বাসি মন্তব্যের কারণে হয়েছিল।

যদিও এটি একটি অতিরঞ্জিত উদাহরণ হতে পারে, আপনি যদি একটি কাছাকাছি সময়সীমার বিরুদ্ধে দৌড়ে থাকেন তবে অনুরূপ কিছু ঘটতে পারে (এবং প্রায়শই ঘটে)। সৌভাগ্যক্রমে, এটি একটি সাধারণ নিয়ম অনুসরণ করে প্রতিরোধ করা যেতে পারে... কোড পরিবর্তন করার সাথে সাথে আপনার মন্তব্য পরিবর্তন করুন।

এটি একটি সহজ নিয়ম যা আপনাকে এবং আপনার দলকে অনেক কিছু থেকে রক্ষা করবে প্রযুক্তিগত debtণ.

এখন যেহেতু আমরা জানি খারাপভাবে লেখা মন্তব্যগুলি কেমন দেখায়, আসুন কিছু ভাল উদাহরণ দেখি।

মন্তব্য ইউনিডিওমেটিক কোড ব্যাখ্যা করা উচিত

কখনও কখনও, প্রাকৃতিক কাজ করার উপায় সঠিক নয়। প্রোগ্রামারদের মানগুলি কিছুটা "ভঙ্গ" করতে হতে পারে, কিন্তু যখন তারা তা করে, তখন তাদের যুক্তি ব্যাখ্যা করে একটু মন্তব্য করার পরামর্শ দেওয়া হয়:

 function addSetEntry(set, value) {    
  /* Don't return `set.add` because it's not chainable in IE 11. */  
  set.add(value);
  return set;
}

এটা সহায়ক, তাই না? যদি আপনি এই কোডটি পর্যালোচনা করার জন্য দায়ী হন, তাহলে আপনি সেখানে কী ঘটছে তা ব্যাখ্যা করে সেই মন্তব্য ছাড়াই এটি সংশোধন করতে প্রলুব্ধ হতে পারেন৷

মন্তব্য ভবিষ্যতে কাজ সনাক্ত করতে পারেন

মন্তব্যের সাথে আরেকটি দরকারী জিনিস হল স্বীকার করা যে আরও কাজ করা বাকি আছে।

// TODO: use a more efficient algorithm
linearSort(ids)

এইভাবে, আপনি আপনার প্রবাহের উপর ফোকাস রাখতে পারেন। এবং পরবর্তী তারিখে, আপনি (বা অন্য কেউ) ফিরে এসে এটি ঠিক করতে পারেন।

মন্তব্য উৎসে ফিরে লিঙ্ক করতে পারেন

সুতরাং, আপনি স্ট্যাকওভারফ্লোতে আপনার সমস্যার সমাধান খুঁজে পেয়েছেন। সেই কোডটি কপি-পেস্ট করার পরে, কখনও কখনও উত্তরটির একটি লিঙ্ক রাখা একটি ভাল জিনিস যা আপনাকে সাহায্য করেছে যাতে আপনি ভবিষ্যতের রেফারেন্সের জন্য এটিতে ফিরে আসতে পারেন।

// Adds handling for legacy browsers
// https://stackoverflow.com/a/XXXXXXX

এটি গুরুত্বপূর্ণ কারণ সমাধান পরিবর্তন হতে পারে। আপনার কোডটি যদি কখনও ভেঙে যায় তাহলে এটি কোথা থেকে এসেছে তা জেনে রাখা সবসময়ই ভালো।

টান অনুরোধ লেখা

অনুরোধ টানুন (PRs) যে কোনো প্রকল্পের একটি মৌলিক দিক। তারা কোড পর্যালোচনার কেন্দ্রবিন্দুতে বসে। এবং কোড পর্যালোচনাগুলি ভাল শব্দ ছাড়াই দ্রুত আপনার দলের পারফরম্যান্সে বাধা হয়ে দাঁড়াতে পারে।

একটি ভালো PR বর্ণনা সংক্ষিপ্ত করে কি পরিবর্তন করা হচ্ছে এবং কেন এটা তৈরি করা হচ্ছে। বড় প্রকল্পগুলির একটি পুল অনুরোধ টেমপ্লেট থাকে, যেমন একটি থেকে অভিযোজিত বাস্তব উদাহরণ:

## Proposed changes
Describe the big picture of your changes here to communicate to the maintainers why we should accept this pull request.

## Types of changes
What types of changes does your code introduce to Appium?
 - [ ] Bugfix (non-breaking change which fixes an issue)
 - [ ] New feature (non-breaking change which adds functionality)
 - ...

## Checklist
 - [ ] I have read the CONTRIBUTING doc
 - [ ] I have signed the CLA
 - [ ] Lint and unit tests pass locally with my changes

## Further comments
If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc…

অস্পষ্ট এড়িয়ে চলুন PR শিরোনাম

অনুগ্রহ করে এই ধরনের শিরোনাম এড়িয়ে চলুন:

• বিল্ড ঠিক করুন।
• বাগ ঠিক করুন।
• প্যাচ যোগ করুন।

এগুলোও করে না প্রয়াস আমরা কি বিল্ড, বাগ, বা প্যাচ নিয়ে কাজ করছি তা বর্ণনা করতে। বিল্ডের কোন অংশটি ঠিক করা হয়েছিল, কোন বাগটি স্কোয়াশ করা হয়েছিল, বা কোন প্যাচ যোগ করা হয়েছিল সে সম্পর্কে একটু অতিরিক্ত বিশদ আপনার সহকর্মীদের সাথে আরও ভাল যোগাযোগ এবং সহযোগিতা প্রতিষ্ঠার জন্য একটি দীর্ঘ পথ যেতে পারে৷ এটা লেভেল-সেট করে এবং একই পৃষ্ঠায় লোকেদের পায়।

PR শিরোনাম ঐতিহ্যগতভাবে লেখা হয় অপরিহার্য কাল. তারা সমগ্র একটি এক লাইন সারাংশ PR, এবং তাদের বর্ণনা করা উচিত কি দ্বারা করা হচ্ছে PR.

এখানে কিছু ভাল উদাহরণ আছে:

• NgOptimizedImage-এ কাস্টম srcset বৈশিষ্ট্য সমর্থন করে
• 75% ছবির গুণমানে ডিফল্ট ইমেজ কনফিগারেশন
• সমস্ত অন্তর্নির্মিত ControlValueAccessors-এর জন্য স্পষ্ট নির্বাচক যোগ করুন

দীর্ঘ এড়িয়ে চলুন PRs

একটি বড় PR মানে একটি বিশাল বিবরণ, এবং কেউ শত শত বা হাজার হাজার লাইনের কোড পর্যালোচনা করতে চায় না, কখনও কখনও শুধুমাত্র শেষ পর্যন্ত পুরো জিনিসটি খারিজ করে দেয়!

পরিবর্তে, আপনি পারেন:

• মাধ্যমে আপনার দলের সাথে যোগাযোগ করুন সমস্যা,
• একটা পরিকল্পনা কর,
• সমস্যাটিকে ছোট ছোট টুকরো করে ফেলুন, বা
• প্রতিটি টুকরোতে আলাদাভাবে নিজের সাথে কাজ করুন PR.

এটা এখন অনেক পরিষ্কার না?

বিস্তারিত প্রদান করুন PR শরীর

এর বিপরীতে PR শিরোনাম, শরীর হয় দ্য সমস্ত বিবরণের জন্য স্থান, সহ:

• কেন হয় PR করা হচ্ছে?
• কেন এই সেরা পদ্ধতি?
• পদ্ধতির কোন ত্রুটি, এবং যদি সম্ভব হয় তাদের সমাধান করার ধারনা
• বাগ বা টিকিট নম্বর, বেঞ্চমার্ক ফলাফল, ইত্যাদি।

বাগ রিপোর্টিং

বাগ রিপোর্ট যে কোনো প্রকল্পের সবচেয়ে গুরুত্বপূর্ণ দিকগুলির মধ্যে একটি। এবং সমস্ত মহান প্রকল্প ব্যবহারকারীর প্রতিক্রিয়া উপর নির্মিত হয়. সাধারণত, অগণিত পরীক্ষার পরেও, ব্যবহারকারীরাই বেশিরভাগ বাগ খুঁজে পান। ব্যবহারকারীরাও মহান আদর্শবাদী, এবং কখনও কখনও তাদের বৈশিষ্ট্য ধারনা থাকে; তাদের কথা শুনুন!

প্রযুক্তিগত প্রকল্পের জন্য, এই সমস্ত উপাদান রিপোর্টিং সমস্যা দ্বারা সম্পন্ন করা হয়. একটি ভাল-লিখিত সমস্যা অন্য বিকাশকারীর পক্ষে খুঁজে পাওয়া এবং প্রতিক্রিয়া জানাতে সহজ।

উদাহরণস্বরূপ, বেশিরভাগ বড় প্রকল্পের সাথে আসে একটি টেমপ্লেট:

 <!-- Modified from angular-translate/angular-translate -->
 ### Subject of the issue
 Describe your issue here.

 ### Your environment
 * version of angular-translate
 * version of angular
 * which browser and its version

 ### Steps to reproduce
 Tell us how to reproduce this issue.

 ### Expected behavior
 Tell us what should happen.

 ### Actual behavior
 Tell us what happens instead.

স্ক্রিনশট সংগ্রহ করুন

আপনার ব্যবহার করে সমস্যা ক্যাপচার সিস্টেমের স্ক্রিন-শুটিং ইউটিলিটি.

এটি একটি স্ক্রিনশট হলে CLI প্রোগ্রাম, নিশ্চিত করুন যে পাঠ্যটি পরিষ্কার। যদি এটি একটি UI প্রোগ্রাম, নিশ্চিত করুন যে স্ক্রিনশট সঠিক উপাদান এবং অবস্থা ক্যাপচার করে।

সমস্যাটি প্রদর্শন করার জন্য আপনাকে একটি প্রকৃত মিথস্ক্রিয়া ক্যাপচার করতে হতে পারে। যদি তাই হয়, চেষ্টা করুন একটি স্ক্রিন-রেকর্ডিং টুল ব্যবহার করে GIF রেকর্ড করুন.

কিভাবে সমস্যা পুনরুত্পাদন

প্রোগ্রামাররা যখন তাদের কম্পিউটারে লাইভ থাকে তখন বাগ সমাধান করা অনেক সহজ। এই কারণেই একটি ভাল প্রতিশ্রুতি সঠিকভাবে সমস্যাটি পুনরুত্পাদন করার পদক্ষেপের সাথে আসা উচিত।

এখানে একটি উদাহরণ দেয়া হলঃ

Update: you can actually reproduce this error with objects:

 ```html
 <div *ngFor="let value of objs; let i = index">
   <input [ngModel]="objs[i].v" (ngModelChange)="setObj(i, $event)" />
 </div>
 ```

 ```js
 export class OneComponent {
   obj = {v: '0'};
   objs = [this.obj, this.obj, this.obj, this.obj];
 ​
  setObj(i: number, value: string) {
     this.objs[i] = {v: value};
  }
 }
 ```

 The bug is reproducible as long as the trackBy function returns the same value for any two entries in the array. So weird behavior can occur with any duplicate values.

একটি কারণ প্রস্তাব করুন

আপনি একজন যিনি বাগটি ধরেছেন, তাই সম্ভবত আপনি এটির কারণের জন্য কিছু সম্ভাব্য কারণ প্রস্তাব করতে পারেন৷ হতে পারে আপনি একটি নির্দিষ্ট ইভেন্টের সম্মুখীন হওয়ার পরেই বাগটি ঘটতে পারে, অথবা এটি শুধুমাত্র মোবাইলে ঘটতে পারে৷

এটি কোডবেস অন্বেষণ করতে ক্ষতি করতে পারে না এবং সমস্যাটি কী ঘটছে তা সনাক্ত করতে পারে। তারপর, আপনার ইস্যুটি আরও দ্রুত বন্ধ হয়ে যাবে এবং সম্ভবত আপনাকে সংশ্লিষ্টদের কাছে নিয়োগ দেওয়া হবে PR.

ক্লায়েন্টদের সাথে যোগাযোগ করা

আপনি একক ফ্রিল্যান্সার হিসাবে কাজ করতে পারেন, অথবা সম্ভবত আপনি একটি ছোট দলে প্রধান বিকাশকারী। উভয় ক্ষেত্রেই, ধরুন আপনি একটি প্রকল্পে ক্লায়েন্টদের সাথে ইন্টারফেস করার জন্য দায়ী৷ 

এখন, প্রোগ্রামার স্টেরিওটাইপ হল যে আমরা দরিদ্র যোগাযোগকারী। আমরা অত্যধিক প্রযুক্তিগত শব্দার্থ ব্যবহার করতে পরিচিত, অন্যদের বলুন কী সম্ভব এবং কী নয়, এবং এমনকি কেউ যখন আমাদের পদ্ধতির বিষয়ে প্রশ্ন তোলে তখন আত্মরক্ষামূলক হয়ে যাই।

সুতরাং, কিভাবে আমরা সেই স্টেরিওটাইপ প্রশমিত করব? ক্লায়েন্টদের জিজ্ঞাসা করুন তারা কি চায় এবং সর্বদা তাদের প্রতিক্রিয়া শুনুন। এটি কিভাবে করতে হয় তা এখানে।

সঠিক প্রশ্ন করুন

আপনি এবং ক্লায়েন্ট একই পৃষ্ঠায় আছেন তা নিশ্চিত করে শুরু করুন:

• আপনার লক্ষ্য শ্রোতা কে?
• সাইটের লক্ষ্য কি?
• আপনার নিকটতম প্রতিযোগী কে এবং তারা ঠিক কি করছে?

প্রশ্ন জিজ্ঞাসা করা ইতিবাচকভাবে লেখার একটি ভাল উপায়, বিশেষ করে এমন পরিস্থিতিতে যখন আপনি কোনও ক্লায়েন্টের প্রতিক্রিয়া বা সিদ্ধান্তের সাথে একমত হন না। প্রশ্ন জিজ্ঞাসা করা সেই ব্যক্তিকে আপনার নিজের অবস্থান রক্ষা করে আক্রমণ করার পরিবর্তে তাদের নিজস্ব দাবি সমর্থন করতে বাধ্য করে:

• এটি একটি অতিরিক্ত কর্মক্ষমতা খরচ সঙ্গে আসে এমনকি যদি আপনি যে সঙ্গে ঠিক আছে?
• উপাদান সরানো কি আমাদের উদ্দেশ্যকে আরও ভালভাবে সম্পন্ন করতে সাহায্য করে?
• দুর্দান্ত, লঞ্চের পরে এটি বজায় রাখার দায়িত্ব কার? 
• আপনি কি জানেন যে এই দুটি রঙের মধ্যে বৈসাদৃশ্য যদি WCAG AA মানকে অতিক্রম করে?

প্রশ্নগুলি অনেক বেশি নির্দোষ এবং শত্রুতার উপর কৌতূহলকে উন্নীত করে।

নিজেকে বিক্রি করুন

আপনি যদি একজন সম্ভাব্য ক্লায়েন্টের কাছে একটি পিচ তৈরি করছেন, তাহলে আপনাকে তাদের নিয়োগ করতে রাজি করতে হবে। কেন ক্লায়েন্ট আপনাকে বেছে নিতে হবে? নিম্নলিখিতগুলি নির্দিষ্ট করা গুরুত্বপূর্ণ:

• কে তুমি
• তুমি কি করো
• কেন আপনি চাকরির জন্য উপযুক্ত
• আপনার করা প্রাসঙ্গিক কাজের লিঙ্ক

এবং একবার আপনি কাজটি পেয়ে গেলে এবং একটি চুক্তি লিখতে হবে, মনে রাখবেন যে একগুচ্ছ বৈধের চেয়ে ভয়ঙ্কর কোন বিষয়বস্তু নেই। যদিও এটি ডিজাইন প্রকল্পের জন্য লেখা হয়েছে, ভাড়াটে খুনি অনেক বন্ধুত্বপূর্ণ কিছু লেখার জন্য একটি চমৎকার সূচনা পয়েন্ট হতে পারে।

বিশদে আপনার মনোযোগ আপনার এবং একই প্রকল্প জয় করার চেষ্টাকারী অন্য বিকাশকারীর মধ্যে পার্থক্য হতে পারে। আমার অভিজ্ঞতায়, ক্লায়েন্টরা খুব সহজে একটি ডেভেলপমেন্ট নিয়োগ করবে যা তারা মনে করে যে তারা কাজের জন্য প্রযুক্তিগতভাবে সবচেয়ে যোগ্য বা অভিজ্ঞ একজনের চেয়ে কাজ করতে উপভোগ করবে।

মাইক্রোকপি লেখা

মাইক্রোকপি ব্যবহারকারী-বান্ধব লেখার শিল্প UI বার্তা, যেমন ত্রুটি। আমি বাজি ধরতে পারি এমন অনেক সময় এসেছে যেখানে একজন বিকাশকারী হিসাবে আপনাকে ত্রুটি বার্তা লিখতে হয়েছিল কারণ সেগুলি চালু করার সময় সমস্ত উপায়ে ব্যাকবার্নারে রাখা হয়েছিল।

এই কারণেই আমরা মাঝে মাঝে এই জাতীয় ত্রুটিগুলি দেখতে পাই:

Error: Unexpected input (Code 693)

ত্রুটি হল শেষ জিনিস যা আপনি আপনার ব্যবহারকারীদের সাথে মোকাবিলা করতে চান। কিন্তু তারা ঘটবে, এবং এটি সম্পর্কে আমরা কিছুই করতে পারি না। আপনার মাইক্রোকপি দক্ষতা উন্নত করার জন্য এখানে কিছু টিপস রয়েছে।

প্রযুক্তিগত শব্দবাক্য এড়িয়ে চলুন

বেশিরভাগ লোকই জানে না সার্ভার কী, যখন 100% প্রোগ্রামাররা করে। এই কারণেই একটি ত্রুটি বার্তায় লেখা অস্বাভাবিক পদগুলি দেখতে অস্বাভাবিক নয়, যেমন এপিআই অথবা "টাইমআউট এক্সিকিউশন।"

যতক্ষণ না আপনি একটি প্রযুক্তিগত ক্লায়েন্ট বা ব্যবহারকারী বেস নিয়ে কাজ করছেন, সম্ভবত আপনার বেশিরভাগ ব্যবহারকারী কম্পিউটার বিজ্ঞানের কোর্স করেননি, এবং ইন্টারনেট কীভাবে কাজ করে এবং কেন একটি নির্দিষ্ট জিনিস কাজ করে না তা জানেন না। অতএব, ত্রুটি.

অতএব, একটি ভাল ত্রুটি বার্তা ব্যাখ্যা করা উচিত নয় কেন কিছু ভুল হয়েছে, কারণ এই ধরনের ব্যাখ্যার জন্য ভীতিকর প্রযুক্তিগত শব্দ ব্যবহার করার প্রয়োজন হতে পারে। সেজন্য প্রযুক্তিগত শব্দবাক্য ব্যবহার করা এড়ানো খুবই গুরুত্বপূর্ণ।

ব্যবহারকারীকে কখনই দোষারোপ করবেন না

এটি কল্পনা করুন: আমি আপনার প্ল্যাটফর্মে লগ ইন করার চেষ্টা করছি। তাই আমি আমার ব্রাউজার খুলি, আপনার ওয়েবসাইট পরিদর্শন করি এবং আমার বিবরণ লিখি। তারপর আমাকে বলা হয়: "আপনার ইমেল/পাসওয়ার্ড ভুল।"

যদিও এই বার্তাটি প্রতিকূল মনে করা নাটকীয় বলে মনে হয়, তবে এটি অবচেতনভাবে আমাকে বোকা বোধ করে। মাইক্রোকপি বলে যে ব্যবহারকারীকে দোষ দেওয়া কখনই ঠিক নয়। আপনার বার্তাটি কম আঙুল-বিন্দুতে পরিবর্তন করার চেষ্টা করুন, যেমন এই উদাহরণটি Mailchimp-এর লগইন থেকে অভিযোজিত: “দুঃখিত, সেই ইমেল-পাসওয়ার্ড সমন্বয়টি সঠিক নয়। আমরা আপনাকে আপনার অ্যাকাউন্ট পুনরুদ্ধার করতে সাহায্য করতে পারি।"

আমি সমস্ত ক্যাপ এবং বিস্ময়বোধক পয়েন্ট এড়ানোর গুরুত্ব যোগ করতে চাই! অবশ্যই, তারা উত্তেজনা প্রকাশ করতে ব্যবহার করা যেতে পারে, কিন্তু মাইক্রোকপিতে তারা ব্যবহারকারীর প্রতি শত্রুতার অনুভূতি তৈরি করে।

ব্যবহারকারীকে অভিভূত করবেন না

আপনার মাইক্রোকপিতে হাস্যরস ব্যবহার করা একটি ভাল ধারণা! এটি মেজাজকে হালকা করতে পারে এবং এটি সবচেয়ে খারাপ ত্রুটির কারণে নেতিবাচকতাকে নিয়ন্ত্রণ করার একটি সহজ উপায়।

কিন্তু যদি আপনি এটি ব্যবহার না করেন ঠিকভাবে, এটি ব্যবহারকারীর জন্য অবমাননাকর এবং অপমানজনক হিসাবে জুড়ে আসতে পারে। যে শুধু একটি বিশাল ঝুঁকি নিতে।

Mailchimp এটা ভাল বলেছেন:

কৌতুক করার জন্য আপনার পথের বাইরে যাবেন না — জোর করে হাস্যরস মোটেও খারাপ হতে পারে না। আপনি যদি অনিশ্চিত হন, একটি সোজা মুখ রাখুন.

(জোর আমার)

অ্যাক্সেসযোগ্য মার্কআপ লেখা

আমরা সহজে অ্যাক্সেসযোগ্যতা সম্পর্কে একটি সম্পূর্ণ নিবন্ধ ব্যয় করতে পারি এবং এটি কীভাবে প্রযুক্তিগত লেখার সাথে সম্পর্কিত। হেক, অ্যাক্সেসিবিলিটি প্রায়শই বিষয়বস্তু শৈলী নির্দেশিকায় অন্তর্ভুক্ত করা হয়, এর জন্য সহ মাইক্রোসফট এবং MailChimp.

আপনি একজন বিকাশকারী এবং সম্ভবত ইতিমধ্যে অ্যাক্সেসযোগ্যতা সম্পর্কে অনেক কিছু জানেন৷ এমনকি আপনি আরও পরিশ্রমী বিকাশকারীদের একজন হতে পারেন যা অ্যাক্সেসযোগ্যতাকে আপনার কর্মপ্রবাহের মূল অংশ করে তোলে। তবুও, এটা অবিশ্বাস্য যে কত ঘন ঘন অ্যাক্সেসযোগ্যতার বিবেচনাগুলি ব্যাক বার্নারে রাখা হয়, আমরা সকলেই জানি যে সমস্ত ক্ষমতা সহ অ্যাক্সেসযোগ্য অনলাইন অভিজ্ঞতা তৈরি করা কতটা গুরুত্বপূর্ণ।

সুতরাং, আপনি যদি আপনার কোডে অন্য কারো কপিরাইটিং বাস্তবায়ন করতে, অন্য ডেভেলপারদের জন্য ডকুমেন্টেশন লিখতে বা এমনকি লিখতে দেখেন UI নিজেকে অনুলিপি করুন, কিছু মৌলিক অ্যাক্সেসিবিলিটি সর্বোত্তম অভ্যাস সম্পর্কে সচেতন হন, কারণ তারা প্রযুক্তিগত লেখার জন্য অন্যান্য সমস্ত পরামর্শকে পূর্ণ করে তোলে।

ভালো জিনিস:

অ্যান্ডি বেল তুলনামূলকভাবে কিছু অফার করে বিষয়বস্তু আরও অ্যাক্সেসযোগ্য করতে আপনি করতে পারেন ছোট জিনিস, এবং এটি তাদের চেক আউট আপনার সময় মূল্য. এবং, শুধু লাথির জন্য, জন রিয়া কিছু ঝরঝরে সম্পাদনার কৌশল দেখায় এটি সম্ভব যখন আমরা শব্দার্থিক HTML উপাদানগুলির সাথে কাজ করছি৷

উপসংহার

সেগুলি ছিল ছয়টি উপায় যা প্রদর্শন করে যে কীভাবে প্রযুক্তিগত লেখা এবং বিকাশ মিলে যায়। যদিও উদাহরণ এবং পরামর্শগুলি রকেট সায়েন্স নাও হতে পারে, আমি আশা করি যে আপনি সেগুলিকে কাজে লাগিয়েছেন, তা অন্য ডেভেলপারদের সাথে সহযোগিতা করা, আপনার নিজের কাজ বজায় রাখা, আপনার নিজের অনুলিপি এক চিমটে লিখতে হবে, বা এমনকি একটি প্রকল্প প্রস্তাবের খসড়া তৈরি করতে হবে। জিনিস

নীচের লাইন: আপনার লেখার দক্ষতা তীক্ষ্ণ করা এবং আপনার লেখায় একটু অতিরিক্ত প্রচেষ্টা করা আসলে আপনাকে একজন ভাল বিকাশকারী করে তুলতে পারে।

প্রযুক্তিগত লেখার সংস্থান

আপনি যদি প্রযুক্তিগত লেখায় আগ্রহী হন:

আপনি কপিরাইটিং আগ্রহী হলে:

আপনি যদি মাইক্রোকপিতে আগ্রহী হন:

আপনি যদি আপনার লেখার উন্নতি করতে একটি পেশাদার স্টাইল গাইড ব্যবহার করতে আগ্রহী হন:

আপনি যদি অ্যাক্সেসযোগ্যতার জন্য লিখতে আগ্রহী হন: