Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
Интересный, но больно «грубый» перевод…
Обычно в наследство достается только каталог htdocs/. Какой-такой контроль версий?..
«Как какой контроль версия? Я же не дурак, я бакапы сохранял, за 2010 год, за 2011 и вроде в начале 2013. А с год назад что-то там поменяли мне в коде и сайт не работает с тех пор. Почините пожалуйста.»© :)
А если по верх ещё чем-то зашифруют.
Так же интересен код, пропущенный через всякий софт облегчающий вес. Ну когда убирают табуляцию, пробелы, закомментированные куски.
Так же интересен код, пропущенный через всякий софт облегчающий вес. Ну когда убирают табуляцию, пробелы, закомментированные куски.
Хм.
А может, проблема, в том, что программисту совсем никак не оплачивают написание документации и описание систем развертывания?
По моему опыту, заказчику надо:
а) чтобы работало здесь и сейчас
б) чтобы это обошлось по возможности как можно дешевле
Мне никто ни разу не предлагал дополнительно оплатить обустройство системы так, чтобы это было понятно следующему разработчику — хотя, скорее всего, я бы от этого не отказался. Но заранее и бесплатно упрощать клиенту переход к другому программисту… по-моему, это слишком.
И вообще, как сам говорит автор:
Если бы автору ПО заплатили за то, чтобы он вернул свой технический долг — разве он бы этого не сделал?
А может, проблема, в том, что программисту совсем никак не оплачивают написание документации и описание систем развертывания?
По моему опыту, заказчику надо:
а) чтобы работало здесь и сейчас
б) чтобы это обошлось по возможности как можно дешевле
Мне никто ни разу не предлагал дополнительно оплатить обустройство системы так, чтобы это было понятно следующему разработчику — хотя, скорее всего, я бы от этого не отказался. Но заранее и бесплатно упрощать клиенту переход к другому программисту… по-моему, это слишком.
И вообще, как сам говорит автор:
Мне платят за то, что я возвращаю чужой технический долг.
Если бы автору ПО заплатили за то, чтобы он вернул свой технический долг — разве он бы этого не сделал?
>Мне никто ни разу не предлагал дополнительно оплатить обустройство системы так, чтобы это было понятно следующему разработчику
Ну да, я прямо вижу, как заказчик с порога начинает кидаться словами вроде svn, github, и тому подобное. Откуда им знать что это такое?
Продавайте хорошо, нагружая необходимыми допами, либо продавайте «как можно дешевле».
Сколько стоит выгрузка на гитхаб?
Сколько стоит написание минимальной документации?
Ну да, я прямо вижу, как заказчик с порога начинает кидаться словами вроде svn, github, и тому подобное. Откуда им знать что это такое?
Продавайте хорошо, нагружая необходимыми допами, либо продавайте «как можно дешевле».
Сколько стоит выгрузка на гитхаб?
Сколько стоит написание минимальной документации?
Я встречал заказчиков «Ты начинай программировать, а мы пока подумаем, что писать в ТЗ». А вы говорите про документацию. :-)
janvarev прав. В общей массе (если брать фриланс или частные заказы), клиенты действительно хотят быстрее, дешевле и без лишних затрат.
Я сам спрашивал не раз, нужна ли документация, инструкция по коду, инструкция по настройке сервера. Всем всегда нужно было. Но стоило заикнуться о доп оплате за это и увеличении сроков, сразу же были отказы.
janvarev прав. В общей массе (если брать фриланс или частные заказы), клиенты действительно хотят быстрее, дешевле и без лишних затрат.
Я сам спрашивал не раз, нужна ли документация, инструкция по коду, инструкция по настройке сервера. Всем всегда нужно было. Но стоило заикнуться о доп оплате за это и увеличении сроков, сразу же были отказы.
Я встречал заказчиков «Ты начинай программировать, а мы пока подумаем, что писать в ТЗ»Да, частый диагноз. Как правило объясняют это тем, что проект надо запустить как можно скорее, поэтому надо как можно скорее начать его реализовывать, иначе «все пропало, гипс снимают, клиент уезжает»©
Нередкий симптом этой аудитории, что не только ТЗ могут «позже предоставить», но и с оплатой попросить подождать, т.к. «Вы же понимаете что сроки очень важно, Вы нам проект срываете, это неприемлимо».
Помогает отчасти проникновенная речь на тему «Вы же понимаете как уникален Ваш проект, его нельзя делать по типовым шаблонам, поэтому сначала нужно ТЗ». Про оплату объяснить труднее:)
Ах да, еще шедевр из этой же серии. «У нас дизайн еще не готов, Вы пока возьмите любой что бы сайт главное запустить, а как будет готов — шустро оденете новый, но на сроках это сказаться не должно, иначе Вы нас подведете»©
А потом удивляются почему «технический долг» образовался…
Тех кто готов учиться или хотя бы понимать. Тех я на руках носить готов. С такими заказчиками всегда приятно работать.
А вот те кто только делают вид, что слушают. А потом через месяц разработки по согласованному ТЗ и срокам. Приходят с «У моей секретарши племянник, в школе делал сайт, вот он говорит вы всё не правильно делаете и денег много просите и вообще всё можно было сделать за пару дней на Joomla».
А вот те кто только делают вид, что слушают. А потом через месяц разработки по согласованному ТЗ и срокам. Приходят с «У моей секретарши племянник, в школе делал сайт, вот он говорит вы всё не правильно делаете и денег много просите и вообще всё можно было сделать за пару дней на Joomla».
Я тоже стараюсь использовать в общении не одни технические термины. А привожу аналогии из обывательской жизни. Где-то помогает, где-то нет.
С последним заказчиком сейчас буду судится. По началу тоже, слушал меня, соглашался. Даже порой останавливал объяснения с «да я всё понял». А потом пошли непонимания с «я такого не слышал», «я думал о другом». При том когда составлялось ТЗ и я ему предлагал если два варианта реализации, возможность выбора. Естественно расписав все плюсы и минусы каждого. Спустя время, он взял СЕОшников, те посмотрели на готовый функционал и предложили тот вариант который забраковал сам заказчик. Мне же было высказано, что это именно то что нужно и необходимо всё переделать. При том напоминание того, что он подписал ТЗ, показ ему того ТЗ от которого он отказался. На него никак не повлияло. Тупо включил режим дурака «я этого не помню». =)
С последним заказчиком сейчас буду судится. По началу тоже, слушал меня, соглашался. Даже порой останавливал объяснения с «да я всё понял». А потом пошли непонимания с «я такого не слышал», «я думал о другом». При том когда составлялось ТЗ и я ему предлагал если два варианта реализации, возможность выбора. Естественно расписав все плюсы и минусы каждого. Спустя время, он взял СЕОшников, те посмотрели на готовый функционал и предложили тот вариант который забраковал сам заказчик. Мне же было высказано, что это именно то что нужно и необходимо всё переделать. При том напоминание того, что он подписал ТЗ, показ ему того ТЗ от которого он отказался. На него никак не повлияло. Тупо включил режим дурака «я этого не помню». =)
Похоже на осеннее обострение. Тоже недавно получил подобную ситуацию, только у меня круче. Заказчик «позабыл» как подписывал акты приёма-сдачи работ. Мало того, начал намекать, что это я якобы подделал документ. Ему кое-как его же юристы объяснили что отказываться от собственной подписи чревато потерей лица и репутации. Не говоря уже про все шансы опрокинуться в суде и плюсом схлопотать 306 статью УПК (заведомо ложный донос).
Заказчик кстати занимается услугами в сфере микрофинансов. Разработка по-понятиям у этих ребят похоже в крови. Зарёкся вообще с такими общаться на будущее. И всем теперь советую обходить микрофинансистов стороной.
Заказчик кстати занимается услугами в сфере микрофинансов. Разработка по-понятиям у этих ребят похоже в крови. Зарёкся вообще с такими общаться на будущее. И всем теперь советую обходить микрофинансистов стороной.
Про оплату объяснить труднее:)
Если ситуация «Вы же понимаете что сроки очень важно, Вы нам проект срываете, это неприемлимо», то довольно просто.
Еще умиляют такие разговоры заказчиков (из реальной жизни): «Да нет… зачем все расписывать? Когда вы все сделаете, мы потом посмотрим и скажем вам, что не так».
> Ну да, я прямо вижу, как заказчик с порога начинает кидаться словами вроде svn, github, и тому подобное. Откуда им знать что это такое?
Когда отсутствие технического долга является важной частью проекта — чаще всего знают, или у меня есть возможность им об этом сказать и быть понятым.
Хороший пример: меня пригласили быть архитектором проекта и руководителем группы программистов. Я должен написать часть кода, поставить процессы, а затем уйти, чтобы на меня, как на высокооплачиваемого архитектора, больше не тратились деньги.
Разумные и осмысленные условия? Более чем — и я их готов принять.
Но чаще заказчику нужен функционал; в этом случае он рассчитывает, что я за осмысленную плату буду поддерживать предложенное решение и сам разбираться со своим техническим долгом.
Иногда клиент решает, что по тем или иным причинам я ему обхожусь слишком дорого, и принимает решение переключиться на другую группу программистов — которым и приходится разбираться с моим кодом. Если это происходит тихо-мирно — как правило, автор исходного кода дает необходимые комментарии по коду и развертыванию, возможно, за отдельную плату.
Ситуация же в статье происходит, на мой взгляд, чаще всего ровно в одном случае — заказчик просто «рвет» отношения, возможно, не оплачивает обещанную часть работы, и после этого пытается найти хоть кого-то, кто заставит его систему заработать. Откуда, собственно, и вытекают все проблемы человека, вновь приходящего на проект — но он должен знать, на что подписывается, ему за это деньги платят.
(Нет, наверное, еще бывает, что программист-раздолбай за один день улетает обретать просветление в Гималаи, и никому ничего не говорит… или фрилансер пропадает на три месяца, так что до него не дозвониться… но тут настолько серьезная проблема с людьми, что технический долг является к ним, скорее, довеском)
Когда отсутствие технического долга является важной частью проекта — чаще всего знают, или у меня есть возможность им об этом сказать и быть понятым.
Хороший пример: меня пригласили быть архитектором проекта и руководителем группы программистов. Я должен написать часть кода, поставить процессы, а затем уйти, чтобы на меня, как на высокооплачиваемого архитектора, больше не тратились деньги.
Разумные и осмысленные условия? Более чем — и я их готов принять.
Но чаще заказчику нужен функционал; в этом случае он рассчитывает, что я за осмысленную плату буду поддерживать предложенное решение и сам разбираться со своим техническим долгом.
Иногда клиент решает, что по тем или иным причинам я ему обхожусь слишком дорого, и принимает решение переключиться на другую группу программистов — которым и приходится разбираться с моим кодом. Если это происходит тихо-мирно — как правило, автор исходного кода дает необходимые комментарии по коду и развертыванию, возможно, за отдельную плату.
Ситуация же в статье происходит, на мой взгляд, чаще всего ровно в одном случае — заказчик просто «рвет» отношения, возможно, не оплачивает обещанную часть работы, и после этого пытается найти хоть кого-то, кто заставит его систему заработать. Откуда, собственно, и вытекают все проблемы человека, вновь приходящего на проект — но он должен знать, на что подписывается, ему за это деньги платят.
(Нет, наверное, еще бывает, что программист-раздолбай за один день улетает обретать просветление в Гималаи, и никому ничего не говорит… или фрилансер пропадает на три месяца, так что до него не дозвониться… но тут настолько серьезная проблема с людьми, что технический долг является к ним, скорее, довеском)
Куда более распространён совсем другой случай: сайт создаётся как часть большого, не-ITшного по своей сути, проекта и заказывается ровно также как заказывается витрина в фирме по изготовлению витрин и закупается мебель. То есть: как разовая задача, предполагающая сроки, оплату и сдачу. Задуматься о том, что существует ещё какой-то там «технический долг» они не могут потому что они не понимают чем создание сайта отличается от расстановки мебели.
А отличается он даже не тем, что созданием сайтов люди занимаются совсем недолго, а тем, что технический долг в заказанной мебели виден кому угодно (если у вас столы соединены с лавками, то и ежу понятно, что их придётся переделывать, чтобы увеличить расстояние от стола до лавки...), а вот «технический долг» даже специалист по внешнему виду сайта не увидит (но он хотя бы догадывается о том, где он может таиться, а заказчик-то свято уверен, что ничего кроме пикселей вообще не существует в природе!).
Исполнитель же, поставленный в условия, когда ему «насилуют мозг» зачастую сильно больше, чем ожидалось изначально и заранее знающий, что поддерживать это ему не нужно будет использует все возможные способы получить экономию «здесь и сейчас». А после нас «хоть трава не расти». Знание же того, что заказчик этого подвоха заведомо не увидит до выплаты денег вряд ли кого-то стимулирует делать «на века», так ведь?
А отличается он даже не тем, что созданием сайтов люди занимаются совсем недолго, а тем, что технический долг в заказанной мебели виден кому угодно (если у вас столы соединены с лавками, то и ежу понятно, что их придётся переделывать, чтобы увеличить расстояние от стола до лавки...), а вот «технический долг» даже специалист по внешнему виду сайта не увидит (но он хотя бы догадывается о том, где он может таиться, а заказчик-то свято уверен, что ничего кроме пикселей вообще не существует в природе!).
Исполнитель же, поставленный в условия, когда ему «насилуют мозг» зачастую сильно больше, чем ожидалось изначально и заранее знающий, что поддерживать это ему не нужно будет использует все возможные способы получить экономию «здесь и сейчас». А после нас «хоть трава не расти». Знание же того, что заказчик этого подвоха заведомо не увидит до выплаты денег вряд ли кого-то стимулирует делать «на века», так ведь?
Ситуация же в статье происходит, на мой взгляд, чаще всего ровно в одном случае — заказчик просто «рвет» отношения, возможно, не оплачивает обещанную часть работы, и после этого пытается найти хоть кого-то, кто заставит его систему заработать.
Ещё частая — сайт сделан, сдан, всё оплачено, через некоторое время требования меняются, но разработчику уже предлагаемые условия неинтересны. Или его просто не найти через пару лет.
При чем тут намереное упрощение?
Вроде бы заря индустрии уже прошла. Есть определенные отраслевые стандарты и отработанные механизмы. Мне к примеру частенько приходится подымать микросайты которые могут прожить всего месяц но даже тут есть определенные правила
1. создать репо на битбаскете ( там нет ограничения на количество приватных репозиториев в отличии от гитхаба)
2. использовать стандартные фреймворки и библиотеки — ( для мелочевки flask, для чего посерьезнее django)
3. комитьтся после каждой фичи
4. pip, virtualenv, fabric для разветки девелоперского и боевого окружение
ничего из этого не требует сколько бы нибыло серьезных затрат но сильно облегчает жизнь как мне так и последующему программисту ( например мне через полгода)
Вроде бы заря индустрии уже прошла. Есть определенные отраслевые стандарты и отработанные механизмы. Мне к примеру частенько приходится подымать микросайты которые могут прожить всего месяц но даже тут есть определенные правила
1. создать репо на битбаскете ( там нет ограничения на количество приватных репозиториев в отличии от гитхаба)
2. использовать стандартные фреймворки и библиотеки — ( для мелочевки flask, для чего посерьезнее django)
3. комитьтся после каждой фичи
4. pip, virtualenv, fabric для разветки девелоперского и боевого окружение
ничего из этого не требует сколько бы нибыло серьезных затрат но сильно облегчает жизнь как мне так и последующему программисту ( например мне через полгода)
Нужно только учесть, что люди, которые знают как всё это делается — они уже люди с опытом и потому стоят дороже, а понять за что — заказчик не может. Ведь и сайт, сделанный «на коленке» за три рубля студентом как-то работает и сайт, сделанный профессионалом вроде вас — тоже. Так зачем платить больше?
Я немного про другое. Оратор выше спрашивал зачем прилагать дополнительные усилия для упрощения последующего сопровождения проекта.
Но сейчас мы уже в такой стадии что инструменты достаточно развиты чтобы выкатывать приличный результат без дополнительных усилий. Скорее даже наоборот.
Но сейчас мы уже в такой стадии что инструменты достаточно развиты чтобы выкатывать приличный результат без дополнительных усилий. Скорее даже наоборот.
Но сейчас мы уже в такой стадии что инструменты достаточно развиты чтобы выкатывать приличный результат без дополнительных усилий. Скорее даже наоборот.
Да, сейчас проекты на порядке более просты, чем раньше — и мне тоже кажется, что производимый код поддерживать куда проще, чем раньше.
Я лишь говорил о «дополнительных усилиях» по увеличению понятности кода — о тех, про которых автор говорит в исходной статье.
Например, возьмем рекомендацию "(Не) Добавляйте зависимости от определенных версий библиотек и ресурсов..."
Предположим, мой клиент захотел иметь возможность генерации DOCX-документов на сайте, и, конечно, для него это одна из многих фич, которая не может оцениваться дорого.
Что сделаю я? Отыщу в интернете библиотеку, поставлю зависимости и быстро встрою в свой проект. Нет, я не буду специально запутывать код, но:
— Буду ли я специально документировать зависимости этой библиотеки? Вряд ли.
— Буду ли я специально в ней разбираться и вытаскивать одну функцию, которая мне действительно нужна, избавляясь от зависимостей? Вряд ли.
— Буду ли я документировать способ встраивания? Тоже вряд ли.
Таким образом, даже используя изначально хороший инструмент, но не прикладывая дополнительных усилий, мы получим все те проблемы поддержки, о которых плачется автор исходной статьи.
Вообще сложность систем всегда будет в среднем чуть выше, чем сложность стандартных инструментов для их создания. И мне кажется, что эти стенания относительно непонятности программ традиционны и больше зависят от людей, чем от самого процесса программирования:
— раньше кто-то писал на ассемблере? — конечно, разобраться в программе сложно.
— кто-то писал на Фортране? — тут же столько зависимостей, разобраться сложно
— у вас ООП? — ну, у вас более 50 классов, я ничего не могу понять в вашей архитектуре
— вы используете фреймворк и все делаете по гайдам, но вы прикрутили N сторонних библиотек? — черт возьми, в этом сложно разобраться!
А истина, мне кажется, проста — нужно поддерживать доверительные отношения с программистом, который вам создал (заметьте!) часть инфраструктуры(!) бизнеса. Тогда в нужный момент он вам объяснит все непонятные места (а то и поправит код), и эти проблемы даже не возникнут.
Ну вот 4-й пункт вызывает сомнения. Репо и библиотеки/фреймворки сейчас стандарт де-факто (если нет желания подсадить заказчика на иглу), но вот инструменты автоматизированного или автоматического развертывания окружения и деплоя приложения требуют серьезных (пятью минутами не обойтись) затрат.
Да тут я немного слукавил.
Мой воркфолу годится только для достаточно стандартизированного окружения и python разработки и пришел я к нему не сразу. Да и то некоторую степень ручной настройки они требуют. К примеру python-dev или libevent все равно руками ставить приходится. Ну и плюс работает только в unix подобных средах. И как справедливо заметили требует определенного профессионального уровня и опыта.
В любом случае если процесс стоит правильно то деплоймент руками никто не делает — проще написать скрипт. А уж что тут будет fabric, maven, gradle, phing. Не важно и для любого стека есть свои стандартизированные инструменты. И на мой взгляд их использование серьезно экономит свои же усилия. А если проект не первый то затраты еще меньше. А это уже самодокументация
Важный момент всетаки тут стек. К примеру java — там все давно заточенно под максимально простой и стандартизированный деплой приложения. Ruby, Python — тоже самое. Велосипедописание бессмысленно. За PHP я не слежу особо, но вижу что в этом направлении сделано очень много.
Мой воркфолу годится только для достаточно стандартизированного окружения и python разработки и пришел я к нему не сразу. Да и то некоторую степень ручной настройки они требуют. К примеру python-dev или libevent все равно руками ставить приходится. Ну и плюс работает только в unix подобных средах. И как справедливо заметили требует определенного профессионального уровня и опыта.
В любом случае если процесс стоит правильно то деплоймент руками никто не делает — проще написать скрипт. А уж что тут будет fabric, maven, gradle, phing. Не важно и для любого стека есть свои стандартизированные инструменты. И на мой взгляд их использование серьезно экономит свои же усилия. А если проект не первый то затраты еще меньше. А это уже самодокументация
Важный момент всетаки тут стек. К примеру java — там все давно заточенно под максимально простой и стандартизированный деплой приложения. Ruby, Python — тоже самое. Велосипедописание бессмысленно. За PHP я не слежу особо, но вижу что в этом направлении сделано очень много.
Сделано очень много, но субъективно более популярны в мире PHP инструменты для/на Ruby — chef, puppet, capistrano или для/на Java, что создает некий барьер для использования. Плюс со стандартизацией в мире PHP вообще всё плохо. Разве что самый распространенный способ деплоя — заливка по ftp (для продвинутых — по sftp). Да и VCS часто используются как простые бэкап-система — одна ветка и код в ней толком ничему не соответствует — ни дев серверу, ни стэйдж, ни продакшену. В общем инструменты есть, а культуры их использования — нет :(
ИМХО их скорее все же нет. Как вы справедливо отметили (если я правильно понял) с инструментами из других миров есть определенный барьер. Так например мои попытки использовать на проектах скажем TeamCity или Jenkins или еще какие инструменты из другого мира регулярно терпят фейл, по разным причинам. И кастомер вроде был не против, но споткнувшись один раз о какую нибудь проблемку, даже маленькую, связанную с применением инструментов с разных платформ, второй раз, третий и в итоге принимается решение использовать инструменты на php.
А тут все не всегда здорово. Например вот не всегда удается скомпилить less`ы с помощью lessphp (попробуйте скомпилить css`ку кастомного бутсрапа с помощью plessc… стабильного релиза который компилится lessc под nodejs). Можно долго перечислять. А скажем про такой позор, адъ и израель как композер лучше вообще молчать.
Вот и выходить, что инструменты вроде есть, но большинство из них в зачаточном состоянии. Вот и сижу я в полвторого ночи, приделываю как мне кажется нужную мне плюшку к PHPCI — еще один зародыш 18ти летней платформы. А кто еще, если не мы? —Десант Опен сурс он такой :)
А тут все не всегда здорово. Например вот не всегда удается скомпилить less`ы с помощью lessphp (попробуйте скомпилить css`ку кастомного бутсрапа с помощью plessc… стабильного релиза который компилится lessc под nodejs). Можно долго перечислять. А скажем про такой позор, адъ и израель как композер лучше вообще молчать.
Вот и выходить, что инструменты вроде есть, но большинство из них в зачаточном состоянии. Вот и сижу я в полвторого ночи, приделываю как мне кажется нужную мне плюшку к PHPCI — еще один зародыш 18ти летней платформы. А кто еще, если не мы? —
проблема, в том, что программисту совсем никак не оплачивают написание документации и описание систем развертывания?
Скорее дело в том, что есть кустарное производство и есть промышленное. В кустарном производстве каждая вещь делается почти как в первый раз, в промышленном изготовление вещей поставлено на поток, а значит есть и инфраструктура контроля качества. И эти виды производств — совершенно разные сферы, с разными заказчиками, разными деньгами, разными требованиями.
Забыли упомянуть о том что как можно чаще необходимо использовать coffee, typescript, dart, livescript, и желательно одновременно.
Разве вас заставляют поддерживать именно TS или CS? Слава богу на выходе у них вполне читабельный JS.
да, особенно если файлы сжаты
про «разжиматели» не надо :)
про «разжиматели» не надо :)
Если предыдущий разработчик был дауном, то какая разница на чем он писал, его код все равно будет невозможно поддерживать :)
А кто вам сказал, что он был «дауном»? У него в ТЗ было что-нибудь про поддержку сайта? Не было? Было только про зелёненькие кнопочки и синие ссылки? Ну так чего вы паритесь: зелёненькие кнопочки и синие ссылки на месте, всё работает, ничего больше [с точки зрения заказчика] в природе нету — какие могут быть претензии к автору?
У него самого, кстати, все исходники вполне могут быть… ну какое-то время, пока он их не потеряет.
У него самого, кстати, все исходники вполне могут быть… ну какое-то время, пока он их не потеряет.
Какая-нибудь навороченная система деплоя может тупо затирать все изменения внесенные в JavaScript при каждом коммите. Или вообще JS не деплоить. То есть чтобы получить возможность нормально править JS, нужно провести нетривиальную для как минимум первого раза работу.
Вы, возможно, не поверите, но во многих организациях в репозитории и правда попадает именно coffee, less и т.п. и писать требуют именно на них.
Т.е. по сути, люди диктуют не только то, на чём и что нужно писать, но и с помощью чего.
Т.е. по сути, люди диктуют не только то, на чём и что нужно писать, но и с помощью чего.
Упомянули.
Каждый день HackerNews и Reddit жужжат о новых крутых языках. Попробуйте их за счет клиента.
Работать с чужим кодом безусловно высокое искусство, но это крайне крайне интересно.
Документированный и понятный код скучен и не несет в себе отпечатков личности писавшего:)
Очень любим «возвращать технические долги», кроме шуток, это реально интересно.
Смотреть и разбираться как кто и почему реализовал, это куда веселее чем тупо кодить очередное app()->encode.
Бесплатным бонусом идет знакомство с чужими подходами, которых иначе бы и не увидели, а это всегда полезно, не замыкаться в рамках. И при чем эти подходы зачастую бывают на удивление элегантны, хотя (или благодаря этому?) и не вписываются в стандартные рамки паттернов проектирования и нормализованных баз.
Код с техническим долгом не обязательно плох и не обязательно создан плохим программистом.
По поводу создания технического долга — присоединимся к комментатору выше.
Обычно прайс выглядит так.
Создать сайт — Х денег и Y времени.
Создать задокументированный по всем правилам сайт — 3*X денег и 3*Y времени.
Мало кто из заказчиков готов платить.
К тому же, для разработчика знакомого с проектом изменение документированного сайта занимает нередко больше времени чем недокументированного. Потому что документированный нельзя быстро и грязно хакнуть плюнув на гайдлайны. Носишься с ним как с писаной торбой:)
Документированный и понятный код скучен и не несет в себе отпечатков личности писавшего:)
Очень любим «возвращать технические долги», кроме шуток, это реально интересно.
Смотреть и разбираться как кто и почему реализовал, это куда веселее чем тупо кодить очередное app()->encode.
Бесплатным бонусом идет знакомство с чужими подходами, которых иначе бы и не увидели, а это всегда полезно, не замыкаться в рамках. И при чем эти подходы зачастую бывают на удивление элегантны, хотя (или благодаря этому?) и не вписываются в стандартные рамки паттернов проектирования и нормализованных баз.
Код с техническим долгом не обязательно плох и не обязательно создан плохим программистом.
По поводу создания технического долга — присоединимся к комментатору выше.
Обычно прайс выглядит так.
Создать сайт — Х денег и Y времени.
Создать задокументированный по всем правилам сайт — 3*X денег и 3*Y времени.
Мало кто из заказчиков готов платить.
К тому же, для разработчика знакомого с проектом изменение документированного сайта занимает нередко больше времени чем недокументированного. Потому что документированный нельзя быстро и грязно хакнуть плюнув на гайдлайны. Носишься с ним как с писаной торбой:)
Никогда не подозревал, сколько матных слов я знаю, пока не открыл исходники от гореписак для битриха.
Так что да, интересно.
Так что да, интересно.
>Работать с чужим кодом безусловно высокое искусство, но это крайне крайне интересно.
А уж ЧСВ-то как поднимает ;)
«Ну блин, ну какой идиот это писал?? Надо же вот так, вот так и вот так. Эх, какой я все-таки умный, не зря мне деньги платят» :D
А уж ЧСВ-то как поднимает ;)
«Ну блин, ну какой идиот это писал?? Надо же вот так, вот так и вот так. Эх, какой я все-таки умный, не зря мне деньги платят» :D
Спасибо за статью! Перевел одну из статей по ссылке: Ущербно-ориентированное программирование.
Выбиваю технические долги. Дорого.
Знаю другой способ разрбатывать неподдерживаемый код. Философия Unix: «Делайте что-то одно, но делайте это хорошо». Кажется никому в голову не приходит «отладка, исправление, поддержка и расширение функциональности» diff или grep или echo. Они просто работают. Без поддержки.
Именно точно так. Работают сасем-сасем без поддержки. А тот факт, что новый diff вышел 24 марта (текущего года, разумеется), grep вышел 26 октября (то есть меньше месяца назад), а coreutils (куда, в частности, входит команда echo) 14 февраля (догадайтесь какого года с одной попытки) — это так, случайность, к делу отношения не имеющая.
Ах, да, echo же у нас ещё и в bash встроена. Не будем говорить на тему сочетаемости философии «делайте что-то одно, но делайте это хорошо» с программой, включающей в себя десятки команд, но вспомним-таки, что последняя версия bash'а тоже вышла в этом году — 7 марта, если быть точным.
Любая сколько-нибудь сложная программа требует поддержки. Даже если у вас в ней всё идеально её всегда можно «чуть-чуть отрефакторить» так, чтобы в ней появилась ошибка, которая стрельнет в каком-нибудь весьма экзотическом случае. Говорю как человек, совсем недавно участвовавший в исправлении подобной ошибки (проявляющейся, разумеется, только и исключительно на Windows8) в программе длиной 315 строк. Стоит ли говорить о том, что написана программа была задолго до выхода Windows 8?
Ах, да, echo же у нас ещё и в bash встроена. Не будем говорить на тему сочетаемости философии «делайте что-то одно, но делайте это хорошо» с программой, включающей в себя десятки команд, но вспомним-таки, что последняя версия bash'а тоже вышла в этом году — 7 марта, если быть точным.
Любая сколько-нибудь сложная программа требует поддержки. Даже если у вас в ней всё идеально её всегда можно «чуть-чуть отрефакторить» так, чтобы в ней появилась ошибка, которая стрельнет в каком-нибудь весьма экзотическом случае. Говорю как человек, совсем недавно участвовавший в исправлении подобной ошибки (проявляющейся, разумеется, только и исключительно на Windows8) в программе длиной 315 строк. Стоит ли говорить о том, что написана программа была задолго до выхода Windows 8?
bash~>uname -a
Darwin uvelichitels-MacBook-Pro.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
bash~>diff -v
diff (GNU diffutils) 2.8.1
Copyright © 2002 Free Software Foundation, Inc.
#По мне, ничего, работает.
Разве хорошая программа обязательно должна включать в себя десятки команд? Разве это делает программу лучше?
«Любая сколько-нибудь сложная программа требует поддержки.» Бесспорно. И чем меньше, тем лучше, на мой взгляд.
Darwin uvelichitels-MacBook-Pro.local 12.5.0 Darwin Kernel Version 12.5.0: Sun Sep 29 13:33:47 PDT 2013; root:xnu-2050.48.12~1/RELEASE_X86_64 x86_64
bash~>diff -v
diff (GNU diffutils) 2.8.1
Copyright © 2002 Free Software Foundation, Inc.
#По мне, ничего, работает.
Разве хорошая программа обязательно должна включать в себя десятки команд? Разве это делает программу лучше?
«Любая сколько-нибудь сложная программа требует поддержки.» Бесспорно. И чем меньше, тем лучше, на мой взгляд.
Поддержки не должно быть ни много, ни мало — ровно столько, чтобы программой можно было без проблем пользоваться. Но на практике оказывается что либо программа правится, либо обрастает набором костылей «снаружи»: глаза б мои не видели этих ваших «ничего, работает». Из-за вставшего в позу Apple'а, который не хочет обновлять системные утилиты приходится либо вставлять в программу кучу костылей, либо носить с собой половину GNU системы.
Собственно код, который обсуждается в статье обычно тоже «работает». Ну там, «за исключением пары мелочей»
Собственно код, который обсуждается в статье обычно тоже «работает». Ну там, «за исключением пары мелочей»
> а coreutils (куда, в частности, входит команда echo) 14 февраля (догадайтесь какого года с одной попытки) — это так, случайность, к делу отношения не имеющая.
Тем не менее, не могу не отметить, что несмотря на редкие изменения, в основном, это дерьмо динозавров окаменело десятки лет назад вместе с багами, безумными алгоритмами и прожорливыми аллокаторами.
Тем не менее, не могу не отметить, что несмотря на редкие изменения, в основном, это дерьмо динозавров окаменело десятки лет назад вместе с багами, безумными алгоритмами и прожорливыми аллокаторами.
Подход Unix приводит к поистине живучей системе — если у вас отвалится diff, то всё остальное продолжит работать.
На самом деле, занятие актуальное. Выросло уже целое поколение говнокодеров начинавших когда то программистов, которые уже набрались опыта и расселись по уютным местам а проекты на которых они учились за деньги заказчиков теперь начинают выплывать. И зачастую тот кто когда то наколбасил наваял в одной конторе теперь исправляет чужие шедевры в другой. По сути это круговорот где одни заложили заработок для других. И это правильно, т.к. скупой должен платить дважды. Съэкономил на спецах, связался с мальчиком «умельцем», будь готов в будующем заплатить за это второй раз. В конечном итоге виноват тот кто принимал решение с кем и как работать, теперь пусть платит если решение было не правильным. И мне их не очень то и жалко, т к. когда то они с довольным лицом мне объявляли «мы решили с вами не работать т.к. Вася Пупкин вызвался сделать это в 3 раза дешевле и быстрее». От спецов им всеравно не уйти, выйдет только это теперь дороже и особого выбора у них уже не будет, и поделом.
Почему же не уйти? Иная контора успевает закрыться раньше, чем у неё возникает потребность в настоящем спеце. А, если нет разницы, зачем платить больше? (с)
У меня сейчас ситуация. Клиент захотел «второй интернет». За 3 месяца разработки, бизнес его накрылся медным тазом и он погряз в долгах. Всё от умения планировать (пустить крупную рекламу о «крупнейшем сайте по зарубежной недвижимости», за 2 месяца до запуска альфа версии сайта) бюджет и сроки. Когда он понял, что бизнес в пролёте и решил его закрывать, увольняя народ пачками и отменяя аренду офиса в самом дорогом БЦ города. Мне была сказана фраза «Я дальше платить отказываюсь, сайт мне не нужен». Вот теперь иду в суд, буду пугать договором.
Зачем же закапывать себя в говнокоде? Закопайте «инициативного мальчика». Согласитесь с тем, что система мегагениальна, посыпьте себе голову песочком и скажите, что раз автор — это их гений, то, разумеется он сможет поддерживать свою систему лучше, чем вы.
Тут главное — продержаться пару месяцев и очень сочуственно кивать головой, когда это чудо будет тонуть — однако при этом всячески и категорически отвергать попытки свалить работу на вас под предлогом «ну тут же совсем чуть-чуть осталось» (отговорка железная: «да-да, осталось совсем чуть-чуть, так что ты уж поднпрягись, а я за пивом сгоняю — можно даже на свои деньги).
Главное — не переоценить себя и не спутать ситуацию, когда человек явно полез явно не в своё дело от ситуации, когда код, в общем, не так и плох, просто написан не совсем так, как вы привыкли. В первом случае — он утонет, фирма потерпит убытки, но вам-таки зарплату повысит, во-втором — можно и без работы остаться.
Тут главное — продержаться пару месяцев и очень сочуственно кивать головой, когда это чудо будет тонуть — однако при этом всячески и категорически отвергать попытки свалить работу на вас под предлогом «ну тут же совсем чуть-чуть осталось» (отговорка железная: «да-да, осталось совсем чуть-чуть, так что ты уж поднпрягись, а я за пивом сгоняю — можно даже на свои деньги).
Главное — не переоценить себя и не спутать ситуацию, когда человек явно полез явно не в своё дело от ситуации, когда код, в общем, не так и плох, просто написан не совсем так, как вы привыкли. В первом случае — он утонет, фирма потерпит убытки, но вам-таки зарплату повысит, во-втором — можно и без работы остаться.
Да просто надо жестко отстаивать свою позицию перед руководством. А то как это часто бывает — спустили разнорядку сверху, маленький босс взял под козырек и спустил всё вниз. Внизу побурлили да и стали делать как велено.
Кстати тот «человек из тех. отдела» проделал одну очень важную работу — выявил реальные требования «клиента». Пусть сделал говно, но оно делает почти все что нужно «клиенту». Т.е. сделал прототип. Обладая этими знаниями можно здорово ускорить переписывание с нуля.
Кстати тот «человек из тех. отдела» проделал одну очень важную работу — выявил реальные требования «клиента». Пусть сделал говно, но оно делает почти все что нужно «клиенту». Т.е. сделал прототип. Обладая этими знаниями можно здорово ускорить переписывание с нуля.
Выросло уже целое поколениеИ не одно поколение. И новые подрастают. Они неисчерпаемы.говнокодеровначинавших когда то программистов
Съэкономил на спецах, связался с мальчиком «умельцем», будь готов в будующем заплатить за это второй разК сожалению серьезный подрядчик в галстуке и с Макбуком тоже не гарантирует никакого качества. Если заказчик ничего не понимает в разработке ПО — нужна третья сторона. Независмый аудитор. А что, это интересная тема… пошел думать.
На моем опыте еще ни один менеджер серьезно не отнесся к тезису «я не могу это сделать быстро (качественно) потому, что там-то и там-то говнокод». Или «это надо переписывать, т.к. если это оставить так, то в последствии мы вообще умрем»Мы недавно в вопросах говнокода и технического долга стали применять следующую практику: если заказчик прессует по срокам, мы говорим, ОК, можно сделать быстрее, если того требует бизнес (читай закостылить). Но таким решением мы накапливаем такой-то технический долг в человеко-днях. Этот долг прописывается в ТЗ и заказчик это подписывает. В следующих итерациях у нас есть право этот долг истребовать.
Правда заказчик(менеджер по продукту) у нас внутренний, а РП(я) — бывший разработчик. Это видимо нечастая схема
Условно «написать абы как, а потом переписать по-нормальному» — это еще и увеличение трудозатрат. Условно, на 50%Условно так: сделать нормально — 100ч. Сделать костыль — 20ч + 100ч долга.
А как заказчик отнесется к увеличению себестоимости?У заказчика есть выбор — делаем сразу хорошо, в сумме дешевле, но конкретная фича появится позже. Делаем быстро — потом за это расплачиваемся.
Все зависит от приоритетов проекта. Если время — на деньги никто особо не смотрит, если деньги — готовы увеличивать сроки. Приоритеты конечно заказчик определяет.
Я бы сюда еще добавил следующие проблемы, которые могут возникнуть в будущем из за необдуманной разработки:
1) Патч чужих модулей. Например, патч модуля memc для nginx. При этом такой патченный модуль может не работать в новой версии nginx, а свежая версия модуля не подойдет т.к. исходный модуль был патченный.
2) Использование специальных структур конкретного языка (например serialize в php) так же может навредить проекту. Если потом возникнет желание прочесть эти структуры в другом языке, то придется искать для этого специальную библиотеку, которая не факт что будет работать идеально.
3) Использование nfs, симлинков, как мне кажется, так же делает код проекта более запутанным.
4) Использование экстенсивного пути развития проектов — использование большого количества серверов вместо оптимизации алгоритмов. Когда серверов много и между ними масса различных связей, поддержка такого проекта является нелегким делом.
5) Иногда при использовании сторонних хранилищ создаются бд, например для sphinx, но при этом конфигуация sphinx не ложится в свн и возможно даже не бэкапится и может быть утеряна при определенных обстоятельствах.
Что касается вставок на руби в пхп — я не совсем понимаю как это может помочь работе скрипта. А вот вставка на луа вполне логична при использовании eval в redis.
Так же не вижу ничего плохого в том чтобы писать админку на пхп, а внешнюю часть на другом языке, который лучше для этого подходит, например на луа.
Так же я придерживаюсь иной точки зрения по поводу nosql решений. Более того, я считаю что такие грузоемкие бд как mysql не должны быть вообще в продакшене. Их можно использовать для админки, но не для большого трафика. Возможно я просто не умею их настраивать, пользоваться временными таблицами и т.д.
1) Патч чужих модулей. Например, патч модуля memc для nginx. При этом такой патченный модуль может не работать в новой версии nginx, а свежая версия модуля не подойдет т.к. исходный модуль был патченный.
2) Использование специальных структур конкретного языка (например serialize в php) так же может навредить проекту. Если потом возникнет желание прочесть эти структуры в другом языке, то придется искать для этого специальную библиотеку, которая не факт что будет работать идеально.
3) Использование nfs, симлинков, как мне кажется, так же делает код проекта более запутанным.
4) Использование экстенсивного пути развития проектов — использование большого количества серверов вместо оптимизации алгоритмов. Когда серверов много и между ними масса различных связей, поддержка такого проекта является нелегким делом.
5) Иногда при использовании сторонних хранилищ создаются бд, например для sphinx, но при этом конфигуация sphinx не ложится в свн и возможно даже не бэкапится и может быть утеряна при определенных обстоятельствах.
Что касается вставок на руби в пхп — я не совсем понимаю как это может помочь работе скрипта. А вот вставка на луа вполне логична при использовании eval в redis.
Так же не вижу ничего плохого в том чтобы писать админку на пхп, а внешнюю часть на другом языке, который лучше для этого подходит, например на луа.
Так же я придерживаюсь иной точки зрения по поводу nosql решений. Более того, я считаю что такие грузоемкие бд как mysql не должны быть вообще в продакшене. Их можно использовать для админки, но не для большого трафика. Возможно я просто не умею их настраивать, пользоваться временными таблицами и т.д.
Что касается вставок на руби в пхп — я не совсем понимаю как это может помочь работе скрипта.
Я встречал вставки в php, ассемблеровского кода. Правда там форма клеила 2 ЕХЕ файла в один. Но всё же. :-)
MySQL оптимизировать не хотите, а алгоритмы оптимизировать хотите (а все мы знаем, что это за алгоритмы такие — по крону кеш разогреть и без этого кеша не дать работать приложению, использовать хитрые технологические решения, требующие тонкой настройки). Раскидывать по серверам (читай, использовать сервисы) не хотите, потому что это неудобно, а писать на несколькоих языках (превед, развёртывание системы локально) хотите, потому что это почему-то удобно.
Оптимизировать на единственной машине есть смысл в том случае, если это даёт прирост в разы. Гораздо проще и дешевле поставить ещё пару серверов (месячная аренда одного сервера обойдётся в дневную зарплату программиста). Опять же, не всегда, но чаще всего.
В любом случае писать нужно изначально так, чтобы в случае чего можно было разнести по разным серверам.
Оптимизировать на единственной машине есть смысл в том случае, если это даёт прирост в разы. Гораздо проще и дешевле поставить ещё пару серверов (месячная аренда одного сервера обойдётся в дневную зарплату программиста). Опять же, не всегда, но чаще всего.
В любом случае писать нужно изначально так, чтобы в случае чего можно было разнести по разным серверам.
В любом случае писать нужно изначально так, чтобы в случае чего можно было разнести по разным серверам.
На одном сервере это может привести к падению производительности.
Я с этим согласен. Я хотел сказать, что если есть возможность оптимизировать скрипты и использовать меньше серверов (не обязательно один), то лучше использовать меньше серверов, даже если проект финансово окупает большее количество железа.
>>MySQL оптимизировать не хотите, а алгоритмы оптимизировать хотите (а все мы знаем, что это за алгоритмы такие — по крону кеш разогреть и без этого кеша не дать работать приложению, использовать хитрые технологические решения, требующие тонкой настройки).
Я использую редис как основную бд во многих проектах. И речь не идет о банальном кешировании KEY=VALUE, в редисе есть масса интересных структур — sorted set, set, возможность использовать встроенный язык луа и т.д. Работает он при этом очень быстро. Но чтобы использовать подобные структуры нужно изначально ориентировать алгоритмы работы на них.
>>MySQL оптимизировать не хотите, а алгоритмы оптимизировать хотите (а все мы знаем, что это за алгоритмы такие — по крону кеш разогреть и без этого кеша не дать работать приложению, использовать хитрые технологические решения, требующие тонкой настройки).
Я использую редис как основную бд во многих проектах. И речь не идет о банальном кешировании KEY=VALUE, в редисе есть масса интересных структур — sorted set, set, возможность использовать встроенный язык луа и т.д. Работает он при этом очень быстро. Но чтобы использовать подобные структуры нужно изначально ориентировать алгоритмы работы на них.
Создавайте максимально сложную систему сборки и развертыванияВ OpenSource такое к сожалению сплошь и рядом. Когда над сборкой проекта приходится камлать больше суток, потому что скрипты сборки, оказывается, требуют наличия Perl определённой версии, Python (2.x, и только 32bit, под 64 не соберётся), Ruby с определённым набором gem'ов, плюс активно используются bash и make. И всё это одновременно!
Интересно, они встречают такое?
> Используйте кучу разных языков программирования и оставайтесь ультрасовременными
Куча разных ЯП не нужны. Достаточно одного Common Lisp, который не более ультрасовременен, чем Python. ;)
Куча разных ЯП не нужны. Достаточно одного Common Lisp, который не более ультрасовременен, чем Python. ;)
Вот тут уже вообще непонятная мешанина из реальных советов и сарказма. Вероятно, дело в переводе.
Добавляйте зависимости от определенных версий библиотек и ресурсов
По-моему это хорошая практика. У нас (в python) зависимости обычно выглядят как-то так:
Flask==0.10.1 Jinja2==2.7.1 MarkupSafe==0.18
Такой подход позволяет уберечься от потенциальных проблем при деплое в продакшен, когда обновление внешнего пакета рушит ранее работающую систему. Замечу, что такой подход конечно же не подходит для разработки библиотек.
В этом плане мне очень нравится современный подход в bundler (ruby):
— gem'ы (единицы пакетного менеджера, библиотеки в частности) зависят нестрого (всякие >=, ~>), в репозиторий не включается информация о конкретных версиях библиотек.
— приложения зависят от фиксированных версий библиотек (естественно, с учётом зависимостей в библиотеках), что гарантирует ту же среду на боевом сервере, как и среда разработки. Обновление версий библиотек и их зависимостей в таком случае делается вручную (через
— gem'ы (единицы пакетного менеджера, библиотеки в частности) зависят нестрого (всякие >=, ~>), в репозиторий не включается информация о конкретных версиях библиотек.
— приложения зависят от фиксированных версий библиотек (естественно, с учётом зависимостей в библиотеках), что гарантирует ту же среду на боевом сервере, как и среда разработки. Обновление версий библиотек и их зависимостей в таком случае делается вручную (через
bundle update), не давая сторонним библиотекам «случайно» поломать код. Особенно это актуально, если библиотека молодая и API ещё не устаканилось.При условии наличия файла requirements.txt
Разворачивал один проект. Долго с одной зависимостью воевал. Кое как выяснилось, что дело в сабмодуле, который только в ветке бэта тестирования лежит у разработчиков. И тянется на прямую с гитхаба.
Разворачивал один проект. Долго с одной зависимостью воевал. Кое как выяснилось, что дело в сабмодуле, который только в ветке бэта тестирования лежит у разработчиков. И тянется на прямую с гитхаба.
Читать нужно как «Добавляйте зависимости от определенных версий библиотек и ресурсов, но нигде их явно не объявляйте — все и так должны догадываться».
Советы «Пишите все с нуля» и «Добавляйте столько стороннего кода, сколько можете» выглядят противоречащими друг другу. Интересно, какой из них более эффективен.
Почему «выглядят»? Они действительно противоречат друг другу. А насчёт эффективности: мы по какому критерию оптимизируем вообще? Первый подход экономит ресурсы компьютера, второй — ресурсы программиста. Потому в разовой системе, которая создаётся под одну-единственную выставку «своего» и через неделю после запуска умрёт «своего» кода должно быть как можно меньше, а в системе, которую мы собираемся запускать на Юпитер и поддерживать десятилетиями без возможности upgrade железа — наоборот. Ну а большинство проектов живут где-то посередине.
Оптимизируем по критерию, указанному в заголовке — «Как разрабатывать неподдерживаемое ПО». Судя по фразе «Ниже несколько практик, которым вам надо следовать в своих проектах, чтобы не оставить меня без работы», неподдерживаемость является именно целью, а не условием «поддержка ПО не предполагается, можете сосредоточиться на других приоритетах».
Противоречие между советами можно и обойти. Например, написать алгоритмическую часть с нуля, а GUI — исключительно внешними библиотеками, причём самыми экзотическими. Или наоборот, GUI — на голом WinAPI (или как оно называется?), а алгоритмы — с применением кучи библиотек и пары движков символьных вычислений.
Противоречие между советами можно и обойти. Например, написать алгоритмическую часть с нуля, а GUI — исключительно внешними библиотеками, причём самыми экзотическими. Или наоборот, GUI — на голом WinAPI (или как оно называется?), а алгоритмы — с применением кучи библиотек и пары движков символьных вычислений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как разрабатывать неподдерживаемое ПО