কোনো স্টার্টআপ পরীক্ষক দিয়ে শুরু হয় না।
তারপর 2 বছর পরে, সেই স্টার্টআপটি তাদের সবচেয়ে বড় গ্রাহকের জন্য একটি নতুন বৈশিষ্ট্য প্রকাশ করতে পারে না যদি না তারা পুরো জিনিসটি একটি বিগ ব্যাং দিয়ে পুনরায় লিখতে পারে। এটা বারবার দেখতে বেদনাদায়ক.
আমাদের সফ্টওয়্যারের স্যানিটারি গুণমান বজায় রাখার জন্য সহজ জিনিসগুলি রয়েছে, যাতে আপনি এই পরিস্থিতিতে শেষ না হন৷
প্রথমত, আপনার ভয়কে আলিঙ্গন করুন। ইঞ্জিনিয়াররা সাহসী মানুষ, এবং আমরা সহজেই স্বীকার করব না যে আমাদের উদ্বেগ আছে। কিন্তু আমাদের আছে, এবং যত তাড়াতাড়ি আমরা এই উদ্বেগগুলি স্বীকার করব এবং শেয়ার করব, তত তাড়াতাড়ি আমরা তাদের মুখোমুখি হওয়ার জন্য প্রস্তুত হব।
আমরা এত তাড়ার মধ্যে আছি যে আমরা সবসময় দেরি করি। পরীক্ষার সময় নেই। ইউনিট পরীক্ষার জন্য কোন সময় নেই. রিফ্যাক্টর করার সময় নেই।
ঠিক আছে, যখন আমরা ইঞ্জিনিয়ারিং দল হিসাবে নিজেদেরকে নাশকতা করতে থাকি তখন এটি সঠিকভাবে করার জন্য পর্যাপ্ত সময় থাকবে না।
আমাদের জিজ্ঞাসা করা হয় এতে কত সময় লাগবে এবং আমরা আমাদের অনুমান থেকে ইউনিট টেস্টিং, ম্যানুয়াল টেস্টিং, এমনকি API টেস্টিং এবং রিফ্যাক্টরিং বাদ দিয়ে থাকি।
সুতরাং আমরা এই মত সফ্টওয়্যার তৈরি:
অন্য সবকিছু একটি প্রান্ত ক্ষেত্রে বিবেচনা করা হয়. (এজ কেস বলে কিছু নেই।)
আমাদের মধ্যে খুব কম লোকই দ্রুত বা নোংরা এবং দ্রুত এবং স্থিতিশীল সফ্টওয়্যারকে না বলতে সাহসী।
আপনার অনুমান থেকে আপনার যা কাটা উচিত তা হল সুযোগ, গুণমান নয়।
আপনি যে উপাদানটির উপর কাজ করছেন তার গুণমান সম্পর্কে আপনি কী জানেন?
এটি আসলে কতটা ভঙ্গুর তা পরীক্ষা করার এবং প্রকাশ করার জন্য কোনও পরীক্ষা নেই এবং কেউ নেই।
আপনি কি এই নোংরা সফ্টওয়্যারটির সাথে প্রতিদিন কাজ করে খুশি?
আপনি কি প্রতিদিন আপনার কাজের মানের সাথে আপস করে খুশি হন, জেনেও এটি ভাল নয়? "আমাদের পরিষ্কার করার সময় নেই" এর সাথে মোকাবিলা করা এবং এখনও দেরি হচ্ছে কারণ এটি নোংরা এবং আপনি সম্ভবত এটি পরিষ্কার না করে এগিয়ে যেতে পারবেন না।
কল্পনা করুন আপনি আপনার পরবর্তী চাকরির ইন্টারভিউতে আছেন। আপনার বর্তমান চাকরিতে আপনি কী নিয়ে বড়াই করবেন? যে আপনি চাপের মধ্যে পারফর্ম করতে পারেন এবং গভীর রাতে ফিক্স করতে পারেন? তারা আপনাকে এর জন্য ভালোবাসবে, কিন্তু তারা আপনাকে জিজ্ঞাসা করবে কেন আপনি এটি সম্পর্কে কিছু করেননি। হয়তো এটা আপনার কাজ ছিল না.
সেই সিদ্ধান্তগুলি নেওয়ার জন্য টিম লিড এবং ইঞ্জিনিয়ারিং ম্যানেজার ছিলেন। যদি এটি আপনার উপর নির্ভর করে তবে আপনি কিছু করতেন। আপনি তাদের বলেছিলেন যে কোডটির রিফ্যাক্টরিং প্রয়োজন, এবং আপনাকে প্রতিটি রেট্রোতে প্রযুক্তি বিভাগের জন্য সময় পরিকল্পনা করতে হবে, এবং কেউ শোনেনি।
আচ্ছা, অনুমান করুন - আপনার অনুমতির প্রয়োজন নেই। আপনার কাজের মান শুধুমাত্র আপনার উপর নির্ভর করে। কেউ আপনাকে বাজে কোড লিখতে বাধ্য করতে পারে না। সময়ের চাপ একটি স্বল্পমেয়াদী অজুহাত। দ্রুত এবং নোংরা সমাধানগুলি পুরো প্রকল্পকে বিলম্বিত করে এবং আপনি যদি প্রথমবার এটি করেন তার চেয়ে বেশি খরচ হয়।
আপনি যে পার্থক্য করতে ইচ্ছুক?
তারপর, এখানে যা করতে হবে: শৃঙ্খলাবদ্ধ হন। আমি দুঃখিত, কিন্তু এটি কাছাকাছি অন্য কোন উপায় নেই. এবং এটি সব স্তরে হওয়া উচিত।
উচ্চ মানের সঙ্গে বিল্ডিং কোড আপনার প্রথম পদক্ষেপ কি হওয়া উচিত?
লগিং এবং সতর্ক করার জন্য প্রচুর সরঞ্জাম রয়েছে। এই প্রথম কাজ করতে হবে. আপনার সফ্টওয়্যার ক্র্যাশ হচ্ছে, এবং আপনি সম্পূর্ণরূপে অসচেতন।
এমন একটি সমাধান খুঁজুন যা আপনাকে ব্যতিক্রম সতর্কতা থেকে সহজেই টিকিট তৈরি করতে এবং সেগুলিকে "পরিচিত" হিসাবে চিহ্নিত করতে বা রিপোর্ট করার পরে সেগুলিকে গোষ্ঠীবদ্ধ করতে দেয়৷
আপনি যদি মনে করেন এটি নিস্তেজ, তাহলে আমি আপনাকে জিজ্ঞাসা করি: আপনি কি আপনার পুরো কর্মদিবসে জোনের গভীরে থাকেন? সমস্ত মিটিং এবং ভারী প্রোগ্রামিং কাজের পরে, আপনাকে আপনার ঘনত্বকে কিছুটা কমাতে হবে। ভাল, সতর্কতা চ্যানেলের মাধ্যমে ব্রাউজ করা অন্য যেকোনো চ্যানেলের মাধ্যমে ব্রাউজ করার চেয়ে ভাল।
শুধু "একটি টিকিট রিপোর্ট করুন" বোতাম বা "জানা হিসাবে চিহ্নিত করুন" বোতামে ক্লিক করুন৷ এবং যদি আপনি কৌতূহলী হয়ে থাকেন, তাহলে আপনি সম্ভবত এক বা দুটি ঠিক করবেন।
এখানে সবচেয়ে বড় যুক্তি আসে - আমরা একটি দম্পতিকে ঠিক করতে পারি, কিন্তু আমরা পরীক্ষা লিখছি যা কাউকে নিশ্চিত করতে হবে, আমাদের স্থাপন করতে হবে এবং এটি দলের জন্য আরও অপরিকল্পিত কাজ তৈরি করে।
প্রধানমন্ত্রী আমাদের চিৎকার করবেন যে আমরা উচ্চ-প্রধান আইটেমগুলিতে কাজ করছি না বরং সোনার প্রলেপ দেওয়া ছোট সতর্কতা নিয়ে কাজ করছি।
এতে সমস্ত "M" ভূমিকা সহ দলটি এটি সম্পর্কে একমত।
থাম্বের একটি নিয়ম প্রকাশ করুন - "যদি এটি ছোট এবং কম-ঝুঁকিপূর্ণ মনে হয়, এবং অন্য কোন কাজ চলছে না, তবে শুধু এটির জন্য যান এবং এটি ঠিক করুন। আমরা প্রতি স্প্রিন্টে "আউট অফ স্কোপের" নির্দিষ্ট একটি বা দুটি ছোট সতর্কতা পরিচালনা করতে পারি , পরিকল্পিতদের সাথে।"
এটা, খুব সহজ.
মাঝে মাঝে সংশোধন করার পাশাপাশি, পরিষ্কার করার পরিকল্পনা সঠিকভাবে করুন। মনে রাখবেন যে পরিকল্পনা দ্বারা, আমি তাদের তীব্রতা বা অগ্রাধিকার নির্বিশেষে তাদের ঠিক করার জন্য দৈনিক/সাপ্তাহিক সময় বরাদ্দ করতে চাই। আপনি প্রথম 5টি ঠিক করার চেয়ে তাদের অগ্রাধিকার মূল্যায়ন করতে আরও বেশি সময় নষ্ট করবেন। তাই, ঠিক করা শুরু করুন।
নিশ্চিত করুন যে প্রতিটি ডেভেলপারের জন্য একটি সতর্কতা আছে, অথবা আপনি যদি বেশিরভাগ সময় ভীড় করেন, সতর্কতার জন্য একটি দৈনিক টাইমস্লট সেট করুন। এবং আমি সকালে এটি প্রথম কাজ করব কারণ অন্যথায়, আপনি এটি কখনই করবেন না।
আবার, এটি একটি নতুন বৈশিষ্ট্য নয়, এবং এটি আপনার সমালোচনামূলক অগ্রাধিকার থেকে সময় খায় বলে মনে হতে পারে, কিন্তু সেই লুকানো সমস্যাগুলির কারণে আপনার সমালোচনামূলক অগ্রাধিকারগুলি ইতিমধ্যেই দেরি হয়ে গেছে। আপনি ইতিমধ্যে দেরী করছেন!
যদিও সতর্কতা এবং লগিং অনেক কিছু প্রকাশ করবে, তারা আপনি যা লুকাচ্ছেন তা লগ করতে পারবে না। সুতরাং কার্পেটের নীচে আপনার সমস্যাগুলি ঝাড়ু দেওয়া বন্ধ করুন।
2 বছর আগে কী ক্র্যাশ হয়েছিল, এবং আপনি জানেন না কেন আজ সম্পূর্ণ আলাদা। এটা ক্র্যাশ যাক, এবং এটা ঠিক. এটি সম্ভবত একইভাবে ক্র্যাশ হবে না, বা এটি ক্র্যাশও হচ্ছে না, তাই একভাবে বা অন্যভাবে, আপনার কোডটি সেগুলি ছাড়াই আরও ভাল আকারে থাকবে।
আমি এটা মানে. আপনি এই মুহূর্তে কিছু কোডে কাজ করছেন। তারপর কোন কিছুই আপনাকে ইউনিট পরীক্ষা লিখতে বাধা দেয় না।
আচ্ছা বুঝলাম! ইউনিট পরীক্ষার জন্য কোন পরিকাঠামো প্রস্তুত নেই, আছে কি? চলে আসো! আপনি যাইহোক যে wannabe বৈশিষ্ট্য বিলম্ব করতে যাচ্ছেন.
ইউনিট টেস্ট ফ্রেমওয়ার্ক সেট আপ করতে আপনার একদিনের বেশি লাগবে না এবং পরীক্ষা চালানোর জন্য আপনার সিআই। এটা করতে.
"আমরা জানি না সমস্যাটি কী এবং আমরা কীভাবে এটি ঠিক করতে যাচ্ছি। আমরা এখনও বিদ্যমান নেই এমন কোডের জন্য পরীক্ষা লিখতে পারি না।"
আমার প্রিয় বিকাশকারী, পরীক্ষার উদ্দেশ্য হল একটি হাইপোথিসিস চেক করা। এটি শুধুমাত্র সফ্টওয়্যার পরীক্ষার জন্য নয়, সাধারণভাবে পরীক্ষার জন্য বৈধ। তাই আপনার জন্য একটি পরীক্ষা লিখতে যা প্রয়োজন তা কোড নয়। আপনি প্রত্যাশিত আচরণ এবং ফলাফল প্রয়োজন.
এখন, যদি ব্যবহারকারীর গল্পগুলি অস্পষ্ট এবং অস্পষ্ট হয় এবং আপনি ব্যবহারকারীর গল্পগুলির বিরুদ্ধে পরীক্ষা লেখা শুরু করতে প্রস্তুত না হন, আমার কাছে এটিরও একটি সমাধান আছে, তবে তার আগে - বাগগুলির জন্য পরীক্ষা-প্রথম কোড লেখা শুরু করুন।
"প্রত্যাশিত ফলাফল" নামে বাগ বিবরণের একটি উপাদান রয়েছে এবং পুনরুত্পাদনের পদক্ষেপগুলি হল আপনার পরীক্ষার ক্ষেত্রে৷ তাই আপনার সামনে ইতিমধ্যেই টেস্ট কেস আছে। এখন, আপনি ফিক্স কোডিং শুরু করার আগে প্রথমে এটি কোড করুন।
টেস্ট-ড্রাইভেন ডেভেলপমেন্ট এমন একটি পরীক্ষা লিখছে যা যাচাই করে যে আপনি সঠিক কাজটি করেছেন, এমন নয় যে আপনি এটি সঠিক করেছেন। ইউনিট পরীক্ষা আপনি সঠিকভাবে করেছেন কিনা তা যাচাই করে।
টেস্ট অটোমেশন এবং কারিগরি ঋণের একই রকম মর্মান্তিক নিয়তি রয়েছে - সেগুলি কখনই শুরু হয় না কারণ "আমরা কখনই সবকিছু কভার করতে পারি না, আমরা কখনই সবকিছু পরিষ্কার করতে পারি না, এটি খুব বেশি। এর জন্য আমাদের কাছে সময় নেই।"
আমার কথা শুনুন: আপনাকে সবকিছু স্বয়ংক্রিয় করতে হবে না!
তবে আপনাকে অবশ্যই আপনার মিশন-সমালোচনামূলক উপাদানগুলিকে স্বয়ংক্রিয় করতে হবে - উচ্চ-অগ্রাধিকার ব্যবহারের ক্ষেত্রে, সমালোচনামূলক অবকাঠামো এবং মূল কার্যকারিতা। আপনি যা পছন্দ করেন তা বলুন, কিন্তু ব্যবসাটি আপনার কোড এবং পরিকাঠামোর 20% উপর নির্ভর করে এবং আপনার গ্রাহকরা আপনার বৈশিষ্ট্যগুলির 20% ব্যবহার করছেন।
আমি এই সঙ্গে যাচ্ছি যেখানে আপনি দেখতে.
এই বৈশিষ্ট্যগুলির জন্য আপনাকে এখনই স্বয়ংক্রিয় পরীক্ষা লেখা শুরু করার দরকার নেই৷ আপনাকে প্রথমে যা করতে হবে তা হল তাদের অগ্রাধিকার।
আপনার উচ্চ- এবং নিম্ন-স্তরের আর্কিটেকচার ডায়াগ্রামের সামনে একটি দল হিসাবে একত্রিত হন। কোন নেই, তারা কি? নাকি যেগুলো আছে সেগুলো 2.5 বছর আগে তোলা একটি হোয়াইটবোর্ডের ছবি? আমি জানি.
হ্যাঁ, আপনাকে অর্ধেক দিন ব্যয় করতে হবে এবং এগুলি আপ টু ডেট করতে হবে। ভাল খবর হল যে আপনাকে সাহায্য করার জন্য মজাদার সরঞ্জাম রয়েছে, তাই আপনাকে ম্যানুয়ালি এটি বজায় রাখার প্রয়োজন হবে না। কিছু ভাবো.
আপনি একটি R&D দল, সর্বোপরি, তাই না?!
আপনার আপ-টু-ডেট আর্কিটেকচার এবং অবকাঠামো চিত্রিত করার সময়, নোট বা চেনাশোনা যোগ করুন, অথবা সমস্ত স্থানগুলিকে গাঢ় বা লাল রঙ করুন:
অঙ্কনগুলি প্রস্তুত হলে, আপনার দলের সাথে বসুন এবং এই সমস্ত বৃত্তাকার উপাদানগুলির জন্য কী পরীক্ষা করা দরকার তা নিয়ে চিন্তাভাবনা করুন৷
এর ফাঁদে পড়বেন না "এটা খুব বেশি! আমাদের এই সব ঢেকে রাখার জন্য অন্য সব কাজ বন্ধ করতে হবে!" আপনি একবারে এই সব কভার করতে হবে না. তবে আপনার একটি পরিকল্পনা দরকার। এখন, অন্য বোর্ড খুলুন, এবং আপনার পরীক্ষার লক্ষ্য লিখতে শুরু করুন। উদাহরণ:
সাফল্য এবং ব্যর্থতার জন্য সমস্ত fetch-data API অনুরোধগুলি কভার করুন যাতে আপনি জানেন যে আপনি খারাপ অনুরোধ পাঠাবেন না এবং যদি এটি ব্যর্থ হয় তবে এটি বিক্রেতার কারণে ব্যর্থ হয়৷
মিশন-সমালোচনামূলক ব্যবহারকারীর যাত্রার রূপরেখা। ইউনিটে এটি ভেঙে ফেলুন। ইউনিট পরীক্ষা লিখ। যখন পরীক্ষা পিরামিড উদ্ভাবিত হয়েছিল, একটি ইউনিট মানে একটি উপাদান, একটি পদ্ধতি নয়, তাই এটি কার্যকারিতা কভার করে, পদ্ধতি এবং ক্লাস নয়।
ট্র্যাফিক জ্যামগুলি চিহ্নিত করুন এবং সিদ্ধান্ত নিন যে আপনি কীভাবে সেগুলিকে মুক্ত করতে যাচ্ছেন৷
এটি সঠিকভাবে করার পরিকল্পনা করুন। আপনার দ্রুত এবং নোংরা কোড নোংরা পরীক্ষা দিয়ে নোংরা থাকবে।
আমি ইচ্ছাকৃতভাবে একটি কভারেজ ম্যাপ ব্যবহার করেছি এবং টেস্টিং পিরামিড নয় কারণ... এই পর্যায়ে, যখন আপনার জায়গায় ম্যানুয়াল বা স্বয়ংক্রিয় কোনো পরীক্ষা নেই, আপনি পিরামিডের জন্য প্রস্তুত নন।
অনেক দলের ভুল ধারণা রয়েছে যে তারা প্রথমে 96% ইউনিট পরীক্ষার কভারেজ অর্জন করতে পারে এবং তারপরে একীকরণ পরীক্ষায় চলে যায় এবং আরও অনেক কিছু। আধুনিক ইউনিট পরীক্ষার কভারেজের সমস্যা হল যে আমরা পদ্ধতি এবং ক্লাস পরীক্ষা করি, কার্যকারিতা নয়।
এমনকি আরও দলগুলি UI অটোমেশন দিয়ে শুরু করে, যা সমানভাবে ভুল।
এটি আসলে সবচেয়ে খারাপ জিনিস যা আপনি করতে পারেন এবং এটি ব্যর্থ হওয়া ধ্বংস হয়ে গেছে।
তাই পিরামিডের উপরে বা নীচে থেকে শুরু করবেন না, বরং একটি ঝুঁকি মানচিত্র তৈরি করুন।
কিছু বৈশিষ্ট্যের জন্য বিস্তৃত ইন্টিগ্রেশন পরীক্ষার প্রয়োজন হতে পারে, অন্যান্য বৈশিষ্ট্যগুলির জন্য ব্যাপক UI পরীক্ষার প্রয়োজন হতে পারে এবং পরবর্তী অংশটি প্রকৃতপক্ষে একটি মূল বৈশিষ্ট্য হতে পারে যার উপর সবকিছু নির্ভর করে (যদিও অন্য একটি লাল পতাকা), এবং আপনাকে এটিকে উপরে থেকে নীচে সম্পূর্ণরূপে কভার করতে হবে।
অথবা এটি একটি ডেটা সংগ্রহ পরিষেবা, এবং আপনাকে এপিআইগুলির কর্মক্ষমতার উপর ফোকাস করতে হবে, উদাহরণস্বরূপ।
আপনার সফ্টওয়্যার হটস্পটগুলির একটি মানচিত্র তৈরি করুন যা ভারী পরীক্ষার প্রয়োজন৷
তারপরে আপনি কীভাবে সেই পরীক্ষাটি স্বয়ংক্রিয় করতে পারেন সে সম্পর্কে চিন্তা করুন।
এর এটা গুটিয়ে যাক. আপনি যদি আপনার জীবনের অর্ধেকটি পরীক্ষা না করেই একটি জায়গায় কাজ করে ব্যয় করেন, কোডটি খারাপ অবস্থায় থাকে এবং আপনার কাছে সময় না থাকে, আপনি "আপনার সময় নেই" বলে আপনি আপস করতে থাকেন। আপনি সম্পূর্ণ খুশি নন, বা অন্তত আপনি বেশ উদাসীন - তারা অর্থ প্রদান করে, এটি তাদের কল, এবং এটি আপনার সিদ্ধান্ত নয়।
এটা শুধু দুঃখজনক. আমি নিশ্চিত যে আপনি আপনার কাজের জন্য গর্বিত নন। এবং আপনি এমনকি পরবর্তী ইউনিকর্নের জন্য অপেক্ষা করতে পারেন যেখানে আপনি চাকরির পাশাপাশি কারণটি পছন্দ করবেন।
ঠিক আছে, গত বছর জিনিসগুলি অনেক বদলে গেছে, তাই না?! আমরা আবারও শিখেছি যে ইউনিকর্নের অস্তিত্ব নেই। নিয়োগে থাকার জন্য আপনাকে একজন অসামান্য বিকাশকারী হতে হবে। কোম্পানিগুলি বের করেছে যে তারা তাদের অবদান নির্বিশেষে লোকেদের ফেলে দিতে পারে।
তবুও, সেখানে ইঞ্জিনিয়ার আছে যেগুলি রাখার জন্য একটি কোম্পানি সবকিছু করবে। তাদের একজন হতে, আপনাকে পরিবর্তন করতে হবে এবং ক্রমাগত প্রমাণ করতে হবে যে ব্যবসাটি আপনার মতো লোকেদের উপর নির্ভর করে।
সবাই খারাপ সফ্টওয়্যার লিখতে পারে, কিন্তু সত্যিকারের ভালোরা শুধুমাত্র আনন্দের সাথে চমৎকার সফ্টওয়্যারই লেখে না বরং অন্যদেরকে অনুপ্রাণিত করে এবং কোড-গুণমানের সংস্কৃতি ছড়িয়ে দেয়।
আপনি কুইকস্যান্ডে অগ্রগতি করতে পারবেন না, এবং শুধুমাত্র আপনি নিজেকে বের করতে পারবেন।