Отводите ли вы время на то, чтобы подумать?
годы, нах 
Ха. Зависит от кода.
Если нажо что-нить сложное с-архитектурировать, то это вообще очень долго можно думать, схемки рисовать... А если прожка небольшая, то очень мазёво кодить, и при это заранее думать о том, что будешь кодить дальше.
Если нажо что-нить сложное с-архитектурировать, то это вообще очень долго можно думать, схемки рисовать... А если прожка небольшая, то очень мазёво кодить, и при это заранее думать о том, что будешь кодить дальше.
Если нажо что-нить сложное с-архитектурировать, то это вообще очень долго можно думать, схемки рисовать...Да сейчас как раз ситуация, когда нужно продумать основу архитектуры.
Временные затраты на написание кода еще как-то худо бедно можно оценить, а вот как оценить время, которое потребуется на то, чтобы подумать? Можно ведь потратить несколько дней и ничего не придумать
, а тогда за что работодатель будет платить тебе деньги. Т.е. с точки зрения бизнеса "думать" рискованное дело.Всё таки думать и схемки рисовать это разные вещи, схемки -- это код.
Можно ведь потратить несколько дней и ничего не придуматьвот об этом как раз думать не следует
Ничего не придумать невозможно.
Может так получится, что после длительного обдумывания существенно изменится техзадание, приведется так сказать в соответствие с реальной ситуацией, но это как бы тоже вполне себе результат.
Гораздо обиднее придумать стройную систему, начать ее кодить, а потом обнаружить, что в ней есть ряд существенных недостатков, из-за которых она совершенно не применима.
Поэтому читай Грейди Буча (кажеццо так "Объектно Ориентированное Проектирование", очень полезная книжка. Я ее правда не дочитал пока, но всё равно она очень полезная =)
Может так получится, что после длительного обдумывания существенно изменится техзадание, приведется так сказать в соответствие с реальной ситуацией, но это как бы тоже вполне себе результат.
Гораздо обиднее придумать стройную систему, начать ее кодить, а потом обнаружить, что в ней есть ряд существенных недостатков, из-за которых она совершенно не применима.
Поэтому читай Грейди Буча (кажеццо так "Объектно Ориентированное Проектирование", очень полезная книжка. Я ее правда не дочитал пока, но всё равно она очень полезная =)
>Грейди Буча (кажеццо так)
на книжке он "Гради"
на книжке он "Гради"
Апох.
Но мысли у него реально рулёзные. Например, что вообще любые системы могут развиваться только проходя через метастабильные состояния. Поэтому если начать кодить сколько-нибудь сложный проект сразу целиком, и запустить его только когда он будет готов, то он нифига не будет работать. Поэтому следует делать всё так, чтобы можно было проверить отдельные части автономно.
Но мысли у него реально рулёзные. Например, что вообще любые системы могут развиваться только проходя через метастабильные состояния. Поэтому если начать кодить сколько-нибудь сложный проект сразу целиком, и запустить его только когда он будет готов, то он нифига не будет работать. Поэтому следует делать всё так, чтобы можно было проверить отдельные части автономно.
в эл. виде есть?
Я вот уже пару недель думаю над одной вещью, которая в итоге должна вылиться ну максимум в пару экранов. Но придумать никак не могу.
- Объектно-ориентированный анализ и проектирование.chm
thnx
Принимая во внимание всякого рода законы мерфи и других выдающихся...
Могу посоветовать распредлелять время над сколь-либо сложным проектом так:
2/5 на обдумывание,
1/5 на кодинг,
2/5 на тестирование и доработку.
И посом еще +20% на форсмажер....
ЗЫ Зато как придешь с досрочно готовым проектом тебе премию выпишут :З
Могу посоветовать распредлелять время над сколь-либо сложным проектом так:
2/5 на обдумывание,
1/5 на кодинг,
2/5 на тестирование и доработку.
И посом еще +20% на форсмажер....
ЗЫ Зато как придешь с досрочно готовым проектом тебе премию выпишут :З
из своего опыта скажу, что я в таких случаях просто начинаю фигачить то решение, которое есть в голове (пусть и глупое). В процессе фигаченья мысли как правило приходят в порядок и нужное решение находится
я так много думаю, что программы писать некогда...
та же фигня 
Составь ТЗ. Причем грамотно. За это тоже берут деньги с заказчика. В ТЗ и продумывается архитектура.
Всё таки думать и схемки рисовать это разные вещи, схемки -- это код.По любому результатом "думания" будут записи и схемы, т.е. код. Получается, что думание это перебор вариантов как все должно быть => тоже самое, что переписывание программы 10 раз заново, но только еще на уровне схем.
из своего опыта скажу, что я в таких случаях просто начинаю фигачить то решение, которое есть в голове (пусть и глупое). В процессе фигаченья мысли как правило приходят в порядок и нужное решение находитсяАга, есть еще идея Test Driven Development писать сразу сначала тест как ета штука должна работать, заодно в голове проясняется как эта штука работать не должна. Потом закодить именно эту штуку(класс, функцию, модуль).
Небольшие библиотечки, чтобы было удобно использовать: simpletest(php JUnit (java NUnit(Microsoft .NET CPPUnit(C++)
TDD хорош в том, что можно не продумывать мелочей. Кроме того, наличие unit-тестов облегчает рефакторинг. Но для того, чтобы проект не выродился в код,который пусть работает, пусть легко отлаживается, но совершенно бессистемен, надо сначала подумать и всегда иметь в голове генеральную линию проекта.
Если же забить на это и допустить бессистемность кода, добавление каждой новой возможности будет требовать все большего объема рефакторинга.
Если же забить на это и допустить бессистемность кода, добавление каждой новой возможности будет требовать все большего объема рефакторинга.
А теперь объясни как таким образом GUI протестить 
(только не надо говорить что ошибки только в логике бывают)
(только не надо говорить что ошибки только в логике бывают) я так много думаю, что программы писать некогда...вообще то, я хотел подумать как раз для того, чтобы уменьшить количество кода
> теперь объясни как таким образом GUI протестить
ты не умеешь из кода мышой двигать? или не умеешь координаты контролов получать?
ты не умеешь из кода мышой двигать? или не умеешь координаты контролов получать?
это все можно... только надо еще и результат работы программы с правильным как-то сверять, а это не всегда легко сделать. Да и в случае веб-интерфейса некоторый сложности будут.
вопрос в том, как это делать ДО программирования?
вопрос в том, как это делать ДО программирования?
По любому результатом "думания" будут записи и схемы, т.е. код. Получается, что думание это перебор вариантов как все должно быть => тоже самое, что переписывание программы 10 раз заново, но только еще на уровне схем.что должно быть? как выглядит конечная система? это описано или сказано заказчиком, если не сказано, то его можно спросить. Поэтому разработчику над эти думать не надо. Подумать можно над тем, чтобы кода было поменьше, чтобы писать его было полегче, расширять и сопровождать.
> Да и в случае веб-интерфейса некоторый сложности будут
для этого есть NUnitAsp
для этого есть NUnitAsp
> вопрос в том, как это делать ДО программирования?
экраннные формы, в теории, должны быть до программирования - соответственно на эти экранные формы можно сделать тесты
ps
но вообще, тестировать надо API системы - а GUI должно быть тонкой надстройкой над этим API
экраннные формы, в теории, должны быть до программирования - соответственно на эти экранные формы можно сделать тесты
ps
но вообще, тестировать надо API системы - а GUI должно быть тонкой надстройкой над этим API
ну это в идеале... иногда в этой тонкой надстройке столько клиентских скриптов бывает, что ошибиться там - не проблема. А этот NUnitAsp клиентский javascript поддерживает?
> ну это в идеале
На данный момент, имхо, в первую очередь должны быть написаны регрессивные тесты, т.е. те тесты, которые проверяют все основную функциональность хотя бы в целом. С такими тестами код намного легче менять.
> этот NUnitAsp клиентский javascript поддерживает?
скорее нет, чем да.
Но клиентские java-script-ы проще тестировать через клиентские же java-script-ы
На данный момент, имхо, в первую очередь должны быть написаны регрессивные тесты, т.е. те тесты, которые проверяют все основную функциональность хотя бы в целом. С такими тестами код намного легче менять.
> этот NUnitAsp клиентский javascript поддерживает?
скорее нет, чем да.
Но клиентские java-script-ы проще тестировать через клиентские же java-script-ы
из своего опыта скажу, что я в таких случаях просто начинаю фигачить то решение, которое есть в голове (пусть и глупое). В процессе фигаченья мысли как правило приходят в порядок и нужное решение находитсяВ моём случае есть масса решений, но все они отрицательно скажутся на производительности. Зафигачить любое из них - минут 5 работы, но толку? Я хочу найти такое, которое не скажется. Фигачить тут почти не надо, т.к. почти всё уже в голове сидит, даже монитор не нужен.
А теперь объясни как таким образом GUI протестить (только не надо говорить что ошибки только в логике бывают)Есть полезная штука mock (заглушка) при тестировании, если есть сложная увязка библиотек создается класс(если вы следуете функциональной парадигме программирования, то набор api который отвечает за замену вызова реальных функций на тестовые заглушки.
Пример: в процессе разработки нет у нас доступа к базе данных: ваяем заглушку, и используем в качестве теста заведомо правильные результаты работы в виде строки.
Пример2: нет возможности в автоматическом режиме проверять работоспособность формы: делаем фасад(прослойку нашего кода между GUI функциями и нашей логикой вывода на экран, создания контролов). При необходимости тестирования переключаем фасад с реальных GUI классов и функций на тестовую заглушку.
Что нужно проверять в GUI:
проверка на ввод неправильных значений
тестирование состояния (неактивные кнопки, меню)
assertWantedPattern (поиск текста в элементах управления, напр, чтобы удостовериться, что ввод неправильных значений выдает ошибку)
Кажется, что это огромный минус: еще одна прослойка, однако это помогает при портировании под другие оконные библиотеки, или переходе на новые версии GUI
В том и бонус тестирования, что мы можем проверять работоспособность программы, даже если важных кусков самой программы нет.
> вообще то, я хотел подумать как раз для того, чтобы уменьшить количество кода
если хорошо подумать, то часто оказывается, что код совсем не нужен: а ну его!
если хорошо подумать, то часто оказывается, что код совсем не нужен: а ну его!
>если хорошо подумать, то часто оказывается, что код совсем не нужен: а ну его!
это как ?
это как ?
шаришь!
Конечно!
Настроение такое, что делать нихрена не хочется, поэтому сижу и думаю
Настроение такое, что делать нихрена не хочется, поэтому сижу и думаю
А иногда бывает полезно подумать как же всё-таки работает эта хня, которую ты только что написал...
Я вот щас написал рекурсивную функцию, она работает как надо, но как она работает, я хз
Я вот щас написал рекурсивную функцию, она работает как надо, но как она работает, я хз
А еще иногда бывает полезно разглядывать собственный код по прошествии нескольких месяцев. Смотришь как на чужой, сразу находишь косяки.
>сразу находишь косяки.
Выкуриваешь их - и сразу догоняешь, почему так написал.
Выкуриваешь их - и сразу догоняешь, почему так написал.
Смотришь как на чужой, сразу находишь косяки.у меня так было где-то первые года 3 работы. Сейчас смотрю на свой прошлогодний код и думаю - блин, какой же я стал ленивый, больше такого красивого кода писать не хочеться. А нахера думать, писать лучше? Через пару лет все-равно половина будет заново переписано, а вторая половина не будет даже и раза поюзана. Пишешь как пишется - и хер сним. Баги придут - поправим, если получется совсем криво - отрефакторим. Лампочки зеленые горят - task completed
Через пару лет все-равно половина будет заново переписано, а вторая половина не будет даже и раза поюзана.Т.к. мой код эксплуатируется по-другому, то я никогда не приду к тезису: "А нахера думать, писать лучше?". Я думаю, мне не захотелось бы писать код с таким коротким lifetime. Разве что за очень большие деньги и в голодные годы.
программирование под Unix, видимо, до сих пор еще несет в себе следы романтики. Завидую.
что ж там такое программирует? 
Ремесленники завидуют?
за всех отвечать не буду
Оставить комментарий
6yrop
перед тем, как писать код. Если да, то сколько? минуты, часы, дни?