Всем привет!
После недавнего неудачного прохождения собеседования в одной конторе, я решил что пора начать более активно двигаться. Задача такова - создать проект, который бы дал необходимые знания, плюс который не стыдно было бы показать на собеседовании.
Идею проекта я уже придумал - своя облачная CRM система для малого бизнеса с поддержкой мобильных устройств.
Так вот, есть вопрос, что вы думаете по этому поводу? Как подойти к проектированию и разработке? Хотели бы вы принять участие в данном проекте?
Если вопрос ко мне, то я планирую в конце лета к практике приступить. Летом банально возможно сорваться на парту-тройку недель + иные «радости» (огороды/шмогороды) кушают время.
Я сам реализовывал большие инженерные проекты, но не в области ПО. Правда участвовал в разработке ПО со стороны заказчика :) Мои 25 копеек:
1. Вы делаете демонстрационный проект на соискание джуна. Он должен стремиться быть идеальным во всем, кроме сложности. То есть если Вы — столяр-школяр, то для Вас лучше идеальная табуретка, чем криво сделанный шкаф в византийском стиле.
2. Сделано должно быть так, чтобы было понятно Ваше творение во всех деталях с первого раза (прозрачный код и пользовательский интерфейс).
3. Проект должен собираться при минимальном вмешательстве со стороны. Для учебного CRM не годится, если для его развертывания придется танцевать час с лишним до/после установки (не нужно заводить несколько логинов, распределять роли, назначать сложную авторизацию по группам и т.п.).
4. При проектировании учебного проекта не стоит ставить максимально-высокие цели, надо сделать приоритет на легкости расширения функционала. Исходя из этого:
1) Напишите ТЗ с этапным созданием. Это не должен быть 200страничный труд, но и десять строк вымученных в notepad-е тоже не годятся.
1.1) Поэтапные требования к функционалу.
1.2) Требования к архитектуре ПО (основное — независимость составляющих).
1.3) Требования по срокам реализации.
1.4) Требования к моделям с описанием стандартных процессов (Например Клиенты. Есть возможность Ввести-Отредактировать-Удалить-Импортировать-Экспортировать(TXT,CSV,JSON,XML) клиента. Есть разграничение прав на данные действия.
1.5) Требования к тестам
1.6) Требования к СКВ (система контроля версий — Git, SVN и.т.п)
… 2) При проектировании делайте упор:
2.1) На независимость модулей. Например, если необходимо добавить другой язык, то это должно быть сведено к новому файлу properties внутрь которого внесены все строковые константы + прописать наличие данного файла и возможность его выбора (а не вылавли
Не за что. По поводу CRM. Один из вопросов, который встает, помимо прочих, даже для первых шагов, это как хранить данные:
1) Есть пользователи системы Users. У них есть следующие атрибуты:
— Id Integer (идентификатор, уникальный код)
— FIO String (ФИО)
— Login String (Логин)
— Password String (Пароль)
— Email String (Адрес электронной почты)
— Phone String (Контактный телефон)
— Comment String (Вспомогательное поле)
— GroupType Integer (Cсылка (reference) на тип группы — админ, менеджер, руководитель ...)
— StatusType Integer (Ссылка на текущий статус — заблокирован(например когда в отпуске), активен, закрыт)
— StartDate DateTime (дата создания)
— LastActiveDate DateTime (дата последней активности в системе)
… и т.п. (
2) Есть клиенты Customers их поля:
— Id Integer (идентификатор, уникальный код)
— CustomerType Integer (Cсылка (reference) на тип клиента физлицо, ип, чп, юрлицо, нко ...)
— Name String (ФИО для физлица, Наименование для юрлица)
— Login String (Логин)
— Password String (Пароль)
— Email String (Адрес электронной почты)
— Phone String (Контактный телефон)
— Comment String (Вспомогательное поле)
— StartDate DateTime (дата создания)
— LastActiveDate DateTime (дата последней активности в системе)
— StatusType Int (Ссылка на текущий статус — заблокирован(например по собств просьбе), активен, закрыт)
— AddressReg String (Адрес регистрации для юрлиц)
— AddressCorr String (Адрес корреспонденции для юрлиц/физлиц)
— INN String (ИНН, для других стран — другой идентификационный финансовый уникальный код)
— IdChief Integer (ссылка на эту же модель(таблицу) на физлицо руководителя, для юрлиц, для физлиц=null и не показывается во view)
— IdAccountant Integer (ссылка на эту же модель(таблицу) на физлицо бухгалетера, для юрлиц, для физлиц=null и не пок
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ
eax.me/programming-language-learning/
eax.me/beginning-programming/
habrahabr.ru/company/rootwelt/blog/302364/
Мои 25 копеек:
1. Вы делаете демонстрационный проект на соискание джуна. Он должен стремиться быть идеальным во всем, кроме сложности. То есть если Вы — столяр-школяр, то для Вас лучше идеальная табуретка, чем криво сделанный шкаф в византийском стиле.
2. Сделано должно быть так, чтобы было понятно Ваше творение во всех деталях с первого раза (прозрачный код и пользовательский интерфейс).
3. Проект должен собираться при минимальном вмешательстве со стороны. Для учебного CRM не годится, если для его развертывания придется танцевать час с лишним до/после установки (не нужно заводить несколько логинов, распределять роли, назначать сложную авторизацию по группам и т.п.).
4. При проектировании учебного проекта не стоит ставить максимально-высокие цели, надо сделать приоритет на легкости расширения функционала.
Исходя из этого:
1) Напишите ТЗ с этапным созданием. Это не должен быть 200страничный труд, но и десять строк вымученных в notepad-е тоже не годятся.
1.1) Поэтапные требования к функционалу.
1.2) Требования к архитектуре ПО (основное — независимость составляющих).
1.3) Требования по срокам реализации.
1.4) Требования к моделям с описанием стандартных процессов (Например Клиенты. Есть возможность Ввести-Отредактировать-Удалить-Импортировать-Экспортировать(TXT,CSV,JSON,XML) клиента. Есть разграничение прав на данные действия.
1.5) Требования к тестам
1.6) Требования к СКВ (система контроля версий — Git, SVN и.т.п)
…
2) При проектировании делайте упор:
2.1) На независимость модулей. Например, если необходимо добавить другой язык, то это должно быть сведено к новому файлу properties внутрь которого внесены все строковые константы + прописать наличие данного файла и возможность его выбора (а не вылавли
Постараюсь за неделю-две набросать подробный план реализации и выложить тут.
1) Есть пользователи системы Users. У них есть следующие атрибуты:
— Id Integer (идентификатор, уникальный код)
— FIO String (ФИО)
— Login String (Логин)
— Password String (Пароль)
— Email String (Адрес электронной почты)
— Phone String (Контактный телефон)
— Comment String (Вспомогательное поле)
— GroupType Integer (Cсылка (reference) на тип группы — админ, менеджер, руководитель ...)
— StatusType Integer (Ссылка на текущий статус — заблокирован(например когда в отпуске), активен, закрыт)
— StartDate DateTime (дата создания)
— LastActiveDate DateTime (дата последней активности в системе)
… и т.п. (
2) Есть клиенты Customers их поля:
— Id Integer (идентификатор, уникальный код)
— CustomerType Integer (Cсылка (reference) на тип клиента физлицо, ип, чп, юрлицо, нко ...)
— Name String (ФИО для физлица, Наименование для юрлица)
— Login String (Логин)
— Password String (Пароль)
— Email String (Адрес электронной почты)
— Phone String (Контактный телефон)
— Comment String (Вспомогательное поле)
— StartDate DateTime (дата создания)
— LastActiveDate DateTime (дата последней активности в системе)
— StatusType Int (Ссылка на текущий статус — заблокирован(например по собств просьбе), активен, закрыт)
— AddressReg String (Адрес регистрации для юрлиц)
— AddressCorr String (Адрес корреспонденции для юрлиц/физлиц)
— INN String (ИНН, для других стран — другой идентификационный финансовый уникальный код)
— IdChief Integer (ссылка на эту же модель(таблицу) на физлицо руководителя, для юрлиц, для физлиц=null и не показывается во view)
— IdAccountant Integer (ссылка на эту же модель(таблицу) на физлицо бухгалетера, для юрлиц, для физлиц=null и не пок