T>И сразу же завершу: я говорил не о непреклонном принципе разработки, а о достижимости некоторой ситуации.
проведу аналогию с законами, который пишутся людьми для людей.
законов-то раз-два и обчелся и они доступны каждому, и то там не получается достичь той цели, которую ты ставишь.
а кода много больше, он намного менее понятен людям, более закрытый (более оторванный от жизни людей) — соответственно задача еще менее реальная.
проблема в том, что при модификации чего-либо надо много чего держать в голове одновременно (причем счет может идти на миллиарды ситуаций), а человеческий мозг имеет довольно серьезные ограничения по количеству одновременно оперируемых понятий.
E>Интересно, почему этот принцип не работал при решении проблемы 2000-го года?
в смысле не работал?
очень даже работал, во многих местах лишь меняли функцию сложения и вычитания времени, когда год 00 — год 99 получалось 1 год, при этом так и оставляя две цифры.
в тех местах где даты между годами сравнивать(оперировать) не надо, даже это не делали
т.е. люди снаружи договаривались о том, что если они видят цифры 00-49, то это 21 первый век, а если 50-99, то это 20 век
E>>Интересно, почему этот принцип не работал при решении проблемы 2000-го года?
DG>в смысле не работал?
В смысле, что во многих местах софт переписывали и базы перелопачивали.
DG>очень даже работал, во многих местах лишь меняли функцию сложения и вычитания времени, когда год 00 — год 99 получалось 1 год, при этом так и оставляя две цифры.
DG>в тех местах где даты между годами сравнивать(оперировать) не надо, даже это не делали
DG>т.е. люди снаружи договаривались о том, что если они видят цифры 00-49, то это 21 первый век, а если 50-99, то это 20 век
Да уж, классный способ работы. Как раз, чтобы в 2090-х годах специалисты по COBOL-у опять стали восстребованны.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, DarkGray, Вы писали:
T>>И сразу же завершу: я говорил не о непреклонном принципе разработки, а о достижимости некоторой ситуации.
DG>проведу аналогию с законами, который пишутся людьми для людей. DG>законов-то раз-два и обчелся и они доступны каждому, и то там не получается достичь той цели, которую ты ставишь.
Какую же я ставлю цель?
DG>а кода много больше, он намного менее понятен людям, более закрытый (более оторванный от жизни людей) — соответственно задача еще менее реальная.
Поэтому принято использовать специально обученных людей — программистов. Для них это жизнь.
DG>проблема в том, что при модификации чего-либо надо много чего держать в голове одновременно (причем счет может идти на миллиарды ситуаций), а человеческий мозг имеет довольно серьезные ограничения по количеству одновременно оперируемых понятий.
Это решается декомпозицией. Никакой проблемы я тут не вижу.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>Пожалуй, подпишусь.
T>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
Искать компонент на любой случай жизни — это идиотизм. Искать компонент для решения конкретной задачи — это нормально и очень правильно во многих ситуациях.
Конечно лучше иметь доступ к исходникам компонентов. Но и без них компоненты и компонентное программирование вполне себе удобный способ производства ПО. Скажем лучше иметь грид (визуальный компонент) написанный знающей в этом деле толк конторой, но не имеющий исходников, нежели грид с исходниками но написанный черти-кем на коленке. Попровить его все равно невозможно, так как на это уйдет оставшаяся часть жизни. Проще выкинуть и взять другой.
Другой пример компоненты гуи из стандартных библиотек. И вообще стандартные библиотеки. Они отлично расшяряются и то, что к ним нет исходников не является проблемой.
Просто лично ты никогда не создавал объемного ПО (которое не создать в одиночку) и не можешь понять зачем это нужно. Кнут вообще теоретик-алгоритмист из прошлого века. К его мнению нужно относиться очень осторожно.
Исходный же код, на мой взгляд, намного более важен не для исправления чужих багов, а для понимания работы кода. Особенно это нужно когда ты развиваешь чужие продукты (например встраиваешь язык в некоторую IDE). Но для этой цели обычно бывает достаточно декомпилированного кода (если речь идет о дотнете или яве). Хотя конечно лучше иметь возможность пройтись по нему отладчиком.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ИМХО, всего надо вмеру.
Я наблюдал как чрезмерно глобализированный код становился кучей воркараундов...
Чрезмерная глобализация ничем не лучше чем чрезмерное "говно-кодирование" (что означает тупо to make it work или re-editable в полном смысле всё девелопится заново каждый раз)
На мой взгляд данное утверждение справедливо для мелких тулзеней, которые выполняют очень мелкую работу и не планируют расширятся..
Таких очень много в линухе...
T>Пожалуй, подпишусь.
T>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
так же подпишусь.
мне несколько раз приходилось править ошибки/добавлять незначительный функционал в open source программы, которыми я пользуюсь.
если бы эти программы использовали закрытые компоненты или вовсе были закрыты, то не уверен, что мне бы это удалось
на мой взгляд это вообще очевидная истина — написать идеальный интерфейс не получится, хоть сколько-нибудь сложная абстракция наверняка окажется "дырявой". Так что рано или поздно все написанное приходится фиксить, конечно при условии востребованности написанного...
T>Пожалуй, подпишусь.
T>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
В чем проблема иметь возможность быстро всё исправить в reusable code?
Имхо, reusable code и untouchable black box or toolkit — это немножко разные вещи.
В словосочетании "reusable code" ключевое слово — это слово "код", который, естественно, можно исправить, если в нем баг.
И если ты стараешься поддерживать его в reusable-состоянии (т.е. он _один_ зовется отовсюду) — в чем проблема?
А вот если под "re-editable code" понимается copy/paste с исправлениями под конкретную ситуацию, то я тебе сейчас расскажу, чем это заканчивается в реальных проектах (по собственному опыту).
Я имел удовольствие работать в одном огромном 10-летнем проекте.
В какой-то момент в одном месте обнаружились ошибки с округлением.
Когда я стал раскапывать ситуация с округлением, оказалось, что в проекте набралось 3-7 (не помню уже точно, сколько) функций округления, все, естественно, простые (что там может быть сложного в округлении), все явно сделанные из одной исходной функции (суда по именам локальных переменных) путем применения подхода "re-editable code". Разница была лишь в обработке всяких граничных случаев. Так как все это умножается на принцип "работает — не трогай" (софт ворочает миллионами долларов), я думаю, сейчас количество этих функций там уже подбирается к 10. И отследить, где какое округление в результате используется — это дело нескольких дней.
А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.
T>>Пожалуй, подпишусь.
T>>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
VD>Искать компонент на любой случай жизни — это идиотизм. Искать компонент для решения конкретной задачи — это нормально и очень правильно во многих ситуациях.
Так вот, моё утверждение: "Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни."
"Искать" и "найти" — разные вещи. Искать можно всегда, вероятность найти — низка.
Современные средства программирования достаточно хороши, чтобы при наличии исходников можно было бы подправить компонент до поддержки твоих нужд.
Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.
Что ещё. Поскольку писать всё проще и проще, смысл имеет писать только очень сложные вещи, которые тяжело воспроизвести. А они, в общем, гораздо уже по области применения, чем простые.
Все остальные твои соображения я опущу. Они к делу не относятся. Только приведу подходящую цитату с с bash.org (без .ru):
Здравствуйте, StevenIvanov, Вы писали:
SI>Здравствуйте, thesz, Вы писали:
SI>на мой взгляд это вообще очевидная истина — написать идеальный интерфейс не получится, хоть сколько-нибудь сложная абстракция наверняка окажется "дырявой". Так что рано или поздно все написанное приходится фиксить, конечно при условии востребованности написанного...
Более того, современные практики и инструменты упрощают это дело всё больше и больше. Поэтому вероятность справится с улучшением за определённый срок всё время растёт, а вероятность найти подходящий компонент в тот же срок падает: растёт количество узко-специализированных компонент, которые тяжело использовать в общем случае.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
T>>Пожалуй, подпишусь.
T>>Возможность быстро всё исправить более достижима, чем возможность найти компонент на любой случай жизни.
J>В чем проблема иметь возможность быстро всё исправить в reusable code?
J>Имхо, reusable code и untouchable black box or toolkit — это немножко разные вещи. J>В словосочетании "reusable code" ключевое слово — это слово "код", который, естественно, можно исправить, если в нем баг. J>И если ты стараешься поддерживать его в reusable-состоянии (т.е. он _один_ зовется отовсюду) — в чем проблема?
Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?
Что самое интересное, вероятность правильной работы кода после исправлений растёт со временем. Компиляторы, дебаггеры, всякие валгринды с параллельными студиями интела... Вчера везде было проще использовать чёрный ящик, сегодня уже не в столь многих местах, а завтра вообще чёрных ящиков останется раз, два и обчёлся.
J>А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.
Стоимость исправления ошибки растёт с увеличением времени с момента её внесения. Это, вроде, медицинский факт, я не думаю, что ты будешь с этим спорить.
Собственно, "запрет" на изменения в повторно используемом коде как раз с этим и связан — нам не хочется исправлять ошибки в уже имеющемся коде.
Поэтому и такое количество округлений: лучше я внесу ошибку в свой собственный код и быстро поправлю, чем внесу исправление в чужой код. Последнее потребует от меня вылезти вне зоны моей ответственности.
Так что я понимаю тех разработчиков.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
T>Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?
Для решения этой проблемы существуют юнит-тесты.
T>Что самое интересное, вероятность правильной работы кода после исправлений растёт со временем. Компиляторы, дебаггеры, всякие валгринды с параллельными студиями интела... Вчера везде было проще использовать чёрный ящик, сегодня уже не в столь многих местах, а завтра вообще чёрных ящиков останется раз, два и обчёлся.
Юнит-тесты все же надежнее и проще.
Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.
J>>А вот если бы с самого начала был _один_ reusable компонент/класс/что-угодно "округлятель" и не разрешалось бы плодить его "легко исправляемые копии", то этого геморроя не было бы.
T>Стоимость исправления ошибки растёт с увеличением времени с момента её внесения. Это, вроде, медицинский факт, я не думаю, что ты будешь с этим спорить.
Не буду.
T>Собственно, "запрет" на изменения в повторно используемом коде как раз с этим и связан — нам не хочется исправлять ошибки в уже имеющемся коде.
Ну вот это, имхо, подход, которому не должно быть места в нормальной разработке.
Потму что ты фактически говоришь: "Я нашел баг, который проявляется в этом месте, он может проявиться еще в сотне других мест, но я не хочу их все проверять и фиксить, поэтому займусь индус-кодерством (т.е. copy/paste)."
Так можно делать только в случае срочных заплаток, с обязательной проверкой всего, иначе просто растет твой долг (technical debt), который рано или поздно придется выплачивать, не тебе, так твоим коллегам.
А если долго не выплачивать, то это просто приведет к банкротству (проект будет проще выкинуть целиком и написать заново, чем продолжать поддерживать).
T>Поэтому и такое количество округлений: лучше я внесу ошибку в свой собственный код и быстро поправлю, чем внесу исправление в чужой код. Последнее потребует от меня вылезти вне зоны моей ответственности. T>Так что я понимаю тех разработчиков.
Этот подход был в свое время хорошо показан Райкиным: "К пуговицам претензии есть?"
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, thesz, Вы писали:
T>>Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?
J>Для решения этой проблемы существуют юнит-тесты.
А если их изначально не было? Как они решат эту проблему?
(кстати, уверен, это именно твой случай)
T>>Что самое интересное, вероятность правильной работы кода после исправлений растёт со временем. Компиляторы, дебаггеры, всякие валгринды с параллельными студиями интела... Вчера везде было проще использовать чёрный ящик, сегодня уже не в столь многих местах, а завтра вообще чёрных ящиков останется раз, два и обчёлся. J>Юнит-тесты все же надежнее и проще. J>Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.
Здравствуйте, thesz, Вы писали:
T>>>Проблема в поддержке инвариантов. Ты поправил повторно используемый код, ты уверен, что он правильно заработает во всех местах его использования?
J>>Для решения этой проблемы существуют юнит-тесты.
T>А если их изначально не было? Как они решат эту проблему?
Изначально там тестов не было вообще.
А если в общем говорить, то тестов было недостаточно, и не было теста, который покрывал бы требуемые граничные случаи.
Стало быть, на этот фикс пишется соответствующий юнит-тест, который этот граничный случай будет проверять.
T>(кстати, уверен, это именно твой случай)
Слава богу, это уже несколько лет не мой случай
T>>>Что самое интересное, вероятность правильной работы кода после исправлений растёт со временем. Компиляторы, дебаггеры, всякие валгринды с параллельными студиями интела... Вчера везде было проще использовать чёрный ящик, сегодня уже не в столь многих местах, а завтра вообще чёрных ящиков останется раз, два и обчёлся. J>>Юнит-тесты все же надежнее и проще. J>>Хотя бы потому, что тебе не нужно запускать все тот список программ, что ты привел.
T>Правильный компилятор
Ты передергиваешь. "Компиляторы, дебаггеры, всякие валгринды", удобство и функциональность которых улучшаются со временем, не предполагают смены языка, как в случае перехода на зависимые типы, когда старый компонент по-любому не может быть использован, просто потому что язык другой.
Понятно, что на бейсике писать удобнее, чем на ассемблере, на С++ — удобнее, чем на бейсике, и т.д, с этим никто не спорит.
T>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".
Кстати, интересно было бы посмотреть, как на зависимых типах будет выглядеть оформление десятка граничных случаев.
Боюсь, что с ростом сложности требований к типам потребуется настолько сложое описание этого типа, что потребуется дебаггер для того, чтоб убедиться, что ты правильно все записал.
В то время как при помощи юнит-тестов подобные вещи выражаются очень просто, хотя, естественно, они не являются строгим доказательством корректности, как в случае использования зависимых типов.
Просто, имхо, баланс должен быть.
Что просто выразить через систему типов — должно быть выражено там, а что проще через простейшие юнит-тесты в противовес килобайту зависимых типов — должно быть в тестах.
T>Современные средства программирования достаточно хороши, чтобы при наличии исходников можно было бы подправить компонент до поддержки твоих нужд.
T>Если мы зафиксируем некоторый срок, то вероятность дописать компонент до нужного уровня становится всё выше и выше с течением времени. Грубо говоря, вчера было труднее написать, чем найти, сегодня проще написать.
А объем этого кода в геометрической прогрессии больше.
T>Мои текущие нападки на юнит-тесты должны рассматриваться в струе "средства программирования делают изменения более дешёвыми".
Цель ясна. И с ней наверное согласны. Но это не отменяет того факта, что разработка не становится дешевле, потому что избавившись от сложности на низком уровне, мы приобретаем сложность и многовариантность (что практически то же самое) на высоком.
