Пояснение про "Объявление. Ищу сотрудника для реализации проекта"
У меня реально мало свободного времени.
Гораздо меньше, чем идей для реализации.
И идеи я реализую во внерабочее время. И оно крайне ценно.
На работе я реализую, пусть и "схожие" задачи, но другие.
И я всецело занят ими.
Поэтому было бы неплохо найти такого человека, которому поставил задачу и "на некоторое время забыл".
Я утрирую конечно.
Но как-то так.
И ешё:
Насчёт соглашений о стиле кода - дело такое - смотрите как оформлен код в уже существующих модулях и старайтесь следовать общему стилю.
Ещё два важных момента:
1. Для ЛЮБОЙ задачи отводим СВОЮ ВЕТКУ от Developing. И коммитим и пушим в эту ветку. Обратно в Developing сливаю я.
2. Как только отвели ветку - надо запустить тесты. И посмотреть - прошли они или нет. Если не прошли, то разобраться почему. Ну и далее в процессе переделок запускаем тесты и смотрим на их результат.
Development Case - у меня нет. Если сильно надо, то можно со временем написать.
Но я предпочитаю подход - "задал вопрос, получил объяснение, пишешь документацию" - О коммуникациях и "передаче знаний".
И ещё...
У меня тут некоторые напряги в семье - поэтому ближайшее время могу быть не всегда доступен.
Список задач можно посмотреть тут:
https://bitbucket.org/lulinalex/mindstream/issues?status=new&status=open
Да! И если я кому-то кажусь снобом, то таки я - не сноб. Я просто 20-ть лет на одном месте работаю. Так что - да - несколько зашорен.
И ешё. Сторонние библиотеки мы принципиально не используем. Должна быть очень веская причина, чтобы использовать сторонние библиотеки.
И да. Мы исповедуем MDP.
И ещё - по деньгам - я предельно честен. Вы делаете код, я плачу деньги. НО! Нет кода - нет денег. Все остальные детали - обсуждаемы. Плачу я из своего кармана. Из "подушки".
Но есть люди, которые готовы выступать в роли спонсоров. Но им нужен рабочий прототип.
И ещё - не стоит упоминать JSON и XML. У меня на них - аллергия. Я уже лет двадцать занимаюсь обработкой различных форматов данных - Обработка текстов. Генераторы, фильтры, трансформаторы и "SAX на коленке".
В проекте я выполняю роли:
1. Представителя заказчика.
2. Архитектора (и эту "поляну" я обычно НИ С КЕМ не делю).
3. Программиста.
4. Тестировщика.
Ну и КОНЕЧНАЯ ЦЕЛЬ проекта - сделать "коробочный продукт" для ВЕДЕНИЯ ИНФРАСТРУКТУРЫ проекта - от ТЗ, модели (UML) и прецедентов, до кода, тестов и "скриптовой автоматизации".
В виде отдельностоящего приложения или плагина к Delphi - я ещё не решил как точно.
Идея примерно такая:
1. Пишем ТЗ.
2. Рисуем прецеденты на модели.
3. Транслируем прецеденты и их детализацию в "скелеты сервисов" - http://programmingmindstream.blogspot.ru/2015/03/blog-post_12.html
4. Реализуем код сервисов.
5. Используем сервисы в приложении.
6. Регистрируем сервисы в скриптовой машине.
7. Пишем тесты (модульные, нагрузочные, регрессионные и GUI) на основе сервисов - http://programmingmindstream.blogspot.ru/2015/02/gui.html.
8. В итоге получаем приложение, которое использует сервисы как для РЕАЛИЗАЦИИ, так и для ТЕСТИРОВНИЯ.
9. В итоге получаем - "хорошо тестируемое приложение" - http://18delphi.blogspot.ru/2014/05/blog-post.html.
И в итоге - моя "дорожная карта" - сойдётся.
У меня реально мало свободного времени.
Гораздо меньше, чем идей для реализации.
И идеи я реализую во внерабочее время. И оно крайне ценно.
На работе я реализую, пусть и "схожие" задачи, но другие.
И я всецело занят ими.
Поэтому было бы неплохо найти такого человека, которому поставил задачу и "на некоторое время забыл".
Я утрирую конечно.
Но как-то так.
И ешё:
Насчёт соглашений о стиле кода - дело такое - смотрите как оформлен код в уже существующих модулях и старайтесь следовать общему стилю.
Ещё два важных момента:
1. Для ЛЮБОЙ задачи отводим СВОЮ ВЕТКУ от Developing. И коммитим и пушим в эту ветку. Обратно в Developing сливаю я.
2. Как только отвели ветку - надо запустить тесты. И посмотреть - прошли они или нет. Если не прошли, то разобраться почему. Ну и далее в процессе переделок запускаем тесты и смотрим на их результат.
Development Case - у меня нет. Если сильно надо, то можно со временем написать.
Но я предпочитаю подход - "задал вопрос, получил объяснение, пишешь документацию" - О коммуникациях и "передаче знаний".
И ещё...
У меня тут некоторые напряги в семье - поэтому ближайшее время могу быть не всегда доступен.
Список задач можно посмотреть тут:
https://bitbucket.org/lulinalex/mindstream/issues?status=new&status=open
Да! И если я кому-то кажусь снобом, то таки я - не сноб. Я просто 20-ть лет на одном месте работаю. Так что - да - несколько зашорен.
И ешё. Сторонние библиотеки мы принципиально не используем. Должна быть очень веская причина, чтобы использовать сторонние библиотеки.
И да. Мы исповедуем MDP.
И ещё - по деньгам - я предельно честен. Вы делаете код, я плачу деньги. НО! Нет кода - нет денег. Все остальные детали - обсуждаемы. Плачу я из своего кармана. Из "подушки".
Но есть люди, которые готовы выступать в роли спонсоров. Но им нужен рабочий прототип.
И ещё - не стоит упоминать JSON и XML. У меня на них - аллергия. Я уже лет двадцать занимаюсь обработкой различных форматов данных - Обработка текстов. Генераторы, фильтры, трансформаторы и "SAX на коленке".
В проекте я выполняю роли:
1. Представителя заказчика.
2. Архитектора (и эту "поляну" я обычно НИ С КЕМ не делю).
3. Программиста.
4. Тестировщика.
Ну и КОНЕЧНАЯ ЦЕЛЬ проекта - сделать "коробочный продукт" для ВЕДЕНИЯ ИНФРАСТРУКТУРЫ проекта - от ТЗ, модели (UML) и прецедентов, до кода, тестов и "скриптовой автоматизации".
В виде отдельностоящего приложения или плагина к Delphi - я ещё не решил как точно.
Идея примерно такая:
1. Пишем ТЗ.
2. Рисуем прецеденты на модели.
3. Транслируем прецеденты и их детализацию в "скелеты сервисов" - http://programmingmindstream.blogspot.ru/2015/03/blog-post_12.html
4. Реализуем код сервисов.
5. Используем сервисы в приложении.
6. Регистрируем сервисы в скриптовой машине.
7. Пишем тесты (модульные, нагрузочные, регрессионные и GUI) на основе сервисов - http://programmingmindstream.blogspot.ru/2015/02/gui.html.
8. В итоге получаем приложение, которое использует сервисы как для РЕАЛИЗАЦИИ, так и для ТЕСТИРОВНИЯ.
9. В итоге получаем - "хорошо тестируемое приложение" - http://18delphi.blogspot.ru/2014/05/blog-post.html.
И в итоге - моя "дорожная карта" - сойдётся.
По ветке на каждого разработчика выглядит несколько накладно. Предлагаю присмотреться к разработке через форки и пулл-реквесты. Так сделано на github, что весьма удобно.
ОтветитьУдалить