एक हफ्ते में मेरा कैच

जितना अधिक एक डेवलपर एक टीम में एक आवेदन पर काम करता है और उसका कोड बेहतर जानता है, उतनी बार वह अपने साथियों के काम को प्रमाणित करने में लगा रहता है। आज मैं दिखाऊंगा कि बहुत अच्छे डेवलपर्स द्वारा लिखे गए कोड में एक सप्ताह में क्या पकड़ा जा सकता है। कटौती के तहत हमारी रचनात्मकता (और मेरे विचारों का एक छोटा) की ज्वलंत कलाकृतियों का एक संग्रह है।

तुलनाकारक

एक कोड है:

@Getter class Dto { private Long id; } // another class List<Long> readSortedIds(List<Dto> list) { List<Long> ids = list.stream().map(Dto::getId).collect(Collectors.toList()); ids.sort(new Comparator<Long>() { public int compare(Long o1, Long o2) { if (o1 < o2) return -1; if (o1 > o2) return 1; return 0; } }); return ids; } 

कोई व्यक्ति नोट करता है कि आप सीधे स्ट्रीम को सॉर्ट कर सकते हैं, लेकिन मैं आपका ध्यान तुलनित्र पर आकर्षित करना चाहता हूं Comparator::compare लिए प्रलेखन Comparator::compare विधि सफेद में अंग्रेजी में कहते हैं:

आदेश के लिए अपने दो तर्कों की तुलना करता है। एक नकारात्मक पूर्णांक, शून्य या एक सकारात्मक पूर्णांक लौटाता है क्योंकि पहला तर्क दूसरे की तुलना में कम, बराबर या उससे अधिक है।

यह ऐसा व्यवहार है जिसे हमारे कोड में लागू किया गया है। क्या गलत है? तथ्य यह है कि जावा के रचनाकारों ने बहुत दूरदर्शी रूप से सुझाव दिया कि कई को इस तरह के तुलनित्र की आवश्यकता होगी और इसे हमारे लिए बनाया जाएगा। हम अपने कोड को सरल करके इसका उपयोग कर सकते हैं:

 List<Long> readSortedIds(List<Dto> list) { List<Long> ids = list.stream().map(Dto::getId).collect(Collectors.toList()); ids.sort(Comparator.naturalOrder()); return ids; } 

इसी तरह, यह कोड

 List<Dto> sortDtosById(List<Dto> list) { list.sort(new Comparator<Dto>() { public int compare(Dto o1, Dto o2) { if (o1.getId() < o2.getId()) return -1; if (o1.getId() > o2.getId()) return 1; return 0; } }); return list; } 

कलाई का एक झटका के साथ में बदल जाता है

 List<Dto> sortDtosById(List<Dto> list) { list.sort(Comparator.comparing(Dto::getId)); return list; } 

वैसे, "विचार" के नए संस्करण में ऐसा करना संभव होगा:

वैकल्पिक दुरुपयोग

शायद हम में से प्रत्येक ने कुछ इस तरह से देखा:

 List<UserEntity> getUsersForGroup(Long groupId) { Optional<Long> optional = Optional.ofNullable(groupId); if (optional.isPresent()) { return userRepository.findUsersByGroup(optional.get()); } return Collections.emptyList(); } 

अक्सर, मूल्य की उपस्थिति / अनुपस्थिति की जांच के लिए Optional उपयोग किया जाता है, हालांकि इसके लिए इसे नहीं बनाया गया था। गाली बाँधो और आसान लिखो:

 List<UserEntity> getUsersForGroup(Long groupId) { if (groupId == null) { return Collections.emptyList(); } return userRepository.findUsersByGroup(groupId); } 

याद रखें कि Optional विधि तर्क या क्षेत्र के बारे में नहीं है, बल्कि वापसी मूल्य के बारे में है। यही कारण है कि यह बिना क्रमांकन समर्थन के डिजाइन किया गया है।

शून्य विधियाँ जो एक तर्क की स्थिति को बदल देती हैं

इस तरह एक विधि की कल्पना करो:

 @Component @RequiredArgsConstructor public class ContractUpdater { private final ContractRepository repository; @Transactional public void updateContractById(Long contractId, Dto contractDto) { Contract contract = repository.findOne(contractId); contract.setValue(contractDto.getValue()); repository.save(contract); } } 

निश्चित रूप से आपने कई बार कुछ ऐसा ही देखा और लिखा होगा। यहां मुझे यह पसंद नहीं है कि विधि इकाई की स्थिति को बदल देती है, लेकिन इसे वापस नहीं करती है। इसी तरह के ढांचे के तरीके कैसे व्यवहार करते हैं? उदाहरण के लिए, org.springframework.data.jpa.repository.JpaRepository::save और javax.persistence.EntityManager::merge एक मान लौटाएं। मान लीजिए कि एक अनुबंध को अपडेट करने के बाद हमें इसे update विधि से बाहर निकालने की आवश्यकता है। यह कुछ इस तरह से निकलता है:

 @Transactional public void anotherMethod(Long contractId, Dto contractDto) { updateService.updateContractById(contractId, contractDto); Contract contract = repositoroty.findOne(contractId); doSmth(contract); } 

हां, हम इकाई को सीधे अपने हस्ताक्षर बदलकर UpdateService::updateContract विधि से पारित कर सकते हैं, लेकिन इसे इस तरह करना बेहतर है:

 @Component @RequiredArgsConstructor public class ContractUpdater { private final ContractRepository repository; @Transactional public Contract updateContractById(Long contractId, Dto contractDto) { Contract contract = repository.findOne(contractId); contract.setValue(contractDto.getValue()); return repository.save(contract); } } // @Transactional public void anotherMethod(Long contractId, Dto contractDto) { Contract contract = updateService.updateContractById(contractId, contractDto); doSmth(contract); } 

एक ओर, यह कोड को सरल बनाने में मदद करता है, दूसरी ओर, यह परीक्षण के साथ मदद करता है। सामान्य तौर पर, void तरीकों का परीक्षण करना एक बेहद ही डरावना काम है, जिसे मैं उसी उदाहरण का उपयोग करके दिखाऊंगा:

 @RunWith(MockitoJUnitRunner.class) public class ContractUpdaterTest { @Mock private ContractRepository repository; @InjectMocks private ContractUpdater updater; @Test public void updateContractById() { Dto dto = new Dto(); dto.setValue("- "); Long contractId = 1L; when(repository.findOne(contractId)).thenReturn(new Contract()); updater.updateContractById(contractId, contractDto); //void // ,       dto? -  : ArgumentCaptor<Contract> captor = ArgumentCaptor.forClass(Contract.class); verify(repository).save(captor.capture()); Contract updated = captor.getValue(); assertEquals(dto.getValue(), updated.getValue()); } } 

लेकिन अगर विधि एक मान लौटाती है तो सब कुछ सरल बनाया जा सकता है:

 @RunWith(MockitoJUnitRunner.class) public class ContractUpdaterTest { @Mock private ContractRepository repository; @InjectMocks private ContractUpdater updater; @Test public void updateContractById() { Dto dto = new Dto(); dto.setValue("- "); Long contractId = 1L; when(repository.findOne(contractId)).thenReturn(new Contract()); Contract updated = updater.updateContractById(contractId, contractDto); assertEquals(dto.getValue(), updated.getValue()); } } 

एक झपट्टे में, न केवल ContractRepository::save को कॉल ContractRepository::save जाँच की ContractRepository::save है, बल्कि सहेजे गए मूल्य की शुद्धता भी।

साइकिल निर्माण

मनोरंजन के लिए, अपनी परियोजना खोलें और इसके लिए देखें:

 lastIndexOf('.') 

एक उच्च संभावना के साथ, पूरी अभिव्यक्ति कुछ इस तरह दिखती है:

 String fileExtension = fileName.subString(fileName.lastIndexOf('.')); 

यही है कि कोई भी स्थिर विश्लेषक इसके बारे में चेतावनी नहीं दे सकता है, यह नई आविष्कार की गई साइकिल के बारे में है। सज्जनों, यदि आप फ़ाइल नाम / एक्सटेंशन या उससे संबंधित एक निश्चित समस्या को हल कर रहे हैं, जैसे पढ़ना / लिखना / कॉपी करना, तो 10 में से 9 मामलों में कार्य आपके समक्ष पहले ही हल हो चुका है। इसलिए, साइकिल निर्माण के साथ टाई करें और तैयार (और सिद्ध) समाधान लें:

 import org.apache.commons.io.FilenameUtils; //... String fileExtension = FilenameUtils.getExtension(fileName); 

इस मामले में, आप उस समय को बचाते हैं जो बाइक की उपयुक्तता की जांच करने पर खर्च किया जाएगा, और अधिक उन्नत कार्यक्षमता भी प्राप्त करें (दस्तावेज़ीकरण FilenameUtils::getExtension )।

या यहाँ एक कोड है जो एक फ़ाइल की सामग्री को दूसरे में कॉपी करता है:

 try { FileChannel sc = new FileInputStream(src).getChannel(); FileChannel dc = new FileOutputStream(new File(targetName)).getChannel(); sc.transferTo(0, sc.size(), dc); dc.close(); sc.close(); } catch (IOException ex) { log.error("", ex); } 

क्या हालात हमें रोक सकते हैं? उनमें से हजारों:

• गंतव्य एक फ़ोल्डर हो सकता है, एक फ़ाइल नहीं
• स्रोत एक फ़ोल्डर हो सकता है
• स्रोत और गंतव्य एक ही फ़ाइल हो सकती है
• गंतव्य नहीं बनाया जा सकता
• वगैरह वगैरह।

दुःख की बात यह है कि इसके बारे में सेल्फ-रिकॉर्डिंग का उपयोग हम सभी पहले से ही नकल के दौरान सीखते हैं।
अगर हम इसे समझदारी से करें

 import org.apache.commons.io.FileUtils; try { FileUtils.copyFile(src, new File(targetName)); } catch (IOException ex) { log.error("", ex); } 

तब चेकों का कुछ हिस्सा कॉपी करने की शुरुआत से पहले प्रदर्शन किया जाएगा, और एक संभावित अपवाद अधिक जानकारीपूर्ण होगा ( FileUtils::copyFile के स्रोत FileUtils::copyFile )।

@ नुल्लेबल / @ नोटनल की उपेक्षा

मान लीजिए कि हमारे पास एक इकाई है:

 @Entity @Getter public class UserEntity { @Id private Long id; @Column private String email; @Column private String petName; } 

हमारे मामले में, तालिका में email कॉलम को पेटनेम के विपरीत, not null रूप में वर्णित not null किया गया है। अर्थात्, हम संबंधित एनोटेशन वाले फ़ील्ड को चिह्नित कर सकते हैं:

 import javax.annotation.Nullable; import javax.annotation.NotNull; //... @Column @NotNull private String email; @Column @Nullable private String petName; 

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

उदाहरण के लिए, विकास के वातावरण उन्हें समझते हैं, और यदि, एनोटेशन जोड़ने के बाद, हम इसे इस तरह से करने की कोशिश करते हैं:

 boolean checkIfPetBelongsToUser(UserEnity user, String lostPetName) { return user.getPetName().equals(lostPetName); } 

तब "आइडिया" हमें इस संदेश के साथ खतरे से आगाह करेगा:

विधि आह्वान 'बराबर' 'NullPointerException' का उत्पादन कर सकते हैं

कोड में

 boolean hasEmail(UserEnity user) { boolean hasEmail = user.getEmail() == null; return hasEmail; } 

एक और चेतावनी होगी:

हालत 'user.getEmail () == अशक्त' हमेशा 'झूठी' है

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

यदि मेरे तर्क अनिर्णायक हैं, तो किसी भी गंभीर परियोजना के स्रोत कोड को देखें, वही "स्प्रिंग" - वे क्रिसमस ट्री की तरह एनोटेशन के साथ लटके हुए हैं। और यह एक सनकी नहीं है, बल्कि एक गंभीर आवश्यकता है।

एकमात्र दोष, यह मुझे लगता है, आधुनिक राज्य में लगातार एनोटेशन बनाए रखने की आवश्यकता है। हालाँकि, यदि आप इसे देखते हैं, तो यह एक आशीर्वाद है, क्योंकि बार-बार कोड पर लौटने से हम इसे बेहतर और बेहतर समझते हैं।

आनाकानी

इस कोड में कोई त्रुटि नहीं है, लेकिन एक अतिरिक्त है:

 Collection<Dto> dtos = getDtos(); Stream.of(1,2,3,4,5) .filter(id -> { List<Integer> ids = dtos.stream().map(Dto::getId).collect(toList()); return ids.contains(id); }) .collect(toList()); 

यह स्पष्ट नहीं है कि चाबियों की एक नई सूची क्यों बनाई जाए जिसके द्वारा खोज की जाती है, अगर यह धारा से गुजरते समय नहीं बदलती है। यह अच्छा है कि केवल 5 तत्व हैं, लेकिन अगर उनमें से 100500 हैं तो क्या होगा? और अगर getDtos विधि 100500 ऑब्जेक्ट्स (सूची में!) लौटाती है, तो इस कोड में किस तरह का प्रदर्शन होगा? कोई नहीं, इसलिए यह इस तरह बेहतर है:

 Collection<Dto> dtos = getDtos(); Set<Integer> ids = dtos.stream().map(Dto::getId).collect(toSet()); Stream.of(1,2,3,4,5) .filter(ids::contains) .collect(toList()); 

यहाँ भी:

 static <T, Q extends Query> void setParams( Map<String, Collection<T>> paramMap, Set<String> notReplacedParams, Q query) { notReplacedParams.stream() .filter(param -> paramMap.keySet().contains(param)) .forEach(param -> query.setParameter(param, paramMap.get(param))); } 

जाहिर है, inParameterMap.keySet() एक्सप्रेशन द्वारा लौटाया गया मान अपरिवर्तित है, इसलिए इसे एक चर में ले जाया जा सकता है:

 static <T, Q extends Query> void setParams( Map<String, Collection<T>> paramMap, Set<String> notReplacedParams, Q query) { Set<String> params = paramMap.keySet(); notReplacedParams.stream() .filter(params::contains) .forEach(param -> query.setParameter(param, paramMap.get(param))); } 

वैसे, ऐसे खंडों की गणना 'ऑब्जेक्ट लूप इन लूप' चेक का उपयोग करके की जा सकती है।

जब स्थैतिक विश्लेषण शक्तिहीन होता है

आठवें जावा लंबे समय से मर चुके हैं, लेकिन हम सभी प्रेम धाराएं हैं। हम में से कुछ उन्हें इतना प्यार करते हैं कि हम उन्हें हर जगह इस्तेमाल करते हैं:

 public Optional<EmailAdresses> getUserEmails() { Stream<UserEntity> users = getUsers().stream(); if (users.count() == 0) { return Optional.empty(); } return users.findAny(); } 

स्ट्रीम, जैसा कि आप जानते हैं, उस पर समाप्ति से पहले ताजा है, इसलिए हमारे कोड में users को बार-बार एक्सेस करने से एक IllegalStateException ।

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

यह मुझे लगता है कि टाइप Stream वेरिएबल्स का उपयोग करने के साथ-साथ उन्हें तर्क के रूप में पारित करना और तरीकों से वापस आना, एक माइनफील्ड में चलने जैसा है। शायद भाग्यशाली है, शायद नहीं। इसलिए एक सरल नियम: कोड में Stream<T> की किसी भी उपस्थिति की जांच की जानी चाहिए (लेकिन तुरंत कट आउट एक अच्छा तरीका है)।

सरल प्रकार

कई सुनिश्चित हैं कि boolean , int , आदि केवल प्रदर्शन के बारे में हैं। यह आंशिक रूप से सच है, लेकिन इसके अलावा, सरल प्रकार डिफ़ॉल्ट रूप से not null । यदि किसी इकाई का पूर्णांक फ़ील्ड एक स्तंभ को संदर्भित करता है जिसे तालिका में not null रूप में घोषित किया गया है, तो यह int बजाय int का उपयोग करने के लिए समझ में आता है। यह एक प्रकार का कॉम्बो है - और मेमोरी की खपत कम है, और null लिए अनावश्यक जांच के कारण कोड को सरल बनाया गया है।

वह सब है। याद रखें कि उपरोक्त सभी अंतिम सत्य नहीं है, अपने स्वयं के सिर के साथ सोचें और किसी भी सलाह के आवेदन पर सार्थक दृष्टिकोण करें।