К сожалению, не могу рекомендовать Бориса к сотрудничеству из-за странных условий, качества и отношения к работе.
#️⃣ Вступление
Задача была “тестовой”, чтобы просто познакомиться с исполнителем перед началом объёмного сотрудничества.
Перед утверждением условий:
- Предоставил Борису полное ТЗ
- Доступ в Репозиторий проекта
Разработчик сказал, что код в целом хороший и чистый, рассказал о требованиях к больших проектам(все задачи только ему, чтобы другие не писали “г*-код”; если код грязный — ставка больше).
Борис самостоятельно назначил стоимость задачи и срок, как он написал, с запасом. Утвердили.
Проблемы:
1️⃣ Ближе к концу проекта Борис стал требовать доплату, поскольку “потратил больше времени, чем планировал”.
Обозначу, в вопросах доплаты всегда готов идти на встречу:
- часто вношу бонус, если исполнитель действительно добавил новых улучшений(пример: соседний проект с Александром)
- задача оказалась сложнее и исполнитель её недооценил
- все дополнительные задачи идут отдельными проектами за отдельную плату, что можно увидеть по отзывам
Но в данном случае — с выставленными требованиями не согласен по следующим причинам:
1. Борис буквально отписывал почти каждый свой шаг в проекте, а позже рассказывал о себе, его стиле работы. Возможно, это интересно, но рамках мелкой задачи — это излишне, и только тратит наше обоюдное время: наш диалог с 1-ой малой задачей, больше чем диалог с постоянными исполнителями, где 4-5 средних-больших.
Полагаю, что на “монолог” было потрачено больше времени, чем на разработку.
2. Стал конфигурировать и копаться в тех частях приложения, с которыми не связана задача, на что я вежливо указывал.
3. Борис сообщал, что были “Требования вне ТЗ и он ещё реализовал улучшения”.
При уточнение было названо: “Не было инструкции по 2FA, пришлось её изучать и обходить; Не было аккаунта ЮниСендер для теста; Пофикшен баг;”
Но указанное - никак не связано с дополнительными требованиями. ТЗ не изменял. Также:
1) "Улучшения". В ТЗ было указано: необходимо выводить отправленные письма администраторами, чтобы контролировать их содержимое.
В системе уже был лог отправленных писем через Почтовый сервис. Борис, с моим одобрением, просто туда стал записывать письма отправленные администратором, и выводить их содержимое.
Фактически это не улучшение, а упрощение работы самому Борису - ему не пришлось делать Read-функционал.
2) Инструкции были в README, комментариях к параметрам.
☑️ Чтобы упростить работу разработчикам — сделаем ещё несколько отдельных разделов в README для конфигурации.
3) Следовало было запросить тестовые данные у меня. а) В условиях проектах специально прописано — не стесняйтесь спрашивать; б) Обычно я самостоятельно такие тестовые данные кидаю, но на этот раз упустил.
☑️ Добавил в чек-лист перед стартом проекта — выдавать демо-данные, чтобы больше не упускать.
4) Благодарен за фиксацию бага. Но указанный баг тесно связан с серверным окружением Бориса, и даже не в той части приложения, с которой следовало вести работу. Обнаружен он был во временном решении. Фиксация - обычная проверка на существование, причём правкой была затёрта TODO: который помечал временное решение;
☑️ Добавим Docker в проект, чтобы все разрабатывали с одним ENV.
4. Все детали проекта были видны до сотрудничества. Борис сам установил оценку, срок и ещё заложил запас, как сам написал. Я даже уточнял в поддержке за правоту в этой ситуации.
2️⃣ Отношение к работе/качество кода
Борис часто говорит о качестве кода(см. раздел "Вступление", абзац №3). Но о своих ошибках пишет - "Это неважно, это мелочь". Считаю, что такой подход несправедливый.
А ошибки в любом случае нестрашны, и повод поучиться для всех, тем более мы подряжаем тестера для перестраховки.
Но раз на то пошло:
1. Был отключен HTML-Encode в GridView, выводятся RAW-данные без фильтрации(зачем?). Username вводится пользователем, поэтому может содержать код для XSS-атаки(+длинная строки): https://i.imgur.com/ueToBOV.png
2. Чтобы выводить данных о пользователях, используются костыли, вместо связей(relations) БД: https://i.imgur.com/cg1HyEM.png || https://i.imgur.com/wqbMM6P.png
3. Не описан revert миграций, хотя он возможен с помощью dropColumn: https://i.imgur.com/Fx7ywLK.png
4. Жёсткая привязка к ID отправителя к авторизованному пользователю в Сервисе, что делает его непереиспользуемым, если ID нужно указать самостоятельно: https://i.imgur.com/XYrZlU4.png
5. Не используется TypeHinting в GridView, что делает неудобным переименование свойств через "Refactor": https://i.imgur.com/0fj30su.png
6. Раздувание сущности Mail. Фактически ему было привязано 3 опицональных поля, которые есть только в сценарии пользователя администратором: https://i.imgur.com/azhhfpD.png
Вместо того, чтобы сделать отдельную сущность и присвоить ей связь. А если потребуются ещё дополнительное поля для ручной отправки?
3️⃣ Остальное
На простые уточняющие вопросы, касательно "улучшений и задач вне ТЗ", чтобы понять позицию - получил претензии.
1. "Долгая проверка, долгие ответы" - у меня есть свой перечень задач, я не могу реагировать 24/7 и ни от кого этого не требую. А также время потребовалось на уточнение вопросов касательно "задач вне ТЗ" и чтение всего потока сообщений.
2. "Понятно почему над проектом работают столько людей и не задерживаются" - в проекте 2 контирбютора, помимо меня. Один занят другой задачей, второй в зоне Б/Д и испытывает проблемы со связью.
