একটি উত্তরাধিকার অ্যাপ্লিকেশন একটি সুসংগত আর্কিটেকচার শুরু


11

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

ডেটা লেয়ারে এলএলবিএলজেন এবং লিনক টু এলএলবিগেনের মিশ্রণ ব্যবহার করা হয়েছে , পাশাপাশি উত্তরাধিকারের ইনলাইন এসকিউএল এর বেশ কয়েকটি উদাহরণ রয়েছে যা রিফ্যাক্টর হয়নি।

কিছু ম্যানেজার ধরণের বাস্তবায়ন রয়েছে, তবে অনেক ক্ষেত্রে অ্যাপ্লিকেশনটি স্মার্ট ইউআই অ্যান্টি-প্যাটার্ন প্রদর্শন করে (অর্থাত ক্লাসের পিছনে কোডে খুব বেশি ব্যবসায়িক যুক্তি)

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

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

পুরো কোড বেসটি রিফ্যাকচারিং বাস্তবসম্মত নয় এবং সম্ভবত কাম্য নয়

আমি জানি এটি কোনও অভিনব পরিস্থিতি নয়, কীভাবে এই সমস্যার সাথে যোগাযোগ করবেন সে সম্পর্কে কোনও কার্যকর ধারণা বা ধারণা আছে?


1
"আকাঙ্ক্ষিত নয়" নিবন্ধটি হ'ল তিনি সমস্ত কিছু রিফ্যাক্টর না করে স্ক্র্যাচ থেকে পুনরায় লেখেন। এবং আপনি কি কখনও রিফ্যাক্টর করতে চান।
রায়নস

উত্তর:


20

আমিও একই পরিস্থিতিতে কাজ করছি এবং আমি আপনাকে নিম্নলিখিত পরামর্শ দিতে পারেন।

  1. আপনার প্রযুক্তিগত reduce হ্রাস করতে হবে । এখন। কেন? কারণ প্রযুক্তিগত debtণ আর্থিক financialণের মতো like আপনি এটির জন্য সুদ দিতে হবে।
  2. যেহেতু পুরো কোড বেসটি রিফ্যাক্ট করা সম্ভব নয়, তাই নিজেকে জিজ্ঞাসা করুন: এটি কী কী প্রতিরোধ করছে? এটি কি খুব বেশি কাজ? কেন?
  3. সময়মতো কারিগরি debtণ হ্রাস করার পরিকল্পনা তৈরি করুন। উদাহরণস্বরূপ, " দল দ্বারা স্পর্শ করা কোডের প্রতিটি বিটকে অবশ্যই নতুন স্ট্যান্ডার্ডের সাথে সংশোধন / রিফ্যাক্টর করা উচিত " হিসাবে নিয়ম স্থাপন করে । সাধারণত: ইউনিট পরীক্ষাগুলি অবশ্যই লিখতে হবে, কোডটি অবশ্যই সঠিক স্তরগুলিতে সরানো হবে ইত্যাদি etc. এটি আপনাকে হাস্যকর ব্যয়বহুল এবং নিম্নমানের "রিফ্যাক্টরিং" প্রকল্পগুলির অবলম্বন না করে প্রচুর কোড ঠিক করতে দেয়।
  4. জঞ্জাল জড়িয়ে দিন। ডাইউপলিং রিফ্যাক্টরিং এবং ভাল আর্কিটেকচারের মূল বিষয়। আপনি যদি কোনওভাবে কোড বেসটি পার্টিশন করতে পারেন তবে আপনি ছোট বিটগুলি রিফ্যাক্টর করতে পারেন।
  5. টেক debtণ আরও বৃদ্ধি করবেন না। টেক debtণ আরও বৃদ্ধি করবেন না। টেক debtণ আরও বৃদ্ধি করবেন না। করো না...

4
+1 আরও কারিগরি debtণ বৃদ্ধি করবেন না।
রায়নস

1
ধন্যবাদ - প্রযুক্তিগত debtণ ধারণাটি খনন করে চলেছে। এটি সম্পর্কে চিন্তা করার খুব দরকারী উপায়। সমস্ত দুর্দান্ত পরামর্শ (বিশেষত 3)
ম্যাট ইভান্স

1
আমি সত্যিই এটি পছন্দ করি: "দলের দ্বারা স্পর্শ করা প্রতিটি বিট কোড অবশ্যই নতুন স্ট্যান্ডার্ড" অংশে স্থির / রিফ্যাক্টর করা উচিত। আমি প্রায়শই শিবিরের মতো উন্নয়নের তুলনা করি: "আপনার
শিবিরের স্থানটিকে

6

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

Sklivvz যা বলে তা ছাড়াও কিছু পরামর্শ:

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

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

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

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


2

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


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

1

লিগ্যাসি সফ্টওয়্যার পুনর্বিবেচনা করার জন্য একটি সত্যিই দুর্দান্ত একটি বিনামূল্যে বই / পিডিএফ রয়েছে: http://scg.unibe.ch/download/oorp/

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


1

যদি এটির সুসংগত আর্কিটেকচার না থাকে তবে এটি কারণ সমস্যাটি বোঝা / যত্ন বোঝায় না। শুধু কোড দূরে। আপনি নতুন কোড লেখার সাথে সাথে আপনার নতুন ভাল আর্কিটেকচারটি প্রবর্তন করা উচিত।

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

আমি মূলত কেবলমাত্র সেই বিষয়গুলি সম্পর্কে যত্ন নিচ্ছি যা আপনার পরিচালকদের প্রকৃতপক্ষে যত্ন নিয়ে আসে, এমন সমস্যা নয় যা তাদের যদি আপনার জ্ঞান থাকে তবে তাদের যত্ন নেওয়া উচিত।

আপনি যদি ম্যানেজমেন্টের জন্য পুনঃ-আর্কিটেকচার বিক্রয় করতে পারেন, পরীক্ষা দিয়ে শুরু করুন। যদি তারা পরীক্ষায় বিনিয়োগ করতে না চান তবে আপনার প্রচেষ্টা কেবল আপনাকেই ঝামেলা করবে।

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