Морально-деградационное

[metaclass]

Посрались в cкайпе с zamotivator на тему CMake, Continuous Integration, тайм-менеджмента и прочего. Был обозван работником НИИ ГиТ, СССР-овским подходом и прочими словами. Ребе забиватор занял позицию на амвоне и толкал речи капитана очевидность с апломбом протестантского проповедника :)
Объяснения, что псение на людей нужно оформлять в более аккуратные формы, т.к. оно не способствует взаимному пониманию, услышаны не были. Теперь понятно, почему его thesz забанил - неумение/нежелание уважать окружающих не способствует душевному и физическому здоровью.

Новости из идеального мира правильной разработки что от айседа, что от забиватора, конечно, огорчают. Оказывается, можно писать тесты, настраивать процессы и ставить CI и при этом получать много бабла на одной работе, вместо того, чтобы делать работающие продукты на трех работах.

Если серьезно, то CI штука полезная, но, как и с баг-трекерами и контролем версий и прочими инструментами для процессов разработки - пока это дело самостоятельно не осилишь и не попробуешь - понять, "занахрена нам инвестировать ресурсы в это дело", практически невозможно. Это как объяснять, зачем иммутабельность - кто ее использовал, тот понимает, а кто нет - пока не попользует - не поймет.

PS: Вообще говоря, таки работа 15 лет в неадекватных условиях действительно ломает мозг. Я конкретно ориентируюсь в работе и процессах на минимальный порог вхождения - потому что работать приходится с людьми, которые до сих пор пишут на 3 дельфи (а то и фокспро с кларионом) и ни о каких контролях версий и вообще процессах и слыхом не слыхивали. А уж скажи им "подключитесь к нашему серверу" - так работа на месяц встанет, пока они осиливать будут.
Т.е. конкретно есть варианты: 1) работаем с тем, что есть, понемногу поднимая уровень 2) посылаем всех, кто не дотягивает до нас, таких умных, нахер.
Второй вариант, по моему мнению, означает закрытие конторы/смену работы, т.к. заказчиков, которые реально готовы вести проекты по современным методикам (а не имитировать их в виде карго-культа) в РБ практически нет.

PPS: Собственно, сформулировал, чем меня этот срач так задел: я стремлюсь сделать продукт качественно. Чисто из перфекционизма, вызванного тем, что я ничего другого толком все равно не умею делать.

И, смотря на десятки готовых продуктов, как снаружи(как пользователь) так и изнутри(как разработчик) вижу, что моя работа на достаточно приличном уровне, хотя ниже, чем хотелось бы иметь. Наличие правильных инструментов в виде трекеров и контроля версий этому сильно помогает. До CI у меня до сих пор не дошли руки.
Сделать еще лучше, чем сейчас - мешает следующее: есть куча более важной и срочной работы, есть множество не до конца осиленных чисто технических (а не организационно-процессных) инструментов, куча интересных вещей типа SDR/DSP/embedded линуксов и прочего. Кроме того, дополнительные улучшения процессов не принесут лично мне дополнительной прибыли, а только гемор по внедрению, обучению коллег и прочая.

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

Но тут приходит молодой забиватор и начинает рассказывать, как обстоят дела с планками качества на проектах совершенно иного уровня, опенсорсных-международных типа Percona Server, про какой-то консалтинг, про каких-то менеджеров, которым он рассказывает сколько они бабок теряют из-за отсутствия CI и прочая. Меня это, очевидно, бесит, потому что мой уровень - это копаться в белорусском налоговом учете.

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

Comments

[metaclass.livejournal.com]

С оверхедом по затратам в 1000%

[jdevelop.livejournal.com]

у вас есть какие-то цифры, которые это подтверждают? у меня таких цифр нет.

[metaclass.livejournal.com]

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

[jdevelop.livejournal.com]

это не UBS, это metaclass, причем какой-то хуевый

[metaclass.livejournal.com]

Сколько в норме уходит времени на написание нормальной девелоперской документации на проект?
Если сам проект, скажем, чисто кодирование-сборка-деплоймент это две недели работы.

[jdevelop.livejournal.com]

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

и ничего, за две недели можно дохера чего сделать, и нормальную девелоперскую документацию

и да, у нас могут быть разные понимания "нормальной документации".

[metaclass.livejournal.com]

Один день - научите меня как?

[jdevelop.livejournal.com]

сначала надо определиться, что как пишется "нормальная документация"

[metaclass.livejournal.com]

Документация, которую можно отдать джуниору и забыть о нем на две недели, пока он будет делать.

[jdevelop.livejournal.com]

и что конкретно не получается?

[metaclass.livejournal.com]

Неясен уровень, до которого нужно детализировать документацию.
Если как написано в стандартах по SRS/SDD - так там явно одним днем не обойдешься.

[jdevelop.livejournal.com]

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

2) интерфейсы модулей, ко с кем по каким протоколам взаимодействует (протоколы - это и сигнатуры в том числе)

3) "ядро" модуля в интерфейсах, чтобы было с чего начать.

и это
а) можно написать за один день для проекта, расчитанного на два-три дня. Можно еще и закодировать какие-то куски в процессе

б) можно отдать джуниору и он сделает, что от него требуется.

А в то время, как джуниор лячкает говнокод, ребе может написать приемочные тесты для модулей.

и не надо тут ISO9000 и прочих артефактов, здравый смысл и нагайка.

[9zloy.livejournal.com]

Такой документации НЕ существует. Джуниору ничего нельзя отдавать. Вообще ничего. Он же даже переменные назвать не сможет в 50% случаев. Ему можно отдать только код, чтобы он его закомитил. И то лучше проверить, не использовал ли он сука -f

[metaclass.livejournal.com]

Вот. А мне тут сказки про документацию и про процессы рассказывают.

[9zloy.livejournal.com]

Так а че, это ж ясно. С джуниорами никакой процесс не поможет. Джуниоров надо учить, а не требовать выполнять 67 правил. Нам, к примеру, некогда учить джуниоров. Поэтому мы их не берем. Совсем не берем. А процессы команда крутых девелоперов и сама может поставить какие надо. Главное им не очень мешать.

[jdevelop.livejournal.com]

сказки, ок

больше не буду, извенити

[jdevelop.livejournal.com]

/me ржал в голос, записал себе показать ссылку мужикам, а то они и не знают

[theiced.livejournal.com]

ты не путай помойки вида сраного епама или где ты там энтерпрайзную жабу ша высираешь и нормальную работу.

[jdevelop.livejournal.com]

Потом разберу на запчасти

[maholet.livejournal.com]

Хуйню ж написал. Один частный случай - это ни разу не доказательство..

[jdevelop.livejournal.com]

вы имеете в виду только мой опыт или предполагаете что такая документация писалась один единственный раз?

[vp.livejournal.com]

Если контора типа "три пишущих программиста", при этом каждый пишет разные проекты, то наш вариант - это то, что сказал лионет.
Давайте сразу правильно выбирать масштаб. Не гугл и не яндекс.