हमने अपने जीवन में सबसे उपयोगी कोड लिखा, लेकिन इसे कचरे में फेंक दिया। हमारे साथ

मैंने अपने तहखाने में एक छिद्रण बैग लटका दिया, उस पर एक विशिष्ट प्रबंधक की एक स्टॉक फोटो चिपका दी और वाक्यांशों को खेलने के लिए अंदर स्पीकर भर दिया, जिससे मुझे गुस्सा आ गया। उदाहरण के लिए, एक नाशपाती कहती है: “व्यवसाय को आपके सही कोड की आवश्यकता नहीं है। उसे समस्या को हल करने की आवश्यकता है ताकि लाभ लागत को कवर करे। यदि आपको इसके लिए गोवनोकॉड की आवश्यकता है, तो गोवनोकॉड होगा। " और मैं लंड खड़ा करने लगा हूँ।

हाल ही में, मैंने नाशपाती में एक नोट जोड़ा: "प्रकार कठिन और अनावश्यक हैं।" इस क्षण, मैंने इतनी मेहनत की कि मेरा हाथ लगभग टूट गया। क्योंकि मेरे लिए पर्याप्त है। कुछ महीने पहले, मैंने अपने करियर के सबसे अहम् मामलों में से एक का अनुभव किया।

मेरे दोस्त अंतोखा ने मुझे एक बड़े, बड़े निगम के समाधान के लिए मदद करने के लिए कहा। मैं सहमत था, और हम कॉरपोरेट गैरबराबरी, कुरकुरे, उन सहयोगियों के साथ युद्ध में डूब गए, जो कुछ भी नहीं समझते थे और सभी तरह के अन्याय। हम कुछ भी नहीं कह सकते, इसलिए हम प्रकारों के बारे में बात करेंगे ताकि ऐसा कचरा कभी किसी के साथ न हो।

1

- ( अंतोक्ष रैन्केडू ) मुझे एक आंतरिक प्लेटफ़ॉर्म टूल के विकास के लिए सौंपा गया था - ऑब्जेक्ट-ओरिएंटेड मॉडल के रूप में सॉफ़्टवेयर संस्थाओं को व्यक्त करने और एपीआई सेवाओं के साथ एकसमान काम के लिए एक पुस्तकालय। यही है, डेटा के साथ बातचीत करने का एक उपकरण जो स्रोत से प्रदर्शन तक जाता है और इसके विपरीत।

इस तरह, स्वरूपण, रूपांतरण, गणना और रूपांतरण की एक बड़ी मात्रा। विशाल संरचनाएं, जटिल पदानुक्रम, हर चीज के साथ हर चीज के कई कनेक्शन। ऐसे नेटवर्क में यह खो जाना बहुत आसान है। आप डेटा के टुकड़े देखते हैं और यह नहीं जानते कि क्या किया जा सकता है और क्या नहीं किया जा सकता है। यह पता लगाने के लिए बहुत समय बिताएं। यह बहुत नशीला है। प्रकारों का केवल एक अच्छा वर्णन समस्या को हल करता है।

कई समाधानों में उपयुक्त टाइपिंग की कमी के कारण, रनटाइम और संकलन समय में एक ही प्रोग्राम व्यवहार को प्राप्त करना अधिक कठिन हो जाता है। प्रकारों को पूर्ण विश्वास देना चाहिए कि सब कुछ समान है और निष्पादन के दौरान भी होगा। टेस्ट वही कर सकते हैं। दोनों पर भरोसा करना सबसे अच्छा है। लेकिन अगर आप प्रकारों और परीक्षणों के बीच चयन करते हैं - प्रकार बहुत अधिक विश्वसनीय और सस्ते हैं।

जब आप एक मोर्चा बनाते हैं, तो समस्याओं के दो स्रोत होते हैं - उपयोगकर्ता और बैकएंड। उपयोगकर्ता के साथ सब कुछ सरल है - उपयोगकर्ता I / O (प्रतिक्रिया, कोणीय, स्वर और अन्य) से अमूर्त कई सुविधाजनक पुस्तकालय और रूपरेखाएं हैं।

बैकएंड के साथ बातचीत में एक और कहानी है। इसकी प्रजातियां कई हैं, और अहसास अंधेरे हैं। आप डेटा का वर्णन करने के लिए एक मानक दृष्टिकोण को परिभाषित नहीं कर सकते। इस वजह से, "डेटा संरचना के सामान्यीकरण" जैसी बैसाखी का आविष्कार किया गया था, जब आने वाले सभी डेटा को एक कठोर संरचना में घटा दिया जाता है, और अगर कुछ गलत हो जाता है, तो अपवाद या असामान्य संचालन शुरू होता है। इससे विकास को गति और सरल होना चाहिए, लेकिन वास्तव में इसके लिए बहुत सारे प्रलेखन, यूएमएल आरेख, सुविधाओं का वर्णन आवश्यक है।

क्लाइंट और सर्वर भागों की परस्पर क्रिया में एक वास्तुदोष की समस्या उत्पन्न हो गई क्योंकि दृश्यपटल परिपक्व हो गया था। यह एक पूर्ण व्यवसाय बन गया, न कि बैकएंड के शीर्ष पर एक लेआउट। पहले, केवल सर्वर साइड डेवलपर्स ने क्लाइंट-सर्वर इंटरैक्शन को कहा था। अब मोर्चों और पीठों को बातचीत करने और बारीकी से काम करने के लिए मजबूर किया जाता है। हमें एक उपकरण की आवश्यकता है जो हमें डेटा सत्य की हानि से बचने के लिए एपीआई डेटा स्रोत सेवाओं के साथ काम करने की अनुमति देगा, और साथ ही साथ आगे के परिवर्तनों को सरल करेगा। इस समस्या को पूरे समुदाय द्वारा संबोधित किया जाना चाहिए।

- (फिल) यदि आप बैक-एंड हैं, तो आपके पास एप्लिकेशन के लिए बहुत सारे वयस्क समाधान और डेटा मॉडलिंग अभ्यास हैं। उदाहरण के लिए, C # में आप एक डेटा मॉडल वर्ग की सुविधा देते हैं। आप कुछ लेते हैं, कुछ EntityFramework, यह आपको उन विशेषताओं की आपूर्ति करता है जिनके साथ आप अपने मॉडल को कोट करते हैं। आप लीब को बताएं कि आधार तक कैसे पहुंचा जाए। फिर आप इस डेटा में हेरफेर के लिए इसके इंटरफ़ेस का उपयोग करते हैं। इस चीज को ORM कहा जाता है।

सामने के अंत में, हमने यह तय नहीं किया कि यह कैसे करना सबसे अच्छा है - हम खोज करते हैं, कोशिश करते हैं, हास्यास्पद लेख लिखते हैं, फिर हम सब कुछ से इनकार करते हैं, हम शुरू करते हैं और हम अभी भी एक निर्णय पर नहीं आते हैं।

- (एंटोहा) जो कुछ मैंने पहले लिखा था उसमें एक बड़ी समस्या थी - संकीर्ण विशेषज्ञता। हर बार लाइब्रेरी को खरोंच से विकसित किया गया था और हर बार एक प्रकार के क्लाइंट-सर्वर इंटरैक्शन के लिए इसे तेज किया गया था। यह सब उपयुक्त टाइपिंग की कमी के कारण होता है।

मेरा मानना ​​है कि स्थिर टाइपिंग के बिना एपीआई और डोमेन अभिव्यक्ति के साथ काम करने के लिए एक सार्वभौमिक पुस्तकालय की कल्पना करना मुश्किल है। इसमें बहुत अधिक प्रतिबिंब होंगे, इसमें भारी मात्रा में प्रलेखन होगा, यह एक या दूसरे रूप के लिए प्रथाओं के संकेत के साथ विभिन्न अनुप्रयोगों से घिरा होगा। यह सरलीकरण नहीं है।

इस तरह के एक अच्छे सार्वभौमिक उपकरण को किसी भी अनुभाग में डेटा की पूरी तस्वीर देनी चाहिए, ताकि आपको हमेशा पता चले कि इस डेटा के साथ कैसे काम करना है और इसकी आवश्यकता क्यों है।

- (फिल) हमें एक परिवाद की आवश्यकता है जो हमें प्रत्येक इकाई का विस्तृत विवरण और नियंत्रण प्रदान करने में सक्षम करेगा, इस इकाई के लिए अलग-अलग इंटरफ़ेस से विभिन्न संसाधनों से डेटा प्राप्त करने के लिए, REST API और json-rpc से graphQL और NQL तक। जो बढ़ते कोड आधार और संरचना को सख्ती और व्यवस्था में रखने की अनुमति देगा। उपयोग करने के लिए सरल और सहज। किसी भी समय संस्थाओं की स्थिति का एक पूर्ण और सटीक विवरण प्रदान करना। हम अपने उपयोगकर्ताओं के मॉड्यूल को डेटा लेयर से अधिक से अधिक अमूर्त करना चाहते हैं।

सबसे पहले, हमने मौजूदा एक को देखा। हमें कुछ पसंद नहीं आया किसी कारण से, डेटा के साथ काम करने के लिए सभी पुस्तकालयों को या तो js पर बनाया जाता है, या किसी भी समूह का एक गुच्छा के साथ। ये किसी भी चीज को बिगाड़ देते हैं। वे डेवलपर्स से यह कहते हुए आंखें मूंद लेते हैं कि इस तरह की लाइब्रेरी से आपको ज्यादा मदद नहीं मिलेगी, जिससे आप अपने डेटा के प्रकारों को नेविगेट नहीं कर पाएंगे, आप उनके कनेक्शनों को व्यक्त नहीं कर पाएंगे। चीजें तब और भी खराब हो जाती हैं जब विभिन्न प्रकार के कई एपीआई का उपयोग किया जाता है या यह विषम होता है।

इन सभी पुस्तकालयों को प्रकारों द्वारा पर्याप्त रूप से संरक्षित नहीं किया गया था। इसलिए, वे हल करने की तुलना में अधिक समस्याएं पैदा करते हैं। उनका उपयोग करना आसान नहीं है, लेकिन अपने डोमेन-विशिष्ट निर्णय लेने के लिए।

इसलिए, संकीर्ण सोच वाले काम के बजाय, जिस पर कार्य खड़ा था, हमने एक बहुत अधिक शक्तिशाली और सार बनाने का फैसला किया, जो कि सब कुछ के लिए उपयुक्त है। और हम अविश्वसनीय रूप से हमारे अधिकार में विश्वास करते थे, क्योंकि केवल इस तरह से वास्तव में अच्छी चीजें बनती हैं।

---

2

- (एंटोहा) जैसा कि अक्सर होता है, मैं सभी प्रकार की पहुंच की प्रतीक्षा कर रहा था ताकि मुझे कंपनी के भंडार में जाने दिया जाए। और यह कई हफ्तों तक रह सकता है। मेरे मामले में, यह केवल एक ही लिया। इस समय, समान लाइब्रेरी बनाने के अपने अनुभव के आधार पर, मैंने कार्य को विघटित कर दिया, समयरेखा का अनुमान लगाया।

समस्या यह है कि पहले, हर किसी की तरह, मैंने बहुत ही विशिष्ट निर्णय लिए। एक सार्वभौमिक उपकरण पर काम करने से अतिरिक्त समस्याएं पैदा होती हैं। टाइप सिस्टम बेहद जटिल निकला, और न ही मुझे और न ही किसी और को इसे डिजाइन करने का कोई अनुभव था। इससे भी बदतर, मेरे आसपास के डेवलपर्स को स्थिर टाइपिंग का बिल्कुल भी विचार नहीं था।

लेकिन मैंने जैसा सही समझा, वैसा करना शुरू कर दिया। डेली में, मैंने आपको बताया कि मैं क्या कर रहा था और क्यों, लेकिन, सिद्धांत रूप में, कोई भी मुझे नहीं समझता था। समस्या के संबंध में टीम के मेरे सवाल हमेशा अनुत्तरित रहे हैं। मानो मेरा अस्तित्व ही नहीं था। दोस्त जो बहुत जटिल और समझ से बाहर कुछ करता है।

मैं समझ गया कि javaScript यहां किसी भी तरह से काम नहीं करेगा। मुझे एक शक्तिशाली टाइपिंग मॉडल के साथ पीएल की आवश्यकता थी, जावास्क्रिप्ट के साथ उत्कृष्ट बातचीत, एक बड़ा समुदाय और एक गंभीर पारिस्थितिकी तंत्र।

- (फिल) मैं टाइपो के आकर्षण को समझने के लिए एंटोहा का लंबे समय से इंतजार कर रहा हूं।

- (एंटोहा) लेकिन इसमें कई समस्याएं हैं जो आपको पागल कर देती हैं। टाइपिंग है, लेकिन मेरे पास अभी भी प्रोग्राम के निष्पादन और उपयोगकर्ता द्वारा निष्पादन के बीच कोई परिपूर्ण पत्राचार नहीं है। टाइपस्क्रिप्ट पहले से जटिल लगती है। उसे सहना पड़ता है। आप हमेशा किसी वस्तु या किसी को लेना और फेंकना चाहते हैं। धीरे-धीरे आप भाषा में, उसके प्रकार प्रणाली में, और यहाँ एक दिलचस्प बात होने लगती है। यह जादुई हो जाता है। सब कुछ टाइप किया जा सकता है।

- (फिल) हमारे जीवन में पहली बार, हम एक साथ आए और कुछ शुरू किया।

पहला चरण उपयोगकर्ता के लिए डेटा स्कीमा का वर्णन करने के लिए है। हमें आश्चर्य है कि यह कैसा दिखता है। कुछ इस तरह:

type CustomerSchema = { 
  id: number;
  name: string;
}
const Customer = new Model<CustomerSchema>(‘Customer’);

, , . id, , , .
, . , , -. , , .

, . — - , . , , . : , , . . :

 /**
   name: String
   String -   js -: StringConstructor
              
        
*/
const customerSchema = Schema.create({
  id: Number,
  name: String,
});

. , , . , Number String . : , . :

const customerSchema = Schema.create({
  id: 1,
  name: 2,
});

. `Schema.create` , . `if (!(property instanceof String)) throw new Error(« , »)`. .

-, , -, . , . , , .

. , Schema.create.

:

//      
type Map<T> = {
  [key: string]: T | Map<T>; 
};

/**
      ,
      ,
     .
*/
type NumberType = Template<NumberConstructor, number, 'number'>;
type StringType = Template<StringConstructor, string, 'string'>;
type SymbolType = Template<SymbolConstructor, symbol, 'symbol'>;
type BooleanType = Template<BooleanConstructor, boolean, 'boolean'>;
type DateType = Template<DateConstructor, Date, 'date'>;

interface ArrayType extends Array<ExtractTypeValues<Types>> {};

type Types = {
  Number: NumberType;
  String: StringType;
  Symbol: SymbolType;
  Boolean: BooleanType;
  Date: DateType;
  Array: ArrayType;
};
//    
type MapTypes= Map<ApplyTemplate<Types>>;
//     - 
type Declaration = ExtractInputTypes<MapTypes>;
interface Schema<...> {
 //   ,   .
 create: <T extends Declaration>(
    declaration: ConvertInstanceTypesToConstructorTypes<T>
  ) => Schema<T>;
};

, . , , , , .

,

type CustomerSchema = {
  id: number;
  name: string;
};
const customerSchema: CustomerSchema = Schema.create({
  id: Number,
  name: String,
});

. , , .

. any. — any, 100%, , .

, , , . . `Schema.create` . 99% , . , . — ! , .

. , , , . . :

const customerSchema = Schema.create({
 id: Number,
 name: String,
});

//   vscode  : id, name 
Schema.raw(customerSchema). 

//   
//    .
Schema.raw(customerSchema).id;

//        .
Schema.raw(customerSchema).neId;

. :

const customerSchema = Schema.create({
 id: Number,
 name: String,
});

if (true) {
  customerSchema.add({gender: String});
} 

//        ,
//      gender.
//  ,           
// .
Schema.raw(customerSchema).

, , , . gender, , (, , this !). - . , , .

, . , , . , . .

:

const customerSchema = Schema.create({
 id: Number,
 name: String,
});

// customerSchema.add({gender: String});
//      ,    .
//  :
const customerWithGenderSchema = customerSchema.add({gender: String});

//   .
// :
Schema.raw(customerWithGenderSchema).
//  id, name, gender

// 
Schema.raw(customerSchema).
//  id, name

, , . , .

:

const customerSchema = Schema.create({
 id: Number,
 name: String,
});

const repository = RepositoryManager.create(openApiDriver, { 
 // config
});
const Customer = Model.create(repository, customerSchema);

Customer.getAll().first().
//   ide  ,       id, name  gender.
//    ,   
Customer.getAll().first().age;
//   .    ,     , 
//   .

getAll .
:

type MapSchemaToDriver<S extends Schema, D extends Driver> = 
  InferSchemaDeclaration<S> extends SchemaDeclaration
    ? InferDriverMethods<D> extends DriverTemplate<IMRReader, IMRWriter>
      ? Repository<InferSchemaDeclaration<S>, InferDriverMethods<D>>
      : never
    : never;

interface Repository<D extends Driver, S extends Schema> {
  get: <T extends DSLTerm>(dsl: ParseDSLTerm<T>) => MapSchemaToDriver<S, D> extends RepositoryTemplate ? ApplyDSLTerm<MapSchemaToDriver<S, D>, T> : Error<’type’, ‘Type error’>;
}

, :

«, B, A, , , , A. . - ».

. .

«» , , . , .

. , . :

« , *--.*, . , id . - , , ».

.

---

2.5

, , , . .

, — , , , . . , , .

, . , , , , . , , .

ODM ORM — IMR (Isomorphic Model Representation)

, , API . , . , select-where , .

— , , .

. . . , , , . , , , , .

, — , — , - .

.

---

3

— () , , . , , , . . , , , .

- , , « ». , . , — . , , ,

, .

. , , . , , , . . . , . , , , , .

— () , , . . , , , .

, , . . , .

— () , . , , . . , . - , , , , .

, - . , . , .

, , . , . .

---

4

— () , — . ! ?! , , , , , ODM/ORM - , . , . , , «- , ».

, , . . , , . .

, , - , . — , .

, . -:

/*
     .
    — .
       .
     
*/

import { View } from '@view';
import { Logger } from '@utils';

//   —  ,    .
//         .
import { Robot } from '@domain/models';

// ,       
//   
function foo() {
 Robot.fetch({
   location: {
     area: 2,
     free: true,
     key: 'f49a6712', //    - compile-time checked
   }
 })
 .then(View.Grid.display)
 .catch(Logger.error);
}

, . , — js/ts . , . - - , , , — Result .

. - Logger.Error, .

/*
   :
       ,
         -  .
     - 
             .
     :
*/
import { Schema, Model } from 'imr';
import { Logger } from '@utils';
import { View } from '@view';
import { robotSchema } from '@domain/schemas';
import { batteryStationService } from '@domain/infrastructure/services/batteryStation';
import { Robot } from '@domain/models';
import { batteryNode } from '../services/nodeNames';

//       
// ,       ,       ,
//  ,        «»
const robotSchemaWithBattery =
  robotSchema
    .add('battery', Schema.union('li-ion', 'silicon'))
    .remove('speed');

// ,       
//     :
function foo(nodeName) {

 //   -:   -,      
 if (nodeName === batteryNode) {
   //   ,      
   const CustomerRobot = Model.create(robotSchemaWithBattery, batteryStationService);

   CustomerRobot
     //        .
     // , , 'li-notIon'  
     .fetch({ filter: { battery: 'li-ion' } })
    
     //   .
     //   ,      ,     ,   .
     //  ,      ,
     //      ,      .
     .then(View.Grid.display)
     .catch(Logger.error)

 } else {
   Robot
     .fetch()
     .then(View.Grid.display)
     .catch(Logger.error)
 }
}

---

5

— () , , , - , . , - , , .

.

, , — . . , — , , . . , , — , .

, : . . .

— . , .

: rcanedu, arttom