একটি সফ্টওয়্যার প্রকল্পের শুরুতে আমি কীভাবে জিনিসগুলি পেতে পারি? [বন্ধ]


64

আমি 1 বছরের অভিজ্ঞতা দিয়ে প্রোগ্রামার, সম্প্রতি আমি বুঝতে পারি আমি খুব কমই সঠিকভাবে একটি প্রকল্প শুরু করি (আমার সাইড প্রজেক্টের বেশিরভাগ), সাধারণত প্রকল্পের চক্রটি এরকম হয়

  1. কয়েকটি ব্যবহারের ক্ষেত্রে শুরু করুন
  2. কোডিং শুরু করুন
  3. কয়েকটি জিনিস বুঝতে পারি যে আমি ভালভাবে পরিচালনা করি নি, এবং বর্তমান কোডবেসে ভাল মানায় না।
  4. কোডের বেশিরভাগ অংশ পুনরায় লিখুন

এবং এটি কয়েক বার যেতে পারে

আমার প্রশ্ন তাই হয়

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

29
পারফেক্ট! এটাকে শেখা বলা হয় :) এবং যোগ্য! = 1 দিনে কার্যকর

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

6
আপনি যদি প্রতিটি প্রকল্প নিখুঁতভাবে শুরু করার জন্য কোনও পদ্ধতি খুঁজে পান তবে আমাদের জানান। অথবা এটি সম্পর্কে একটি বই লিখে কোটিপতি হয়ে যান।
মাস্ট

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

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

উত্তর:


70

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

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

অতএব, সামনের দিকে সবকিছু পরিকল্পনা করা অসম্ভব এবং আপনি যদি পারেনও, সেই পরিকল্পনা অনুসরণ করা আপনাকে অসম্পূর্ণ বা অপ্রচলিত কিছু তৈরি করতে পরিচালিত করবে। এটি জেনে, আমরা আমাদের পরিকল্পনার মধ্যে পরিবর্তনকে সংহত করি। আসুন আপনার পদক্ষেপগুলি দেখুন:

  1. কয়েকটি ব্যবহারের ক্ষেত্রে শুরু করুন
  2. কোডিং শুরু করুন
  3. কয়েকটি জিনিস বুঝতে পারি যে আমি ভালভাবে পরিচালনা করি নি, এবং বর্তমান কোডবেসে ভাল মানায় না।
  4. কোডের বেশিরভাগ অংশ পুনরায় লিখুন

এটি আসলে একটি দুর্দান্ত সূচনা পয়েন্ট। এখানে আমি কীভাবে এর কাছে যাব:

1. কয়েকটি ব্যবহারের ক্ষেত্রে শুরু করুন

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

আমি আপনাকে যে সফ্টওয়্যারটি দিতে পারি তার ক্ষুদ্রতম, সহজতম টুকরা কী যা আপনার পরিস্থিতির উন্নতি করতে পারে?

এটি আপনার ন্যূনতম টেকসই পণ্য - এটির চেয়ে ছোট কিছু আপনার ব্যবহারকারীর পক্ষে সহায়ক নয়, তবে বড় কিছু ঝুঁকিপূর্ণ খুব শীঘ্রই পরিকল্পনা করছেন। এটি তৈরির জন্য পর্যাপ্ত তথ্য পান, তারপরে এগিয়ে যান। সচেতন থাকুন যে আপনি এই মুহুর্তে সমস্ত কিছুই জানেন না।

2. কোডিং শুরু করুন।

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

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

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

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

3. নকশায় সমস্যা বা ত্রুটি মোকাবেলা।

এটা ঘটবে। এটি অনিবার্য। এই গ্রহণ করুন। আপনি যখন এই সমস্যার মধ্যে একটি আঘাত করেন, তবে এটি কোন ধরণের সমস্যা তা স্থির করুন।

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

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

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

৪. কোডটির কিছু অংশ পুনর্লিখন করুন

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

5. পরীক্ষা

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

6. শিখুন

আপনি এই চক্রটি অতিক্রম করার সময়, আপনি যে সমস্যাগুলি খুঁজে পাচ্ছেন এবং যে পরিবর্তনগুলি করছেন তাতে মনোযোগ দিন। নিদর্শন আছে? আপনি উন্নতি করতে পারেন?

কিছু উদাহরণ:

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

চটপটি হন

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

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

5
"দুর্দান্ত। আপনি যত তাড়াতাড়ি সম্ভব কাজ করবেন you've আপনি কোড লেখার আগ পর্যন্ত আপনার ক্লায়েন্টরা শূন্য সুবিধা পেয়েছে planning আপনি যত বেশি সময় পরিকল্পনায় ব্যয় করবেন, ক্লায়েন্টটি আর কোনও ব্যয় ব্যয় না করে অপেক্ষা করতে ব্যয় করবে।" যাই হোক না কেন এটি দিয়ে একমত হতে পারে না। আপনি পরিকল্পনার জন্য যত কম সময় ব্যয় করবেন, ক্লায়েন্ট তত বেশি সময় ব্যয় করতে পারে না এমন কোনও জিনিসের জন্য অপেক্ষা করতে ব্যয় করে যা বাস্তবে সঠিকভাবে কাজ করে।
অরবিটে

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

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

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

3
সমাপ্তিতে, এগিল সম্মত হন যে খুব কম পরিকল্পনা করার মতো জিনিস রয়েছে। এটি কেবলমাত্র পরামর্শ দেয় যে এখানে খুব বেশি কিছু রয়েছে।
anaximander

14

এই স্বাভাবিক.

আপনি দুটি পদ্ধতির একটি গ্রহণ করতে পারেন:

  1. স্বাগতম পরিবর্তন

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

  1. পরিবর্তন এড়ানো

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

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


11

সফ্টওয়্যার বিকাশকে অন্তর্নিহিত "দুষ্ট" সমস্যার একটি সিরিজ হিসাবে বর্ণনা করা হয়েছে

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

এটি আপনার মুখোমুখি সমস্যাটিকে পুরোপুরি বর্ণনা করে। মূলত, আমরা যা করি তা শক্ত । যদি এমন কোনও অংশ থাকে যা "রুটিন" হিসাবে বর্ণনা করা যেতে পারে, সময়ের সাথে সাথে আমরা এটিকে আলাদা করে এবং স্বয়ংক্রিয় করি। সুতরাং যা বাকি রয়েছে তা নতুন বা কঠিন the

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

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

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


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

6

এই ধরনের অনুশীলনগুলি কি সাধারণ, বা এর দ্বারা বোঝা যায় আমি সক্ষম নই?

এগুলি পারস্পরিক একচেটিয়া নয়। প্যাটার্নটি সাধারণ হতে পারে এবং আপনি এখনও অযোগ্য হতে পারেন। আপনার লক্ষ্যগুলির বিরুদ্ধে আপনার কর্মক্ষমতা পরিমাপ করে আপনার দক্ষতা নির্ধারণ করা যেতে পারে। আপনি কি আপনার লক্ষ্য পূরণ করছেন?

এই প্যাটার্নটি কি সাধারণ? দুর্ভাগ্যবশত হ্যাঁ. তারা কী সমস্যা সমাধান করছে, কীভাবে তারা একটি সঠিক সমাধান ইঞ্জিনিয়ার করবে এবং কোন মেট্রিকগুলি সাফল্য অর্জন করবে সে সম্পর্কে স্পষ্ট ধারণা ছাড়াই অনেক লোক প্রকল্পগুলিতে ডুব দেয়।

এই দিকটিতে আমি কীভাবে নিজেকে উন্নত করতে পারি?

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

একবার আপনি এটি করা শুরু করার পরে, বিবেচনা করুন: কোডটি আবার লিখতে হবে না এমন কি এমন দেখতে লাগে ? এই কোড:

  • একটি দরকারী জিনিস না।
  • এটি সঠিকভাবে না।
  • এটি যথেষ্ট পারফরম্যান্স সহ করে।

সুতরাং: আপনি আরও বেশি কোড লিখবেন যেখানে সেই কোডটি একটি কার্যকর কাজ করে সঠিকভাবে, ভাল পারফরম্যান্সের সাথে, আপনাকে কম কোডটি পুনরায় লিখতে হবে।


1

আমি এটি নিরাপদ বলে মনে করি আপনি আরও ভাল কাজের উপায় থেকে দূরে নন এবং আপনি এই নৌকায় একমাত্র নন।

আমার মনে হয় আপনি যা হারিয়েছেন তা হ'ল, আপনি যা চান তা নির্ধারণ করে দিলেও , আপনি কীভাবে এটি করবেন তা করার জন্য আপনি একই প্রক্রিয়া করতে থামবেন না ।

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

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

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


1

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

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

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

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

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

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

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


1

আমি কয়েকটি পয়েন্টার যুক্ত করতে চাই

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

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

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

4) বর্ধিত শিক্ষার এই প্রক্রিয়াটি কখনও থামে না (এবং হওয়া উচিত নয়)! আপনি 10 বছরের মধ্যে ফিরে তাকান এবং হাসি হবে।

আশা করি এটি একটি সামান্য বিট এবং শুভকামার সাহায্য করবে!


"যাই হোক না কেন" পড়া উচিত। উপরের পোস্টটি সম্পাদনা করেছেন।
খ্রিস্টান মাইলার

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