Я чёртовы сутки просидел над таской. Нужно было спроектировать самостоятельный модуль, а людям с тяжелой формой перфекционизма нельзя давать задачи на проектирование.
У меня была неделя — целая бесконечность, которой мне не хватило. Снова и снова я перебирал в голове варианты использования того, что должен сделать, но картинка идеального модуля не клеилась. Всегда находился кейс, который хорошо показывал: такой дизайн — говно. Я думал, играл на гитаре, пробовал писать, тупил в монитор, гуглил, играл с детьми, снова думал — голова всегда была занята дурацким модулем.
В последний день я был на пределе, потратил двадцать часов на работу не вылезая. И вот — вечер воскресенья, я безумно хочу спать, но всё ещё сижу и пытаюсь придумать подходящее название для какого-то класса в своём псевдокоде, чей дизайн, конечно же, отправиться на помойку сразу, как только я его закончу, потому что он слишком неидеальный. За несколько часов до дьюдейта у меня не было ничего, кроме убитой поисками недели.
В понедельник утром я отправил пулл реквест. Его приняли с восторгом. Но способ, на который я пошел… вот уж никогда не думал, что отважусь на такое.
Говорят, разработка — коллективный труд. Я бы сказал по-другому: в разработке коллективное все, кроме самой разработки. Коллективный результат, коллективные обсуждения, синкапы, где вы проговариваете планы. Но сам процесс работы над кодом — просто солипсически изолированный от остальных людей.
Когда задачи распределены (а описание задачи — это 1% от дела), каждый сам за себя. Ты продумываешь свой код один, пишешь его один — причем не дай бог кому заглянуть в твой монитор в этот момент. Ты выбираешься из своей головы в люди, когда у тебя уже есть, что им показать. Вы обсуждаете, а потом снова изолируетесь в своих одиночествах.
Показать неготовый набросок — катастрофа. Как будто тебя увидят не просто голым, а без кожи, без черепа. Увидят все твои обычные несовершенные мысли, которые еще не оформились в умные решения.
То есть “коллективная работа” это не какой-то десятимозговый организм, где все вместе, все в десять раз быстрее, лучше, и купаются в синергии. Коллективная работа — это все та же работа в одиночестве, просто с ритуалом скидывания наделанного в одиночестве в общую кучу.
В готовых проектах намешаны строки сотен людей, и сливаясь в одном файле, они теряют авторство. Но нельзя прийти в команду и сказать “вот вам мои руки, мозжечок, и правая дуга мозга, берите, набирайте ими код”. В команде каждый самостоятельно делает свое дело один. Вообще, одиночество сознания — страшная штука. Мы смеемся над идеей солипсизма, как будто это религия тупых чсвшников. Но вот ирония: все что у нас есть для его опровержения — только собственное субъективное восприятие.
Чтобы чувствовать себя частью команды, надо приносить коллективу результаты, рассказывать о них и слушать. Это всегда путь тысяч компромиссов. А с компромиссами у меня большие проблемы.
Вот один из худших — если хочешь работать хорошо, иногда нужно писать плохой код, чтобы успевать за сроками. Я попробовал, и не смог. Не знаю, болезнь это, издержки чсв или что-то ещё, но я просто не могу закоммитить то, что считаю говном. С одной стороны, вроде это и не проблема. Качество моих решений создаёт мне репутацию парня, который работает оправданно долго. Мне никогда не дают таски, которые горят, потому что я сразу начну «трахать всем мозг». Меня спрашивают, почему так долго, я доходчиво объясняю, какие проблемы я пытался решить, почему это не тривиально, и почему важно было сделать это по-настоящему качественно. Меня не слушают, но верят.
Почему-то так важно, чтобы люди думали — совершенны не только мои результаты, но и мои мысли. А если кто-то увидит мой процесс мышления в сыром коде, то меня сразу разоблачат.
Конечно, я слишком часто оказывался в ситуациях, когда мне не хватало понимания или мозгов, чтобы сделать таск идеально. Но я всегда считал, что помощи просят только слабаки. Это тоже часть самообмана. Якобы чтобы стать достойным коллектива, надо уметь быть абсолютно самостоятельным.
Другими словами — чтобы я чувствовал себя полноценным, мне хочется одновременно быть и в коллективе, и одиночкой внутри него. Чувствуете противоречие? Я тоже, но ничего не могу поделать. И путь обмана и самообмана всегда казался мне приятнее пути компромиссов.
У меня есть друг, тоже разработчик. Мы никогда не работали на одной работе, у нас совершенно перпендикулярные стеки, но мы очень много обсуждали программирование. Работая на примерно одинаковых должностях мы очень любили встретиться, и поврать друг другу вдоволь, как круто мы всех разносим на своих работах.
Тот момент, когда тебя впервые называют Senior — охеренный, он случился у нас одновременно. Болтая, мы высмеивали своих коллег (иногда выдуманных), потому что наша с ним дружба всегда содержала очень высокий градус конкуренции и взаимного уважения. Нельзя было просто так прийти и сказать: «Антоха, а вот сегодня я по-настоящему облажался». Мы два самозванца, которые раздувают свою самооценку до астрономических масштабов, чтобы спастись от своей никчёмности.
Но когда моя неделя на проектирование модуля подошла к концу, от никчемности было уже не спастись.
Мне в скайп позвонил Антоха. Хотел обсудить, как круто он сегодня нахамил ПМу, которая не понимает, как устроена разработка. Видимо, я был в таком отчаянии, что самооценка не сработала. Я просто пошарил экран, открыл описание таски и спросил: «Как мне это сделать?». Это было мощное нарушение негласного контракта нашей дружбы, но Антоха просто сказал: “открывай IDE”.
Код надо было писать на C#, с которым он никогда не работал, поэтому в голове промелькнуло — потрачу кучу времени без толку. Лучше уж поспать, и на синке сказать, что эстимейт был неверный, буду работать дальше. В IDE был как раз открыт текстовый файл, где я описал последний вариант дизайна модуля. И Антоха сразу — «Я бы назвал эту штуку вот так». Охереть можно, название подошло идеально.
Он начал задавать вопросы — почему тут так, это что такое, как эти вещи связаны. Работа закипела. Мы много спорили в процессе, но это как интерактивное код ревью, причем такое, которое делается на совесть (когда не просто указываешь на проблемы, но и предлагаешь решение). Мы быстро ушли от псевдокода. Солюшн, фолдеры, интерфейсы, дока, имплементации, IoC. Модуль не получался идеальным, он получался хорошим, а тот факт, что так считал не я один — легко побеждал мой перфекционизм.
Мы сделали недельную работу за несколько часов. Не закрывая скайп, я довольный вбивал git commit, push. Вместе написали дескрипшн к пулл реквесту. Я сказал, что для меня было честью работать вместе, и ушёл спать.
На следующий день я стал всё это обдумывать и понял, что произошло какое-то дерьмо. Антоха не знает C#, никогда не работал с дотнетом, но работал со мной на равных, если не лучше. Получается он что, засранец, лучше меня что-ли?
Сразу захотелось поделать его работу вместе с ним, чтобы в очередной раз проверить себя. Но как такое предложить, я не знал. Решил подождать, вдруг сам попросит, втайне начав изучать его стек. И он попросил. Пошарил экран, показал, где застрял. Я сразу увидел несколько вариантов решений. Начали обсуждать, он принялся кодить. Быстро и круто. Из меня js-ник, как из гофера дженерик, но я действительно ему помог. Хрен его знает, как это устроено, но с тех пор всегда, когда я пишу код — у меня в голове воображаемый Антоха, который мне помогает. Ты невольно примеряешь манеру мышления своего партнёра, а уметь мыслить по-разному — очень ценное качество разработчика.
Есть, правда, одна проблема. Дурацкие NDA. Я её игнорирую, потому что верю, что Антоха не понесётся выкладывать подсмотренный IMessageReceiver в свой инстаграм.
Я долго думал, почему это работает, и решил, что тут дело не в свежем взгляде. Каждый разработчик подходит к задачам по-своему. Есть вещи, которые человек с моей манерой мышления решает за минуту, а есть такие, где мой мозг просто загоняет себя в безвыходный лабиринт из неверных решений.
Но та концепция командной работы, которая есть сейчас — не работает. Когда тебе страшно быть слабым звеном, страшно осознавать, что твой вклад меньше, чем у других. Что если ты в чем-то слаб — команда тебя выкинет.
Я слышал, у сценаристов, которые сидят вместе и толпой на ходу сочиняют сюжеты, есть термин “эмоциональная оголенность”. Это состояние, когда люди вообще не боятся думать сырые мысли вслух и публично, а чужие мысли звучат как свои. Так вот, если найдёте себе партнера, с которым сможете работать так же легко, как с собой, считайте, что все ваши профессиональные проблемы решены.
Сильнейшее лекарство от всех сомнений и профессиональных болячек — когда кто-то относится к твоей неидеальности нормально.
merhalak
Вытер слезы.
Правда неделя — совсем немного. Сейчас уже второй месяц сижу над модулем в полном моём распоряжении. Уже руки трясутся.
alatushkin
Что за компания, что за проект?)
Exponent
Странно, я явно не перфекционист, за 2 месеца сделал подсистему, загнал 2ТБ в облак и запустил в прод. Не все было красиво, но подсистема делала свое дело.
Watcover3396
Вытер слезы(1).
Правда два месяца — совсем немного. Я просидел 6 лет одновременно изучая UDK/UE4, программирование и игру-мечты которую хотел сделать в режиме ММО, я не хвастаюсь, тут нечем хвастаться, очень много времени потратил топчась на месте, ну хоть программировать научился, а игры делать — нет.
Как-то одновременно грустно и страшно, грустно что ошибся и не осилил, страшно признать свою ошибку, в теории там все просто, а вот на практике без опыта, анрил.
К сожалению мысли слишком идеализированны и абстрактны, мне показалось что скопировать готовую сингловую игру и потом уже как нибудь ее переделывать под свои хотелки несложно, к черту продумывание и документирование, на ходу решу, ага.
Zoolander
я знаком с рядом начинающих и не начинающих инди-гейм-разработчиков
многие из них вязнут в большом проекте, это частая беда
даже опытные люди, выпустившие не одну игру, бывает, увязают в новой игре и не могут выпустить ее год, хотя по виду она — двухмерная простая фигня, которую так и хочется оценить максимум в 2 недели. В одну, если графика уже есть.
Watcover3396
Да, все проблемы в наших головах, эти провалы новичков уже классика жанра.
Забавно то, что попутно изучению я читал гору статей каждый день, опыт других разработчиков, в том числе негативный, но я был уверен что как-нибудь соображу, у меня ведь все по другому, ага.
kireevmp
Особенно страшно это проявляется в работе над собственным проектом (ещё хуже, если в одиночку). Ты вроде бы пишешь, пишешь, а всё не идеально, а нужно, чтобы было лучше всех — не зря же старался! И ты никогда не закончишь, если не поймёшь, что идеального ничего не бывает, есть достаточно хорошее, чтобы быть идеальным.
Спасает одно — понимание, что не ты один такой. "Вон, люди даже в ядре Linux ошибки и баги допускают, а ты? Ты здесь написал лучше, чем они!" — говоришь себе, и успакаиваешься. Просто держишь планку, не опускаясь в совсем грязь, но и не пытаясь переплюнуть гору. Не быть же всегда идеальным.
lxsmkv
Важна архитектурная однородность. Все что нарушает ритмичную закономерность, не подчиняется общему принципу — мешает нам. Мы противимся, потому что наш мозг говорит нам — «это слишком сложно». Мы подсознательно ищем простоты и симметрии. «Всё должно быть изложено так просто, как только возможно, но не проще». Если попытаться упростить автомобиль — получится самокат.
paranoya_prod
Собственный проект, в одиночку. Четыре раза переделана не только схема БД, но и код. Все варианты рабочие. Даже красивые картинки в Визио рисовал. Но! Чего-то хочется, а чего — не знаю. Что знаю, того не хочется. Идёт третья неделя войны с собственным перфекционизмом и попытками выпендриться.
vics001
Проблема работы в одиночку, рефлексия загоняет в тупик. Хочется услышать чье-то мнение — да, все правильно, да продолжай делать это или это. Без другого мнения, рефлексия загоняет вглубь проблемы.
rcanedu
У меня нет инстаграма!
zloddey
Чуваки заново изобрели парное программирование. Поздравляю!
sudden_death
Тссс…
Szer
В тегах вроде так и написано :)
SbWereWolf
+1
try1975
Парное программирование, не? Вам понравится: habr.com/ru/post/432324
mkovalevskyi
почти екстремальное )
try1975
Я имел ввиду замечательный случай парного программирования, описанный по ссылке, которой лично меня приводит в восторг, хотя, верится с трудом в такой сахар, но если это так, то это наиболее продуктивный дуэт в истории программирования, они нашли друг друга и очень ценят такое сотрудничество, как и я
oldd
Добро пожаловать в парное программирование.
EvgeniiR
Если в команде разработчиков каждый сам за себя, у команды явно проблемы с атмосферой и отношениям между коллегами.
По поводу парного программирования, свежих взглядов, переработок, сопернической атмосферы в коллективе — все уже было описано в книге Роберта Мартина, «Идеальный Программист». И истории, кстати, очень похожие в книге представлены
grondek
Не обязательно проблемы в команде.
Свой код другим разработчикам ты показываешь или на ревью или когда нужен какой-то совет. Основную часть времени ты действительно сам по себе.
baragol
Я вообще не программист. Но «подумать об кого-то» — это и правда обычно лучше всего помогает сдвинуть с места глыбу, об которую ты уже почти надорвался в одиночку.
speshuric
Про парное программирование всё понятно (и про необходимость взаимодоверия, и про мгновенную конструктивную обратную связь, и про эффективность в удачной паре).
Но меня вот смутили моменты "Код надо было писать на C#, с которым он никогда не работал, поэтому в голове промелькнуло — потрачу кучу времени бестолку." и "Из меня js-ник, как из гофера дженерик, но я действительно ему помог.". На senior-уровне удивительно видеть удивление, что один опытный разработчик может давать разумные советы разработчику на другом языке. Ладно, если бы хотя бы один из них писал на чем-то «радикальном-маргинальном», но почти все коммерческие ЯП (C#, Java, JS, Go, C и даже С++ иногда, Python, Ruby, PHP, Object Pascal, VB и даже 1С) на этом уровне очень-очень похожи. Да, «ревьюер» должен принять, что оформление кода и многие моменты реализации другие, не должен через слово повторять «а вот у нас в [моя платформа] всё было бы лучше», но это к этому моменту (senior же!) уже должно быть гигиеническим навыком. Иначе как такой «senior» будет адаптироваться к деталям code style и к коду «соседних» команд?
Ну да, конечно есть куча «непохожих»: функциональные, как Haskell, Lisp, F# и прочие OCamlы (а знаете как увольняют хаскель-программиста? «собирай свои монадки и уматывай!» (с) Башорг :) ), с непривычной системой типов, как в Scala, или, наоборот, низкоуровневые — ассемблер, с непривычной семантикой памяти (Rust), логические (Prolog), очень специфичные по предметной области (Verilog) и т.п. В этом случае барьер не столько языковой, сколько понятийный. Но и даже здесь есть ислючение — декларативный SQL, который так или иначе на базовом уровне знает не меньше половины программистов «традиционных» языков.
Так что для опытного разработчика не нужно удивляться, что другой опытный разработчик может прочитать код на другом языке и оценить решение.
Neikist
Как перешедший с 1с на котлин под андроид подтверждаю что языки просто интуитивно понимаются новые если есть опыт какой то. Но вот с фреймворками, либами, некоторыми подходами уже могут быть проблемы, правда решаются они чаще всего одним хорошо заданным вопросом в гугл или коллеге за 5 минут, пусть и не всегда.
firedragon
C 1C легче переходить на VB NET. Сугубо по семантике. Как мне кажется, все более менее успешные языки имеют корни в С.
С, С++, Java, C#, JS, PHP
Neikist
Ну хз. Из любопытства уже имея опыт с 1с в разной степени трогал плюсы, java, python, сейчас котлин вот, правда на нем уже за деньги пишу в отличие от остальных экспериментов. Разве что с плюсами проблемы возникли (хотя все равно решил задачу, пилил компоненту для 1с), и то из за ручного управления памятью и бедной стандартной библиотеки а не из за языка как такового. Один знакомый 1сник недавно бек для своего приложения на флаттере запилил на go — тоже отзывался как об очень простом языке. Хотя о go по моему все так отзываются. А, ну и js еще, несколько раз нужен был, нарисовать нестандартные интерфейсы для 1с, опять же с самим языком никаких проблем. Просто сел и начал писать хотя до того js вообще не видел, просто ориентировался на сообщения линтера когда начинал писать что то не как в js. Разве что с замыканиями там у меня какие то непонятки были, но не уверен.
vsb
Есть такая проблема. Третий месяц делаю простейшую систему. Там реально работы на день, если не рефлексировать, а тупо сесть и вбить код и это ещё больше вгоняет в депрессию. И точно так же не могу заставить себя говнокодить, прям ступор какой-то.
Ktulhy
Я в таких случаях сначала пишу так, чтобы работало, очень грязно и очень тупо :)
Если и это не помогает, то нужно переключиться на задачу с другой стороны — например, уйти от попытки выстраивать нижний слой абстракции и перейти сразу к верхнему, начать писать систему с другой стороны.
Как вариант — просто создать новый репозиторий и потихоньку подглядывать в старый (из говнокод-проектов примерно 10% кода оказались полезными, +понимание ограничений, с которыми можно столкнуться)
Psychosynthesis
Не понимаю за что человека заминусовали.
За говнокод действительно надо бить по рукам, только вот такой метод — реально работает. Когда ты пишешь что-то, что уже работает, но криво, в процессе в 99% случаев понимаешь как сделать это хотя бы немного лучше.
bobic
Мне кажется здесь очень хорошо подходят слова Кента Бека «Make it work, make it right, make it fast».
Многие вещи, о которых сразу и не подумаешь выползают уже на реализации. И наоборот, то чего сильнее всего опасался вообще не будет играть большой роли.
Сидеть и теоретизировать до бесконечности придумывая идеальное решение тоже не выход. Зачастую реализация может подсказывать пути хороших решений.
Так что нужен баланс.
Alexufo
После «Make it work» включают другое правило «работает — не трогай.» Или «там такой говнокод, лучше не лезть»
bobic
Никто же не говорит писать говнокод.
Просто сидеть и придумывать идеальную архитектуру не написав ни единой строчки кода тоже не вариант.
Нужны итерации, пускай даже для себя.
Так должна вырисовываться хорошая архитектура.
fesst
Между этими правилами есть барьер: commit. :)
ganqqwerty
Поэтому после того как сделал make it work, надо не подавать виду и тихонько рефакторить. Спросят про статус — скажи «сделал 40%».
marshinov
и это будет, кстати, правда
sumanai
Первые 90% же.
peresada
Опасная тактика, если ничто не мешает изначально сделать не говнокод, а код пусть и не особо продуманный, но без грязи. Потому что есть большой шанс, что вернуться к исправлению говнокода не будет ни желания, ни возможностей.
lxsmkv
Мне как-то коллега с девопса рассказал, что дали интегрировать кластер с кастомными конфигурационными скриптами на Groovy, написанными вундеркиндом-одиночкой и документацией архитектуры «на салфетке». «Я, — говорит, — докер, Jenkins и его Groovy API, терраформ, ансибле, и пр. понимаю. Но что с этим всем делает этот скрипт — нет!».
А я в Groovy… «знаю что функции обьявляются словом def». Сели вместе разбирать. Он пытается в vim обьять необьятное, я говорю: «Не мучайся, закинь в IntellJ там навигация, сразу тебе покажет где какая функция вызвается.… Нет, никому не скажу.» Прощелкали все, он мне по ходу рассказывает как там контейнеры разворачиваются, я ему рассказываю, как тут замыкание в функцию передается. Слово за слово и скрипт кончился. Потратили не больше часа, а до этого у него аж волосы дыбом стояли от ступора.
popov654
А можно поподробнее — что такое разворачивание кластера, Jenkins, Groovy? Что делал тот скрипт? Можно хотя бы в виде ссылок. Желательно, для совсем чайника :)
lxsmkv
Я тестировщик, а не девопс, просто тусуюсь с ними в перерывах, потому что они крутые штуки делают. Так что постараюсь пояснить как могу.
Под кластером понимается тут конгломерат из контейнеров в которых живут сервисы и службы. Jenkins это серверное ПО для автоматизации в частности для сборки. Groovy — язык программирования широкого назначения.
По общему смыслу, скрипт настраивал все службы на топологию серверной части.
Docker позволяет запустить приложение в ограниченом окружении (т.н. контейнере) и отделить его от других приложений. Все приложения заворачиваются в контейнеры.
Чтобы построить полезный сервис для пользователя, там давно уже не только apache, php, mysql, там куча всяких серверных программ, нацеленных как на сам процесс разработки, jira, git, sonar и т.д. так и на обеспечение сервиса и его надежной работы: быстрый поиск, искуственный интеллект, репликация данных и т.д. Если архитектура на микросервисах, там вообще каждый микросервис в своем контейнере может жить. Этих контейнеров сотни тысяч могут быть. Ты ими в ручную уже не сможешь управлять. У тебя есть сервис для этого, навернулся контейнер — ты не выясняешь что с ним — выкинул, вставил новый, репликация данных, и оно снова работает. В течении минут. Примерно так работает современное айти. За подробностями о каждой отдельной технологии — в гугл, потому что тема невероятно обширная.
popov654
Искусственный интелект — это что-то связанное с нейросетями, наверное? Быстрый поиск — он вроде бы средствами СУБД неплохо делается (во всяком случае, самописные костыли чаще всего работают хуже).
Про Git не понял. Он не для пользователя нужен, а для разработчика, и должен стоять на его машине, а не на сервере. Или мы говорим про тот Git, который будет делать деплой из репозитория?
Потерю данных могут предотвратить транзакции на уровне базы данных (если они поддерживаются движком и сервером). Про остальное — не понял толком :) Какого рода «навернулся» встречаются в реальной практике? Почему помогает простой перезапуск (обычно наворачивается что-то из-за бага в исходном коде)? Зачем заворачивать сервисы в контейнеры, если можно реализовать их как обычные скрипты на PHP/Perl/Python/Go, возвращающие JSON (и дёргающие по необходимости внутренние сервисы вроде тех же движков распознавания изображений, вычисления хэшей музыкальных файлов и прочего)?
lxsmkv
У контейнера есть доступ к ядру системы, и доступ к виртуальной файловой системе, но настроены только те папки которые приложению нужны. Обертка получается очень легковесная. Работает оно так же как работало бы на хосте.
Контейнер заворачивает сервис со всеми его зависимостями. Например одному приложению нужен PHP 4.х, другому PHP 5.x. чтобы избежать конфликтов, все пихают в контейнеры. В том же питоне есть virtualenv, та же самая причина, питон второй нужно отделить от третьего, а еще нужно три разных версии третьего питона, потому что не все библиотеки совместимы с последними версиями языка. Приложение пишут и сдают заказчику. Начинали писать на ангуляре 1, и закончили на ангуляре 1, заказчику не нужны новейшие версии фреймворка — ему нужно работающее приложение. Завернул его в контейнер и сдал. И оно точно будет работать как работало у разработчиков на машине. Не произойдет такого, что на целевой системе тут надо еще то да се установить, конфиги и системные переменные прописать — все уже в контейнере.
Другой пример. Какая нибудь фирма решила открыть филиал в другой стране. Ставят точно такой же дата-центр, делают репликацию контейнеризированной инфраструкуры, и из головного офиса управляют двумя идентичными дата-центрами.
На контейнерах можно делать A/B тесты — одной части пользователей сервис показывает обновленную версию интерфейса. Или урезанный сервис для стран третьего мира — наследуется контейнер базового приложения и перенастраивается.
Вам просто не виден масштаб. Возможно вы думаете что google работает на сервере а под ним база mysql, обернутая скриптами.
Жесткий диск сломался — перекинул контейнер на другую машину и запустил. Полная миграция дата-центра в течении одного часа — реальность.
Или новичок-программист случайно проапдейтил на node.js сервере зависимости пакетов — и все приложение легло. А завтра утром нужно показывать заказчику. Восстанавливают контейнер с рабочими версиями зависимостй и все.
Если интересно посмотрите это видео: Возможности программного обеспечения Docker (~1 ч.)
Конечно сервис может быть так и устроен, но весь этот зоопарк оборачивают в контейнер, чтобы то, что работало вчера продолжало работать и завтра и послезавтра и через 10 лет. По принципу «never change a running system» — программный комплекс консервируют в контейнерах. На каких версиях подсистем приложение, написали на тех оно пусть и работает всю жизнь. Не надо ничего трогать.
Задача девопса не в том из каких компонент реализовать приложение, а в том как обеспечить работу команды разработчиков и эксплуатацию этого приложения заказчиком при постоянно меняющихся условиях в бизнесе с минимальными затратами.
Вообще-то это все оффтоп. Хотите оффтопить пишите в личку, а то еще минусов нахватаете.
popov654
Какой тогда вообще в этом смысл? Чтобы что-то собрать из готовых решений, не надо вообще уметь писать код. Это как раз и школьник сможет сделать. Не вижу в этом особого творчества, если честно.
Серьёзно, такие ещё есть?) Я понимаю, что пример с потолка, но всё равно странно требование старой версии софта, тем более настолько.
Это можно сделать и без контейнеров, просто правкой конфигов на нодах, обслуживающих часть клиентов или отдельную страну. Но да, наверное, удобно.
Гугл — уникальный случай, сервисов такой сложности и с такой нагрузкой в мире единицы. А вы рассказываете про нечто гораздо более распространённое, как я понимаю.
А для такого есть виртуальные облака — Amazon например такую миграцию умеет по требованию или в случае неполадок :)
Ну для этого ведь надо сделать бэкап контейнера? А в случае его отсутствия мы бы файл с зависимостями забэкапили, меньше места под это нужно. Или там в само ПО управления контейнерами встроена система создания контрольных точек, и они весят мало?
Красивый подход) То есть выходит, если я пишу приложение, оно потащит за собой свою версию PHP, свою версию MySQL и так далее? Не выйдет ли так, что если на сервере работает много контейнеров, то всё это будет много весить и получится избыточное дублирование сущностей (то есть будет продублировано даже то, что и так работало бы нормально без сбоев в обычном режиме с одной общей версией ПО для разных приложений)?
В целом понятно, спасибо)
peresada
Суть программирования в автоматизации, причем автоматизации того, что еще не автоматизировано. И если уже есть адекватное готовое решение, то нужно задать себе вопрос «А могу ли я сделать лучше, за адекватное время», скорее всего ответ будет очевиден. И нет, школьник (в том контексте, в котором Вы написали) не сможет собрать нормальную инфраструктуру, конечно, если мы говорим о серьезных проектах и о бизнесе.
А творчество можно проявлять в логике, да и оркестрировать готовыми решениями и связывать их в общую структуру — это тоже творчество.
popov654
Иногда суть программирования просто в том, чтобы решить интересную задачу. А способов решения как правило всегда несколько, и даже не факт, что способ, который придёт в голову именно Вам, уже был кем-то применён :)
Автоматизация — да, но её столькими разными способами можно сделать.
Я утрировал, конечно же. Естественно, не сможет.
Тоже верно. Но всё-таки…
Вот только час назад читал статью по конфигурации ES для поиска данных в больших массивах. Тоже творчество, конечно. И вообще проектирование структуры любой БД — тоже творчество. Но как-то для меня это скучно. Ну не то совсем.
staticlab
Скрипты должны исполняться определённой версией интерпретатора. Никто не гарантирует, что при обновлении PHP с 7 до 8 в скрипте ничего не сломается. Ну а сервисы для распознавания изображений, обработки звука и т.п. скорее всего требуют какие-либо бинарные зависимости. Всё вместе это тяжело тащить на сервер — что-то наверняка будет конфликтовать, особенно если проект большой. Да и сервисы на разных языках требуют кучу разных окружений и установку своих зависимостей. Вдобавок, контейнер можно развернуть на любой машине, в т.ч. и разработческой, без установки каких-либо зависимостей.
Пример с потолка, но, например, в PHP 5.4 было расширение mysql, а потом его объявили deprecated, а в 7 вообще выпилили. Тут или огораживать существующий код в отдельный заповедник со своим PHP, или новые сервисы тоже писать на старом PHP, или бросать текущие задачи и переписывать старый сервис на новый PHP. Понятно, что дешевле огородить, а потом при наличии свободного времени переписать.
С контейнерами это можно сделать даже на одном сервисе. Опять же, правка конфигов на целом кластере (да и в принципе управление конфигурацией сервисов) — это тоже нетривиальная задача.
Уже с десятком микросервисов нужно как-то управляться.
Вот контейнеры для облаков очень удобны: может хоть сотня разных крутиться в одном облаке и никому не мешать. К тому же можно легко балансировать нагрузку, регулируя количество экземпляров одного сервиса. Даже если один экземпляр упал из-за ошибки, есть ещё несколько живых. Пока восстанавливается ещё один, остальные работают. В случае обновления то же самое — новые экземпляры по одному вытесняют старые. В результате система в целом работает без остановок.
Все версии образов уже хранятся в репозитории. Нужно только скомандовать раскатить нужную. Контрольные точки не делают, потому что контейнеры не хранят долговременные данные. Его просто уничтожают и запускают новый.
Да, это плата за переносимость, отсутствие зависимостей и простоту развёртывания.
popov654
А если это один проект — проблем с производительностью и стабильностью не будет из-за того, что он у нас на два контейнера разнесён?
Конфиг, затрагивающий такие серьёзные параметры, должен быть один на машину, имхо :)
Вы про Git? Нам в вузе говорили, что хранение бинарников в репозиториях не привествуется, потому что это занимает много места, и вообще, теряется весь смысл использования системы контроля версий.
Тогда как откатить данные, которые остались в промежуточном состоянии из-за падения контейнера? Чисто на транзакциях это решать?
Да, ещё глупый вопрос от чайника — если я привык разрабатывать код на винде, есть какое-то удобное приложение под Windows, чтобы рулить содержимым таких контейнеров, или не вариант?
staticlab
Производительность от докера падает незначительно. Другой аспект — производительность монолита против микросервисов. Но если проект большой, то переходить на микросервисы может быть обосновано.
Стабильность скорее только увеличивается за счёт резервирования сервисов. Кроме того, физически отдельные экземпляры могут быть на разных машинах в разных дата-центрах или вообще в облаке.
Нет. Там всё сложнее. Во-первых, как я уже сказал выше, машин может быть несколько, либо одна машина может обслуживать множество целевых групп. В каждом случае для A/B-тестирования нужно делать своё решение. А для микросервисного приложения существуют целые специализированные сервисы конфигурации. Руками никто конфиги не раскладывает — это противоречит подходу devops.
Нет, я про репозитории докера. Там хранятся все версии готовых образов всех сервисов — собранные и протестированные.
Здесь возникает проблема управления распределёнными транзакциями. Это действительно сложная техническая задача.
Для Windows < 10, к сожалению, только Docker в Linux в VirtualBox.
Denister
Прочитал — вдохновился.)
KirEv
я терпеть не могу работать в офисе: это нужно добираться, вставать утром поранше хотя бы в 11 (люблю засиживаться), вовремя уходить с работы (после 19 возле дома в котором жил невозможно было найти парковочное место, бывало мин40 кружлял), потом поесть надо, шум часто не по делу… и т.п…
но мне нравилось работать в офисе: это прямой доступ к идеям, обсуждений, можно подсмотреть кто чем занимается, как решает задачи, и в конце концов — прямой доступ к телу других разработчиков… часто можно просто взять за рукав и утащить на часовой перекур и разного говорить\рассуждать\планировать… это не сравниться с скайпами и т.п. удаленными штуками… если вдвоем — еще так сяк, но когда несколько человек — часто бардак…
Scarfase1989
Эх как приятны такие моменты, когда оба понимают суть проблемы и говорят на одном языке. Аж прям мурашки по коже и глаза блестят.
copist
1. Joy, Inc.: How We Built a Workplace People Love, Richard Sheridan (Работа мечты. Как построить компанию, которую любят, Ричард Шеридан)
Коллектив, синергия, парное программирование, если кратко.
2. Что делать с тем, что я постоянно переписываю почти весь код?
Следуй принципам MVP в своей собственной работе, сдавай частями, рефактори работающее, если кратко.
AnROm
Не случайно существует Метод утенка, который я стараюсь внедрить в командах, где работаю. Просто вместо утенка обсуждайте таски, решение и другие технические вопросы с коллегами, даже если вам кажется, что человек не в теме и у него нет подходящей компетенции и опыта. Просто подсаживайтесь к кому-нибудь или к себе на рабочее место просите подойти. Непосвященный в детали человек может задать вам вопрос, после которого у вас будет озарение. К тому же вы можете прийти к решению уже в процессе объяснения проблемы собеседнику. В многих моих предыдущих командах это работало как для меня, так и для коллег.
У всех нас(извините, если кого-то обидела) есть пробелы знаний в каких-то областях. Но есть же и то, в чем вы настолько круты, что мало кто из команды может сравниться с вами в этом опыте и знании каких-то вопросов. Адекватные люди это понимают и будут вас ценить, даже если вы не идеальны в некоторых других вопросах, никто и не подумает что вы — «слабое звено». Лично мне это помогает в озвученной выше ситуации :)
zloddey
Есть ещё один мега-приём, который можно применять, если обсудить не с кем. Можно подробно и в деталях расписать проблему для самого себя — на бумаге или в текстовом документе. Мозг точно так же начинает находить "слепые зоны" в рассуждениях, которые не были видны раньше.
Я на эту тему писал статью, там метод изложен более подробно.
marshinov
Это называется парное программирование. Придумали очень давно. Я всегда скидываю наброски дизайна, в котором не уверен на ревью команде. Не понимаю, почему нельзя показывать недописанных код.
ganqqwerty
Вы же будете как голый! Все увидят, что вы мыслите так же как и остальные нормальные люди, сначала предлагая алгоритм с квадратической сложностью и потом доводя ее до логарифмической! Как можно такое представить?! (убегает в приступе экзистенциального ангста)
marshinov
Хуже того, у меня вообще сначала кругом LINQ и про сложность алгоритма я вообще не думаю.
unicsoid
А у меня не выходит признать нормальность такого метода на каком-то эмоциональном уровне. Мозгами я понимаю, что все знать невозможно и взгляд со стороны всегда полезен и нужен. Даже всем так говорю. Но сам почти не пользуюсь этим. Долбаный синдром самозванца ;(
Sinner963
Очень вдохновляющий пост, местами будто вставки из «Бойцовского клуба» Чака Паланика прям, например эта фраза прям отослала
Я стараюсь абстрагироваться обычно от мнения других, ведь главное — добиться работающего результата. И, конечно, внутренний перфекционизм очень этому мешает порой
mad_nazgul
Парное программирование — весело!
Особенно когда за одним компьютером.
DespotMagic
Мне кажется это вполне нормальный подход. И не всегда для этого нужен специальный друг. Можно просто с кем то из коллег такое проделать. Если коллеги адекватные, думаю они без проблем согласятся помочь.
Как то раз у нас даже было трипл-программирование :). И оно прошло очень эффективно. Выработали хорошее решение для не самой тривиальной задачки. Остановили друг друга пару раз от ненужных решений и от того же зловредного «перфекционизма». Просто банально со стороны по другому иногда смотришь. И это помогает. Ты думаешь «тут ещё можно улучшить», а тебе так «забей, уже отлично». И тебе легчает)). И ещё понимаешь, что эти же люди могут и ревьюрить. И тебе ещё больше легчает. Ну и в конце появляется то удовлетворение, ради которого ты этой работой и занимаешься.
В общем на мой взгляд в 80% случаях это реально эффективно. Но это дополнительное время людей, нельзя злоупотреблять. Если не идёт, надо останавливаться. И из опыта понял, что это эффективно, когда уровень «партнёров» примерно одинаковый. Иначе это уже больше наставничество.
ganqqwerty
Сначала автору надо преодолеть свое неприятие показывать промежуточные результаты работы.
staticlab
Однако вы же сами писали: " Приверженцы статической и динамической типизаций никогда не поймут друг друга. И TypeScript им не поможет." Значит не всё так категорично?
vassabi
их спасут и поймут приверженцы «могу писать код. и статически и динамически».
WRP
«Таски и эстимейты» меня одного напрягают?
Cerberuser
Что характерно, применимо после некоторой доработки напильником далеко не только к IT. Метод "засунь гордость подальше и пригласи бета-ридера", к примеру, может сдвинуть с мёртвой точки молодого писателя (проверено на себе).
SirEdvin
Думаю, вы неправильно описываете задачи ...
jknight
Нет, просто 80% работы занимают 10-20% времени, согласно известному тезису. Если же всерьез упороться в оставшиеся 20%, и целиться в 99.9%, то соотношение времени описания и реализации задачи будет как раз такое…
NiPh
Как раз от этого и спасает описание задачи. Иначе можно случайно нацелиться и в 105%, и пилить пока эта задача не перестанет быть актуальной.
jknight
Правильного перфекциониста и описание задачи не спасает, т.к. целиться будет в 110%.
SirEdvin
На мой взгляд, правильное описание задачи это как раз и 80% работы. Разумеется, если вы пишете какой-то привязанный к бизнесу процесс, а не внутренний сервис, который будет работать сам по себе. Хотя и так это довольно важная часть работы.
ganqqwerty
Могу вспомнить кучу ситуаций когда после нормального описания задачи появлялось идеальное ее решение — не делать эту задачу. Всегда к этому стремлюсь.
ganqqwerty
Я вообще стараюсь свести количество не-pair-programming-работы к минимуму. Сидишь сам, скучаешь, страдаешь ненужной фигней, не замечаешь ошибки… Вдвоем веселее, да и код в итоге лучше.
ukrdev
Я хотел бы высказать свое имхо по поводу первой части статьи.
Мне кажется что на уровне middle/senior плохого кода не бывает, бывает только плохое или неудачное но вполне рабочее решение.
За 9 лет разработки, я понял одну простую истину — никогда за одну итерацию не получится сделать хорошое решение, нужно несколько итераций что бы добиться хорошего решения, а вот кол-во итераций уже зависит от опыта, поэтому чем больше опыта тем меньше итераций делает разработчик. Чем быстрее ты пройдешь нужное кол-во итераций тем быстрее ты получишь тот результат на который расчитываешь.
vassabi
на уровне junior тоже не бывает плохого кода, просто он не всегда компилируется :)
я вам даже больше скажу — как только код удовлетворяет бизнес-требованиям, значит он готов к продакшену (и то, даже это слишком строгий критерий, т.к. это бывает в 30% случаев пуска код в продакшен, в случае внутреннего заказчика и в 90% — НЕ 100! когда был подписан контракт, так что ...)
nmrulin
В целом верно. Но по факту людей часто «бьют»за то, что в первой итерации у них неидеальный код программа падает и т.д. Либо вторая крайность, если не сильно падает, говорят «и так сойдёт» и не дают сделать последующие итерации. Прибавим к тому, что многих в школе за то же «били». Так и рождается перфекционизм.
Elizir
Я может чего-то не понимаю, но ранее ни разу в жизни не сидеть с товарщием/коллегой за одним экраном, выискивая баг? Обсуждая архитектуру, ища возможное и оптимальное решение? И это даже не парное программирование, я всегда считал, что именно это и есть командная работа, а не участие в периодических митингах.
try1975
А я вот за 28 лет карьеры не испытывал подобного, а хотелось бы…
igor-glyf
Автор открыл дял себя XP, а в частности PP.
Мы когда-то так в универе работы писали, командный дух.
411
Если вы сидите над задачей и за 2 недели ничего не написали — вы решаете не задачу, а какую-то другую проблему. Возможно из разряда «а что, если на вход передать шестиногую собаку, у которой хвост спереди». Решение задачи — не только написание кода
khayrov
Хорошо помогает code review не для галочки и политика минимальных самодостаточных изменений (одно проистекат из другого, потому что нормально отревьюить весь код для сколько-нибудь нетривиальной фичи зараз невозможно). Когда исчезает вариант «посижу ещё ночь и выкачу идеальный pull request на несколько тысяч строк», волей-неволей приходится выдавать промежуточные результаты.
Есть следующий уровень той же проблемы: застрять в попытке написать идеальный design document. Тут уже формальных решений меньше, только культура команды.
AirLight
Исповедь одичалого интроверта.
barsuksergey
Надо же, вспомнил ещё раз статью, как добрался до места, где аргивяне в разведку отправить хотят одинокого мужа:
Нестор, меня побуждает мой дух и отважное сердцеВ лагерь проникнуть враждебных мужей, находящийся близко.
Если б, однако, со мной и другой кто итти согласился,
Было бы мне веселее и много смелее на сердце.
Ежели двое идут, то придумать старается каждый,
Что для успеха полезней. А что бы один ни придумал,
Мысль его будет короче, и будет решенье слабее.
Гомер, Илиада, то ли VIII век до н.э., то ли X век до н.э.
rustacean137
Такая проблема не возникает если всё дробить на мелкие части, и часто делать коммит с маленьким но самодостаточным(работающим) кодом.
И дробить стоит с задачи.