Открыть список
Как стать автором
Обновить

Как написать проект для продакшена командой из одного человека (или небольшой командой)

Блог компании VDSina.ruПрограммированиеАнализ и проектирование системУправление разработкойDevOps
Перевод
Всего голосов 30: ↑25 и ↓5 +20
Просмотры5.5K
Комментарии 8

Комментарии 8

Очень субъективная статья, и советы противоречивые.
«Избегайте многословия» — тот же Python во многом гораздо компактнее, чем предложенный C#.
Да и вообще, не так уж плохо писать много простого кода, иногда куда хуже одна строка в System.Linq с тремя лямбдами внутри, которую даже дебажить тяжело.

Кроме того, языки со строгой типизацией просто незаменимы в действительно больших проектах, монолитах, в них удобно путешествовать по коду в IDE, а если у вас микросервисы, в докере, и кодовая база каждого относительно небольшая, можно спокойно писать и на Python.
Лучше не участвовать в разработке в единственном лице. Это не только минус для самого разработчика: будете вариться в собственном соку, но и риск для бизнеса — программист может изображать видимость работы, а потом, за пару месяцев до релиза уволиться. А новый программист услышав «тут почти все готово, осталось немного доделать» скажет, что «тут вообще все переделывать надо, с этим невозможно работать».

Даже если все хорошо, и программист и бизнес довольны, выйдя с такой работы на рынок лет так через 5… может оказаться, что ваши подходы к разработке полностью устарели и вы «неликвид».
Как я говорил выше, следует придерживаться языков со строгой типизацией и избегать многословия. Это означает, что Python или Go, вероятно, являются не лучшими вариантами.

Вот про Go этот пассаж непонятен… Наверное, там можно писать всё на голых интерфейсах и сплошной интроспекции — тогда будет и "нетипизировано" и "многословно" — но это какой-то особый странный путь.

Как я говорил выше, следует придерживаться языков со строгой типизацией и избегать многословия. Это означает, что Python или Go, вероятно, являются не лучшими вариантами.

Python — немногословен и строго типизирован, любой кто захочет продолжить вместо тебя проект, легко сделает это. Странно отказываться от него)

Понравилась статья, хорошие советы. Еще при одиночной разработке могут всплыть вопросы связанные с тем какой именно продукт создается. Одиночкам приходится быть немножко аналитиком и/или маркетологом. Без этого можно легко создать продукт, который не будет решать задачу клиенту или будет никому не нужен на рынке.


Был ли у кого-нибудь опыт использования генераторов кода? В теории они должны сильно помогать в одиночной разработке предоставляя готовую архитектуру и какую-то долю функционала с качественным кодом.

Про генераторы кода не знаю, но есть фреймворки, которые по сути предоставляют готовую архитектуру с которой можно сразу начать делать проект, из того что использую я — nestjs, nuxt, с ними чуть проще чем с чистым express или vue, но при этом приходится жертвовать гибкостью проекта, при желании можно всё настроить, но будет сложнее чем с более низкоуровневыми решениями. Для меня плюсы пока перебивают минусы

Посмотрел nestjs, nuxt. Да, довольно интересные ускорялики. Даже GraphQL есть в nestjs...


Как теряется гибкость проекта при их использовании? Рассматривая документацию и примеры ничего такого не видно, все максимально открыто и доступно.


Не знаете ли что-то подобное под C#?

Разумеется, реализовать готовую для продакшена кодовую базу можно даже в vim! Но, увы, только лет через десять.

Куча людей использует vim в режиме "а-ля IDE", обвешавшись плагинами, и тратят на это вовсе не годы. А IntelliSense вообще смахивает на скрытую рекламу.


Не используйте языки без строгой типизации.

А это вообще старый как мир холивар, и подавать его как безусловный совет — ну такое.


В остальном статья полна воды.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
vdsina.ru
Численность
11–30 человек
Дата регистрации
Представитель
Mikhail

Блог на Хабре