Меню

Лабораторные или Полевые ?

|

В опубликованной только что на sapland статье "Классификация отраслевых решений" есть слабое место, за которое конечно сразу зацепился внимательный читатель. Деля разработки на лабораторные и полевые я ни чего не доказывая объявил, что лабораторные лучше. Пришло время держать ответ.

В опубликованной только что на sapland статье "Классификация отраслевых решений" есть слабое место, за которое конечно сразу зацепился внимательный читатель. Деля разработки на лабораторные и полевые я ни чего не доказывая объявил, что лабораторные лучше. Пришло время держать ответ.

Чуть раньше, в статье "Замкнутый цикл производства пустых фантиков" я рассказывал про проблемы как раз полевого отраслевого решения (правда термин "полевое" тогда еще отсутствовал). Держа это в голове и сосредоточившись на разработке классификаций, я упустил из виду доказательство. Исправляюсь:

Вообще то ИТ системы не так сложны как это кажется. В их основе лежит арифметика с минимальными вкраплениями теории множеств (структуры баз данных). Написанный с нуля код (лабораторный вариант) с большой вероятностью вполне пригоден к делу, к тому же его гораздо легче развивать. Полевой вариант создавался как развитие базовой архитектуры

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти

Обсуждения Количество комментариев3

Комментарий от  

Олег Точенюк

  |  23 января 2012, 23:41

Я не понял следующее, почему лабораторный вариант имеет более правильный код чем полевой, если система разрабатывается с нуля как там так и там, только во втором случае у нас уже есть клиент. Почему во втором случае это архитектура заплаток? Заплатки как раз будут в первом случае, потому что сделали какое-то решение попытались его применить к уже конкретному клиенту и "пошла жара", во-втором же случае в ходе реализации чаще проще внести изменения, когда увидели что уже надо, чем надо, но уже поздно, так как структура базы данных уже монолит и городить будем как раз костыли. Таким образом полевое решение это нормальная разработка, да с моментом заточки под клиента, второй клиент да это уже возможно будут заплатки, но аналогично такие же заплатки будут и при лабораторной системе и втором клиенте.
 
Далее как раз лабораторное решение может быть бутафорским с фантазиями теоретика постановщика и архитектора, а вот полевой нет, так как у вас есть клиент которому это надо и под которого вы это делаете и он то как раз и обрывает полет мысли теоретиков.

Комментарий от  

Дмитрий Мартынов

  |  24 января 2012, 09:30

Я не понял следующее, почему лабораторный вариант имеет более правильный код чем полевой, если система разрабатывается с нуля как там так и там, только во втором случае у нас уже есть клиент. Почему во втором случае это архитектура заплаток? Заплатки как раз будут в первом случае, потому что сделали какое-то решение попытались его применить к уже конкретному клиенту и "пошла жара", во-втором же случае в ходе реализации чаще проще внести изменения, когда увидели что уже надо, чем надо, но уже поздно, так как структура базы данных уже монолит и городить будем как раз костыли. Таким образом полевое решение это нормальная разработка, да с моментом заточки под клиента, второй клиент да это уже возможно будут заплатки, но аналогично такие же заплатки будут и при лабораторной системе и втором клиенте.
 
Далее как раз лабораторное решение может быть бутафорским с фантазиями теоретика постановщика и архитектора, а вот полевой нет, так как у вас есть клиент которому это надо и под которого вы это делаете и он то как раз и обрывает полет мысли теоретиков.

Путано получается, надо проще! Да и название Лабораторные/Полевые - неправильное. Все же не Полевые а Боевые.
 
Лабораторные / Боевые
 
Ассоциативно может показаться, что боевые обязательно должны быть лучше, но чтобы лучше представить я уточную параллель.
 
Допустим бизнес – это пушка, а ERP система – это конвейер для быстрой подачи снарядов (по техническим причинам снаряды лежат не совсем рядом). В этом случае вид и форма боевого конвейера зависит от рельефа местности. Но обратите внимание, что для другой пушки тот же самый конвейер может не подойти. Если мы воюем на ровной поверхности, то всегда подойдет, но даже в той же отрасли новая компания находится на другом месте и там другой рельеф.
Боевой конвейер можно переместить к другой пушке, отпилив все лишнее и укрепив дополнительными подставками, однако есть шанс, что после того как мы отпилим все лишнее выясниться, что у этой самоделки нет каркаса и она не жизнеспособна.
Лабораторный конвейер, конечно разрабатывался на ровной местности, но его сразу пытались сделать таким, чтобы и в овраге при небольшой допилке, он бы смог работать. Конечно жизнь преподнесет нам совсем другой овраг, и все конструкция лабораторного решения имеет жесткий хребет и есть шанс заставить его работать в новой местности.
 
Второй вариант анологии – это вакцина. Бизнес – живое существо, болезнь – это человеческий фактор. Боевая вакцина конечно эффективна, но только для конкретного штамма вируса. Другая фирма – это другие особенности и люди используют их иначе в свою пользу. Это тоже человеческий фактор, но он имеет другие проявления – другой штамм. Боевую вакцину исправить сложно, вот новую лабораторную, которая сразу делалась для уничтожения различных вирусов натравить на новый вирус проще…

Комментарий от  

Олег Точенюк

  |  25 января 2012, 11:52

Путано получается, надо проще! Да и название Лабораторные/Полевые - неправильное. Все же не Полевые а Боевые.
 
Лабораторные / Боевые
 
Ассоциативно может показаться, что боевые обязательно должны быть лучше, но чтобы лучше представить я уточную параллель.
 
Допустим бизнес – это пушка, а ERP система – это конвейер для быстрой подачи снарядов (по техническим причинам снаряды лежат не совсем рядом). В этом случае вид и форма боевого конвейера зависит от рельефа местности. Но обратите внимание, что для другой пушки тот же самый конвейер может не подойти. Если мы воюем на ровной поверхности, то всегда подойдет, но даже в той же отрасли новая компания находится на другом месте и там другой рельеф.
Боевой конвейер можно переместить к другой пушке, отпилив все лишнее и укрепив дополнительными подставками, однако есть шанс, что после того как мы отпилим все лишнее выясниться, что у этой самоделки нет каркаса и она не жизнеспособна.
Лабораторный конвейер, конечно разрабатывался на ровной местности, но его сразу пытались сделать таким, чтобы и в овраге при небольшой допилке, он бы смог работать. Конечно жизнь преподнесет нам совсем другой овраг, и все конструкция лабораторного решения имеет жесткий хребет и есть шанс заставить его работать в новой местности.
 
Второй вариант анологии – это вакцина. Бизнес – живое существо, болезнь – это человеческий фактор. Боевая вакцина конечно эффективна, но только для конкретного штамма вируса. Другая фирма – это другие особенности и люди используют их иначе в свою пользу. Это тоже человеческий фактор, но он имеет другие проявления – другой штамм. Боевую вакцину исправить сложно, вот новую лабораторную, которая сразу делалась для уничтожения различных вирусов натравить на новый вирус проще…

Думаю дальше что-то обсуждать нет смысла так как нужны реальные примеры о том что лучше. Из моей практики лабораторные системы, проигрывают полевым, но привести примеры получится вряд ли так как по правильному нужно иметь клиента, лабораторию и понеслось.. а на выходе бы получили что вышло лучше и что лучше стало тиражироваться.
 
PS: Кстати я так и не понял, почему в вашем примере лабораторная система это стройная конструкция, а полевая это всегда некий набор костылей?! Хотя даже при таком подходе полевые костыли уже работают, а вот так стройная конструкция еще даже не догадывается какие костыли ей будут лепить в ходе внедрения :-)