Comments 96
про паталогоанатомов забыли. Кто-то же должен оперировать тушку, если на ней уже зависла куча бабла.
Именно так, иногда (к моему удивлению) инвесторы покупают что-то «с именем», но полностью гнилое, в долгах и с разбежавшейся кто куда командой разработки. И тут возникает очень серьезный вопрос: убить все и переписывать с нуля, или же попытаться шаг за шагом, дабы не пугать существующих пользователей, аккуратно все переписать «как надо».
В заголовке и тексте приставка «веб-» лишняя.
Абсолютно те же самые слова можно отнести к «невеб-» проектам.
А возможно, даже и к не-IT-индустрии
Абсолютно те же самые слова можно отнести к «невеб-» проектам.
А возможно, даже и к не-IT-индустрии
Ну я поскромничал немного :-) Вообще ИМХО именно в IT может наблюдаться просто неадекватное усложнение систем за счет высокой концентрации мозгов, выдающих код в короткий промежуток времени. Если недоглядеть то такой кошмар перезапутанный может получиться, что никакая автомобильная электрика с 8 километрами проводов в одном кузове сравниться не может.
На счёт «Помойки», это похоже на множество аутсорс-проектов, которые я видел. Будете смеяться, но «помойки» приносят неплохие деньги, и там работают вполне здравомыслящие люди именно ради этих денег.
Кстати множество успешных OpenSource проектов те ещё «помойки».
Кстати множество успешных OpenSource проектов те ещё «помойки».
Самая простая реализация холодильника — ветка main в репозитории кода, в эту ветку запрещены прямые чекины, только слияния кода из девелоперских веток и фиксов из веток релизов.
Согласен. А еще лучше, если главный коммитер — руководитель отдела разработки, чтобы занимался действительно полезным делом и брал на себя ответственность за код подчиненных.
Уже начиная от 3 подчиненных руководитель отдела разработки или начнет коммитить не глядя или начнет с детьми общаться на помеси HTML и JavaScript. Надо делегировать по-любому, иначе с ума сойдешь.
А если не проверять код — тоже сойдешь с ума, но не сразу, а через полгода, когда от проекта начнут отваливаться куски трупной плоти. Лучше сразу проверять, вооружившись набором инструментов.
Линус Торвальдс раньше же все смотрел, что в ядро попадало, успевал как то :-) Это сейчас он окружен группой помощников — лень трудно побороть :-)
Плюс, коммитить должен не автор, а ревьюер и после успешного прогона полного набора тестов.
Я бы добавил в теги методологии разработки. Очень правильная статья, на определенном этапе необходимо внедрять TDD, XP, SCRUM и прочие сложные вещи, которые упростят жизнь в перспективе. Можно развить эту тему именно в сторону методологий, т.к. это уже готовые стандарты которым можно следовать для достижения поставленной цели.
Вся эта статья написана лишь для того, чтобы упоминуть bitrixframework в контексте добра? Согласитесь, его качество кода нельзя никак отнести к разряду «первой свежести», от которого не бегут программисты.
Я не хотел бы тут утомлять уважаемых коллег продуктовым маркетингом. Согласитесь, далеко не просто сложные системы поддерживать в первой свежести — но вот допускать их погружение в болото помойки — преступление :-)
Не имею ничего против битрикса, как коробки для быстрого развёртывания, но это удел веб мастеров, а не программистов.
А вот если писать какие-то модули, то битрикс — это ад и никак не вписывается в нормальный процесс разработки. Его код не только не первой свежести, но даже не второй и третьей. Сложные проекты на битриксе действительно подердживать невозможно, он не testability, extensible, controllability.
да и agile, scrum тестирование для вас непревычные слова, особенно опус про тестирование порадовал.
Собственно битрикс в профиле указывает, что я был прав. А ведь некоторые приняли это за чистую монету и будут продолжать делать свою модульную систему, вместо использования тестов. Кстати, как вы делаете рефакторинг без тестов, эксперементируете на сотрудниках и клиентах у которых отваливает функционал после апдейтов?
А вот если писать какие-то модули, то битрикс — это ад и никак не вписывается в нормальный процесс разработки. Его код не только не первой свежести, но даже не второй и третьей. Сложные проекты на битриксе действительно подердживать невозможно, он не testability, extensible, controllability.
да и agile, scrum тестирование для вас непревычные слова, особенно опус про тестирование порадовал.
Собственно битрикс в профиле указывает, что я был прав. А ведь некоторые приняли это за чистую монету и будут продолжать делать свою модульную систему, вместо использования тестов. Кстати, как вы делаете рефакторинг без тестов, эксперементируете на сотрудниках и клиентах у которых отваливает функционал после апдейтов?
А приведите плз. пример коробочного решения, которое есть рай для программистов. Вот ищу ищу, да найти не могу, все что требует доработки чужого кода — называется адом :-)
Например, Rails, Django, для любителей явы — Spring или GRails. Самые развитые на данный момент фреймворки. На PHP хороши Zend, Cake, однако немножко недотягивают.
Diem на базе Symfony, magento на ZF (высокий порог входа, но код нормальный и расширяемый), Drupal менее противен нежели битрикс, WordPress очень хорош и расширяем и огромная куча других менее известных решений.
А битрикс очень ужасен и имеет закрытое ядро, так что даже пофиксить сам не сможешь, это сразу крест на серьёзном проекте.
А битрикс очень ужасен и имеет закрытое ядро, так что даже пофиксить сам не сможешь, это сразу крест на серьёзном проекте.
Согласен про друпал и битрикс, однако у заказчиков иногда существует другое мнение. Приглашали как-то доделать сайт для президента Башкирии, который был на рельсах, но не устраивал, т.к. у нас мало таких спецов и они дороги. Их мнение по поводу CMS было четким — если за CMS платишь, то и по шапке есть кому настучать, то есть, кому позвонить с требованием исправить косяк. Если же используется друпал, то нет такого его разработчика, которому можно было позвонить и потребовать.
Хотя в таких случаях всегда вопрос возникает к разработчикам сайта, а не разработчикам CMS. И тут уже справедливо ваше замечание.
Хотя в таких случаях всегда вопрос возникает к разработчикам сайта, а не разработчикам CMS. И тут уже справедливо ваше замечание.
«А битрикс очень ужасен и имеет закрытое ядро, так что даже пофиксить сам не сможешь, это сразу крест на серьёзном проекте.»
Возражу:
— ядро открыто, исходники ваши
— для модификации его работы нужно использовать переопределение обработчиков событий (помните такой есть паттерн программирования — Observer)
По поводу ужасности… контретный пример можете привести? Интересно.
Возражу:
— ядро открыто, исходники ваши
— для модификации его работы нужно использовать переопределение обработчиков событий (помните такой есть паттерн программирования — Observer)
По поводу ужасности… контретный пример можете привести? Интересно.
У Symfony и magento — довольно высокий уровень вхождения (строгое ООП). У 1С-Битрикс — он низкий, за счет использования нескольких популярных паттернов и многолетней борьбы с объектно-дизориентированным программированием, уводящим решения в облака сложности.
И прошу, пишите конкретику, эмоции «ужасен, противен» — не понятны мне и коллегам.
И прошу, пишите конкретику, эмоции «ужасен, противен» — не понятны мне и коллегам.
govnokod.ru/search?search=bitrix
govnokod.ru/search?search=%D0%B1%D0%B8%D1%82%D1%80%D0%B8%D0%BA%D1%81
я в своё фремя инъекцию в нём нашёл через десять минут просмотра исходников, было это года три назад.
и не надо сказок про ооп, мы с вами взрослые люди и знаем, что битрикс тоже оперирует объектами, только делается это в процедурном стиле, что гораздо сложнее нежели используя фишки ооп: наследование, инкапсуляция, интерфейсы… Вы вот сами привели объектный паттерн observer. который, кстати, позволяет менять только то, что задумывалось и не позволяет править баги и проводить оптимизацию.
govnokod.ru/search?search=%D0%B1%D0%B8%D1%82%D1%80%D0%B8%D0%BA%D1%81
я в своё фремя инъекцию в нём нашёл через десять минут просмотра исходников, было это года три назад.
и не надо сказок про ооп, мы с вами взрослые люди и знаем, что битрикс тоже оперирует объектами, только делается это в процедурном стиле, что гораздо сложнее нежели используя фишки ооп: наследование, инкапсуляция, интерфейсы… Вы вот сами привели объектный паттерн observer. который, кстати, позволяет менять только то, что задумывалось и не позволяет править баги и проводить оптимизацию.
Вот именно. В ядре предусмотрено множество мест, где генерятся события. При необходимости точки создания события легко добавляются по первому обращению. Поэтому ядро править — не нужно, а нужно просто внимательно читать документацию к используемым библиотекам.
Да, в Битрикс объекты используются как пространства имен для функций. Может вы предлагаете юникс, в котором все на функциях почти, переписать на ООП на С++? Шутите?
Да, в Битрикс объекты используются как пространства имен для функций. Может вы предлагаете юникс, в котором все на функциях почти, переписать на ООП на С++? Шутите?
не занимайтесь софистикой, если бы код юниксов был на ооп, он бы от этого только выиграл во всех моментах кроме производительности, а битрикс и без этого ОЧЕНЬ медленный.
и опять же серьёзный крупный проект и зависимость от саппорта битрикса — это смешно. люди php, nginx, mysql патчат при надобности, а здесь нельзя поправить исходник на скриптовом языке, какое-то ядро, которое практически не обладает серьёзными возможностями в сравнении с любым фреймворком.
и опять же серьёзный крупный проект и зависимость от саппорта битрикса — это смешно. люди php, nginx, mysql патчат при надобности, а здесь нельзя поправить исходник на скриптовом языке, какое-то ядро, которое практически не обладает серьёзными возможностями в сравнении с любым фреймворком.
«а битрикс и без этого ОЧЕНЬ медленный» — цифры дайте, плз.
«а здесь нельзя поправить исходник на скриптовом языке, какое-то ядро, которое практически не обладает серьёзными возможностями в сравнении с любым фреймворком.»
Вот примеры «серьезных крупных» проектов на Битриксе без патчей мускуля, пхп, nginx:
МТС, Госдума России, Евросеть, Связной, Xerox, Epson, Газпром-нефть, МЧС России, Эльдорадо
Иногда коллеги обращаются в саппорт, но в основном, т.к. получили исходники, развивают системы сами, прикручивая к ним Doctrine, Propel, ZF, ContinuousIntegration и т.п. при необходимости.
Вы думаете, в этих организациях люди без мозгов и не просчитывают риски и плюсы/минусы внедрений? Я думаю, что клиент всегда голосует за лучшее.
«а здесь нельзя поправить исходник на скриптовом языке, какое-то ядро, которое практически не обладает серьёзными возможностями в сравнении с любым фреймворком.»
Вот примеры «серьезных крупных» проектов на Битриксе без патчей мускуля, пхп, nginx:
МТС, Госдума России, Евросеть, Связной, Xerox, Epson, Газпром-нефть, МЧС России, Эльдорадо
Иногда коллеги обращаются в саппорт, но в основном, т.к. получили исходники, развивают системы сами, прикручивая к ним Doctrine, Propel, ZF, ContinuousIntegration и т.п. при необходимости.
Вы думаете, в этих организациях люди без мозгов и не просчитывают риски и плюсы/минусы внедрений? Я думаю, что клиент всегда голосует за лучшее.
6 последних лет пишу на ZF, BitrixFramework и чистом PHP. Указанных проблем — не наблюдаю.
>>> 2) Если проект имеет сложную бизнес-логику, биллинг и т.п. — воспользуйтесь готовым решением/фреймворком (ZendFramework, BitrixFramework и т.п.) — чтобы ничего сложного вам делать не пришлось.
А как тогда програмцы научатся понимать и реализовывать эту сложную бизнес-логику? И что есть сложная бизнес-логика?
А как тогда програмцы научатся понимать и реализовывать эту сложную бизнес-логику? И что есть сложная бизнес-логика?
Ну вот попробуйте с нуля написать модуль обработки заказов. Там много тонкостей — от округления машинного нуля до тюнинга уровня изоляции транзаций. Не все программисты, к сожалению, знают, что это такое. Я бы взял для этих целей готовое решение и направил разработчиков на курсы по АПИ к решению — кто сдаст сертификат на 4-5, остается в проекте, кто не сдаст — не проходит испытательный срок. Удобно и надежно имхо.
Простите, возможно я не в теме, но я не вижу никаких проблем в обработке заказов… Можете описать кратко хоть одну проблему, которая может скушать мозг?
А вот я видел, что получается, если дать неопытным разработчикам спроектировать… прочь сложные вещи — хотя бы модуль управления курсами валют. Технические баги это еще ничего, но когда баги логические, когда на объекты предметной области код разложить невозможно — это просто ужасно :-)
ZendFramework имеет встроенный модуль управления курсами валют? Что-то я теряю нить разговора…
Не думаю, но вот реальные примеры модулей:
Валюты,
Заказы,
Торговый каталог
В них — минимальный функционал. Думаю, общем и сложность работы очевидна. Смысл их писать с нуля, разве только прокачать программистов :-)
Валюты,
Заказы,
Торговый каталог
В них — минимальный функционал. Думаю, общем и сложность работы очевидна. Смысл их писать с нуля, разве только прокачать программистов :-)
Что-то мне страшно стало… Вы действительно считаете, что это сложные модули? Неужели в веб-разработке все так плохо?
Они не сложные, но вот довести их до продакшн-качества — сложно.
Кажется я что-то упустил в последнее время в веб-разработке…
Смотрите шире. Вот написали вы простенькую обработку заказа — корзина и её оформление. А следующему заказчику понадобились скидки. Что делаем? Дописываем. Ещё одному заказчику понадобилась нетривиальная обработка части заказа перед окончанием оформления заказа. А кому-то понадобилось сделать доставку через UPS, EMS и что-нибудь ещё с авторасчётом стоимости. И внезапно этого же захотелось самому первому клиенту, у которого был простенький магазин. Дальше самые банальные хотелки продолжать не буду, но представьте, что это всё надо сделать в одном тиражируемом продукте, чтобы удовлетворяло всех и, самое главное, правильно работало при включении/отключении той или иной функции:-)
Сложен ли этот функционал в расчленённом виде? Местами — да. Сложно ли его сделать стабильным для тысяч клиентов с различными требованиями? См. выше комментарий Александра Сербула.
Сложен ли этот функционал в расчленённом виде? Местами — да. Сложно ли его сделать стабильным для тысяч клиентов с различными требованиями? См. выше комментарий Александра Сербула.
Начнем с того, что я бы не писал простенькую обработку заказа. В нее было бы изначально заложено множество вещей, одна из которых — масштабирование. Нетривиальные обработки и способы доставки выносятся в хэндлеры, система плагинизируется, и, если надо, добавляется система управления состояниями. Другими словами, я бы писал конструктор, а не простое решение задачи, и на этом конструкторе решал бы задачу.
И, к сожалению, я забыл, что обычно задачи решаются в лоб. Отвык уже так думать, поэтому и немного был обескуражен, что люди в простых вещах сложности видят
И, к сожалению, я забыл, что обычно задачи решаются в лоб. Отвык уже так думать, поэтому и немного был обескуражен, что люди в простых вещах сложности видят
> В нее было бы изначально заложено множество вещей
я счастлив жив и работать на одном континенте и одной планете с таким гением, как Вы! спасибо Вам, что Вы есть!
я счастлив жив и работать на одном континенте и одной планете с таким гением, как Вы! спасибо Вам, что Вы есть!
вот видите: я самый обычный человек и сделал опечатку («жив» вместо «жить») даже в простейшем комментарии.
я счастлив, что мы с вами на одной планете, но мне стыдно, ведь я такой несовершенныыыыыыыйййййй
я счастлив, что мы с вами на одной планете, но мне стыдно, ведь я такой несовершенныыыыыыыйййййй
Согласен. Такого разработчика я бы с руками и ногами оторвал. Сразу писать конструктор — это круто. :-)
Да вот хотя бы взять нормальный телекомовский биллинг для телефонии. Вроде, ничего сложного — на входе 10М CDR записей о звонках, на выходе кипа счетов абонентам. Но дьявол кроется в мелочах.
Пусть Вася позвонил Пете, сказал ему плохое слово и бросил трубку. Звонок — 5 секунд.
Стоимость этого направления — 2 руб./мин
Казалось, бы — Вася должен нам 2*(5/60) рублей.
Но по закону, звонки до 5 сек. не тарифицируются.
Тогда — 0?
Но это не касается звонков на 8-800, где платит вызываемый абонент.
Тогда Петя должен?
А если посчитать продолжительность звонка не с момента когда Петя взял трубку, а с момента когда Вася закончил набирать номер? Тогда уже 15 секунд получается.
А если у них межофис и они платят абонентку и говорят сколько хотят?
Причем все это разработчикам сразу никто не скажет, хитрые продавцы будут вспоминать все эти особенности по ходу разработки, а еще часть по ходу придумают.
Пусть Вася позвонил Пете, сказал ему плохое слово и бросил трубку. Звонок — 5 секунд.
Стоимость этого направления — 2 руб./мин
Казалось, бы — Вася должен нам 2*(5/60) рублей.
Но по закону, звонки до 5 сек. не тарифицируются.
Тогда — 0?
Но это не касается звонков на 8-800, где платит вызываемый абонент.
Тогда Петя должен?
А если посчитать продолжительность звонка не с момента когда Петя взял трубку, а с момента когда Вася закончил набирать номер? Тогда уже 15 секунд получается.
А если у них межофис и они платят абонентку и говорят сколько хотят?
Причем все это разработчикам сразу никто не скажет, хитрые продавцы будут вспоминать все эти особенности по ходу разработки, а еще часть по ходу придумают.
Вот вот. Эти мелочи черт из за ногу отлавливать придется полгода как минимум, теряя время и деньги.
Эти мелочи должны выявляться на этапе бизнес-анализа, никак не разработчиками, нормально спроектированный модуль без трудоемкого рефакторинга должен достаточно гибко настраиваться и закладывать в себе даже те возможности, о которых на начальном этапе даже не думают, как о вполне реальных. Не вижу ничего сложного в приведенных правилах, что не могло бы быть заложено изначально, откуда тут полугодичная потеря может возникнуть?
Поддерживаю на 100%. Грамотный предпроект и согласование с заказчиком позволяют решить проблему внезапных хотелок если не полностью, то хотя бы сузить ее до вменяемых масштабов. Вменяемые масштабы — это когда вы можете сказать — «извините, вы не упоминали о такой особенности этого бизнес-процесса, давайте посмотрим на схему. Видите — нету. А вот — видите, — ваша подпись. Мы готовы реализовать это после того, как сделаем весь функционал, который есть на схеме.»
Даже если на препродакшн потратить столько же денег и времени, сколько на разработку, все равно всего не перечислишь. А отмазки вида «в ТЗ не было» с 99% наших заказчиков не канают. И ладно бы это были пацанчики из 90-х. А то ведь это чаще тетеньки средних лет которым руководство поставило задачу «сделать документооборот» и которые ничего не подпишут пока не обойдут всех начальников отдела и не получат от каждого «ок». В процессе этого обхода ТЗ может измениться до неузнаваемости. Скажете, не работать с такими? Других у нас нет…
Тёма может себе позволить с такими не работать и иметь грамотный предпроект и согласование с заказчиком и бизнес-аналитиков. А таким IT-бомжам как мы приходится рыться по помойкам и компенсировать ветреность заказчика такими штуками как TDD, Agile, SCRUM и рефакторинг.
Embrace the changes, как говорит великий Фаулер.
Тёма может себе позволить с такими не работать и иметь грамотный предпроект и согласование с заказчиком и бизнес-аналитиков. А таким IT-бомжам как мы приходится рыться по помойкам и компенсировать ветреность заказчика такими штуками как TDD, Agile, SCRUM и рефакторинг.
Embrace the changes, как говорит великий Фаулер.
Я не согласен на 100%. У вас договорные отношения, которые четко прописаны на бумаге. А что касается того, что у вас какие-то не такие заказчики — не обольщайтесь, они все одинаковые, я думаю, что у Лебедева все так же. Что касается того, что ТЗ в процессе его написания меняется — это нормально, для этого и нужен предпроект, чтобы выявить потребность заказчика. А вот когда ТЗ меняется после подписания, то это значит, что у вас не налаже нормальный контакт с заказчиком, и он вами крутит так, как ему удобно. На практике это означает, что маржа с этого проекта в итоге падает, поскольку ресурсов тратится больше, чем ожидалось, и возникает вопрос — о целесообразности этого проекта.
В общем-то, Вы правы, насчет маржи. Как бы то ни было, решающее слово в споре с заказчиком в нашей конторе имеют продавцы и гендир. Меня, как руководителя исполнителей, ставят в конечном итоге перед фактом — что бы ты не говорил, а придется прогнуться. Причины разные — начиная от административного ресурса и заканчивая нашими косяками, на которые давит заказчик мотивируя смену ТЗ.
Зная из практики что скорее всего так все равно будет, я уже заранее готовлю народ, требуя хорошего покрытия тестами.
Зная из практики что скорее всего так все равно будет, я уже заранее готовлю народ, требуя хорошего покрытия тестами.
Если их приходится отлавливать на этапе разработки, значит вам нужно расстрелять ваших бизнес-аналитиков.
нет, ну если это в одном методе, да все на ифы повесить, тогда да — изменить что-то проблематично будет, но… вы поняли, да, как такого разработчика назвать?
Самый сок в том, что это не сразу заранее известно, чтобы можно было сразу правильно спроектировать. Это становится известно по итерациям. Выкладываешь бету, звонит заказчик, говорит — ничего не работает. Начинаешь выяснять, оказывается — звонки на границе суток, которые начались вчера, а закончились сегодня должны обсчитываться в разные дни в детализации, но с одним номером звонка. Все исправляешь — а тут еще какая-нибудь архинужная фича, которую придумал заместитель младшего мерчандайзера по фейсингу шелвинга — например, звонки на службу ЖКХ про протечки крыш и труб не тарифицируются — социальная программа.
И тут изначально красивый такой, модульный и архитектурный код начинает неудержимо фалломорфировать, потому что заказчик давит — «Да тут всего то чуть-чуть подправить, завтра сделаете?» Вот тут то и надо жесткость проявлять, о которой автор статьи писал.
А по четкому ТЗ, которое не меняется, да еще и заранее обдуманному кто хочешь напишет.
И тут изначально красивый такой, модульный и архитектурный код начинает неудержимо фалломорфировать, потому что заказчик давит — «Да тут всего то чуть-чуть подправить, завтра сделаете?» Вот тут то и надо жесткость проявлять, о которой автор статьи писал.
А по четкому ТЗ, которое не меняется, да еще и заранее обдуманному кто хочешь напишет.
Не понимаю, как вам поможет Zend Framework в «округлении машинного нуля и в тюненге уровня изоляции транзакций»?
Кстати, модульность не заменит тестов — если это не сферический конь в вакууме. Так что если девелоперы не умеют писать автотесты или по каким-то причинам не хотят — надо писать тесты в виде программы для специально обученного эникейщика и прогонять вручную. Так, к примеру, делают в CAS. Полный прогон — неделю человек сидит и контролы щелкает по бумажке, записывая что получилось.
Кстати, сдача проекта госзаказчику подразумевает программу испытаний, которая тоже на бумажке записана и запись результатов ручного выполнения в таблицу.
Кстати, сдача проекта госзаказчику подразумевает программу испытаний, которая тоже на бумажке записана и запись результатов ручного выполнения в таблицу.
Я полностью поддерживаю. Модульность, юнит-тесты, системные тесты — если делаются с головой, нужны. А если без головы — то вам придется поддерживать две помойки — помойку кода и помойку юнит-тестов.
А уж тем более если говорить об agile методах, то разработка через тестирование, разработка через поведение, когда сначала заботишься о том чтобы были интеграционные и модульные тесты, а только затем модули и приложение, которое их успешно проходит. Для программистов на рельсах и других высокоуровневых фреймворках в этом плане уже есть все инструменты.
Скажу честно. Видел проекты, большие, может не первой свежести, но близкие к ней — в которых НЕТ юнит-тестов, но поддерживается строго модульность и принята практика тестирования большим числом участников Бета-версий. И уверен, они будут развиваться, и ничего страшного не случиться.
Я думаю к тестам надо без фанатизма относиться. Если процесс работы построен так, что регрессию отлавливают без тестов и код не загрязняется со временем, то и не нужны они. Но это нужно чтобы разработчики были очень грамотные, а ПМ — вообще гений.
Я рассматриваю SCRUM, XP, TDD и т.п. как способ формализации программирования, сведение искусства до ремесла, чтобы можно было почти любого научить, если он сам хочет. Чтобы студию превратить в завод. В конце концов, это бизнес.
Я рассматриваю SCRUM, XP, TDD и т.п. как способ формализации программирования, сведение искусства до ремесла, чтобы можно было почти любого научить, если он сам хочет. Чтобы студию превратить в завод. В конце концов, это бизнес.
Конечно могут. Но насколько это эффективно по сравнению с agile методологиями, когда изначально любой рефакторинг предсказуем, т.к. есть автоматизированные тесты. Практика показывает что затраченное время на разработку уменьшается и качество кода улучшается значительно.
Самая незаметная, но от этого не менее весомая плюшка тестов заключается в кристаллизации ТЗ. Начать кодить еще не представляя что должно получиться может любой, а вот чтобы написать тест, тем более приемочный придется четко обозначить конечный результат.
На данный момент и в PHP полно инструментов для написания от юнит тестов до функциональных, не всё же Rails досталось. Главное не убивать на тесты всё своё время :) а что-то и писать работающее.
p.s. интересно, а кто это у нас делал сайт для президента РБ на Rails, Мальджини?
p.s. интересно, а кто это у нас делал сайт для президента РБ на Rails, Мальджини?
«Свежесть бывает только одна — первая, и она-же последняя...»
1) «Системы жесткого контроля качества и мотивации» в природе быть не может. Либо жёсткий контроль — либо мотивация. Кому нравится работать под жёстким контролем, поднимите руку. На практике нужен контроль мягкий, но последовательный. Скажем, не увольнять за косяк (и ни в коем случае не отчитывать публично), а при первом косяке вычитать 50 рублей, при втором (в том же месяце) — 100, и т.д.
2) «Вытянуть» можно проект из любого состояния при единственном условии — наличие работающего продукта. Пусть даже он кривой, глючный и написан на коболе. Для этого нужно соблюдать нехитрые правила:
а) Выкинуть из головы максимализм (переписать с нуля, весь код — на рефакторинг и т.п.). Обилие висящих «постановок на рефакторинг» (который некогда и некому делать) ничем не поможет, кроме демотивации.
б) Установить правила, которым должен удовлетворять весь вновь написанный код, и следить за их соблюдением (за попадание в репозиторий кривого кода — 50р, 100р и т.д.; с пруф-оф-концептами, написанными на коленке, можно и на локальном компе баловаться).
в) Последовательно замещать кривой код вновь написанным настолько маленькими кусками, чтобы изменения были безболезненны и не ломали продукт (нашли баги — обсудили с прогером, сколько времени нужно на то, чтобы исправить все баги этого участка кода, и сколько — на «переписать с нуля». Если переписать займёт на порядок больше времени — выкидываем «переписать» из головы, и скрепя сердце правим старый код, по возможности одновременно приводя его в соответствие с новыми правилами).
г) Вводить новые архитектурные концепции параллельно с существующими, а не вместо них. Переводить продукт на новую архитектуру последовательно, по частям. Да, это иногда сложно, но всегда реально. Лучше потратить два месяца на придумывание инфраструктуры для последовательного перевода проекта на новую архитектуру, чем полгода на создание с нуля «версии 2.0», которая в итоге так никогда и не заработает.
2) «Вытянуть» можно проект из любого состояния при единственном условии — наличие работающего продукта. Пусть даже он кривой, глючный и написан на коболе. Для этого нужно соблюдать нехитрые правила:
а) Выкинуть из головы максимализм (переписать с нуля, весь код — на рефакторинг и т.п.). Обилие висящих «постановок на рефакторинг» (который некогда и некому делать) ничем не поможет, кроме демотивации.
б) Установить правила, которым должен удовлетворять весь вновь написанный код, и следить за их соблюдением (за попадание в репозиторий кривого кода — 50р, 100р и т.д.; с пруф-оф-концептами, написанными на коленке, можно и на локальном компе баловаться).
в) Последовательно замещать кривой код вновь написанным настолько маленькими кусками, чтобы изменения были безболезненны и не ломали продукт (нашли баги — обсудили с прогером, сколько времени нужно на то, чтобы исправить все баги этого участка кода, и сколько — на «переписать с нуля». Если переписать займёт на порядок больше времени — выкидываем «переписать» из головы, и скрепя сердце правим старый код, по возможности одновременно приводя его в соответствие с новыми правилами).
г) Вводить новые архитектурные концепции параллельно с существующими, а не вместо них. Переводить продукт на новую архитектуру последовательно, по частям. Да, это иногда сложно, но всегда реально. Лучше потратить два месяца на придумывание инфраструктуры для последовательного перевода проекта на новую архитектуру, чем полгода на создание с нуля «версии 2.0», которая в итоге так никогда и не заработает.
Кстати, а как это делают у вас в Битриксе? Можно об этом без NDA узнать? Оччень интересно! Среда, фреймворки серверные и клиентские, техпроцесс… Похоже это тема для еще одной статьи, не так ли?
Я постараюсь отдельно написал об этом. Не хочется менять тему статьи, которая посвящена борьбе за качество и жизнь продуктов.
Вы только не забудьте, плз. А то по тому коду, что я вижу, складывается ощущение, что хоть как-то налаживаться процесс разработки там начал только в последние полгода-год максимум.
Вы про ООП? Я вот разочаровался в нем. Иногда оно полезно, а иногда вредно имхо.
Мне ваши слова именно в таком виде очень напоминают «разоблачающие» статьи Рыжикова об XSLT. Когда люди не умеют использовать технологию и не понимают ее, но осуждают. Это лирика.
По сути. Не важно ООП или нет. Главное, чтобы код был в порядке. В Битриксе оно не так. Мест, где проносится в голове мысль «WTF» крайне много.
Хотя, как я уже написал, в последние полгода-год ситуация с кодом начинает улучшаться. Вижу это просто потому что люблю копаться в том, с чем работаю.
По сути. Не важно ООП или нет. Главное, чтобы код был в порядке. В Битриксе оно не так. Мест, где проносится в голове мысль «WTF» крайне много.
Хотя, как я уже написал, в последние полгода-год ситуация с кодом начинает улучшаться. Вижу это просто потому что люблю копаться в том, с чем работаю.
Я думаю это пережитки роста и развития большого продукта. Постепенно устаревшие вещи рефакторятся. Замечаю, что некоторые сложные вещи, типа бизнес-процессов, реализуются на ООП, что имхо разумно в данном случае.
Работал одно время серьезно с XSLT. Видимо тогда был спор почему в Битриксе не используется XSLT и Smarty для шаблонизации — просто попадаются иногда фанатики технологий, типа если нет полиморфизма и наследования, значит система уродливая :-)
Работал одно время серьезно с XSLT. Видимо тогда был спор почему в Битриксе не используется XSLT и Smarty для шаблонизации — просто попадаются иногда фанатики технологий, типа если нет полиморфизма и наследования, значит система уродливая :-)
Область применения XSLT очень ограничена. Это не панацея от всех бед и не серебрянная пуля. Но технология однозначно полезная.
Я когда-то думал, что XML/XSLT/XPath/XPointer и т.п. получат большое распространение. Но вот когда популярность стали набирать «простые» форматы типа Yaml в Symfony…
Может это естественно для человека — стремиться сначала к сложному, стукнуться башкой, а затем вернуться к простому?
Может это естественно для человека — стремиться сначала к сложному, стукнуться башкой, а затем вернуться к простому?
XSLT не сильно расширяема, это главная проблема технологии. А дефолтных функций хватает только на примитив.
Взять тот же Smarty, написал своих модификаторов, функций, и используешь их во всех проектах. Не понравилось поведение, дописал новых или изменил старые. С XSLT не уверен, что фишка прокатит.
Взять тот же Smarty, написал своих модификаторов, функций, и используешь их во всех проектах. Не понравилось поведение, дописал новых или изменил старые. С XSLT не уверен, что фишка прокатит.
XSLT 2.0 не сильно расширяем? Нельзя шаблон на файлы разделять? Я уж молчу о том, что в обычном режиме XSLT процессор позволяет использовать функции, написанные на родном языке программирования. Хотя, постойте! Может, вы используете PHP(или любой другой язык), где нет XSLT 2.0 процессоров, а только 1.0? Ну тогда ругаться на давно устаревшую технологию как-то странно.
Я с очень большим трудом могу придумать в каких ситуациях возможностей XSLT будет не хватать. В 99% случаев они решаются изменением подаваемого на вход XML. Правда стоит заметить, что ровно также, как при переходе от реляционной БД нереляционной требует смены подхода, также и в случае с XSLT в сравнении с тем же Smarty.
Хотя, безусловно, для каждой задачи есть свои инструменты. И XSLT ни в коем случае не стоит пихать везде, где ни попадя.
Я с очень большим трудом могу придумать в каких ситуациях возможностей XSLT будет не хватать. В 99% случаев они решаются изменением подаваемого на вход XML. Правда стоит заметить, что ровно также, как при переходе от реляционной БД нереляционной требует смены подхода, также и в случае с XSLT в сравнении с тем же Smarty.
Хотя, безусловно, для каждой задачи есть свои инструменты. И XSLT ни в коем случае не стоит пихать везде, где ни попадя.
А можно, как идиоту, на пальцах объяснить смысл этих советов:
Контроль за чем, отсев чего? То есть их единственная задача когда через них почему-то не проходит API, это самоотсев — сидят, ничего не делают и думают, увольняться им или нет. Воспитают те, кто не должен ничего создавать.
Каких экспертов, а что ревизия кода ответа на этот вопрос не дает? У нас каждый метод вынесен в отдельный модуль, это хорошо? А если продукт из одного модуля это считается достаточно модульным? А описанием архитектуры вообще хоть кто ни будь должен озадачиваться или просто все шатаются и спрашивают друг у друга что попало, таким образом выясняя, чем они занимаются?
Архитектура подменяет тестирование?!
Судьбы протухших продуктов расписаны в излишне черных тонах, они могут десятилетиями вполне продолжать существовать, быть перепроектированы, если у проекта код-говно, это не страшно, так как это только часть затрат на проект и полный рефакторинг с некоторой периодичностью для веба с его темпами ввода проектов в эксплуатацию и модификации — это совершенно нормально.
3) Данные коллеги не должны ничего создавать. Их задача — жесткий контроль и отсев. Через них либо проходят код, АПИ, архитектура — либо не проходят и без компромиссов. Да, по началу у вас будет кадровая текучка но затем, останутся люди (либо вышеуказанные специалисты их воспитают), которые сумеют делать вещи, пропускаемые через вышестоящий фильтр качества и здравого смысла.
Контроль за чем, отсев чего? То есть их единственная задача когда через них почему-то не проходит API, это самоотсев — сидят, ничего не делают и думают, увольняться им или нет. Воспитают те, кто не должен ничего создавать.
4) Каждый день спрашивайте коллег-экспертов:
— Создаваемый продукт модульный? Ожидаемый ответ: Да или поставлена задача на рефакторинг.
Каких экспертов, а что ревизия кода ответа на этот вопрос не дает? У нас каждый метод вынесен в отдельный модуль, это хорошо? А если продукт из одного модуля это считается достаточно модульным? А описанием архитектуры вообще хоть кто ни будь должен озадачиваться или просто все шатаются и спрашивают друг у друга что попало, таким образом выясняя, чем они занимаются?
6) Если эксперты вам говорят, что разработчики умеют писать модульные тесты — разрешите им это делать. Значит вам повезло. Если не умеют и не учатся — не беда. Нас спасет модульность.
Архитектура подменяет тестирование?!
Судьбы протухших продуктов расписаны в излишне черных тонах, они могут десятилетиями вполне продолжать существовать, быть перепроектированы, если у проекта код-говно, это не страшно, так как это только часть затрат на проект и полный рефакторинг с некоторой периодичностью для веба с его темпами ввода проектов в эксплуатацию и модификации — это совершенно нормально.
«Контроль за чем, отсев чего? То есть их единственная задача когда через них почему-то не проходит API, это самоотсев — сидят, ничего не делают и думают, увольняться им или нет. Воспитают те, кто не должен ничего создавать.»
Эти люди несут ответственность за код. Если пропустили вверх, значит Вы уверены, что код благоразумный. Линукс так разрабатывается, другие известные опенсорс проекты. Коммитеры — люди особой важности.
«Архитектура подменяет тестирование?!»
Не подменяет. Но:
1) Если архитектура у вас гнилая, вам тестирование не поможет.
2) Если архитектура модульная и пропускается через коммитеров — то тестирование будет «автоматическим», через выпуск и испытание сообществом беты. Можете мне показать где в линуксе живут юниттесты? :-)
Эти люди несут ответственность за код. Если пропустили вверх, значит Вы уверены, что код благоразумный. Линукс так разрабатывается, другие известные опенсорс проекты. Коммитеры — люди особой важности.
«Архитектура подменяет тестирование?!»
Не подменяет. Но:
1) Если архитектура у вас гнилая, вам тестирование не поможет.
2) Если архитектура модульная и пропускается через коммитеров — то тестирование будет «автоматическим», через выпуск и испытание сообществом беты. Можете мне показать где в линуксе живут юниттесты? :-)
Sign up to leave a comment.
Веб-проекты «первой свежести» —«холодильник» качества