আপনি যে প্রোগ্রামিং অনুশীলনটি একবার পছন্দ করেছিলেন সে সম্পর্কে আপনি নিজের মতামত বদলেছেন? [বন্ধ]

Question 1

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

9 বছর আগে বন্ধ ছিল ।

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

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

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

সম্প্রদায়ের কাছে আমার প্রশ্নগুলি, আত্ম-উন্নতির চেতনায়, হ'ল:

আপনি সম্প্রতি কোন প্রোগ্রামিং প্যাটার্ন বা অনুশীলনগুলি পুনর্বিবেচনা করেছেন এবং এখন এড়ানোর চেষ্টা করছেন?
আপনি কি তাদের প্রতিস্থাপন করার সিদ্ধান্ত নিয়েছে?

Question 2

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Question 3

একক রিটার্ন পয়েন্ট।

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

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

Question 4

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

এক কথায় ওভাররেঞ্জাইনারিং ।

Question 5

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

Question 6

"নিখুঁত" আর্কিটেকচার

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

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

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

Question 7

ক্যাফিন ব্যবহার। এটি একবার আমাকে জাগ্রত এবং এক গৌরবময় প্রোগ্রামিং মুডে রেখেছিল, যেখানে কোডটি আমার আঙ্গুল থেকে জ্বরে তরলতার সাথে উড়ে গেছে। এখন এটি কিছুই করে না, এবং এটি না থাকলে আমার মাথা ব্যথা হয়।

Question 8

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

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

Question 9

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

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

Question 10

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

Question 11

কখনও ক্রাশ হয় না।

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

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

আমার প্রিয় "ক্রাশ করবেন না" প্যাটার্নটি হ'ল:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

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

Question 12

আমি ভেবেছিলাম যখনই আমি সেগুলিকে স্বীকৃতি দিয়েছি তখন ডিজাইনের ধরণগুলি প্রয়োগ করা বুদ্ধিমানের কাজ ।

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

একাধিক (খুব) বিভিন্ন ভাষা ব্যবহার করে আমার চোখ খুলেছে এবং আমাকে বুঝতে পেরেছে যে আমার সমস্যাগুলির ক্ষেত্রে অন্য লোকের সমাধানগুলি আমার ভুলভাবে প্রয়োগ করতে হবে না। রুবির মতো ভাষায় কারখানার প্যাটার্ন প্রয়োগ করা দেখে আমি এখন কাঁপছি ।

Question 13

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

সত্যিই, যেকোন কিছুতে নির্দ্বিধায় মেনে চলা ক্ষতিকর হতে পারে।

Question 14

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

সম্পাদনা করুন: এই সত্তার ব্যতিক্রম অবশ্যই, যখন আমিই সবচেয়ে বেশি যত্নশীল (বা একটি গোষ্ঠীর জন্য স্টাইল সেট করার মতো অবস্থানে থাকি)। সেক্ষেত্রে আমি যা চাই তা করি!

(দ্রষ্টব্য যে এটি কোনও সামঞ্জস্যপূর্ণ শৈলী না থাকার মতো নয় I আমি মনে করি একটি কোডবেসে একটি ধারাবাহিক শৈলী পাঠযোগ্যতার জন্য খুব গুরুত্বপূর্ণ))

Question 15

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

Question 16

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

বাস্তবে, আমি কার্যক্ষমতার অনেকগুলি দুর্বল সংগঠিত বিট সহ সবেমাত্র একটি বিশাল নেমস্পেস তৈরি করেছি।

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

Question 17

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

Question 18

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

কোনও অবজেক্ট কনস্ট্রাক্টরের ভিতরে কোনও ব্যবসার যুক্তি সম্পাদন করা। উত্তরাধিকার এবং ওভারলোডেড কনস্ট্রাক্টর তৈরির সক্ষমতা সহ রক্ষণাবেক্ষণকে কঠিন করে তোলে।

Question 19

পরিবর্তনশীল / পদ্ধতি / টেবিল / নামগুলি সংক্ষেপিত করা হচ্ছে

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

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

Question 20

সহায়ক পদ্ধতির একটি কাস্টম স্তর সহ এন্টারপ্রাইজ লাইব্রেরির মতো বিদ্যমান ডেটা অ্যাক্সেস উপাদানগুলিকে মোড়ানো।

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

Question 21

১৯৮৪ সালে স্মলটালকের বিষয়ে পড়ার সময় আমি প্রথম অবজেক্ট-ওরিয়েন্টেড প্রোগ্রামিংয়ের কথা শুনেছিলাম, তবে 1992 সালে সিফ্রন্ট সি ++ সংকলক ব্যবহার না করা পর্যন্ত আমার কোনও ভাষা অ্যাক্সেস ছিল না। অবশেষে ১৯৯৯ সালে আমি স্মলটালক ব্যবহার করতে শুরু করি। আমি অধীর আগ্রহে প্রত্যাশিত ছিলাম প্রযুক্তি, এবং এটি সফ্টওয়্যার বিকাশ সংরক্ষণ করতে পারে যে ধারণা কেনা।

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

আমি সময় পেলেই ক্লোজুরে কিছু কাজ করতে আগ্রহী, যা খুব সুবিধা দেয় না, যদিও এটি সঠিকভাবে বুঝতে পারলে এটি জাভা অবজেক্ট ব্যবহার করতে পারে। আমি oo মারা গেছে এমন কিছু বলতে প্রস্তুত নই, তবে ব্যক্তিগতভাবে আমি আগে যে ফ্যান ছিলাম তা নয়।

Question 22

সি # তে, _notationব্যক্তিগত সদস্যদের জন্য ব্যবহার করা। আমি এখন এটি কুরুচিপূর্ণ মনে করি।

আমি তখন this.notationব্যক্তিগত সদস্যদের জন্য পরিবর্তিত হয়েছি , কিন্তু আমি এটি ব্যবহারে বেমানান ছিলাম, তাই আমি এটিও বাদ দিয়েছি।

Question 23

আমি বাস্তবায়নের আগে ডিজাইনের প্রস্তাবিত পদ্ধতির দ্বারা বিশ্ববিদ্যালয়ের কাছে যাওয়া বন্ধ করে দিয়েছি। বিশৃঙ্খলাবদ্ধ এবং জটিল পদ্ধতিতে কাজ করা আমাকে মনোভাব পরিবর্তন করতে বাধ্য করেছে।

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

কোডটি আপনি প্রথমে এর মতো দেখতে ভেবেছিলেন এমন সমস্ত কিছু দেখবে না। প্রতিবার ঘটে :)

Question 24

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

Question 25

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

Question 26

চেক করা ব্যতিক্রম

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

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

Question 27

সার্থক যে কোনও কিছুই কেবল একটি নির্দিষ্ট ভাষায় কোড করা হয়েছিল। আমার ক্ষেত্রে আমি বিশ্বাস করি যে সি হ'ল সর্বকালের সেরা ভাষা এবং আমার অন্য কোনও ভাষায় কোনও কোড করার কোনও কারণ নেই ... সর্বদা।

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

Question 28

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

Question 29

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

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

Question 30

সমস্ত শ্রেণীর সদস্যদের সূচনা করা হচ্ছে।

আমি প্রতিটি শ্রেণীর সদস্যকে কিছু দিয়ে সাধারণত স্পষ্টভাবে সূচনা করতাম, সাধারণত নুল হয়। আমি বুঝতে পেরেছি যে এটি:

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

Question 31

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

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