Здравствуйте, Sheridan, Вы писали:
P>> Пока мне понятно, что ромбики ты нарисовал тольто потому, что в C++ есть возможность реализовать подобное. S>Нет. Это помогло мне дважды унаследоваться от одного объекта (точнее дважды от двух).
Ну и зачем? В таких построениях и без ромбиков забот хватает. Если кто-то попытается что-нибудь в твоем коде поправить, он нарвется на нехилый головняк. Вон в Java ромбиков нет, и то мне до недавнего времени приходилось неделями копаться, чтобы, казалось бы, простенький баг поправить. Причин две: наследование реализации, похожее на то, что ты нарисовал (без ромбиков, конечно) и отсутствие тестов. Но это уже позади.
P>> А вот как ты это все заставишь работать без тестов — это и в самом деле непонятно. S>В смысле? работает же.
Это оно у тебя в лабораторных условиях работает. А если дашь мало-мальски грамотному тестировщику — тут же перестанет работать.
S>Ты предлагаешь код притягивать за уша к тестам? Наоборот должжно быть.
Это у кого как. Правильные тесты таковы, что тестируемый код на них падает. А если тесты подгонять под тестируемый код, они ловить ничего не будут. Тесты — это формализованные требования к твоим классам, как-то так.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, dr.Chaos, вы писали:
C>> S>А разве код может чтото делать иное, кроме того что он делает? о0
C>> Бгг. Макс, с учётом того, что в с/с++ за счёт ошибки в адресной арифметике может произойти запись куда угодно, ты не в чём не можешь быть уверен. C>> Вот есть у меня массив идентификаторов и между местом заполнения и чтения (2 вложенных вызова и немного бизнес логики) туда успевает кто-то насрать. А ошибки в адресной арифметике не так уж сильно и заметны.
S>Ну так тут отладка нужна, а не тестирование. Тестирование всего лишь даст статистические данные — как часто вместо данных будет мусор.
Так вот тесты для того и нужны что бы как можно раньше обнаружить ошибку.
Приветствую, Privalov, вы писали:
P> S>Нет. Это помогло мне дважды унаследоваться от одного объекта (точнее дважды от двух).
P> Ну и зачем? В таких построениях и без ромбиков забот хватает. Если кто-то попытается что-нибудь в твоем коде поправить, он нарвется на нехилый головняк. Вон в Java ромбиков нет, и то мне до недавнего времени приходилось неделями копаться, чтобы, казалось бы, простенький баг поправить. Причин две: наследование реализации, похожее на то, что ты нарисовал (без ромбиков, конечно) и отсутствие тестов. Но это уже позади.
Ты предлагаешь усложнять реализацию, упрощая код? Спасибо, не надо. У меня хватает мозгов на код такой сложности.
P> S>В смысле? работает же. P> Это оно у тебя в лабораторных условиях работает. А если дашь мало-мальски грамотному тестировщику — тут же перестанет работать.
Он мне предоставит список действий, я починю. Обычный ход.
P> S>Ты предлагаешь код притягивать за уша к тестам? Наоборот должжно быть. P> Это у кого как. Правильные тесты таковы, что тестируемый код на них падает. А если тесты подгонять под тестируемый код, они ловить ничего не будут. Тесты — это формализованные требования к твоим классам, как-то так.
Это придется дохрена изменений вносить. Как минимум поддержку эмуляции пользователя (нажать на кнопку, ввести строку в поле). Либо тесты писать на чемто другом совершенно, что позволяет приложение подобным образом гонять. Ведь ошибка то не только в коде может быть, но и в привязках интерфейса к коду, не так ли?
Нахрена мне эта головная буль, если я и без нее справляюсь ничо так.
P> S>Ты предлагаешь код притягивать за уша к тестам? Наоборот должжно быть.
P> Это у кого как. Правильные тесты таковы, что тестируемый код на них падает. А если тесты подгонять под тестируемый код, они ловить ничего не будут. Тесты — это формализованные требования к твоим классам, как-то так.
Я все жду реакции типа "или помогайте или идите в ж.. со своими советами"
Здравствуйте, Sheridan, Вы писали:
S>Это придется дохрена изменений вносить. Как минимум поддержку эмуляции пользователя (нажать на кнопку, ввести строку в поле). Либо тесты писать на чемто другом совершенно, что позволяет приложение подобным образом гонять. Ведь ошибка то не только в коде может быть, но и в привязках интерфейса к коду, не так ли? S>Нахрена мне эта головная буль, если я и без нее справляюсь ничо так.
Ты бы на досуге почитал про тестирование хотя бы пару статей...
Начни хотя бы с Unit тестов...
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, alpha21264, Вы писали:
A>>Шеридан это не программист. Шеридан — это сисадмин.
A>>Еще не понятно?
A>>У хорошего сисадмина железяки круглые сутки сами работают. A>>Так что уж Шеридан-то хоть 8 часов в сутки может опен-сорсить.
M>И что? Я хоть слово против этого сказал?
M>Шеридан заявил, что оркестра можно и нужно разрабатывать в свободное от работы время. Когда ему сказали, что это нереально для крупного софта, он начал рассказывать сказки про админов и студентов.
M>Все до сих пор ждут, чтобы он в своей вечной мудрости снизошел и наконец-то рассказал, что делать нестудентам и неадминам
A>>А еще говорят, что в Микрософте (да да, том самом) работник может A>>(или даже должен?) 20% времени тратить на что-то не связанное с работой. A>>Типа они так саморазвитие поощряют.
M>И?
Ну вот когда в такой ситуации ставят "И?", я просто не могу не воскликнуть "ну какой-же ты тупой!".
Модератор, если будешь меня банить за слово "тупой", забань и Мамута за раздражающее поведение.
Устраивайся в Микрософт и будет у тебя время для опен-соурса (не обязательно Линукса).
Это только один из путей.
Мамут! Ты хочешь доказать, что у людей нет времени на опен соурс? Надорвешься.
У людей на опен-соурс время есть. И сообщение топикстартера говорит, что таки людей тысячи.
Каждый это делает по своему. Некто Сергей Брин для этого аж целую корпорацию припахал.
Здравствуйте, Sheridan, Вы писали:
S>Ну так тут отладка нужна, а не тестирование. Тестирование всего лишь даст статистические данные — как часто вместо данных будет мусор.
Отладка нужна когда уже есть корка. Это не говоря уже о том, что корка не всегда бывает . А вот выявить ситуацию когда оно падает — тут и нужны тесты. Ты всё равно ведь тестируешь когда пишешь что-либо, просто ты про них сразу забываешь ничего не записывая/кодируя.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, Demandred, Вы писали:
D>Ты бы на досуге почитал про тестирование хотя бы пару статей... D>Начни хотя бы с Unit тестов...
Позволю себе опять потроллить. Речь идет о программе для Linux, а там, как известно, если у пользователя что-то не работает, то этот пользователь — криворукий дебил. Так что, сдается мне, не только тесты не нужны, но и отладка тоже. И да здравствуют ромбики!
a> A>>А еще говорят, что в Микрософте (да да, том самом) работник может a> A>>(или даже должен?) 20% времени тратить на что-то не связанное с работой. a> A>>Типа они так саморазвитие поощряют.
a> M>И?
a> Ну вот когда в такой ситуации ставят "И?", я просто не могу не воскликнуть "ну какой-же ты тупой!". a> Модератор, если будешь меня банить за слово "тупой", забань и Мамута за раздражающее поведение. a> Устраивайся в Микрософт и будет у тебя время для опен-соурса (не обязательно Линукса). a> Это только один из путей.
Из таких известных компаний есть только Гугл. И достаточно погуглить, чтобы узнать, что эти 320% хороши только в теории
a> Мамут! Ты хочешь доказать, что у людей нет времени на опен соурс? Надорвешься. a> У людей на опен-соурс время есть. И сообщение топикстартера говорит, что таки людей тысячи.
a> Каждый это делает по своему. Некто Сергей Брин для этого аж целую корпорацию припахал.
Ого. У гугла внезапно появились опенсорс продукты, кроме Андроида? И да, напомню, что над андроидом работают full-time программисты, время которых оплачивает Гугл.
Ну, еще можно, наверное, вспомнить wave. Только вот незадача, над этим проектом тоже работали full-time программисты
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, Privalov, вы писали:
P>> S>Нет. Это помогло мне дважды унаследоваться от одного объекта (точнее дважды от двух).
P>> Ну и зачем? В таких построениях и без ромбиков забот хватает. Если кто-то попытается что-нибудь в твоем коде поправить, он нарвется на нехилый головняк. Вон в Java ромбиков нет, и то мне до недавнего времени приходилось неделями копаться, чтобы, казалось бы, простенький баг поправить. Причин две: наследование реализации, похожее на то, что ты нарисовал (без ромбиков, конечно) и отсутствие тестов. Но это уже позади. S>Ты предлагаешь усложнять реализацию, упрощая код? Спасибо, не надо. У меня хватает мозгов на код такой сложности.
P>> S>В смысле? работает же. P>> Это оно у тебя в лабораторных условиях работает. А если дашь мало-мальски грамотному тестировщику — тут же перестанет работать. S>Он мне предоставит список действий, я починю. Обычный ход.
А проверишь как?
Ты в курсе что такое, например, regression тестирование?
Объясняю, если не в курсе
Тебе дали баг со степами.
Ты его пофиксил.
И даже проверил, что не воспроизводится.
Но есть совершенно ненулевая вероятность, что поломалось что-то в другом месте.
Как ты это собрался проверять?
После кажного билда проводить полное ручное тестирование?
А еще бывают баги до которых из интерфейса не доберёшься.
Как ты их собрался тестить? В дебагере пеерменные менять?
P>> S>Ты предлагаешь код притягивать за уша к тестам? Наоборот должжно быть. P>> Это у кого как. Правильные тесты таковы, что тестируемый код на них падает. А если тесты подгонять под тестируемый код, они ловить ничего не будут. Тесты — это формализованные требования к твоим классам, как-то так. S>Это придется дохрена изменений вносить. Как минимум поддержку эмуляции пользователя (нажать на кнопку, ввести строку в поле). Либо тесты писать на чемто другом совершенно, что позволяет приложение подобным образом гонять. Ведь ошибка то не только в коде может быть, но и в привязках интерфейса к коду, не так ли? S>Нахрена мне эта головная буль, если я и без нее справляюсь ничо так.
Хохохо — это жесть просто.
Приветствую, midcyber, вы писали:
m> Причем тут код? Я спросил, как ты гарантируешь, что понял все, на что повлияет изменение
А иначе с какого великого я туда полезу?
Здравствуйте, genre, Вы писали:
G>Здравствуйте, alpha21264, Вы писали:
A>>Ты первый начал сравнивать программы с материальным производством. A>>А это сравнение изначально ОЧЕНЬ некорректно. Пора бы уже в ФАК занести. A>>Так что не обижайся.
G>Я сравниваю сложность работы над серьезным софтверным проектом с любой другой работой. Сложность работы над GNOME, а это сотни человеко-лет, запредельная для самоделкиных.
GNOME — это WindowManager. А WindowManager-ов в Юниксах как грязи. Что опровергает исходный тезис.
A>>И у тебя такой софистики минимум три экземпляра в одном сообщении. Перечислить остальные?
G>Давай.
1) Ты стал сравнивать программирование с реальным производством (это я уже писал в исходном сообщении)
Все отличия программирования от материального производства играют в пользу программирования.
2) Ты посчитал GNOME серьезным (то есть, большим проектом). Это почти правда. За исключением того,
что его никто не обязывает быть большим. Есть аналоги, которые меньше на порядки. Ну и вообще, тезис
о том, что программа обязательно должна быть огромным монстром, она как-то того... неправильная.
Не, я понимаю, что Микрософт по другому не умеет, но нас-то кто обязывает?
3) Когда ты назвал Гном большим проектом, ты забыл (намеренно умолчал) о том, что это не монолит,
а куча хоть и связанных, но все-таки отдельных программ.
4) Ну и все-таки факт, что самоделкины собирали у себя на коленке автомобили говорит о том, что ВРЕМЯ
(мы же о времени говорим) у людей на такие серьезные увлечения есть. А ты утверждаешь, что его нет.
5) Ну и ты самое главное забыл. Гном — существует. Вот че хочешь делай, а он есть.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, midcyber, вы писали:
m>> Причем тут код? Я спросил, как ты гарантируешь, что понял все, на что повлияет изменение S>А иначе с какого великого я туда полезу?
фак...броня крепка и танки быстры?
Вот растрелял ты память своим фиксом и отвалилась другая функциональность.(это крайний случай)
как ты это проверять собрался руками?
Или ты хочешь сказать, что такого не бывает?
Или ты поправил какой-то Helper класс.
А в другом месте тоже заложились на неправильное поведение.
Как ты это без тестов собираешься определить?
Прокликать все менюшки?
Здравствуйте, alpha21264, Вы писали:
A>GNOME — это WindowManager. А WindowManager-ов в Юниксах как грязи. Что опровергает исходный тезис.
Исходный тезис был, что такие вещи на коленке не делаются. Собственно про количество денег вложенное в open-source тут выше все сказали.
A>>>И у тебя такой софистики минимум три экземпляра в одном сообщении. Перечислить остальные?
G>>Давай.
A>1) Ты стал сравнивать программирование с реальным производством (это я уже писал в исходном сообщении) A>Все отличия программирования от материального производства играют в пользу программирования.
Я сравнивал сложность написания серьезных программных продуктов со сложностью серьезных реальных производств. Чувствуешь разницу.
A>2) Ты посчитал GNOME серьезным (то есть, большим проектом). Это почти правда. За исключением того, A>что его никто не обязывает быть большим. Есть аналоги, которые меньше на порядки. Ну и вообще, тезис A>о том, что программа обязательно должна быть огромным монстром, она как-то того... неправильная. A>Не, я понимаю, что Микрософт по другому не умеет, но нас-то кто обязывает?
что значит не обязывает? он таким является независимо от того обязывает ли его кто-то или нет.
A>3) Когда ты назвал Гном большим проектом, ты забыл (намеренно умолчал) о том, что это не монолит, A>а куча хоть и связанных, но все-таки отдельных программ.
и?
A>4) Ну и все-таки факт, что самоделкины собирали у себя на коленке автомобили говорит о том, что ВРЕМЯ A>(мы же о времени говорим) у людей на такие серьезные увлечения есть. А ты утверждаешь, что его нет.
Я говорил о качестве. Качество этих самоделок в сравнении с серьезными промышленными автомобилями говорит о том, что время может и есть, но качественную вещь на коленке создать практически невозможно.
A>5) Ну и ты самое главное забыл. Гном — существует. Вот че хочешь делай, а он есть.
Приветствую, blackhearted, вы писали:
b> S>А иначе с какого великого я туда полезу?
b> фак...броня крепка и танки быстры? b> Вот растрелял ты память своим фиксом и отвалилась другая функциональность.(это крайний случай) b> как ты это проверять собрался руками?
Да. Посмотреть откуда пользуется правленый мной код и проверить. Только я не могу понять -как можно отстрелить память гдето и не заметить.
b> Или ты поправил какой-то Helper класс. b> А в другом месте тоже заложились на неправильное поведение.
Отстрелить руки и ноги. Надо исправлять, а не херней заниматься.
Здравствуйте, Sheridan, Вы писали:
S>Приветствую, blackhearted, вы писали:
b>> S>А иначе с какого великого я туда полезу?
b>> фак...броня крепка и танки быстры? b>> Вот растрелял ты память своим фиксом и отвалилась другая функциональность.(это крайний случай) b>> как ты это проверять собрался руками? S>Да. Посмотреть откуда пользуется правленый мной код и проверить. Только я не могу понять -как можно отстрелить память гдето и не заметить.
b>> Или ты поправил какой-то Helper класс. b>> А в другом месте тоже заложились на неправильное поведение. S>Отстрелить руки и ноги. Надо исправлять, а не херней заниматься.
Сразу виден опытный человек.
Я тебе гарантирую, чт даже в твоём проекте есть баги о которых ты не подозреваешь.
И пока ты не покроешь нормально свой код тестами так и будешь спать в блаженном неведении и с мыслями, что ты круче всех.
Заметь, coverage не обязательно unit тестами.
Но у тея их нет вообще, соотвтетственно нет никаких гарантий, что любой, даже самый минорный фикс не поломает что-то другое.
При покрытии тестами такая гарантия(хоть и небольшая) появляется.
И уповать на то, что ты сможешь посмотреть все места где оно используется не стоит.
Судя по твоей диаграмме наследования баг в одном месте вероятно может всплыть через N a-ий совершенно в дргуом месте.
Только не нужно мне рассказывать, что я рассказываю сказки.
Сказочник в этом треде как раз ты — потому, что рассказываешь сказки о том, что можешь проконтролировать весь код.
проблема значительно усложняется при появлении хотябы еще одно человека в команде.
Я думаю, что ты способен догадаться почему.
Здравствуйте, Sheridan, Вы писали: b>> Или ты поправил какой-то Helper класс. b>> А в другом месте тоже заложились на неправильное поведение. S>Отстрелить руки и ноги. Надо исправлять, а не херней заниматься.
бида, бида. копай(с) куда только, хер его знает.
Здравствуйте, Sheridan, Вы писали:
P>> Как должны эти тесты выглядеть, впрочем, тоже. S>Ты предлагаешь код притягивать за уша к тестам? Наоборот должжно быть.
пичаль, пичаль. смысл от тестов, притянутых к коду? правильно, поменяли код, свалились тесты, значит ... фиксим тесты. верно, Шеридан?
з.ы. лично я уже лет 5ть наблюдаю эти уже ставшие унылыми потуги местечкового сисадмина научить "дзен-програмизму" рсдновских "говнокодеров".
Максим, ну ты же вроде неплохой специалист в своей сфере. ну сколько можно херней маятся. не твое это, не твое.
Бгг. Макс, с учётом того, что в с/с++ за счёт ошибки в адресной арифметике может произойти запись куда угодно, ты не в чём не можешь быть уверен.
. А вот выявить ситуацию когда оно падает — тут и нужны тесты. Ты всё равно ведь тестируешь когда пишешь что-либо, просто ты про них сразу забываешь ничего не записывая/кодируя.
