Скільки рішень ухвалює розробник? Погляд новачка, який запускає продукт

Автор цього блогу — Python-девелопер Сергій Солдатов, який вирішив створити досить унікальний продукт. І це в умовах перегрітого ринку праці й захмарної конкуренції.

Але спочатку ми вирішили розпитати у девелопера про проєкт та можливості для того, щоб читачі змогли співвіднести задачі та рішення, які він ухвалював. Передаємо йому слово. 

Про Shallwe

Shallwe — це українська платформа для пошуку сусідів для спільної оренди житла. Все просто — ти реєструєшся, заповнюєш анкету та отримуєш доступ до анкет інших. Нічого зайвого.

Ти будеш бачити тільки точний збіг з анкетою — бюджет, вподобання, наявність тварин, тощо. Знайшов кого треба — пишеш, домовляєшся і ви або підселяєтесь, якщо вже є житло, або шукаєте його вже разом самостійно.

Наша задача — звести людей зі схожою потребою, які можуть ужитись.

Як ми знаємо, така потреба є. І часто доводиться просто відмовлятися від ідеї сусідства, хоча вона може бути дуже вигідною.

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

Далі вже плани залежно від циклу фідбеків по українській версії та можливості маштабувати ідею на захід.

Навіщо цей проєкт?

Для мене це можливість взагалі не шукати роботу, якщо команда джунів покаже свою здатність добре працювати й продукт можна буде масштабувати.

Це можливість шукати роботу, маючи вже сильний досвід й не штовхаючись з трейніками в черзі на роботу за 300$.

В цілому для всіх в моїй команді це можливість навчитись працювати на стартапі від А до Я — від перших ідей до перших-других-третіх проблем на проді.

І навчитись самостійності, швидкості, гнучкості, командній роботі, здатності ухвалювати інформовані рішення й нести відповідальність перед іншими, розуміти краще бізнес й т.д.

Ну й стандартні технології звісно вивчити набагато глибше, ніж на курсах та на фрілансі, тому що практики більше й загалом задача набагато складніша за фріланс.

Рішення високого/середнього рівня абстракції

І так, питання високого/середнього рівня абстракції, які мені доводиться зараз вирішувати:

• на яких технологіях будувати (затратність, простота у використанні, підводні камені, перспектива розвитку, і т.д.);
• які архітектурні підходи обрати, які з ними можуть бути проблеми — які з цих проблем неважливі, які важливі;
• в якому порядку реалізовувати;
• які принципи та практики з написання коду, тестів і документації встановити на глобальному то локальних рівнях;
• які пакети й дизайн-підходи використовувати для рішень конкретних блоків задач;
• чим зараз можна пожертвувати, щоб прискорити розробку;
• на чому треба зупинитися подовше, бо там можливо приховані дуже важливі проблеми;
• як доставляти код, які створити середовища, як організувати свою ефективну взаємодію з іншими розробниками, QA та девопсом;
• яким чином зараз тестувати концепт, наскільки глибоко тестувати, скільки часу на це виділити;
• як грамотно організувати залежності в модулях;
• і традиційно періодичні питання: чи все вірно я придумав? Або треба переглянути? Якщо так – то що?

А крім того, на рівні імплементації — також постійні рішення. Навіть просто неймінг це важливо. І  написання коду — це щоденні рішення у спробах передбачити, як далі буде розвиватися цей код.

Будь-яку задачу можна реалізувати у 150 різних способів.  І з них швиденько треба обирати ті, які принесуть менше потенційних проблем, але й достатньо швидкі у реалізації та просто читаються.

Постійні рішення

• Наприклад, обираєш бібліотеку під одну задачу — треба замислитися про те, чи не буде швидко розширюватися функціонал (і тоді вона вже не підходить). Потрібно дивитись як її підтримує автор, бо можливо там є баги, які ніхто вже не пофіксить. Або ще якісь проблеми;
• як декомпозувати задачу, яким методом, як пріоретизувати частини; наскільки глибоко її розбирати заздалегідь, а що можна зробити вже на ходу;
• чи використовувати тут TDD або *підставити практику*;
• де можна менше тестувати модуль, бо окремі частини вже протестовані;
• як саме писати ці тести, на що тестувати, як оформити тест-кейси;
• чи треба тут витрачати час на рефактор або ні, чи очікуються тут якісь зміни?;
• як краще реалізувати алгоритм? чим пожертвувати?

Навіть трейні потрібно ухвалювати рішення, які приведуть до ОК від старшого девелопера. І навіть рішення про те, де краще спитати, а де краще самому розібратись.

Вчіться брати відповідальність за рішення, це ваша робота, ким би ви не працювали. Це універсальна навичка.

Блог створено на базі допису автора в LinkedIn