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