Всем привет, решил поделиться рандомными мыслями. Более интересно начинающим разработчикам, но думаю все могут что-нибудь добавить или обсудить. Погнали!
#1
Разработка - это про построение систем, а не чисто про написание кода. И да, это сложно. Заниматься этим можно, только если это действительно тебе интересно. Будешь себя насиловать, выгоришь или станешь просто грустным.
#2
Выбери техстек, конкретный ЯП и хотя бы лет 5 придерживайся его. Экспериментировать можно, но не стоит много метаться между стеками. Ценятся хардскиллы, конкретная экспертиза, а не поверхностные знания всего и вся.
#3
Хочешь поднять зарплату - повышай квалификацию и меняй работу. Это работает пока ты не сеньор-помидор. Дальше прирост ЗП несущественный и адекватный проект и коллектив будут цениться выше.
#4
Свыкнись с тем, что тебе надо быть немного бизнес аналитиком. Хотя бы чтоб уметь расплетать "поток сознания" гуманитариев, рано выявлять конфликтующие требования и т.п.
#5
Читай хорошие книжки, особенно по теме разработки или конкретным технологиям. В мире много людей умнее тебя (в разных вопросах), которых ты никогда не встретишь, но знания которых можешь получить через чтение.
#6
Халявы не будет. Чтобы что-то хорошо уметь, надо много страдать. Много гриндить.
#7
Пет-проекты - это весело. Если любишь разработку, будешь их клепать конвейерно. Но ни один не закончишь =D. Также это безопасный, "безстрессовый" способ экспериментировать.
#8
В коммерческом проекте два основных качества - это деньги (зп, доли, премии) и инженерная культура. Очень плохую инженерную культуру трудно компенсировать деньгами.
#10
Самые большие деньги, которые можно заработать в отрасли - это НЕ зарплата. Это доли от владения растущей компанией.
#11
Учи английский язык. Хотя бы чтоб перестать называть таблицу заказов как "order" в БД.
#12
Наличие хоть каких-то стандартов на проекте (и в жизни) - лучше, чем их полное отсутствие.
#13
Автотесты отнимают время, но помогают вдолгую. Подумай, как правильно объяснить это не-разработчикам.
#14
Первые 4 часа рабочего дня продуктивнее, чем вторые 4 часа. Голова свежее.
#15
ИИ (LLM) - прикольная технология, но чересчур захайпованная. По кривой хайпа Гартнера вполне возможно дальнейшее разочарование. Толковый мотивированный человек НЕ ЗАМЕНЯЕТСЯ никакими современными искусственными интеллектами.
#16
Много ходи пешком. Я любил использовать время обеда, чтобы просто гулять.
#17
Все эстимейты по итогу пересчитываются в часы. Всякие "стори поинты" и прочее шаманство - не более, чем дымовая завеса.
#18
Будь адекватным и вежливым, но не заискивающим. И ищи таких же. С говнюками тяжело работать, а от подлиз трудно добиться правды.
#19
Очень сложные (и важные) системы могут работать по очень простым правилам.
#20
Старайся менять работу не чаще, чем раз в полтора года. Обычно на ~100% эффективность разработчики выходят после 6 месяцев работы на одном проекте.
#21
Давай себе отдых. Если ты не заметил(а) отсутствие девятого пункта - возможно, пора сделать перерыв и прогуляться.
P.s.: Текст разрешается копировать только в неизменном оригинальном виде, с указанием авторства и ссылкой на оригинал.
Kerman
А что не так? Вроде устоявшийся термин, везде orders, во всех примерах. Есть purchase order как часть терминологии sap, например. Или то, что термин в единственном числе?
tkutru Автор
Это просто пример, возможно в SAP есть такой стандарт и там это нормально.
Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.
В более широком смысле - лучшее владение английским позволяет более точно, более репрезентативно именовать сущности, классы, переменные, функции, методы и т.п. Делать код более понятным и поддерживаемым.
Kerman
Во первых, не во "многих" а в ANSI SQL 92. Во-вторых таблицы принято называть сущностью во множественном числе, никаких коллизий при этом не происходит. При этом не понятна аргументация в сторону английского языка. Order - это совершенно корректный и общепринятый термин для обозначения заказа. Точка.
tkutru Автор
Я уже сказал, что это один из примеров, их можно найти ещё и для всего. На базе ANSI SQL 92 есть много чего, MySQL, PostgreSQL, MariaDB (кто не любит проприетарщину мускуля), Transact SQL и прочее. Это так, навскидку. Это примерно 90% всего интернета, на минуточку. Если вы лично с этим не пересекались, то вы в меньшинстве и нет гарантий, что не пересечётесь никогда. В любом случае, основная идея, что очень ограниченное владение английским будет делать ваш код хуже, менее читабельным и поддерживаемым. Или вы с этим тоже не согласны?
Насчёт того, как где принятно называть таблицы, это не истина в последней инстанции, а стандарты конкретного стека и команды/проекта. Например - как по мне - т.к. в условном мускуле нет many-to-many из коробки, надо использовать таблицу сопряжения (junction table) и вот там вполне можно использовать plural. Типа authors_to_books и т.п. А вот когда обычная сущность, лучше singular (единственное число), почему? Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers, и это странно, ведь на ООП уровне вы часто будете работать с одной конкретной сущностью, обзывая её множественным числом. В любом случае, это вопрос принятых стандартов, и "истины в последней инстанции" я в этом вопросе не наблюдаю.
Kerman
Какого стека? Какого проекта? Какой ещё команды? Order - это термин из английского языка, обозначающий заказ. Упорядочивание тоже.
Не лучше
Не будет. В любой ORM можно сделать маппинг имени класса к таблице. Какие-то это автоматом делают, вроде EF, но всё равно можно руками поправить. Ну никто же не переносит напрямую имена таблиц из snake_case таблиц в языки с CamelCase стандартом. Таблица - "orders", класс "Order", репозиторий "Orders". Это стандарт индустрии, общепринятое соглашение.