Pull to refresh

Comments 99

UFO just landed and posted this here
Что за компания, что за проект?)
Странно, я явно не перфекционист, за 2 месеца сделал подсистему, загнал 2ТБ в облак и запустил в прод. Не все было красиво, но подсистема делала свое дело.
UFO just landed and posted this here
Вытер слезы(1).

Правда два месяца — совсем немного. Я просидел 6 лет одновременно изучая UDK/UE4, программирование и игру-мечты которую хотел сделать в режиме ММО, я не хвастаюсь, тут нечем хвастаться, очень много времени потратил топчась на месте, ну хоть программировать научился, а игры делать — нет.
Как-то одновременно грустно и страшно, грустно что ошибся и не осилил, страшно признать свою ошибку, в теории там все просто, а вот на практике без опыта, анрил.
К сожалению мысли слишком идеализированны и абстрактны, мне показалось что скопировать готовую сингловую игру и потом уже как нибудь ее переделывать под свои хотелки несложно, к черту продумывание и документирование, на ходу решу, ага.
fuf
image

Смирился, решил зайти с другой стороны на которую изначально забил — геймдизайн.

Дубль 2, часть 1.
я знаком с рядом начинающих и не начинающих инди-гейм-разработчиков

многие из них вязнут в большом проекте, это частая беда
даже опытные люди, выпустившие не одну игру, бывает, увязают в новой игре и не могут выпустить ее год, хотя по виду она — двухмерная простая фигня, которую так и хочется оценить максимум в 2 недели. В одну, если графика уже есть.
Да, все проблемы в наших головах, эти провалы новичков уже классика жанра.
Забавно то, что попутно изучению я читал гору статей каждый день, опыт других разработчиков, в том числе негативный, но я был уверен что как-нибудь соображу, у меня ведь все по другому, ага.

Особенно страшно это проявляется в работе над собственным проектом (ещё хуже, если в одиночку). Ты вроде бы пишешь, пишешь, а всё не идеально, а нужно, чтобы было лучше всех — не зря же старался! И ты никогда не закончишь, если не поймёшь, что идеального ничего не бывает, есть достаточно хорошее, чтобы быть идеальным.


Спасает одно — понимание, что не ты один такой. "Вон, люди даже в ядре Linux ошибки и баги допускают, а ты? Ты здесь написал лучше, чем они!" — говоришь себе, и успакаиваешься. Просто держишь планку, не опускаясь в совсем грязь, но и не пытаясь переплюнуть гору. Не быть же всегда идеальным.

Важна архитектурная однородность. Все что нарушает ритмичную закономерность, не подчиняется общему принципу — мешает нам. Мы противимся, потому что наш мозг говорит нам — «это слишком сложно». Мы подсознательно ищем простоты и симметрии. «Всё должно быть изложено так просто, как только возможно, но не проще». Если попытаться упростить автомобиль — получится самокат.
Собственный проект, в одиночку. Четыре раза переделана не только схема БД, но и код. Все варианты рабочие. Даже красивые картинки в Визио рисовал. Но! Чего-то хочется, а чего — не знаю. Что знаю, того не хочется. Идёт третья неделя войны с собственным перфекционизмом и попытками выпендриться.
Проблема работы в одиночку, рефлексия загоняет в тупик. Хочется услышать чье-то мнение — да, все правильно, да продолжай делать это или это. Без другого мнения, рефлексия загоняет вглубь проблемы.

Нужно поделился проектом с кем то. Рассказать пообсуждать. Тогда будет легче.

Чуваки заново изобрели парное программирование. Поздравляю!

В тегах вроде так и написано :)

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

По поводу парного программирования, свежих взглядов, переработок, сопернической атмосферы в коллективе — все уже было описано в книге Роберта Мартина, «Идеальный Программист». И истории, кстати, очень похожие в книге представлены
Не обязательно проблемы в команде.

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

Я вообще не программист. Но «подумать об кого-то» — это и правда обычно лучше всего помогает сдвинуть с места глыбу, об которую ты уже почти надорвался в одиночку.

Про парное программирование всё понятно (и про необходимость взаимодоверия, и про мгновенную конструктивную обратную связь, и про эффективность в удачной паре).

Но меня вот смутили моменты "Код надо было писать на 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, который так или иначе на базовом уровне знает не меньше половины программистов «традиционных» языков.

Так что для опытного разработчика не нужно удивляться, что другой опытный разработчик может прочитать код на другом языке и оценить решение.
Как перешедший с 1с на котлин под андроид подтверждаю что языки просто интуитивно понимаются новые если есть опыт какой то. Но вот с фреймворками, либами, некоторыми подходами уже могут быть проблемы, правда решаются они чаще всего одним хорошо заданным вопросом в гугл или коллеге за 5 минут, пусть и не всегда.
C 1C легче переходить на VB NET. Сугубо по семантике. Как мне кажется, все более менее успешные языки имеют корни в С.

С, С++, Java, C#, JS, PHP
Ну хз. Из любопытства уже имея опыт с 1с в разной степени трогал плюсы, java, python, сейчас котлин вот, правда на нем уже за деньги пишу в отличие от остальных экспериментов. Разве что с плюсами проблемы возникли (хотя все равно решил задачу, пилил компоненту для 1с), и то из за ручного управления памятью и бедной стандартной библиотеки а не из за языка как такового. Один знакомый 1сник недавно бек для своего приложения на флаттере запилил на go — тоже отзывался как об очень простом языке. Хотя о go по моему все так отзываются. А, ну и js еще, несколько раз нужен был, нарисовать нестандартные интерфейсы для 1с, опять же с самим языком никаких проблем. Просто сел и начал писать хотя до того js вообще не видел, просто ориентировался на сообщения линтера когда начинал писать что то не как в js. Разве что с замыканиями там у меня какие то непонятки были, но не уверен.
UFO just landed and posted this here

Я в таких случаях сначала пишу так, чтобы работало, очень грязно и очень тупо :)
Если и это не помогает, то нужно переключиться на задачу с другой стороны — например, уйти от попытки выстраивать нижний слой абстракции и перейти сразу к верхнему, начать писать систему с другой стороны.
Как вариант — просто создать новый репозиторий и потихоньку подглядывать в старый (из говнокод-проектов примерно 10% кода оказались полезными, +понимание ограничений, с которыми можно столкнуться)

Не понимаю за что человека заминусовали.

За говнокод действительно надо бить по рукам, только вот такой метод — реально работает. Когда ты пишешь что-то, что уже работает, но криво, в процессе в 99% случаев понимаешь как сделать это хотя бы немного лучше.
Мне кажется здесь очень хорошо подходят слова Кента Бека «Make it work, make it right, make it fast».
Многие вещи, о которых сразу и не подумаешь выползают уже на реализации. И наоборот, то чего сильнее всего опасался вообще не будет играть большой роли.
Сидеть и теоретизировать до бесконечности придумывая идеальное решение тоже не выход. Зачастую реализация может подсказывать пути хороших решений.
Так что нужен баланс.
После «Make it work» включают другое правило «работает — не трогай.» Или «там такой говнокод, лучше не лезть»
Никто же не говорит писать говнокод.
Просто сидеть и придумывать идеальную архитектуру не написав ни единой строчки кода тоже не вариант.
Нужны итерации, пускай даже для себя.
Так должна вырисовываться хорошая архитектура.
Между этими правилами есть барьер: commit. :)
Поэтому после того как сделал make it work, надо не подавать виду и тихонько рефакторить. Спросят про статус — скажи «сделал 40%».
UFO just landed and posted this here
Опасная тактика, если ничто не мешает изначально сделать не говнокод, а код пусть и не особо продуманный, но без грязи. Потому что есть большой шанс, что вернуться к исправлению говнокода не будет ни желания, ни возможностей. И не забывайте, что громкими цитатами типа «Make it work, make it right, make it fast» чаще всего пользуются выдающиеся личности, для которых одно только «make it work» выглядит иначе, и если эти выдающиеся личности увидят результат «make it work» многих программистов, скорее всего они отреагируют фразой из серии «i didn't mean so bad»

На этапе прототипирования говнокод — единственный выход, особенно если решаешь задачу, с которой раньше не встречался. Если у вас заказчик здорового человека — он прекрасно понимает, что первые несколько написанных версий кода — говнокод в любом случае. Обычно в новой итерации я использую около 20-30% ранее написанного кода (покрытого тестами, естественно), что позволяет, с одной стороны, свежим взглядом посмотреть на архитектуру, а с другой — не переписывать код, который уже работает

Мне как-то коллега с девопса рассказал, что дали интегрировать кластер с кастомными конфигурационными скриптами на Groovy, написанными вундеркиндом-одиночкой и документацией архитектуры «на салфетке». «Я, — говорит, — докер, Jenkins и его Groovy API, терраформ, ансибле, и пр. понимаю. Но что с этим всем делает этот скрипт — нет!».
А я в Groovy… «знаю что функции обьявляются словом def». Сели вместе разбирать. Он пытается в vim обьять необьятное, я говорю: «Не мучайся, закинь в IntellJ там навигация, сразу тебе покажет где какая функция вызвается.… Нет, никому не скажу.» Прощелкали все, он мне по ходу рассказывает как там контейнеры разворачиваются, я ему рассказываю, как тут замыкание в функцию передается. Слово за слово и скрипт кончился. Потратили не больше часа, а до этого у него аж волосы дыбом стояли от ступора.
А можно поподробнее — что такое разворачивание кластера, Jenkins, Groovy? Что делал тот скрипт? Можно хотя бы в виде ссылок. Желательно, для совсем чайника :)
Я тестировщик, а не девопс, просто тусуюсь с ними в перерывах, потому что они крутые штуки делают. Так что постараюсь пояснить как могу.
Под кластером понимается тут конгломерат из контейнеров в которых живут сервисы и службы. Jenkins это серверное ПО для автоматизации в частности для сборки. Groovy — язык программирования широкого назначения.
По общему смыслу, скрипт настраивал все службы на топологию серверной части.

Docker позволяет запустить приложение в ограниченом окружении (т.н. контейнере) и отделить его от других приложений. Все приложения заворачиваются в контейнеры.
Чтобы построить полезный сервис для пользователя, там давно уже не только apache, php, mysql, там куча всяких серверных программ, нацеленных как на сам процесс разработки, jira, git, sonar и т.д. так и на обеспечение сервиса и его надежной работы: быстрый поиск, искуственный интеллект, репликация данных и т.д. Если архитектура на микросервисах, там вообще каждый микросервис в своем контейнере может жить. Этих контейнеров сотни тысяч могут быть. Ты ими в ручную уже не сможешь управлять. У тебя есть сервис для этого, навернулся контейнер — ты не выясняешь что с ним — выкинул, вставил новый, репликация данных, и оно снова работает. В течении минут. Примерно так работает современное айти. За подробностями о каждой отдельной технологии — в гугл, потому что тема невероятно обширная.
Docker позволяет запустить приложение в ограниченом окружении (т.н. контейнере) и отделить его от других приложений. Все приложения заворачиваются в контейнеры.
А зачем это делается? И как приложению в такой песочнице работать?)

быстрый поиск, искуственный интеллект, репликация данных и т.д.
Искусственный интелект — это что-то связанное с нейросетями, наверное? Быстрый поиск — он вроде бы средствами СУБД неплохо делается (во всяком случае, самописные костыли чаще всего работают хуже).

Про Git не понял. Он не для пользователя нужен, а для разработчика, и должен стоять на его машине, а не на сервере. Или мы говорим про тот Git, который будет делать деплой из репозитория?

Ты ими в ручную уже не сможешь управлять. У тебя есть сервис для этого, навернулся контейнер — ты не выясняешь что с ним — выкинул, вставил новый, репликация данных, и оно снова работает.
Потерю данных могут предотвратить транзакции на уровне базы данных (если они поддерживаются движком и сервером). Про остальное — не понял толком :) Какого рода «навернулся» встречаются в реальной практике? Почему помогает простой перезапуск (обычно наворачивается что-то из-за бага в исходном коде)? Зачем заворачивать сервисы в контейнеры, если можно реализовать их как обычные скрипты на PHP/Perl/Python/Go, возвращающие JSON (и дёргающие по необходимости внутренние сервисы вроде тех же движков распознавания изображений, вычисления хэшей музыкальных файлов и прочего)?
Быстрый поиск — он вроде бы средствами СУБД неплохо делается (во всяком случае, самописные костыли чаще всего работают хуже).
elasticsearch и пр. конечно же я имел ввиду. Может фрилансеры-школьники и пишут костыли, но все нормальные люди собирают приложение из готовых решений.

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

Контейнер заворачивает сервис со всеми его зависимостями. Например одному приложению нужен PHP 4.х, другому PHP 5.x. чтобы избежать конфликтов, все пихают в контейнеры. В том же питоне есть virtualenv, та же самая причина, питон второй нужно отделить от третьего, а еще нужно три разных версии третьего питона, потому что не все библиотеки совместимы с последними версиями языка. Приложение пишут и сдают заказчику. Начинали писать на ангуляре 1, и закончили на ангуляре 1, заказчику не нужны новейшие версии фреймворка — ему нужно работающее приложение. Завернул его в контейнер и сдал. И оно точно будет работать как работало у разработчиков на машине. Не произойдет такого, что на целевой системе тут надо еще то да се установить, конфиги и системные переменные прописать — все уже в контейнере.

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

На контейнерах можно делать A/B тесты — одной части пользователей сервис показывает обновленную версию интерфейса. Или урезанный сервис для стран третьего мира — наследуется контейнер базового приложения и перенастраивается.

Вам просто не виден масштаб. Возможно вы думаете что google работает на сервере а под ним база mysql, обернутая скриптами.

Какого рода «навернулся» встречаются в реальной практике?
Жесткий диск сломался — перекинул контейнер на другую машину и запустил. Полная миграция дата-центра в течении одного часа — реальность.
Или новичок-программист случайно проапдейтил на node.js сервере зависимости пакетов — и все приложение легло. А завтра утром нужно показывать заказчику. Восстанавливают контейнер с рабочими версиями зависимостй и все.
Если интересно посмотрите это видео: Возможности программного обеспечения Docker (~1 ч.)

Зачем заворачивать сервисы в контейнеры, если можно реализовать их как обычные скрипты на PHP/Perl/Python/Go, возвращающие JSON (и дёргающие по необходимости внутренние сервисы вроде тех же движков распознавания изображений, вычисления хэшей музыкальных файлов и прочего)?
Конечно сервис может быть так и устроен, но весь этот зоопарк оборачивают в контейнер, чтобы то, что работало вчера продолжало работать и завтра и послезавтра и через 10 лет. По принципу «never change a running system» — программный комплекс консервируют в контейнерах. На каких версиях подсистем приложение, написали на тех оно пусть и работает всю жизнь. Не надо ничего трогать.

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

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

Какой тогда вообще в этом смысл? Чтобы что-то собрать из готовых решений, не надо вообще уметь писать код. Это как раз и школьник сможет сделать. Не вижу в этом особого творчества, если честно.

Например одному приложению нужен PHP 4.х

Серьёзно, такие ещё есть?) Я понимаю, что пример с потолка, но всё равно странно требование старой версии софта, тем более настолько.

На контейнерах можно делать A/B тесты — одной части пользователей сервис показывает обновленную версию интерфейса. Или урезанный сервис для стран третьего мира — наследуется контейнер базового приложения и перенастраивается.

Это можно сделать и без контейнеров, просто правкой конфигов на нодах, обслуживающих часть клиентов или отдельную страну. Но да, наверное, удобно.

Вам просто не виден масштаб. Возможно вы думаете что google работает на сервере а под ним база mysql, обернутая скриптами.

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

Жесткий диск сломался — перекинул контейнер на другую машину и запустил

А для такого есть виртуальные облака — Amazon например такую миграцию умеет по требованию или в случае неполадок :)

Восстанавливают контейнер с рабочими версиями зависимостй и все.

Ну для этого ведь надо сделать бэкап контейнера? А в случае его отсутствия мы бы файл с зависимостями забэкапили, меньше места под это нужно. Или там в само ПО управления контейнерами встроена система создания контрольных точек, и они весят мало?

Конечно сервис может быть так и устроен, но весь этот зоопарк оборачивают в контейнер, чтобы то, что работало вчера продолжало работать и завтра и послезавтра и через 10 лет. По принципу «never change a running system» — программный комплекс консервируют в контейнерах. На каких версиях подсистем приложение, написали на тех оно пусть и работает всю жизнь. Не надо ничего трогать.

Красивый подход) То есть выходит, если я пишу приложение, оно потащит за собой свою версию PHP, свою версию MySQL и так далее? Не выйдет ли так, что если на сервере работает много контейнеров, то всё это будет много весить и получится избыточное дублирование сущностей (то есть будет продублировано даже то, что и так работало бы нормально без сбоев в обычном режиме с одной общей версией ПО для разных приложений)?

В целом понятно, спасибо)
Какой тогда вообще в этом смысл? Чтобы что-то собрать из готовых решений, не надо вообще уметь писать код. Это как раз и школьник сможет сделать. Не вижу в этом особого творчества, если честно.


Суть программирования в автоматизации, причем автоматизации того, что еще не автоматизировано. И если уже есть адекватное готовое решение, то нужно задать себе вопрос «А могу ли я сделать лучше, за адекватное время», скорее всего ответ будет очевиден. И нет, школьник (в том контексте, в котором Вы написали) не сможет собрать нормальную инфраструктуру, конечно, если мы говорим о серьезных проектах и о бизнесе.

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

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

Автоматизация — да, но её столькими разными способами можно сделать.

И нет, школьник (в том контексте, в котором Вы написали) не сможет собрать нормальную инфраструктуру, конечно, если мы говорим о серьезных проектах и о бизнесе.

Я утрировал, конечно же. Естественно, не сможет.

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

Тоже верно. Но всё-таки…

Вот только час назад читал статью по конфигурации ES для поиска данных в больших массивах. Тоже творчество, конечно. И вообще проектирование структуры любой БД — тоже творчество. Но как-то для меня это скучно. Ну не то совсем.
UFO just landed and posted this here
Понятно, что дешевле огородить, а потом при наличии свободного времени переписать.

А если это один проект — проблем с производительностью и стабильностью не будет из-за того, что он у нас на два контейнера разнесён?

Опять же, правка конфигов на целом кластере (да и в принципе управление конфигурацией сервисов) — это тоже нетривиальная задача.

Конфиг, затрагивающий такие серьёзные параметры, должен быть один на машину, имхо :)

Все версии образов уже хранятся в репозитории.

Вы про Git? Нам в вузе говорили, что хранение бинарников в репозиториях не привествуется, потому что это занимает много места, и вообще, теряется весь смысл использования системы контроля версий.

Контрольные точки не делают, потому что контейнеры не хранят долговременные данные.

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

Да, ещё глупый вопрос от чайника — если я привык разрабатывать код на винде, есть какое-то удобное приложение под Windows, чтобы рулить содержимым таких контейнеров, или не вариант?
UFO just landed and posted this here
физически отдельные экземпляры могут быть на разных машинах в разных дата-центрах или вообще в облаке

А как же время отклика между разными машинами при работе в связке? Или там каждая единица содержит всё, что нужно для обслуживания клиента?

Руками никто конфиги не раскладывает — это противоречит подходу devops.

А почему? Гораздо проще раскидать инстансы по физическим машинам так, чтобы одна машина обслуживала только одну целевую группу, и конфиг был один. Можно немного проиграть в количестве необходимых машин, но в целом это может окупиться.

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

И если просто использование контейнеров её не решает (а падать они могут часто)… То прелесть всего механизма как-то слегка теряется :(

Для Windows < 10, к сожалению, только Docker в Linux в VirtualBox

Я имею в виду не боевой сервер для продакшена. А просто, грубо говоря, скачать какой-то образ, потестить его, что-то поменять. Или запаковать собственную разработку в контейнер. Значит, мне понадобится виртуалка с любой версией Linux?
UFO just landed and posted this here
Потому что конфигурация тоже хранится в виде исходного кода.

Это вообще как?
И чем плохи стандартные INI или JSON конфиги? Код легко может их парсить, они удобно читаются человеком.

Да, можно поставить на любой. Docker Toolbox содержит урезанный Линукс исключительно для запуска Докера, но с ним не очень удобно работать и могут быть проблемы.

Как оно вообще выглядит? Как VirtualBox/VMware/etc.? То есть выбираем образ, стартуем, и… и что дальше? У нас стартуют сервисы, которые содержатся в контейнере — при этом основная ОС «не засоряется» ничем, и как только контейнер выключается, всё на хосте выглядит так же, как было?
UFO just landed and posted this here
О, даже так (VirtualBox плюс надстройка какая-то сверху)? Окей. Но как же скорость запуска? Виртуалки требуют некоторое время для старта (и ресурсы на каждую машину, чтобы она «хорошо себя чувствовала»). Соответственно, если юзать контейнеры, сервер понадобится более мощный.

А ещё интересно, как решают вопрос с СУБД. Её ведь нельзя обернуть в контейнер (иначе при перезапуске мы потеряем все изменения в данных БД)? Или там данные просто лежат в каталоге, который вне контейнера хранится)
А ещё интересно, как решают вопрос с СУБД. Её ведь нельзя обернуть в контейнер (иначе при перезапуске мы потеряем все изменения в данных БД)? Или там данные просто лежат в каталоге, который вне контейнера хранится)


Докеризация позволяет «монтировать» внутренние папки контейнера к внешним папкам хоста. Называется `volume`
UFO just landed and posted this here
UFO just landed and posted this here
Например одному приложению нужен PHP 4.х

Серьёзно, такие ещё есть?) Я понимаю, что пример с потолка, но всё равно странно требование старой версии софта, тем более настолько.

4.х не знаю, а 5.2.17 есть ((((

я терпеть не могу работать в офисе: это нужно добираться, вставать утром поранше хотя бы в 11 (люблю засиживаться), вовремя уходить с работы (после 19 возле дома в котором жил невозможно было найти парковочное место, бывало мин40 кружлял), потом поесть надо, шум часто не по делу… и т.п…

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

Эх как приятны такие моменты, когда оба понимают суть проблемы и говорят на одном языке. Аж прям мурашки по коже и глаза блестят.
1. Joy, Inc.: How We Built a Workplace People Love, Richard Sheridan (Работа мечты. Как построить компанию, которую любят, Ричард Шеридан)
Коллектив, синергия, парное программирование, если кратко.

2. Что делать с тем, что я постоянно переписываю почти весь код?
Следуй принципам MVP в своей собственной работе, сдавай частями, рефактори работающее, если кратко.
Основным критерием оценки при расстановке приоритетов на очередной цикл реализации может выступить удовлетворённость пользователя.
Он начал задавать вопросы — почему тут так, это что такое, как эти вещи связаны. Работа закипела. Мы много спорили в процессе, но это как интерактивное код ревью, причем такое, которое делается на совесть

Не случайно существует Метод утенка, который я стараюсь внедрить в командах, где работаю. Просто вместо утенка обсуждайте таски, решение и другие технические вопросы с коллегами, даже если вам кажется, что человек не в теме и у него нет подходящей компетенции и опыта. Просто подсаживайтесь к кому-нибудь или к себе на рабочее место просите подойти. Непосвященный в детали человек может задать вам вопрос, после которого у вас будет озарение. К тому же вы можете прийти к решению уже в процессе объяснения проблемы собеседнику. В многих моих предыдущих командах это работало как для меня, так и для коллег.

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

У всех нас(извините, если кого-то обидела) есть пробелы знаний в каких-то областях. Но есть же и то, в чем вы настолько круты, что мало кто из команды может сравниться с вами в этом опыте и знании каких-то вопросов. Адекватные люди это понимают и будут вас ценить, даже если вы не идеальны в некоторых других вопросах, никто и не подумает что вы — «слабое звено». Лично мне это помогает в озвученной выше ситуации :)
Не случайно существует Метод утенка, который я стараюсь внедрить в командах, где работаю. Просто вместо утенка обсуждайте таски, решение и другие технические вопросы с коллегами, даже если вам кажется, что человек не в теме и у него нет подходящей компетенции и опыта. Просто подсаживайтесь к кому-нибудь или к себе на рабочее место просите подойти.

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


Я на эту тему писал статью, там метод изложен более подробно.

Это называется парное программирование. Придумали очень давно. Я всегда скидываю наброски дизайна, в котором не уверен на ревью команде. Не понимаю, почему нельзя показывать недописанных код.

Вы же будете как голый! Все увидят, что вы мыслите так же как и остальные нормальные люди, сначала предлагая алгоритм с квадратической сложностью и потом доводя ее до логарифмической! Как можно такое представить?! (убегает в приступе экзистенциального ангста)
Хуже того, у меня вообще сначала кругом LINQ и про сложность алгоритма я вообще не думаю.

А у меня не выходит признать нормальность такого метода на каком-то эмоциональном уровне. Мозгами я понимаю, что все знать невозможно и взгляд со стороны всегда полезен и нужен. Даже всем так говорю. Но сам почти не пользуюсь этим. Долбаный синдром самозванца ;(

Очень вдохновляющий пост, местами будто вставки из «Бойцовского клуба» Чака Паланика прям, например эта фраза прям отослала
Мы два самозванца, которые раздувают свою самооценку до астрономических масштабов, чтобы спастись от своей никчёмности.

Я стараюсь абстрагироваться обычно от мнения других, ведь главное — добиться работающего результата. И, конечно, внутренний перфекционизм очень этому мешает порой
Парное программирование — весело!
Особенно когда за одним компьютером.
Мне кажется это вполне нормальный подход. И не всегда для этого нужен специальный друг. Можно просто с кем то из коллег такое проделать. Если коллеги адекватные, думаю они без проблем согласятся помочь.
Как то раз у нас даже было трипл-программирование :). И оно прошло очень эффективно. Выработали хорошее решение для не самой тривиальной задачки. Остановили друг друга пару раз от ненужных решений и от того же зловредного «перфекционизма». Просто банально со стороны по другому иногда смотришь. И это помогает. Ты думаешь «тут ещё можно улучшить», а тебе так «забей, уже отлично». И тебе легчает)). И ещё понимаешь, что эти же люди могут и ревьюрить. И тебе ещё больше легчает. Ну и в конце появляется то удовлетворение, ради которого ты этой работой и занимаешься.

В общем на мой взгляд в 80% случаях это реально эффективно. Но это дополнительное время людей, нельзя злоупотреблять. Если не идёт, надо останавливаться. И из опыта понял, что это эффективно, когда уровень «партнёров» примерно одинаковый. Иначе это уже больше наставничество.
Сначала автору надо преодолеть свое неприятие показывать промежуточные результаты работы.
UFO just landed and posted this here
их спасут и поймут приверженцы «могу писать код. и статически и динамически».
«Таски и эстимейты» меня одного напрягают?

Что характерно, применимо после некоторой доработки напильником далеко не только к IT. Метод "засунь гордость подальше и пригласи бета-ридера", к примеру, может сдвинуть с мёртвой точки молодого писателя (проверено на себе).

а описание задачи — это 1% от дела

Думаю, вы неправильно описываете задачи ...

Нет, просто 80% работы занимают 10-20% времени, согласно известному тезису. Если же всерьез упороться в оставшиеся 20%, и целиться в 99.9%, то соотношение времени описания и реализации задачи будет как раз такое…
Как раз от этого и спасает описание задачи. Иначе можно случайно нацелиться и в 105%, и пилить пока эта задача не перестанет быть актуальной.
Правильного перфекциониста и описание задачи не спасает, т.к. целиться будет в 110%.
На мой взгляд, правильное описание задачи это как раз и 80% работы. Разумеется, если вы пишете какой-то привязанный к бизнесу процесс, а не внутренний сервис, который будет работать сам по себе. Хотя и так это довольно важная часть работы.
Могу вспомнить кучу ситуаций когда после нормального описания задачи появлялось идеальное ее решение — не делать эту задачу. Всегда к этому стремлюсь.
Я вообще стараюсь свести количество не-pair-programming-работы к минимуму. Сидишь сам, скучаешь, страдаешь ненужной фигней, не замечаешь ошибки… Вдвоем веселее, да и код в итоге лучше.

Я хотел бы высказать свое имхо по поводу первой части статьи.


Мне кажется что на уровне middle/senior плохого кода не бывает, бывает только плохое или неудачное но вполне рабочее решение.
За 9 лет разработки, я понял одну простую истину — никогда за одну итерацию не получится сделать хорошое решение, нужно несколько итераций что бы добиться хорошего решения, а вот кол-во итераций уже зависит от опыта, поэтому чем больше опыта тем меньше итераций делает разработчик. Чем быстрее ты пройдешь нужное кол-во итераций тем быстрее ты получишь тот результат на который расчитываешь.

на уровне junior тоже не бывает плохого кода, просто он не всегда компилируется :)
я вам даже больше скажу — как только код удовлетворяет бизнес-требованиям, значит он готов к продакшену (и то, даже это слишком строгий критерий, т.к. это бывает в 30% случаев пуска код в продакшен, в случае внутреннего заказчика и в 90% — НЕ 100! когда был подписан контракт, так что ...)
В целом верно. Но по факту людей часто «бьют»за то, что в первой итерации у них неидеальный код программа падает и т.д. Либо вторая крайность, если не сильно падает, говорят «и так сойдёт» и не дают сделать последующие итерации. Прибавим к тому, что многих в школе за то же «били». Так и рождается перфекционизм.
Я может чего-то не понимаю, но ранее ни разу в жизни не сидеть с товарщием/коллегой за одним экраном, выискивая баг? Обсуждая архитектуру, ища возможное и оптимальное решение? И это даже не парное программирование, я всегда считал, что именно это и есть командная работа, а не участие в периодических митингах.
А я вот за 28 лет карьеры не испытывал подобного, а хотелось бы…
Автор открыл дял себя XP, а в частности PP.
Мы когда-то так в универе работы писали, командный дух.
Если вы сидите над задачей и за 2 недели ничего не написали — вы решаете не задачу, а какую-то другую проблему. Возможно из разряда «а что, если на вход передать шестиногую собаку, у которой хвост спереди». Решение задачи — не только написание кода

Хорошо помогает code review не для галочки и политика минимальных самодостаточных изменений (одно проистекат из другого, потому что нормально отревьюить весь код для сколько-нибудь нетривиальной фичи зараз невозможно). Когда исчезает вариант «посижу ещё ночь и выкачу идеальный pull request на несколько тысяч строк», волей-неволей приходится выдавать промежуточные результаты.


Есть следующий уровень той же проблемы: застрять в попытке написать идеальный design document. Тут уже формальных решений меньше, только культура команды.

UFO just landed and posted this here
Оправдывает название «классика».
Показать неготовый набросок — катастрофа. Как будто тебя увидят не просто голым, а без кожи, без черепа. Увидят все твои обычные несовершенные мысли, которые еще не оформились в умные решения.

Такая проблема не возникает если всё дробить на мелкие части, и часто делать коммит с маленьким но самодостаточным(работающим) кодом.


И дробить стоит с задачи.

Sign up to leave a comment.

Articles