এমন কোনও প্রোগ্রামিং দৃষ্টান্ত রয়েছে যা অন্যান্য প্রোগ্রামারদের কাছে নির্ভরতা তৈরির প্রচার করে?


26

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

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

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

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


2
আপনি কী ধরণের "বিভিন্ন শিল্পকর্মের সাথে সংযুক্ত গোলকধাঁধার মত নির্ভরতা" বোঝাতে পারেন? তারা কি নির্ভরতা তৈরি করে, এটি মাভেনের মতো বিল্ড সরঞ্জাম দিয়ে সমাধান করা যেতে পারে? এগুলি কি ইনপুট নির্ভরতা, যেখানে এই নিদর্শনগুলির মধ্যে একটি এমন কোনও ইনপুট নির্ভর করে যা স্পষ্ট বা স্পষ্ট নয়? তারা কি ডাটাবেস টেবিলের মধ্যে কী নির্ভরতা?
হতাশ

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

4
আক্ষরিক অর্থে তাদের সব
মাইলস রাউট 17'17

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

1
ডিজাইনের নিদর্শন নামে একটি বই রয়েছে (বইটি স্তন্যপান করে তবে এটি যা বলে তার বেশিরভাগই ভাল, সিঙ্গলটন সম্পর্কে কিছু বাদে)। নির্ভরতা পরিচালনার ক্ষেত্রে এর বেশ কয়েকটি বিভাগ রয়েছে।
ctrl-alt-delor

উত্তর:


19

আবিষ্কারযোগ্যতা

এর অনুপস্থিতি অনেক সংগঠনে জর্জরিত। ফ্রেডটি আবার কোথায় তৈরি করেছে? গিট ভাণ্ডারে অবশ্যই। কোথায়?

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

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

একটি সংবেদনশীল সাংগঠনিক আর্কিটেকচার নিয়ে এসে এটি দলিল করার দলটির দায়িত্ব এর মতো জিনিস রয়েছে

  • ফোল্ডার সংস্থা
  • প্রকল্প রেফারেন্স
  • ক্লাস ডকুমেন্টেশন (এটি কী, এটি কী করে, কেন এটি বিদ্যমান, এটি কীভাবে ব্যবহৃত হয়)
  • প্রকল্প, মডিউল, সমাবেশ, ডকুমেন্টেশন যাই হোক না কেন।

দলগুলি যাতে নিয়মিত চক্রটি পুনরায় উদ্ভাবন না করে সেগুলি বিষয়গুলিকে সংগঠিত এবং আবিষ্কারযোগ্য করে তোলা দলের দায়িত্ব।

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


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

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

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

5
@ রবার্টহারভে: বেশ সম্প্রতি শুনেছেন: "আমরা এমন কোড লিখি যা ডকুমেন্টেশনের প্রয়োজন হয় না"। ভুল। আপনি ডকুমেন্টেশন ছাড়াই কোড লিখছেন।
gnasher729

3
কিছু ভাল জিনিস এখানে। এনবি লেখার কোডের মধ্যে পার্থক্য রয়েছে যার পক্ষে মন্তব্য এবং সমর্থনকারী ডকুমেন্টেশন লেখার প্রয়োজন নেই ।
রবি ডি

10

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

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

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


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

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

অনুমোদনের সম্ভাব্য ছোট পরিবর্তনগুলির প্রস্তাব দেওয়ার জন্য +1। আমি এটি অভিজ্ঞতা পেয়েছি এবং এটি আমাকে আরও প্রভাবিত করে কেউ হতে সাহায্য করেছিল এবং তারপরে আমার প্রস্তাবগুলি আরও বেশি প্রভাব ফেলল।
RawBean

2

স্থাপত্য।

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

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

আদর্শভাবে, এই নিয়মগুলি মনের একাকীত্বের দ্বারা একীকৃত

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

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

আমি কোনও এক ব্যক্তির সমস্ত সিদ্ধান্ত গ্রহণের বড় ভক্ত নই; তবে, এমন একজন "আর্কিটেক্ট" বা "প্রযুক্তিগত পণ্য মালিক" সনাক্ত করা যিনি স্থাপত্য আলোচনার মধ্যস্থতা এবং সিদ্ধান্তের নথিপত্র দায়ের করার জন্য দায়বদ্ধ, এটি আরও বৃহত্তর মন্দকে মোকাবেলা করে: দায়বদ্ধতার বিভাজন যা কোনও বোধগম্য আর্কিটেকচারের দিকে পরিচালিত করে না


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

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

1

সফটওয়্যার ইঞ্জিনিয়ারিং এ স্বাগতম (উভয় অর্থে);) এটি একটি ভাল প্রশ্ন, তবে সত্যই কোনও সহজ উত্তর নেই, কারণ আমি নিশ্চিত যে আপনি সচেতন। সময়ের সাথে সাথে এটি আরও ভাল অনুশীলনের দিকে বিকশিত হওয়া, মানুষকে আরও দক্ষ হতে প্রশিক্ষণ দেওয়ার (সংজ্ঞা অনুসারে শিল্পের বেশিরভাগ লোকই মাঝারি দক্ষতা) এর একটি ঘটনা ...

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

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

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

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


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

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

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

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

2
ঠিক আমার অভিজ্ঞতা: আপনার দলের সদস্যরা তারা কী করছে তা বুঝতে হবে। আমি লোককে এমভিভিএম এবং এমভিসি মিশ্রিত করতে দেখি, অন্যরা ডাব্লুপিএফ নিয়ন্ত্রণগুলি এমনভাবে ব্যবহার করে যা উইন্ডোজ ফর্মগুলির সাথে স্বাভাবিক (বা বরং: ভিবি 6), সি-তে প্রোগ্রামিং করা লোকেরা অবজেক্ট-ওরিয়েন্টেশনের প্রাথমিক জ্ঞান ছাড়াই ... তাদের শেখান। তাদের আবার শিখিয়ে দিন। হতাশ হবেন। তাদের আবার শিখিয়ে দিন, ... প্রায়শই হাল ছেড়ে দেওয়ার কথা ভাবছেন। এবং তাদের আবার
বার্নহার্ড হিলার

1

আমি @ রবার্টহার্ভির কনভেনশন সম্পর্কে ধারণা পছন্দ করি এবং মনে করি তারা সহায়তা করে। আমি @ কার্লবিলিফেল্টের "আপনি যেমন যান তেমন নথি" করার ধারণাটিও পছন্দ করি এবং এটি জরুরী জানি কারণ ডকুমেন্টেশনটি বর্তমান রাখার একমাত্র উপায় way তবে আমি মনে করি যে ওভার-আর্চিংয়ের ধারণাটি হ'ল কীভাবে আপনার কোডের সমস্ত টুকরো খুঁজে পেতে, তৈরি করতে এবং মোতায়েন করা জরুরী!

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

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

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

উপসংহারে

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


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

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

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

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

1

প্রশ্নের উত্থাপিত হিসাবে প্রশ্নের উত্তর দেওয়ার জন্য (আপনার নির্দিষ্ট পরিস্থিতির জন্য আপনাকে পরামর্শ দেওয়ার চেয়ে):

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


0

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

প্রারম্ভিকদের জন্য, ডাটাবেসের প্রতিটি সারিতে একটি DATE_ADDED এবং DATA_UPDATED কলাম ছিল যাতে আমরা দেখতে পারি কখন এটি ডাটাবেসে যুক্ত হয়েছিল এবং কখন এটি পরিবর্তন করা হয়েছিল। আমাদের কাছে একটি SOURCE_CODE কলামও ছিল যাতে আমরা জানতে পারি যে প্রতি বিট ডেটা সিস্টেমটিতে প্রবেশ করেছে।

এরপরে আমাদের কাছে সাধারণ সরঞ্জাম ছিল যা আমাদের সমস্ত ডেটা গুদামে যেমন বাছাই, টেবিলের ম্যাচ, স্লাইজার এবং ডিকার ইত্যাদি জুড়ে চলেছিল had

বেসপোক কোডটি একেবারে ন্যূনতমতে রাখা হয়েছিল এবং তারপরেও, এটি বিভিন্ন কোডিং এবং প্রতিবেদনের শৈলীতে নিশ্চিত হতে হয়েছিল।

আমি ধরে নিতে চলেছি আপনি ইটিএল স্যুটগুলির সাথে ইতিমধ্যে পরিচিত । এই দিনগুলিতে আপনি নিখরচায় প্রচুর কার্যকারিতা পেয়েছেন যা প্রায় এক দশক আগে আমি যখন খেলায় ছিলাম তখন উপস্থিত ছিল না।

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


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

1
আদর্শটি হ'ল আপনি স্টেজিং টেবিল বা ফ্ল্যাট ফাইলগুলির মাধ্যমে ডেটা শেষের শেষের দিকে ট্র্যাক করতে পারেন তবে আপনার যদি তা না থাকে তবে আপনার চলার কোড রয়েছে।
রবি ডি

0

আপনার মামলার সাথে এটি কতটা প্রাসঙ্গিক তা আমি জানি না, নির্ভরতা আরও দৃশ্যমান এবং কোডের সাধারণ রক্ষণাবেক্ষণের জন্য কিছু কৌশল রয়েছে-

  • গ্লোবাল ভেরিয়েবলগুলি এড়িয়ে চলুন, পরিবর্তে প্যারামিটার ব্যবহার করুন। এটি ক্রস ল্যাঙ্গুয়েজ কলগুলিতেও প্রযোজ্য।
  • যতটা সম্ভব ভেরিয়েবলের মান পরিবর্তন / পরিবর্তন করা এড়িয়ে চলুন। একটি নতুন পরিবর্তনশীল তৈরি করুন এবং সম্ভব হলে আপনার মানটি পরিবর্তন করতে হবে।
  • কোডটি মডুলার করুন। অংশটি আসলে কোন সাধারণ বাক্যে কী করছে (কীভাবে নয়) তা বর্ণনা করা সম্ভব না হলে শর্তটি সন্তুষ্ট করে এমন মডিউলগুলিতে বিভক্ত করুন।
  • আপনার কোড অংশের নাম সঠিকভাবে দিন Name কোডের কোনও অংশটি সহজ শর্তে কী করছে তা আপনি যখন বর্ণনা করতে পারবেন তখন সেই পদগুলি অংশটির নাম হয়ে যায়। সুতরাং, কোডটি মডিউল / শ্রেণি / ফাংশন / পদ্ধতি / পদ্ধতি ইত্যাদির মাধ্যমে স্ব নথিভুক্ত হয়
  • আপনার কোড পরীক্ষা করুন। আপনার কোডের সত্ত্বাগুলি তাদের পূর্ববর্তী পয়েন্টে আলোচিত, তাদের নাম ন্যায্য করে কিনা তা পরীক্ষা করুন।
  • কোডগুলিতে ইভেন্টগুলি লগ করুন। কমপক্ষে দুটি স্তরের লগ বজায় রাখুন। প্রথমটি সর্বদা সক্ষম থাকে (এমনকি উত্পাদনেও) এবং শুধুমাত্র সমালোচনামূলক ইভেন্টগুলিতে লগ করে। এবং অন্যটি মূলত সমস্ত কিছুতে লগ করতে ব্যবহার করুন তবে চালু বা বন্ধ করা যেতে পারে।
  • আপনার কোডবেস ব্রাউজ, রক্ষণাবেক্ষণ এবং বিকাশের জন্য উপযুক্ত সরঞ্জামগুলি সন্ধান করুন এবং ব্যবহার করুন। এমনকি ভিজ্যুয়াল স্টুডিও কোডের একটি সাধারণ "অনুসন্ধান সবকিছু" বিকল্পটি কিছু ক্ষেত্রে আমার জীবনকে অনেক সহজ করে তুলেছে।
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.