|
| Рефлексия интерфейсов вместо регрессионных тестов |
#148925 |
|
Автор: Osoka
Дата: 11 Июня 2009 23:31
Существует ли какой-нибудь архитектурный подход, основанный на использовании интерфейсов (конструкция из ООП) и саморефлексии программы в отношении взаимосвязей объектов в программе на основе соответствия интерфейсам, который позволял бы отказаться от использования регрессионных тестов в проектах? |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148931 |
|
Автор: Трикипау
Дата: 12 Июня 2009 01:34
не пугайте людей такими словами! особенно программистов  |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148933 |
|
Автор: -=Lucky=- 
Дата: 12 Июня 2009 01:59
не знаю. а зачем отказываться?
зы: при помощи интерфейсов отмечают статические спецификации, а тестов - поведенческие. одни другим не мешают. если ничего не путаю. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148942 |
|
Автор: Osoka
Дата: 12 Июня 2009 14:10
Начинающий, а вы имели ввиду гугль молчит или "гугль молчит"?
Ладно, сформулирую, по другому. Существует ли теорема о корреляции обладания кодером информацией о связи объектов между собой в его программе и степенью неизвестности координат (мест) образования ошибок в результате
добавления, изменения или удаления части кода программы. И как практическое следствие этой теоремы, существует ли решение, которое позволяло бы отказаться от регрессионных тестов, как средства поиска ошибок через наблюдение следствий произведенных инзменений в пользу некоего паттерна, основанного на
саморефлексии кода, который знает все свои внутренние связи и поэтому способен увидеть все потенциально зависимые элементы и как следствие отпала бы необходимость искать ошибки с помощью регрессинных тестов.
Я знаю, существует методика инверсия контроля, основанная на использовании
"менеджеров связи", но почему-то с ними по-прежнему используются регрессионные тесты.
PS. Ну, а моя личная мотивация в этом вопросе, наверное, очевидна. Хочется составлять меньше регрессионных тестов, меньше их запускать и при этом сохранить управляемость кода при его росте. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148943 |
|
Автор: Osoka
Дата: 12 Июня 2009 14:14
Или ещё так: я знаю, что на нашей планете за все надо платить и при решении того или иного вопроса нужно лишь решить кто будет платить, т.е. за чей счет будет решен вопрос. Поэтому третья формулировка моего вопроса может звучать так, существует ли какой-нибудь паттерн, основанный на использовании
исключительно средств компилятора // интерпретатора, который позволяет решить задачу поиска кросс-ошибок, возникающих вследствие внесения изменения в уже существующий код, т.е. решать ту же задачу, что и регрессионные тесты. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148944 |
|
Автор: Начинающий Программист (О пользователе)
Дата: 12 Июня 2009 15:33
Ах **тестов**! Я прочитал как "текстов", сначала.
А соседнем тереде прочитал вместо "Не поняли очевидно всех масштабов этой золотой жилы" как "Не поняли очевидно всех масштабов этой золотой жопы", ну да.
1. Почему таки "регрессионных"? Вы используете тесты только для контроля
работоспособности кода после внесения изменений? Это только половина их функционала, при активном юнит-тестировании лучше полностью перейти на светлую сторону TDD - т.е. тест становится определяющим.
Необходимость изменений в коде диктуется изменениями требований.
Требования
формализуются в виде тестов.
Поэтому при изменении требований сначала меняется тест, потом корректируется код.
Когда тест проходит успешно, считается, что требование выполнено.
Ну это в теории, разумеется, на практике это выглядит так:
http://www.youtube.com/watch?v=l1wKO3rID9g
2. Такой теоремы не существует.
Проблема в наличии динамического состояния наследования и приведения типов. И в том, что теоремы могут
существовать только в формальных теориях, да.
Т.е. если алгоритм использует переменную типа IMyType в языках с динамическим состоянием конкретный тип можно узнать только в процессе выполнения программы (и он может менятся более того). А с приведенем типов вообще всё плохо: можно даункастить и
апкастить к чему попало и что там на самом деле никакими статическим средствами не узнать (например, название типа может вообще вводиться пользователем с клавиатуры).
Но тут еще стоит определиться, что является "координатами ошибки". По мне так ошибка - нарушение объектом контракта (в
широком смысле, т.е. когда объект говорит, что Sum(2, 2) = 5 это тоже нарушение контракта). Т.е. в результате внесения изменений ошибка может образоваться только в месте внесения изменений и нигде больше. Если для вас "координаты ошибки" - это какое-то другое место в программе, где 5 вызывает
какой-то критический сбой, надо сперва определиться, что считать таким местом.
Ну еще ощибки могут быть вызваны изменением контракта. Т.е. когда действительно надо, чтобы по контракту Sum(2, 2) стало 5, но некоторые потребители к этому не готовы. Тогда задача сводится к определению
всех потребителей, но это не возможно по описанной выше причине. Еще из-за транзитивности зависимостей "потребителем" скорее всего окажется 95% оставшегося кода. Т.е. в такой "локализации" мало толку.
Для борьбы с транзитивностью можно пользоваться следующим предположением: мы меняем
контракт A. Его потребителем является объект b, который в свою очередь реализует контракт B. Мы считаем, что ошибка есть нарушение контракта B (т.к. мы его не меняли). Отсюда следует, что ошибки нужно искать в изменяемых объектах и в их непосредственных потребителях. Опять же поиск ошибок есть
проверка выполнения контрактов, т.е. опять же тестирование.
Чтобы кнопки меньше жать, можно воспользоваться каким-нибудь языком, поддерживающим design by contract методологию. Правда они все равно всего не тестируют, просто более серьезная проверка, чем та, которую обеспечивает
статическая типизация в жавке, крестах или решеточке.
Самые серьезные статические проверки, насколько мне известно, строятся на intuitionistic type theory (http://en.wikipedia.org/wiki/Intuitionistic_type_t... особенно сюда http://en.wikipedia.org/wiki/Dependent_type советую зайти), даже языки её реализующие есть, но сам я ими не
пользовался. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148949 |
|
Автор: -=Lucky=-
Дата: 12 Июня 2009 16:01
Osoka, что означают термины верификация и валидация? |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148950 |
|
Автор: Начинающий Программист (О пользователе)
Дата: 12 Июня 2009 16:06
Анонимный кармадрочер, который минусит Осоку, просто съеби хабрахабр.
В коем-то веке серьезная тема на сираном f37.
Цитата:
От пользователя: Osoka
существует ли какой-нибудь паттерн, основанный на использовании исключительно средств компилятора // интерпретатора
|
Понятное дело, что такого паттерна существовать не может.
"Паттерн" это вообще типовой костыль для определенного языка (да-да паттерны GOF -
это костыли для жавки, крестов, шарпов, смалталков и всех им подобным, в хаскеле, например, они не имеют смысла, там другие костыли - монады например).
Может существовать язык, построенный на формальной теории, позволяющий обнаруживать подобные ошибки. Что-нибудь построенное на
лямбда-счислениях и зависимых типах (ссылки в предыдущем посте), например, хотя не в курсе, если честно.
Вообще, если бы существовал язык позволяющий дать формальное описание задачи... да наверно тогда программисты просто допускали бы ошибки в этом самом описании. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148951 |
|
Автор: Свободный человек
Дата: 12 Июня 2009 16:09
Цитата:
От пользователя: Osoka
|
Программисты, у которых забот хватает на работе такими вопросами не занимаются
Как завалить проект и сказать закачику, что во всем виновата неправильная рефлексия тестов. Поэтому бюджет надо увеличить в 2 раза и сроки тоже
Добрый день, мне нужен сайт-визитка.
Вам с рефлексией тестов или без? В регрессиию квазимультур заверните плиз |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148958 |
|
Автор: pavelz
Дата: 12 Июня 2009 19:14
Цитата:
От пользователя: Osoka
Существует ли
|
Это алгоритмически неразрешимая задача (если я понял вопрос). |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148959 |
|
Автор: Osoka
Дата: 12 Июня 2009 20:19
1. Начинающий, благодарю вас за столь четкое и точное мнение. Я полностью прочувствовал, что озвученная мной проблема пока неразрешима.
2. На основе вашего объяснения у меня возник попутный вопрос в тему. Существует такое понятие как "late night hack", которое означает некие
полутопорные решения (коррекции) создаваемые под сиюминутные требования, чаще всего под давлением дедлайна. Но мы знаем (и Начинающий еще раз это подтвердил), что в серьезном проекте прозрачно увидеть всю картину связей целиком невозможно, поэтому нашими единственными "глазами" являются тесты.
Кроме того, мертвичина неизбежно образуется в проекте в областях непересечения общих знаний. Я знаю участки АБВГ, он знает участки БВГД, участки А, Д становятся мертвичиной, потому что ими не пользуются. Причем я и он могут быть одним и тем же лицом, т.е. мной, но в разные периоды времени
по отношению к одному и тому же проекту.
Как лучше всего относится (имею ввиду с психологической точки зрения) к некой мертвичине внутри проекта. Раньше, я всегда чистил свой код, но сегодня у меня физически не получается это делать, потому что сроки и объемы больше того, что у меня
есть. Сегодня все гуд, но где-то внутри я немного переживаю, что однажды какой-нибудь проект разрастется так, что превратиться в русскую рулетку и я тупо буду бояться что-то в нем вообще трогать.
3. Лаки, затрудняюсь определить как ваш вопрос относится к нашей теме, но если вы просто
хотели уточнить, то пожалуйста, это очень простой вопрос
Исходник:
if ($Comment=="@!#$") // верификация - проверять
htmlentities($Comment) // валидация - делать годным |
4. Свободный чел, мне кажется, все как раз наоборот: кодеры у которых дел до жопы больше всех заинтересованы в том, чтобы находить решения позволяющие создавать более качественный код, ибо кодинг - это на 80% -
отладка кода. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148960 |
|
Автор: Начинающий Программист (О пользователе)
Дата: 12 Июня 2009 21:05
Цитата:
От пользователя: Osoka
с психологической точки зрения
|
А никак
Когда я линкую какую-нибудь библиотеку к проекту, я использую 10% её функций, все остальное "мертвечина". Граф достижимости строится без проблем, некоторые конпеляторы неиспользуемый код просто не конпелируют.
В готовой программе пользователь может не использовать половину функций - тоже
"мертвечина".
Если программа разработана с использованием TDD можно выкидывать все, что не попадает под сode coverage тестов - т.к. если нет тестов, значит задача реализации данного функционала не стояла.
Цитата:
От пользователя: Osoka
что однажды какой-нибудь проект разрастется так, что превратиться в русскую рулетку
|
Это происходит со всеми проектами. Декомпозиция, устранение зависимостей (через
инверсию), устранение побочных эффектов и модульное тестирование позволяют отодвинуть этот неприятный момент, но никто не живет вечно. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148964 |
|
Автор: _____________. 
Дата: 12 Июня 2009 23:19
Цитата:
От пользователя: Свободный человек
Программисты, у которых забот хватает на работе такими вопросами не занимаются
|
Ещё одна причина говнокода. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148965 |
|
Автор: Osoka
Дата: 13 Июня 2009 01:41
Цитата:
От пользователя: Начинающий Программист
А никак
|
Эх... 
Я тут еще подумал об
одной архитектурной парадигме: если предположить, что нашей целью является не красота кода, как было у меня скажем так "до сих пор", а гарантию *управляемости работоспособностью*, то я насчитал только две статегии, очень, кстати, похожих на политику компаний в отношении сотрудников: 1. наводим
порядок и 2. нанимаем новых людей.
Не выдумывая новой метафоры, позаимствую метафору Начинающего про каунтер. Была функция Count(2,2)==4; вдруг понадобилась функция Count(2,2)==5; Как действуют две наши стратегии:
1. Правим Count(2,2)==4; на Count(2,2)==5; запускаем тесты. Все,
кто "не согласен" с новой политикой "руководства" причесываем, т.е. производим "внушение за закрытыми дверями".
2. Оставляем Count(2,2)==4; принимаем на работу CountAss(2,2)==5; и в cамых актуальных местах используем CountAss(), а во всех старых местах по-прежнему работают как привыкли. Если
очень нужно сохранить имена, то правим Count($a,$b,$mode==false); и по $mode==true вызываем CountAss(2,2);
Пока я был мАлАдой, то всегда жил по стратегии 1., но если сегодня и до нового года я ещё проживу на ней, то дальше, я точно уже буду не в состоянии наводить порядок ибо t
наведения порядка будет стремится к t разработке нового кода, а поскольку за первое никто не платит, а кредиты, квартплату и обеды никто не отменял, то чувствует моя ж**а, что мне уже сегодня нужно плотненько формировать привычку по образу стратегии 2.
Вопрос, что, чисто как более
опытные коллеги по цеху, посоветуете учесть и принять на вооружение по культуре "наращивания" кода, как противоположенность тому, чем я занимался "до сих пор" - практически только созданием. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148966 |
|
Автор: Майк  (О пользователе)
Дата: 13 Июня 2009 09:01
Я бы все-таки старался не забивать совсем на старые участки кода, потому что через некоторое время любая правка этого кода будет чрезвычайно болезненной. Выкраивать хоть полдня, хоть пару часов, чтобы привести legacy код в порядок. Даже начальству можно объяснить, что если не заниматься этим время
от времени, время внесения новых фич будет расти экспоненциально. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148987 |
|
Автор: Smasher  (Отправить письмо)
Дата: 13 Июня 2009 17:28
Цитата:
От пользователя: Osoka
Я тут еще подумал об одной архитектурной парадигме: если предположить, что нашей целью является не красота кода, как было у меня
скажем так "до сих пор", а гарантию *управляемости работоспособностью*, то я насчитал только две статегии, очень, кстати, похожих на политику компаний в отношении сотрудников: 1. наводим порядок и 2. нанимаем новых людей.
Не выдумывая новой метафоры, позаимствую метафору Начинающего
про каунтер. Была функция Count(2,2)==4; вдруг понадобилась функция Count(2,2)==5; Как действуют две наши стратегии:
1. Правим Count(2,2)==4; на Count(2,2)==5; запускаем тесты. Все, кто "не согласен" с новой политикой "руководства" причесываем, т.е. производим "внушение за закрытыми
дверями".
2. Оставляем Count(2,2)==4; принимаем на работу CountAss(2,2)==5; и в cамых актуальных местах используем CountAss(), а во всех старых местах по-прежнему работают как привыкли. Если очень нужно сохранить имена, то правим Count($a,$b,$mode==false); и по $mode==true вызываем
CountAss(2,2);
Пока я был мАлАдой, то всегда жил по стратегии 1., но если сегодня и до нового года я ещё проживу на ней, то дальше, я точно уже буду не в состоянии наводить порядок ибо t наведения порядка будет стремится к t разработке нового кода, а поскольку за первое никто не
платит, а кредиты, квартплату и обеды никто не отменял, то чувствует моя ж**а, что мне уже сегодня нужно плотненько формировать привычку по образу стратегии 2.
|
1. Вообще, мое мнение что наводить порядок нужно вовремя, то есть не откладывать на потом. Если не навести
порядок сейчас то потом будет еше меньше времени на это, плюс код начнет забываться. Если не наводить порядок вообще то потом модификация + отладка кода не приведенного в порядок займет гораздо больше времени чем ушло бы на приведение кода в порядок + модификация и отладка приведенного в порядок
кода (пример есть в пункте 2).
2. В данном случае лучше стратегия 1. Просто представьте себе что когда-нибудь потом нужно будет внести изменения в процедуру Count (везде). В первой стратегии нужно будет внести одно изменение в одну процедуру. Во второй стратегии нужно будет внести N
изменений в N процедур (N - это сколько мы процедур наплодим по стратегии 2 за это время), это, понятно, в N раз сложнее. Сложно будет даже банально все время помнить что у нас N процедур Count.
3. Если нет времени на то чтобы все делать правильно (то есть наводить порядок сразу), то
это означает что заданный темп разработки слишком высок. Это нельзя так оставлять, нужно либо поговорить с начальником либо еще как-то решить эту проблему. Если торопиться и использовать неоптимальные стратегии (которой в данном случае я считаю стратегию 2), то это НЕ выход - эти неоптимальные
стратегии потребуют в будущем гораздо больше времени, чем ушло бы сейчас на приведение все в порядок. Так делать можно только если есть 100% уверенность что потом будет больше времени и удастся привести все в порядок, и тогда нужно записать все участки не доведенные до ума в to do list, который
потом хранить как зеницу ока пока все везде не будет приведено в порядок.
[Сообщение изменено пользователем 13.06.2009 17:29] |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148989 |
|
Автор: -=Lucky=-
Дата: 13 Июня 2009 19:55
Цитата:
От пользователя: Osoka
Лаки, затрудняюсь определить как ваш вопрос относится к нашей теме, но если вы просто хотели уточнить, то пожалуйста, это очень
простой вопрос
|
С каждой программой связано две проблемы:
1. правильно-ли составлена программа;
2. правильно-ли она работает (с точки зрения заказчика, например).
Задачи, связанные с первой проблемой решаются при помощи *верификации* - проверки,
что программа удовлетворяет критериям некоторой формальной системы . ООП-интерфейсы - лишь один из примеров такой формальной системы. Другой популярный пример - типы данных. Классная штука встроена в академический язык Eiffel , основанная на упомянутой выше парадигме "design by contract", при помощи
которой эти самые контракты там описываются.
Достоинство формальных систем заключается в том, что они позволяют тестировать программы в автоматическом режиме (и поэтому могут встраиваться в компиляторы). Например, компилятор может верифицировать функцию sum(x,y) относительно объявленной
для нее сигнатуры типов (int, int) : int.
С такой верификацией программ связана одна засада. Изменяя программу, мы неизбежно изменяем и критерии верификации. Поэтому при помощи подобных систем невозможно отслеживать корректность программ в ретроспективе. Т.е. программа, после
очередного изменения, оставаясь внутренне формально непротиворечивой ("компилируется"), может начать выдавать абсолютно непредсказуемые результаты.
Тесты дают возможность посмотреть на программу с другой стороны: со стороны входных данных и ожидаемых результатов. Это та информация,
которая не должна изменяться при модификации программного кода. Собственно поэтому тесты и "живут" отдельно, а так же требуют отдельной проработки. Тесты можно использовать как инструмент для автоматической *валидации*. Хотя по сути, тесты так же являются формальной системой.
У всех
формальных систем, с практической точки зрения, есть один общий недостаток: они не дают ответа на главный вопрос: "делает-ли ваша программа то, что нужно?". |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#148990 |
|
Автор: -=Lucky=-
Дата: 13 Июня 2009 20:26
Цитата:
От пользователя: Osoka
2. Оставляем Count(2,2)==4; принимаем на работу CountAss(2,2)==5; и в cамых актуальных местах используем CountAss(), а во всех
старых местах по-прежнему работают как привыкли. Если очень нужно сохранить имена
|
то используем неймспейсы.
модель отражает некий аспект из реального мира (кружку чая, бизнес-процесс, поведение и т.п.). и пока аспект не изменился (2 ложки чая + 2 ложки чая =
4), существующую модель трогать не нужно (для инопланетянской физики пишется новая модель, которой дается собственное имя). DDD - термин такой. |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#149012 |
|
Автор: Osoka
Дата: 14 Июня 2009 23:18
Цитата:
От пользователя: Майк
Я бы все-таки старался не забивать совсем на старые участки кода
|
В том-то и прикол, что так я мыслил и
жил сколько себя помню кодером, а понимание, что "забивать надо уметь" и что это умение есть мой следующий шаг в профессиональном росте, пришло только этим летом. Я сам очень переживаю из-за этого, но через 8 лет я хочу войти в элиту прикладных программистов, поэтому другого выхода у меня нет. Я
должен чувствовать себя как рыба в воде, даже в помойке. Майк, если вы из тех, кто любит говорить "с этим я не работаю" (как и я "вчера"), то вы пока не спец высшего уровня. Вы можете быть хорошим кодером, но не элитой.
Для того, чтобы договориться со своей совестью, я использую
принцип, предложенный Начинающим. Я как бы убеждаю себя, что код, на который я кладу с прибором - это просто часть сторонней библиотеки, а как известно, мы же никогда не суёмся внутрь сторонних библиотек. Мы или работаем с ними или не пользуемся вообще. Новаторство идеи состоит в том, чтобы признать
часть своего кода библиотекой, т.е. перестать нести за неё ответственность, как например, за своего ребенка, потому что он уже стал совершеннолетним и живет своей жизнью. Наводить порядок в старом коде, это все равно, что интересоваться у своего взрослого сына, кого он e**л вчера ночью.
Цитата:
От пользователя: Майк
Даже начальству можно объяснить
|
Цитата:
От пользователя: Smasher
нужно либо поговорить с начальником
|
Вообще-то я это и есть он 
Цитата:
От пользователя: Smasher
Вообще, мое мнение что наводить порядок нужно вовремя, то есть не откладывать на потом
|
Я с Вами абсолютно согласен, я "до сих пор" так и жил, но
революция (эволюция) моей карьеры состоит в расширении понятия порядок. То, что раньше у меня считалось "как можно?!", сегодня считается "да, это не самый крутой вариант, но почему бы и нет". Вспоминаются слова "Democracy is the worst form of government, except for all those other forms that have
been tried from time to time" (У.Черчилль, 11.11.1947, выступление в английской думе).
Трансформация моего отношения к кодингу - это лишь частный случай трансформации моего общего мировоззрения. Я много попробовал в этой жизни и вынужден был проститься с юнешским максимализмом
(перфекционизмом). Мир оказался намно-о-го больше меня. Жизнь слишком коротка и изменчива, чтобы все делать идеально. Чаще для достижения успеха достаточно просто выжить, просто быть в нужное время, в нужном месте. Раньше на первом свидании с девушкой я болтал без умолку, я стремился как-то
поухаживать, то сегодня я понимаю, что сам факт того, что её кто-то пригласил и с этим кто-то можно адекватно и интересно общаться - это уже означает, как в шутку говорит мой отец, "жизнь удалась".
Плохая новость: мир намного больше меня.
Хорошая новость: это вынуждает вести
себя проще.
Чем больше проблема, тем проще нужны средства. Это пародокс, от которого я просто шалею.
Чем больше и сложнее проект, тем тупее должен быть стиль. Простота - высшая форма мастерства.
То же самое и в кодинге. Я перестал сочинять собственные форматы
файлов, собственные алгоритмы построение древовидных структур и функций сравнения двух файлов. Я осознал, что сам факт поставки заказчку функционирующей программы - это уже "жизнь удалась". Это не значит, что мой код - это полный п**ц для восприятия. Нет. Много лет назад я отправился в путешествие
по нашей профессии, перебовал все, что встречал на своем пути, а сегодня как бы вернулся домой и понял, что ничего "такого" в нашем мире нет. Часто вместо класса можно обойтись функцией, а вместо функции прямо расписать решение. Правильное название переменной или функции может заменить 10 строк
комментария. Но, опять же я отлично понимаю, что иногда сложность задачи такова, что без фабрики плагинов прогу просто не запалить, но такое встречается не часто, ибо я прикладной кодер и в моем бизнесе уровень абстракции редко превышает два уровня.
Цитата:
От пользователя: Smasher
Если не наводить порядок вообще то потом модификация + отладка кода не приведенного в порядок займет гораздо больше времени чем ушло бы на приведение кода в
порядок + модификация и отладка приведенного в порядок кода
|
Фишка в том, что с помощью Начинающего, который как-то давно порекомендовал мне читать вики от "Система" до упора, я научился строить архитектуру так, что этой задачи теперь вообще не существует. Как
говорит Сунь Дзы "Побеждает тот, кто не воюет". Эту замутку понять нелегко, но можно. Беспорядок - это путаница. Путаница - это следствие беспорядочных, случайных связей. Запрети перекрестные связи и веди коммуникацию объектов между собой через единый центр и тогда смерть одного объекта никогда не
убьет организм, ибо волна смерти будет остановлена менеджером связей.
Цитата:
От пользователя: Smasher
В данном случае лучше стратегия 1. Просто
представьте себе что когда-нибудь потом нужно будет внести изменения в процедуру Count (везде). В первой стратегии нужно будет внести одно изменение в одну процедуру. Во второй стратегии нужно будет внести N изменений в N процедур (N - это сколько мы процедур наплодим по стратегии 2 за это время),
это, понятно, в N раз сложнее. Сложно будет даже банально все время помнить что у нас N процедур Count
|
Смешер, вы человек уважаемый, но конкретно в данном случае вы просто еще не вкурили, что Начинающий предложил играть вообще в другую игру. Лично мне
потребовалось два месяца, чтобы понять его, а когда я понял, я просто взвизгнул. В новой парадигме больше не существует задачи "когда-нибудь потом нужно будет внести изменения в процедуру" и поэтому потребности в "сложно будет даже банально все время помнить что у нас N процедур Count" вообще
нет.
Это очень непросто понять, потому для этого нужно уметь работать с собственными стереотипами, но я их изменил и поэтому у меня открылся новый горизонт для движения.
Цитата:
От пользователя: Smasher
Если нет времени на то чтобы все делать правильно (то есть наводить порядок сразу), то это означает что заданный темп разработки слишком высок. Это нельзя так оставлять
|
Вы мыслите как мужчина и в этом ваша слабость. В нашей стране почти все мужское население от 40 лет спилось, потому что не смогли перестроить свое мышление на новый лад, когда случилась перестройка, а женщинам это далось легче, поэтому мы и наблюдаем такой взрыв активности бизнес-вуман. Вы
посмотрите до чего дошло: по городу висят плакаты с рекламой на фильм, где женщина стоит на одном колене и делает предложение мужику! Ведь это не прикол. Это уже реалии в которых мы живем.
Ваша ошибка состоит в том, что вы пытаетесь темп жизни подогнать под ограничения вашей модели
создания компьютерных программ. Вас просто жизнь пополам сломает как щепку. Вопрос только когда. Правильно мыслить наоборот, по-женски: я вижу, что темпы становятся сверхзвуковыми и моя модель создания софта трещит по швам. Я начал это чувствовать пару месяцев назад и поэтому слава богу у меня
оказалось достаточно времени и сил, чтобы перестроиться на новую схему производства софта, адекваную темпам, которые задает рынок.
Цитата:
От
пользователя: Smasher
Если торопиться и использовать неоптимальные стратегии
|
Смеш, боже мой, как я с Вами согласен! Использовать неоптимальные стратегии - это просто самоубийство. Но дело в том, что стратегия 2. - это а) плод моих поисков, б) это
еще ветка не стабильная и она требует заточки, но уже сегодня я вижу, что это моё будущее, а 1. по-тихоньку умрет. Чем-то это мне напоминает историю с Windows и Windows NT. Во времена Win 9x - NT нахер никому не была нужна. Но если бы Майкрософт не вложили деньги в NT, а они могли бы этого и не
делать, то они просто просрали бы рынок начиная с 2000 года. Помните они даже выпустили Me edition, но это было так - мертвому припарка. Красиво, привычно, работает, но мир катится дальше.
Когда вы называете 2. "неоптимальной" вдумайтесь, а по сравнению с чем вы называете её
неоптимальной? 9/10 вы сравниваете с сегодняшним положением, а нужно сравнивать с положением декабря этого года, со следующей весной. Я, например, через силу заставляю себя читать гламурные журналы, слушать современную попсу и "Касту". Мне это не нравится, но не я определяю тренды, а терять
адекватность среде - вот чего я боюсь больше всего на свете.
Можно с пеной у рта доказывать, что механика лучше коробки автомат, потому что позволяет чувствовать машину, но если ты не умеешь пользоваться коробкой автомат, то вы, сэр, будете в пролете. Вопрос только когда. На рынке это
означает потерю конкурентноспособности, страх конкуренции, неуверенность, низкие цены и как следствие бедность.
Цитата:
От
пользователя: Smasher
Так делать можно только если есть 100% уверенность что потом будет больше времени и удастся привести все в порядок
|
Это полная глупость. Любому взрослому человеку ясно как божий день, что никакого увеличения времени в будущем
не предвидиться, а наоборот, будет еще больше ответственности, задач, требований и скорость.
Цитата:
От пользователя: Smasher
нужно записать все
участки не доведенные до ума в to do list, который потом хранить как зеницу ока пока все везде не будет приведено в порядок
|
Сегодня скорости такие, что никто уже никакие бумажки не читает, потому что скрость поиска нужной бумажки больше, чем скорость изучения и
решения самой проблемы, а в 7/10 случаев люди вынуждены отказаться от решения проблем вообще, чтобы справиться с более важными.
Цитата:
От
пользователя: -=Lucky=-
то используем неймспейсы
|
это уже вчерашний день. неймспейс сегодня - это обозначение библиотеки (плагина), а не вариации.
Цитата:
От пользователя: -=Lucky=-
модель отражает некий аспект из реального мира
|
Это тоже уже вчерашний день. Скорость изменения реального мира выше скорости создания модели. Бизнес-логика больше не
может опираться на модели, она должна опираться только на "контейнеры". Может быть, я точно не знаю, концепция моделирования годиться для системного софта, но для прикладного она больше не годиться. Прикладной кодер должен уметь разработать программу, которая легко и динамично кастомизируется,
скажем, под 1000 клиентов, но при этом остается тем не менее одной программой. При этом кодер ничего не должен помнить, не должен путаться и не ссаться, что он что-то изменит и все упадет. И стратегия 2. как раз именно это и позволяет. Да, у нас будет 748 функций Count() - нет проблем. По крайней
мере, благодаря Начинающему, конкретно я уже почувствовал как именно это достигается. Респект ему от меня от всей души!
[Сообщение изменено пользователем 14.06.2009 23:34] |
|
цитировать |
сообщить модератору
| Ответить
|
| Re: Рефлексия интерфейсов вместо регрессионных тес... |
#149014 |
|
Автор: Майк (О пользователе)
Дата: 14 Июня 2009 23:44
Цитата:
От пользователя: Osoka
В новой парадигме больше не существует задачи "когда-нибудь потом нужно будет внести изменения в процедуру"
|
Цитата:
От пользователя: Osoka
я уже почувствовал как именно это достигается
|
Поделись сокровенным знанием |
|
цитировать |
сообщить модератору
| Ответить
|
| Сообщение по теме |
| Для того, чтобы опубликовать сообщение в данный форум Вам необходимо авторизоваться или зарегистрироваться, если Вы до сих пор не зарегистрированы на Е1. |
|
|
|
|
