কোনও ডিজাইনের নথিতে কোনও প্রদত্ত নকশার পক্ষে উপকারের / বিতর্ক সম্পর্কে আলোচনা থাকা উচিত বা এটি সত্য এবং যুক্তিগুলির উপর ফোকাস করা উচিত?


13

আমি বর্তমানে একটি নকশা নথি আপডেট করার প্রক্রিয়ায় রয়েছি যাতে এটি সঠিক এবং ভবিষ্যতের বিকাশকারীদের জন্য আপ টু ডেট থাকে।

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

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

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

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

প্রশ্নাবলী:

  • যদি কোনও নকশার নথিটি কাঁচা তথ্যগুলিতে ("এটিই এটি নকশা") এবং যুক্তি ("এই কারণেই এটি নকশা কেন") বা এটির জন্য সমস্যাযুক্ত হতে পারে এমন নকশার সাথে অ-ত্রুটিযুক্ত সমস্যাগুলি চিহ্নিত করতে ব্যবহার করা উচিত ভবিষ্যতের বিকাশকারীরা?
  • যদি এই তথ্য ক্যাপচারের জন্য যদি নকশা নথিটি ব্যবহার না করা হয়, তবে কোন ধরণের দলিল এটি ক্যাপচার করবে এবং ডিজাইনের যৌক্তিকতা, ট্রেডঅফস এবং জ্ঞাত সমস্যাগুলির আলোচনার সাথে আর কী কী ক্যাপচার করা উচিত (ত্রুটিগুলি যেমন ট্র্যাক হয় না অন্যান্য সরঞ্জাম ব্যবহার করে)?

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

1
@ রবার্ট এটি আমার কাছে খুব একটা উত্তর বলে মনে হচ্ছে, যদিও আপনি উপযুক্ত উপায়ে বিবেচনা করবেন তা সম্ভবত প্রসারিত হতে পারে।
থমাস ওপেনস

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

উত্তর:


7

যদি দু'পক্ষের বাক্যগুলিতে ভাল বা বিপরীত সংক্ষিপ্তসার করা যায়, তবে সেগুলি ডিজাইনের নথিতে রাখা ঠিক আছে। আর যে কোনও কিছুই আলাদা করা উচিত।

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


আমি সেই বিন্যাসটি বেশ পছন্দ করি। যদি আপনি কিছু মনে করেন না তবে এটি চেষ্টা করার জন্য আমাকে এটি ধার / চুরি করতে হতে পারে। সম্ভবত আমি এটি কর্পোরেট-টেম্প্লেটিজও করব এবং আমার টিমের চারপাশে এটি পাস করব, যদি এটি আমার পক্ষে ভাল কাজ করে এবং আপনার পক্ষ থেকে কোনও আপত্তি নেই।
টমাস ওয়েন্স

2
@ থমাসের মালিক: এর জন্য যান! এটি এখানে ভাল কাজ করে, এবং আমি এটি পছন্দ করি। :) আমি মনে করি না যে আপনি এটি "চুরি" করতে পারবেন যেহেতু আমি জানি যে অন্যান্য সংস্থাগুলির লোকেরাও একই রকম কাজ করে, এটি খুব কমই "নতুন";)
হতাশায়

5

যদি কোনও নকশার নথিটি কাঁচা তথ্যগুলিতে ("এটিই এটি নকশা") এবং যুক্তি ("এই কারণেই এটি নকশা কেন") বা এটির জন্য সমস্যাযুক্ত হতে পারে এমন নকশার সাথে অ-ত্রুটিযুক্ত সমস্যাগুলি চিহ্নিত করতে ব্যবহার করা উচিত ভবিষ্যতের বিকাশকারীরা?

এটি "হয়-বা" নয়।

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

একটি নথির সুবিধা? লোকেরা এটি পড়তে পারে।

একটি ডকুমেন্টের অসুবিধা? কয়েক। বেশিরভাগ ক্ষেত্রে এটি তারিখের বাইরে চলে যায়।

একাধিক নথির সুবিধা? কোনটিই নয়।

একাধিক দলিলের অসুবিধা? DRY নীতি এবং সাক্ষর প্রোগ্রামিং পড়ুন দয়া করে। একাধিক দলিল মানে ত্রুটির একাধিক উত্স। প্রতিটি নথি অন্যের সাথে একমত হয় না এবং কোডের সাথে একমত হয় না। এটি বেশ সুস্পষ্ট। এটাই পাগলের পথ।


হাত কাটা এড়ানো।

একটি সদর্থক-দলিল দস্তাবেজ কী-যদি এবং আকর্ষণীয় উপদ্রব আলোচনার অনির্দিষ্ট গভীরতার দিকে টেনে আনতে পারে।

আপনি যদি মনে করেন যে উপকার ও কৌতূহল উপস্থাপন করা প্রয়োজন তবে এটিকে সংক্ষেপে এবং বিন্দুতে রাখুন।

কি উপর ফোকাস।

খালি হাড়ের নীচে যা নেই তা রাখুন।

আপনি যদি মানদণ্ড, অধ্যয়ন বা বাস্তবে অন্বেষণকৃত বিকল্পগুলি করেন তবে তা নথি করুন। তবে আপনি যদি কেবল বিকল্প বিবেচনা করে থাকেন তবে এটি হ্রাস করুন।

এটি আপনার বিচার ও দুর্দশার ব্যক্তিগত ইতিহাস হওয়া উচিত নয়।

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

  • এখনও সমস্যা আছে? অনির্ধারিত? তার মানে বিকল্প আছে। এটি নথি।


আপনার শেষ দুটি বাক্য বিশেষত সত্য। আমি যে সমস্ত বিষয় নিয়ে আলোচনা করার পরিকল্পনা করেছিলাম তা হ'ল সমস্যাগুলি যা আমি কোনও বৈশিষ্ট্য বাস্তবায়নের / একটি ত্রুটি সমাধানের, পরীক্ষার লেখার জন্য, বা প্রোফাইলিংয়ের সময় আবিষ্কার করা এবং পুরো ডিজাইনের সামগ্রিক সমালোচনা নয় faced আপনি কি ডিজাইনের নথিতে বা কোনও পৃথক নথিতে এটি নথির পরামর্শ দিচ্ছেন?
টমাসের মালিক

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

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

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

1
@ থমাস ওয়ানস: বিবেচনা করুন যে আপনি অনন্য এবং অন্য সকলেই অলস। "আমি যার কল্পনাও করতে পারি না"। আপনাকে আরও বেশি লোকের সাথে দেখা করতে হবে এবং ডকুমেন্টেশনে কী পরিমাণ সামান্য পরিমাণ রাখা হয়েছে তা দেখতে হবে। উদাহরণ স্বরূপ. 100 এর স্ট্যাকওভারফ্লো প্রশ্নগুলি - প্রতিদিন - টিউটোরিয়াল দ্বারা তুচ্ছ উত্তর দেওয়া হয়। এখনো. লোকেরা পুরোপুরি নির্বোধ প্রশ্নগুলি পড়ে না এবং জিজ্ঞাসা করে না। আমি গত 3 দশক ধরে কেবল যা পর্যবেক্ষণ করেছি তার পুনরাবৃত্তি করতে পারি। ভাবেন না পড়া। আপনার অভিজ্ঞতা ভিন্ন হতে পারে। আপনি পরামর্শ চেয়েছিলেন। আমি তোমাকে দিয়েছি।
এস .লট

2

সিদ্ধান্ত গ্রহণের প্রক্রিয়াটিতে 3 টি গুরুত্বপূর্ণ তথ্য রয়েছে:

  • যা চেষ্টা করা হয়েছিল এবং কী কাজ করে নি (এবং কেন এটি কাজ করে না, কারণ আপনি চলমান লক্ষ্যকে লক্ষ্য করছেন)
  • কি
  • কী হতে পারে (এক্স বাস্তবায়িত হওয়ার জন্য কেবল অপেক্ষা করছেন ...)

তবে, "কী" থেকে বাদে বাকি সমস্ত লোক পাঠককে বিভ্রান্ত করবে এবং তাকে সিস্টেমটি আঁকানো থেকে বিরত করবে।

আমি অন্য 2 টি ক্যাপচার করার ধারণাটি পছন্দ করি, যদিও তারা সিস্টেমটি শেখার জন্য কম আকর্ষণীয়, তারা পরিবর্তন করার সময় সময় সাশ্রয়ী হতে পারে।

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


1

হ্যাঁ. একটি নকশার নথিতে বর্ণিত নকশার সাথে সম্পর্কিত সুবিধাগুলি, ঝুঁকি এবং অনুমানগুলি ব্যাখ্যা করা উচিত। একটি নকশা নথির বিভিন্ন উদ্দেশ্য রয়েছে:

  1. নকশাটি লিখিতভাবে পান যাতে প্রতিটি এটি বুঝতে পারে এবং যাতে প্রতিটি ব্যক্তির বোঝা সময়ের সাথে সাথে না যায়।

  2. প্রকল্পটিতে কাজ করা অ-প্রযুক্তিগত লোকদের সাথে নকশাটি যোগাযোগ করুন।

  3. সময়সূচী, সংস্থান সম্পদ বরাদ্দ, ব্যয় নির্ধারণ এবং অন্যান্য ধরণের পরিকল্পনায় সহায়তা করুন।

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

  5. চুক্তি দ্বারা প্রায়শই সরবরাহযোগ্যগুলির মধ্যে একটি।

(সম্ভবত অন্যরাও আছেন তবে এগুলি খুব ভাল শুরু))

এই উদ্দেশ্যগুলির প্রত্যেকটি একটি ডিজাইন ডক দ্বারা পরিবেশন করা হয়েছে যা এই নকশাটি কেন বেছে নেওয়া হয়েছিল এবং সম্পর্কিত ঝুঁকিগুলি কী তা স্পষ্টভাবে ব্যাখ্যা করে:

  1. এটি ঝুঁকি এবং সুবিধাগুলি কী তা দলের প্রত্যেককে জানা উচিত যাতে তারা এই ঝুঁকিগুলি এড়াতে এবং ডিজাইনের সুবিধাগুলির সর্বোত্তম ব্যবহার করতে একত্রে কাজ করতে পারে।

  2. প্রযুক্তিবিহীন দলের সদস্যদের জন্য, ঝুঁকিগুলি এবং সুবিধাগুলি বোঝা প্রায়শই ডিজাইনের নিজস্ব বিবরণের চেয়ে বেশি গুরুত্বপূর্ণ।

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

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

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

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

ডিজাইনের নথিগুলি লেখার জন্য এখানে একটি ব্লগ এন্ট্রি যা আপনাকে সহায়ক মনে করতে পারে।


0

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

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


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

0

আমি ব্যক্তিগতভাবে এটি নকশা নথিতে রাখি না। ডিজাইনের নথিতে এটি কীভাবে হয় তা নয়, এটির রূপরেখা দেওয়া উচিত।

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


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

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

0

আমি ডিজাইন নথিতে যুক্তি স্থাপন সম্পর্কে আপনার সাথে একমত।

যাই হোক,

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

সুতরাং,

রক্ষণাবেক্ষণের সময় ডিজাইনে যে পরিবর্তনগুলি করা হয় সে সম্পর্কে আমি যুক্তি কেবল সন্নিবেশ করান।


অবশ্যই শেষ বাক্য। আমি জানি না কেন জিম, বব এবং স্টিভ এইভাবে তাদের অ্যাপ্লিকেশনটি ডিজাইন করার সিদ্ধান্ত নিয়েছে, তাই আমি এটিকে যুক্তিযুক্ত করার চেষ্টাও করব না। যদিও আমি নিশ্চিত করতে পারি যে কোনও নির্দিষ্ট মডিউল বা উপাদান প্রয়োজনীয়তার সাথে জড়িত এবং আমি যে সিদ্ধান্ত নিয়েছি সেগুলিও যুক্তিযুক্ত করতে পারে।
টমাস ওপেনস
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.