Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

Ralex. We do the work.
На рынке с 1999го года. Средняя ценовая категория. Ориентация на эффективность решений.
Ознакомтесь с нашим портфолио
Узнайте больше о услугах
Свяжитесь с нами:
E-mail: [email protected]
Tel: (044) 587 - 84 - 78
Custom web design & дизайн и разработка сайта "под ключ"
Креативный, эффективный дизайн. Система управления сайтом (СУС).
Custom flexible разработка систем электронной коммерции
Система e-commerce разрабатывается под индивидуальные потребности. Гибкая функциональность.
Search Engine Optimzation & оптимизация под поисковые системы (SEO)
Постоянная оптимизация и мониторинг сайта в поисковых системах. Достигаем результата быстро и эффективно
Custom logo design & дизайн логотипа и фирменного стиля
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.
профессиональная рекламная фотография
креативно, смело, качественно
Custom logo design & рекламный креатив. дизайн рекламы
Многолетний опыт. Огромное портфолио. Уникальное предложение и цена.

Автоматизація для людей: Очищаємо скрипти збірки від запахів

  1. Серія контенту:
  2. Цей контент є частиною серії: Автоматизація для людей
  3. Про цю серії статей
  4. Уникаємо аромату збірки-тільки-в-IDE
  5. Малюнок 1. IDE зв'язку в збірці
  6. Копіювати-і-вставити - як дешеві парфуми
  7. Лістинг 1. Скрипт в Ant для операцій копіювати-і-вставити
  8. Лістинг 2. Скрипт в Ant для операцій копіювати-і-вставити
  9. Присмак довгих об'єктів
  10. Лістинг 3. Довгий об'єкт
  11. Лістинг 4. Витяг об'єктів
  12. Великі файли збірки також мають сильний запах
  13. Малюнок 2. Поділ файлів збірки
  14. Якщо не чистити
  15. Лістинг 5. Зробіть чистку
  16. Сморід від сильної закодованість
  17. Лістинг 6. Сильно закодовані значення
  18. Лістинг 7. Використання властивостей
  19. Успішна збірка, коли тести погано пахнуть (або невдало завершуються)
  20. Лістинг 8. Запах: вдала збірка, хоча тести провалилися
  21. Лістинг 9. Тести завершують збірку з помилкою
  22. Запах чарівної машини
  23. Малюнок 3. Чарівна машина
  24. Сморід від поганого стилю
  25. Ніколи ще збірки не пахли так ароматно
  26. Ресурси для скачування

Наша взаимовыгодная связь https://banwar.org/

Автоматизація для людей

Практики створення узгоджених, повторюваних і легко підтримуваних збірок

Серія контенту:

Цей контент є частиною # з серії # статей: Автоматизація для людей

https://www.ibm.com/developerworks/ru/views/global/libraryview.jsp?series_title_by=Автоматизация+для+людей

Слідкуйте за виходом нових статей цієї серії.

Цей контент є частиною серії: Автоматизація для людей

Слідкуйте за виходом нових статей цієї серії.

Мені не подобається термін "запах", коли мова йде про щось, пов'язаним з кодом. Дивно говорити людиноподібними термінами про бітах і байтах. Справа не в тому, що слово "запах" неточно відображає ознаки, що вказують, що код неправильний; просто звучить кумедно. Незважаючи на своє невдоволення, я буду саме так описувати збірки програм, тому що, чесно кажучи, велика кількість скриптів, які я бачив за багато років, смерділи.

Часто навіть великі програмісти відчувають труднощі при складанні; таке трапляється, якщо вони недавно дізналися як писати процедурний код - написання великих монолітних білд-файлів, копіювати-і-вставляти скрипт-код, складно за допомогою коду задавати атрибути і т.д. Мене завжди дивувало чому так виходить (може бути тому що збірка не компілюється в щось, що споживач міг би з часом використовувати?) Однак, всі ми знаємо, що збірка - основний момент в створенні коду, який споживач буде використовувати, і якщо ці скрипти є одним великим кулею смороду, створення програм швидко перетворюється в випробування.

На щастя, ви можете з легкістю застосовувати цілий ряд практик для збірки (буде це Ant, Maven або навіть що-небудь власне), які матимуть велике значення для того, щоб збірка була узгоджена, повторювана і легко підтримувана. Щоб швидко навчитися створювати кращі скрипти для збірки, треба подивитися, як не варто їх створювати, зрозуміти, чому не варто так робити, і потім подивитися правильний спосіб створення. У даній статті я застосовую саме такий підхід. Я поясню наступні 9 запахів збірки, які ви повинні уникати, чому ви повинні їх уникати і як їх усунути:

  • Збірка тільки в IDE
  • Копіювати-і-вставити
  • довгі об'єкти
  • Великі файли збірки
  • Не чистіть
  • Сильно закодовані значення
  • Успішна збірка при неуспішних тестах
  • чарівні машини
  • недолік стилю
Про цю серії статей

Як і всі розробники я працюю, щоб автоматизувати процеси для користувачів; але більшість з нас не помічає можливість автоматизувати свої власні процеси розробки. З цієї точки зору серія статей Автоматизація для людей присвячена розширенню практичного застосування програм автоматизації процесів розробки і навчає коли і як успішно застосовувати автоматизацію.

Хоча цей список не претендує бути всеосяжним, він представляє більшість запахів, які я нарахував за роки, проведені за читанням і написанням сценаріїв. Деякі інструменти, наприклад Maven, створені, щоб керувати більшістю робіт, пов'язаних зі складанням. Але багато хто з перерахованих помилок можуть виникнути незалежно від того, яким інструментом ви користуєтеся.

Уникаємо аромату збірки-тільки-в-IDE

Збірка-тільки-в-IDE відрізняється тим, що вона може виконуватися тільки в IDE розробника і на жаль це схоже найпоширеніший запах збірки. Проблема збирання-тільки-в-IDE відноситься до типу "на моїй машині працює", коли програма працює в середовищі розробника і не в якійсь іншій. Що ще ... через те, що збирання-тільки-в-IDE погано автоматизуються, вони з великими труднощами інтегруються в середу Безперервною Інтеграції (Continuous Integration). По суті в більшості випадків такі збірки неможливо атоматізіровать без втручання людини.

Якщо бути до кінця відвертим, IDE варто використовувати для виконання зборки, але ваша IDE не повинна бути єдиною річчю, яка може здійснювати збірку програмного забезпечення. Зокрема повністю запрограмована збірка дозволяє команді використовувати різні IDE, тому що будуть визначені зв'язки між IDE і складанням і ніяких інших доступних шляхів, як показано на малюнку 1:

Малюнок 1. IDE зв'язку в збірці

Збірка-толькл-в-IDE перешкоджає автоматизації, і єдиний спосіб позбутися від цього смороду - зробити скріптуемую збірку. На цю тему є досить документації і безліч книг (см. ресурси ), А з такими проектами як Maven дуже просто визначити збірку прямо з робочої версії. У будь-якому випадку, збирайте свою платформу для збірки і зробіть свій проект скріптуемим якомога швидше.

Копіювати-і-вставити - як дешеві парфуми

Дублювання коду є спільною проблемою для програмних проектів. Насправді навіть популярні проекти з відкритим кодом продубльовані на 20-30%. І на скільки дублювання коду ускладнює його підтримку, на стільки ж ускладнюється можливості запуску програм збірки. Уявіть, наприклад, що вам треба встановити посилання на певні файли за допомогою класу fileset в Ant, як показано в лістингу 1:

Лістинг 1. Скрипт в Ant для операцій копіювати-і-вставити
<Fileset dir = "./ brewery / src"> <include name = "** / *. Java" /> <exclude name = "** / *. Groovy" /> </ fileset>

Якщо вам треба буде звернутися до цього списку файлів ще де-небудь, скажімо для компіляції, перевірки або створення документації, ви можете використовувати той же fileset в декількох місцях, і якщо далі вам треба буде змінити що-небудь в fileset (припустимо, виключити файли .groovy), вам вже не доведеться робити зміни в декількох місцях. Насправді, це не легко підтримуване рішення, однак, це просто виправити.

Клас patternset в Ant, показаний в лістингу 2, дозволяє мені послатися на логічне ім'я, яке представляє потрібні мені файли. Тепер, коли мені треба додати (або видалити) додаткові файли вfileset, я буду робити це тільки один раз.

Лістинг 2. Скрипт в Ant для операцій копіювати-і-вставити
<Patternset id = "sources.pattern"> <include name = "** / *. Java" /> <exclude name = "** / *. Groovy" /> </ patternset> ... <fileset dir = " ./brewery/src "> <patternset refid =" sources.pattern "/> </ fileset>

Цей прийом знаком для тих, хто має досвід об'єктів-орієнтованого програмування: замість того, щоб визначати одну і ту ж логіку в кожному класі, зазвичай таку логіку поміщають в метод, який можна викликати в будь-якому місці. Потім треба підтримувати цей метод тільки в одному місці, обмежуючи потік помилок і спрощуючи повторне використання.

Присмак довгих об'єктів

У своїй книзі Refactoring Мартін Фоулер (Martin Fowler) описує код з Довгими методами з досить приємним запахом так: "ніж довжині процедура, тим складніше її зрозуміти." Довгі методи, по суті, тягнуть занадто багато зобов'язань. Коли приходить час збирання, запах збірки Довгих Об'єктів представляє скрипт, який складніше зрозуміти і підтримувати. У лістингу 3 показаний відносно довгий об'єкт:

Лістинг 3. Довгий об'єкт
<Target name = "run-tests"> <mkdir dir = "$ {classes.dir}" /> <javac destdir = "$ {classes.dir}" debug = "true"> <src path = "$ {src .dir} "/> <classpath refid =" project.class.path "/> </ javac> <javac destdir =" $ {classes.dir} "debug =" true "> <src path =" $ {test. unit.dir} "/> <classpath refid =" test.class.path "/> </ javac> <mkdir dir =" $ {logs.junit.dir} "/> <junit fork =" yes "haltonfailure =" true "dir =" $ {basedir} "printsummary =" yes "> <classpath refid =" test.class.path "/> <classpath refid =" project.class.path "/> <formatter type =" plain "usefile = "true" /> <formatter type = "xml" usefile = "true" /> <batchtest fork = "yes" todir = "$ {logs.junit.dir}"> <fileset dir = "$ {test.unit .dir} "> <patternset refid =" test.sources.pattern "/> </ fileset> </ batchtest> </ junit> <mkdir dir =" $ {reports.junit.dir} "/> <junitreport todir = "$ {reports.junit.dir}"> <fileset dir = "$ {logs.junit.dir}"> <include name = "TEST - *. xml" /> <include name = "TEST - *. txt" /> </ fileset> <report format = "frames" todir = "$ {reports.junit.dir}" /> </ junitreport> </ target>

Цей довгий об'єкт (повірте, я бачив набагато довше) представляє чотири різних процесу: компіляція вихідного коду, компіляція тестів, запуск тестів JUnit і створення звіту JUnitReport. Ціла купа обов'язків, не кажучи вже про додавання до складності всього того XML в одному місці. Цей об'єкт можна розбити на чотири - незалежних, логічних, як показано в лістингу 4:

Лістинг 4. Витяг об'єктів
<Target name = "compile-src"> <mkdir dir = "$ {classes.dir}" /> <javac destdir = "$ {classes.dir}" debug = "true"> <src path = "$ {src .dir} "/> <classpath refid =" project.class.path "/> </ javac> </ target> <target name =" compile-tests "> <mkdir dir =" $ {classes.dir} "/ > <javac destdir = "$ {classes.dir}" debug = "true"> <src path = "$ {test.unit.dir}" /> <classpath refid = "test.class.path" /> </ javac> </ target> <target name = "run-tests" depends = "compile-src, compile-tests"> <mkdir dir = "$ {logs.junit.dir}" /> <junit fork = "yes" haltonfailure = "true" dir = "$ {basedir}" printsummary = "yes"> <classpath refid = "test.class.path" /> <classpath refid = "project.class.path" /> <formatter type = " plain "usefile =" true "/> <formatter type =" xml "usefile =" true "/> <batchtest fork =" yes "todir =" $ {logs.junit.dir} "> <fileset dir =" $ { test.unit.dir} "> <patternset refid =" test.sources.pattern "/> </ fileset> </ batchtest> </ junit> </ target> <target name =" run-test-report "depends = "compile-src, compile-tests, run-tests"> <mkdir dir = "$ {reports.junit.dir}" /> <ju nitreport todir = "$ {reports.junit.dir}"> <fileset dir = "$ {logs.junit.dir}"> <include name = "TEST - *. xml" /> <include name = "TEST- * .txt "/> </ fileset> <report format =" frames "todir =" $ {reports.junit.dir} "/> </ junitreport> </ target>

Як ви можете бачити, завдяки тому, що кожен об'єкт має одну задачу, код в лістингу 4 став набагато простіше. Поділяючи об'єкти в залежності від мети, ви можете спростити і тим самим забезпечити можливість використання об'єктів в різних компонентах, тобто повторно використовувати, якщо необхідно.

Великі файли збірки також мають сильний запах

Фоулер також визначає Великі Класи як запах коду. У скриптах збірки схожий запах мають великі файли збірки, які дико складно прочитати. Непросто зрозуміти які об'єкти що роблять і які між ними зв'язку. Це знову ж таки вносить труднощі в підтримку; більш того, у величезних файлах збірки часто зустрічається операція вирізати-та-вставити.

Щоб зменшити розмір файлів збірки, ви можете знайти частини скрипта, які логічно співвідносяться і виділити ці частини в більш дрібні файли збірки, які будуть виконуватися одним загальним файлом збірки (наприклад, в Ant ви можете викликати інші файли збірки за допомогою програмного модуля ant).

Найчастіше я розбиваю скрипти збірки за допомогою функції ядра і перевіряю, що вони можуть виконуватися як автономні (stand-alone) скрипти (подумайте про компонентний поданні для збірки). Наприклад, я хочу визначити чотири типи тестів розробки в моїй збірки в Ant: елемент, компонент, система і функціональність. Далі я також хочу запустити чотири типи автоматичних інспектора: стандарт написання коду, аналіз зв'язків, вплив несправностей і складність коду. Я поділяю реалізацію тестів і інспекторів в два різних файлу збірки, замість того, щоб помістити виконання цих тестів і інспекторів в один монолітний скрипт збірки (разом з компіляцією, інтеграцією бази даних і розгортки), див. Рисунок 2:

Малюнок 2. Поділ файлів збірки

Більш дрібні і лаконічні файли збірки набагато легше підтримувати і розуміти; по суті, цей же шаблон справедливий і для коду. Схоже, у нас є шаблон, правда?

Якщо не чистити

Складання, які в обов'язковому порядку не скорочують основні пропозиції, - це бомба уповільненої дії. Наприклад, якщо ваша збірка не скорочує прості речення, такі як видалення раніше створених файлів зі старими даними, помилка може виникнути з збереженого файлу з попередньою збірки. Або можливо (що ще гірше), збірка може виявитися успішною, через файлів попередньої збірки.

На щастя, ось воно рішення: ви можете з легкістю позбутися пропозицій, видаливши всі створені директорії і файли з будь-якої попередньої збірки. Це просто дію скоротить пропозиції і дозволить зробити точним статус успіху чи неуспіху. Лістинг 5 демонструє приклад чистки середовища збірки за допомогою delete в Ant для видалення будь-яких файлів і директорій, використаних в попередній збірці:

Лістинг 5. Зробіть чистку
<Target name = "clean"> <delete dir = "$ {logs.dir}" quiet = "true" failonerror = "false" /> <delete dir = "$ {build.dir}" quiet = "true" failonerror = "false" /> <delete dir = "$ {reports.dir}" quiet = "true" failonerror = "false" /> <delete file = "cobertura.ser" quiet = "true" failonerror = "false" / > </ target>

Окремі файли з більш ранніх збірок можуть стати причиною зайвого головного болю. Зробіть собі послугу і завжди видаляйте будь-які створені артефакти, перш ніж розпочати складання.

Сморід від сильної закодованість

Як прийом копіювати-і-вставити, так і сильна закодованість значень заважає повторному використанню. Коли скрипти збірки містять сильно закодовані значення, якщо який-небудь аспект треба модифікувати, вам доведеться змінювати це значення в декількох місцях. Або ще гірше, ви можете пропустити в одному місці і отримаєте невловиму помилку, пов'язану з помилкою в значенні. Більш того, якщо ви підете моєю порадою і будете використовувати множинні скрипти збірки, сильно закодовані значення стануть основною проблемою в підтримці збірки. Повірте мені в цьому!

Для прикладу в лістингу 6 модуль run-simian має кілька сильно закодованих шляхів і значень, а саме директорію _reports:

Лістинг 6. Сильно закодовані значення
<Target name = "run-simian"> <taskdef resource = "simiantask.properties" classpath = "simian.classpath" classpathref = "simian.classpath" /> <delete dir = "./_ reports" quiet = "true" / > <mkdir dir = "./_ reports" /> <simian threshold = "2" language = "java" ignoreCurlyBraces = "true" ignoreIdentifierCase = "true" ignoreStrings = "true" ignoreStringCase = "true" ignoreNumbers = "true" ignoreCharacters = "true"> <fileset dir = "$ {src.dir}" /> <formatter type = "xml" toFile = "./_ reports / simian-log.xml" /> </ simian> <xslt taskname = " simian "in =" ./_ reports / simian-log.xml "out =" ./_ reports / Simian-Report.html "style =" ./_ config / simian.xsl "/> </ target>

У мене будуть труднощі з сильно закодованої Директорією _reports, якщо я вирішу покласти звіти Simian в іншу директорію; до того ж якщо інші інструменти використовують цю директорію де-небудь в скрипті, хтось міг цілком написати цю назву з помилкою, через що звіти з'являться в різних директоріях. Для простоти і зручності я раджу визначати властивість значення, яке буде вказувати на директорію. Тоді по всьому скрипту я можу послатися на це властивість, значить і зміни треба буде зробити лише в одному місці. Лістинг 7 показує перероблений run-simian:

Лістинг 7. Використання властивостей
<Target name = "run-simian"> <taskdef resource = "simiantask.properties" classpath = "simian.classpath" classpathref = "simian.classpath" /> <delete dir = "$ {reports.simian.dir}" quiet = "true" /> <mkdir dir = "$ {reports.simian.dir}" /> <simian threshold = "$ {simian.threshold}" language = "$ {language.type}" ignoreCurlyBraces = "true" ignoreIdentifierCase = "true" ignoreStrings = "true" ignoreStringCase = "true" ignoreNumbers = "true" ignoreCharacters = "true"> <fileset dir = "$ {src.dir}" /> <formatter type = "xml" toFile = "$ {reports.simian.dir} / $ {simian.log.file} "/> </ simian> <xslt taskname =" simian "in =" $ {reports.simian.dir} / $ {simian.log.file} "out =" $ {reports.simian.dir} / $ {simian.report.file} "style =" $ {config.dir} / $ {simian.xsl.file} "/> </ target>

Сильно закодовані значення не сприяють гнучкості, вони перешкоджають їй. Досить просто сильно закодувати з'єднання до бази даних в String в своєму вихідному коді, ви також повинні уникати сильно закодованих речей на зразок шляхів в скриптах збірки.

Успішна збірка, коли тести погано пахнуть (або невдало завершуються)

Збірка - це щось більше ніж просто компіляція вихідного коду, вона також може включати виконання автоматичних тестів розробників, і якщо ви хочете зберегти свою програмну функціональність, не дозволяйте жодному невдало завершеному тесту закрастися в збірку. А все ж, в чому сенс тестів, якщо вони все одно не можуть підтвердитися?

У лістингу 8 міститься приклад з таким запахом. Зверніть увагу, що атрибут haltonfailure в завданні junit в Ant встановлений на false (це його значення за замовчуванням). Це означає, що збірка не завершиться з помилкою, навіть якщо один з тестів JUnit провалиться.

Лістинг 8. Запах: вдала збірка, хоча тести провалилися
<Junit fork = "yes" haltonfailure = "false" dir = "$ {basedir}" printsummary = "yes"> <classpath refid = "test.class.path" /> <classpath refid = "project.class.path" /> <formatter type = "plain" usefile = "true" /> <formatter type = "xml" usefile = "true" /> <batchtest fork = "yes" todir = "$ {logs.junit.dir}"> <fileset dir = "$ {test.unit.dir}"> <patternset refid = "test.sources.pattern" /> </ fileset> </ batchtest> </ junit>

Є пара підходів, щоб уникнути цього запаху. Перший дуже простий - встановити атрибут haltonfailure значення true. Це вбереже збірку від успішного завершення, якщо який-небудь тест провалиться.

Єдине, що мені не подобається в цьому рішенні, це що я не можу бачити який відсоток тестів не завершилися успішно і всю картину цілком. Тому другий підхід полягає в установці властивості, якщо який-небудь з тестів провалився. Потім я налаштовую Ant, щоб він завершував з помилкою збірку, коли він виконає всі тести. Обидва підходи будуть працювати. У лістингу 9 показаний другий спосіб з використанням властивості tests.failed:

Лістинг 9. Тести завершують збірку з помилкою
<Junit dir = "$ {basedir}" haltonfailure = "false" printsummary = "yes" errorProperty = "tests.failed" failureproperty = "tests.failed"> <classpath> <pathelement location = "$ {classes.dir}" /> </ classpath> <batchtest fork = "yes" todir = "$ {logs.junit.dir}" unless = "testcase"> <fileset dir = "$ {src.dir}"> <include name = "* * / * Test * .java "/> </ fileset> </ batchtest> <formatter type =" plain "usefile =" true "/> <formatter type =" xml "usefile =" true "/> </ junit> <fail if = "tests.failed" message = "Test (s) failed." />

Складання, яким вдалося пройти, дають помилкове відчуття безпеки. Якщо провалилися тести, не буде успішною і сама збірка: краще раніше розібратися з проблемою, ніж пізно вночі, коли вам краще поспати.

Запах чарівної машини

З усіх запахів, що покривають статтю, цей можливо самий смердючий. Чарівні машини - це одні-з чарівних частин апаратного забезпечення, які можуть здійснювати збірку тільки на програмах даної компанії. Цей сценарій не такий штучний, як могло б здатися. Я зустрічався з такими майстрами (wizard) -чудовіщамі кілька разів за свою кар'єру. Такі машини перетворюються в демонів, хоча б коли губляться зв'язку.

Легко бачити, як нормальна машина в інфраструктурі компанії може стати чарівною: з часом розробники ненавмисно додають важкі зв'язку в скрипт машини, роблять посилання на повному обсязі доступні шляхи директорій або навіть встановлюють інструменти, які є тільки на даній машині, що мало-помалу заважає запускати збірку на інших машинах. Для прикладу погляньте на малюнок 3:

Малюнок 3. Чарівна машина

Сильно закодовані посилання на машині, шляхи, в які входять певні диски (такі як С :), і певні кошти на машині - все це червоні прапори, які зачаровують машину. Як тільки ви побачите посилання на диск С: або виклик особливого інструменту (наприклад, grep), змінюйте скрипт негайно. Якщо ви зловили себе на думці, що "директорія C: \ Program Files \ є на будь-якій машині" або щось на зразок того, подумайте ще раз.

Сморід від поганого стилю

Як і стиль програмування в основних мовах, тут є такі ж припущення при побудові скриптів збірки. Коли вибираєте стиль програмування для скриптів збірки, врахуйте наступне:

  • імена властивостей
  • імена об'єктів
  • імена директорій
  • імена для змінних середовища
  • структуроване розташування тексту
  • довжина ліній

Особисто я вважаю за краще використовувати правила інших мов на скільки це можливо, коли працюю зі стилем. На щастя, група з кількох людей створили ресурс Елементи стилю в Ant (див. ресурси ). У цьому документі автори описують правила такі як назва об'єктів з використанням нижнього регист і розділової точкою, довжину рядків і розташування тексту. Який би ресурс ви не вибрали, дотримання правил стилістики допоможе вам зробити легко підтримувані файли збірки на довго.

Ніколи ще збірки не пахли так ароматно

Я можу спокійно ставитися до запаху дешевих парфумів, однак є річ, яку я не виношу, якщо говорити людиноподібними термінами, - це аромат підтримуються скриптів збірки. Як смердючий код з часом стане вам дуже дорого, то ж буде з погано спроектованими збірками. Якщо в повітрі висить дух від неузгоджених, неповторним і насилу підтримуваних збірок, знайдіть час, щоб це переробити. І ваша середовище розробки буде пахнути як троянди.

Ресурси для скачування

Схожі тими

  • оригінал статті Automation for the people: Remove the smell from your build scripts .
  • Apache Ant : Мати платформи Java для збірки.
  • Maven : Потужна платформа, що використовує краще від Ant.
  • Елементи стилю в Ant : Програмування скриптів збірки в Ant.
  • " Управління проектом: Maven робить це простіше "(Charles Chan, developerWorks, квітень 2003): Java розробник, Чарльз Чен, розповідає про можливості Maven і проведе вас по всіх етапах установки проекту Maven.
  • " Чарівна машина AntiPattern "(Testearly.com, липень 2006): докладніше про запах чарівних машин.
  • " 10 поганих порад по збірці - Частина I "(Testearly.com, липень 2006): докладніше про поганий звичкою сильно закодувати значення.
  • " Перетворення файлу збірки "(Testearly.com, березень 2006): почитайте про переміщення чарівних чисел з технікою символьних констант в дії.
  • " Автоматизація складання і процес тестування "(Erik Hatcher, developerWorks, серпень 2001): дізнайтеся, як використовувати Ant для збірки і тестування свого програмного забезпечення.
  • " 15 найкращих рад в Ant "(Eric Burke, OnJava, грудень 2003): ефективні способи використання інструментарію Ant для збірки.
  • Зона технологій Java : Сотні статей про кожному аспекті Java програмуванні.

Підпішіть мене на ПОВІДОМЛЕННЯ до коментарів

Jsp?
Може бути тому що збірка не компілюється в щось, що споживач міг би з часом використовувати?
Схоже, у нас є шаблон, правда?
А все ж, в чому сенс тестів, якщо вони все одно не можуть підтвердитися?
Категории
  • Биология
  • Математика
  • Краеведению
  • Лечебная
  • Наука
  • Физике
  • Природоведение
  • Информатика
  • Новости

  • Новости
    https://banwar.org/
    Наша взаимовыгодная связь https://banwar.org/. Запустив новый сайт, "Пари Матч" обещает своим клиентам незабываемый опыт и возможность выиграть крупные суммы.


    Наши клиенты
    Клиенты

    Быстрая связь

    Тел.: (044) 587-84-78
    E-mail: [email protected]

    Имя:
    E-mail:
    Телефон:
    Вопрос\Комментарий: