Ну вряд ли на паскале запрещено писать длинные выражения с глубоким вложением.

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

Я вообще не в курсе о чем он  

Почему плохих?
И что такое большие программы?

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

Я помню, хантил меня как-то бывший коллега. Рассказывал какую инфраструтуру они строят. Между несколькими типовыми решениями прокинули интеграционную шину. И как круто звучит, на JBOSS сервере, с персистом на оракле, посредством JMS, есесно не без хибернейта, воркфлоу процессинг опосред обменом XML сообщениями. Там еще какие-то термины были, в которые я не вдуплил вобще. Техническая реализация на плечах двух жаваписов в москве, трех в киеве. Полгода работы, мегабайты кода. Ядро уже запилили, сейчас активно херачат адаптеры к интегрируемым системам. Но проблемы с производительностью, хороший ораклист им бы был очень в масть, жаваписы плавают на датабазе. Я смотрел на него и хлопал глазами. Буквально ту же хрень, я замутил за пару месяцев соло, на PL/SQL без всяких жибосов, жимыэсов, хибернейтов. Ну жава там да, была, чтобы разбирать сложноструктурированные XML эпических размеров. И там, блин, все просто. Кода с гулькин нос, основной код - трансформация данных. Но это больше гемор для аналитиков как правильльно распихать нераспихуемое нежели для программера. Однако,  если я кому-то стану это презентавать, я врядли смогу это сделать круто, используя много умных слов. Если бы я делал решение с претензией на тиражность, мы врядли смогли бы его продать - сильно не круто ибо. Слишком мало квадратиков с магическими аббревиатурами и стрелочками.

Я как бы работаю сейчас далеко не на последнего работодателя и участвую в достаточно крупных по масштабу проектах. Модули ценнобразования, заказов, к технической реализации которых я непосредственно причастен, сейчас обсчитывают порядка семисот магазинов. Модуль ассортиментного планирования - порядка полутора тысяч. Через интеграционную шину, о которой я упоминал выше сейчас связаны порядка 8 типов учетных систем, из них количество экземпляров 2-х типов исчисляется сотнями. Казалось бы есть чем хавастануть, проекты масштабные. Но не никак могу сказать что это большие программы. Кода там мало, если причесать откровенный гoвнокод, вычистить аттавизмы, так почти вобще не останется.

Взаимодействие же с пользователем в этих проектах, как правило, сводятся к тому чтобы показать ему набор данных, позволить выделить несколько десятков строк и подвергнуть выделенные объекты какому-то действию. То-ли вызвать хранимую процедуру, то-ли сохранить в буфере обмена, чтобы потом вставить в другое окошечко, чтобы получить другой набор данных.

Парни, расскажите плиз как причаститься к написанию больших программ. Но только толковых. Бестолково большие программы - не интересны.

Это сообщение отредактировал(а) Zloxa - 24.4.2013, 00:12

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

Как? Разве ты этого ещё не понял? Для этого нужен ВПФ   

Э-э... Word, Photoshop большие программы?

Э-э... Visual Studio, Embarcadero RAD Studio ?   

Я не понял: толи это ты не понял, что последняя реплика была шуткой, толи ты понял и твоя реплика была шуткой. В последнем случае уже я твою шутку не понял   

Я тоже не понял, это ответы мне на вопрос - что есть большая программа?
Если так, то отвечу:




SKrivosein, Beltar, вам действительно часто приходится писать свой фотошоп и рад студию? Или же вы, скорее, как и я в отрасли занимаете нишу строительства велосипедов для бизнесса?

Zloxa, много лет тому назад я тоже имел подобный ворфлоу. Но потом меня научили, что увеличения качества ПО в 2 раза требует увеличения ресурсов раз в 5, в зависимости от ситуации. И бизнес готов платить. И тут на помощь приходят норм ЯП + Фреймворки, тулы, самые различные тесты, паттерны и прочие средства. Есть места, где риски очень велики, и нельзя наедятся на то, что программа написанная Злохой отработает верно.

Наверное, да, на марсоходе там.. в банкинге, в атомной промышленности.

Но таких мест, где готовы в пятеро увеличивать бюджет для увеличения качества в 2 раза - не так много. Мне такие места не попадаются. Мне, к сожалению, постоянно попадаются места, где сроки исполнения - вчера. И дело тут не в делфи. Делфи у меня в резюме идет как доп скилл, последней строчкой. Основной скилл у меня по орацлу. Орацл нищеброды не юзают.

Это сообщение отредактировал(а) Zloxa - 24.4.2013, 09:20

Zloxa, сначала про бедность, потом про богатство. Oracle есть деньги купить и на нём всё и заканчивается. )

Я так понимаю, первый ответ был адресован всё-таки мне и означал он, что эти большие программы были написаны без впф. Как бы указание на то, что дядявова не всегда прав  

serger, и к чему эта твоя фраза? Я констатировал факт. Айайай, да, вокруг одни негодяи, настоящего дартаньяна, одновременно богатого и щедрого хрен найдешь. Как правило, те, что действительно щедры, быстро перестают быть богатыми, те, кто богат - в лучшем случае рачительны, в худшем - те еще скряги.

Это сообщение отредактировал(а) Zloxa - 24.4.2013, 11:15

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



А вот когда я заявил подобное, на меня тут же накинулись оголтелые дефиноиды 



Юнит тесты тут неуместны, это вообще не задача тестирования. Это скорее release management. Это задача release engineer проверить, что на базу накатили все необходимые патчи. Для этого можно использовать всякие разные тулы. Если release engineer раздолбай и полагаться на него нельзя, то можно на старте приложения выполнять проверку целостности схемы. В любом случае это не тестирование.
А если уж так хочется тестировать БД, то выносим все запросы в файлы ресурсов, берем какой нибудь DbUnit или SQLUnit и гоняем тесты. Но даже эти тесты не смогут гарантировать, что в день Х когда у вас будет релиз release engineer накатит нужные патчи на базу.



Принципы разработки ПО не зависят от языка. В каком-то случае одни подходы предпочтительней, в другом случае другие, но сами принципы общие. И то что ты их не знаешь, наглядно показывает твой уровень как разработчика. Даже абракадабра и та признает пользу юнит тестирования включив DUnit в состав IDE, и кстати угадай откуда был слизан DUnit?



Гуй не был приоритетным для Sun, были высокие системные требования, не было доступа к нативным плюшкам системы. Для серверсайда это все неважно, потому там Ява взлетела. А вот на гуе подсуетилась МС, понятно что предоставив тесную интеграцию с ОС и Офисным пакетом, для чисто виндовой разработки Си-октоторп выглядит предпочтительней.

Добавлено через 7 минут и 58 секунд

Еще как юзают. Нищеброд это не количество денег не счету/в кармане.

Zloxa я уже так немного этой дискуссии посмеиваюсь   
Никто никого в этой теме не убедит, разве что иногда узнает чего то нового, да и то...

Понял, спасибо. Т.е. первый пункт из двух перечисленных через запятую - вычеркиваю.

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


Разве они накинулись? Они просто указали на места где еще можно использовать продукт. Можно не значит нужно. Так же как молотк нужен для забивания гвоздей, но можно им и орехи колотить. Однако ж для того, чтобы колоть орехи покупать молоток - тем более не целесообразно, чем меньше вероятность того, что тебе придется им еще и гвозди забивать.

Добавлено через 2 минуты

Ну так я и не читаю посты тех, кто тут для того чтобы убеждать.
Я читаю только посты тех, кто может что-то рассказать.

Ну и твои, почему-то. Почему - не знаю.