Николай Долганов
Так, собственно, вы последним блоком комментария и описали мою идею: есть стандарты, есть KPI, и тот же принцип KISS вполне себе сочетается с принципами SOLID. Есть разница между "зафигачить необслуживаемый продукт" и "зафигачить MVP". Если ты знаешь, как будет дальше идти оптимизация и расширение, как потенциально протестировать свой код, то оптимизация качества идёт несколько другим путём. Просто есть много проектов, где качество кода вообще выходит за рамки любых стандартов, и это порождает проблему анализа кода на этапе обслуживания и расширения. Например, я сталкивался с проектами, где считается нормой дублировать код сейчас, а оптимизировать его - потом. И это, как ни странно, не связано с лидом - он пришёл в проект позже. Но это вызывает проблемы обслуживания кода. Я видел и обратную крайность: когда человек много лет пилил проект, следуя логике тотальной оптимизации качества, а потом настолько увлёкся рефакторингом, что провести через него доработку в продакшен стало почти невозможно. В первом случае, лид работает по-старинке, пока нет глобальных переделок. Во втором случае, лид столкнулся с глобальными переделками и психанул, осознал, что если бы он применял заранее некоторые паттерны разработки, то в последние два года у него не было бы конфликта с бизнесом. В обоих случаях джуны не растут. В первом случае потому, что в работу не берутся паттерны проектирования и разработки. Во втором случае - из-за того, что только лид знает, как работает его код. В первом случае, джун сразу приносит прибыль, но эта прибыль в будущем рассеется на обслуживании кода. И первый случай неизбежно порождает второй. Когда джуны не смогут решать проблемы обслуживания и фиксить критические баги, никто их не будет держать на месте. Отсюда следует, что принципиальное значение имеет знание общих принципов и паттернов проектирования. Например, декомпозировать код, покрывать его простыми тестами, которые будут дописаны в будущем, внимательнее относиться к реализации задач и применять шаблоны проектирования вместо лобовой атаки. Это не сильно замедлит процесс, но даст более качественный код. Кроме того, это позволит джунам сразу приносить прибыль. Джуну требуется формализация реализации вплоть до псевдокода. Ему надо сразу обозначить, какие паттерны он должен применить. Проблема джуна не приносящего прибыль - это проблема лида, который занимается фигнёй вместо формализации D-требований (см. Эрика Дж. Брауде). На мой взгляд, лид не должен сам писать код. Для хорошего кода есть сеньоры. Как и для обучения джунов. Лид должен строить архитектуру и формализовать требования к коду, писать документацию. Тогда вся команда будет приносить прибыль.
Главное, чтобы юристов не нагрузил.
А правда, что людей с дипломом стабильно зомбируют постоянно всем рассказывать о том, что у них шире кругозор и системнее мышление?
К пенсии сертификаты и дипломы дадут возможность работать, не работая. Каким-нибудь мелким чиновником, например.
Я, в последнее время, чаще встречаю лидов, которые не хотят сливать в продакшен даже не джуниор код (чистый, покрытый тестами). Просто потому, что он не соответствует их представлениям о мире. Я видел компанию, где люди не перерастают джунов просто потому, что так выгодно. Поэтому, склонен не согласиться. Джун должен приносить прибыль, максимум, через 3 месяца с момента приёма на работу. Если ты берёшь 2 - 3 джунов, а прибыли с них нет ни через месяц, ни через 2, ни через 3, то это говорит о проблемах твоего лида. Есть общие правила написания кода для рынка. Например, те же solid + clean code. Высокий Test coverage позволяет в процессе ревью менять условия исполнения кода, входные данные и проверять работоспособность кода. Если твой лид гонит про то, что тесты ему не нужны, и при этом сразу не сливает код джунов, если он объективно соответствует общерыночным стандартам, то проблема, скорее-всего, не в джунах, а в высокооплачиваемом лиде. Может, он потому и высокооплачиваемый, что является носителем некоего индивидуального стандарта разработки, нигде более на рынке не встречающегося? И его замена вызовет проблемы с тем, что джуны не обучены, а новый лид будет долго разбираться с тем, что происходит в коде?
Заголовок: Кликбейтные заголовки предпочитают писать геи и моральные уроды.
Текст: на самом деле, нет!
Тело человека приспосабливается к условиям окружающей среды. Качалка - это, прежде-всего, потребность в питании. Ты питаешься больше, чаще, потом идёшь к железу, и программируешь своё тело на раскачку мышц, поскольку даёшь ему усиленную нагрузку, и механизмы твоего организма работают на прирост мышечной массы. Потом, ты бросаешь качалку: организм требует того же объёма продуктов, но нагрузки уже нет. Мышечная масса сокращается, чтобы отложить жир, поскольку тебе больше не нужна. Плюс, потребление пищи если и сокращается, то не на много.
То, что обещает битрикс, надо делить на ноль.
Так 1С же вам обещали, что там всё из коробки работает, настраивается любой обезьяной с мышкой, прошедшей курс разработчика Битрикс, который вы можете и сами купить.
Прям в голос
Смех без причины - признак кое-чего на букву Д
О, мамкины маркетологи подъехали. Конечно, конечно, чёрный лист - это зло. И охрану в магазинах надо отменить. И камеры наблюдения смущают клиентов. Вы только не волнуйтесь, здесь никто не сомневается в том, что вы - хороший бизнесмен. Вот, выпейте таблеточку.
Это же франшиза. Я недели полторы назад заказывал: в нашем городе у них всё вполне хорошо: привезли вовремя, хотя заказ был большим, вкус мне понравился. Недочёты были, но мелкие. Возможно, у компании есть проблемы с контролем качества, и новые точки, открывающиеся по франшизе, со временем понимают, как обмануть систему контроля. Либо, система заказа перегружает отдельные точки, и им выгоднее выдать брак, чем терять заказ. С этой точки зрения, конечно, вопросы идут к головному офису.
Заказываешь 5 пицц, ждёшь готовности. Отменяешь заказ. На завтра повторяешь скрипт. И послезавтра повторяешь.
Это ресурс, на котором рейтинг пользователя ничего не значит, а модерация трёт комменты, но не блокирует авторов. Ты всерьёз считаешь, что это благоприятная среда для высокооплачиваемых экспертов, а не для нищих троллей?
Знаешь, я тебя даже поддержу. Ты верно сделал, что написал пост. Надеюсь, что ответ был официальным, и тебя, действительно, удалили из ЧС.
Вот я тоже читаю комменты, и перестаю понимать, что вообще происходит? Люди всерьёз считают, что на оплату труда влияет его вид. В другой ветке какой-то дед-робототехник утверждает, что на него работают только студенты, и считает что показателем для начисления зарплаты служит знание древнего алгоритма для оптических мышек.
Безумие какое-то. Кстати, безумие неплохо оплачивается. Почему - не знаю. Так исторически сложилось, наверное.
Хм. Изначально, вопрос ставился о целесообразности воспитания второкурсников для IT компании. То, что вы переходите на оскорбления со второго комментария, пытаетесь угадать мой возраст по фотографии, в целом, ведёте себя агрессивно, не делает вам никакой чести, и показывает вас очень неадекватным работодателем. Впрочем, как я отметил в первом сообщении ветки, воспитывать второкурсников для серьёзного IT - это тоже не адекватно. И возраст человека, который скажет вам об этом, а вам будут не раз это говорить, не влияет на аргументацию этого мнения, как и на его истинность.
Действительно, понты. Это фото 2009 года.
И я не верю, что компания, нанимающая студентов, может позволить себе мои услуги.
Ужас. Но вы хоть берёте этих программистов в рабство на случай, если они вдруг решат уйти работать в другую фирму? Правда, кто их возьмёт? Так-то, работая со второго курса в одной компании, опыт в разном стеке не набьёшь. И разные методологии не освоишь.
Вопрос не в том, что айтишник должен получать меньше, а врач - больше. Вопрос в том, откуда беутся деньги на зарплаты одних и других. В случае с врачами, государство имеет возможность регулировать зарплаты как напрямую, так и путём проведения реформ. При этом, стоит отметить, что в частных клиниках врачи получают вполне достойную зарплату. Потому, что отлажены бизнес-процессы и есть спрос. В IT всё то же самое: что вы собрались там регулировать, чтобы уменьшить зарплату айтишникам и увеличить зарплату бюджетников-врачей? Вы намерены ходить и запрещать людям скачивать мобильные приложения? Заказывать пиццу онлайн? Пользоваться банковскими картами? А ведь именно такой спрос рождает приложение на рынке IT. И, даже если вы сможете навести цифровой шариат, и вернуть людей к кнопочным мобильникам и компьютерам на перфокартах, это ну никак не повысит зарплаты врачей, поскольку деньги населения всё так же будут улетать в чёрную дыру страховых компаний, оседая периодически в карманах главврачей и чиновников отдела здравоохранения.
Сама идея того, что зарплаты айтишников и врачей можно тюнинговать, говорит о безграмотности её носителя. Нужно смотреть, почему IT отрасль имеет такие финансовые запасы, и строить эффективную систему здравоохранения, а не разглагольствовать о пропасти между зарплатами врачей и программистов.
Логика закончилась тогда, когда человек попытался выдать гуманитарную идею "избавиться от богомерзких программистов" за продукт "no-code". И я это дерьмо видел сотни раз: человек спутал желаемое с действительным, показал, что не знает свою целевую аудиторию, не знает продукт, за который заплатил. Ему сделали что-то, но для чего и для кого - он пояснить не может. В принципе, уже здесь его можно было слать лесом. Нет информации, какую проблему решает продукт, как он её решает, кто его купит? Просто банальная графомания. Пусть, сперва, поучится основам IT бизнеса, а потом строчит свои промо.
И, собственно, с этого же момента становится понятно, почему его продукт 4 раза переписывался, и почему его разраб кидает его в день релиза. Чел тупо не шарит в том, что делает. Плюс, он путает принцип DRY с коммерческим обоснованием no-code. Использование либ, паттернов, реализаций - это нормально, как и автогенерация кода. Но это не имеет никакого отношения к no-code концепции, которая предоставляет, по сути, code as service. То есть, есть код, который решает некие стандартные вопросы бизнеса, и он сдаётся в аренду, а владелец code as service, имеет свой отдел разработки и обслуживания. Это и есть современный no-code. Но никак не волшебное решение, которое пишет код за тебя. Если оно и появится, то появится в пресс-релизах амазона, гугла или майкрософта, но никак не в статье программистофоба Олега Сотникова.
У вас, элементарно, каша в голове, и вы нас ею кормите. Основная проблема разработки - это перевести customer-требования - в development-требования. То есть, выбрать путь реализации. Например, вам нужно показать сто товаров на web-странице. Наиболее удачное решение - использовать тот же wix. На нём же можно реализовать продажу этих товаров и подключить простую аналитику. Но, когда вам нужно начать интеграцию с вашим складом, либо, у вас есть потребность в более обширной аналитике, вы сталкиваетесь с потребностью изучения ваших потребностей и поиска более сложного технического решения. И здесь уже начинается процесс разработки. Тот же wix имеет потолок в части параметров ваших товаров и скорости фильтрации по большому числу параметров. Это уже вопрос оптимизации запросов и обработки big data.
Вы совершили много ошибок, написав своё промо. К нему много вопросов. Самые основные:
1. Какая ваша целевая аудитория?
2. Какие конкретные проблемы вы решаете, и как?
Люди, которые осознают важность этих вопросов, без труда поймут, почему от вас сваливает разработчик в день релиза, и почему вы 4 раза переписываете саой продукт. Ответ очевиден: вы не знаете ни возможностей своего продукта, ни своей целевой аудитории. А значит, вы продаёте ничто никому. Вполне очевидно, что ваш продукт позволяет создать некие простые приложения в формате no-code, и вы бы это сказали, если бы был диалог между вами, и вашими разработчиками. Но вы их не слушаете. Вы пытаетесь продать нам не реализованные, утопические customer-требования, выдавая их за project features. Вполне ясно, что вы не донесли эти требования до своих разработчиков, а те, в свою очередь, не сформировали из них development-требования. Если бы вы знали разницу между этими требованиями, а также, процесс превращения одного в другое, то не несли бы ту чушь, что несёте сейчас. Вы пытаетесь поменять процесс, который не понимаете. Это как если бы я нанял пару физиков из местного политена, и начал бы писать статейки на серьёзных ресурсах на тему "я изменил принципы базовой физики".
Ну, как бы, использовать и настроить либу - это тоже процесс разработки. Мы же не пользуемся для разработки перфокартами, не так ли?
Слабо написать no-code решение без единого разработчика? Вот когда напишете, тогда и возвращайтесь.
Если решение может жить и продавать на wix, то мне, как программисту, оно, тем более, не нужно.
И 10 лет назад то же самое было. Только там ещё был Ucoz. А потом ещё был битрикс, на котором "вообще всё из коробки работает, Вась, отвечаем"! Объективно, пока роботы учатся ходить, а ИИ имитирует работу ботов для квипа и джаббера, нам бояться нечего. Когда робот впервые реализует небольшое ПО по ТЗ заказчика, используя качественные паттерны и готовые реализации алгоритмов, и это будет дешевле реализации человеком, вот тогда и будем сухари сушить.
Зачем же они всем всегда об этом рассказывают?