আপনি প্রথমে কী দেখছেন: কোড বা ডিজাইন?


17

যদি আপনি কেবল একটি নতুন প্রকল্পের সাথে পরিচয় করিয়েছেন, এটি কীভাবে কাজ করে তার ধারণা পেতে আপনি প্রথমে কী খুঁজছেন?

আপনি কি প্রথমে ডিজাইনের সন্ধান করেন? যদি কোনও নকশা থাকে তবে আপনি এতে কী খুঁজছেন? ক্লাস ডায়াগ্রাম বা ডিপ্লোয়মেন্ট ডায়াগ্রাম বা সিকোয়েন্স ডায়াগ্রাম বা অন্য কিছু?

অথবা আপনি কোডের জন্য সরাসরি যান? যদি তা হয় তবে কীভাবে আপনি বুঝতে পারবেন যে বিভিন্ন স্তরগুলি কীভাবে যোগাযোগ করে?


একবার কোড লেখা হয়ে গেলে নকশাটি তখন অনেকটাই একটি নিদর্শন ...

উত্তর:


24

আমি কোড দিয়ে শুরু। পৃথক নকশা নথি, যদি থাকে তবে ভুল বা ভুল ধারণা না হওয়ার সম্ভাবনা রয়েছে। সুতরাং, আমি কোডের মাধ্যমে কিছু সহজ প্রবাহ ট্রেস করার চেষ্টা করে শুরু করি; যদি এটি কোনও ওয়েব অ্যাপ হয় তবে এটি একটি অনুরোধ বা অনুরোধের ক্রম হতে পারে, উদাহরণস্বরূপ। এটি একবার হয়ে গেলে, আমার আরও বোঝাপড়া আটকে দেওয়ার জন্য এক ধরণের কঙ্কাল রয়েছে। তারপরে, আমি ফিরে গিয়ে ডিজাইন বা অন্যান্য ডকুমেন্টেশন পড়তে পারি, তবে সেই সময়ে, এগুলির সাথে সম্পর্কিত করার জন্য এবং তাদের সাথে বৈধতা দেওয়ার জন্য আমার কাছে কিছু কংক্রিট রয়েছে, যাতে আমি ডুফের তথ্য সনাক্ত করতে পারি। অথবা আমি কেবল পঠন কোড, বা পরীক্ষার কেসগুলি ইত্যাদি চালিয়ে যেতে পারি


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

আপনি কি এই উত্তরটি প্রথমে লিখেছেন বা ডিজাইন করেছেন?
মতিন উলহাক

না, আমি বিরক্ত না হওয়া অবধি কেবল কীবোর্ডের বিপরীতে আমার মাথা ছিটিয়েছি।
টম অ্যান্ডারসন

9

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


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

6

আমি একটি বিকাশকারী সিস্টেম স্থাপন করে শুরু করি। আমি নথিভুক্ত পদ্ধতি ব্যবহার করি। বাস্তবতার সাথে ডকুমেন্টেশন কতটা সিঙ্ক করছে তা এইটিকে বিড়ালটিকে ব্যাগ থেকে বের করে দেয়।

নির্ভরতাগুলি কী তা আমাকেও বলে। এই বিষয়টি।

এখন যে আমি একটি বিকাশকারী সেটআপ পেয়েছি, (এবং আমি যেতে যেতে সংশোধন করে সেটআপ নথিটি চিহ্নিত করি) আমি একটি সংস্করণ তৈরি করি। আমি এই পর্যায়ে সমস্ত প্রশ্ন জিজ্ঞাসা শেষ।

এখন এটি নির্মিত হয়েছে, আমি ব্যবহারকারীর ম্যানুয়াল থেকে প্রাথমিক অনুশীলন করি। এটি আমাকে সিস্টেমটি আসলে কী করে তা মোটামুটি বলে।

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

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

তারপরে আমি "টুডো" এবং "ফিক্সমি" মন্তব্যের জন্য আইডিই আউটপুটটি দেখি। "2.0 সংস্করণে ঠিক করা" এর মতো বিষয়গুলিও টিপ-অফ।

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


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

4

আমার অগ্রাধিকার হ'ল প্রকল্পটির একটি ওভারভিউ পেতে ডিজাইন দিয়ে শুরু করা এবং বিশদটি খনন করার আগে এর কয়েকটি মূল বৈশিষ্ট্য এবং / অথবা কাঠামো বোঝার চেষ্টা করা।


4

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


3

একটি জটিল টুকরো সফটওয়্যারটির জন্য আমি এটিকে মোটামুটিভাবে এমনভাবে দেখব যেন এটি কোনও নতুন উন্নয়ন প্রকল্প। বড় ধারণা- দর্শন, প্রসঙ্গ, সুযোগ, স্টেকহোল্ডারদের দিয়ে শুরু করুন। কিছু ব্যবহারকারীর নথিপত্র পড়ুন এবং এটি কীভাবে ব্যবহৃত হবে তার একটি ধারণা পান। সম্ভব হলে সফটওয়্যারটির সাথে কিছু ব্যবহারকারীর প্রশিক্ষণ পান (বা প্রযোজ্য)। তারপরে এটি কীভাবে উচ্চ স্তরে কাজ করে তার একটি ধারণা পেতে প্রয়োজনীয়তা এবং নকশার ডকুমেন্টেশনগুলি সন্ধান শুরু করুন। ডিজাইনাররা যদি এখনও থাকে তবে তাদের সাথে কথা বলুন। বিভিন্ন পদ্ধতিতে সিস্টেম আর্কিটেকচারটি দেখুন। সেখান থেকে মূল কার্যকারিতাটি খনন করা এবং প্রয়োজনীয় কোডগুলি এবং প্রয়োজন অনুযায়ী নকশায় ফিরে কিছু কোডের দিকে তাকানো শুরু করুন। আপনি কোডটির দিকে নজর দেওয়ার সাথে সাথে সফ্টওয়্যারটিকে কার্যত দেখতে দেখুন। সমস্ত সময়, ভবিষ্যতের রেফারেন্সের জন্য কিছু সংক্ষিপ্ত ডকুমেন্টেশন সংকলন করুন - আপনার নিজের ক্লিফ নোটের মালিক। আপনার কীভাবে এটি সমস্ত কাজ করে এবং একসাথে খাপ খায় তার একটি দুর্দান্ত ধারণা না পাওয়া পর্যন্ত শাখা ছাড়ুন তবে আপনি যে অংশগুলির সাথে কাজ করছেন সেগুলিতে মনোনিবেশ করুন। এতক্ষণে আপনার কাছে পুরো সিস্টেমের শীর্ষস্থান থেকে নীচে উপলব্ধি করা হয়েছে, বা কমপক্ষে আপনার জন্য প্রযোজ্য অংশগুলি।

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


3

কোডটি নিজেই এবং কোনও ডিজাইনের নথির মধ্যে আপনার পিছনে কাজ করা উচিত।

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

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

  • আপনি কোড এবং ডিজাইনের মাধ্যমে কাজ করার সাথে সাথে নিজের ডকুমেন্টগুলি তৈরি করুন যা আজ কোড সম্পর্কে আপনার বোঝার বর্ণনা দেয়। হতে পারে এই নথিগুলি একটি সাধারণ স্কেচ বা দুটি, সম্ভবত সেগুলি একটি উইকিতে রাইটআপ হয়, সম্ভবত তারা অন্য কিছু। এগুলি খুব জটিল করবেন না: 30-পৃষ্ঠার কোনও শব্দ ডক্স নেই। কেবল আপনার ধারণাগুলি নামিয়ে দিন, যা আপনার নিজস্ব চিন্তাভাবনাকে স্পষ্ট করে দেবে।


2

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


2

আমি নকশা ডকুমেন্টেশন দিয়ে শুরু। বিশেষত, স্পেসিফিকেশন - যা জিনিসটির দিকে তাকানো হচ্ছে তার উদ্দেশ্যকে বলে।

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

যদি সম্ভব হয় তবে আমি সেই লোকদের সাথে কথা বলি যারা এতে কাজ করেছিল - এটি কী করে? কিভাবে? কেন? কোথায় লাশ দাফন করা হয়?

কোডগুলিতে ঝাঁপ দেওয়ার বিকাশকারীদের মধ্যে একটি প্রবণতা রয়েছে: "আমাকে এই কোডটি আপনাকে দেখিয়ে দিন"। এটি তাদের পক্ষে ঠিক আছে তবে আমার প্রয়োজনগুলি হাইজ্যাক করে - যা উচ্চ স্তরের বোঝা যা নিম্ন স্তরের স্টাফকে প্রসঙ্গ দেয়।

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

তবেই কোডে প্রবেশের চেষ্টা করা মূল্যবান।

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

যা যা বলেছিল - যখন কোনও ডকো নেই, লোক নেই, এবং কেবল কোড নেই - তখন কোডটির দিকে তাকানো ছাড়া এটির জন্য কিছুই নেই।

সেক্ষেত্রে, আমি সাধারণত ধীর গভীর পড়া দ্বারা এটি চেষ্টা করে বুঝতে পারি না, আমি একটি দ্রুত পাস করি, সমস্ত কিছুর উপর পড়া পড়া im কখনও কখনও এটি কেবল ফাইলগুলি খোলা থাকে এবং পৃষ্ঠা-ডাউন কী টিপুন sit আপনি কেবল এটি করে একটি বড় ছবির আশ্চর্য প্রশংসা পেতে পারেন। (এবং কিছু কিছু ক্ষেত্রে আমি এক্সিকিউটেবল ফাইলগুলি স্ট্রিং-ডাম্প করেও সেগুলিতে ট্রল করেছিলাম, স্বাক্ষর এবং নিদর্শনগুলি খুঁজছি। গত 20-বিজোড় বছরগুলিতে এটি আশ্চর্যজনকভাবে কার্যকর হয়েছে))


1

আমি পরীক্ষা দিয়ে শুরু। ইউনিট পরীক্ষা এবং ইন্টিগ্রেশন পরীক্ষা ভাল লিখিত হয়, তারা ব্যবহারের ক্ষেত্রে বর্ণনা। যদি সেগুলি ভাল না লেখা হয় বা একেবারেই না লিখিত হয় (তবে দুঃখের বিষয়, এটি মূলত কেস), আমি কোডের এন্ট্রি পয়েন্টগুলি দিয়ে শুরু করি এবং তাদের নকশার সাথে মেলে।

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

আমি সর্বদাই চেষ্টা করি এমন কিছুতে মূল্য যুক্ত করার চেষ্টা করি; পরীক্ষার লিখন, কোড সাফ করা, বৃহত (20+ লাইন) ফাংশনগুলি রিফেক্টর করা।

আমি দেখতে পেয়েছি যে একা ডকুমেন্টেশন তৈরি করা কোডটিতে কোনও আসল মান যুক্ত করে না কারণ এটি কখনও কোডের সাথে ইন্টারঅ্যাক্ট করে না।


1

ঠিক আছে, "নকশা" কি? একটি পড়া? একটি ইউএমএল চিত্র? আপনি অর্ধেক একটি নকশা নথি করতে পারেন (এবং বেশিরভাগ ক্ষেত্রে), আপনি অর্ধেকভাবে কোড করতে পারবেন না

যে কোনও ডিজাইনটি কেবল একটি মতামত হতে চলেছে , যদিও কোডটি সত্য

আমি তখনই দ্বিতীয় মাধ্যমিক নথিগুলিকে উল্লেখ করব যখন আমি কোডটির যুক্তি বুঝতে পারি না

বিকাশকারীদের জন্য পড়ার কোড একটি প্রয়োজনীয় দক্ষতা। আপনি এখন এটি শিখতেও পারেন, তবে ক্যারিয়ারের সময় আপনি কোনও উপকারী ডকুমেন্টেশন দেখতে পাবেন না


1

তারপরে আমি বিকাশকারীর README, TODO এবং চেঞ্জলগের দিকে নজর দিই। যদি আমি বুঝতে না পারি যে সফ্টওয়্যারটি কেন লেখা হয়েছিল, এটি কীভাবে লেখা হয়েছিল এবং কোথায় চলছে ... আমি এটি ব্যবহার করি না।


1

প্রথমে ডিজাইন করুন, তারপরে কোড করুন, আপনি যদি চান তবে টপ-ডাউন করুন, তাই আমি কাজ করতে হবে এমন প্রতিটি স্তরের প্রসঙ্গটি বুঝতে পারি।

তবে যদি আমাকে খুব নির্দিষ্ট পরিবর্তন করতে হয়, যেমন কোনও প্রতিবেদন বা গণনা ঠিক করার মতো, আমি কেবল গিয়ে কোডটি দেখি।

আরও সুনির্দিষ্টভাবে, আমার "ডিজাইনের প্রথম" পদ্ধতির এটি একটি:

আমি যদি সেখানে একটি হয় তবে ডি ডোমেন মডেল দিয়ে শুরু করি, যদি না থাকে তবে আমি অন্তত একটি বেসিক তৈরি করি (একটি ভাল সূচনা পয়েন্ট হ'ল ডেটা মডেল)। এটি অ্যাপ্লিকেশনটির "গ্লোরিারি" এবং বস্তুর (শ্রেণি) মধ্যে সম্পর্ককে সংজ্ঞায়িত করে।

এটি চিত্র দ্বারা "কোন বস্তুগুলি পরিচালনা করা হয়" অ্যাপ্লিকেশন দ্বারা।

তারপরে আমি অ্যাপ্লিকেশনটির দ্বারা "কী প্রসেসগুলি করা হয়" তা খুঁজে পেতে ব্যবহারের ক্ষেত্রে মডেলটি সন্ধান করি, যদিও আমি যদি একটি হয় তবে একটি প্রক্রিয়া মানচিত্র পছন্দ করি যা প্রক্রিয়াগুলির ক্রমগুলি দেখায়।

এর পরে আমার অ্যাপ্লিকেশনটির একটি সুন্দর ছবি থাকা উচিত এবং তারপরে আমি পরিবর্তনটি ডিজাইনি করতে যেতে পারি।

যাইহোক, উপরের উত্তরটি ব্যবসায়িক প্রয়োগগুলির প্রসঙ্গে।


1

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

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


1
  1. আবেদনের কার্যকরী উদ্দেশ্য
  2. অ্যাপ্লিকেশনটির কার্যকরী সুযোগ এবং প্রবাহ গ্রাহকের অন্যান্য সিস্টেমের সাথে তার যোগসূত্র।

আমি অত্যন্ত সমালোচনামূলক মডিউল / পয়েন্টের আবেদনের কোড দেখার পরে: কোডটি দেখে, আমি ডিজাইনের ভালতা যাচাই করতে পারি।

উদাহরণ:

আর্থিক প্রতিবেদন সম্পর্কে আপনাকে একটি ওয়েব-অ্যাপের অ্যাপ্লিকেশন পরিচালনায় কাজ করতে হবে।

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

আমি বার্তাটি সম্পর্কে কোড পড়ার পরে, প্রারম্ভ এবং শেষ অ্যাপ্লিকেশন (সম্ভাব্য লক ইন ডিবি), ডেটা তৈরির মাস্টার প্রক্রিয়া যা জানাতে হবে ইত্যাদি ইত্যাদি (উদাহরণস্বরূপ, গ্যাসের স্টোরেজে মাস্টার প্রক্রিয়াটি সম্পর্কে সরবরাহ এবং ইনজেকশন সহ গ্রাহকদের স্টোরেজ অঞ্চলে গ্যাস স্টকের গণনা; গৌণ প্রক্রিয়াটি হ'ল এই ডেটাটির পূর্বে গণনা করা বিলিং)


1

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


0

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


0

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

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

আমার মতে একটি একক সাধারণ মডিউল বা সাধারণ অ্যাপ্লিকেশন হ'ল কোড স্তরে প্রায় সর্বদা সর্বোত্তমভাবে যোগাযোগ করা।

প্রতিটি পরিস্থিতিতে সঠিক উত্তর নেই!

আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.