একটি নতুন প্রকল্পে পরিকল্পনা এবং প্রোগ্রামিংয়ের সঠিক মিশ্রণ


10

আমি একটি নতুন প্রকল্প শুরু করতে চলেছি (একটি খেলা, তবে তা গুরুত্বহীন)। প্রাথমিক ধারণাটি আমার মাথায় তবে সমস্ত বিবরণ নেই।

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

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

আপডেট : "ক্লিক ডামি" দিয়ে আর কার্যকারিতা বাস্তবায়নের বিষয়ে কীভাবে?

উত্তর:


5

আপনি সঠিক পথে আছেন কয়েক মাস পরিকল্পনার ব্যয় করার দরকার নেই, তবে আপনার অবশ্যই একরকম পরিকল্পনা করা উচিত।

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

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


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

আপনি "পরিকল্পনা" বানান ভুল রাখেন। আমি ভেবেছি যে আমি এটি উল্লেখ করব যেহেতু আমি আপনার মন্তব্য সম্পাদনা করতে পারি না :) তবে হ্যাঁ, আমি মনে করি যে স্ক্রাম একটি দুর্দান্ত পদ্ধতির এটি নমনীয়তা বজায় রেখেছে এবং আপনাকে প্রকল্পটি চালিয়ে যাওয়ার প্রচেষ্টাটি এমনকি মূল্যবান কিনা তা সিদ্ধান্ত নেওয়ার সুযোগ দেয়।
jmort253

ওও জার্মান ভাষায় এটি অন্যভাবে: এক এন নিয়ে পরিকল্পনা এবং দুটি মি নিয়ে প্রোগ্রামিং ...: ডি ধন্যবাদ!
ওয়ারেনফেইথ

@ ওয়ারেনফেইথ - দুঃখিত! এটাই আমার নৃতাত্ত্বিক উত্স প্রকাশিত! আমার ভুল চিহ্নিত করার জন্য ধন্যবাদ;)
jmort253

11

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


3
.... এবং প্রতিবার আপনার এমন কোনও ধারণার জন্য যা আপনার মনে হয় যে শীতল হতে পারে কেবল সেই ধারণাটি স্ক্রাম-ব্যাকলগে লিখুন তবে ন্যূনতম টেকসই পণ্য সম্পন্ন না হওয়া পর্যন্ত বাস্তবায়ন করবেন না।
k3b 10

আমার এখনও কতটা গভীর পরিকল্পনা করা উচিত তা মূল প্রশ্ন। আপনি যদি আমাকে সেই পরামর্শটি দিতে পারেন তবে আপনি উত্তরটি গ্রহণ করেছেন।
ওয়ারেনফেইথ

1
@ ওয়ারেনফেইথ: বৈশিষ্ট্য - >> গল্প - >> পরীক্ষার কেস।
স্টিভেন এ লো।

4

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

একজনকে বুঝতে হবে যে রিফ্যাক্টরিং উন্নয়নের একটি সাধারণ অঙ্গ এবং এটি কখন করা উচিত তা সিদ্ধান্ত নেওয়ার বিষয় । দীর্ঘক্ষণ অপেক্ষা করুন এবং সম্পূর্ণ পুনর্লিখনের জন্য ভিক্ষা করে আপনি বিপুল পরিমাণ স্প্যাগেটি দিয়ে শেষ করুন। মজার না.

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


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

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

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

@ ওয়ারেনফেইথ: যতক্ষণ কোডটি শক্ত এবং আকারে থাকে ততক্ষণ আপনার পুনর্লিখনগুলি এড়াতে সক্ষম হওয়া উচিত। কেবলমাত্র যখনই আমি পুনর্লিখনগুলি দেখেছি তখনই যখন সিস্টেমটি কাদা একটি বড় বল (কোন রিফ্যাক্টরিং) বা মৌলিক প্রযুক্তিগত পরিবর্তন (প্ল্যাটফর্মের পরিবর্তন) হয়ে যায়।
মার্টিন উইকম্যান

3

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

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

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

আরও সংক্ষিপ্তভাবে সংক্ষিপ্তসার হিসাবে, কেউ বলতে পারেন "সিউডো কোড এবং / অথবা টিডিডি পরিকল্পনা সহ" সবচেয়ে শক্ত অংশটি প্রথমে মোকাবেলা করুন, ভাগ করুন এবং বিজয় করুন "!


আমি টিডিডির ভক্ত নই তবে যাইহোক ধন্যবাদ!
ওয়ারেনফেইথ

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

3

শুধু কোডটি মডুলার করার চেষ্টা করুন। আপনার পরিকল্পনা করা অন্য যে কোনও কিছুই পরবর্তী পুনরাবৃত্তির সময় ফেলে দেওয়া হতে পারে।


2

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

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