Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата --Ins-- @ 10.02.11, 09:30

Угу, но не потому что я пишу программы и мне пофиг на то, как они работают, а потому, что таких ошибок, которые ты собираешься ловить тестами, у меня даже не возникнет. Я просто пугаюсь когда порой читаю про юнит-тестирование. Авторы пишут что мол вспомните сколько времени и сил у вас забирает отладка, что типа большая часть времени разработки уходит не на написание кода, а на приведение его к работоспособному виду, поиск ошибок и т.д. и т.п. Это ж как так можно довести до такого состояния код, чтобы приводить его к работоспособному виду стоит гораздо дороже, чем собственно его разработать? Я всегда считал, что такое только индусам под силу. Я конечно возможно что-то делаю неправильно, но в моем случае 50% времени забирает проектирование классов, интерфейсов, 40% времени написание кода, и 10% - тестирование и отладка. На качество программ не жалуюсь

--Ins--, поработай в команде в конце концов, и не над Hello World, а над средней сложности продуктом Если ты не пишешь бизнес логику, то так и скажи, зачем же гнать на очевидные вещи...
Юнит тесты, экономят кучу времени на отладку как правило, а также на решение внезапно возникшей проблемы... представь только, что есть у тебя общий класс, который юзается много где, ты решил его прорефакторить, ну прорефакторил, проверил пару сценариев - вроде все работает, ты доволен, а клиент выхватил AV. Да и хотя бы основные сценарии воспроизведения, ты будешь долго проходить... а вот Юнит тесты тебе сразу же протестируют все базовые сценариии... так шо ты ошибаешься...
Ты еще скажи, что ты никогда не делаешь ошибок;)

Сообщение отредактировано: KILLER - 10.02.11, 11:33

Цитата --Ins-- @ 10.02.11, 09:30

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

Во-первых, ты читаешь что-то странное про юнит-тестирование.
Во-вторых, если ты пишешь только такие проекты, что описывал в соседней теме, то и трудностей у тебя нет.
В-третьих, почитай что-нибудь о разработке ПО. От Бруксов до Макконнеллов и др.

Цитата

Я конечно возможно что-то делаю неправильно, но в моем случае 50% времени забирает проектирование классов, интерфейсов, 40% времени написание кода, и 10% - тестирование и отладка.

В целом примерно так. А потом ты передаешь то, что сделал, отделу тестирования.

Цитата

Цитата D_KEY @ 09.02.11, 21:17

--Ins--, у тебя мания величия Delphi

Нет, это у вас дельфифобия

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

Цитата D_KEY @ 10.02.11, 11:47

Во-первых, ты читаешь что-то странное про юнит-тестирование.

Из того, что есть под рукой - Мартин Фаулер. Достаточно авторитетный автор? Я думаю да. Цитирую...

Цитата

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

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

Цитата D_KEY @ 10.02.11, 11:47

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

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

Сообщение отредактировано: --Ins-- - 10.02.11, 12:34

Цитата --Ins-- @ 10.02.11, 12:29

Цитата

Из того, что есть под рукой - Мартин Фаулер. Достаточно авторитетный автор? Я думаю да. Цитирую...
Если посмотреть, на что уходит время у большинства программистов, то окажется, что на написание кода в действительности тратится весьма небольшая его часть. Некоторое время уходит на уяснение задачи, еще какая-то часть - на проектирование, а львиную долю времени занимает отладка. Уверен, что каждый читатель может припомнить длинные часы отладки, часто до позднего вечера...

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

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

Цитата

Цитата D_KEY @ 10.02.11, 11:47

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

Угу. А какие они должны быть? Степень отвественности в моих проектах весьма высока, это не калькулятор настольный.

По уровню сложности они не сильно отличаются, ИМХО.
Были хотя бы проекты больше полугода работы, скажем, на 3х человек?

Цитата

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

Значит был отдел тестирования. И что, не находил ошибок?

Цитата

Ели ты намекаешь что я не работал в команде, то разочарую тебя, большую часть времени я работал в команде

Замечательно. И то, что делают другие, не прогоняя юнит-тесты перед коммитами/передачей на тестирование, тебя не волнует?

Цитата D_KEY @ 10.02.11, 12:36

Я так понимаю, что под отладкой и исправлением ошибок ты понимаешь то, что возникает при создании ПО и отловлено в этот же период и самим тобой?

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

Цитата D_KEY @ 10.02.11, 12:36

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

Были, ПО для электронных микроскопов - нас было от трех до семи человек (в разные этапы любди приходили и уходили), 4 года

Цитата D_KEY @ 10.02.11, 12:36

И что, не находил ошибок?

Находил. Речь ведь о том, сколько времени уходит на их исправление, так?

Цитата D_KEY @ 10.02.11, 12:36

И то, что делают другие, не прогоняя юнит-тесты перед коммитами/передачей на тестирование, тебя не волнует?

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

Добавлено 10.02.11, 12:48

Цитата D_KEY @ 10.02.11, 12:36

По уровню сложности они не сильно отличаются, ИМХО.

А ты их видел? Наишешь на коленке за пару деньков, а?

Сообщение отредактировано: --Ins-- - 10.02.11, 12:48

Цитата --Ins-- @ 10.02.11, 12:43

Цитата D_KEY @ 10.02.11, 12:36

Я так понимаю, что под отладкой и исправлением ошибок ты понимаешь то, что возникает при создании ПО и отловлено в этот же период и самим тобой?

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

Кстати, например, Брукс дает такие оценки

Цитата

проектирование - 1/3,
написание команд -1/6,
отладка компонент и отдельных подсистем - 1/4,
системная (комплексная) отладка всех компонент - 1/4.

Я с ним, в принципе, соглашусь. Но у меня только перекос от отладки компонент в сторону системной отладки.

Цитата

Цитата D_KEY @ 10.02.11, 12:36

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

Были, ПО для электронных микроскопов - нас было от трех до семи человек (в разные этапы любди приходили и уходили), 4 года

И что, процесс кодирования(не проектирования) нового функционала занимал больше, чем процесс поиска ошибок и их последующего устранения?

Цитата

Особенно нет, так как у нас было разделение ответственностей. В моем коде без моего ведома и с моего согласия никто ничего нового не сделает.

Даже если так. Есть ведь общие части, исправив которые, можно что-то у кого-то сломать.

Цитата

Цитата D_KEY @ 10.02.11, 12:36

По уровню сложности они не сильно отличаются, ИМХО.

А ты их видел? Наишешь на коленке за пару деньков, а?

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

Сообщение отредактировано: D_KEY - 10.02.11, 13:04

Цитата D_KEY @ 10.02.11, 13:03

И что, процесс кодирования(не проектирования) нового функционала занимал больше, чем процесс поиска ошибок и их последующего устранения?

Естественно, и меня удивляет когда иначе, если честно. И это еще притом, что с проектированием у нас не все было гладко

Цитата D_KEY @ 10.02.11, 13:03

Я с ним, в принципе, соглашусь. Но у меня только перекос от отладки компонент в сторону системной отладки.

А у меня - наоборот. Принцип черного ящика: клиент работает с неким модулем/компонентом как с черным ящиком, и если последний отлажен - то ему все равно в каком окружении работать. Я считаю, что и при работе в команде этот принцип должен соблюдаться - твой напарник работает с твоими модулями/компонентами как с черным ящиком, и тогда просто всем: мне - так как меня не волнует что он там в своем клиентском коде сделает, и его - так как он работает с моим вьюером данных микросъемки так же, как и с кнопокой TButton, например. Мы с ним просто согласуем интерфейс. Это к слову о декомпозиции...

Цитата D_KEY @ 10.02.11, 13:03

Ну я исходил из того, что ты описал...

Т.е. по описанию "программа для рисования" ты сделаешь вывод, что MS Visio или Corel Draw - это программка не сложнее каклькулятора?

Сообщение отредактировано: --Ins-- - 10.02.11, 13:18

Цитата --Ins-- @ 10.02.11, 13:17

Цитата D_KEY @ 10.02.11, 13:03

И что, процесс кодирования(не проектирования) нового функционала занимал больше, чем процесс поиска ошибок и их последующего устранения?

Естественно, и меня удивляет когда иначе, если честно. И это еще притом, что с проектированием у нас не все было гладко

Мне кажется, что ты или много проектируешь при кодировании, или просто психологически так воспринимаешь(кстати, так у всех), джиру/редмайн/и т.п. использовали?

Цитата

А у меня - наоборот. Принцип черного ящика: клиент работает с неким модулем/компонентом как с черным ящиком, и если последний отлажен - то ему все равно в каком окружении работать. Я считаю, что и при работе в команде этот принцип должен соблюдаться - твой напарник работает с твоими модулями/компонентами как с черным ящиком, и тогда просто всем: мне - так как меня не волнует что он там в своем клиентском коде сделает, и его - так как он работает с моим вьюером данных микросъемки так же, как и с кнопокой TButton, например. Мы с ним просто согласуем интерфейс. Это к слову о декомпозиции...

Так и есть. Более того, системное тестирование и предполагает наличие отлаженных и самостоятельных компонентов Кстати, под системой понимается не только отдельное приложение, но и группа системных программ/демонов/клиентских программ/утилит и т.п.

Цитата

Цитата D_KEY @ 10.02.11, 13:03

Ну я исходил из того, что ты описал...

Т.е. по описанию "программа для рисования" ты сделаешь вывод, что MS Visio или Corel Draw - это программка не сложнее каклькулятора?

Нет, этого будет не достаточно. Я тебя обидеть не хотел и не вкладывал негативного смысла.

Цитата D_KEY @ 10.02.11, 13:26

Мне кажется, что ты или много проектируешь при кодировании

Я собственно именно в этом удовольствие от программирования и нахожу.

Цитата D_KEY @ 10.02.11, 13:26

джиру/редмайн/и т.п. использовали?

Главный наш какие-то case-средства использовал, я систему в целом не проектировал, его схем и моделей не видел.

Цитата D_KEY @ 10.02.11, 13:26

Нет, этого будет не достаточно. Я тебя обидеть не хотел и не вкладывал негативного смысла.

Я знаю что не хотел, я тебе намекаю на другое: у тебя предвзятое отношение к Delphi и к программам, которые на нем пишутся. Ты наверное видел много калькуляторов со скиновыми движками, на Delphi писанных, чего греха таить - это действительно так, но тот факт, что создать красивый UI в Delphi может даже школьник не означает, что инструмент ни для чего другого не годится. Сложный проект - это не обязательно программа, которая сама доказывает Великую Теорему Ферма или расшифровывает криптотексты АНБ США. Сложность программы может заключаться, например, в ее интеграции с другими программами и программными комплексами. В моих же программах обычно самое сложное - это визуализация данных и процессов. Юнит-тестами это не отладишь все равно

Человеку свойственно заблуждаться. Хуже того, ему свойственно упорствовать в своих заблуждениях.

Цитата --Ins-- @ 10.02.11, 13:39

Цитата D_KEY @ 10.02.11, 13:26

Мне кажется, что ты или много проектируешь при кодировании

Я собственно именно в этом удовольствие от программирования и нахожу.

Но речь идет о кодировании. Проектирование - да, много времени отнимает. Непосредственный перенос проектных решений в код - не так уж и много.

Цитата

Цитата D_KEY @ 10.02.11, 13:26

джиру/редмайн/и т.п. использовали?

Главный наш какие-то case-средства использовал, я систему в целом не проектировал, его схем и моделей не видел.

Я говорил о системе управления проектами и багтрекинга.
Кстати, рекомендую redmine - великолепная система.
http://ru.wikipedia.org/wiki/Redmine

Цитата

В моих же программах обычно самое сложное - это визуализация данных и процессов. Юнит-тестами это не отладишь все равно

Представления юнит тестами отладить трудно, а вот модели - вполне.

Цитата D_KEY @ 10.02.11, 20:57

Я говорил о системе управления проектами и багтрекинга.

Ясно. Тогда Trac

Цитата D_KEY @ 10.02.11, 20:57

Кстати, рекомендую redmine - великолепная система.
http://ru.wikipedia.org/wiki/Redmine

Да, мне тоже понравилась - без проблем встала на генте, без проблем вжилась в апач, наверно не больше двадцати минут на развёртывание потратил. Теперь потихоньку переводим на неё проекты.

Сообщение отредактировано: Adil - 11.02.11, 00:23

std::sort<vector<A>::iterator>(
    b.begin(),
    b.end(),
       (&_1->*&A::x <  &_2->*&A::x && bind(pStrCmp, &_1->*&A::y, &_2->*&A::y) == 0)
    || (&_1->*&A::x >= &_2->*&A::x && bind(pStrCmp, &_1->*&A::y, &_2->*&A::y) != 0)
);

отличный пример читабельности С++... =)

Сообщение отредактировано: korvin - 14.02.11, 18:37

У тебя примеры на Хаскелле все такие, не надо тут на C++ гнать