Программист 1с
По поводу взаимозаменяемости вы не правы. В 1с человек при всем желании не сможет вывернуться и написать так чтобы другой его не понял.

Странный критерий. А зачем выворачиваться и писать так, чтоб другой не понял?
Программист 1с
Во вторых сколько есть специалистов по дельфи? А сколько по 1с?

А вот этот довод категорически не в пользу 1с, даже если количество одинэсников окажется больше.
В частной беседе один знакомый франчайзер утверждал, что найти хороших разработчиков под 1с, особенно для 1с8 очень проблематично. Подавляющее большинство из той армии "разработчиков" 1с7, которых тут часто называют одним обидным словом, по его словам непригодны для качественной масштабной разработки в 1с8. Поэтому сами они предпочитают сейчас брать на работу не одинэсников, выросших в программисты из юзеров 1с путем мелкого конфигурирования, а "классических" программистов с фундаментальной подготовкой, со знанием C++, Pascal, Java и т.д., но не 1с. А уж 1с они сами обучат.

Программист 1с
По поводу специалистов незнающих что появилось в последних версиях упп. Неужели вы думаете что есть время постоянно следить за обновлениями?

Тут дар речи можно потерять....
Если это впариватели c первой страницы Рейтинга "Центров компетенции по производству" фирмы "1С" , у которых заявлены десятки внедрений УПП, имеется не одна сотня спецов 1с8. И к тому же по их же словам этот вопрос про спецификации им мы задали далеко не первые, и у них нет времени ознакомиться с тем, чем они себе на хлеб зарабатывают - ну тогда извините.
Программист 1с
Это не получается потому что спецы занимаются как правило написанием с нуля.

Что ставит под большое сомнение ваш тезис "В 1с быстрее потому что почти всегда можно взять за основу уже созданное, и только подправить мелочи."

Программист 1с
Написать можно все даже на VB лишь бы специалист был хороший. (лишь бы он потом никуда не ушел)
Понятие архитектуры системы в сообщесте 1с не модно?

Программист 1с Александр Гoлдун Программист 1с
По поводу специалистов незнающих что появилось в последних версиях упп. Неужели вы думаете что есть время постоянно следить за обновлениями?

Тут дар речи можно потерять....
Кстати а вы знаете все новое что появилось в последней дельфи? Или вы примерно остановились на 5 версии и ее у же хватает? Это не вопрос к вашей квалификации - это вопрос к тому что нет нужды бежать вперед. Если можно не спеша пройтись.

Во-первых - да. Я очень внимательно читаю раздел Whats New в хелпах как по Delphi, так и по используемому серверу БД Sybase SQL Anywhere при выходе очередных версий.
Во-вторых - да, остановились пока на 6-й версии Delphi. Хватает, хотя рассматриваем целесообразность покупки Delphi 2007. Похоже что оно того стоит. (кстати говоря, перевод в нашем случае будет практически безболезненным, не идущим ни в какое сравнение с перводом конфигурации с 1с7.7 на 1с8 )
Но аналогия в данном случае не очень подходящая. Упомянутая возможность в спецификациях - это не технологические программерские рюшечки, а актуальная для многих прикладная потребность. И если сами франчи не читают раздел "Что нового" в документации, то можно предположить, что многим из них плевать, что там нового. А имеющиеся готовые конфигурации используются лишь как красивые игрушки для презентаций доверчивым клиентам.

vogenut Александр Гoлдункстати говоря, перевод в нашем случае будет практически безболезненным, не идущим ни в какое сравнение с перводом конфигурации с 1с7.7 на 1с8 )Вы, товарищ, наверно с Delphi5 на Delphi7 никогда не пробовали переходить.
Переводил. Легко, хотя именно с 5 на 7 был мелкий проектик. Так же имею опыт перевода не мелких работающих систем практически начиная с версии 1 до 6 пошагово. С Delphi 6 на Delphi 2007 делал только пробные переводы без запуска в рабочую эксплуатаци. Мелкие проблемы были связаны с одной сторонней библиотекой. Решилось исправлением одной строчки в библиотеке. Ну а всякий модный бред типа .Net пока что удается обходить стороной. Нам и на win32 неплохо.

А конфигурацию с 1с7.7 на 1с8 перевести можно?
Ну ладно, не конфигурацию целиком, хотя бы какие-то модули?
А плавно мигрировать можно? Чтоб при работе с единой БД переводить не всех единомоментно, а постепенно, по рабочим местам?

Взвешенное обсуждение плавно начинает превращаться в непонятно что
vogenut
Александр ГoлдунА конфигурацию с 1с7.7 на 1с8 перевести можно?
Можно

Что ж, это для меня новость. А мне только что сообщили, что нет, только вручную с переписыванием кода.
vogenut
Так же, как вы не подцепите скомпилированый в Delphi7 модуль в проекте Delphi5. Даже больше скажу, исходник не получиться скомпилировать, кроме простейших случаев.

Ну, значит у меня система - простейший случай
vogenut
Александр ГoлдунА плавно мигрировать можно? Чтоб при работе с единой БД переводить не всех единомоментно, а постепенно, по рабочим местам?Можно, если использовать две базы и обеспечить между ними синхронизацию.
Я выделил жирным шрифтом специально. Достойный ход - отрицательный ответ на поставленный вопрос заменить положительным ответом на другой вопрос. А вообще, я полагал эти вопросы риторическими и не ожидал, что на них ответ последует

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

Хотелось на самом деле все процитировать и поставить жирный +1. Очень похожие впечатления возникли, когда разбирался с УПП. Подавляющее большинство форм и журналов сделаны по дефолту за несколько минут. Попытка привести это в минимально удобный вид даже без принципиального изменения функциональности как минимум уравнивает скорости разработки. А когда начинаешь корежить функционал и логику, тогда все - глубокое отставание обеспечено.

vogenut
Александр ГoлдунЯ выделил жирным шрифтом специально....Ну зачем задавать такие вопросы? Вас это действительно интересует или чисто поржать?

Я ж сказал, эти вопросы предполагались как риторические. Значит "чисто поржать".
vogenut
Сами знаете, что ни одна учетная система такого не позволяет.

Чего?????? Извините, но после этого утверждения уже и у меня зародились сомнения в Вашей компетентности. Знакомо понятие "клиент-серверная архитектура"? Или трехзвенная?
Так вот, при четком разделении этих уровней не вижу никаких препятствий тому, чтобы например при единой БД часть рабочих мест была на Delphi X, другая на Delphi Y, третья вообще хоть на MS Access или на чем угодно. Лично у меня практически всегда переходы происходили плавно, помодульно, а не единомоментно. Если 1с такого не позволяет, то это не значит, что ни одна учетная система это не позволяет.
vogenut
Александр ГoлдунА когда начинаешь корежить функционал и логику, тогда все - глубокое отставание обеспечено.Это опять же зависит от того как написан функционал. Гуи 8.0 построенна на паттерне MVC, это надо знать, соответственно выстраивая свой код в данной идеологии. Если писать по другому, то ни к чему хорошему это не приведет.
Да при чем тут паттерн и прочие модные слова? Каким паттерном регламентируется то, что в большинстве журналов сортировать, делать быстрый поиск и фильтровать можно только по номеру или по дате документа? Может паттерн MVC описывает что документ может иметь только 2 статуса - сохранен и проведен? А элементарный фильтр в журнале документов, скажем, по вхождению номенклатуры в табличную часть документа? Да можно много перечислять.
Для себя я выводы относительно преимуществ 1с для разработки систем уже сделал достаточные.

Программист 1с
В третьих чем вас не устраивает цикл 10-15 лет на одной версии программы 7 - сейчас 8 и так далее.

Да я прекрасно понимаю. Проехали этот момент. Случайно зацепились.

Создавая этот топик, я не ставил целью обхаять 1с ни в коем случае. Я просто хотел выяснить, что может дать перевод на 1с именно внутренней разработки, ибо сам имел сомнения по этому поводу, а со стороны слишком часто слышал в последнее время, что все будет в шоколаде. Причем как от конченных юзеров, мечтающих о волшебной кнопке, так и от айтишников.
Проведенное исследование может и не до конца объективное, но оно показало (для меня, для моего случая):
1. Преимущества по готовому уже функционалу (УПП) мы практически не получим. Ибо все равно многого из того что нужно, там нет. А что есть - требует такой переделки, что легче считать, что его нет.
2. Преимуществ по скорости разработки нового нет никаких. Скорость сопоставима при решении простейших задач, но с их усложнением может очень заметно отстать по сравнению с хорошим фреймворком, сделанным под свои нужны.
3. Преимуществ по кадрам нет никаких. Проверено на практике свежим опытом закрытия вакансий.


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

В общем, для меня вопрос почти закрыт. Почти - это потому что есть еще горячие головы в управлении, которым неймется.

Не могу не отметить, что у нас в плане разработки эта поднятая буча с одинэсом принесла свои полезные плоды
- Наконец-то сделали свою библиотеку прикладных компонентов
- Причесали API модулей, Сделали внятную COM-обертку для многих объектов.
- Начили наводить порядок в разбросанной документации, как юзерской, так и девелоперской.
- Обозначили план работ с приоритетами на ближайшие пол-года
и т.д.

Так что встряска иногда полезна

Программист 1с Александр ГoлдунДля себя я выводы относительно преимуществ 1с для разработки систем уже сделал достаточные.
Интересно какие? Потому что я как дельфист и программист 1с уже давно сделал выводы что нужно писать на 1с, а что нужно на дельфи. Вот интересно сравнить.
Да большую часть уже озвучили. Если кратко резюмировать, то я выбрал бы 1с8 в следующих случаях:
1. Имеющиеся конфигурации максимально устраивают. Требуемые переделки минимальны
2. Требуемый функционал красиво ложится в идеологию 1с. По сути это система учета свершившихся фактов.
3. Система имеет небольшую трудоемкость в создании, делается для стороннего заказчика и нет желания самому в дальнейшем заниматься сопровождением этого.
Может показаться, что этим пунктом я противоречу сам себе. Когда я сам утверждал, что нет кадровых преимуществ, я имел в виду все же более масштабную внутреннюю разработку.

При каком-то сочетании этих трех пунктов, да еще и при остутствии противопоказаний, типа по масштабируемости и т.п., я, возможно, предпочел бы 1с8.

Если бы я начинал с нуля проект подобный тому же, что веду сейчас, я все же предпочел бы скорее всего опять универсальное средство разработки. Будь то Delphi, С# и т.д. - не принципиально. Может быть взял бы готовый фреймворк. Но не как среду разработки, а именно как фреймворк, дополняющий среду.

А Ваши выводы можно услышать?

vogenutЯ имел в виду промышленые системы.

Под промышленными имелись в виду коробочные.

vogenutПаттерн MVC расшивровывается как Model-View-Controller. Он регулирует взаимодействие отображения и источника данных.
Темный я в этом вопросе. Неуч. Странно, но почему-то не стыдно в этом признаться. Не читал про эти паттерны. Как-нибудь на досуге погуглю для улучшения общей начитанности.
vogenutДля того, что бы сортировка (поиск, фильтрование) работала быстро, необходимо завести соответствующие индексы. Если вам нужны специфические фильтры, то это тоже реализуемое.
Да я ж не спорю, я в курсе даже, как оно реализуется! Просто для демонстрации быстроты разработки часто показывают именно быстрое создание этого стандартного примитивного журнала автоматом. Да только вот я делаю так же быстро, унаследовавшись от базовой формы журнала, гораздо более функциональный и удобный интерфейс, для получения аналога которого в 1с надо очень заметно потрудиться. А индексировать каждое поле в таблице - абсурд.