Зачин

Случилось недавно в университете разрабатывать программный комплекс клиент-серверного взаимодействия на JAVA. Финальное задание по спецкурсу, если можно так выразиться. В разработке принимало участие 10 человек. Что само по себе вносит коррективы в организацию любой деятельности. Принимал в этом самое непосредственное участие, приняв обязанности, если можно так выразиться, тимлидера. Конечно же, все началось с идеи: чего бы такого написать под конец, чтобы приятно удивить преподавателя и за одно, заслужить экзамен автоматом. В результате первичного мозгового штурма положили концепцию проекта: Сделаем сетевое приложение, использующее клиент-серверную архитектуру: сервер содержит базу данных со студентами, фотками, информацией и цитатами. Клиент запрашивает информацию с сервера и отображает ее пользователю. Позже возникли более смелые мысли:

• Что если сделать возможность администрирования сервером: удаленная остановка, запуск, смена конфигураций. Соответственно, сюда же добавляем клиент для админа, чтобы рулить всем-всем.
• Интернационализация приложения: это всегда хорошо и удобно, когда программа говорит с тобой на нужном языке :)

Работа

Что последовало затем ? Проектирование, объектно-ориентированное моделирование. Здесь мы представляли задачу, как построение механизма взаимодействия объектов, описывая их свойства и интерфейсы. Самая легкая, но самая главная часть: определить базовые классы, данные, в нужном виде: класс студента, списка студентов. Позже был выделен серверный студент, как наследник обычного, но с добавочным полем пути к фотке на сервере, для списка разработан интерфейс (в терминологии ООП JAVA) в целях расширяемости (подгружать ли список из файла, либо с БД, либо иным другим способом). Классы, для работы с изображениями, данными. Изначально решили, что тот же клиент будет существовать в консольном и GUI вариантах, причем GUI ничто иное, как фронтенд. Сервер построен на работе с селектором и каналами, т.е. все операции с сетью без блокировки. Взаимно-согласованные серверы, именно так это называлось в нашем курсе. Для генерации ответа опять же выделили интерфейс, который потом реализовали в отдельном классе. Здесь же распределили обязанности в реализации, разобрали работу протокола, сформировали все требования к нему. Далее технические средства реализации: Среда разработки Eclipse для JAVA, SVN-сервер нашей кафедры для синхронизации разработки. Ну что же, после оформления этих деталей началась разработка. Первым делом выложил приблизительный каркас проекта с пояснением роли каждого класса, раскидал все по пакетам. Выложил описание протокола с примерами, выложил распределение заданий, памятки по работе с SVN. Было сразу обговорено еще раньше, что в SVN нельзя коммитить некомпилируемый код, оставлять пустыми комментарии коммита, лезть в чужие классы без надобности, разве что разрешалось делать заглушки отсутствующих методов с TODO или FIXME. Это помогало избегать конфликтов в SVN до последнего. Я не хочу говорить, что кто-то не обладает необходимым багажом знаний, скорее опыта, поэтому модель задачи и реализация была упрощена, не требовалось знать те же паттерны проектирования и т.п., чтобы отведенное время не тратилось на перенастройку на новый, непривычный лад.

Ложка дегтя.

Какие были допущены ошибки (на мой взгляд):

• Необходимо было заранее согласовать некий фреймворк для конвертации данных, участвующих в программе. Результатом получилось, что два человека для своих классов в разных пакетах писали одни и те же служебные методы перевода буфера в строку и обратно (мелочи, а тратит время).
• Никогда не бывает много информации и детализации о проекте. Если одна вещь мне видится так, то не значит, что другой человек разделит мое мнение. На начальных этапах изменения в SVN не всегда согласовывались с изначальными планами.
• Нужно заранее ставить сроки окончания работы с запасом. Все мы люди, со своими заботами и проблемами. Выставленный срок оказался слегка затянутым, поэтому все кинулись коммитить уже под его конец (на 4-ый день из 6 поставленных резко возросла активность разработки).
• Под конец работы внимание рассеивается, так что некоторые вещи к релизу выглядят неожиданными и упущенными. Нужно всегда выбирать себе план по времени на каждую задачу. Если не успел - не добивать ее тут же, а перенести на максимально близкий срок после выполнения других.
• Всегда стоит относиться с уважением к чужому коду. Если что-то не нравится, то лучше рассказать, как надо, а не переписать и указать на новый вариант. Нужно интересоваться мнением всех участников, доверять им в некоторых вопросах безоговорочно. Благодарить за хорошую работу и вообще всяческое содействие. Ведь вполне ясно, что специфика проекта не предполагает, что кто-то получит от него сколь-либо значимую материальную выгоду. (вспомним опенсорс)
• Не стоит пытаться все сделать самому, а такое желание часто возникает: опять же из-за различного подхода к реализации, выборки мелочей.

Плоды трудов.

Да, вот я и закончил мрачную часть, а теперь к позитивному: Проект вышел в срок, хотя последняя ночь была по сути бессонной для двух человек. Преподаватель был в восторге, как и мы сами. Конечно, как это всегда бывает, функционал под конец был урезан, но не настолько, чтобы чья-то работа оказалась убрана из релиза.

Послесловие.

Исходниками распоряжаться не считаю правильным, поэтому не прикладываю, но саму программу и адрес публично-доступного сервера: всегда пожалуйста. Осознаю, что один командный проект с более-менее успешным концом не дает право задирать нос и лелеять надежды на дикий успех.