বছরের পর বছর ধরে কীভাবে একটি বড় এবং জটিল সফ্টওয়্যার পণ্য বজায় রাখা যায়?


156

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

দেখে মনে হয় যে উন্নয়নের একটি নির্দিষ্ট পর্যায়ে সফ্টওয়্যারটিতে "হ্যাকিয়র" এবং "হ্যাকিয়র" পাওয়ার প্রবণতা রয়েছে বিশেষত যখন দলের সদস্যদের মধ্যে যে কোনও একটি সংস্থাতে আর্কিটেকচারের কাজের সংজ্ঞা দেয়নি।

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

বছরের পর বছর ধরে কীভাবে সোর্স কোডটি সত্যই রক্ষণাবেক্ষণের জন্য রাখা যায় সে সম্পর্কে কোনও সহায়ক পরামর্শ রয়েছে?


9
বইগুলি সুপারিশ করুন: স্টিভ ম্যাককনেলের লেখা 'সফটওয়্যার প্রজেক্ট বেঁচে থাকার গাইড', স্টিভ ম্যাককনেলের 'র‌্যাপিড ডেভলপমেন্ট', মার্টিন ফওলারের 'রিফ্যাক্টরিং'
ইমরান ওমর বুখশ

15
... এবং আঙ্কেল বব দ্বারা 'ক্লিন কোড';) (রবার্ট সি মার্টিন)
গ্যান্ডালফ

34
এটি কি খুব প্রশ্ন এমন কিছু নয় যা বিশ্ববিদ্যালয়গুলিতে কয়েক দশকের ভারী পাঠ এবং পুরো কোর্সকে উত্সাহিত করেছিল?
স্পষ্টত

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

8
@ এরিক ইয়িন: স্ব-ডকুমেন্টিং কোডের জন্য প্রচেষ্টা করুন। উদ্দেশ্যগুলি সম্পর্কে মন্তব্যগুলি কেবল সেগুলি ব্যবহার করুন যেখানে তারা বোঝাপড়া বাড়ায়।
মিচ গম

উত্তর:


138

কোড পচা এড়ানোর একমাত্র আসল সমাধান হ'ল ভাল কোড করা!

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

সাধারণ ভাল অভ্যাসগুলি সাহায্য করতে পারে:

  1. সহজবোধ্য রাখো.
  2. সহজবোধ্য রাখো. এটি বিশেষত আর্কিটেকচার, "বড় চিত্র" -র ক্ষেত্রে প্রযোজ্য। বিকাশকারীদের যদি বড় ছবি পেতে খুব অসুবিধা হয় তবে তারা এর বিরুদ্ধে কোড দিচ্ছেন। সুতরাং আর্কিটেকচারটি সহজ করুন যাতে সমস্ত বিকাশকারী এটি পায়। যদি স্থাপত্যটি সাধারণের চেয়ে কম হতে হয়, তবে সেই আর্কিটেকচারটি বুঝতে বিকাশকারীদের অবশ্যই প্রশিক্ষণ দিতে হবে। যদি তারা এটি অভ্যন্তরীণ করে না, তবে তাদের এতে কোড করা উচিত নয়।
  3. কম সংযোগ এবং উচ্চ সংহতি জন্য লক্ষ্য । দলের সবাই এই ধারণাটি বোঝে তা নিশ্চিত করুন। একটি প্রকল্পে আলগাভাবে মিলিত, সম্মিলিত অংশগুলির সমন্বয়ে, যদি কিছু অংশ অনিবার্য জগাখিচুড়ি হয়ে যায়, আপনি কেবল সেই অংশটি আনপ্লাগ এবং পুনর্লিখন করতে পারেন। কাপলিং শক্ত থাকলে এটি আরও শক্ত বা প্রায় অসম্ভব।
  4. ধারাবাহিক থাকো. কোন মানদণ্ডগুলি সামান্য অনুসরণ করবে তবে দয়া করে কিছু মান অনুসরণ করুন । একটি দলে প্রত্যেকের অবশ্যই একই মানদণ্ড অনুসরণ করা উচিত। অন্যদিকে, স্ট্যান্ডার্ডগুলির সাথে খুব বেশি সংযুক্ত হওয়া এবং বাকীগুলি ভুলে যাওয়া সহজ: দয়া করে বুঝতে পারেন যে মান কার্যকর হওয়ার সময় সেগুলি কেবল ভাল কোড তৈরির একটি ছোট্ট অংশ। এটির একটি বড় সংখ্যা তৈরি করবেন না।
  5. ধারাবাহিকভাবে কাজ করার জন্য একটি দল পেতে কোড পর্যালোচনাগুলি কার্যকর হতে পারে।
  6. আইডিই, সংকলক, সংস্করণ নিয়ন্ত্রণ, বিল্ড সিস্টেম, ডকুমেন্টেশন জেনারেটর, গ্রন্থাগার, কম্পিউটার , চেয়ার , সামগ্রিক পরিবেশ ইত্যাদি ইত্যাদি - সমস্ত সরঞ্জাম ভালভাবে বজায় রাখা হয়েছে যাতে বিকাশকারীদের গৌণ সমস্যাগুলির সাথে তাদের সময় নষ্ট না করতে হয় তা নিশ্চিত করুন প্রকল্প ফাইল সংস্করণ বিরোধ হিসাবে লড়াই, উইন্ডোজ আপডেট, গোলমাল এবং যাই হোক না কেন ব্যালাল কিন্তু বিরক্তিকর স্টাফ। এই জাতীয় উদ্বেগজনক জিনিসগুলির সাথে বারবার যথেষ্ট সময় নষ্ট করা মনোবলকে হ্রাস করে, যা কমপক্ষে কোডের মানের উন্নতি করতে পারে না। একটি বড় দলে, এক বা একাধিক লোক থাকতে পারে যার মূল কাজ বিকাশকারী সরঞ্জাম বজায় রাখা।
  7. প্রযুক্তিগত সিদ্ধান্ত নেওয়ার সময়, প্রযুক্তিটি পরিবর্তন করতে এটি কী গ্রহণ করবে তা ভেবে দেখুন; কোন সিদ্ধান্তগুলি অপরিবর্তনীয় এবং কোনটি নয়। অপরিবর্তনীয় সিদ্ধান্তগুলি অতিরিক্ত সাবধানতার সাথে মূল্যায়ন করুন। উদাহরণস্বরূপ, আপনি যদি জাভাতে এই প্রকল্পটি লেখার সিদ্ধান্ত নেন , এটি একটি বেশ অনেকটা অপরিবর্তনীয় সিদ্ধান্ত। আপনি যদি ডেটা ফাইলের জন্য কিছু স্ব-সেদ্ধ বাইাইনারি ফর্ম্যাট ব্যবহার করার সিদ্ধান্ত নেন তবে এটিও মোটামুটি অপরিবর্তনীয় সিদ্ধান্ত (একবার কোডটি বন্যের বাইরে চলে গেলে এবং আপনাকে সেই ফর্ম্যাটটিকে সমর্থন করতে হবে)। তবে জিইউআইয়ের রঙগুলি সহজেই সামঞ্জস্য করা যায়, প্রাথমিকভাবে বাদ দেওয়া বৈশিষ্ট্যগুলি পরে যুক্ত করা যেতে পারে, সুতরাং এ জাতীয় সমস্যা নিয়ে কম চাপ দিন।

8
এগুলি দুর্দান্ত পয়েন্টস। আমার অবশ্যই স্বীকার করতে হবে যে আমি "এটিকে সহজ রাখি" এর সাথে লড়াই করি t এটি বিভিন্ন প্রসঙ্গে বিভিন্ন ব্যক্তির কাছে বিভিন্ন জিনিস বোঝায় যা "সরল" বরং জটিল করে তোলে (তবে তখন বিষয়গুলিকে জটিল করার মতো প্রাকৃতিক প্রবণতা আমার আছে)।
ক্রমিই

3
আমি আপনার পয়েন্টগুলির সাথে পুরোপুরি একমত, বিশেষত "কেআইএস"। তবে আমি এমন একটি প্রবণতা দেখছি যা আরও বেশি সংখ্যক (কম বয়সী?) বিকাশকারীরা এমনকি সাধারণ প্রসঙ্গটি বর্ণনা করতে বরং জটিল কাঠামো ব্যবহার করে।
10'12


8
উম্ম, এবং "8. এটি সহজ রাখুন"।
দাউদ ইবনে করিম

7
# 6 একটি +10 এর উপযুক্ত।
জিম জি।

55

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

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

একটি দুর্দান্ত পার্শ্ব প্রতিক্রিয়া হিসাবে, ইউনিট পরীক্ষাগুলি আশা করি আপনার বাগের সংখ্যাও হ্রাস করবে।


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

40

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

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

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


খুব ভালো কথা, আপনি ষাঁড়ের চোখে আঘাত করলেন! দুঃখের সাথে বলতে হবে, তবে এখানে ঠিক যা ঘটছে। এবং প্রযুক্তিগত সীসা ছাড়াই জিনিসগুলি পরিবর্তন করা অসম্ভব বলে মনে হচ্ছে ...
10'12

4
@ সিআরমিউ যেভাবে জিনিসগুলি যান ঠিক তেমন অনুমান করি তবে আমি এ থেকে ক্লান্ত হয়ে উঠছি। আমার চারপাশের সবকিছু কী ভুল বলে মনে হচ্ছে তা সম্পর্কে আমি এতটা সচেতন না হলে আমি আবারও জুনিয়র বিকাশকারী হতে চাই wish দেখে মনে হচ্ছে আমি আমার মাঝারি ক্যারিয়ারের প্রথম দিকে সঙ্কট শুরু করছি। তবে আমি ঘুরে বেড়াচ্ছি ... সাহায্য করে খুশি।
ম্যাপেল_শ্যাফ্ট

1
@ মার্ফ কেন রক্ষণাবেক্ষণের পর্যায়ে আপনার কাছে সর্বজনীন দলের নেতৃত্ব থাকা উচিত নয়? আমি যতক্ষণ না আগেও কোনও দলের নেতৃত্বের কাছ থেকে কিছু কম আশা করেছিলাম, এবং আমি যখন দলের নেতৃত্ব ছিলাম তখন আমি নিজের কাছ থেকে কিছু কম আশা করতাম না।
ম্যাপেল_শ্যাফ্ট

1
@ ম্যাপেল_শ্যাফ্ট কারণ ক) আমি ধরে নিই না যে একটি প্রকল্পের জন্য নিবেদিত একটি দল নেতৃত্ব রয়েছে এবং এটি কমবেশি প্রথম প্রয়োজনীয়তা এবং খ) আমার মনে হয় আপনাকে নকশা এবং বাস্তবায়ন (এটি সমস্ত) বুঝতে হবে এবং এটিই হার্ড। একদিকে আমরা সকলেই যুক্তি দিই যে আমাদের প্রকল্পগুলিতে সমস্ত জ্ঞানের এক ফন্ট আমাদের থাকা উচিত নয় এবং এখনও এখানে আমরা বলছি যে আমাদের একটি আছে? যে যোগ হয় না?
মারফ

2
@ ম্যাপেল_শ্যাফ্ট সম্ভবত আমি একজন বিমল পুরনো প্রোগ্রামার হয়েছি (-: তবে এখানে একটি সমস্যা রয়েছে যে এটি প্রায়শই "স্টাইল" প্রয়োগ করা হয় যা বিদ্যমান কোডবাসে গভীরভাবে অনুসরণ করা দরকার - এবং এটি কোডার এবং সীসা উভয়ের জন্যই ভিনগ্রহ হতে পারে (প্রচুর জন্য আসল বিশ্বের কারণে)
মার্ফ

18

আমরা করতে পারি এমন বেশ কয়েকটি জিনিস রয়েছে:

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

এমন সংস্কৃতি তৈরি করুন যেখানে সমস্ত বিকাশকারী স্থাপত্যের মালিকানা গ্রহণ করে। সমস্ত বিকাশকারীদের স্থাপত্য অখণ্ডতা বিকাশ এবং রক্ষণাবেক্ষণের প্রক্রিয়াতে জড়িত হওয়া দরকার।

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

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

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

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


1
+1, বিশেষত "এমন একটি দল তৈরির জন্য যা একসাথে ভালভাবে কাজ করতে পারে এবং কার্যত একটি পণ্য সরবরাহ করতে পারে" "
দশম

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

1
@ ক্যাস্পার: হুবহু আমার মনে মনে যা ছিল তা তুমি আমার চেয়ে বেশি প্রকাশ কর।
ক্রমিই

18

এই সমস্যাটি সম্পর্কে আমি যেভাবে যাচ্ছি তা হ'ল মূলটিকে স্ন্যাপ করা:

আমার ব্যাখ্যাটি মাইক্রোসফ্ট /। নেট থেকে শর্তাদি ব্যবহার করবে , তবে যে কোনও প্ল্যাটফর্ম / সরঞ্জামবক্সে প্রযোজ্য হবে:

  1. নামকরণ, কোডিং, চেকিনস, বাগ প্রবাহ, প্রক্রিয়া প্রবাহ - মূলত যে কোনও কিছুতে মানক ব্যবহার করুন Use
  2. দলের সদস্যদের যারা বিধি মানেন না তাদের বিদায় জানাতে ভয় পাবেন না। কিছু বিকাশকারীরা কেবলমাত্র নির্ধারিত মানগুলির মধ্যে কাজ করতে পারে না এবং কোড-বেস পরিষ্কার রাখার জন্য যুদ্ধক্ষেত্রে 5 তম কলামের শত্রু হয়ে যাবে
  3. দীর্ঘ সময় ধরে পরীক্ষার জন্য নিম্ন দক্ষ দলের সদস্যদের বরাদ্দ করতে ভয় পাবেন না।
  4. পচা কোড পরীক্ষা করা এড়াতে আপনার অস্ত্রাগারের প্রতিটি সরঞ্জাম ব্যবহার করুন: এতে ডেডিকেটেড সরঞ্জামগুলি পাশাপাশি প্রিল-লিখিত ইউনিট পরীক্ষাগুলি অন্তর্ভুক্ত যা বিল্ড ফাইলগুলি, প্রকল্পের ফাইলগুলি, ডিরেক্টরি কাঠামো ইত্যাদি পরীক্ষা করে invol
  5. প্রায় 5-8 সদস্যের একটি দলে, আপনার সেরা লোকটি প্রায় নিয়মিত রিফ্যাক্টরিং করুন - অন্যরা যে গণ্ডগোলটি ফেলে দেয় তা পরিষ্কার করে। এমনকি আপনি যদি ক্ষেত্রের সেরা বিশেষজ্ঞদের খুঁজে পান, তবুও আপনার মধ্যে একটি জগাখিচুড়ি থাকবে - এটি অনিবার্য নয়, তবে ধ্রুবক রিফ্যাক্টরিং দ্বারা এটি সীমাবদ্ধ হতে পারে।
  6. ইউনিট পরীক্ষা লিখুন এবং সেগুলি বজায় রাখুন - প্রকল্পটি পরিষ্কার রাখতে ইউনিট পরীক্ষার উপর নির্ভর করবেন না, তারা তা করে না।
  7. সবকিছু নিয়ে আলোচনা। দলে জিনিসগুলি নিয়ে আলোচনার জন্য কয়েক ঘন্টা ব্যয় করতে ভয় পাবেন না। এটি তথ্য ছড়িয়ে দেবে এবং খারাপ কোডের মূল কারণগুলির একটিকে দূর করবে: প্রযুক্তি, লক্ষ্য, মান ইত্যাদি নিয়ে বিভ্রান্তি confusion
  8. হতে খুব কোড লেখা পরামর্শদাতা থেকে সতর্ক থাকুন: তাদের কোড, প্রায় সংজ্ঞা দ্বারা, বাস্তব শিটি কাপড় হতে হবে।
  9. চেকইন আগে প্রক্রিয়া পদক্ষেপ হিসাবে অগ্রাধিকার পর্যালোচনা করুন। রোলব্যাক কমিট করতে ভয় পাবেন না।
  10. মুক্তির আগে শেষ পর্যায়ে না থাকলে খোলা / ঘনিষ্ঠ নীতিটি কখনই ব্যবহার করবেন না: এটি কেবল পচা কোডকে গন্ধে ফেলে রাখার দিকে পরিচালিত করে।
  11. যখনই কোনও সমস্যার মুখোমুখি হয়, কোনও সমাধান কার্যকর করার আগে এটি সম্পূর্ণরূপে বোঝার জন্য সময় নিন - বেশিরভাগ কোড পচা সম্পূর্ণরূপে বোঝা যায় না এমন সমস্যার সমাধান বাস্তবায়ন থেকে আসে।
  12. সঠিক প্রযুক্তি ব্যবহার করুন। এগুলি প্রায়শই সেটগুলিতে আসবে এবং তাজা থাকবে: আপনি ভবিষ্যতের যে কাঠামোর সমর্থন নিশ্চিত করেছেন তার বিটা সংস্করণের উপর নির্ভর করে চলা স্থির, তবে অপ্রচলিত ফ্রেমওয়ার্কগুলির উপর নির্ভর করে না, যা অসমর্থিত।
  13. সেরা মানুষ ভাড়া।
  14. বিশ্রাম বন্ধ - আপনি একটি কফি শপ চালাচ্ছেন না।
  15. যদি ম্যানেজমেন্ট সেরা স্থপতি না হয় এবং তারা সিদ্ধান্ত গ্রহণের প্রক্রিয়ায় হস্তক্ষেপ করে - অন্য একটি কাজ সন্ধান করুন।

1
এখন, 'অতিরিক্ত সময়' তে সি # রি-রাইটিংয়ে কাজ করার সময় আপনার যদি 100 বছরের ফর্ম এবং ক্লাসের সাথে 12 বছরের পুরানো ভিবি 6 অ্যাপটি বজায় রাখতে এবং বাড়িয়ে দিতে হয় তবে আপনি কী করবেন?
jfrankcarr

7
# 3 এর সাথে দ্বিমত পোষণ করুন। প্রশিক্ষণ প্রশিক্ষণহীনদের শাস্তি হিসাবে দেখা উচিত নয়। আসলে এটি সমস্ত দেব দ্বারা করা উচিত, এবং কোডিং এবং ডিজাইনিংয়ের মতো সমান গুরুত্বপূর্ণ হিসাবে গণ্য করা উচিত! আপনার যদি মিঃ দলে প্রশিক্ষণ নেই, তবে তাকে কিছুটা প্রশিক্ষণের জন্য দল থেকে নামিয়ে দিন!
NWS

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

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

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

12

ইউনিট পরীক্ষা লেখার সময়, রিফ্যাক্টরিং দ্বারা পচা কোড পরিষ্কার করুন। আপনি যখনই স্পর্শ করবেন না এমন সমস্ত কোডে (এই) ডিজাইন debtণ পরিশোধ করুন:

  • একটি নতুন বৈশিষ্ট্য বিকাশ করুন
  • একটি সমস্যা ঠিক করুন

আপনার পরীক্ষার প্রথম বিকাশের চক্রকে দুর্দান্তভাবে গতি দিন:

  • কোড মডিউলগুলিকে স্ক্রিপ্টিং ভাষায় রূপান্তর করতে রিফ্যাক্টরিং
  • দ্রুত, ক্লাউড-ভিত্তিক পরীক্ষা মেশিন ব্যবহার করুন

কম সংযুক্তিকে ব্যবহারের জন্য রিফ্যাক্টর কোড (অত্যন্ত অভ্যন্তরীণভাবে সমন্বিত ইউনিটগুলির দ্বারা):

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

জৈব বৃদ্ধি ভাল; বড় আপ-ফ্রন্ট ডিজাইন খারাপ।

এমন একজন নেতা আছেন যিনি বর্তমান নকশা সম্পর্কে জ্ঞানবান। যদি তা না হয় তবে আপনি যতক্ষণ না বুদ্ধিমান হন ততক্ষণ প্রকল্পের কোডটি পড়ুন।

রিফ্যাক্টরিং বই পড়ুন।


1
+1 ভাল প্রথম উত্তর, আমাদের সাথে নিজেকে পরিচয় করানোর নিখুঁত উপায়!
ইয়ানিস

11

সহজ উত্তর: আপনি পারবেন না

এজন্য আপনার ছোট এবং সাধারণ সফ্টওয়্যার লেখার লক্ষ্য করা উচিত । এটা সহজ না.

এটি কেবল তখনই সম্ভব যদি আপনি আপনার আপাতদৃষ্টিতে জটিল সমস্যাটিকে যতটা সম্ভব সহজ এবং সংক্ষিপ্তভাবে সংজ্ঞায়িত করতে যথেষ্ট দীর্ঘস্থায়ী চিন্তা করেন।

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

অন্য কথায়, অন্যরা যেমন উল্লেখ করেছে, সরলতা এবং আলগা মিলন হ'ল মূল উপাদান।

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


9

আমি এমন একটি পণ্যের কোড-বেসে কাজ করি যা ১৯৯৯ সাল থেকে ধারাবাহিক বিকাশে চলেছে, সুতরাং আপনি কল্পনা করতে পারেন যে এটি এতক্ষণে জটিল। আমাদের কোডবেস মধ্যে hackiness সবচেয়ে বড় উৎস অসংখ্য বার আমরা থেকে এটা পোর্টের ছিল থেকে এএসপি ক্লাসিক থেকে ASP.NET , ADO থেকে ADO.NET করতে এখানে postbacks থেকে আয়াক্স , UI 'তে লাইব্রেরি, কোডিং মান, ইত্যাদি সুইচিং

সব মিলিয়ে আমরা কোড বেসটি বজায় রাখার একটি যুক্তিসঙ্গত কাজ করেছি। আমরা যে প্রধান বিষয়গুলি অবদান রেখেছি তা হ'ল:

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

2) একটি ঝরঝরে বিকাশের পরিবেশ রাখুন - কোডটি আর ব্যবহার করা হয় না তা মুছে ফেলার বিষয়ে সজাগ থাকুন এবং প্রজেক্ট ডিরেক্টরিতে ব্যাকআপ কপি / ওয়ার্কিং কপি / পরীক্ষামূলক কোড উপস্থিত থাকবেন না।

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


8

যেহেতু আপনি প্রশ্নটি প্রকল্প পরিচালনার সাথে ট্যাগ করেছেন, তাই আমি কিছু নন-কোড পয়েন্ট যুক্ত করার চেষ্টা করেছি :)

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

  • ধারাবাহিকতা / অভিন্নতা যথেষ্ট চাপ দেওয়া যাবে না। এটি 'একে একে যান' সংস্কৃতিটিকে নিরুৎসাহিত করবে এবং নতুন বিকাশকারীদের যদি সন্দেহ হয় তবে জিজ্ঞাসা করতে উত্সাহিত করবে।

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

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

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

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


7

অত্যন্ত বর্ধিত কোডের একটি বৈশিষ্ট্য হ'ল ফাংশন বিশুদ্ধতা

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

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

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

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

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


2
আপনি যা বর্ণনা করছেন তার আর একটি নাম
হ'ল বিবাদী

6

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

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

আরেকটি পদ্ধতি হ'ল প্রত্যেককে কমপ্লেক্স.আইআরসি এবং ডেইলি ডাব্লুটিএফ পড়তে হবে যাতে তারা খারাপ ডিজাইন এবং খারাপ প্রোগ্রামিংয়ের পরিণতিগুলি শিখতে পারে এবং ডেইলি ডাব্লুটিএফ- তে পোস্ট করা নিজস্ব কোড দেখে তারা ভয় পাবে ।


6

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

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

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

তবে, আপনার যদি একটি কঠোর সময়সীমা থাকে, তবে আমি মনে করি যে আরও একটি ভাল বিষয় মনে রাখা উচিত:

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

এবং আমার ব্যক্তিগত পছন্দের টিপটি উদ্ধৃতিটির আরও বেশি, যদিও আমি উত্সটি মনে করতে পারি না:

"কোডটি যেন আপনার পরে আসে এমন ব্যক্তি হ'ল হোমসিডাল সাইকোপ্যাথ যা জানে আপনি কোথায় থাকেন"


সিন্ট্যাক্স হাইলাইটিং ব্যবহার করে ফাংশন এবং শ্রেণি অবস্থানগুলিতে কেবল কোড বিভাগগুলির বিভাজন সরবরাহ করা সত্ত্বেও আমি সর্বদা ফাংশন এবং শ্রেণি মন্তব্যগুলি সহায়ক বলে মনে করি। আমি খুব কমই ফাংশন কোডগুলিতে মন্তব্যগুলি রাখি, তবে আমি প্রতিটি শ্রেণি এবং ফাংশনের জন্য একটি লাইন লিখি, যেমন /** Gets the available times of a clinic practitioner on a specific date. **/বা /** Represents a clinic practitioner. **/
নিক বেডফোর্ড

5

একটি নীতি যা উল্লেখ করা হয়নি তবে আমি গুরুত্বপূর্ণ মনে করি তা হল খোলা / বদ্ধ নীতি

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

শুধু আমার 2 সেন্ট।


ব্যবসায়ের প্রয়োজনীয়তা যদি ওয়ার্কিং কোড পরিবর্তনে প্রকাশিত হয়? দুর্বল ফ্যাক্টরযুক্ত তবে প্রযুক্তিগতভাবে 'ওয়ার্কিং' কোডটি আপনাকে দীর্ঘমেয়াদে আঘাত করতে পারে, বিশেষত যখন প্রয়োজনীয় পরিবর্তনগুলি করার সময় আসে তখন।
জিঙ্গলেস্তুলা

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

5
  • একটি স্কাউট হতে । কোডটি যতটা খুঁজে পেয়েছে তার চেয়ে সর্বদা ছেড়ে দিন।

  • ভাঙা উইন্ডোজ ঠিক করুন । আপনি যখন 3.0 সংস্করণে থাকবেন তখন এই সমস্ত মন্তব্য "সংস্করণ 2.0 তে পরিবর্তন" হয়।

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

  • কোন অনুমানগুলি আর সত্য নয় যা নকশাকে একটি নির্দিষ্ট দিকে ঠেলে দেয়? সেই গণ্ডগোলের কিছু পিছনে একটি ছোট রিফ্যাক্টরিং লুকিয়ে থাকতে পারে।

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

  • সতর্কবাণীগুলি সরানোর জন্য একটি দল হিসাবে এক সপ্তাহ ব্যয় করুন যাতে আসল সমস্যাগুলি দৃশ্যমান হয়।

  • কোডিং মান হিসাবে সমস্ত কোড পুনরায় ফর্ম্যাট করুন।

  • আপনার বাগ ট্র্যাকারের সাথে আপনার সংস্করণ নিয়ন্ত্রণ ব্যবস্থা আবদ্ধ রয়েছে তা নিশ্চিত করুন । এর অর্থ ভবিষ্যতের পরিবর্তনগুলি দুর্দান্ত এবং দায়বদ্ধ এবং আপনি কেন কাজ করতে পারেন।

  • কিছু প্রত্নতত্ত্ব করুন। মূল নকশার নথিগুলি সন্ধান করুন এবং সেগুলি পর্যালোচনা করুন। তারা অফিসের কোনায়, পরিত্যক্ত অফিসের জায়গাতে বা ফাইলিং মন্ত্রিপরিষদে কোনও পুরানো পিসিতে থাকতে পারে না ever

  • ডিজাইনের নথিগুলি একটি উইকে পুনরায় প্রকাশ করুন। এটি জ্ঞানের প্রাতিষ্ঠানিককরণে সহায়তা করে।

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

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

  • যদি আপনার দলের নেতৃত্ব এই জিনিসগুলি না করে, তবে এটি কোম্পানির পক্ষে খারাপ।

  • সমস্ত নতুন কোড পরিমাপিত কভারেজ সহ সঠিক ইউনিট পরীক্ষা দেয় তা নিশ্চিত করার চেষ্টা করুন। সুতরাং সমস্যাটি আরও খারাপ হতে পারে না।

  • পুরানো বিটগুলির কয়েকটি পরীক্ষা করার চেষ্টা করুন যা ইউনিট পরীক্ষিত নয়। এটি পরিবর্তনের ভয়কে হ্রাস করতে সহায়তা করে।

  • আপনি যদি পারেন তবে আপনার ইন্টিগ্রেশন এবং রিগ্রেশন টেস্টটি স্বয়ংক্রিয় করুন। কমপক্ষে একটি চেকলিস্ট আছে। পাইলটগুলি স্মার্ট এবং তারা প্রচুর অর্থ প্রদান করে এবং তারা চেকলিস্ট ব্যবহার করে। তারা খুব কমই স্ক্রু আপ।


4

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


3

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

এই প্রভাবকে সীমাবদ্ধ করার উপায় হ'ল একটি ভাল নকশা দিয়ে শুরু করা যেখানে এটি প্রসারণ পরিচালনা করতে যথেষ্ট নমনীয়। ইতিমধ্যে এ বিষয়ে বেশ কয়েকটি পরামর্শ দেওয়া হয়েছে।

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


2

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

দীর্ঘ সময় ধরে চলমান প্রকল্প বজায় রাখা যেমন পৃথক বিকাশকারী হিসাবে প্রকল্প পরিচালকের ততটুকু দায়িত্ব।

লোকেরা হ্যাকগুলি পরিচয় করে না কারণ তারা এটি পছন্দ করে; তারা পরিস্থিতিতে বাধ্য হয়।


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

2

আমি কেবল একটি অ-প্রযুক্তিগত সমস্যা এবং একটি (সম্ভবত) ব্যবহারিক পদ্ধতির রাখতে চাই।

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

আপনি যদি সেই বইগুলিতে কোড মানের খুঁজে পাওয়া স্বপ্ন দেখে থাকেন তবে আপনার এই বিষয়ে উদ্বিগ্ন একজন বসেরও দরকার।

অথবা আপনি যদি কেবল "ফ্রাঙ্কেনস্টাইন প্রকল্প" কে নিয়ন্ত্রণ করতে চান তবে এগুলি আমার টিপস:

  • সংগঠিত করুন এবং সরল করুন
  • সংক্ষিপ্ত ফাংশন
  • দক্ষতার তুলনায় পাঠযোগ্যতার পক্ষে অগ্রাধিকার দিন (অবশ্যই গ্রহণযোগ্য এবং কিছু দক্ষতা লাভ খুব খারাপভাবে রাখা যায় না)

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

বৈশিষ্ট্য প্রয়োগ এবং বাগ ফিক্সের বাইরেও কোড সাফ করার জন্য আপনার সময় দিন।


"... প্রকল্পটি ধ্বংসপ্রাপ্ত" - আমার অভিজ্ঞতায় এটি অগত্যা নয়। বিকল্প বললেন ম্যানেজার শিক্ষিত এবং "বিনিয়োগ" করার মধ্যে প্রচেষ্টা সন্তুষ্ট হয় maintainability এবং অ্যাড্রেসিং প্রযুক্তিগত-ঋণ
মশা

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

1

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

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

এমনকি আপনি অনেকগুলি প্রকল্পের মধ্যে এই ছোট, স্বতন্ত্র গ্রন্থাগারগুলি ভাগ করে নেওয়া বিবেচনা করতে পারেন (গিট সাবমডিউলগুলি আপনার বন্ধু) are

বলা বাহুল্য, প্রতিটি ছোট, স্বতন্ত্র গ্রন্থাগার ইউনিট-পরীক্ষা করা উচিত। যদি কোনও নির্দিষ্ট গ্রন্থাগার ইউনিট-টেস্টযোগ্য না হয় তবে আপনি কিছু ভুল করছেন।

আপনি যদি সি বা সি ++ ব্যবহার করেন এবং অনেকগুলি ছোট .so ফাইল থাকার ধারণাকে অপছন্দ করেন তবে আপনি সমস্ত লাইব্রেরিগুলিকে একত্রে একটি বৃহত্তর .so ফাইলে লিঙ্ক করতে পারেন, অথবা বিকল্পভাবে আপনি স্থির লিঙ্কিং করতে পারেন। জাভা ক্ষেত্রেও এটি একই, কেবলমাত্র .ar তে পরিবর্তন করুন।


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

0

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

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

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

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

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