О собственной разработке программного обеспечения

Не зарабатываешь, а присваиваешь.

Зарабатывают совсем другие люди... В частности, эти самые проводницы...

Если ты "зарабатываешь", тем, что пишешь программы, то, надо признать, что и Сечин с Миллером, и Путен Ужасный - тоже зарабатывают, они пишут программы, без которых целая страна "не сможет" существовать. Потому они и "зарабатывают". больше.

Только вот ни ты, ни они нихрена не зарабатывают. Они и ты получаете незаработанные деньги. Не воруете. Не грабите. Но не зарабатываете.



Это сообщение отредактировал Laryx - 4.09.2022 - 11:22

и тут мы приходим к тому, что многие вопросы проще решить на варезных/сторонних сайтах, там быстрее помогут чем официальная техподдержка

какие "топят", при чем здесь "снесняться"?
тебе говорят, что софт рождается годами и дописывается еще столько же
своровать он что-то хочет

Это сообщение отредактировал kinkomatik - 4.09.2022 - 16:30

Смотрел 2 раза Жуки и Жуки-2 пока на юг ехал. Разве в реале не так?

И в итоге этого рождается мастодонт, который весит терабайты, требования космические, а функционал типа тетриса, половину всего дерьма при этом от мдулей лицензирования. Давно пора отходить от этого говна, пилить прозрачные лёгкие проекты.

Хз, вдвоëм с другим прогером запилили нотный/партитурный вьювер с поддержкой кучи форматов и кучей дополнительных фич, типа перевода партитуры в гитарные табы с отображением нужных струн и прочего гомна. Ну за полтора года, ок. На момент нашего ухода у приложения было более 1.5кк скачиваний. И таки шо? Заплатили нам смешную премию - и ебитесь дальше, как хотите, на ваши места набраны дешёвые студенты, они будут дальше тащить проект. Так что я последнее время не желаю делать всë в идеале, нахуй надо. Рефакторинг, ревью, фикс багов и минимум разработки.

Размещено через приложение ЯПлакалъ

К сожалению, пока ты будешь "пилить прозрачный и лёгкий проект", тебя десять раз опередят те, кто "из дерьма и палок", пользуясь огромным монструозным фреймворком "слепит" аналогичный проект, и будет иметь внимание пользователя, а твой проект, может быть, и лучший - никому не будет нужен.



Здесь ситуация та же, что и в остальной экономике - народу надо побыстрее, да подешевле, а то, что работает кое-как, и ресурсов дохрена потребляет - мы как-нибудь переживём...

Да ты просто в воронку МойОфис ни разу не попадал, да и в школы их сейчас бесплатно устанавливают. Имхо, проблема другая: пока петух не клюнет, никто сам по себе не перейдет с привычного мс на разработку в фазе становления. Нужно или уникальными удобными фичами снабдить продукт, или сделать что-то мощнее, круче Microsoft Off, что выглядит само по себе (с учетом стартовой позиции) как фантасмагория. Пока всех добровольно-принудительно не переведут, так и будут все болтаться.

Вот именно, что из говна и палок. Вот так и работаем.

А нормальный программист должен знать как работает проц, память и уж тем более сеть, если учесть, что сейчас почти весь софт имеет сетевое взаимодействие. И, между прочим, роутер и свитч по разному обрабатывают сетевые соединения и человек, который программирует сетевое взаимодействие - это знать должен.

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

Это называется документированием интерфейса, в вашем случае - хидер файла.
К комментариям в коде это отношения не имеет.

Просто в Вашем случае, если что-то на 2 порядка выше хелло ворлд и Вам не обойтись без комментариев, то, скажу Вам, что Вы НЕ умеете проектировать код. Конечно, если взять антипаттерн superclass, где у вас мегабайты кода, то да, в таком говне без комментариев не разобраться.

Как-то все очень утрировано у ТСа. Все программисты - исключительно "капризные дети".
Дети - это те, кто закончил онлайн-курс или прочитал книгу "С++ для чайников за 21 урок" и с этого начавшие свой путь в профессии.
А есть и нормальные.

Как занятый в machine-learning проекте, могу сказать, что это тоже говно то еще..

Почему же, одно другому вовсе не мешает.

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

Вот, как раз, совсем недавно, в коде сделал комментарий, что обычная функция сравнения строк не годится, нужна специальная (там особые случаи есть), и ссылка на эту функцию в хедере. Чтобы если я возвращусь к этому коду через год - не было желания заменить сравнение строк в этом месте на обычное cтроковое сравнение.



Это сообщение отредактировал Laryx - 5.09.2022 - 13:40

Комментарии должны объяснять, почему здесь сделано именно так, а не иначе.

Как ты с помощью "самодокументирующегося" кода это сделаешь?

Это как раз и является хорошим примером комментариев в коде - не очевидное использование функционала.

Да там и других перлов хватает

DevOps существует для выбивания лишних денег зарплаты на модном слове, а не для улучшения разработки

Позвольте не согласиться.

Работал я в одной конторе с очень извращенным понятием о DevOps. Представьте себе проект на котором работают несколько разрабов. Вот выпускается версия и отдается в тестирование. Естественно находятся косяки, но новая версия не выпускается, а начинают выпускаться патчи, исправляющие эти косяки. Что то исправляет проблемы, что то создает новые, на патчи выпускаются патчи и т.д. в итоге к моменту когда нужно отдать версию в продакшен, тимлид начинает бегать и собирать по разным репозиториям эти патчи, что то где-то забыл, на что то где-то забил... версия уходит клиенту кривая, клиент негодует..... А нужно то всего лишь организовать нормальный DevOps...

P.S. а когда тимлид идет в отпуск или заболеет, вообдще веселуха)
P.P.S. Если кто-то думает что DevOps это только про организацию доставки продукта(обновлений продукта) клиенту, то вы сильно ошибаетесь...

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

На рубеже веков был редактор Atlantis - замена ворда на 1 дискете (1,44 мегабайта) и им реально люди пользовались, и им хватало!

Это называется "чего изволите господин разработчик? Можно я вам ботинки почищу и премию за просто так выдам, а программу когда сделаете - тогда и сделаете"

Я уже в паре контор поработал, где модный DevOps внедряли(не основная деятельность).
Качество программ не улучшилось ни на грамм, даже, пожалуй стало хуже.
То, что уже давно качество программ стало хуже старых времен Waterfall - это безусловно, и намного хуже. Но вот в краткосрочной перспективе падение качества не так явно заметно, хотя общая тенденция деградации качества - налицо.

Вот в том то и проблема, что люди зачастую не понимают разницы между компаниями, занимающимися разработкой ПО как основной деятельностью и компаниями(или отделами), которые пилят ПО под конкретно взятые производства(программисты на заводе и т.п.).

Последних большинство, но т.к. эти команды зависимы от внешних факторов и на них постоянно давят, они никогда не выпустят продукт уровня первых.

Ну например: достаточно сложно объяснить директору по производству, зачем на
каждый написанный метод нужно написать еще один, который будет делать только одно- проверять первый.(тесты, зачастую занимают половину объема ПО, а иногда и больше). Зачем один человек тратит часть времени на проверку кода другого. и т.п.

И получается, что управленцы считают что программеры - это обслуживание основного бизнеса, а потом удивляются, а почему это у них нормального ПО не получается уровня Microsoft или Google. Печально это...

Хм...

Мне вот интересно - топик-старт сам в какой области "плотно и профессионально" разработкой занимается? Это главный вопрос.

Кратенько о себе: webdev и devops (когда это так ещё и не называлось даже) - с 1998 года (а так вообще кодить/админить начал ещё в 1988 примерно), в период с 2002 по 2005 много и плотно занимался PDM-системами, с 2007 подсел на ERP-support (основной продукт, который в поддержке - Mapics - редкий зверь под специфические производственные задачи). Ну и всё это время продолжался webdev и devops. По стэкам прошёл от Perl и PHP3 до PHP8 и NodeJS, от ванильного JS до Vue3 и React, от MySQL3 и Access в качестве prod-DB до MySQL8 и MSSQL2014, параллельно задев Postgre и Oracle. В devops прошел от Netware и net-script до виндовых лесов, AD-on-linux и всех прелестей gitlab-ci и github ci/cd... В общем, есть некоторый опыт. Также есть опыт создания и рулёжки команд (2 собственных стартапа, один сдох, один удачно продали на "посеве"). В данный момент работаю в найме + проектная работа в режиме полуфриланса (длинные контракты).

Ну поехали по пунктам...

Имеем некий бизнес, который решил пилить IT-продукт. А можно узнать - что за продукт этот чудный? Это профильная область для чудного бизнеса или "просто озарение снизошло, что надо запилить вот такую хрень"? :) Это В КОРНЕ меняет подход к начальной разработке и даже формированию команды, если что.

Бизнес-идея и даже ТЗ - это... Так, общий примерный план. Не более того. Потому что предсказать организационный сдвиг на основе технических решений - это даже не фантастика. Это невозможно. Точнее, возможно, но в узкой области (типа "вот тут допилим фичу - будет вот так") и при условии опыта боевой работы с продуктом хотя бы года 3.

Сразу "отсечём лишнее описание" - если продукт непрофильный для бизнеса (не решает его "болей") - это чистой воды "классический стартап с начальным финансированием". Ничего общего с "промышленной разработкой" не имеет, требует специфическую команду и "двинутого на идее фаундера" (без него даже реально-рабочий MVP не нарисуешь хоть с мильярдом баксов). Поэтому таки допускаем, что продукт в той или иной мере "профильный" и есть где снимать экспертизу по бизнес-логику.

И... Команда на первые полгода не нужна. "Чиста IT-шников". Нужен продакт и пару аналитиков. Ещё хорошо иметь "сильно бывалого" внедренца в качестве консультанта. Который "видел много говна на реальных завалах". В таком раскладе за полгода вполне себе можно софрмировать понимание "как именно и что именно мы решаем" и "на каких стэках". После этого начинаем потихоньку формировать команду. Реально на стартовом этапе в пределе надо 5-6 человек на постоянку. Хотя в большинстве случаев надо 3-4. Но уровня уверенных сеньоров. Да, это не дёшево, но и не так уж дорого в рамках бизнеса.

Дальше за полгода вполне себе запилится MVP в рамках задачи. Тут ключевой момент - это первичка и схема внедрения. Они должны быть рождены за первые полгода работы продакта и аналитиков. Поэтому MVP изначально должен иметь вменяемую логику, хоть как-то обрисованную хотя бы в какой-нидь базовой схемке по IDEF0. Этот MVP даст понимание о логике внедрения. Дальше где-то год будет пилиться "более-менее полный продукт", который ещё не реально продавать "сторонним заказчикам". Управление балансом фич и технического долга должен вести продакт, который должен понимать "что за продукт делается".

Если вся эта история уложится в 1 или 2 "глобальных рефактора" за первый год - это значит собрали весьма недурную команду. Если больше 4 - можно хоронить продукт без смены команды.

Итого через 2 года вполне себе можно выкатить некую "версию 0.9", которую можно впулить 2-3 заказчикам в профильном рынке на условии "очень большой скидки", ибо на них будет отладка. Это будут "друзья навек", если продукт взлетит. На этих 2-3 будет отладка фронта внедрения, как раз с первой "продажей" надо начинать формировать уже нормальный суппорт полной схемы - от внедренцев и front-line до встраивания 2 или 3 уровней поддержки... Примерно ещё за год продукт начнёт формироваться, станут примерно понятны "куда дальше фичи крутить" и надо будет раздувать команду разрабов до 15-20 человек с выстраиванием логики разработки и разделением зон ответственности между группами.

Итого примерно через 3 года после начала процесса при условии разработки в области, где есть бизнес-экспертиза у тех, кто это затеял - вполне себе можно напилить продукт, который реально продать.

А то, что ТС написал - это когда люди, у которых есть чуть-чуть денежков, решают запилить "типа стартап" совершенно не понимая "как это работает". Стартап - это не идея. Это не команда. И не деньги или инвесторы. Стартап - это когда есть "психованный на идее, который способен худо-бедно повести команду и ему повезло откуда-то добыть денег на начальную фазу (это отнюдь на MVP)". Если "психа" нет - стартапа не будет. Будет "попытка разработки". Учитывая перенасыщенность нынешнего рынка "всяко-разными решениями, включая всякий no-code" - это будет попытка сделать ежа из ужа молотком и нитками. Сдохнет в общем.

PS. Ничего личного к ТС. Просто некоторый опыт.

Это сообщение отредактировал andysh888 - 6.09.2022 - 12:12

А в чём проблема "10 млн. записей"?

У меня вон щас база ERP крутится с 2006 года. Под полсотни таблиц с 20-30-40-50млн. записей. Сервак - 4-головый XEON 2650 с 32Gb памяти. Всё прекрасно летает. Самый термоядерный отчёт (аналитика за произвольный период с прямой выборкой из рабочих таблиц с теми самыми 20-30-40млн. записей, причём там затрагиваются чуть ли не все эти таблицы) формируется около 25-30 секунд по SQL-time.

Всякая текущая работа - все запросы в рамках 0.5-1 секунды, львиная доля - - в пределах 0.2-0.3 сек

Что не так с 10млн. записей?