ਉਹੀ ਕੰਮ ਕਰਨ ਤੋਂ ਕਿਵੇਂ ਰੋਕਿਆ ਜਾਵੇ

ਕੀ ਤੁਸੀਂ ਰੁਟੀਨ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ ਵਾਰ-ਵਾਰ ਦੁਹਰਾਉਣਾ ਪਸੰਦ ਕਰਦੇ ਹੋ? ਇਸ ਲਈ ਮੈਂ ਨਹੀਂ ਕਰਦਾ। ਪਰ ਹਰ ਵਾਰ SQL ਕਲਾਇੰਟ ਵਿੱਚ ਜਦੋਂ Rostelecom ਸਟੋਰੇਜ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਸੀ, ਮੈਨੂੰ ਟੇਬਲ ਦੇ ਵਿਚਕਾਰ ਸਾਰੇ ਜੋੜਾਂ ਨੂੰ ਹੱਥੀਂ ਰਜਿਸਟਰ ਕਰਨਾ ਪੈਂਦਾ ਸੀ। ਅਤੇ ਇਹ ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ 90% ਮਾਮਲਿਆਂ ਵਿੱਚ ਟੇਬਲਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਲਈ ਖੇਤਰ ਅਤੇ ਸ਼ਰਤਾਂ ਪੁੱਛਗਿੱਛ ਤੋਂ ਪੁੱਛਗਿੱਛ ਤੱਕ ਮੇਲ ਖਾਂਦੀਆਂ ਹਨ! ਇਹ ਜਾਪਦਾ ਹੈ ਕਿ ਕਿਸੇ ਵੀ SQL ਕਲਾਇੰਟ ਕੋਲ ਆਟੋ-ਕੰਪਲੀਸ਼ਨ ਫੰਕਸ਼ਨ ਹੁੰਦੇ ਹਨ, ਪਰ ਸਟੋਰੇਜ ਲਈ ਇਹ ਹਮੇਸ਼ਾ ਕੰਮ ਨਹੀਂ ਕਰਦਾ: ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਲਈ ਉਹਨਾਂ ਵਿੱਚ ਘੱਟ ਹੀ ਵਿਲੱਖਣ ਰੁਕਾਵਟ ਅਤੇ ਵਿਦੇਸ਼ੀ ਕੁੰਜੀ ਸ਼ਾਮਲ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਹੋਵੇਗਾ ਕਿ ਹਰੇਕ ਨਾਲ ਇਕਾਈਆਂ ਕਿਵੇਂ ਸੰਬੰਧਿਤ ਹਨ। ਹੋਰ ਅਤੇ ਇਹ ਤੁਹਾਡੇ ਲਈ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।

ਇਨਕਾਰ, ਗੁੱਸੇ, ਸੌਦੇਬਾਜ਼ੀ, ਉਦਾਸੀ ਅਤੇ ਮਨਜ਼ੂਰੀ ਦੇ ਨੇੜੇ ਆਉਣ ਤੋਂ ਬਾਅਦ, ਮੈਂ ਫੈਸਲਾ ਕੀਤਾ - ਕਿਉਂ ਨਾ ਬਲੈਕਜੈਕ ਨਾਲ ਆਟੋਫਿਲ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕਰੋ? ਮੈਂ dbeaver ਕਲਾਇੰਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹਾਂ, ਜਾਵਾ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ, ਇਸਦਾ ਇੱਕ ਓਪਨ ਸੋਰਸ ਕਮਿਊਨਿਟੀ ਸੰਸਕਰਣ ਹੈ. ਇੱਕ ਸਧਾਰਨ ਯੋਜਨਾ ਪਰਿਪੱਕ ਹੋ ਗਈ ਹੈ:

1. ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਕਲਾਸਾਂ ਲੱਭੋ ਜੋ ਸਵੈ-ਪੂਰਤੀ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਨ
2. ਉਹਨਾਂ ਨੂੰ ਬਾਹਰੀ ਮੈਟਾਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਰੀਡਾਇਰੈਕਟ ਕਰੋ ਅਤੇ ਉੱਥੇ ਤੋਂ ਸ਼ਾਮਲ ਹੋਣ ਬਾਰੇ ਜਾਣਕਾਰੀ ਖਿੱਚੋ
3. ??????
4. ਮੁਨਾਫਾ

ਮੈਂ ਪਹਿਲੇ ਬਿੰਦੂ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝ ਲਿਆ - ਮੈਨੂੰ ਬੱਗ ਟਰੈਕਰ ਵਿੱਚ ਆਟੋਫਿਲ ਨੂੰ ਅਨੁਕੂਲ ਕਰਨ ਲਈ ਇੱਕ ਬੇਨਤੀ ਮਿਲੀ ਅਤੇ ਸੰਬੰਧਿਤ ਵਚਨਬੱਧ SQLCompletionAnalyzer ਕਲਾਸ ਦੀ ਖੋਜ ਕੀਤੀ। ਮੈਂ ਕੋਡ ਨੂੰ ਦੇਖਿਆ ਅਤੇ ਇਹ ਉਹੀ ਹੈ ਜੋ ਮੈਨੂੰ ਚਾਹੀਦਾ ਹੈ। ਜੋ ਬਾਕੀ ਬਚਦਾ ਹੈ ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣਾ ਹੈ ਤਾਂ ਜੋ ਸਭ ਕੁਝ ਕੰਮ ਕਰੇ. ਮੈਂ ਇੱਕ ਮੁਫਤ ਸ਼ਾਮ ਦਾ ਇੰਤਜ਼ਾਰ ਕੀਤਾ ਅਤੇ ਲਾਗੂ ਕਰਨ ਦੁਆਰਾ ਸੋਚਣਾ ਸ਼ੁਰੂ ਕੀਤਾ. ਮੈਂ json ਵਿੱਚ ਟੇਬਲ ਲਿੰਕ ਨਿਯਮ (ਮੈਟਾਡੇਟਾ) ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ. ਮੇਰੇ ਕੋਲ ਇਸ ਫਾਰਮੈਟ ਨਾਲ ਕੰਮ ਕਰਨ ਦਾ ਕੋਈ ਵਿਹਾਰਕ ਅਨੁਭਵ ਨਹੀਂ ਸੀ ਅਤੇ ਮੌਜੂਦਾ ਕਾਰਜ ਨੂੰ ਇਸ ਭੁੱਲ ਨੂੰ ਠੀਕ ਕਰਨ ਦੇ ਮੌਕੇ ਵਜੋਂ ਦੇਖਿਆ ਗਿਆ ਸੀ।

ਜੇਸਨ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਮੈਂ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ json- ਸਧਾਰਨ ਗੂਗਲ ਤੋਂ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਹੈਰਾਨੀ ਦੀ ਸ਼ੁਰੂਆਤ ਹੋਈ. ਜਿਵੇਂ ਕਿ ਇਹ ਨਿਕਲਿਆ, dbeaver, ਇੱਕ ਸੱਚੀ ਐਪਲੀਕੇਸ਼ਨ ਵਜੋਂ, Eclipse ਪਲੇਟਫਾਰਮ ਉੱਤੇ OSGi ਫਰੇਮਵਰਕ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਲਿਖਿਆ ਗਿਆ ਸੀ। ਤਜਰਬੇਕਾਰ ਡਿਵੈਲਪਰਾਂ ਲਈ, ਇਹ ਚੀਜ਼ ਨਿਰਭਰਤਾ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨਾ ਸੁਵਿਧਾਜਨਕ ਬਣਾਉਂਦੀ ਹੈ, ਪਰ ਮੇਰੇ ਲਈ ਇਹ ਹਨੇਰੇ ਜਾਦੂ ਵਰਗਾ ਸੀ, ਜਿਸ ਲਈ ਮੈਂ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਤਿਆਰ ਨਹੀਂ ਸੀ: ਆਮ ਵਾਂਗ, ਮੈਂ ਉਹਨਾਂ ਕਲਾਸਾਂ ਨੂੰ ਆਯਾਤ ਕਰਦਾ ਹਾਂ ਜਿਨ੍ਹਾਂ ਦੀ ਮੈਨੂੰ json-ਸਿਪਲ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਸਿਰਲੇਖ ਵਿੱਚ ਲੋੜ ਹੁੰਦੀ ਹੈ. ਸੰਪਾਦਿਤ ਕਲਾਸ, ਇਸਨੂੰ pom. xml ਵਿੱਚ ਨਿਸ਼ਚਿਤ ਕਰੋ, ਜਿਸ ਤੋਂ ਬਾਅਦ ਪ੍ਰੋਜੈਕਟ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਆਮ ਤੌਰ 'ਤੇ ਅਸੈਂਬਲ ਹੋਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ ਅਤੇ ਗਲਤੀਆਂ ਨਾਲ ਕਰੈਸ਼ ਹੋ ਜਾਂਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ, ਮੈਂ ਬਿਲਡ ਤਰੁਟੀਆਂ ਨੂੰ ਠੀਕ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਿਹਾ: ਮੈਂ ਲਾਇਬ੍ਰੇਰੀ ਨੂੰ pom.xml ਵਿੱਚ ਨਹੀਂ, ਪਰ manifest.mf ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਰਜਿਸਟਰ ਕੀਤਾ, ਜਿਵੇਂ ਕਿ OSGI ਦੁਆਰਾ ਲੋੜੀਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਇਸਨੂੰ ਆਯਾਤ-ਪੈਕੇਜ ਦੇ ਤੌਰ ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ। ਸਭ ਤੋਂ ਸੁੰਦਰ ਹੱਲ ਨਹੀਂ, ਪਰ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ. ਫਿਰ ਅਗਲਾ ਹੈਰਾਨੀ ਪ੍ਰਗਟ ਹੋਇਆ. ਜੇਕਰ ਤੁਸੀਂ ਇੰਟੈਲੀਜ ਆਈਡੀਆ ਵਿੱਚ ਵਿਕਾਸ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਸਿਰਫ਼ ਜਾ ਕੇ ਗ੍ਰਹਿਣ ਪਲੇਟਫਾਰਮ ਦੇ ਆਧਾਰ 'ਤੇ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ: ਇੱਕ ਤਜਰਬੇਕਾਰ ਡਿਵੈਲਪਰ ਨੂੰ ਪੁੱਛਗਿੱਛ ਨੂੰ ਪੂਰਾ ਕੀਤੇ ਬਿਨਾਂ ਕਿਸੇ ਵਿਸ਼ਲੇਸ਼ਕ ਤੋਂ ਘੱਟ ਨਹੀਂ ਝੱਲਣਾ ਚਾਹੀਦਾ ਹੈ। ਬੀਵਰ ਡਿਵੈਲਪਰ ਖੁਦ ਬਚਾਅ ਲਈ ਆਏ, ਵਿਕੀ ਵਿੱਚ ਦਰਸਾਉਂਦੇ ਹੋਏ ਕਿ ਇੱਕ ਡਫਲੀ ਨਾਲ ਸਾਰੇ ਡਾਂਸ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ। ਸਭ ਤੋਂ ਤੰਗ ਕਰਨ ਵਾਲੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹਨਾਂ ਸਾਰੇ ਸਕੁਐਟਸ ਦੇ ਬਾਅਦ ਵੀ, ਪ੍ਰੋਜੈਕਟ ਆਯਾਤ-ਪੈਕੇਜ ਦੁਆਰਾ ਜੁੜੀ ਜੇਸਨ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਨਾਲ ਡੀਬੱਗ ਵਿੱਚ ਲਾਂਚ ਨਹੀਂ ਹੋਣਾ ਚਾਹੁੰਦਾ ਸੀ (ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਇਹ ਅਜੇ ਵੀ ਮੁਕੰਮਲ ਉਤਪਾਦ ਵਿੱਚ ਸਫਲਤਾਪੂਰਵਕ ਇਕੱਠਾ ਕੀਤਾ ਗਿਆ ਸੀ)।

ਉਸ ਸਮੇਂ ਤੱਕ, ਮੈਨੂੰ ਆਪਣੇ ਕੰਮ ਲਈ json ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਅਸੁਵਿਧਾ ਦਾ ਅਹਿਸਾਸ ਹੋ ਗਿਆ ਸੀ - ਆਖ਼ਰਕਾਰ, ਮੈਟਾਡੇਟਾ ਨੂੰ ਹੱਥੀਂ ਸੰਪਾਦਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ, ਅਤੇ xml ਫਾਰਮੈਟ ਇਸ ਲਈ ਬਿਹਤਰ ਅਨੁਕੂਲ ਹੈ. xml ਦੇ ਪੱਖ ਵਿੱਚ ਦੂਜੀ ਦਲੀਲ JDK ਵਿੱਚ ਸਾਰੀਆਂ ਲੋੜੀਂਦੀਆਂ ਕਲਾਸਾਂ ਦੀ ਮੌਜੂਦਗੀ ਸੀ, ਜਿਸ ਨੇ ਇੱਕ ਬਾਹਰੀ ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ ਲੜਾਈ ਨੂੰ ਰੋਕਣਾ ਸੰਭਵ ਬਣਾਇਆ. ਬਹੁਤ ਖੁਸ਼ੀ ਨਾਲ, ਮੈਂ ਸਾਰੇ ਮੈਟਾਡੇਟਾ ਨੂੰ json ਤੋਂ xml ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਅਤੇ ਆਟੋਕੰਪਲੀਟ ਤਰਕ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ।

ਮੈਟਾਡੇਟਾ ਉਦਾਹਰਨ

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<tableRelations>
    <tableRelation>
        <leftTable>dim_account</leftTable>
        <rightTable>dim_partner</rightTable>
        <joinColumnPair leftColumn="partner_key" rightColumn="partner_key"/>
        <joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
    </tableRelation>
    <tableRelation>
        <leftTable>dim_account</leftTable>
        <rightTable>dim_branch</rightTable>
        <joinColumnPair leftColumn="src_id" rightColumn="src_id"/>
        <joinColumnPair leftColumn="branch_key" rightColumn="branch_key"/>
    </tableRelation>
</tableRelations>

ਨਤੀਜੇ ਵਜੋਂ ਆਈ ਤਬਦੀਲੀਆਂ ਕੀਤੀਆਂ SQLUtils ਅਤੇ SQLCompletionAnalyzer ਕਲਾਸਾਂ ਵਿੱਚ। ਵਿਚਾਰ ਇਹ ਹੈ: ਜੇਕਰ ਪ੍ਰੋਗਰਾਮ ਬੁਨਿਆਦੀ ਤਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਢੁਕਵੇਂ ਸਵੈ-ਸੰਪੂਰਨ ਸੁਝਾਵਾਂ ਨੂੰ ਲੱਭਣ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ, ਤਾਂ ਇਹ ਇੱਕ ਬਾਹਰੀ xml ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੰਭਾਵਿਤ ਜੋੜਾਂ ਦੀ ਮੌਜੂਦਗੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਫਾਈਲ ਆਪਣੇ ਆਪ ਵਿੱਚ ਟੇਬਲਾਂ ਦੇ ਜੋੜਿਆਂ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ ਜੋ ਉਹਨਾਂ ਖੇਤਰਾਂ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜਿਸ ਦੁਆਰਾ ਇਹਨਾਂ ਟੇਬਲਾਂ ਨੂੰ ਲਿੰਕ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਰਿਕਾਰਡ eff_dttm ਅਤੇ exp_dttm ਅਤੇ ਲਾਜ਼ੀਕਲ ਡਿਲੀਟ ਫਲੈਗ deleted_ind ਦੀਆਂ ਤਕਨੀਕੀ ਵੈਧਤਾ ਮਿਤੀਆਂ 'ਤੇ ਪਾਬੰਦੀਆਂ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸੈੱਟ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਜਦੋਂ ਕੋਡ ਵਿੱਚ ਬਦਲਾਅ ਕੀਤੇ ਗਏ ਸਨ, ਤਾਂ ਸਵਾਲ ਪੈਦਾ ਹੋਇਆ ਸੀ - ਮੈਟਾਡੇਟਾ ਨਾਲ ਫਾਈਲ ਨੂੰ ਕੌਣ ਭਰੇਗਾ? ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਹਨ, ਸਾਰੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਰਜਿਸਟਰ ਕਰਨਾ ਮਹਿੰਗਾ ਹੈ। ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਇਹ ਕੰਮ ਆਪਣੇ ਸਾਥੀ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਨੂੰ ਸੌਂਪਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਮੈਂ ਮੈਟਾਡੇਟਾ ਫਾਈਲ ਨੂੰ svn ਵਿੱਚ ਪੋਸਟ ਕੀਤਾ ਹੈ, ਜਿੱਥੋਂ ਪ੍ਰੋਗਰਾਮ ਦੇ ਨਾਲ ਸਥਾਨਕ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਇੱਕ ਚੈੱਕਆਉਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਿਧਾਂਤ ਇਹ ਹੈ: ਕੀ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਹਸਤੀ ਪ੍ਰਗਟ ਹੋਈ ਹੈ? ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਕ ਫਾਈਲ ਵਿੱਚ ਸੰਭਵ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਤਬਦੀਲੀਆਂ ਕਰਦਾ ਹੈ, ਬਾਕੀ ਆਪਣੇ ਆਪ ਨੂੰ ਚੈੱਕ ਆਊਟ ਕਰਦੇ ਹਨ ਅਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਸਵੈ-ਸੰਪੂਰਨਤਾ ਦਾ ਆਨੰਦ ਲੈਂਦੇ ਹਨ: ਕਮਿਊਨਿਟੀ, ਗਿਆਨ ਦਾ ਸੰਗ੍ਰਹਿ ਅਤੇ ਇਹ ਸਭ ਕੁਝ। ਸਹਿਕਰਮੀਆਂ ਲਈ ਪ੍ਰੋਗਰਾਮ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਇੱਕ ਵਰਕਸ਼ਾਪ ਦਾ ਆਯੋਜਨ ਕੀਤਾ, ਕੰਫਲੂਐਂਸ ਵਿੱਚ ਇੱਕ ਲੇਖ ਲਿਖਿਆ - ਹੁਣ ਕੰਪਨੀ ਕੋਲ ਇੱਕ ਹੋਰ ਸੁਵਿਧਾਜਨਕ ਸਾਧਨ ਹੈ.

ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ 'ਤੇ ਕੰਮ ਕਰਨ ਨਾਲ ਮੈਨੂੰ ਇਹ ਸਮਝ ਮਿਲੀ ਕਿ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਟਿੰਕਰ ਕਰਨ ਤੋਂ ਡਰਨ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ - ਇੱਕ ਨਿਯਮ ਦੇ ਤੌਰ 'ਤੇ, ਉਹਨਾਂ ਕੋਲ ਇੱਕ ਸਪਸ਼ਟ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਅਤੇ ਭਾਸ਼ਾ ਦਾ ਮੁਢਲਾ ਗਿਆਨ ਵੀ ਪ੍ਰਯੋਗਾਂ ਲਈ ਕਾਫੀ ਹੋਵੇਗਾ। ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਮਾਤਰਾ ਵਿੱਚ ਲਗਨ ਨਾਲ, ਤੁਸੀਂ ਨਫ਼ਰਤ ਵਾਲੇ ਰੁਟੀਨ ਕਾਰਜਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣ ਦੇ ਯੋਗ ਹੋਵੋਗੇ, ਆਪਣੇ ਆਪ ਨੂੰ ਨਵੇਂ ਪ੍ਰਯੋਗਾਂ ਲਈ ਸਮਾਂ ਬਚਾ ਸਕਦੇ ਹੋ।

ਸਰੋਤ: www.habr.com