Mga panuntunan sa code: ang kapangyarihan ng wastong pagbibigay ng pangalan, mabuti at masamang komento

Gaano kadalas mo kailangang maunawaan ang code ng ibang tao? Kapag, sa halip na ilang oras, gumugugol ka ng mga araw para lang maunawaan ang lohika ng nangyayari. Ang nakakatawa ay para sa taong nagsulat ng code na ito, ang lahat ay malinaw at napakalinaw. At ito ay hindi nakakagulat: pagkatapos ng lahat, ang perpekto o perpektong code ay isang napakalabing konsepto, dahil ang bawat developer ay may sariling pananaw sa mundo at ang code, ayon sa pagkakabanggit. Higit sa isang beses napunta ako sa isang sitwasyon kung saan ang aking kasamahan at ako ay tumingin sa parehong code at may iba't ibang opinyon tungkol sa kawastuhan at kalinisan nito. Familiar ang pakiramdam, di ba? Gayunpaman, mayroong ilang mga puntong nasubok sa oras na dapat sundin, na sa huli ay gagana sa aming kalamangan, dahil kung iiwan mo ang iyong code sa estado kung saan mo mismo gustong matanggap ito, magiging mas masaya ang mundo at mas malinis. Sa aming huling artikulo tungkol sa mga panuntunan sa pagsulat ng code (o sa halip, isang maliit na gabay), hinawakan namin ng kaunti ang mga rekomendasyon para sa pagsusulat ng system sa kabuuan at ang mga elemento nito tulad ng mga bagay, kanilang mga interface, mga klase, mga pamamaraan at mga variable. Doon ko maikling binanggit ang tamang pagpapangalan ng ilang elemento. Ngayon gusto kong pag-usapan ang tungkol dito nang eksakto, dahil ang mga tamang pangalan ay ginagawang mas madali ang pagiging madaling mabasa ng code. Isasara namin ang paksa ng tamang code sa tulong ng mga pagmuni-muni at maliliit na halimbawa ng mga komento sa code - ito ba ay mabuti o hindi napakahusay. Kaya simulan na natin.

Tamang pagpapangalan

Ang mga tamang pangalan ay nagpapabuti sa pagiging madaling mabasa ng code, nang naaayon sa pagtitipid ng oras sa familiarization, dahil mas madaling gumamit ng isang paraan kapag ang pangalan ay halos naglalarawan ng paggana nito. Dahil ang lahat ng nasa code ay binubuo ng mga pangalan (mga variable, pamamaraan, klase, file object, atbp.), ang puntong ito ay nagiging napakahalaga kapag gumagawa ng tama at malinis na code. Batay sa itaas, ang pangalan ay dapat maghatid ng kahulugan kung bakit, halimbawa, ang isang variable ay umiiral, kung ano ang ginagawa nito at kung paano ito ginagamit. Paulit-ulit kong tatandaan na ang pinakamagandang komento para sa paglalarawan ng isang variable ay ang tamang pangalan nito.

Mga Interface sa Pangalan

Ang mga interface ay karaniwang gumagamit ng mga pangalan na nagsisimula sa malaking titik at nakasulat sa camel case (CamelCase). Ito ay dating magandang kasanayan kapag nagsusulat ng isang interface upang i-prefix ito ng isang I upang italaga ito bilang isang interface (hal. IUserService), ngunit ito ay medyo pangit at nakakagambala. Sa ganitong mga kaso, mas mainam na magsulat nang wala ito (UserService), at magdagdag ng -Impl (UserServiceImpl) sa pagpapatupad nito. Well, o bilang isang huling paraan, idagdag ang prefix C (CUserService) sa pagpapatupad nito.

Mga pangalan ng klase

Tulad ng mga interface, ang mga pangalan ay naka-capitalize at gumagamit ng istilo ng kamelyo (CamelCase). Kahit anong uri ng apocalypse ang nangyayari, gaano man kabilis ang mga deadline, ngunit hindi, tandaan, ang pangalan ng isang klase ay hindi dapat maging isang pandiwa! Ang mga pangalan ng klase at bagay ay dapat na mga pangngalan at ang kanilang mga kumbinasyon (UserController, UserDetails, UserAccount, at iba pa). Hindi mo dapat ibigay ang pangalan ng bawat klase na may abbreviation ng application na ito, dahil magdaragdag lamang ito ng hindi kinakailangang kumplikado (halimbawa, mayroon kaming User Data Migration application, at magdaragdag kami ng UDM sa bawat klase - UDMUserDeatils, UDMUserAccount, UDMUserController ).

Mga pangalan ng pamamaraan

Karaniwan ang mga pangalan ng mga pamamaraan ay nagsisimula sa isang maliit na titik, ngunit gumagamit din sila ng istilo ng kamelyo (CamelCase). Sa itaas ay napag-usapan natin ang katotohanan na ang mga pangalan ng klase ay hindi dapat maging pandiwa. Narito ang sitwasyon ay diametrically kabaligtaran: ang mga pangalan ng mga pamamaraan ay dapat na mga pandiwa o ang kanilang mga kumbinasyon sa mga pandiwa: findUserById, findAllUsers, createUser, at iba pa. Kapag lumilikha ng isang pamamaraan (pati na rin ang mga variable at klase), upang maiwasan ang pagkalito, gumamit ng isang diskarte sa pagbibigay ng pangalan. Halimbawa, para maghanap ng user, ang paraan ay maaaring isulat bilang getUserById o findUserById. At isa pang bagay: huwag gumamit ng katatawanan sa mga pangalan ng mga pamamaraan, dahil maaaring hindi nila maintindihan ang biro, pati na rin kung ano ang ginagawa ng pamamaraang ito.

Mga pangalan ng variable

Sa karamihan ng mga kaso, ang mga variable na pangalan ay nagsisimula sa isang maliit na titik at ginagamit din ang Camelcase, maliban sa mga kaso kung saan ang variable ay isang global constant. Sa ganitong mga kaso, ang lahat ng mga titik ng pangalan ay nakasulat sa malalaking titik at ang mga salita ay pinaghihiwalay ng isang underscore - "_". Kapag pinangalanan ang mga variable, maaari mong gamitin ang makabuluhang konteksto para sa kaginhawahan. Sa madaling salita, kapag mayroong isang variable bilang bahagi ng isang bagay na mas malaki - halimbawa, firstName, lastName, status - sa mga ganitong kaso maaari kang magdagdag ng prefix na nagpapahiwatig ng object kung saan bahagi ang variable na ito. Halimbawa: userFirstName, userLastName, userStatus. Kailangan mo ring iwasan ang mga katulad na pangalan para sa mga variable kapag mayroon silang ganap na magkakaibang kahulugan. Mga karaniwang kasalungat para sa mga variable:

• simulan/tapos
• Una huli
• naka-lock/naka-unlock
• min/max
• susunod/nakaraan
• lumang bago
• binuksan/sarado
• nakikita/hindi nakikita
• pinagkukunan ng target
• pinagmulan/destinasyon
• taas baba

Mga maikling variable na pangalan

Kapag mayroon tayong mga variable tulad ng x o n o isang katulad nito, hindi natin agad nakikita ang intensyon ng taong nagsulat ng code. Hindi halata kung anong paraan ang nagagawa n: nangangailangan ito ng mas maalalahaning pag-iisip (at iyon ang oras, oras, oras). Halimbawa, mayroon kaming field - ang id ng responsableng user, at sa halip na ilang pangalan tulad ng x o just id, tatawagin namin itong variable na responsibleUserId, na agad na nagpapataas ng pagiging madaling mabasa at makabuluhan. Gayunpaman, ang mga maikling pangalan tulad ng n ay may lugar bilang mga lokal na pagbabago sa maliliit na pamamaraan, kung saan ang bloke ng code na may pagbabagong iyon ay ilang linya lamang ng code, at ang pangalan ng pamamaraan ay perpektong naglalarawan kung ano ang nangyayari doon. Ang isang developer, na nakakakita ng ganoong variable, ay nauunawaan ang pangalawang kahalagahan nito at napakalimitadong saklaw. Bilang resulta, mayroong ilang pag-asa sa haba ng pangalan ng variable: kung mas mahaba ito, mas global ang variable at kabaliktaran. Bilang halimbawa, isang paraan upang mahanap ang huling na-save na user ayon sa petsa:

public User findLastUser() {
   return findAllUsers().stream()
           .sorted((x, y) -> -x.getCreatedDate().compareTo(y.getCreatedDate()))
           .findFirst()
           .orElseThrow(() -> new ResourceNotFoundException("Any user doesn't exist "));
}

Dito ginagamit namin ang mga maikling pangalan na x at y upang itakda ang pag-uuri ng stream, at kalimutan ang tungkol sa mga ito.

Pinakamainam na haba

Ipagpatuloy natin ang paksa ng haba ng pangalan. Ang pinakamainam na haba ng pangalan ay nasa pagitan ng maximumNumberOfUsersInTheCurrentGroup na haba ng pangalan at n. Iyon ay, ang mga masyadong maikli ay nagdurusa mula sa isang kakulangan ng kahulugan, at ang mga masyadong mahaba ay umaabot sa programa nang hindi nagdaragdag ng pagiging madaling mabasa, at sila ay masyadong tamad na isulat ang mga ito sa bawat oras. Hindi isinasaalang-alang ang kaso sa itaas, para sa mga variable na may maikling pangalan tulad ng n, kailangan mong panatilihin ang haba sa humigit-kumulang 8-16 na mga character. Ito ay hindi isang mahigpit na panuntunan: higit pa sa isang gabay.

Maliit na pagkakaiba

Hindi ko maaaring balewalain ang mga banayad na pagkakaiba sa mga pangalan, dahil isa rin itong masamang kagawian, dahil maaari ka lang malito o gumugol ng maraming dagdag na oras sa pagpuna ng maliliit na pagkakaiba sa mga pangalan. Halimbawa, ang pagkakaiba sa pagitan ng InvalidDataAccessApiUsageException at InvalidDataAccessResourceUsageException ay mahirap makita sa isang sulyap. Gayundin, madalas na lumitaw ang maling impormasyon kapag gumagamit ng maliit na L at O, dahil madali silang malito sa 1 at 0: sa ilang mga font ang pagkakaiba ay mas halata, sa iba ay mas mababa.

Semantikong bahagi

Kailangan nating ilagay ang semantic na bahagi sa mga pangalan, ngunit huwag mag-overplay sa mga kasingkahulugan, dahil, halimbawa, ang UserData at UserInfo ay talagang may parehong kahulugan, at kailangan nating maghukay ng mas malalim sa code upang maunawaan kung anong partikular na bagay ang kailangan natin. . Iwasan ang mga salitang hindi nagbibigay kaalaman, halimbawa, firstNameString: bakit kailangan natin ang salitang string? Maaari bang maging object ng uri ng petsa ang isang pangalan? Siyempre hindi: samakatuwid, simple - firstName. Bilang halimbawa, gusto kong banggitin ang mga boolean variable, halimbawa, flagDelete. Ang salitang bandila ay walang anumang semantikong kahulugan. Mas makatwirang tawagan ito - isDelete.

Disinformation

Gusto ko ring magsabi ng ilang salita tungkol sa maling pagpapangalan. Sabihin nating mayroon tayong pangalan na userActivityList, at ang bagay na pinangalanan ay hindi sa uri ng Listahan, ngunit ilang iba pang lalagyan o custom na bagay para sa imbakan. Maaari nitong malito ang karaniwang programmer: mas mainam na tawagan ito tulad ng userActivityGroup o userActivities.

Maghanap

Ang isa sa mga kawalan ng maikli at simpleng mga pangalan ay mahirap hanapin ang mga ito sa malaking halaga ng code, dahil ano ang mas madaling mahanap: isang variable na tinatawag na pangalan o NAME_FOR_DEFAULT_USER? Siyempre, ang pangalawang pagpipilian. Ito ay kinakailangan upang maiwasan ang mga madalas na nagaganap na mga salita (mga titik) sa mga pangalan, dahil ito ay madaragdagan lamang ang bilang ng mga file na natagpuan sa panahon ng paghahanap, na hindi maganda. Nais naming ipaalala sa iyo na ang mga programmer ay gumugugol ng mas maraming oras sa pagbabasa ng code kaysa sa pagsulat nito, kaya maging maingat sa pagbibigay ng pangalan sa mga elemento ng iyong aplikasyon. Ngunit paano kung hindi mo nagawang pangalanan ito nang matagumpay? Paano kung ang pangalan ng isang pamamaraan ay hindi naglalarawan nang maayos sa paggana nito? Ito ay kung saan ito dumating sa play, ang aming susunod na item ay mga komento.

Mga komento

Walang katulad ng may-katuturang komento, ngunit walang nakakagulo sa isang module tulad ng walang kabuluhan, luma, o mapanlinlang na mga komento. Isa itong espadang may dalawang talim, di ba? Gayunpaman, hindi mo dapat ituring ang mga komento bilang isang hindi malabo na kabutihan: sa halip, bilang isang mas mababang kasamaan. Pagkatapos ng lahat, ang isang komento, sa kakanyahan nito, ay kabayaran para sa isang hindi matagumpay na ipinahayag na pag-iisip sa code. Halimbawa, ginagamit namin ang mga ito upang kahit papaano ay maiparating ang kakanyahan ng pamamaraan kung ito ay lumalabas na masyadong nakakalito. Sa ganoong sitwasyon, mas mainam na i-refactor nang tama ang code sa halip na magsulat ng mga mapaglarawang tala. Kung mas luma ang komento, mas malala, dahil ang code ay may posibilidad na lumago at nagbabago, ngunit ang komento ay maaaring manatiling pareho, at habang tumatagal ito, mas nagiging kahina-hinala ang mga talang ito. Ang mga hindi tumpak na komento ay mas masahol pa kaysa sa walang komento, dahil sila ay nalilito at nanlilinlang, na nagbibigay ng maling mga inaasahan. At kahit na mayroon kaming isang napaka nakakalito na code, sulit pa rin na huwag magkomento dito, ngunit muling isulat ito.

Mga uri ng komento

• Ang mga legal na komento ay mga komentong iniiwan sa simula ng bawat source code file para sa mga legal na dahilan, gaya ng:

  * Copyright (c) 2007, 2013, Oracle and/or its affiliates. All rights reserved.
  * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms.

• Ang mga komentong nagbibigay-kaalaman ay mga komentong nagbibigay ng paliwanag sa code (nagbibigay ng karagdagang impormasyon o layunin ng isang partikular na piraso ng code.

  Bilang halimbawa:

  /*
  * Объединяет пользователя из бд и пришедшего для обновления
  * Когда в requestUser поле пустое, оно заполняется старыми данными из foundUser
  */
  private User mergeUser(User requestUser, User foundUser) {
         return new User(
         foundUser.getId(),
         requestUser.getFirstName() == null ? requestUser.getFirstName() : foundUser.getFirstName(),
         requestUser.getMiddleName() == null ? requestUser.getMiddleName() : foundUser.getMiddleName(),
         requestUser.getLastName() == null ? requestUser.getLastName() : foundUser.getLastName(),
         requestUser.getAge() == null ? requestUser.getAge() : foundUser.getAge()
         );
         }

  Sa kasong ito, maaari mong gawin nang walang mga komento, dahil ang pangalan ng pamamaraan at ang mga argumento nito, kasama ang napaka-transparent na pag-andar, ay naglalarawan sa kanilang sarili nang maayos.

• babala na komento - isang komento na ang layunin ay bigyan ng babala ang iba pang mga developer tungkol sa mga hindi kanais-nais na kahihinatnan ng ilang aksyon (halimbawa, kung bakit ang pagsubok ay minarkahan bilang @Ignore):

  // Слишком долго отрабатывает
  // Не запускайте, если не располагаете избытком времени
  @Ignore
  @Test
  public void someIntegrationTest() {
         ……
         }

• TODO - mga komento na mga tala para sa hinaharap na kailangang gawin, ngunit sa ilang kadahilanan ay hindi maaaring gawin ngayon. Ito ay isang magandang kasanayan, ngunit kailangan pa rin silang regular na suriin upang alisin ang mga hindi nauugnay upang maiwasan ang kalat.

  Примером послужит:

  //TODO: Add a check for the current user ID (when will be created security context)
  
  @Override
  public Resource downloadFile(File file) {
         return fileManager.download(file);
         }

  Тут мы помечаем, что нужно добавить проверку юзера, который скачивает (id которого мы вытащим из security контекста) с тем, кто сохранил.

• усorвающий комментарий — комментарий, подчеркивающий важность Howого-то обстоятельства, что на первый взгляд может показаться несущественным.

  Как пример, кусочек метода, заполняющий тестовую БД, некими скриптами:

  Stream.of(IOUtils.resourceToString("/fill-scripts/" + x, StandardCharsets.UTF_8)
         .trim()
         .split(";"))
         .forEach(jdbcTemplate::update);
  // Вызов trim() очень важен, убирает возможные пробелы в конце скрипта
  // чтобы при считке и разбивке на отдельные requestы не было пустых

• javaDoc — комментарии, которые описывают API определенного функционала для общего пользования. Наверное, самые полезные комментарии, так How с documentированным API в разы легче работать, но они также могут устаревать, How и любые другие. Поэтому не забываем, что главный вклад в documentацию вносится не комментариями, а хорошим codeом.

  Пример вполне обычного метода обновления пользователя:

  /**
  * Обновляет передаваемые поля для пользователя по id.
  *
  * @param id  id обновляемого пользователя
  * @param user пользователь с заполненными полями для обновления
  * @return обновленный пользователь
  */
         User update(Long id, User user);

Плохие сценарии комментариев

• бормочущий комментарий — комментарии, которые обычно пишут на скорую руку, смысл которых понятен только разработчику, писавшего их, так How только он видит ту ситуацию с теми нюансами, на которые он и ссылается.

  Рассмотрим данный пример:

  public void configureSomeSystem() {
         try{
         String configPath = filesLocation.concat("/").concat(CONFIGURATION_FILE);
         FileInputStream stream = new FileInputStream(configPath);
         }  catch (FileNotFoundException e) {
         //В случае отсутствия конфигурационного file, загружается конфигурация по умолчанию
        }
  }

  Кто загружает эти настройки? Были ли они загружены ранее? Метод предназначен для перехвата исключений и вызова дефолтных настроек? Слишком много вопросов возникает, ответы на которые можно получить лишь углубившись в изучение других частей системы.

• избыточный комментарий — комментарий, который не несёт смысловой нагрузки, так How и так понятно что происходит в заданном участке codeа (он читается не проще, чем code).

  Смотрим пример:

  public class JdbcConnection{
  public class JdbcConnection{
     /**
      * Журнальный компонент, связанный с текущим классом
      */
     private Logger log = Logger.getLogger(JdbcConnection.class.getName());
  
     /**
      * Создаёт и возвращает connection с помощью входящих параметров
      */
     public static Connection buildConnection(String url, String login, String password, String driver) throws Exception {
         Class.forName(driver);
         connection = DriverManager.getConnection(url, login, password);
         log.info("Created connection with db");
         return connection;
     }

  Какой смысл таких комментариев, если мы и так всё прекрасно видим

• недостоверные комментарии — комментарии, не соответствующие истине и лишь вгоняющие в заблуждение (дезинформирующие). Как например:

  /**
  * Вспомогательный метод, закрывает соединение со сканером, если isNotUsing истинно
  */
  private void scanClose(Scanner scan, boolean isNotUsing) throws Exception {
     if (!isNotUsing) {
         throw new Exception("The scanner is still in use");
     } scan.close();
  }

  What в этом комменте не так? А то, что он немножко врёт нам, ведь соединение закрывается, если isNotUsing = false, но ниHow не наоборот, How нам вещает пометка.

• обязательные комментарии — комментарии, которые считают обязательными (Javadoc), но кои по факту иногда бывают излишне нагромождающими, недостоверными и ненужными (нужно задуматься, а нужны ли здесь такие комментарии).

  Пример:

  /**
  *  Creation пользователя по переданным параметрам
  * @param firstName Name созданного пользователя
  * @param middleName среднее Name созданного пользователя
  * @param lastName фамorя созданного пользователя
  * @param age возраст созданного пользователя
  * @param address addressс созданного пользователя
  * @return пользователь который был создан
  */
  User createNewUser(String firstName, String middleName, String lastName, String age, String address);

  Смогли бы вы понять, что делает метод без этих комментариев? Скорее всего да, поэтому комментарии в этом случае стают бессмысленными.

• журнальные комментарии — комментарии, которые иногда добавляют в начало модуля, при каждом его редактировании (что-то вроде журнала вносимых изменений).

  /**
  *  Записи ведутся с 09 января 2020;
  **********************************************************************
  *  09.01.2020  : Обеспечение соединения с БД с помощью Jdbc Connection;
  *  15.01.2020  : Добавление интерфейсов уровня дао для работы с БД;
  *  23.01.2020  : Добавление интеграционных тестов для БД;
  *  28.01.2020  : Имплементация интерфейсов уровня дао;
  *  01.02.2020  : Разработка интерфейсов для сервисов,
  *  согласно требованиям прописанным в user stories;
  *  16.02.2020  : Имплементация интерфейсов сервисов
  *  (реализация бизнес логики связанной с работой БД);
  *  25.02.2020  : Добавление тестов для сервисов;
  *  08.03.2020  : Празднование восьмого марта(Миша опять в хлам);
  *  21.03.2020  : Рефакторинг сервис слоя;
  */

  Когда-то этот проход был оправдан, но с появлением систем управления исходным codeом (например — Git), это стало лишним нагромождением и усложнением codeа.

• комментарии ссылки на авторов — комментарии, преднаmeaningм которых является, указание человека, писавшего code, чтобы можно было связаться и обсудить, How что и зачем:

  * @author  Bender Benderovich

  Опять же, системы контроля версий прекрасно запоминают, кто и когда добавил данный code, и подобный подход излишен.

• ang commented code ay code na na-comment out para sa isang dahilan o iba pa. Isa sa mga pinakamasamang gawi, dahil nagkomento ka at nakalimutan mo, at ang ibang mga developer ay walang lakas ng loob na tanggalin ito (paano kung ito ay isang bagay na mahalaga).

  //    public void someMethod(SomeObject obj) {
  //    .....
  //    }

  Dahil dito, naipon ito na parang basura. Sa anumang pagkakataon ay hindi dapat iwanan ang naturang code. Kung talagang kailangan mo ito, huwag kalimutan ang tungkol sa bersyon ng control system.

• Ang mga hindi halatang komento ay mga komentong naglalarawan ng isang bagay sa isang hindi kinakailangang kumplikadong paraan.

  /*
      * Начать с массива, размер которого достаточен для хранения
      * всех byteов данных (плюс byteы фильтра) с запасом, плюс 300 byte
      * для данных заголовка
      */
  this.dataBytes = new byte[(this.size * (this.deep + 1) * 2)+300];

  Dapat ipaliwanag ng isang komento ang code, hindi kailangan ng paliwanag mismo. Anong meron dito? Ano ang "filter bytes"? Ano ang kinalaman ng +1 dito? Bakit eksaktong 300?

Kung magpasya kang magsulat ng mga komento, narito ang ilang tip para sa paggamit ng mga ito:

1. Gumamit ng mga istilong madaling mapanatili: ang pagpapanatili ng mga istilong masyadong magarbong at kakaiba ay maaaring nakakainis at nakakaubos ng oras.
2. Huwag gumamit ng mga komento sa dulo ng mga linya na tumutukoy sa mga solong linya: lumilikha ito ng malaking tumpok ng mga komento, at mahirap na magkaroon ng isang nagpapahayag na komento para sa bawat linya.
3. Kapag gumagawa ng komento, subukang sagutin ang tanong na "bakit" sa halip na "paano."
4. Iwasan ang mga pagdadaglat. Tulad ng sinabi ko sa itaas, hindi namin kailangan ng paliwanag para sa komento: ang komento ay ang paliwanag.
5. Maaari mong gamitin ang mga komento upang markahan ang mga yunit ng pagsukat at ang hanay ng mga katanggap-tanggap na halaga.
6. Maglagay ng mga komento malapit sa code na inilalarawan nila.

Bilang resulta, nais ko pa ring ipaalala sa iyo: ang pinakamahusay na mga komento ay ang kawalan ng komento, at sa halip na ito, wastong pagpapangalan sa application. Bilang isang patakaran, kadalasan ay gagawa na kami ng handa na code, pinapanatili at palawakin ito. Ito ay higit na maginhawa kapag ang code na ito ay madaling basahin at maunawaan, dahil ang masamang code ay humahadlang, naglalagay ng isang spoke sa mga gulong, at pagmamadali ay ang tapat na kasama nito. At ang mas masamang code na mayroon tayo, mas maraming bumababa ang pagganap, kaya kailangan nating mag-refactor paminsan-minsan. Ngunit kung sa simula pa lang ay susubukan mong magsulat ng code kung saan ang mga kasunod na developer ay hindi nais na mahanap ka at patayin ka, pagkatapos ay kakailanganin mong refactor ito nang mas madalas. Ngunit ito ay kinakailangan pa rin, dahil ang mga kondisyon at kinakailangan para sa produkto ay patuloy na nagbabago, na pupunan sa pamamagitan ng pagdaragdag ng mga karagdagang koneksyon, at walang pagtakas mula dito. Sa wakas, mag-iiwan ako ng ilang mga kagiliw-giliw na link para makilala mo ang paksang ito dito , dito at dito , sa palagay ko iyon lang para sa akin ngayon, salamat sa lahat ng nagbabasa))