Pull to refresh

Comments 108

На одном дыхании. Давно стал считать: предел совершенства — есть цель.
«Лучшее — враг хорошего» (с) М. Джиованни, 1574 и другие
Я к тому что слепо бросаться в крайность перфекционизма все же не стоит.

А статья довольно интересная, есть о чем задуматься. Интересно, будет ли это редким случаем, когда статья больше комментариев?!
Недавно читал статью — tl;dr: погоня за идеалов вызывает депресию и приводит к прокрастинации. Именно перфекционизм, а не лень.
А мне нравится почему-то. Напоминает чтение txt много лет назад, книг с либру, например.
Всё же режет глаз, особенно на фоне других постов.
Именно шрифт заставил меня прочитать этот текст. Действительно при моих ассоциациях выглядит как класика, рядом с примитивной попсой рядом. Так что на вкус и цвет…
чтение txt много лет назад, книг с либру, например.

Я до сих пор читаю книги на сайте либру.
Мне, как постоянному пользователю различных IDE, намного проще воспринимать моноширинный шрифт. Да, да — сам удивляюсь.
<pre>...</pre>

зато, таким образом можно выравнивать текст по ширине, чего стандартный редактор не позволяет
Узкую колонку текста читать всегда легче. На широкой колонке глаз может постоянно сбиваться со строки.
Обычно ширину колонки я могу менять, изменяя размеры окна браузера. Здесь — нет.
Фиксированная ширина текста — прошлый век.
Сейчас принято делать текст резиновым, чтобы пользователь сам выбирал себе ширину и не зависеть от прихоти дизайнера.
Откуда столько нелюбви к моим словам, просто констатирующим тот факт, что Courier New был выбран из-за решения применить предварительно форматированный текст?
Если вы прочитаете предыдущие посты автора, то увидите, что в них он использует стандартное оформление. Может именно этот пост и надо читать только на мониторе, и в том виде, как это задумал автор? Это далеко не научная статья, а скорее изречение мыслей автора, и эффект при прочтении довольно своеобразный. И уж точно выделяющийся из общей массы. В конце концом, все же нам выбирать читать что-либо или нет.
Как итог, имеем половину комментариев, посвященных исключительно проблеме выбранного автором шрифта. Хотя других тем для дискуссии здесь уж точно хватает.
У меня на планшете строчки поста обрезаются в правой части, где они контактируют с желтыми хабраблоками вместо нормального переноса.
Там не Курьер Нью, а моноширинный по дефолту в настройках браузера.
UFO landed and left these words here
Правая или левая граница может быть за кожухом, поэтому лучше 78, а еще лучше 76!
Разделяю ваше негодование. Сам подумал, что надо мной издеваются, когда не смог найти в хабротэгах способа выравнивать текст по ширине.
Очень хуёво сглаживается в Линуксе.
Вру, сглаживается хорошо. Просто непривычно. А вообще: беллетристика моноспэйсом о непрагматизме.
После прочтения машинально ткнул esc. :)
Интересный стиль, читается на одном дыхании.

Сделать фон синим/ серым в стиле nc/dn и получится ня.
Я наверное как раз из тех, кто не следует догмам и не молится на «совершенные техники». Когда-то давным-давно я услышал фразу: «Чтобы быть кузнецом — надо ковать!» — и вот с тех пор это как руководство к действию… но тут еще и Ленина можно добавить «Учиться, учиться и еще раз учиться!»

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

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

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

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

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

Скажем, есть две страницы и переключалка между ними. Переключаемся в коде страниц. Потом добавили третью — поняли, что нужно сделать диспетчер. Гуру здесь отличается от новичка тем, что делает это уже на второй. Сделали, поместили в глобалы (ну а как же :) ). Потом оказалось, что нужно добавить другой модуль, который не связан с первым. Инстанцируем класс модуля. Делаем второй диспетчер и выносим из глобалов в модуль, создаем фабрику диспетчеров, потом диспетчер диспетчеров и так далее.
Никто не может предугадать заранее, в каком направлении пойдет развитие системы. А идеальная абстракция и так уже создана — это сам язык.
А просто один алгоритм переключения, использующий список (массив) идентификаторов (или пусть даже объектов) страниц, Вас уже не устраивает? Обязательно нужно городить весь этот огород из модулей и диспетчера? ;-)
Алгоритм можно обернуть в функцию, в класс — это уже от стиля зависит. Не вижу принципиальной разницы. Ключевой момент в том, что обработка переходов передается из кода страницы куда-то на сторону.
Ключевой момент в данном контексте как раз не алгоритм, а использование более простых структур вместо всего этого зоопарка классов, модулей, диспетчеров, фабрик. Не примите за оскорбление, но что, действительно настолько сильно мозг сломан ООП-методологией и паттернами или это просто шутка такая?
Насчет диспетчера диспетчеров шутка. А все остальное — нет. Когда проект большой, то разобраться в нем без применения структурирования невозможно.
Для каждой системы свои простые структуры. Если у вас всего 10 разнородных сущностей, то вы можете не строить над ними второй этаж. А если 100, то вы задумаетесь и над третьим. Иначе просто повеситесь от объема избыточного кода и трудновычищаемых зависимостей.
Полагаю, если Вы уже с 3-й страницы в данном примере начинаете строить такие ООП-зАмки, то Ваш висящий где-нибудь трупик найдут гораздо раньше, чем Вы доберетесь до 100 «разнородных сущностей» (звучит уже даже как-то угрожающе, как монстры какие-то ;-) ), ибо в данном случае избыточность плодите как раз Вы, при чем с завидной производительностью и рвением, насколько я понял.

Думаю, такого рода библиотеки будут очень в помощь Вам: habrahabr.ru/post/172119/
Настоящее ООП! Берите, не стесняйтесь, пользуйтесь! ;-)
Извращенством можно заниматься на любом языке. Фраза была о том, что мне все понятно стало с собеседником. Он не использует тесты (не считает нужным), лабает что-то единолично на пхп (причем спокойно может переписать все заново) и у него хороший код. Ок, мне не о чем с ним разговаривать. Очевидно у нас с ним слишком разное восприятие того, что такое разработка.
> Очевидно у нас с ним слишком разное восприятие того, что такое разработка.

Можно поинтересоваться о Вашем восприятии? Занимательно было бы узнать о настоящей разработке!
создаем фабрику диспетчеров, потом диспетчер диспетчеров и так далее.

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

habrahabr.ru/post/141477/
Гуру сделает в N Измерениях, а не в одном, еще до добавления первой страницы, причем с абстрактным классом для абстрактной операции, где навигация — лишь частный случай перемещения вьюпорта в абстрактных данных :)
Причем он напишет для этого свою либу и выложит на гитхаб, да :)
Уберите pre и больше никогда не пользуйтесь! Читать с мобильных устройств просто невозможно!
Весьма приятная статья, спасибо.
Мысль про бо́льшую неоднозначность «расширяемость vs с нуля» для меня свежа, возьму на вооружение и проверки.
Я все-таки спрошу: вы читали The Pragmatic Programmer?
что такое «чистый код» каждый понимает по своему и это хорошая тема для флейма. Я всегда был врагом излишней патернизации в угоду производительности, так как основная специфика — это высоко-нагруженность.
И правильно сказал автор, что Фаулер царь и бог только в своем классе разработки приложений.
По большей части — паттерны нужны, но когда точно знаешь, что проект заточен под MySQL/PgSQL и тип БД меняться точно не будет — нет смысла наворачивать на класс общения с БД Адаптер. Другое дело — коробочный вариант…
Я тут недавно пообщался с некоторыми тимлидами, которые готовы в паттерны завернуть все что угодно. Особенно увлечены ОРМ. Но, если выкинуть 35-45% кода, то он все равно решит эту же задачу. Так зачем платить больше, если ждем диких нагрузок? Хотим производительности от БД на больших объемах — шардим данные… А если шардим данные, то какого черта завязываемся на ОРМ, архитекторы хреновы :(…
сорри — наболело…
ОРМ — Опытный Ракетный Мотор? Мне кажется, рекетные технологии достаточно быстры.
Эхх… Пятница. У всех наболело.
а постановка задачи сейчас судя по всему во всех областях хромает — вот и копаем «от забора и до обеда».
Вот моя теория насчет любви тимлидов к ORM. Есть масса проектов, где использование ORM более, чем уместно. Тимлидам он нравится, т.к. если задача хорошо ложится на возможности ORM — кодеры быстро пишут понятный и легко изменяемый/сопровождаемый код. Скорость разработки и стоимость поддержки настолько приятнее, что иногда ORM можно увидеть и в местах, где он по каким-то причинам (например — производительность) не очень уместен.
Наилучший свод правил, по моему личному мнению, как писать «правильный» код, содержится в книге по экстремальному программированию. Не важно как именно ты пишешь, применяешь паттерны или нет, оопэ или шмоопэ, используешь фреймворки или фонтанируешь рулонами спагетти, тщательно все документируешь или считаешь, что лучшая документация это код, пишешь комментарии или нет, главное — стоимость поддержки в будущем. Если через пол года, не вызывая никаких проблем, за максимально короткий срок можно внести исправления в систему, значит код написан правильно.

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

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

При это есть противоположный пример — параллельно писали проект по всем правилам, спринг, maven, тесты, абстракция на абстракции — в итоге все ведущие программисты уволились, индусы проект не потянули, и проект просто забросили. А писали его года 3.

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

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

Да! Только вчера был длинный разговор с коллегой, который хотел взять и все переписать на другую архитектуру, аргументы вида «а вот если прилетят инопланетяне, то и тогда новую архитектуру можно будет расширить» :)
Отличная статья. А то я вчера прочел про то как человеку впаривают автотестирование на его небольшие веб проекты, что мне аж плохо стало… Теперь баланс добра и зла восстановлен.
«попробуйте во время проектирования очередного модуля или сколько-то серьезного класса задавать вопрос „почему“ на каждое свое действие, попробуйте с точки зрения логики обосновать последовательность ваших действий, так чтобы одно однозначно следовало из другого»

Вот эта способность и отличает инженеров от ремесленников. Буковки SOLID, LSP, O(n), NF, Кнут и подобные вполне себе позволяют ответить на вопрос «почему».

А сказка про «простые» проекты, которые можно делать на коленке — отмазка неуча.

P.S. А вот с выводами, с оговорками, согласен. Любой инструмент нужно применять понимая зачем, когда и как. Не понимаешь — учись. Но что бы учиться, надо читать и пробовать. А не говорить себе «эта фигня никому не нужна»

P.P.S. Я таких называю «кодеры», в отличие от «разработчиков». Вторые — инженеры. Первые — ремесленники. Может быть и те и те нужны. Но я предпочитаю работать с инженерами.

Еслми копнуть в глубь истории то инжинер (engineer) — это двигателист. Высококвалифицированный техник который поддерживает работоспособность хитрого агрегата, а так же может скомпоновать его из известных блоков более или менее представляя их назначение. Он совершенно не в курсе почему именно эта марка стали должна идти на впускной выпускной клапан, причем толковый еще интересуется почему (стойкость к воздействиям и т.д.), а ведь есть просто шаманы — они запомнили что на клапана ставится 95-я и им просто поболту что есть уже более 50 видов сталей плюс композиты которые даже лучше справяться по своим показателям, но он будет пихать «старое и проверенное», а частенько еще и редко и дорогое в замене и поддержке. Оба ничем не отличаются от ремесленников — просто первый может следя за рынком создать сверхлегкий ДВС известной схемы, а второй будет клепать ширпотреб по чужим чертежам. Создание принципиально новой схемы — это дело совершенно других ребят — математиков и цсников, которые разрабатывают новые алгоритмы, придумывают хитровыделанные алгебры и хитроразмерные функциональчики.
Цепочку: Ученый — Компоновщик(он же дизайнер, он же архитектор) — Производитель никто не отменял. Чистые ученые скатятся в софистику и теории, чистые компоновщики будут играть во все то же лего из тех же кубиков, а производственники будут клепать тот же самый велосипед или смартфон иногда делая вип версию с гравировочкой и стразиками, или лоу кост — без вай-фая.
«Двигателист»!!!

Вы бы хоть со словарём сначала сверились, что ли. Или у гугла спросили.
ru.wikipedia.org/wiki/%D0%98%D0%BD%D0%B6%D0%B5%D0%BD%D0%B5%D1%80

Вот такие «двигателисты» и ваяют говнокод на коленке, не понимая почему это именно говнокод.
о, у кого-то правда вызвала батхёрт :)
Вы кроме википедии, ничего не читали чтоли?
Дабы подавить развитие баттхерта рекомендую поглядеть в итиль и посмотреть чем занимается инженер (дофига обязанностей техника и чу-чуть принеси подай), и чем дизайнер-проектировщик-архитектор, а то корчите из себя не пойми что, а обязанностей не знаете.
Далее: парень отвечающий на паровую машину — это mechanic, но на подлодках там все пипец как сложно… И там уже engineer (двигателист).
Вы упоминаете инженера в старом советском понимание, тот самый у которого мозг между ушами и один костюм на всех фотках в паспорте. Современный инженер уже другой: он платит кредиты, отвисает по кабакам, смотрит теорию большого взрыва чтобы чувствовать себя чуть умнее остальных и причем например не может объяснить разницу между SAS и SATA, или свято верует в то что по HDMI кабелю идет аналоговый сигнал и даже не интересуется подробностями, хотя при этом смеется над бухгалтершами неумеющими включить или выключить компьютер (а ведь их это точно так же неинтересует пункт два как и его пункт один). Он собрал, оно работает, он получил бабки и доволен. Не правда-ли мерзкое животное? Не все такие, но вот большинство…
Относительно кода могу согласится с одним из вышеописанных примеров: если это сделано быстро, работает четко и поддается до/переработке — это хороший код. Перевод на русский: если эта машина для меня комфортна и выполняет поставленные ей задачи, ремонтируется в тех условиях в которых я ее буду эксплуатировать и ремонтируется доступным мне инструментом — я ее возьму и буду ездить. То есть по пустыне хорош уазик карбюраторный ибо он подлежит восстановлению чуть ли не из металлолома с помощью кувалды лома, коекакой матери… ах да… пару консервных банок не забыть чтобы в случае чего карбюратор собрать было из чего. Но это не значит что на этом чудовище я буду гонять по городу где есть сервис центры и прочие достижения цивилизации? :)
Вы описали какого-то отморозка :) Наверное мне повезло — рядом со мной таких исчезающе мало.

Для начала, я имею основания полагать, что прочитал я, как минимум, не меньше вашего.

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

Если вы не видите разницы между должностью в штатном расписании и профессией, я не буду дальше спорить.

Собственно, автор статьи пишет примерно о том же — метод и инструмент надо применять осознано, а не потому что прочитал умную книжку. Только, судя по комментариям, большинство восприняли текст как «паттерны говно, TDD отстой, clean code — дурацкое требование начальства». И это печалит.

P.S. Кстати, культура речи и письма тоже один из признаков профессионала :)

P.P.S. Ну таки признайте, что с двигателистом вы облажались :) Действительно, очень легко подумать, что engineer от слова engine. Но увы.
К сожалению не признаю. современный инженер в IT это всетаки от слова «двигателист», а не от французских корней :(
Нашел только один подвид старого советского — design engineer.
Остальные просто квалифицированные техники.
Просто удивляет ваша реакция. Заказываете блэйд сервер ibm. Приезжает первый «инженер», заносит сервер в серверную, распаковывает, монтирует в стойку, проверяет наличие питания и готовность к следующему этапу. потом второй который все коммутирует ставит пустые ОС на лезвия и уезжает, потом третий который делает тонкую настройку, если вы берете нештатные лезвия то будет полуторный который втыкает апгрейды памяти в лезвия… И это все «ИНЖЕНЕРЫ». Настоящие инженеры по ITIL. Но мне их удобнее называть «двигателистами» Ибо они под разряд даже техника наладчика все не проходят.
В тяжелом машиностроении кстати тоже попадались забавные тела в ранге инженеров. Им в институте вбили пять формул (может и больше) и они катают по ним как шаманы по кругу с бубном и только на них и смотрят… Ни о чем больше не думают… Кстати благодаря им и приелся у меня термин двигателист :) Это еще лет 15 назад было. Связать их с французским словом определяющим полет мысли было сложно… Гдето как крота с ласточкой.
Но дело в том что в IT инженер — это как директор в както попавшейся мне гейрбалайфоподобной конторе. Не было там никого ниже директора, так и тут нет техников — они все называются инженерами. А инженеры называются архитекторами. В общем просто подмена понятий.
Если бы были такие должности как «верстальщик кода», «алгоритмист», «техник-монтажник» — было бы понятнее, но путем присвоения красивого и звучного звания «программист» быдлокодеру — можно сыграть на его себялюбии и удержать при меньшей зарплате. :)
И я вижу различие. Но вот почему-то слишком много «двигателистов» поработав в должности — мнят себя инженерами…
Не «двигателист», скорее все-таки «проектировщик/создатель машин» или «машинник», если по вашему. :) И в общем случае подразумевается как раз человек, который и в теме насчет марки стали (или хотя-бы понимающий, что этот вопрос обязательно требует подключения профильного специалиста), и потенциально способный выдавать нестандартные решения, типа роторно-поршневого двигателя (если уж вы начали о ДВС).
Кхм.

Если ссылки не помогают, скажу прямо:

An engineer is a professional practitioner of engineering, concerned with applying scientific knowledge, mathematics, and ingenuity to develop solutions for technical problems. Engineers design materials, structures, and systems while considering the limitations imposed by practicality, regulation, safety, and cost. The word engineer is derived from the Latin roots ingeniare («to contrive, devise») and ingenium («cleverness»).
Написано хорошо и правильно — но всю статью пережевывается одна банальная мысль — не принимайте на веру чужой опыт.
Относитесь ко всему со здоровым скептицизмом. Особенно к тому, на что молятся массы. Думайте своей головой.

Автор, спасибо.
PS: Собственно к данной статье это тоже относится ;)
Я считаю, что есть только один хороший паттерн — сажать разработчика на поддержку своего проекта. А там уж пусть как хочет, так и пишет. И не важно — наговнокодил он или напаттернил. И то, и другое может вызвать жуткий баттхерт у другого программиста.
Это экономически нецелесообразно.
Если узко смотреть, то да. А если весь жизненный цикл продукта учесть, то уже не факт.
Как раз наоборот. Вы же не хотите зависеть от единственного поставщика услуг на протяжении всего срока дизни продукта, давая ему тем самым возможность диктовать вам условия?
Клиент по любому будет зависеть от разработчика, который написал программу. И надо сразу в договоре прописать его обязательства по поддержке. Иначе у клиента может быть полная засада при выявлении проблем.

Проблема в том, что все стремятся оптимизировать только себя. Если «написал, сдал, а там хоть трава не расти». То трава и не вырастет. А если на поддержку посадили, то он опять себя начинает оптимизировать, но уже на новом уровне — чтобы было просто для юзеров и безглючно.
Клиент по любому будет зависеть от разработчика, который написал программу.

Вот этого и надо избегать. По крайней мере, это в интересах клиента (или, если смотреть мельче, в интересах начальства конкретного программиста).

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

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

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

Кто вам это сказал?
Время жизни конкретной программы обычно не более 3-5 лет. Этого вполне хватит для «пожизненных» обязательств. А если продукт развивать, то опять же это уже долгосрочный договор. К примеру, на холодильники в среднем гарантия 3 года. И ничего — живут же (заметьте, там есть такая фишка как износ).

Кто вам это сказал?

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

Во-первых, вы никогда не видели систему старше десяти? Я видел.

А во-вторых, за это время можно сменить двух-трех контракторов.

Этого вполне хватит для «пожизненных» обязательств.

За деньги в несколько раз превышающие стоимость разработки.

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

У вас неверная формулировка: не «стороннему», а «другому». Вот у меня в отделе ротация кадров — код писал один человек, через месяц уволился, теперь поддерживать другому. Я, очевидно, заинтересован в том, чтобы этот «другой» мог в нем (коде) разобраться быстро, а стоимость его поддержки была минимальной.
Я тоже видел систему старше десяти лет. Ее грызут одни и те же програмисты. Стоимость разработки при поддержке другим программистом возрастает, а не уменьшается! Потому что ему сложнее и дольше разобраться в коде.

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

На самом деле такая поддержка занимает не так уж много времени и не напрягает.
Стоимость разработки при поддержке другим программистом возрастает, а не уменьшается!

Понятно. Контрактов с пятикратно завышенной ценой просто потому, что «а куда вы денетесь», вы не видели?

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

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

Ну, то есть, разрабочик ПО, в моем понимании, это производитель (а не просто работник). А значит, должен обеспечивать гарантию. Короче, он хотя бы «вправе» это делать, как по закону о защите прав потребителя.

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

Если такую возможность ввести, то это нехило бы изменило ландшафт. Дополнительным бонусом было бы уменьшение монополизации. Например, все пользуют 1С, Java, C#, PHP и т.п., потому что там уже сформирован рынок труда. Разработка на чем-то новом и перспективном не ценится, как раз из-за косяков с поддержкой. А гарантийную поддержку сложно или нельзя прописать юридически. Поэтому имеем сильную тенденцию к монополизации. Это относится в том числе и к ОС, СУБД и прочим платформам.

Как считаете?
Ну, то есть, разрабочик ПО, в моем понимании, это производитель (а не просто работник).

Уже неверно. Чтобы он был производителем, ему нужно дать больше автономности — что неэффективно для компании.

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

Нет. Если мы говорим о наемном труде (а не о контракте на выполнение работ) — то нет.

Как считаете?

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

Еще раз: поддержка — это рынок. Нет никакого смысла быть на нем альтруистом.
Ну вот вы говорите, что у вас из отдела увольняются программисты, остается какой-то рабочий код. Почему вам, как компании неэффективно, чтбы они поддерживали то, что они накодили? Хотя бы в течение гарантийного срока. Хотя бы за четко прописанные деньги. Я реально не понимаю вашей логики. Ну и пусть вы будете зависеть от программиста. Но и он же по договору будет привязан к вам. Риски же снижаются, стоимость работ тоже.
Потому что качество этой поддержки будет ниже, чем мне бы хотелось — и у меня нет ровным счетом никакого способа повлиять на него.
Почему качество поддержки будет ниже?
Потому что у исполнителя нет никаких причин делать свою работу хорошо — все равно от этого ничего не зависит.
Почему не зависит? Во-первых, если поддержку прописать в договоре, то качество ничем не будет отличаться. Во-вторых, качество исправления глюков дискретно: или исправил, или нет. В-третьих, программист будет заинтересован в уменьшении количества обращеней к нему. В-четвертых, программист будет-таки ловить свои глюки, а не чужие. А это две большие разницы.
Ваш варинат — утопия.
Давайте рассмотрим причины ухода человека с работы

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

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

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

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

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

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

Во-вторых, качество исправления глюков дискретно: или исправил, или нет.

Глупости какие. Есть как минимум «за сколько времени» и «какой ценой для системы».

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

Зависит от условий договора.

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

Несомненно. Свои ошибки замечать сложнее.

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

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

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

Кроме того, не стал бы однозначно ставить под сомнение компетентность руководства, которое назначило тимлидом не самого опытного разработчика. В реальности профессиональный уровень — не единственный критерий. Очень часто бывает, что на роль тимлида выбирают, старожила, к которому уже привыкли и знают как вести с ним диалог или того, кто еще помнит как работает унаследованный код. Бывает так, что иностранные заказчики не могут без слез слышать акцент кого-либо еще из команды. И бывают даже случаи, когда из нескольких кандидатов только один не ведет себя асоциально.

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

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

В этом случае как раз уместно игнорирование такого решения.

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

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

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

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


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

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


Насчет отдельных разработчиков — соглашусь, это встречается чаще, но решается просто — назначением задачи на кого-то из числа согласных, конфликта при этом не возникает. Но заявление по собственному, как по мне, очень уж радикальная мера.
Проблема в том, что мы не можем построить коммунизм внутри отдельно взятой команды
Вы про self-regulating teams (в скраме, например) не слышали?

кто-то должен заниматься общими вопросами.

Это какими, например?

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

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

Зачастую людям банально лень.

решается просто — назначением задачи на кого-то из числа согласных

К сожалению, это не решает проблем системного характера (тесты, конвенции, трекинг и так далее).

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

А зачем мне сотрудник, который не согласен работать так, как я считаю лучше для компании? Тем более — зачем мне сотрудник, который осознанно саботирует принятые в компании решения?
Вы про self-regulating teams (в скраме, например) не слышали?

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

А зачем мне сотрудник, который не согласен работать так, как я считаю лучше для компании? Тем более — зачем мне сотрудник, который осознанно саботирует принятые в компании решения?

Вы подменяет смысл сказанного. Речь шла о том, зачем сотруднику увольняться в случае разногласий и я высказался в том смысле, что «незачем». Если вы говорите о том, зачем тимлиду сотрудник и почему бы ему просто не уволить такого умника, то нужно понимать, что во-первых решения об увольнении не принимаются спонтанно одним человеком, это достаточно сложный и неприятный процесс, а во-вторых тимлид же и нанимал этого человека, стало быть попытаться уволить кого-то — все равно что признаться в собственной ошибке.
Может быть где-то в параллельной вселенной и существует такое явление, но в реальности хоть убейте, не могу себе представить заказчика, который вкладывает в проект свои деньги и соглашается с тем, что ответственность в случае каких-то неприятностей ляжет на абстрактную «команду» — он скорее будет скандалить и требовать линчевать скрам мастера / тимлида / техлида / кого угодно еще.

Заказчика это вообще волновать не должно. Заказчика общается с руководителем проекта (который с тим-лидом ничего общего не имеет).

Речь шла о том, зачем сотруднику увольняться в случае разногласий и я высказался в том смысле, что «незачем».

Альтернатива — идти к начальству — озвучена уже.

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

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

Хорошо, допустим в той схеме, о которой вы говорите есть некий руководитель проекта и нет тимлида, но что он будет делать в случае неудач? Он будет объяснять заказчику что луна в стрельце или попробует внутри команды найти виноватого? А найдет ли?
Он будет объяснять заказчику что луна в стрельце или попробует внутри команды найти виноватого? А найдет ли?

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

странный вывод из всего этого: современные методики разработки зло.
причем если неопытные разработчики делают все плохо по незнанию, то опытные злонамеренно, из гордыни…

… проэкты которые не надо поддерживать, они пишуться изначально без ошибок, одним человеком в обозримое время и больше не повторяются — это плод больного воображения
Один из основных тезисов (даже рецептов), который всегда мне приходил в голову при произнесении предложений в стиле «А почему от GoF я не стал писать код лучше?», «Что-то я не могу понять, где какой паттерн запихнуть», и.т.д. автор изложил в следующем предложении
Если вы все таки хотите понять кто и зачем все это использует, то
изучайте код больших проектов на Java, C#, C++.


Остается только добавить, что нужно изучать код хороших с т.з. этого самого кода проектов. Какой проект хороший — для новичка определить трудно.
Можно сократить пост до фразы: «мода ≠ догма».
Only those users with full accounts are able to leave comments. Log in, please.