আর্কিটেকচারের নকশা করা সময় নষ্ট করা কীভাবে বন্ধ করবেন [বন্ধ]

Question

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

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

আমি কীভাবে আমার প্রোগ্রাম এবং সিস্টেমগুলিকে "স্থপতি" করব তা স্থির করার চেষ্টা করে ঘন্টা এবং ঘন্টা ব্যয় করি। উদাহরণস্বরূপ - আমি কি এই যুক্তিটিকে 1 বা 2 শ্রেণিতে বিভক্ত করি, আমি কীভাবে ক্লাসের নাম রাখি, আমি কি এই ব্যক্তিগত বা জনসাধারণকে তৈরি করব, ইত্যাদি These এই ধরণের প্রশ্নগুলি আমার অনেক সময় নেয় এবং এটি আমাকে ব্যাপকভাবে হতাশ করে। আমি কেবল প্রোগ্রামটি তৈরি করতে চাই - আর্কিটেকচারকে জঘন্য করা হবে।

আমি কীভাবে আর্কিটেকচার পর্বের মধ্য দিয়ে আরও দ্রুত এবং কোডিং এবং ডিবাগিং ধাপটি উপভোগ করতে পারি?

Comments

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

— জারেড স্মিথ

আর্কিটেকটিং হ'ল আপনার পরিকল্পনার পর্ব - এটিকে সঠিক করুন এবং এটি আপনার 90% প্রয়াসের বাকি অংশটি কোডিং, ডিবাগিং এবং ব্যবহারকারী গ্রহণযোগ্যতা সহ being এড়িয়ে যাওয়া বা তাড়াহুড়ো করা বাঞ্ছনীয় নয় , যেহেতু আপনি অভাবনীয়, অবর্ণনীয় সমাধান দিয়ে শেষ করতে পারেন, তাই যদি আপনি এটি করতে পছন্দ না করেন তবে আপনার পক্ষে সম্ভবত এটি অন্য কারওর করা দরকার ... নামকরণ এর মধ্যে অন্যতম কঠিন সমস্যা is সফ্টওয়্যার বিকাশ, একটি বিকাশকারী একটি 5 লাইন পদ্ধতির নামের উপর দিন ধরে বেদনাদায়ক করতে পারে। অন্য কিছু হওয়ার দরকার না হওয়া পর্যন্ত সবকিছুকে ব্যক্তিগত করুন private তারা যখন একাধিক কাজ করে তখন ক্লাসগুলি বিভক্ত করুন।

— মু

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

— njzk2

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

— বেসিল স্টারিনকিভিচ

"সপ্তাহের কোডিং আপনার পরিকল্পনার কয়েক ঘন্টা বাঁচাতে পারে।"

— মিকিফ

Answer 1

নিখুঁত হ'ল শত্রু।

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

তবে আপনারও নিখুঁততার বিষয়ে চিন্তা করা উচিত নয়। দুটি ডিজাইন যদি অচলাবস্থার সাথে লড়াই করে তবে এর অর্থ তারা সম্ভবত একই ধার্মিকতার বিষয়ে। শুধু একটি সঙ্গে যান। এটি এমন নয় যে একবার আপনি সেই ডিজাইনের ত্রুটিগুলি সনাক্ত করে জিনিসগুলি পরিবর্তন করতে পারবেন না।

(এবং আশা করি এটি প্রযুক্তিগত সমস্যাগুলি ডিবাগ করার / সমাধান করার জন্য কেবল একটি উপায় নেই বলে আপনি জানতে পেরে একবারে এটিও সহায়তা করবে))

Comments

বিশ্লেষণ দ্বারা পক্ষাঘাতও মনে আসে।

— মাইক 65535

কখনও কখনও ডিজাইনের সিদ্ধান্তের জন্য নিখুঁত চূড়ান্ত সালিসি এক চতুর্থাংশ হয়।

— candied_orange

ইয়াগনি এবং কেআইএসএস এবং জিটিএফও;)

— জলি জোকার

এই উত্তরটি যে কারও কাছে পড়ছেন - godশ্বরের প্রতি ভালবাসার জন্য অভাবজনক বাস্তবায়নকে ন্যায়সঙ্গত করতে "পারফেক্টটি হ'ল শত্রু" ব্যবহার করবেন না। এই উক্তিটির উদ্দেশ্যটি হ'ল আপনাকে অতিমাত্রায় রোধ করা থেকে বিরত রাখা, উইন্ডোজ ভিস্তা বা অ্যাপল III এর মতো কিছুটা বাজে নকশা তৈরি করা বন্ধ না করা।

— টি। সর - মনিকা

@ টি.সর: ভিস্তার ব্যর্থতা কার্যত 0% প্রযুক্তিগত ব্যর্থতা এবং প্রায় 100% এমবিএ ব্যর্থতা ছিল।

— name

Answer 2

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

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

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

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

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

আমি কীভাবে আর্কিটেকচার পর্যায়ে এবং কোডিং এবং ডিবাগিং পর্বে যাচ্ছি যা আমি উপভোগ করতে পারব কীভাবে?

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

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

আমি কেবল প্রোগ্রামটি তৈরি করতে চাই, আর্কিটেকচারটি বাঁধ দেওয়া হবে।

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

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

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

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

Comments

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

— নীল

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

— কাফেইন

আমার দাবিটি হ'ল প্রতিটি বড় পর্যাপ্ত কোড বেসটি জৈবিকভাবে বৃদ্ধি পায় ( গলের আইন দেখুন ...)। এছাড়াও,

— কোনও নবাগতকে

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

— কেভিন ২

Answer 3

আমি মনে রাখতে চাই তিনটি মটো আছে।

• "সবকিছুই সম্ভব হিসাবে সহজ হওয়া উচিত, তবে সহজ নয়"

  আপনার "একটি শ্রেণি বা দুটি?" উদাহরণটি ধরতে আমি জিজ্ঞাসা করব, "এর সহজ সমাধানটি কোনটি?"

• "স্পষ্টত কোনও বাগ নেই" বনাম "অবশ্যই কোনও বাগ নেই"

  পরেরটি বেশি পছন্দনীয়!

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

  1. কোডটি তত্ত্বের সাথে চালানো উচিত (অর্থাত্ আপনার মাথায়)।
  2. তারপরে যদি এটি অনুশীলনে কাজ না করে আপনি অনুশীলনটি তত্ত্বের সাথে মিল না পাওয়া পর্যন্ত আপনি এটি ডিবাগ করতে পারেন।

  একজন নবজাতক কখনও কখনও 1 ম পদক্ষেপ নিয়ে বিরক্ত করেন না, যেমন এটি আপনার মাথায় চালানো (উদাহরণস্বরূপ এটি খুব জটিল) - তবে সেক্ষেত্রে এটি "তত্ত্বের পরিবর্তে" কেবল "দুর্ঘটনায়" চলছে, সম্ভবত আপনি সম্ভবত " অ-সুস্পষ্ট বাগগুলি খুঁজে পাওয়ার জন্য এটি যথেষ্ট পরীক্ষা করেছে।

• গল এর আইন

  এটি ওরফে "রিফ্যাক্টর"।

  অনুশীলনে এর অর্থ:

  1. কাজ করে এমন একটি [এনওয়াই] সহজ সিস্টেম দিয়ে শুরু করুন
  2. এখন সময় এসেছে একটি নতুন বৈশিষ্ট্য যুক্ত করার
  3. বিদ্যমান সিস্টেমটি রিফ্যাক্টর করুন যাতে (যেমন পর্যন্ত) নতুন বৈশিষ্ট্য যুক্ত করা সহজ

  4. নতুন বৈশিষ্ট্য যুক্ত করুন

  5. ... এবং উপরে হিসাবে পুনরাবৃত্তি

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

Answer 4

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

তবে আপনার সিস্টেমে "ন্যূনতম সংখ্যার ন্যূনতম সংখ্যার" দেখতে কেমন তা ভেবে কিছুটা সময় নেওয়া সর্বদা ভাল। একটি ভাল যথেষ্ট স্থাপত্য থেকে শুরু করুন এবং আপনি যেতে হিসাবে এটি উন্নত।

সম্পাদনা করুন: @ বেসিল উত্তরটি কীভাবে আপনার নূন্যতম আর্কিটেকচারে পুনরাবৃত্তি করতে এবং উন্নত করতে পারে তার একটি উদাহরণ দেয়।

Comments

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

— যুদ্ধ

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

— নীল

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

— sul4bh

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

— যুদ্ধ

@ ব্যাটল: আগে "কাঠামোগত ক্ষেত্রে" কাঠামো যুক্ত করা যা সহজেই অতিরিক্ত কাজ পরিচালনার দিকে পরিচালিত করে। আমার অভিজ্ঞতা অনুসারে, কোড বেসের বর্তমান আকারের জন্য প্রয়োজনীয় সর্বদা বিস্তৃতিগুলির সংখ্যা থাকা সত্যিই একটি ভাল লক্ষ্য - কম নয়, আর নেই the কোড বেসটি বাড়ানোর আগে বিমূর্ততা যুক্ত করা উচিত, এটি আগে নয় That আমি এই উত্তরটি কীভাবে পড়লাম।কিন্তু "বিমূর্ততার ন্যূনতম সংখ্যা" শব্দের ভুল ব্যাখ্যা করা যেতে পারে

— ডক ব্রাউন

Answer 5

কোনও সিস্টেমের আর্কিটেকচারের কথা চিন্তা করে সময় নষ্ট হয় না।

আমি বিশ্বাস করি আপনার প্রশ্নটির পুনঃব্যবস্থা করা যেতে পারে "" কীভাবে আমি স্থাপত্য সংক্রান্ত সিদ্ধান্ত নেওয়ার সাথে আরও দক্ষ হতে পারি? "

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

-

আর দীর্ঘ উত্তরের জন্য ...

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

আমি মনে করি এই বিষয়টি আলোচনা করার সময় মনে রাখা 3 টি গুরুত্বপূর্ণ বিষয় রয়েছে:

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

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

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

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

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

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

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

একক দায়িত্বের নীতি : একটি শ্রেণীর কেবলমাত্র একক দায়িত্ব থাকতে হবে (অর্থাত্ কেবল সফ্টওয়্যারটির নির্দিষ্টকরণের একটি অংশে পরিবর্তন হওয়া উচিত শ্রেণীর স্পেসিফিকেশনকে প্রভাবিত করতে সক্ষম)।

উন্মুক্ত / বদ্ধ নীতি : "সফ্টওয়্যার সত্তা… এক্সটেনশনের জন্য উন্মুক্ত হওয়া উচিত, তবে পরিবর্তনের জন্য বন্ধ করা উচিত।"

• উত্তরাধিকার ওভার রচনা ধারণা

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

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

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

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

Comments

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

— TKK

Answer 6

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

যেখানে প্রকল্পের আগে আর্কিটেকচারের প্রয়োজনীয়তা রয়েছে:

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

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

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

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

Answer 7

আমি আপনাকে শর্তাবলী এবং সংক্ষিপ্তসারগুলির একটি গোছা ফেলতে যাচ্ছি না (যার মধ্যে বেশিরভাগ কোডার / সফ্টওয়্যার ইঞ্জিনিয়াররা খুব কমই সম্মত হন)। পরিবর্তে, নিম্নলিখিত বিবেচনা করুন:

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

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

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

4. আমি যুক্তি দিয়ে বলব যে বিল্ডিং সফটওয়্যারটি ইঞ্জিনিয়ারিংয়ের চেয়ে আর্ট / ক্রাফ্ট। দুর্দান্ত শিল্পটি কেবল ব্যক্তি ব্রাশস্ট্রোক সম্পর্কে নয়, বরং শিল্পী / কারিগর দ্বারা তৈরি উচ্চ-স্তরের সিদ্ধান্ত এবং ট্রেড অফ সম্পর্কে।

Answer 8

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

আর্কিটেকচার আপনার কোডের জন্য দুটি জিনিস করে:

1. এটি আপনার এবং অন্যদের জন্য আপনার কোডটি বোঝা সহজ করে তোলে।
2. এটি আপনার কোডটিকে এমনভাবে গঠনে সহায়তা করে যা এটির প্রসার এবং সংহতকরণকে আরও সহজ করে।

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

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

এখন আপনি যে অংশটির জন্য প্রকৃত পক্ষে এখানে রয়েছেন:

আর্কিটেকচার অংশের মাধ্যমে আপনি কী কী আরও দ্রুত পেতে পারেন:

1. এটা করবেন না

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

উপায়টি অতিক্রম করার সাথে, আপনি আর্কিটেকচারকে কম বেদনাদায়ক করতে কী করতে পারেন:

1. তাড়াতাড়ি কর
2. চুরি করা
3. শিখুন / এটি আঁকড়ে থাকুন
4. এটি অতিরিক্ত না

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

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

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

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

(পিএস: এই শেষ বাক্যটি অলস হওয়ার কোনও অজুহাত নয় working ওয়ার্কিং সফ্টওয়্যারটিকে প্রাধান্য দেওয়ার অর্থ এই নয় যে কোনও দিন আপনাকে ভাল কোডিং শিখতে হবে না))

Answer 9

উত্তর খুব সহজ,

• একটি প্রোটোটাইপ তৈরি করুন (টাইম বক্সড)
• রিফ্যাক্টর (আপনার বিস্তৃত উপাদানের উপর ভিত্তি করে যতটা সময় ব্যয় করতে পারেন)

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

Answer 10

আমি কীভাবে আর্কিটেকচার পর্যায়ে এবং কোডিং এবং ডিবাগিং পর্বে যাচ্ছি যা আমি উপভোগ করতে পারব কীভাবে?

আপনার আরও অভিজ্ঞ সহকর্মীদের কাছে (বা সহায়তা চাইতে) এই কাজটি প্রেরণ দ্বারা।

দ্রুত এই জাতীয় সিদ্ধান্ত নেওয়ার জন্য আপনার প্রয়োজনীয় অভিজ্ঞতার অভাব হয়। ইউনি আপনাকে একটি দুর্দান্ত তাত্ত্বিক পটভূমি পেয়েছে তবে এটি আপনাকে কেবল একটি সূচনা লাইনে পৌঁছে দেয়। অতীতে একইরকম আর্কিটেকচার একইরকম পরিস্থিতিতে কীভাবে আচরণ করেছিল তা জেনেও প্রদত্ত পরিস্থিতিতে কোনও স্থিত স্থাপত্যের বিচার করার উপায় নেই।

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

Comments

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

— জিমি জেমস

@ জিমি জেমস আমি "কাজের ক্ষেত্রে আরও ভাল" হিসাবে পরিবর্তিত হয়েছি। কারণ অভিজ্ঞতা এটির একটি অংশ মাত্র।

— এজেন্ট_এল

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

— জিমি জেমস

Answer 11

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

কীভাবে আর্কিটেকচার ডিজাইনের সময় নষ্ট করা বন্ধ করবেন

এই প্রশ্ন বরং বোঝা হয়। এছাড়াও, আপনি আর্কিটেকচার ডিজাইন করেন না । আপনি স্থপতি । আর্কিটেকচার এবং নকশা পরিপূরক এবং সম্পর্কিত ক্রিয়াকলাপ, তবে তারা একইরকম নয়, এমনকি যদি তারা ওভারল্যাপ করে।

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

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

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

কিন্তু আমার দ্বিমত আছে...

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

এটি কেবলমাত্র বৃহত সিস্টেমে যার জন্য একটি বিশাল সংখ্যক লোক বা সিস্টেম-স্তরের সফ্টওয়্যার জড়িত যা খুব জটিল স্টাফ করে যার জন্য সুস্পষ্ট আর্কিটেকচারের প্রয়োজন হয়।

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

এই পেশার জন্য এটি ন্যূনতম প্রয়োজনীয়, এবং আমি আনন্দিত যে এগুলি করতে আপনার কোনও সমস্যা নেই (আপনি যদি এটি করেন তবে আমি উদ্বিগ্ন হব))

তবে মনে হচ্ছে এমন এক শ্রেণির সমস্যা রয়েছে যার একটির সমাধান নেই

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

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

- সফ্টওয়্যার আর্কিটেকচারের মতো জিনিস।

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

যখন আমরা এই জাতীয় সিস্টেমগুলির জন্য সফ্টওয়্যার তৈরি করি (একটি ব্যাংকিং সিস্টেম, একটি বিদ্যুৎ মনিটরিং সিস্টেম, একটি টিকিট বিক্রয় ব্যবস্থা ইত্যাদি), তখন আমরা লক্ষ্য করি এমন একটি সফ্টওয়্যার তৈরি করা যা এই ধরনের সিস্টেমের কার্যকারিতা এবং প্রয়োজনীয়তার অনুকরণ করে।

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

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

ঠিক আছে। শেখা বা শেখানো এটি সহজ বিষয় নয়, প্রচুর অনুশীলন ছাড়াই নয়।

আমি কীভাবে আমার প্রোগ্রাম এবং সিস্টেমগুলিকে "স্থপতি" করব তা স্থির করার চেষ্টা করে ঘন্টা এবং ঘন্টা ব্যয় করি। উদাহরণস্বরূপ, আমি কি এই যুক্তিটিকে 1 বা 2 শ্রেণিতে বিভক্ত করি, আমি কীভাবে ক্লাসের নাম রাখি, আমি কি এই ব্যক্তিগত বা জনসাধারণকে তৈরি করব, ইত্যাদি These এই ধরণের প্রশ্নগুলি আমার বেশিরভাগ সময় নেয় এবং এটি আমাকে ব্যাপকভাবে হতাশ করে। আমি কেবল প্রোগ্রামটি তৈরি করতে চাই, আর্কিটেকচারটি জঘন্য করা হবে।

দুর্ভাগ্যক্রমে, এটি কোনও সফ্টওয়্যার আর্কিটেকচার নয়।

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

আমি কীভাবে আর্কিটেকচার পর্যায়ে এবং কোডিং এবং ডিবাগিং পর্বে যাচ্ছি যা আমি উপভোগ করতে পারব কীভাবে ?

এর উত্তর দেওয়ার উপায় খুঁজে পেতে আমার খুব কষ্ট হচ্ছে, কারণ এটি বরং সংবেদনশীল।

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

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

আপনি অগ্রগতি করবেন না, আপনি পরিপক্ক বা নতুন জ্ঞান অর্জন করতে পারবেন না।

সেনাবাহিনীতে এই কথা আছে, "স্তন্যপান আলিঙ্গন করুন।"

অন্য বাক্যাংশ একই পরামর্শ আছে। "এটি যদি স্তন্যপান না করে তবে এটির মূল্য হবে না" এবং আমার প্রিয়, "যদি এটি স্তন্যপান করে (এবং এটি গুরুত্বপূর্ণ), এটি স্তন্যপান বন্ধ না করা পর্যন্ত এটি করুন" "

আমার সুপারিশ:

আমার কাছে মনে হচ্ছে আপনি এখনও পার্থক্য বোঝার জন্য সংগ্রাম করছেন

1. কোডিং (কীভাবে আপনার ক্লাসগুলি, মডিউলগুলি কী কোড করবেন না, নামকরণের কনভেনশন, অ্যাক্সেস ভিজিবিলিটি, স্কোপ ইত্যাদি),

2. ডিজাইন (কতগুলি স্তর, সম্মুখ-প্রান্ত / ব্যাক-এন্ড / ডিবি, প্রতিটি কীভাবে যোগাযোগ করে, কোথায় যায়) এবং সহজ সিস্টেমগুলির নকশা থেকে উদ্ভূত আর্কিটেকচারের সিদ্ধান্তগুলি,

3. আর্কিটেকচার (জটিল সিস্টেমে যেমন হাজার হাজার লোকের প্রয়োজন হয়, তবে কয়েক হাজার মানুষ-ঘন্টা নয়))

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

সাফ কোড

রবার্ট "আঙ্কেল বব" মার্টিনের "ক্লিন কোড" শুরু করার জন্য ভাল জায়গা।

সফটওয়্যার সংহতি

অতিরিক্তভাবে, আমি পরামর্শ দিচ্ছি যে আপনি একটি নির্দিষ্ট অবজেক্ট-ওরিয়েন্টড সফটওয়্যার মেট্রিক যার নাম LCOM বা বরং LCOM4 রয়েছে with

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

http://www.aivosto.com/project/help/pm-oo-cohesion.html#LCOM4 https://www.computing.dcu.ie/~renaat/ca421/LCOM.html

সফ্টওয়্যার নীতিমালা

এটি "একক দায়িত্বের নীতি" বা এসআরওয়াইয়ের সাথে ঘনিষ্ঠভাবে সম্পর্কিত যা আমাদের সকলের সাথে পরিচিত হওয়া উচিত। এসআরওয়াই হ'ল 5 "সলিড" এর মধ্যে একটি যা আমাদের কোডিংয়ে দক্ষ হতে গেলে আমাদের সবার সাথে পরিচিত হওয়া দরকার।

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

অতিরিক্ত বই

শেষ অবধি, আমি নিম্নলিখিতগুলিও পরামর্শ দেব:

• মার্টিন ফোলার এবং কেন বেকের "রিফ্যাক্টরিং" হ'ল পরবর্তী বইটি আমি এই তালিকায় পড়েছি।

• রিচার্ড মিচেল, জিম ম্যাককিম এবং বার্ট্র্যান্ড মায়ারের "ডিজাইন বাই কন্ট্রাক্ট, উদাহরণের মাধ্যমে" (আইফেলের খ্যাতির পরে।) এই বইটি মুদ্রণের বাইরে, তবে আপনি অ্যামাজনে সস্তা, ব্যবহৃত কপিগুলি খুঁজে পেতে পারেন।

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

আমি নিশ্চিত যে আরও এমন পেশাদাররা থাকবেন যারা এই পরামর্শগুলিতে যুক্ত, বিয়োগ বা আপত্তি করবেন। তারা সম্ভবত অন্যান্য অভিজ্ঞতার সাথে বৈধতাযুক্ত অন্যান্য পরামর্শ নিয়ে আসবে।

আমি কেবল এটিই বলতে পারি - কোনও শর্টকাট নেই।

শুভকামনা.

Answer 12

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

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

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

Answer 13

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

জিনিস নামকরণের ক্ষেত্রে এটি আমার কাছে "লেখার" অংশ কিন্তু এটি নিঃসন্দেহে প্রোগ্রামিংয়ের একটি খুব গুরুত্বপূর্ণ অঙ্গ: আপনি কীভাবে নাম রাখবেন সে সম্পর্কে কঠোর চিন্তা করতে দ্বিধা বোধ করবেন না, এবং নামটির পরিধি আরও শক্ত করে ভাবেন think

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