Хабрахабр / Комментарии к посту «Общие соображения по архитектуре ПО или Пособие для Главного Плотника (часть 1: что такое хорошо)» в блоге «Разработка»

20.07.2010 13:16:05 Semenych

Semenych — Tue, 20 Jul 2010 13:16:05 GMT

Ну записать то можно, вопрос в том каких и сколько телодвижений надо проделать :-)

20.07.2010 13:11:40 intr13

intr13 — Tue, 20 Jul 2010 13:11:40 GMT

Эх, кто бы спорил. Я тоже работаю по похожим принципам и почти во всем с вами согласен.

Только я к сожалению не вижу мир таким радужным, и очень часто замечаю произвол разработчиков. Причем в большинстве своем их произвол оправдан и разумен.

Я думаю не стоит дальше продолжать спор, тем более вы не признаетесь, что и вас бывали случаи произвола ;)

p/s
Кстати вы довольно интересный человек (по внешним признакам :)), может быть вы запишите подкаст с товарищем golodnyj и расскажите пару интересных баек в эфире? Я имею ввиду подкаст taop.rpod.ru/

20.07.2010 12:45:58 Semenych

Semenych — Tue, 20 Jul 2010 12:45:58 GMT

Вы путаете два понятия.
1. Я работаю потому что мне такая работа интересна.
2. Но раз уж работаю то я делаю работу нормально, а не так как мне в голову придет.

Посмотрим на проблему со стороны заказчика — он нанимает людей сделать проект. Ему вообще все равно как будет сделано внутри. Ему важно
1. качество
2. срок
3. бюджет
4. возможность владения тем, что ему сделали. Т.е. если первые 3 пункта ОК но делать изменения в проекте может только та команда которая проект делала — то заказчик де факто заложник команды разработчиков и не владеет своим кодом.
5. также важна предсказуемость т.е. если сказали что сделаем к 1-ому числу то сделали к 1-ому.

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

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

Если девелоперам плохо — думаю это проблемы менеджера и/или компании.

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

По поводу технологий, рисков и т.п. представьте себе такую ситуацию — вы отдали деньги инвестционному фонду. Приходите туда через какое-то время — спрашиваете как дела. Вам отвечают
— Мы вложили деньги в акции компании К.
— А почему туда?
— У них девушка прикольная на акциях нарисована, нам нравится.

Ваша реакция?

20.07.2010 12:28:37 intr13

intr13 — Tue, 20 Jul 2010 12:28:37 GMT

И правда? Вот вы например, со своим опытом, работаете только за деньги на работе? И больше вас ничего не интересует? Например, вы выберете более денежный проект в ущерб интересности?

И даже не было у вас проектов где вы делали что рискованное, для пользы проекта, без учета прибыли?

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

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

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

p/s
Я сам сторонник стандартных решений, но почему то кругом вижу одних велосипедистов.

20.07.2010 10:13:44 Semenych

Semenych — Tue, 20 Jul 2010 10:13:44 GMT

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

Пример из предидущего комментария закончился созданием платформы Java т.е. Гослинг хотел полета мысли пришел с этим к менеджеру и тот посмотрел на Гослинга и решил что дядька крутой и стоит ему дать бюджет. Но при этом что характерно он говорил с начальством с точки зрения нафига это надо компании и бизнесу.

20.07.2010 10:04:07 intr13

intr13 — Tue, 20 Jul 2010 10:04:07 GMT

То есть получается что все нормальные программисты готовы всецело себя отдать целям бизнеса? Пожертвовав своими амбициями на благо заказчика? С трудом в это верю я :)

Да и как определить полезность для бизнеса? Это ведь чистой воды продажа решения и рисковое производство.

20.07.2010 09:54:34 Semenych

Semenych — Tue, 20 Jul 2010 09:54:34 GMT

ну насчет жлобства не знаю, с Воронежскими заказчиками не общался. А так это по моему общесоветская черта.

20.07.2010 09:31:56 xeningem

xeningem — Tue, 20 Jul 2010 09:31:56 GMT

«Жлобство», ну по рассказам по крайней мере. «В Воронеже желание заказчика получить всё и без оплаты достигает прямо таки невероятных размеров» — цитата бывшего коллеги.
Баек травить не буду :)

20.07.2010 09:13:19 Semenych

Semenych — Tue, 20 Jul 2010 09:13:19 GMT

Допустимо все что годится для бизнеса. Нормальна ли ситуация когда программер хочет уйти из компании, а ему говорят — скажи что тебе не нравится — хочешь давай мы тебе дадим денег а ты на них будешь удовлетворять амбиции? Сами знаете чем такая ситуация в реальной жизни закончилась.

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

Писать много кода это дорого и расточительно тут дело не в амбициях. Так что framework нужен только нужно обоснование для бизнеса в чем будет выгода.

20.07.2010 09:05:15 intr13

intr13 — Tue, 20 Jul 2010 09:05:15 GMT

Хорошо, я перефразирую вопрос: допустимо ли в рамках бюджета удовлетворять личные амбиции программистов, при условии что прибыль (денежная) от удовлетворения амбиции будет отрицательной. Например, допустимо ли написать фреймворк и потерять 5 процентов от бюджета на амбиции или стоит писать много кода без всякого фреймворка? В итоге получится что люди мотивируются в проекте не только результатом, но и интересностью (удовлетворением амбиций).

Конечно многое зависит от, и все тут белые и пушистые, но все же…

20.07.2010 08:48:14 Semenych

Semenych — Tue, 20 Jul 2010 08:48:14 GMT

Не у нас как раз было нормально мы были нормальными IT-шниками попавшими в АСУТП соответственно смотрелись мы там крайне чужеродно, зато у нас работало. И шеф-монтаж мы делали быстро т.к. готовились дома. А вот коллеги или московского оффиса это было да.
Старые >40 лет программеры, хорошо умеющие держать в руках паяльник и знающие наизусть прерывания MSDOS. Увы про то что настройки надо хранить отдельно и про массу дпугих добрых вещей им не рассказали.

Был вообще анекдотичный случай — один чел хранил исходники строго на той машине где стояла SCADA диспетчера. Т.е. он месяц бухал, потом ехал и месяц творил на месте, заводил там все прямо на месте и возвращался бухать. Правда его в конце 90-х уволили.

BTW это какая такая еще более известная Воронежская черта?

20.07.2010 08:39:47 xeningem

xeningem — Tue, 20 Jul 2010 08:39:47 GMT

Сам «родом из АСУТП». Не то, чтобы сильно подтвеждаю, но в части разработки бардака там немеряно. В частности, из десятка организаций, с которыми я сталкивался не было ни одной с «выделенным» QA. Может быть это чисто Воронежская черта (ну, помимо более известной...), кто знает.
Но с АСУТП там опять таки есть один тонкий момент — пока не заработает — домой не уедешь. Шеф-монтаж — это такое дело…

20.07.2010 08:36:38 Semenych

Semenych — Tue, 20 Jul 2010 08:36:38 GMT

Ну может и менее болезненно делать. Как пример — новый функционал делается по новому и постепенно вытесняет старый — это конечно геморой для команды — но за изменения надо платить.
А две версии — это жестко — лучше без этого обойтись.

20.07.2010 07:14:58 maovrn

maovrn — Tue, 20 Jul 2010 07:14:58 GMT

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

Минус итеративного подхода в том, что во время переходного периода (а он, как все временное, может длиться бесконечно долго) придется поддерживать обе версии. Например, разработчики решили переделать библиотеку Х на Y, в новых фичах использовать Y. Но старые фичи используют X и переписывать все старые фичи, чтобы они работали с Y накладно. В итоге в проекте параллельно работают две версии одной библиотеки.

20.07.2010 06:33:31 Semenych

Semenych — Tue, 20 Jul 2010 06:33:31 GMT

Тут да сложно что-то добавить. Главное понимать что «кропотливое соблюдение сформировавшихся правил» это вообще-то и есть архитектура.

Переписывать это не выход. Как говорит товарищ Брукс переписать приложение вообще нельзя. Можно только написать аналогичное новое.

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

Хотя конечно что-то очень постепенно и итерационно можно менять, но не не видя кода точнее сказать сложно

20.07.2010 06:01:57 maovrn

maovrn — Tue, 20 Jul 2010 06:01:57 GMT

Какой ответ вы ожидаете? Переписывание, особенно если программа работает — страшное зло. Рефакторинг ради рефакторинга. Наверное у всех программистов, которые сталкиваются с чужим кодом возникает ощущение «что за… это все надо переписать». Не факт что новая архитектура будет лучше, будет удовлетворять требованиям. А что с ней (архитектурой) будет когда команда программистов снова сменится. Люди ведь часто устают или вырастают и переходят с проекта на проект через 2-3-4 года. А проект остается. Уверен, у следующей команды также возникнет ощущение, что все надо переписать.

20.07.2010 00:31:07 intr13

intr13 — Tue, 20 Jul 2010 00:31:07 GMT

*но программисты ее не переваривают

20.07.2010 00:30:28 intr13

intr13 — Tue, 20 Jul 2010 00:30:28 GMT

Спасибо довольно интересно, особенно байки.

Но у меня есть немного странный вопрос: что делать если архитектура приложения удовлетворяет требованиям и подходит для заказчика, но программисты ее переваривают?

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

Основная цель конечно качественный результат :)

19.07.2010 18:30:57 Semenych

Semenych — Mon, 19 Jul 2010 18:30:57 GMT

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

19.07.2010 18:28:23 Semenych

Semenych — Mon, 19 Jul 2010 18:28:23 GMT

Сложно сказать. Сейчас немного времени появилось пока жена с дочками в деревне, там видно будет.
Рассказать то есть о чем. Заявки принимаются. Вот черновик сделал одной статьи — если все будет ровно то думаю к среде «отправить в печать». Тема — про отказоустойчивость.

19.07.2010 17:13:42 VasilioRuzanni

VasilioRuzanni — Mon, 19 Jul 2010 17:13:42 GMT

Роскошная статья. Ждем продолжений! (Кстати, о чем они будут? :-)

В целом по архитектуре — считаю хорошей тенденцией появление многих фреймворков для реализации тех или иных архитектурных паттернов, которые при этом просты в использовании и (что важно) «навязывают» способ сделать что-то. Как, к примеру, Ruby On Rails — «нужно и правильно» делать так то и так то. И новичкам не удается отступить от православного способа, и любой другой разработчик уверен, что никто не придумал своих ненужных «джедайских штучек».

«Выяснилось, что дела идут хорошо, но приложение должно работать в разных конфигурациях, и есть масса проблем с развертыванием и зависимостями между модулями для некоторых конфигураций, но их почти удалось решить, убрав плагины и ведя разработку для каждой из более десятка конфигураций в своей ветке svn.»
Это очень интересный момент. В будущих статьях будет что-нибудь про multu-tenant-системы?

19.07.2010 12:54:53 Semenych

Semenych — Mon, 19 Jul 2010 12:54:53 GMT

нет это не я :-) извинения приняты

19.07.2010 12:54:23 Semenych

Semenych — Mon, 19 Jul 2010 12:54:23 GMT

OMG какой лавкрафт, какой анонимус, какая стать? Девушка Вы о чем вообще? Это вообще livejournal.com

19.07.2010 12:53:29 Alice_F

Alice_F — Mon, 19 Jul 2010 12:53:29 GMT

да, судя по этому ответу, действительно я ошиблась, а там, видимо, тролль написал.
прошу прощения(

19.07.2010 12:51:49 Alice_F

Alice_F — Mon, 19 Jul 2010 12:51:49 GMT

если это не вы, то прошу прощения

19.07.2010 12:51:19 Alice_F

Alice_F — Mon, 19 Jul 2010 12:51:19 GMT

lisaflay.livejournal.com/51997.html

19.07.2010 12:25:32 Semenych

Semenych — Mon, 19 Jul 2010 12:25:32 GMT

Э-э-э извините истерическое поведение в Вашем ЖЖ это про меня? А Вы извините кто? Можно ссылку на истерическое поведение?
Или это таки не про меня?

19.07.2010 12:23:34 Semenych

Semenych — Mon, 19 Jul 2010 12:23:34 GMT

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

19.07.2010 12:22:58 Semenych

Semenych — Mon, 19 Jul 2010 12:22:58 GMT

Вообще байки 100% реальные — произошли либо со мной либо у меня на глазах.
Другой вопрос что байки эти я многим рассказывал, так что могло и расползтись.

19.07.2010 12:21:33 Semenych

Semenych — Mon, 19 Jul 2010 12:21:33 GMT

Ключевое слово АСУТП. И вообще есть много тайных мест в нашем бизнесе где десятилетиями произрастают такого рода кадры.

19.07.2010 12:20:50 Semenych

Semenych — Mon, 19 Jul 2010 12:20:50 GMT

Да приходилось и в довольно большом количестве.

19.07.2010 08:54:00 Semenych

Semenych — Mon, 19 Jul 2010 08:54:00 GMT

Нет в данном случае «художник» это имеется ввиду стадия когда не лечится.
Я сейчас работаю в компании где вообще к сотрудникам отнсятся более чем толерантно. Если человек дело делает и пользу приносит — то все остальное решаемо. Часто можно найти проект где надостатки этого конкретного человека превратятся в достоинства. Но не всегда.
Но есть закоренелые случаи e.g. один коллега в результате отстаивания своей точки зрения — вышел работать очень рано утром и к моменту когда все пришли не работу поменял половину классов (своих и чужих) приведя проект в абсолютно хаотичное состояние.

19.07.2010 08:49:08 Alice_F

Alice_F — Mon, 19 Jul 2010 08:49:08 GMT

нет, такое вполне возможно, просто у меня возникли сомнения в авторстве из-за того, что в диалоге habrahabr.ru/blogs/development/90880/#comment_3069161 Semenych не ответил напрямую типа «да это ж я написал)», а свёл к тому, что ещё выложит.
сомнения усугубились из-за истеричного поведения в моём жж — не знаю, может ли человек, пишущий предъявы в стиле блондинки, написать такую довольно годную статью.
кстати говоря, напиши он спокойно здесь, что он автор — никаких проблем. я могла ошибиться. извинилась бы. теперь как-то совсем доверия нет

19.07.2010 07:23:54 tangro

tangro — Mon, 19 Jul 2010 07:23:54 GMT

К стати, и правда интересно, неужели всё вышеизложенное случилось с одним и тем же человеком и более того, автором данного поста? Я просто уже читал около половины баек из данной статьи в разных местах.

19.07.2010 07:02:49 dzmitryc

dzmitryc — Mon, 19 Jul 2010 07:02:49 GMT

«Группа из трех товарищей… все они были зрелые проверенные специалисты… один большой файл на 150 Кб, в котором захардкожена строка связи с БД, включая пароль, и оттуда же идут все обращения к БД»

… вызывает «когнитивный диссонанс». За такое даже начинающим начинающим товарищам дают по пальцам.

19.07.2010 06:31:59 powerman

powerman — Mon, 19 Jul 2010 06:31:59 GMT

Я не совсем понял суть вопроса. При совместной работе и активном обсуждении текущих проблем уровень каждого определяется достаточно быстро, сам собой. Деление на конкретные уровни вроде junior/average/senior относительно условно и у каждого может быть своё, но общая квалификация определяется без проблем. Ну, если задуматься, то легко определяется квалификация тех, кто менее опытен, чем ты или равен тебе по опыту. Квалификацию более опытных товарищей определить вряд ли получится, кроме самого факта их большей квалифицированности.

19.07.2010 06:10:06 chiaroscuro

chiaroscuro — Mon, 19 Jul 2010 06:10:06 GMT

> Команда должна быть с архитектурой более или менее согласна. Если яростного фаната Oracle заставить делать приложение на PostgeSQL и требовать от него высокой производительности — получится не очень. Если не получается, надо:

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

Если приходилось, расскажите, пожалуйста.

19.07.2010 06:07:00 chiaroscuro

chiaroscuro — Mon, 19 Jul 2010 06:07:00 GMT

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

Вопрос Вам и автору топика: каким образом определяете «крутость» (по выражению ОПа) или же «квалифицированность» работника?

19.07.2010 05:40:48 Alice_F

Alice_F — Mon, 19 Jul 2010 05:40:48 GMT

если вы выложили чужую статью, следует отмечать авторство

19.07.2010 04:14:51 powerman

powerman — Mon, 19 Jul 2010 04:14:51 GMT

Книг вообще и учебников в частности на эту тему написано множество, и я не чувствую себя достаточно крутым, чтобы написать еще один — самый лучший.
…
(из третьей части) Я лично знал двоих людей написавших и издавших книги в издательстве Manning, оба они по профессиональному уровню тянули в лучше случае на мидлов.

Это довольно типичная ситуация: люди, которые знают многое, так же понимают, как много они ещё не знают, и воздерживаются от написания книг… а в это время гораздо менее квалифицированные, но зато более самоуверенные пишут книжки. В результате действительно хороших книг в IT катастрофически мало, зато полным-полно «профи», которые подкрепляют свои заблуждения ссылками на «умные» книжки.

он <художник, и он так видит>, тогда это больше к менеджменту и в сторону выхода

Вы несколько раз это упоминаете (как минимум ещё было в четвёртой части), но с точки зрения менеджмента это не самое лучшее решение проблемы. Увольнение проф.пригодного сотрудника — это, по сути, знак ошибки менеджера. Одна из задач менеджера — найти способ получить максимальную отдачу от каждого. Да, этот у нас «художник», но ведь идеальных сотрудников не бывает, у каждого свои особенности и недостатки, все разные и это надо учитывать — хороший менеджер умеет организовать работу так, чтобы максимально использовать сильные стороны каждого сотрудника, а их недостатки при этом минимально мешали работе. Художники плохо работают в команде, но зачастую для них можно найти отдельные, небольшие, но нетривиальные проекты, исследовательские задачи, создание прототипов, и т.п. — и они в большинстве случаев решат эти задачи лучше, быстрее и дешевле (если не увлекутся мелкими деталями, но за этим уже должен следить менеджер), сэкономив таким образом ресурсы основной команды. Хотя, возможно, мы с Вами просто по-разному понимаем термин «художник», тогда всё что я здесь написал может быть не актуально.