Ну есть не только Юнит-тесты... )

Добавлено через 1 минуту и 9 секунд
Ну и тесты ж полезны не только тем, что проверяют. Они повышают качество кода - причём только наличием своего присутствия.   

И получал по носу, что метод не найден. Ну да, зараза сродни склееному в тексте SQL.

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

Добавлено через 3 минуты и 5 секунд
Ой, хорошо-то как, когда ты один и никто тебе код не поломает...

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

Дак со скуки помрёте. Хотя наверное не привыкать ;)

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



Ага, скучно же, когда все работает, как часы.

Это сообщение отредактировал(а) Beltar - 23.4.2013, 19:15

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

Ну если вы на самом деле собрались письками мериться, то тогда и правила надо определить, основываясь на возможности изменения требований к тому же гую, вомзможности поддержки и развития проекта, возможности тестирования и т. д. Что прделожил ты? Создашь структуру базы, оговорите гуй и будете сравнивать количество строк. Я, честно говоря вообще не понимаю, как можно интерпретировать такой результат.
Тебе уже объяснили, что платформы типа впф, стали ответом на требования индустрии. Требования к софту и ко времени его разработки стали гораздо жестче чем раньше и таким образом перед разработчиками стоят совсем другие проблемы. Главной из них стала значительно возросшая сложность ПО. Именно поэтому стали так популярны шаблоны проектирования, модульные тесты и прочая дребедень, которая тебе не нужна. Естественно шаблоны позволяют решать практически любые проблемы проектирования, почти независимо от технологии и особенностей языка. Но когда платформа хорошо приспособлена для создания хорошей архитектуры, то таковая создается на ней меньшими усилиями. И в этом смысле, если единственным требованием к приложению будет его вид, а не архитектура, то о выгоде с точки зрения даже количества кода вряд ли можно говорить. А если она и будет, то возможно за счет некоторых возможностей языка, которые к конкретной технологии вроде как и не имеют отношения.
Следующий момент, который меня сильно смущает - я не понимаю, что вообще может показать количество строк. Иногда лаконичный код говорит о преимуществах языка или технологии, иногда об умениях того, кто его написал, но чаще такой код просто имеет худшее качество. Например, можно все описывать длинными и глубоко вложенными друг в друга выражениями. В таком коде все будет в одной строке, при этом код будет совершенно нечитабельным, да и если отладчик на нем запнется, то вряд ли ты сразу сможешь определить какая именно часть кода вызвала ошибку. Поэтому мне в принципе непонятно, что должно показать малое количество кода. Если твой код будет на десяток-другой строк меньше, это что будет означать? Что дельфа лучше впф что ли?  

Язык разметки - да, даже в названии это заложено. 

Ну, не знал.

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

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

Ну, селекты проверит, про остальные я как-то забыл, ну Злоха напомнил =)

Не все  

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

Ты неправильно интерпретируешь мой ответ. Есть вещи, которые тестить легко, а есть такие, которые тестить либо невозможно, либо очень трудно. Задача проектирования во многом как раз в том и состоит, чтобы тестированию можно было подвергнуть как можно больше логики, нуждающейся в тестировании. 
Удобно наверно передать контролу формулу, чтобы он тебе график отрисовал, но протестировать, что он рисует ты не сможешь. С другой стороны, если ты выделишь парсинг формулы в отдельный метод, грубо говоря генерацию набора точек в отдельный метод, а гуй-компоненту поручишь только выводить точки на экран, то протестировать правильность формирования точек по разным формулам ты вполне сможешь. Относительно эффекта не скажу, поскольку не очень понимаю о чем речь. Но суть в том, что в любом приложении можно выделить значительную часть логики, которая будет поддаваться тестированию, хотя реализация такого проекта может сильно отличаться от того, к чему ты привык.

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



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



Я по обстановке делаю. Иногда задача абсолютно тривиальна и можно бросить под кнопку, если что, потом скопипастить в отдельную процедуру. Иногда нет, тогда стараешься правильно разбить.



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

Может не про шаблоны вообще, а про отделение логики от гуя, но что-то в этом направлении было.

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

А если условия изменятся и в методе что-то надо будет изменить? Как проверить корректность внесенных изменений?

Об этих случаях я не говорю. Но у тебя в процессе этого обсуждения акценты все-таки несколько поменялись.



Рефакторинг - это достаточно много приемов и большинство направлено именно на изменение структуры программы.

Надо. Сравнить по идее можно только примерную трудоемкость и интерфейс. Потому что сейчас я не понимаю, что реальные возможности WPF, а что фикция. Т. е. VCL штука старая и создана исходя из работы под Win95 и ограниченность ресурсов, одно только деление ее графических контролов на TGraphicContol и TWinControl по наличию оконного дескриптора и канваса, показательно. Там сложнее сделать современный нтерфейс, с этим никто не спорит, но в принципе все рабочее и можно любой мыслимый контрол в сети найти. FMX пока вообще несерьезно. WPF же предлагает крутотенечку, только набирать ее, похоже, придется все равно ручками, а возможности по проверке правильности форматирования в дизайне ограничены. Сам дизайнер все не вылечат. Т. е. технология тоже не самая зрелая. Приложений написанных на WPF, я, скорее всего, вообще не видел.

А про архитектуру, ну при работе с базами отделение данных от модели само собой происходит. Уж чего-чего, но этого у Delphi не отнимешь, взглянуть на то, как работа с БД в WPF было бы интересно.



C++ way.



Паскаль в этом плане всегда превосходил и Си и плюсы, что не мешало наезжать на Delphi.

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

Жаль, я если честно, надеялся, что он при сборке преобразуется в код, а не сохраняется в ресурс связываясь с кодом в рантайме.



Это сообщение отредактировал(а) Zloxa - 23.4.2013, 21:07

Он преобразуется в специальный бинарный формат BAML. Тот в свою очередь сохраняет струтктуру XAML как есть, но просто делает более удобочитаемой для машины.

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

Понимаешь, C++ и Паскаль это не просто языки, это взаимоисключающие концепции о том, каким должен быть язык программирования. Паскаль фактически язык с авторазметкой исходника (те же procedure\function в стене текста хорошо видны) и принудительным соблюдением ряда правил, фанаты плюсов же считают, что язык им не указ и склонны к тому, чтобы иметь побольше фич, и возможностей писать емко, поскольку некоторые фичи порождают проблемы, то появляются фичи для решения этих проблем, и языку всегда есть куда расти.

Beltar да для простого интерфейса, без всяких там особеностей, руками набирать нечего не прийдётся. Слухи о глючности дизайнера сильно преувеличены.
Что значит "правильности форматирования" в твоём понимании? 
Здесь похоже даже между дотнетчиками похоже нет общего мнения:
А я например бленд использую паралельно студио, тем более что они позволяют работать одновремено. И ничего плохого в этом не нахожу.
Нaпример если у кого стоит Silverlight 5, могу показать XAML заготовку, зделаную так. Там практически нет кода С#, и неодного растрового image. Ну и в белах полях страниц будет много табличек а графиков... Это на чешском, что в данном случае неважно.
Не критиковать сильно   , это будет десктоп силверлайт, который будет использовать WCF с удалённым сервером. Пока это только бета-бета интерфейс.