Здравствуйте, уважаемые.

Хочу наконец сделать что-то серьезное, но не знаю с какого края подойти к разработке. Как вы поступаете когда не знаете с какого конца браться. Усугублено это клиент-серверной архитектурой.
Пробовал начать с дизайна. Писал на бумажках, потом терял, да и зачем они там, какие-то хилые, проще с ходу писать, я не в команде, т.е. даже и для себя то в лом писать UML. Что посоветуете, какой диагноз?

PS: Мудрость по поводу "Когда не знаешь за что браться - берись за ум" не предлагать.

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

Ну можно не на бумажке - файл тоже хорошо.

1. Описать варианты использования - UseCases. Сделать их подробными.
2. Под подробные UseCases сделать архитектуру классов
3. Реализовать классы
4. Параллельно писать Unit-tests - для удобства проверки
5. Завершить версию и начать улучшать в новой версии.

Все.

v2v, AntonSaburov, главное в нашем деле поддержка, спасибо, помогло, уже не боюсь браться.
В новом проекте - главное начать, в принципе как и везде.
+ еще сегодня решил заглянуть в соседскую тетрадку по университету. Про нисходящее проектирование. Так вот меня там зацепила фраза: "сначала система описывается в терминах обобщенной функции предметной области, каждая из функций делится на подфункции (выполняется уточняющий шаг), уточняющие шаги делаются до тех пор, пока не получится языка программирования."

в принципе это 2-й пункт в посте v2v

 

Надо начинать с поиска прототипа. Говорят, в интернете есть все. Найти и прикрутить. Так работают профессионалы.    

Прототип то однозначно есть всегда, и данный случай, естественно, не исключение.

самое выгодное решение. если это решение развить, то можно вообще ничего не делать - а просто найти   

Тут у меня настал кризис веры. Причиной тому высказывание:

+ поведение товарищей по локальной сети. Когда предлагаю затестить мой мини-шедевр, сначала с удовольствием соглашаются, но когда не запускается, спрашивают "что не так?" - я кидаю им jre-setup, многие отказываются от дальнейших процедур, потому что лень устанавливать.

В связи с этим размышления... начиная с Windows XP в поставку включен .NET, и разработчикам под эту технологию проще продвигать свою технологию, нежели Java. А каждое приложение, включающее в себя JRE - это издевательское отношение к целевому пользователю и плюс в пользу дотеров, которым не надо думать об этом.

Интересует перспектива desktop приложений, жива ли она и не загнется ли?

Да ладно  
Скачиваешь IzPack и делаешь им инсталятор, который сам поставит и программу и JRE.

Sun предпринимает усилия для уменьшают размера JRE и упрощения процедуры установки. Некоторые производители (например, Dell) предустанавливают java на новые компьютеры. 



Установка JRE иногда представляет проблему для клиентов. У людей, далеких от компьютеров, не всегда это успешно получается. Прочитал отзывы на сайте IzPack, но так и не понял - он устанавливает JRE лучше, чем это делает Sun на своем сайте? 

Это сообщение отредактировал(а) COVD - 22.10.2007, 16:16

Какую (если инсталяция происходит в silent режиме)?

Я давно не инсталлировал, но по крайней мере раньше инсталляция состояла из нескольких нажатий кнопок. Опять же, пользователь должен иметь административные права на своем аккаунте. Короче, нам звонят в тех поддержку с этими проблемами.   Возможно, мы чего-то не так делаем (не используем IzPack). Но вот, что пишет авторитет (Брюс Эккель, http://www.adobe.com/devnet/flex/articles/...ng_java_04.html) :



ну и дальше сравнение с flash и т.д.

Это сообщение отредактировал(а) COVD - 22.10.2007, 17:15

Ну тот же .NET ставится аналогично, и еще и перезагрузки требует (правда его скоро интегрируют в винду и ставить будет не надо). Ну а звонят иногда, чтобы узнать "Как распечатать документ с дискетки?".



А на Flash можно писать Desktop приложения? Или ты про веб?

Жалуются, что не работает. Потом выясняется, что JRE не установлена или как-то криво установлена (а я ставил  ).  То есть это один из поводов для звонков, которого не было во времена использования встроенных в браузеры jvm. Брюс Эккель отмечал, что у флаша преимущество по этому пункту, т.е. это образец, как надо инсталяцию реализовывать, в одно нажатие кнопки. Может, Sun уже и продвинулся в этом направлении.

Да, удивительно, но аплеты почти в сухую проиграли флешкам :(

Вот этот пункт интересный, гипотетически представляю что это и как, но, на практике что-то непонятно, как реализуется.

В смысле?.. Ты не в курсе, что такое юнит-тесты?  

А что это такое?

Это фреймворк для написания тестов к разрабатываемым классам. Очень полезная вещь для разработки проектов в услових меняющихся требований и комадной разработки.
Junit

Добавлено через 3 минуты и 3 секунды
Учимся любить юнит тесты

О, братишка! Мне как раз надо кое-что спрограммисть а времени нет. Возьмёшся?

ЗЫ. Чтобы научиться писать программы надо написать хотябы одну.

Это сообщение отредактировал(а) pompei - 23.10.2007, 11:20

Бумажки(электронные или древесно-волокнистые) используй в любом случае!!!
Даже(тем более) если пишешь один.
Забудешь - не вернёшь. Пиши джавадоку, даже если там тупейший метод(только не пиши "тупейший метод", пиши по сути, как для несведущего соседа).
Ну и всегда пиши хоть маленькую, но бумажку по архитектуре. Себе же полезно будет. Ну а лучше не маленькую бумажку, а хорошую, но небольшую доку.

Это больше чем фреймворк. JUnit - да, фреймворк, а юнит-тесты вообще - это технология. И юнит-тесты не привязаны только к Java, их можно использовать практически везде. Хотя, насчёт LISP я не уверен - не встречался с ним ни разу.
Если кратко, смысл юнит-тестов состоит в том, что сначала ты пишешь код тестирования своего кода (собственно, юнит-тесты), а уже затем пишешь сам рабочий код. Написал один-два юнит-теста - пишешь к ним код. Запускаешь. Добиваешься, чтобы всё отработало правильно (с точки зрения теста). Ничего нового и лишнего при этом в коде быть не должно. Только чтобы тест отработал. Затем придумываешь ещё один-два теста и добиваешься их отработки. Вот так, постепенно, твоя программа сама напишется за счёт "натягивания" её на юнит-тесты.
Честно скажу - впечатление незабываемое. 

Добавлено через 4 минуты и 55 секунд

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

И в результате помимо своей системы получаешь еще тестировочный пакет, который может ее проверить вдоль и поперек.

Юнит-тесты хороши, когда мы тестируем "боевого сферического коня в вакууме", т.е. метод, который складывает 2 и 2 (или обрезает расширение у имени файла) . А вот если метод читает-пишет файлы, работает с БД, с сетью или, не дай бог, с ПО стороннего производителя, вот тогда начинается веселье. :(

Выражение "натягивания" на юнит-тесты" -- это пять! ))

Угу :( Если суть не в простой логике КА, а нужно протестить что-то сложное с "состояниями", причём очень сложными и разнесёнными по разным подсистемам.
"Хороший" юнит тест кэйс может быть размером с целую подсистему     
Кста, для этого ещё полезен dbunit.

Так... а JMock или альтернативными вы как активно пользуетесь? Сегодня только начал читать и тестить, впечатлился возможностями, но в голове каша.

ps в догонку сказанному на первой странице по поводу виртуальной машины. Когда надо было нести прогу в универ, где тоже нет явы.. я просто скопировал на флешку всю ЖРЕ\ директорию : работало на урА  

nornad, я не писал, что не знаю что это такое, я писал, что не понимаю с чем их едят 



Денег, конечно, требуется!!!  Но, есть и другой путь, который, я почти полностью уверен, используется тучей программистов. Когда проект задумывается, простенький и без команды, программист не беспокоится о документации, архитектуре и прочей номенклатуре, он просто пишет код. Когда из зерна начинается проклёвываться росток (т.е. проект пошел в гору), программист начинает задумываться о привлечении команды в проект и только тогда берется за бумажки. Могу привести в пример игру Domestic Cat'а при ее написании он не шипко старался угодить всем стандартам, а просто писал.

ЗЫ: я тут как раз пишу тестовую систему. Т.е. грубо говоря на вход тестируемому модулю поступают данные и возвращается результат, который сравнивается с эталонным. И JUnit натолкнул меня на мысль, что может в качестве тестера мне как раз использовать JUnit? Т.е. есть набор тестов (50 штук к примеру) через них лупится, на первой же осечке выходит из теста. А также существуют ограничения по времени и по выделенной памяти.
ЗЗЫ: простите, что я не так часто появляюсь, просто меня из дома выгнали, щас доступ в инет проблематичен :(

Лично я даже не слышал о таком. Я и юнит-тестами мало пользуюсь. Потому как интерфейс ими вообще не проверишь, а писать мне больше приходится интерфейсного, чем расчётного. В последних моих программах доля расчётов, которые можно обложить тестами составляет процентов десять. Имхо, юнит-тесты в этом случае уже не так полезны. Хотя в критических местах (где есть сложности с расчётами) применить всё же можно и зачастую нужно.


Ну, на такую JRE другие программы (чужие) завязать сложнее. Хотя при желании тоже можно. В принципе, Java не требует непосредственной инсталляции в винде.

Добавлено через 7 минут и 2 секунды

Это пример проекта, который был создан ради развлечения и не предполагал ни передачи кода другим разработчикам, ни развития проекта в будущем.
Достаточно яркий пример написания "фор фан". Если так писать за деньги, то будешь не очень хорош в команде. На маленьких проектах - вполне нормально может получаться долгое время. Но в итоге всё равно на одном из проектов придёшь к стадии, когда надо передать кому-то код. С документацией. И вот тут-то о тебе и сложится антересное мнение окружающих коллег.   


Ну да. Зачем писать своё такое же? 
Только тесты в JUnit, кажется, все прогоняются, а не "по первой осечке". Хотя, я с JUnit не работал. Тесты писал больше на сях. На Java пока не требовалось. 

Вот, я как раз и описывал. Еще 1 аргумент. 2-3 энтузиаста собрались. А как мы знаем на голом энтузиазме далеко не уедешь, его хватает на 3-4 недели, а если ядреные энтузиасты то месяца на 3-4, не более. Так вот представьте, что это ценное время они стали тратить на написание документации и тестов. Пока они писали энтузиазм испарился в 2 раза быстрее + написанного целевого кода в 2 раза меньше. Итого в 4 раза меньше результата. !!! Я не говорю о том случае, когда ты работаешь в организации, и тебе не важно как долго, главное платят деньги. !!!

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

Спасибо alex_nevolin за статью, описанное принято к сведению.

Не согласен. Писать проектную документацию не должны все скопом - это не только у голых энтузиастов потерпит поражение, но и у "одетых". Документирование же кода отнимает времени совсем немного, если производить его в процессе, а не после.


Покажи мне ту организацию, где платят хорошие деньги за "неважно как долго", я туда уже хочу. 


Хорошо, если альфа. Но скорее это будет вообще макет, код которого в будущем использовать не стоит. Голый энтузиазм и отсутствие нормального проектирования с закреплением решений на "бумаге" приведёт к тому, что код будет не прямо-таки смердить. Да и документирование у тебя будет в стиле "эте не баг, это фича".

А вообще это обсуждение корректнее уже вести в разделе "Управление проектами". Непосредственно к одной лишь Java отношения оно уже не имеет.

Вот о том и речь... Mock - болванка, заглушка. Позволяет внутри unit теста очень быстро написать реализацию интерфейса (или класса) с требуемым тебе поведением. JMock полностью совместим с JUnit и дополняет его.

Пример использования.

Предположим, что у нас есть интерфейс ICollaborator с описанием единственного метода executeJob, возвращающего строковое значение:

И есть класс ServiceClass с единственным методом runService. В качестве аргумента метод принимает реализацию интерфейса ICollaborator и сравнивает возвращаемое методом executeJob строковое значение со строкой "success". В случае совпадения значений возвращается истина, иначе - ложь.

Что делать, если нам необходимо протестировать класс ServiceClass, но при этом писать реализацию интерфейса ICollaborator рано? Вот в таком случае нам может пригодиться JMock.

Создадим тестовый класс, и перво-наперво надо с помощью аннотации org.junit.runner.RunWith указать, что тест будет запускаться с помощью класса JMock, полностью совместимого с JUnit4.

Затем нужно создать фабрику - объект Mockery. Следующим этапом будет создание болванки, являющейся "как бы" реализацией интерфейса ICollaborator.

Далее необходимо настроить поведение болванки. Сначала дам код, потом только прокомментирую его

Тут с непривычки можно рехнуться, если честно! Явадок на JMock подробными комментариями не радует, поэтому за консультацией отправляю на сайт www.jmock.org, где можно найти достаточно информации по синтаксису Expectations (ожиданий). Кстати, синтаксис "ожиданий" очень похож на конструкции языка программирования Perl, такое вот ИМХО...

Метод checking навешивает на болванки требуемые нами expectations - удачное, кстати, слово. Ожидания - это то поведение, которое мы ожидаем от новоиспечённых болванок.

Метод one() принимает объект - болванку и возвращает его (объекта) как бы настоящий класс, чьи методы теперь можно вызывать, чем мы и воспользуемся. Мы "ожидаем", что будет вызван метод executeJob(). Потом метод должен (will) вернуть (returnValue) строку "success". One() подразумевает, что метод executeJob будет вызван в ходе теста ровно один раз, не больше и не меньше.

Далее код повторяется с той лишь разницей, что возвращаемым значением будет строка "failure". Для чистоты эксперимента, так сказать.

Теперь болванку collaborator можно с чистой совестью применять в данном тесте. Ограничения - должно быть ровно два вызова executeJob(), они будут возвращать разные значения. Ограничения можно сделать и не такими жёсткими, возможности работы с JMock на самом деле очень велики, охватить все его возможности в одной статье не представляется возможным. Главное - понять предназначение библиотеки и её основные концепции, а там уже можно накручивать любые конструкции ожиданий, какие только представить можно!

Ну что, тест!

Зелёная полоска - успех! Класс ServiceClass отработает с классами, реализующими интерфейс ICollaborator, именно так, как было задумано.

JMock позволяет создавать болванки не только для интерфейсов, но и для классов - в равной степени абстрактных и конкретных, прописывать им любое ожидаемое поведение и тестировать приложение в любых условиях (как говорится, максимально приближенных к боевым).

Пример теста взят с сайта www.ibm.com. Статья изрядно устарела - потребовалось немало поскрипеть мозгом, чтобы привести выложенный там код в рабочее состояние. Плюс ко всему, JMock уже позволяет тестировать реализации классов, не имеющих конструкторов с пустыми аргументами. Так что особой надобности в RMock, также описанном в статье, я не рассмотрел.

Вроде много написал... на ФАК, кажется, не тянет, хотя это на усмотрение модераторов.

Под интерфейсом я имел в виду гуй. 

Это я не догнал...  

Гуй тестить тяжко, согласен.