Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 248
годы должны пройти для понимания этого.
Вдохновляет.
Недавно пришёл к мысли: многие начинающие программисты воспринимают программирование как творчество. А нужо воспринимать как инструмент. Вырезать с корнем свой перфекционизм и просто решать поставленную задачу.
Вы правы, но абсолютно везде нужно чувство меры.
Конечно. Добиваться цели, но без фанатизма. Не нужно бросаться в крайности и писать работающий абы-какой код, нужно и думать о подержке с масштабированием, но и что-то очень универсальное долго и упорно городить тоже не стоит. Просто я столкнулся уже с парой проектов, где в погоне за улучшением сроки превысили выносливость разработчиков и релиз так и не наступил.
Считаю что «опытность» разработчика заключается в умении чувствовать и соблюдать баланс между «работает» и масштабированием. Нормальный IT менеджер должен ещё уметь дать зелёнкам его(баланс) почувствовать. Собственно отсюда и проблема человека из первой исповеди — все ему толкуют «делай проще», а «что такое полюс и с чем его едят» (с) А. Милн. никто сказать не может.
А останется ли радость от работы после такого изменения?
А почему нет?
«Я решил задачу — я молодец» все равно будет работать. Удовлетворение от решения проблемы то остается.
«Я решил задачу — я молодец» все равно будет работать. Удовлетворение от решения проблемы то остается.
Вы любите свою работу только за то, что способны ее выполнить?
Я люблю свою работу за то что могу сделать, что создаю и да, то что могу решить вопрос. )
Я не говорила будто считаю программирование лишенным творческого подхода, просто у меня для самовыражение есть хобби. )
Я не говорила будто считаю программирование лишенным творческого подхода, просто у меня для самовыражение есть хобби. )
Дык комментарий выше имхо не об этом говорит. Человек любит эффективно решать поставленные задачи, а не процесс их решения ради самого процесса. И статья именно об этом!
Лично я воспринимаю разработку в первую очередь — как творческую область. Решить проблему можно уймой способов, в том числе скучных и быстрых. Но от такого решения и радости меньше. А вот решить красиво, это уже надо уметь.
Понимаете «красиво» для всех по разному. Каждый вкладывает свой смысл, но значение по сути не меняется. Я тоже люблю красиво решать вопрос.
Мне нравится делать что-то хорошо сразу, но всегда в будущем (или даже сейчас) найдется другое решение лучшее и красивее. И если находится этот способ я перепишу код и буду довольна, но выше уже было сказано о чувстве меры. Ибо код можно править бесконечно. У меня нет той степени перфекционизма о которой говорят сейчас в комментариях) Но я понимаю о чем речь и чувства. Перфекицонизм во мне просыпается в хобби, где никогда и ничто не будет достаточно хорошо, красиво или идеально.
Здесь вообще нельзя спорить, вмешиваются разные взгляды, вкусы, предпочтения, условия.
Мне нравится делать что-то хорошо сразу, но всегда в будущем (или даже сейчас) найдется другое решение лучшее и красивее. И если находится этот способ я перепишу код и буду довольна, но выше уже было сказано о чувстве меры. Ибо код можно править бесконечно. У меня нет той степени перфекционизма о которой говорят сейчас в комментариях) Но я понимаю о чем речь и чувства. Перфекицонизм во мне просыпается в хобби, где никогда и ничто не будет достаточно хорошо, красиво или идеально.
Здесь вообще нельзя спорить, вмешиваются разные взгляды, вкусы, предпочтения, условия.
Мне вот непонятно, почему во всей статье и многих комментариях перфекционизм воспринимается как что-то непригодное для коммерческой разработки… До определённого уровня он не только пригоден, но ещё и полезен!
Ну вот простой пример:
— пришёл заказчик и говорит хотим такую-то фичу (сохранять некоторые параметры в куки и встраивать эти параметры в ифрейм) — ок, пользуемся уже существующим инструментарием + досыпаем чуть-чуть программной логики — первый вариант перфекционизма (не добавлять лишней сущности).
— приходит заказчик снова, говорит, нужна определённая бизнес-логика и вообще есть несколько разных списков параметров, за раз должен применяться один. Ок, оцениваем — дополнять старый функционал будет костылищем, вырезаем старый код, делаем аккуратный отдельный модуль-фильтр, прописываем обратную совместимость (чтобы после релиза ничего не сломать). Опять перфекционизм — поддерживаемость + наглядность + изоляция отдельного кода.
PS да — заказчик уже несколько раз приходил с изменениями в реализуемой бизнес-логике и вовремя выполненный рефакторинг на втором раунде серьёзно сэкономил сил, нервов и времени.
Ну вот простой пример:
— пришёл заказчик и говорит хотим такую-то фичу (сохранять некоторые параметры в куки и встраивать эти параметры в ифрейм) — ок, пользуемся уже существующим инструментарием + досыпаем чуть-чуть программной логики — первый вариант перфекционизма (не добавлять лишней сущности).
— приходит заказчик снова, говорит, нужна определённая бизнес-логика и вообще есть несколько разных списков параметров, за раз должен применяться один. Ок, оцениваем — дополнять старый функционал будет костылищем, вырезаем старый код, делаем аккуратный отдельный модуль-фильтр, прописываем обратную совместимость (чтобы после релиза ничего не сломать). Опять перфекционизм — поддерживаемость + наглядность + изоляция отдельного кода.
PS да — заказчик уже несколько раз приходил с изменениями в реализуемой бизнес-логике и вовремя выполненный рефакторинг на втором раунде серьёзно сэкономил сил, нервов и времени.
Спорный вопрос, потому что каждому — своё.
Мне вот в кайф сам факт решения задачи. Пользователю придётся делать меньше кликов? Он сможет в два вопроса мастера решить то, что раньше решал 3мя звонками по телефону и стоянием в очередь? Ему теперь приходит напоминалка в виде СМС и push-а, он не проспит нужное событие? Проблема пользователя решена — я удовлетворён, я сделал полезную работу. Уменьшил энтропию, упростил кому-то жизнь. И всегда, при любой разработке, выбирая между «упростить жизнь себе» и «упростить жизнь пользователю моей разработки» я постараюсь выбрать второй вариант. Подчеркну, постараюсь — всё-таки заказчиком обычно выступает не будущий пользователь, а третье лицо, и требуется соблюдать баланс.
А вот сам код — он инструмент. Инструмент упрощения, улучшения жизни. Мне доставляет удовольствие сам процесс написания кода (иначе бы процесс программирования был бы пыткой), но он, блин, не самоцель. По этой же причине я люблю рефакторинг, который уменьшит количества кода или упростит его поддержку, но люто не люблю рефакторинг с предпосылками «это некрасиво», «это не по фэншую/не по канонам» и.т.п.
Мне вот в кайф сам факт решения задачи. Пользователю придётся делать меньше кликов? Он сможет в два вопроса мастера решить то, что раньше решал 3мя звонками по телефону и стоянием в очередь? Ему теперь приходит напоминалка в виде СМС и push-а, он не проспит нужное событие? Проблема пользователя решена — я удовлетворён, я сделал полезную работу. Уменьшил энтропию, упростил кому-то жизнь. И всегда, при любой разработке, выбирая между «упростить жизнь себе» и «упростить жизнь пользователю моей разработки» я постараюсь выбрать второй вариант. Подчеркну, постараюсь — всё-таки заказчиком обычно выступает не будущий пользователь, а третье лицо, и требуется соблюдать баланс.
А вот сам код — он инструмент. Инструмент упрощения, улучшения жизни. Мне доставляет удовольствие сам процесс написания кода (иначе бы процесс программирования был бы пыткой), но он, блин, не самоцель. По этой же причине я люблю рефакторинг, который уменьшит количества кода или упростит его поддержку, но люто не люблю рефакторинг с предпосылками «это некрасиво», «это не по фэншую/не по канонам» и.т.п.
я люблю рефакторинг, который уменьшит количества кода или упростит его поддержку, но люто не люблю рефакторинг с предпосылками «это некрасиво»
Красивый код — это и есть простой код, в котором нет ничего лишнего.
Встаёт вопрос — считать ли «лишним» «задел на будущее»?
Я для себя выработал какую-то такую стратегию: если я точно знаю, что это в будущем понадобится, то оставляю определенный запас. Если же: «ну, может быть, по идее пригодится», то делать максимально адаптированно под текущую ситуацию. Бизнес-требования меняются очень быстро и с большим разбросом, поэтому тратить лишнее время сейчас смысла нет.
А вообще, со временем все больше полагаешься на интуицию — вот этот участок кода захардкодим, потому что менять его не придется, а вот здесь можно слегка добавить абстракций. Видимо, это и есть опыт, который надо нарабатывать только практикой.
Так что, красота кода в отрыве от контекста не значит, на мой взгляд, ничего. А даже в контексте, если убрать случаи явного говнокода, всё это очень субъективно.
А вообще, со временем все больше полагаешься на интуицию — вот этот участок кода захардкодим, потому что менять его не придется, а вот здесь можно слегка добавить абстракций. Видимо, это и есть опыт, который надо нарабатывать только практикой.
Так что, красота кода в отрыве от контекста не значит, на мой взгляд, ничего. А даже в контексте, если убрать случаи явного говнокода, всё это очень субъективно.
нет, пока он не содержит кода.
А зачем только программированием ограничиваться? Давайте считать, что вообще ни в какой профессии нет места творчеству. Вам хочется писать офигенную музыку? А ну быстро вырезайте с корнем свой перфекционизм! Народу нужна качественная и понятная попсятина, а не ваши потуги на самовыражение!
Если у вас контракт на такую музыка, садитесь и пишите. Если это творчество для себя, то можете самовыражаться с перфекционизмом.
Ну зачем же перегибать палку. Если музыка нужна для зароботка — пишите попсу. Если для души и узкого круга ллюбителей — пишите своё. В кино сейчас всё точно так и обстоит. Вон, Zach Braff снимает художественные произведения, а кто-то клепает тех же трансформеров зарабатывает неплохие деньги. Всё зависит от цели.
Я считаю, что призыв выкорчевать с корнем свой перфекционизм — это и есть «перегибать палку». В процессе эволюции у человека не просто так появилось чувство прекрасного. Красота и эффективность всегда связаны друг с другом. В комментариях ниже уже рассказывают о проблемах, возникающих, когда всё делают по принципу «лишь бы как-то работало».
В процессе эволюции у человека не просто так появилось чувство прекрасного.Красивая теория, а мне кажется, что эволюция выработала чувство неудовлетворенности текущим положением. И потому если не унять своего перфекциониста — никогда не сможешь чувствовать себя хорошо здесь и сейчас, т.к. все время придется бежать к лучшему.
Лучшее — враг хорошего (с) М. Джиованни
А почему нельзя для зароботка писать хорошую музыку? Тот же вопрос и про кино.
Почему же нельзя, можно. Но зачастую не получается.
Я бы сказал что дело не в «не получается», а в «нет желания».
Я бы сформулировал как «недостаток упорства», а не желания… Для видео — есть Youtube, и там некоторые реально зарабатывают. С музыкой — тоже наверняка тоже есть. Даже просто играя в компьютерные игры можно заработать — тот же Youtube, или же Twitch…
Дело не в «нет желания», а в «нет спроса». Нет спроса — нет денег (заработка). Не верите? Посмотрите, где в чартах хорошие инструментальные группы, и где «тынца-шмынца-муси-пуси».
Вершина чартов — однодневки, которых раздули талантливые продюсеры и (если речь идет о музыке) отличные звукорежиссеры.
В творчестве «хороших» (читай — истинно талантливых) исполнителей главная ценность — преданность аудитории. Если какая-нибудь «Птичка-Певичка» завтра пропадет и перестанет петь, то о ней через неделю никто даже не вспомнит. И то, что вчера ее крутили по всем радиостанциям (кроме «Серебряного Дождя»), ей никак не поможет. А вот предствьте себе, сколько должно пройти лет, чтобы забыли Кортнева, Макаревича, Шевчука.
И, хоть вышеперечисленные господа и не блистают «в топе», интегрально, за годы, они заработали существенно больше. И, в том числе, благодарных слушателей. Так что, «не стоит прогибаться под изменчивый мир». Писать и петь надо то, что умеешь и хочешь. Если, конечно, хоть что-то действительно умеешь.
В творчестве «хороших» (читай — истинно талантливых) исполнителей главная ценность — преданность аудитории. Если какая-нибудь «Птичка-Певичка» завтра пропадет и перестанет петь, то о ней через неделю никто даже не вспомнит. И то, что вчера ее крутили по всем радиостанциям (кроме «Серебряного Дождя»), ей никак не поможет. А вот предствьте себе, сколько должно пройти лет, чтобы забыли Кортнева, Макаревича, Шевчука.
И, хоть вышеперечисленные господа и не блистают «в топе», интегрально, за годы, они заработали существенно больше. И, в том числе, благодарных слушателей. Так что, «не стоит прогибаться под изменчивый мир». Писать и петь надо то, что умеешь и хочешь. Если, конечно, хоть что-то действительно умеешь.
А кто такой Кортнев?
Автор песен и солист группы "Несчастный Случай". Кроме того, близкий друг творческого коллектива «Квартет И» и соавтор их спектаклей.
Вот вам песенка хорошая.
Вот вам песенка хорошая.
вы удивитесь, но в музыке очень мало творчества, и очень много рутины. Мы видим выступление артиста на сцене (либо слушаем запись из студии), но под этим скрывается очень, очень много рутинной, скучной, малоинтересной работы.
Как раз из разряда целей: сыграть данный кусок в заданном темпе, воспроизвести стилистику, и т. д.
И музыканту перфекционизм тоже вреден: можно довести исполнение пары мелодий до совершенства, но такой музыкант мало кому нужен, нужен музыкант с широким репертуаром.
Как раз из разряда целей: сыграть данный кусок в заданном темпе, воспроизвести стилистику, и т. д.
И музыканту перфекционизм тоже вреден: можно довести исполнение пары мелодий до совершенства, но такой музыкант мало кому нужен, нужен музыкант с широким репертуаром.
Мне кажется, чтоб качественно использовать программирование как инструмент, нужно сначала овладеть программированием как творчеством.
Ах как было бы здорово жить в мире, в котором вы правы. В том, в который мы с вами по недоразумению попали, к сожалению, наибольшего успеха достигают зануды-трудоголики, которые не прилагают душевных усилий, а просто «херачат код». На десятерых таких приходится один «фантазер», который хоть что-то сочиняет сам. И больше миру обычно не надо.
Как бы мне — и, судя по всему, вам — не хотелось, но, на современном этапе развития человечества, разработка ПО это именно творчество.
Это напрямую следует как из того уровня формализации (как процесса, так и целей), который на данный момент принят в этой области. Так и из того уровня решений, которые вынуждены самостоятельно принимать даже «начинающие программисты».
Это напрямую следует как из того уровня формализации (как процесса, так и целей), который на данный момент принят в этой области. Так и из того уровня решений, которые вынуждены самостоятельно принимать даже «начинающие программисты».
Угу, а потом начинается, проект А использующий либу хочет доп функционал, она появился в новой версии апи стороннего сервера, надо обновить апи, следовательно при обновлении либы провести регресс тесты всех работающих проектов. А потом выяснится что в старом апи был депрекейтед метод который как раз юзается в проекте В. Много раз такое видел. И по хорошему получается что либа уже поддерживает разные версии апи, настраивается снаружи и превратилась в маленького монстрика. Так что не везде в данный момент совпадающий код является общим.
Я из своей практики вижу, что почти никогда нет возможности сказать заранее: оно маленькое или оно будет расти.
Но практически проблема не с говнокодом. В самом говнокоде нет ничего особо плохого. Проблемы начинается когда люди начинают бояться его выкинуть и заменить на что-то более удобоваримое.
И вот тут — как раз важен опыт: нужно осознать что да, «пора уже это выкинуть и переписать» до того, как этот компонент разрастётся настолько, что переписывание станет невозможным.
Но практически проблема не с говнокодом. В самом говнокоде нет ничего особо плохого. Проблемы начинается когда люди начинают бояться его выкинуть и заменить на что-то более удобоваримое.
И вот тут — как раз важен опыт: нужно осознать что да, «пора уже это выкинуть и переписать» до того, как этот компонент разрастётся настолько, что переписывание станет невозможным.
Если приложение кому-то нужно, то оно развивается =)
Интересный посыл про удобство. Мне удобно писать и читать длинные строки, а кто-то каждый поганый SQL запрос SELECT-FROM-WHERE на три строки разбивает потому что у него парсер слабый. А мне наоборот неудобно в голове строки собирать — мне нравится на весь поток смотреть, а не на его куски.
Но это всё вопросы стиля кодирования, конечно, а не качества собственно кода.
Но это всё вопросы стиля кодирования, конечно, а не качества собственно кода.
Чтобы его выкинуть, надо сначала понять как он работает, чтобы не задеть поведение использующих его частей, в которых уже возможно тоже заковнокожены костыли, ожидающие костыльного поведения. Понять говнокод — половина беда. Понять его правильно со всеми нюансами костылей, когда git log выглядит как череда из коммитов с локоничным сообщением «fix» или «fix of a last fix» — вообще невозможно. А если при этом «опытные разработчики» еще и на тесты забили, потому что «нет времени, надо пилить фичи», то даже пытаться практически бесполезно.
Соль в том, что обычно разбор говнокода предстоит не тому, кто поленился навести красоту.
Тут скорее просто стремление к техническому совершенству должно быть коммерчески обосновано. Если у участников есть понимание, что совершенство кода позволит в будущем заработать больше денег (создать более сложный проект и т.п.) — то конечно можно совершенствовать код до бесконечности. Но иногда дешевле просто выкинуть полностью код 8-ли летней давности и написать новый (возможно даже на какой-то новой платформе).
Пример из реальной жизни — когда я пришел в одну компанию, у них были реализованы порядка 20 совместно работающих сайтов на общих библиотеках и темплейтах (classic asp еще). Казалось бы — все это хорошо и здорово! А потом оказалось, что чуть ли не в каждом из этих сайтов версии этих библиотек разные. И простое обновление до последней — запросто роняло сайт. И это был мини-филиал ада — пытаться что-то править там — так как правка одной из библиотек тянула за собой необходимость проверять, не ломают ли эти правки что-то еще во всех остальных сайтах, где она используется. Так что выносить в библиотеки код, хоть и обычно правильно, но надо делать это надо осмотрительно.
Этот подход обычно не работает, потому что когда программист С берет библиотеку, он обнаруживает, что она делает примерно то, что надо, но не совсем. Вопрос, как расширить функционал? Есть известные принципы для расширения функционала, но их можно применить только тогда, когда исходная библиотека предполагает именно такое расширение. Т.е. программист А должен был заранее предусмотреть не только требования к своему проекту, но и требования, которые в будущем возникнут у программиста С. А также у всех остальных программистов D, E, F, для которых и пишется эта библиотека. На практике это хорошо работает только для малого числа функций, которые очень далеки от прикладных задач.
Что за «прикладные задачи»? Это я вспомнил книгу «Мифический человеко-месяц». Там упоминалось, что задачи можно разделить на «прикладные» и «системные». Если с «системными» все более-менее хорошо и однозначно, то в «прикладных» все очень зыбко и подвержено изменениям, в результате стоимость работ по «прикладным» задачам оказывается в разы выше.
Что за «прикладные задачи»? Это я вспомнил книгу «Мифический человеко-месяц». Там упоминалось, что задачи можно разделить на «прикладные» и «системные». Если с «системными» все более-менее хорошо и однозначно, то в «прикладных» все очень зыбко и подвержено изменениям, в результате стоимость работ по «прикладным» задачам оказывается в разы выше.
Может быть совершенный код и получается тогда, когда идет постоянное противоборство программиста перфекциониста, который все хочет сделать хорошо, а значит долго, и менеджера, которому главное решить быстро задачу и получить профит. В споре рождается истина.
Не является ли такой подход тормозом в профессиональном развитии? Если я, условно говоря, умею клепать сайты по шаблонам, 100% времени занят этим, плюс подгоняю все задачи под моё эффективое умение клепать. Велика вероятность, что я так и останусь на этом уровне, и через пару лет мои навыки и понимание коммерческих следствий своих решений будут стоить дешевле чем грязь.
Имхо, перфекционизм и тяга к прекрасному строго обязательны в школьные и университетские годы, когда человек программирует для себя.
Более того, они обязательны в начале карьеры, если приходится работать в левой непрофильной конторе с маленькой зарплатой. Многих такие условия демотивируют, однако это отличный шанс как следует освоить новые направления и выработать стиль без особой ответственности за сорванные сроки.
Более того, они обязательны в начале карьеры, если приходится работать в левой непрофильной конторе с маленькой зарплатой. Многих такие условия демотивируют, однако это отличный шанс как следует освоить новые направления и выработать стиль без особой ответственности за сорванные сроки.
Еще в школе на факультете по программированию до нас, детей, пытались донести мысль: «Профессиональное программирование не является искусством, оно — ремесло. Профессиональные программисты создают продукты на продажу. Только программирование как хобби может быть искусством.»
Понимание этого пришло только с годами. Да и то не полностью еще.
Понимание этого пришло только с годами. Да и то не полностью еще.
Поэтому программирование как хобби необходимо для того, чтоб писать хорошие программы не продажу.
И тем не менее программирование является исскуством. Многие из картин висящих сейчас в музеях тоже писались по заказу и на продажу. И почему хобби не может совпадать с работой?
А вообще, программирование как ремесло — это давняя мечта всех менеджеров, подразумевается что средний человек после стандартного курса обучения должен быть способен выпускать с заданной скоростью стандартные модули, из которых можно комбинировать различные стандартные программы. Так ведь не получается же! Компании которые наиболее последовательно шли по этому пути сейчас тратят до 60% ресурсов на исправление первичных и вторичных багов.
Статья-то абсолютно правильная, только написана она умеренным перфекционистом для вразумления крайних перфекционистов и перфекционистами же в основном обсуждается. Неужели никто никогда не сталкивался с кодом, написанным изначально ремеслинниками и ими же поддерживаемыми?
В обшем, основная мысль — должен быть баланс, крайности ведут в адь.
А вообще, программирование как ремесло — это давняя мечта всех менеджеров, подразумевается что средний человек после стандартного курса обучения должен быть способен выпускать с заданной скоростью стандартные модули, из которых можно комбинировать различные стандартные программы. Так ведь не получается же! Компании которые наиболее последовательно шли по этому пути сейчас тратят до 60% ресурсов на исправление первичных и вторичных багов.
Статья-то абсолютно правильная, только написана она умеренным перфекционистом для вразумления крайних перфекционистов и перфекционистами же в основном обсуждается. Неужели никто никогда не сталкивался с кодом, написанным изначально ремеслинниками и ими же поддерживаемыми?
В обшем, основная мысль — должен быть баланс, крайности ведут в адь.
Ваше сравнение с картинами — это, к сожалению, признак вашего невежества и непонимания, что такое искусство, и чем оно отличается от ремесла.
Дело в том, что картины на заказ писались не по техническим заданиям. Они полностью строились по желанию автора. Заказчик не мог сказать «вот тут мне не нравится перо на шляпе, переделайте» и уж тем более «поиграйтесь с цветом».
Стоимость работ, соответственно, не кореллировала с реальной сложностью, и уж тем более с художественной ценностью результата. (Про художественную ценность программного обеспечения самого по себе мне даже как-то говорить странно.) Никак не связан гонорар автора (а не заработок!) и та цена, по которой эту картину вчера продали на аукционе.
Это уже потом, с появлением массового производства, появилась идея, что чтобы результат массового производства продать массам, нужно, чтобы он соответствовал определённым требованиям. И эти требования начали выдвигать исполнителю. И это уже ремесло.
Как-то была «двухсерийная» лекция Андрея Кончаловского про искусство. Он аргументирует позицию в том числе историческими фактами. Если хотите спорить — сначала посмотрите. Если хотите спорить с ним — ну, поздравляю, попробуйте создать хотя бы одно произведение искусства, которое действительно кто-то вменяемый воспримет как произведение искусства, потом пересмотрите ещё раз. Не знаю, какой он там режиссёр, но искусствовед — удивительно грамотный и адекватный.
Дело в том, что картины на заказ писались не по техническим заданиям. Они полностью строились по желанию автора. Заказчик не мог сказать «вот тут мне не нравится перо на шляпе, переделайте» и уж тем более «поиграйтесь с цветом».
Стоимость работ, соответственно, не кореллировала с реальной сложностью, и уж тем более с художественной ценностью результата. (Про художественную ценность программного обеспечения самого по себе мне даже как-то говорить странно.) Никак не связан гонорар автора (а не заработок!) и та цена, по которой эту картину вчера продали на аукционе.
Это уже потом, с появлением массового производства, появилась идея, что чтобы результат массового производства продать массам, нужно, чтобы он соответствовал определённым требованиям. И эти требования начали выдвигать исполнителю. И это уже ремесло.
Как-то была «двухсерийная» лекция Андрея Кончаловского про искусство. Он аргументирует позицию в том числе историческими фактами. Если хотите спорить — сначала посмотрите. Если хотите спорить с ним — ну, поздравляю, попробуйте создать хотя бы одно произведение искусства, которое действительно кто-то вменяемый воспримет как произведение искусства, потом пересмотрите ещё раз. Не знаю, какой он там режиссёр, но искусствовед — удивительно грамотный и адекватный.
Сначала мне нравился ваш комментарий, а потом вы использовали неубедительное «сперва добейся». Это я так, о спорах.
В данном случае, это «сперва попробуй». И "… которое воспримет" — чтобы не было картины, написанной хвостом осла, которую выдают за искусство. Не любая мазня — живопись.
Да, искусство — штука сложная. Одновременно и тонкая, и толстая.
Взять хотя бы фонтан Дюшана.
Вы тоже ознакомьтесь с теми лекциями Кончаловского. Он даёт вполне адекватное, хотя и субъективное, определение искусства, и вряд ли кто-то, руководствуясь этим определением, назовёт искусством этот фонтан. (Субъективизм заключается в том, что определение позволяет решить, является ли это искусством для меня, субъекта, который хочет выработать это решение.)
Вот, видите, вы сами согласны с тем, что всё субъективно. Я тоже согласен с тем, что всё субъективно.
А ещё я согласен с предыдущим комментатором в том, что во всём должен быть баланс. Совершенно утилитарные вещи могут содержать в себе творческие элементы, а творчество часто вырождается в рутинную работу.
А ещё я согласен с предыдущим комментатором в том, что во всём должен быть баланс. Совершенно утилитарные вещи могут содержать в себе творческие элементы, а творчество часто вырождается в рутинную работу.
Смотрю я на этот фонтан, потом на некоторый код, потом снова на фонтан… и понимаю, программирование это искусство.
Роберта Мартина на вас нет.
Так как был и программистом и руководителем, смог посмотреть на эту проблему с двух сторон. Всё правильно: проще и быстрее — это хорошо, важен результат. Пока не встаёт вопрос поддержки. Ещё веселее, если поддержки другими программистами. Потери человеко-часов на некогда написанном по-быстрому отбивают желание торопить программистов.
Серьёзно? А где вы берёте время на переписывание продукта с нуля? Особенно, если требования к нему растут взрывообразно?
Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
Серьёзно? А где вы берёте время на переписывание продукта с нуля? Особенно, если требования к нему растут взрывообразно?
Никогда не угадаешь, какие появятся требования и какой проект неожиданно загнётся.
Стоит выбирать, жить в сегодняшнем дне или в гипотетическом завтрашнем.
Стоит выбирать, жить в сегодняшнем дне или в гипотетическом завтрашнем.
Чтобы понадобилась поддержка нужно, для начала, чтобы продукт вообще появился и «взлетел».
Вспоминается «пример про Петю и Васю»
Если же будущее продукта гарантировано, то да, стоит думать и о нём.Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
© Goodkat
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
© Goodkat
«Появился и взлетел» — это про стартапы. У меня, например, всегда есть конкретный заказчик с конкретными потребностями. Всегда проводится анализ требований и составляется ТЗ, по которому сразу понятно на чём ваять, за сколько денег и в какие сроки. Всё это фиксируется в договоре\приказе и начинается работа до дедлайна. С систематически не укладывающимся в дедлайн программистом я просто прощаюсь. Программист, работающий быстрее и качественнее других, наоборот поощряется. Всё просто.
Как всегда, вопрос баланса. Иногда, если не сделать проще и быстрее, то вопрос поддержки уже не встает, встает вопрос поиска работы. Так что зависит от ситуации, как бы КО это не звучало.
1. Чувство меры обычно приходит с опытом.
2. Опыт появляется гораздо быстрее, если код регулярно подвергается code review и конструктивной критике со стороны более опытных программистов.
Я лично много для себя понял и многому научился в процессе код ревью. Причем слышал и приведенные в статье замечания.
3. Вместе с тем, у меня лично при программировании временами есть чувство творчества и красоты созданного кода. И такие моменты лично для меня очень ценны в моей работе и жизни.
2. Опыт появляется гораздо быстрее, если код регулярно подвергается code review и конструктивной критике со стороны более опытных программистов.
Я лично много для себя понял и многому научился в процессе код ревью. Причем слышал и приведенные в статье замечания.
3. Вместе с тем, у меня лично при программировании временами есть чувство творчества и красоты созданного кода. И такие моменты лично для меня очень ценны в моей работе и жизни.
я лично использую закон Парето для разумной борьбы с перфекционизмом.
>Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
Довольно спорно — мне кажется, думать об этом нужно всегда. Система обязаны быть расширяемой. Архитектура это не сам небоскреб а его фундамент. Сделали правильно — строите дальше, ошиблись начинаете все сначала. Это правило работает как для всей системы в целом, так и для отдельных классов.
Довольно сложно объяснить Заказчику, что для того, чтобы добавить в систему «Вот эту маленькую хреновину», Вам нужно писать Систему с нуля, потому что с изначально неверной архитектурой Системы, весь запас костылей уже был исчерпан ранее…
Довольно спорно — мне кажется, думать об этом нужно всегда. Система обязаны быть расширяемой. Архитектура это не сам небоскреб а его фундамент. Сделали правильно — строите дальше, ошиблись начинаете все сначала. Это правило работает как для всей системы в целом, так и для отдельных классов.
Довольно сложно объяснить Заказчику, что для того, чтобы добавить в систему «Вот эту маленькую хреновину», Вам нужно писать Систему с нуля, потому что с изначально неверной архитектурой Системы, весь запас костылей уже был исчерпан ранее…
Ну так да: теперь в распоряжении есть живые «поставщики кода», то функцию «делания кода» можно оставить им, а самому состедоточиться на «делании качества», рефакторя и вылизывая их говнокод.
P.S. Пруф цитаты.
P.S. Пруф цитаты.
Чего-то все цепляются к фразе «Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура».
В каждом конкретном случае предполагается, что есть кто-то главный с мозгами, который в общем понимает, что можно быстро заговнокодить, а что сразу надо написать нормально. Речь в статье не о методологии разработки программного обеспечения.
Статья-то про другое.
Статью рекомендуется дать к прочтению программистам, которые считатают «не технарей» быдлом и говном. Менеджеры нихрена не делают же. А когда просишь программиста лично пообщаться с заказчиком и объяснить, почему из-за распиздяйства этого программиста проект лежал 6 часов, то тут как тут нужен менеджер. Еще можно статью дать почитать восторженным молодым специалистам, которые хотят нахуячить 18 рядов абстрактных классов и интерфейсов, потому что «в будущем может понадобиться».
В целом, статья о том, что программист сам по себе без менеджеров, бухгалтеров, продажников и прочих членов большой команды нахрен никому не нужен. Статья именно про работников контор, а не про фрилансеров и прочих, способных данные проблемы решать самостоятельно.
В каждом конкретном случае предполагается, что есть кто-то главный с мозгами, который в общем понимает, что можно быстро заговнокодить, а что сразу надо написать нормально. Речь в статье не о методологии разработки программного обеспечения.
Статья-то про другое.
Статью рекомендуется дать к прочтению программистам, которые считатают «не технарей» быдлом и говном. Менеджеры нихрена не делают же. А когда просишь программиста лично пообщаться с заказчиком и объяснить, почему из-за распиздяйства этого программиста проект лежал 6 часов, то тут как тут нужен менеджер. Еще можно статью дать почитать восторженным молодым специалистам, которые хотят нахуячить 18 рядов абстрактных классов и интерфейсов, потому что «в будущем может понадобиться».
В целом, статья о том, что программист сам по себе без менеджеров, бухгалтеров, продажников и прочих членов большой команды нахрен никому не нужен. Статья именно про работников контор, а не про фрилансеров и прочих, способных данные проблемы решать самостоятельно.
Еще можно статью дать почитать восторженным молодым специалистам, которые хотят нахуячить 18 рядов абстрактных классов и интерфейсов, потому что «в будущем может понадобиться».
У нас таких называют архитектурными астрономами.
Это искаженное «Архитектурные астронавты» Джоэла Спольски?
Слишком много времени прошло, чтобы точно вспомнить, но, вероятно, это вот из этого комментария
Для меня «дзен» ООП — это умение написать с его помощью такую архитектуру классов, которую не придется рефакторить до основания после очередной смены требований. И тут пригодится не сколько умелое применение паттернов, сколько интуиция по поводу того, что реально в будущем может потребовать изменений. И не впасть при этом в over-engineering и не стать архитектурным астрономом.
Менеджеры нихрена не делают же.
Если программисту хоть раз пришлось самому общаться с заказчиком — так и есть, менеджер нихрена не делает и он — быдло и говно. А если он при этом смеет как-то ещё вякать на программиста по поводу сроков и стоимости, то его не просто уволить нужно, а набить ещё при этом лицо.
Не-не-не. Имеется в виду менеджер, который уже затрахался разгребать за программистом, огребать от заказчика и программист, который багует, считая что «ошибки — обязательный элемент творения». При этом реакция на уже громкое негодование менеджера (не в первый раз негодует) идет не в стиле «О, черт, мой косяк, простите, максимально быстро исправлю», а с позиции «Не рассказывай мне про мои ошибки, ничтожество, ибо аз есмь творец, а ты быдло в белом воротнике».
Ну и попытки рассказать не технарям, что вообще-то это сложно написать такой функционал без ошибок, бла-бла. За это просто убивать хочется. Человек искренне уверен в крайней сложности своей работы, и никчемности чужой работы, забывая, что всякая работа по-своему сложна.
В общем, неуважительное отношение к чужому труду, расточительное отношение к чужому времени и завышенное самомнение — вот это фу, за которое хочется ломать суставы, как завещала принцесса. Причем это фу, которое со стороны программистов встречается часто, а со стороны бухгалтеров-манагеров и прочих не_ИТ_профессионалов редко.
Ну и попытки рассказать не технарям, что вообще-то это сложно написать такой функционал без ошибок, бла-бла. За это просто убивать хочется. Человек искренне уверен в крайней сложности своей работы, и никчемности чужой работы, забывая, что всякая работа по-своему сложна.
В общем, неуважительное отношение к чужому труду, расточительное отношение к чужому времени и завышенное самомнение — вот это фу, за которое хочется ломать суставы, как завещала принцесса. Причем это фу, которое со стороны программистов встречается часто, а со стороны бухгалтеров-манагеров и прочих не_ИТ_профессионалов редко.
В общем, неуважительное отношение к чужому труду, расточительное отношение к чужому времени и завышенное самомнение — вот это фу, за которое хочется ломать суставы, как завещала принцесса. Причем это фу, которое со стороны программистов встречается часто, а со стороны бухгалтеров-манагеров и прочих не_ИТ_профессионалов редко.
Наверное, именно из-за очень уважительного отношения к чужому труду и бережного отношения к чужому времени бухгалтеры, зовущие админа, чтобы он вставил бумагу в принтер, стали частью фольклора.
Не надо гнать на программистов, и уж тем более по сравнению с бухгалтерами и манагерами. Среди них всех попадаются как нормальные люди, так и особи с раздутым ЧСВ, и среди моих знакомых бухгалтеров таких больше, чем среди знакомых программистов.
А админы жалуются и на тех, и на других. И вообще они нытики :)
Вот из вашей истории я вижу такой сценарий:
М(Менеджер): Нам нужно реализовать фичу1, фичу2, фичу3 и фичу4
П(Программист): Хм… ну тут только месяц реализовывать. Потом еще месяца 2 тестировать, отлаживать.
М: Мы бы хотели в конце месяца релиз.
П: Но до конца месяца же 3 недели всего.
М: Ну фичу4 впринципе можно не делать
Через месяц:
М: У тебя опять баги во всех фичах
П: Ну нельзя столько функционала написать за 3 недели и без ошибок.
М: Так ты же итак не делал фичу4. Можно было исправить ошибки за это время. Нам в новом релизе надо запилить фичу5, фичу6, фичу7, а мы не можем это делать, потому что у нас нет фичи1, фичи2, фичи3, они все с багами и нам надо править баги.
А еще бывает такое, что менеджер приходит, и говорит, надо реализовать такую и такую фичу. Ты смотришь на эту фичу, и понимаешь, что она дико не логична, пользоваться ей — это все равно что есть кактус. А чтобы реализовать эту фичу — нужно впихнуть букет костылей. Ты пытаешься объяснить, чем фича плоха, и что это вообще бред сивой кобылы, а не фича. Но менеджер вынашивал эту фичу 3 недели, и он думает примерно так:
Этот аз есмь программист вообще оборзел. Никакого уважения к человеческому труду, одно завышенное самомнение.
М(Менеджер): Нам нужно реализовать фичу1, фичу2, фичу3 и фичу4
П(Программист): Хм… ну тут только месяц реализовывать. Потом еще месяца 2 тестировать, отлаживать.
М: Мы бы хотели в конце месяца релиз.
П: Но до конца месяца же 3 недели всего.
М: Ну фичу4 впринципе можно не делать
Через месяц:
М: У тебя опять баги во всех фичах
П: Ну нельзя столько функционала написать за 3 недели и без ошибок.
М: Так ты же итак не делал фичу4. Можно было исправить ошибки за это время. Нам в новом релизе надо запилить фичу5, фичу6, фичу7, а мы не можем это делать, потому что у нас нет фичи1, фичи2, фичи3, они все с багами и нам надо править баги.
А еще бывает такое, что менеджер приходит, и говорит, надо реализовать такую и такую фичу. Ты смотришь на эту фичу, и понимаешь, что она дико не логична, пользоваться ей — это все равно что есть кактус. А чтобы реализовать эту фичу — нужно впихнуть букет костылей. Ты пытаешься объяснить, чем фича плоха, и что это вообще бред сивой кобылы, а не фича. Но менеджер вынашивал эту фичу 3 недели, и он думает примерно так:
Этот аз есмь программист вообще оборзел. Никакого уважения к человеческому труду, одно завышенное самомнение.
А бывает когда-нибудь (хотя бы раз в два года), что виноват программист?
В примере с программистом и менеджером опять скатываемся к плохо организованному процессу разработки, когда программист остается за все крайним, а менеджер-самодур может менять условия задачи, сроки и состав задач в зависимости от расположения Марса по отношению к Юпитеру. Это отвратный сценарий, хоть и частый. Я все-таки рассматриваю условно нормальных людей в условно нормальной рабочей обстановке.
Я вообще привык к хорошему и все рассуждения веду с такой точки зрения: менеджер не может просто так взять и что-то сказать, для этого есть продукт-овнер, а если они оба (менеджер и ПО) городят херню, то можно пойти к непосредственному начальству и челом бить. И тогда тебе объяснят, что вообще-то «херня» имеет далеко идущие планы и все грабли, о которых ты говоришь, учтены. А может и нет, может ты расскажешь про грабли, о которых никто не подумал и «херню» отменят или перепланируют с учетом твоих корректив. Я привык к адекватной обстановке в конторе, когда учитывается только голос разума, а не позиция говорящего в иерархической структуре компании.
Далее, не следует думать, что я считаю, что мудаки есть только среди программистов. Отнюдь. Количество мудаков всюду невероятно огромно. При этом процентное соотношение разное. В каких-то специальностях мудаков много, в каких-то мало. Следует понимать, что под мудаками в данном контексте я имею в виду людей с низкими профессиональными качествами. Может, бухгалтер Маша дома отличная мать-хозяйка и делает шикарнейший менет. Но на работе она мудак.
И вот теперь, зная все это, можно вернуться к моему предыдущему комментарию. Я говорил о людях, которые с точки зрения организации труда, как сыр в масле. При этом всё сплошь творческие личности. И вот среди таких товарищей есть пренебрежительное отношение к представителям других профессий и уверенность в собственном интеллектуальном превосходстве. И вот это плохо. Превосходство может и есть, чаще оно действительно есть — технарь в состоянии разобраться с бухгалтерией, бухгалтер вникнуть в программирование и начать писать тоже может, но это случай из ряда вон. И вот на ниве повышенного IQ и осознания, что можешь что-то, чего другие не могут, махать своим ЧСВ — вот это фу. А этим ну вот прям многие грешат.
Причем далее это может привести не только к плохому отношению к другим, но и к плохим взаимоотношениям между программистами, писькомерству и нежеланию делиться знаниями. А отсюда к застою и расколу прямой путь.
Короче. Надо быть человеком и думать головой. Даже на работе =)
Я вообще привык к хорошему и все рассуждения веду с такой точки зрения: менеджер не может просто так взять и что-то сказать, для этого есть продукт-овнер, а если они оба (менеджер и ПО) городят херню, то можно пойти к непосредственному начальству и челом бить. И тогда тебе объяснят, что вообще-то «херня» имеет далеко идущие планы и все грабли, о которых ты говоришь, учтены. А может и нет, может ты расскажешь про грабли, о которых никто не подумал и «херню» отменят или перепланируют с учетом твоих корректив. Я привык к адекватной обстановке в конторе, когда учитывается только голос разума, а не позиция говорящего в иерархической структуре компании.
Далее, не следует думать, что я считаю, что мудаки есть только среди программистов. Отнюдь. Количество мудаков всюду невероятно огромно. При этом процентное соотношение разное. В каких-то специальностях мудаков много, в каких-то мало. Следует понимать, что под мудаками в данном контексте я имею в виду людей с низкими профессиональными качествами. Может, бухгалтер Маша дома отличная мать-хозяйка и делает шикарнейший менет. Но на работе она мудак.
И вот теперь, зная все это, можно вернуться к моему предыдущему комментарию. Я говорил о людях, которые с точки зрения организации труда, как сыр в масле. При этом всё сплошь творческие личности. И вот среди таких товарищей есть пренебрежительное отношение к представителям других профессий и уверенность в собственном интеллектуальном превосходстве. И вот это плохо. Превосходство может и есть, чаще оно действительно есть — технарь в состоянии разобраться с бухгалтерией, бухгалтер вникнуть в программирование и начать писать тоже может, но это случай из ряда вон. И вот на ниве повышенного IQ и осознания, что можешь что-то, чего другие не могут, махать своим ЧСВ — вот это фу. А этим ну вот прям многие грешат.
Причем далее это может привести не только к плохому отношению к другим, но и к плохим взаимоотношениям между программистами, писькомерству и нежеланию делиться знаниями. А отсюда к застою и расколу прямой путь.
Короче. Надо быть человеком и думать головой. Даже на работе =)
И вот на ниве повышенного IQ и осознания, что можешь что-то, чего другие не могут, махать своим ЧСВ — вот это фу. А этим ну вот прям многие грешат.
Повышенный IQ помимо способности что-то сделать должен ещё по идее дать способность понять, что махать ЧСВ плохо. Другими словами, если кто-то машет ЧСВ, вполне вероятно, что IQ на самом деле у него никакой не повышенный. Умный человек — умный, а не умеющий решать задачки.
А вот к маханию ЧСВ часто приводит именно начальственное положение на фоне отсутствия нормального IQ. Как этот сопляк посмел спорить! Он что, думает, что умней меня? Я его урою! И это как раз и приводит к историям про мудаков-менеджеров и программистов-страдальцев. Здесь уходит умный (сам). В обратной ситуации (дурак-подчинённый, умный начальник) дурака обычно увольняют.
Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую программ прототипирования интерфейсов
Oh yeah, baby…
Баланс важен везде. Суть, пожалуй, именно в балансе. Перегибы в любую сторону, в любом вопросе — зло. Как архитектура ради архитектуры, так и говнокод ради зашибания бабла здесь и сейчас. Грабли с обеих сторон узкой дорожки.
Вообще, по поводу фразы о «системе на вырост». Мне кажется, тут нужно разделить два случая:
1) В задаче ясно говорится (или умалчивается), что для данного продукта будет определённое максимальное количество пользователей, и возможное превышение его в ближайшее время очень маловероятно;
2) В требованиях указано, что система должна быть сделана горизонтально расширяемой с возможностью, например, добавить в случае чего новый сервер.
В первом случае «система на вырост» не нужна, во втором же — строго обязательна.
P.S. Я вполне не против «строить в деревне небоскрёб», если это будет соответственно профинансировано Заказчиком (и очень желательно — иметь в себе некоторые сложности, для саморазвития).
1) В задаче ясно говорится (или умалчивается), что для данного продукта будет определённое максимальное количество пользователей, и возможное превышение его в ближайшее время очень маловероятно;
2) В требованиях указано, что система должна быть сделана горизонтально расширяемой с возможностью, например, добавить в случае чего новый сервер.
В первом случае «система на вырост» не нужна, во втором же — строго обязательна.
P.S. Я вполне не против «строить в деревне небоскрёб», если это будет соответственно профинансировано Заказчиком (и очень желательно — иметь в себе некоторые сложности, для саморазвития).
Третий секрет. Начните писать к commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.
Вот именно такая логика часто и приводит к тому, что наступает ситуация, при которой переписать дешевле и проще, чем развивать.
Все перечисленные в статье аргументы абсолютно справедливы… но только для краткосрочных проектов. А в долгоиграющих есть такое понятие, как рефакторинг. И как показывает мой скромный опыт, если в проекте руководитель пренебрегает необходимостью этой «гигиенической» процедуры, то сепсис и гангрена всего проекта неизбежны.
Насколько мне известно, примерно 30% действий, совершаемых разработчиками над кодом, не имеют ни малейшего отношения к пользовательской функциональности. Причем если на фазе «зализывания багов» эта цифра может опуститься до 5-10% (и модель, описываемая в статье почти работает), то на фазе начала нового проекта, когда большая часть работы связана даже не столько с архитектурным проектированием, сколько с изучением инструментария и предметной области, написать, какой профит тут получил пользователь нельзя.
Погодите, статья как раз и предлагает писать упрощенный код. Если не угадали с упрощением — всегда можно сделать рефакторинг. Скажем, после нескольких месяцев разработки выяснилось, что часть функций действительно дублируются в 2 местах. Вот тогда и стоит делать рефакторинг для выделения общей части. А если изначально писать обобщенную библиотеку, то велик шанс не угадать, как она будет использоваться в дальнейшем, и усилия пропадут даром.
Правильнее всего сделать так: когда потребуется написать второй дубль кода, выделить его в отдельную функцию для переиспользования. Для этого, правда, надо быть в курсе, что такой код уже есть, а для этого — знать, какой код уже есть. А новый разработчик может просто не знать, какой код уже есть, и напишет «велосипед», не подозревая о том.
всегда был против использования излишнего кода…
правильно подмечено: больше кода — больше ошибок.
правильно подмечено: больше кода — больше ошибок.
Почему-то к каждой такой статье вижу здоровенные треды «куча абстракций» VS «весь код в контроллере». Статья-то не о том, что надо «фигак-фигак и в продакшен подешевле да побыстрее, а там разберемся, на крайняк перепишем с нуля». Статья о том, что абсолютно любая работа программиста должна быть экономически оправдана. Если ту же задачу можно решить дешевле, то ее надо решить дешевле, а не разводить сопли про всякие там высшие материи. Другой вопрос если программист реально видит риск дешевого решения и принимает _осознанное_ и _аргументированное_ решение усложнить вот этот вот кусочек архитектуры, потому что ожидаются такие-то требования — это ок, по-моему.
Задели прям за живое =) Сам недавно очень много размышлял на эту тему и пришел к абсолютно идентичными выводам и аргументации как в статье.
Вы и ваш двойник открыли бизнес по автоматизации чего-нибудь. Конкретно вы из вас двоих — директор.Я ничего не понял. :( Какого работодателя я нагрел, если вы сами назвали меня директором? И каким образом я кого-то нагрел на несколько копеек (часовая ставка / 9600)?
Какая у вашего двойника часовая ставка? Возьмите калькулятор и поделите цифру, указанную в трудовом договоре на 160. Если вы совершаете эти действия в рабочее время, то поделите результат еще на 60. Вот на столько (+20% льготной ставки в ПФР + 0.2% за травматизм + 6% УСН (половину можно зачесть из налогов ПФР) = +23.2% минимум) вы нагрели своего работодателя, развлекаясь здесь со мной.
Тоже перечитал этот абзац три раза, но таки понял.
160 — количество рабочих часов в месяц. Чтобы узнать часовую ставку делим «цифру» (ну число же, блин!) из трудового договора на количество часов.
А следующее предложение уже о том, что если вы это считаете в рабочее время (следовательно, не работаете), то работодатель теряет на этом деньги. Полагается, что на расчёты ушла 1 минута, по-этому делим часовую ставку на 60.
А автора я бы всё таки попросил переписать этот абзац ;)
160 — количество рабочих часов в месяц. Чтобы узнать часовую ставку делим «цифру» (ну число же, блин!) из трудового договора на количество часов.
А следующее предложение уже о том, что если вы это считаете в рабочее время (следовательно, не работаете), то работодатель теряет на этом деньги. Полагается, что на расчёты ушла 1 минута, по-этому делим часовую ставку на 60.
А автора я бы всё таки попросил переписать этот абзац ;)
Было бы здорого если бы раз в две недели кто нибудь зачитывал этот отрезвляющий пост! Спасибо!!!
программисты никому не нужны. И программы тоже. То есть совсем. Людям интересны они сами, их проблемы...Программы нужны программистам. Программисты тоже люди.
Я думаю, весьма редкое событие в жизни, когда один программист платит другому программисту деньги просто за «красивый код».
Это обычно называется donate, и чаще всего мотивация немного другая.
Это обычно называется donate, и чаще всего мотивация немного другая.
> Я думаю, весьма редкое событие в жизни, когда один программист платит другому программисту деньги просто за «красивый код».
Я же просто уверен, что имея более удобный интерфейс библиотеки (пусть это свойство будет частью собирательного «красивый код»)
реализующий необходимый программисту функционал выбор будет очевидно в сторону…
«Красота кода» это и есть внутренняя характеристика от программиста к программисту, так как красоту кода не видит пользователь.
Я же просто уверен, что имея более удобный интерфейс библиотеки (пусть это свойство будет частью собирательного «красивый код»)
реализующий необходимый программисту функционал выбор будет очевидно в сторону…
«Красота кода» это и есть внутренняя характеристика от программиста к программисту, так как красоту кода не видит пользователь.
А часто художники платят художникам «просто за красивую картину»?
Хочу заметить, что общая стоимость использованных в проекте библиотек часто значительно превышает стоимость экземпляра готового продукта для юзера. И, кстати, donate я бы тоже не исключал из экономики ибо он, слава богу, становится все популярнее.
Поясню свою позицию. Я считаю, что именно open-source создает будущее индустрии не потому, что «проприетарщики» зажали свой код и требуют деньги, а потому, что код их ужасен (ибо написан согласно принципу «прибыль в первую очередь»)
Зачастую код коммерческого решения настолько негибок и глючен, что поддерживающий его огромный штат программистов с трудом выдерживает конкуренцию с новым open-source-проектом, который делают на порядок меньше людей. Так, к примеру, на глазах у древних как мамонты 3DMax и Maya «вырос» Blender.
Поясню свою позицию. Я считаю, что именно open-source создает будущее индустрии не потому, что «проприетарщики» зажали свой код и требуют деньги, а потому, что код их ужасен (ибо написан согласно принципу «прибыль в первую очередь»)
Зачастую код коммерческого решения настолько негибок и глючен, что поддерживающий его огромный штат программистов с трудом выдерживает конкуренцию с новым open-source-проектом, который делают на порядок меньше людей. Так, к примеру, на глазах у древних как мамонты 3DMax и Maya «вырос» Blender.
Я начинаю понимать, что смысл моего комментария немного был не понят. Я к тому, что не встречал еще людей, которые бы заплатили за «красоту» кода и не более. Как за красивое полотно. Не потому что код чистый, понятный, удобный и его легко интегрировать. А вот просто потому что мне понравилась программа. Красивая она. Т.е. это был ответ на то что «программисту нужна программа». Программисту не нужна программа как просто красивый набор букв и символов. Ему нужно удобное и легкое решение. Я вот вообще о чем!
Я мечтаю, чтобы у каждого opensource была параллельная коммерческая лицензия. Платная лицензия позволяет предъявлять претензии.
Сейчас же ситуация выглядит так:
opensource: «Если что-то будет работать плохо или не будет работать совсем, я верну вам деньги.»
я: «Но я же ничего не платил.»
opensource: «Вот именно.»
Немного спасают maintainer'ы, которые всего за 50$ (OpenSceneGraph) — 125$ (x264) в час согласны доработать свой код. К чести maintainer'ов, работа всегда выполнялась четко, в срок и полностью соответствовала ожиданиям.
Сейчас же ситуация выглядит так:
opensource: «Если что-то будет работать плохо или не будет работать совсем, я верну вам деньги.»
я: «Но я же ничего не платил.»
opensource: «Вот именно.»
Немного спасают maintainer'ы, которые всего за 50$ (OpenSceneGraph) — 125$ (x264) в час согласны доработать свой код. К чести maintainer'ов, работа всегда выполнялась четко, в срок и полностью соответствовала ожиданиям.
У вас смешались в кучу кони люди: платный/бесплатный софт, опенсорс и возможность предъявить претензии.
Опенсорс — это всего лишь открытый исходный код. Есть еще проприетарный софт. Но это не значит что опенсорс бесплатный, а проприетарный — платный. Полно бесплатного проприетарного софта.
И если вы что-то заплатили за софт — это еще не значит что можно качать права. Ваши права определяются пользовательским соглашением, с которым вы согласились при установке софта.
Опенсорс — это всего лишь открытый исходный код. Есть еще проприетарный софт. Но это не значит что опенсорс бесплатный, а проприетарный — платный. Полно бесплатного проприетарного софта.
И если вы что-то заплатили за софт — это еще не значит что можно качать права. Ваши права определяются пользовательским соглашением, с которым вы согласились при установке софта.
> программисты никому не нужны. И программы тоже. То есть совсем.
Разрешите процитировать мораль басни Крылова — «Свинья под дубом»:
Мне кажется это будет тут уместно.
Разрешите процитировать мораль басни Крылова — «Свинья под дубом»:
Невежда также в ослепленье
Бранит науки и ученье,
И все ученые труды,
Не чувствуя, что он вкушает их плоды.
Мне кажется это будет тут уместно.
> Правда думаете, что цикл на итераторах работает быстрее, чем на индексах
А если стурктура данных — linked list? ;)
А если стурктура данных — linked list? ;)
Для красоты и правильности есть свои проекты и опенсурс.
Мне кажется что налицо старый, как мир, конфликт:
-желание делать любимое дело, со своими критериями красоты (творчество)
-выполнение работы по найму
Мне понравилась аналогия с музыкой, приведенная выше. Подобное разделение, в общем, есть в любом искусстве. Грубо — попса, созданная с целью делать деньги, и авангард (андеграунд, народные напевы и.т.д.) созданные ради себя самих.
Проблема в том, что программисты (в широком смысле слова — сотрудники, занятые в разработке ПО), в большинстве своем, очень любят свое дело. Поэтому стараются делать его наилучшим (с их точки зрения) образом. А с точки зрения руководителя/заказчика нужно чтоб работало ТОТЧАС. Стройные иерархии классов конечному пользователю не видны, и польза от проработки архитектуры «на будущее» — не очевидна.
Тем не менее, программисты вряд ли захотят делать «ширпотреб». Для себя я нашел любопытное решение — я занимаюсь разработкой дома для души. А на работе перешел из разработки в тестирование :)
-желание делать любимое дело, со своими критериями красоты (творчество)
-выполнение работы по найму
Мне понравилась аналогия с музыкой, приведенная выше. Подобное разделение, в общем, есть в любом искусстве. Грубо — попса, созданная с целью делать деньги, и авангард (андеграунд, народные напевы и.т.д.) созданные ради себя самих.
Проблема в том, что программисты (в широком смысле слова — сотрудники, занятые в разработке ПО), в большинстве своем, очень любят свое дело. Поэтому стараются делать его наилучшим (с их точки зрения) образом. А с точки зрения руководителя/заказчика нужно чтоб работало ТОТЧАС. Стройные иерархии классов конечному пользователю не видны, и польза от проработки архитектуры «на будущее» — не очевидна.
Тем не менее, программисты вряд ли захотят делать «ширпотреб». Для себя я нашел любопытное решение — я занимаюсь разработкой дома для души. А на работе перешел из разработки в тестирование :)
К счастью реалии рынка не соответствуют этому (вне всякого сомнения разумному) мнению :)
А реальность такова, что мне мало интересны проблемы моего работодателя, точно как и ему мало интересны мои эстетические предпочтения в программировании. Просто так сложилось, что я люблю есть, а работодателю могут быть полезны мои навыки. Трудовой контракт это честная сделка только в том случае, если обе стороны признают, что их цели и интересы различны и готовы идти на компромиссы. Обе стороны.
Для меня программирование — самоцель, а работа — побочный эффект. Я не скрываю этого на собеседованиях и ожидаю, что к такой позиции будут относиться с уважением и пониманием — до тех пор пока работа выполняется. Но если мне начнут рассказывать, что этого мало и я ещё и должен работать с «правильным отношением» — я просто сменю компанию.
Давайте же уважать друг друга и стремиться к разумным компромиссам ;)
А реальность такова, что мне мало интересны проблемы моего работодателя, точно как и ему мало интересны мои эстетические предпочтения в программировании. Просто так сложилось, что я люблю есть, а работодателю могут быть полезны мои навыки. Трудовой контракт это честная сделка только в том случае, если обе стороны признают, что их цели и интересы различны и готовы идти на компромиссы. Обе стороны.
Для меня программирование — самоцель, а работа — побочный эффект. Я не скрываю этого на собеседованиях и ожидаю, что к такой позиции будут относиться с уважением и пониманием — до тех пор пока работа выполняется. Но если мне начнут рассказывать, что этого мало и я ещё и должен работать с «правильным отношением» — я просто сменю компанию.
Давайте же уважать друг друга и стремиться к разумным компромиссам ;)
Да, ситуация к нам благосклонна :) Однако подобный подход может «аукнуться» в периоды кризиса, или стать препятствием на пути к карьерному росту (хотя не всем оно и надо)
Всё так. Это прекрасно, что есть люди, которым нравится программировать. До тех пор, пока работа выполняется, вам никто не начнет рассказывать про «правильное отношение». Мало того, работодатель будет только рад найти программиста на 60 тыс., который всю жизнь будет прикрывать задачи на 60 тыс. Работодатель не планирует рост заплаты, развитие, продвижение по карьерной лестнице и т.д., и с удовольствием (и легким сожалением) с этих же 60 тыс. проводит программиста на пенсию. Дворник с 20-летним стажем всё равно будет получать зарплату дворника, как бы ловко он не управлялся с метлой.
Эта статья не для вашего начальника, а для вас. Потому что в один прекрасный момент понадобится человек, готовый взять на себя ответственность в весомом денежном эквиваленте, в условиях ограниченных ресурсов. И было бы очень здорово, если таким человеком оказались бы вы.
Эта статья не для вашего начальника, а для вас. Потому что в один прекрасный момент понадобится человек, готовый взять на себя ответственность в весомом денежном эквиваленте, в условиях ограниченных ресурсов. И было бы очень здорово, если таким человеком оказались бы вы.
Жаль, что в статье не упомянут такой способ улучшения дизайна существующего кода, как рефакторинг. Заодно помогает относительно быстро научиться писать хорошо.
В статье описана не конкретная методология разработки, а один из руководящих принципов, основанных на ценности создаваемого, который, если его принять, может помочь воспитать в себе более хороший стиль программирования. Этот же принцип пригоден для любого производства. Качество проработки мелких деталей зависит от того, за сколько вы собираетесь продавать готовый продукт. Сравните резные деревянные детали на мебели разной ценовой категории.
Я не агитирую за т.н. «говнокод» и не говорю, что перфекционизм — это плохо. Я лишь говорю о том, что код должен соответствовать своей бизнес-ценности. У нас есть части, которые отполированы до блеска — это разные транспортные уровни. Потому что, если не будет работать передача данных, то ничего работать не будет. А есть части, которые намерено сделаны дешево. Скажем pdf-просмотрщик на pdf.js — тормозит, ест много памяти, но свою цель выполняет и написан за один вечер (левой ногой).
Я не агитирую за т.н. «говнокод» и не говорю, что перфекционизм — это плохо. Я лишь говорю о том, что код должен соответствовать своей бизнес-ценности. У нас есть части, которые отполированы до блеска — это разные транспортные уровни. Потому что, если не будет работать передача данных, то ничего работать не будет. А есть части, которые намерено сделаны дешево. Скажем pdf-просмотрщик на pdf.js — тормозит, ест много памяти, но свою цель выполняет и написан за один вечер (левой ногой).
Я не агитирую за т.н. «говнокод» и не говорю, что перфекционизм — это плохо
Значит в статье вы сильно переусердствовали. Однозначно создаётся впечатления, что надо «фигак-фигак и в продакшен» и никакой перфекционизм не допустим.
Было бы замечательно, если бы это мнение Вы отразили в статье. А-то реально создается впечатление, что Вы весь код предлагаете писать быстро и некачественно.
Кину свои 0,5 копеек.
Приоритеты при разработке:
1. Должен быть результат, т.е. програма должна работать и выполнять свою работу — это главное. Всё остальное — лирика.
2. Результат должен быть эффективным, т.е. всё должно выполняться за приемлимое время и кушать приемлимое количество ресурсов, и т.д.
3. Результат должен быть стабилен, без косяков. Если результат нестабилен, но эффективно выполняет свою работу с некоторыми косяками, то это лучше, чем стабильный код съедающий все ресурсы либо выполняющийся год. Не относится к случаю из пункта 1.
4. Код результата должен быть оформлен по правилам KISS, YAGNI и DRY + правила вашей среды разработки.
5. Все остальные требования.
6. Profit.
Приоритеты при разработке:
1. Должен быть результат, т.е. програма должна работать и выполнять свою работу — это главное. Всё остальное — лирика.
2. Результат должен быть эффективным, т.е. всё должно выполняться за приемлимое время и кушать приемлимое количество ресурсов, и т.д.
3. Результат должен быть стабилен, без косяков. Если результат нестабилен, но эффективно выполняет свою работу с некоторыми косяками, то это лучше, чем стабильный код съедающий все ресурсы либо выполняющийся год. Не относится к случаю из пункта 1.
4. Код результата должен быть оформлен по правилам KISS, YAGNI и DRY + правила вашей среды разработки.
5. Все остальные требования.
6. Profit.
Давайте будем честными. У директора и у программиста разные цели и мотивация. Программисту интересно «программировать», именно поэтому он этим занимается. А директору деньги зарабатывать, поэтому он директор. Конечно, хороший результат заключается в компромиссе, но пока программист занимается программированием, не пытайтесь свалить на него ответственность директора и поставить одного на место другого, пусть директор сам по этому поводу париться, ему за это платят, причем сильно больше, чем программисту. Как только программист будет получать деньги за то, что компания больше заработала, как это бывает, когда программист делает свой проект какой-то, так сразу появляется и мотивация на «сделать быстрее». А если не нравится, то конъюнктура рынка такова, что разработчика возьмет другой директор, более лояльный к личностным нюансам.
Тронуло черт возьми… На самом деле как будто в душу себе заглянул. Сам руковожу компанией разработчиков и за плечами приличный опыт работы рядовым программистом в разных компаниях (ну как я считаю по крайней мере). Поэтому проникся всеми ньюансами с обоих сторон. Спасибо огромное за статью!
Одни компании выпускают по 50 продуктов в месяц, другие по пять, третьи по одному, а четвертые один продукт в 5 лет. А некоторые и один в 30 лет.
Скажите, Вы хотите автопилоты в машины, которые писали бы говнокодеры с мыслью о том, как бы их менеджер быстрее заработал на этом денег? А беспилотное метро? А может школьники пусть софт на космические аппараты пишут? Как насчет телекомов с их инфраструктурой? А может разработку Half Life 3 каким пацанам с улицы отдадим?
Когда Вася пишет сайт-визитку для мелкой конторы за X рублей, менеджер справедливо хочет, чтобы Вася писал его быстро, потому как лишь бы купили.
Когда Вася пишет движок CryEngine, нужно, чтобы его архитектура была качественная и продуманная, код быстрым и лаконичным. Ведь мало того, что движок нужно использовать самим, его еще нужно продать, потом написать версию 2, потом опять продать, и дальше по циклу. Будет Вася говнокодером — есть великий шанс вообще весь проект загубить и обанкротить компанию.
И пример этот реален. Откройте код движка id Tech и какой-нибудь «бизнес системы». Земля и небо.
Тому парню из цитаты топика я бы посоветовал просто искать работу R&D, где нужны рассудительность, мозг, умение красиво и правильно решать проблемы, где результат твоего труда нужен не вчера, а понадобится послезавтра.
Скажите, Вы хотите автопилоты в машины, которые писали бы говнокодеры с мыслью о том, как бы их менеджер быстрее заработал на этом денег? А беспилотное метро? А может школьники пусть софт на космические аппараты пишут? Как насчет телекомов с их инфраструктурой? А может разработку Half Life 3 каким пацанам с улицы отдадим?
Когда Вася пишет сайт-визитку для мелкой конторы за X рублей, менеджер справедливо хочет, чтобы Вася писал его быстро, потому как лишь бы купили.
Когда Вася пишет движок CryEngine, нужно, чтобы его архитектура была качественная и продуманная, код быстрым и лаконичным. Ведь мало того, что движок нужно использовать самим, его еще нужно продать, потом написать версию 2, потом опять продать, и дальше по циклу. Будет Вася говнокодером — есть великий шанс вообще весь проект загубить и обанкротить компанию.
И пример этот реален. Откройте код движка id Tech и какой-нибудь «бизнес системы». Земля и небо.
Тому парню из цитаты топика я бы посоветовал просто искать работу R&D, где нужны рассудительность, мозг, умение красиво и правильно решать проблемы, где результат твоего труда нужен не вчера, а понадобится послезавтра.
Исключения лишь подтверждают правила. Проблема в том, что 90% программистов любой говносайт воспринимают как программу для Боинга. И когда директор их пинает — они смотрят с высока и говорят — отстань — я тут творчеством занимаюсь.
Ну это косяк менеджера, а не программиста. Значит, ему нужны люди, которые будут на шаблоне быстро «фигак-фигак и в продакшн». Не надо тогда писать в резюме, что фирма ищет офигенного программиста с божественными знаниями языка (а то и нескольких), по совместительству хорошего архитектора, вот это все. Так и надо писать, что нужен кодер, который быстро и эффективно будет строчить то, что скажет менеджер/тимлид.
Что-то вас из крайности в крайность. Желание получить продукт вовсе не означает фигак-фигак и в продакшен. Просто сплошь и рядом одни творцы. Приходят тоннами на собеседование и все хотят интересной работы — а где ее набрать? Закон Паретто везде закон — а они творить хотят. Поэтому не надо перегибать — вы всех, кто не плодит кучу классов с чего-то считаете говнокодерами — а я их считаю как раз толковыми людьми, знающими разницу между искусством и работой.
Так я еще раз говорю, не пишите, что у Вас интересная работа! Пишите, что есть куча рутины, баг-трекер завален ошибками, сроки сжаты и т.д.
Ну вот пример, что я хочу донести. Открываю hh, вбиваю слово «программист», щелкаю на одну из первых попавшихся вакансий: инженер-программист. Вы понимаете, чем будет заниматься этот человек? Тут тебе и «Развитие интеграции IT-сервисов на базу интеграционной платформы SAP XI (SAP PI)», и «Понимание принципов интеграции корпоративных приложений, сервисно-ориентированной архитектуры (SOA)», но чего надо от человека — нифига непонятно. Особенно учитывая, что это торговая компания.
Открываем другую вакансию, от Evernote (к этой компании никакого отношения не имею). Ну сразу видно, что люди писали, а не отдел кадров теги накидывал. Тут явно нужен человек, который будет знать, нужно ли плодить кучу классов или нет.
Ну вот пример, что я хочу донести. Открываю hh, вбиваю слово «программист», щелкаю на одну из первых попавшихся вакансий: инженер-программист. Вы понимаете, чем будет заниматься этот человек? Тут тебе и «Развитие интеграции IT-сервисов на базу интеграционной платформы SAP XI (SAP PI)», и «Понимание принципов интеграции корпоративных приложений, сервисно-ориентированной архитектуры (SOA)», но чего надо от человека — нифига непонятно. Особенно учитывая, что это торговая компания.
Открываем другую вакансию, от Evernote (к этой компании никакого отношения не имею). Ну сразу видно, что люди писали, а не отдел кадров теги накидывал. Тут явно нужен человек, который будет знать, нужно ли плодить кучу классов или нет.
Оххх, да нет я вам говорю постоянно интересной работы, она везде 20 на 80 примерно. Задачи примерно одинаковые везде, ну где-то на старте да, вам придется заюзать новую либу, изучить новый интерфейс, освоить новый софт. Но как только вы это сделаете — опять начнется рутина. Не бывает за редким исключением работ, где интересность высока все время. Все равно вы будете кодить, тупо кодить. Разница в том, что нормальный программист делает свою раоту хорошо, а «творец» на пустом месте выдумывает себе интересность, которой нет — в результате этих фантазий он строит замки из классов и впендюривает ненужные выкрутасы, только чтобы было типа интересно. А таких много — вот в чем проблема.
Кодить — не значить «тупо кодить». На проектах с грамотной архитектурой кодить приятно. И даже в чужом коде разбираться.
А вот в хрен пойми какой лапше — конечно, рутина, мозговынос и «тупо кодить», потому что «быстрее бы это закончилось».
Понимаете, вот писали пару крутых разрабов проект, все было шикарно и красиво. Пришел новый парень, под давлением менеджера, не вникая в заложенную идеологию, накидал хрен пойми что, лишь бы работало. И работает, да.
Но потом, чтобы хоть что-то в проекте как-то изменить, приходится лопатить половину проекта. И тут начинаются «менеджер, нам нужно сделать рефакторинг», «менеджер, а давай все выкинем и напишем заново — быстрее будет» и т.д. Но менеджер говорит нет, бабла-то это не приносит. Вот и начинается конфликт тех, кто не хочет продолжать писать говно и тех, кто еще это говно хочет продать.
А вот в хрен пойми какой лапше — конечно, рутина, мозговынос и «тупо кодить», потому что «быстрее бы это закончилось».
Понимаете, вот писали пару крутых разрабов проект, все было шикарно и красиво. Пришел новый парень, под давлением менеджера, не вникая в заложенную идеологию, накидал хрен пойми что, лишь бы работало. И работает, да.
Но потом, чтобы хоть что-то в проекте как-то изменить, приходится лопатить половину проекта. И тут начинаются «менеджер, нам нужно сделать рефакторинг», «менеджер, а давай все выкинем и напишем заново — быстрее будет» и т.д. Но менеджер говорит нет, бабла-то это не приносит. Вот и начинается конфликт тех, кто не хочет продолжать писать говно и тех, кто еще это говно хочет продать.
Любой человек с новой парадигмой и видением структуры проекта придет и назовет ваш чудо-код говнокодом. Мы все прекрасно знаем, что понятие говнокод зависит от каждого первого человека. Другой вопрос, что многие хотят учиться и привыкают к новому проекту, а кто-то противится этому. Вы никогда не приходили в проект, который был весь такой ООП и красивый, но от старой команды никого не осталось? Вот там начинаются танцы с бубном — разберись в красивом коде. Тогда как говнокод понятен и прост, то в стройной ооп структуре проекта еще надо разобраться. Вы постоянно пишите с каким-то перекосом. У вас как у Толкиена -либо говнокод — либо красиво. Черного и белого не бывает, как и понятия «интересная работа». Даже в студии, выпускающей сайты, всегда найдется интересная работа. Всегда будет интересный заказчик.
Я сталкивался с такими красивыми проектами, в которые кодер без 120 тыщ ЗП даже подойти бы не смог — и кому это нужно? Красивые проекты требуют неоправданно дорогих программистов, плохо поддерживаются не дорогими программистами и в целом нет никакой надобности в таком.
Вон Баду — крупнейший проект сетевой и там кода под PHP 4 дофига — и ничего — живет и процветает. Так что рассказывать истории про чудо-архитектуру, поддерживаемую на века… Ну да, пока тимлид у вас сидит, а не поменял срочно вашу компанию на другую. Вот тут начнется чудо понимания, что красивый проект вовсе не таков.
Я сталкивался с такими красивыми проектами, в которые кодер без 120 тыщ ЗП даже подойти бы не смог — и кому это нужно? Красивые проекты требуют неоправданно дорогих программистов, плохо поддерживаются не дорогими программистами и в целом нет никакой надобности в таком.
Вон Баду — крупнейший проект сетевой и там кода под PHP 4 дофига — и ничего — живет и процветает. Так что рассказывать истории про чудо-архитектуру, поддерживаемую на века… Ну да, пока тимлид у вас сидит, а не поменял срочно вашу компанию на другую. Вот тут начнется чудо понимания, что красивый проект вовсе не таков.
Тогда как говнокод понятен и прост, то в стройной ооп структуре проекта еще надо разобраться.
Да, злООПотребление вполне себе является говнокодом, ибо чрезмерно переусложнено. Но не все то говнокод, что написано «по-простецки». Как-то у вас очень уж обобщенно написано.
Это неправда. Говнокодомерка характерна как раз хреновым программистам, либо же новичкам. Нормальные программисты всегда с удовольствием покопаются в чужом хорошем коде. Qt, boost, Ogre3d, STL и прочее — проекты, в которых приятно и полезно копаться.
Используя тут же Qt в своих проектах, мы используем рекомендуемые конструкции, паттерны, архитектурные примочки. Любой хорошо знакомый с данным фреймворком разработчик без труда разбирается в нашем «всем таким красивым ООП».
Мне кажется, Вы не понимаете, о чем я говорю, когда употребляю слово «говнокод». ООП, функциональщица и прочее могут быть или не быть, это совершенно неважно (в конце-концов, в том же C вообще нет ООП, но ряд самых значимых проектов написан именно на этом языке). Речь о том, когда программист решает проблему написаем 150 строк кода, вместо того, чтобы вызвать одну функцию из стандартной библиотеки/фреймворка. Потом «разработчик» узнает, что его функция не работает на таком наборе данных. А потом на таком. 150 строк кода вырастают до 300, код полон конструкции if и switch, повсюду непонятная лапша.
Позже, используя эту функцию, человек находит в ней ошибку, но исправляет не в теле функции, а где-то вне. В результате логика работы с этой конструкцией вылетела за пределы конструкции, и теперь другому разработчику не получится просто взять и заменить все это на одну строчку кода — потому что правильная работа теперь будет обрабатываться неправильно.
И поддержка этого ада превращается в настоящий кошмар. Менеджерам-то менять ничего не хочется, оно же работает, деньги вот приносит! Но любой чих-пых, вместо часа работы, может обернуться днем работы, а то и неделей. И тут менеджер вдруг понимает, что проект-то сложный, нужно на него больше людей, нанимает еще X разработчиков. Но вместо решения проблемы, мы приходим к проблеме «Если 1 женщина рожает ребенка за 9 месяцев, то 9 женщин должны родить за 1 месяц».
Когда пишется проект сегодня, а продается завтра — насрать, кто и как его будут писать.
Когда проект пишется год, два, пять лет, долгое время поддерживается, состав разработчиков сменяется — очень, ОЧЕНЬ важно писать проект грамотно. И начинать его должны писать люди, у которых ЗП много выше 120к.
Какая связь между плохим кодом и PHP? То, что на этом языке написано много плохого кода говорит лишь о том, что порог вхождения очень низкий, и любой, прочитав пару-тройку статей, может уже что-то налабать.
Баду никогда не использовал, но Вы лучше бы с каким-нибудь проектом типа ВКонтакте сравнили. Там команда разрабов была — мехматовцы, вмкашники, олимпиадники и прочие умы. Думаю, очень дорогая команда из крутых спецов. И как бы их не поливали дерьмом и не любили на Хабре, написали они очень значимый, очень большой и инфраструктурный проект.
Используя тут же Qt в своих проектах, мы используем рекомендуемые конструкции, паттерны, архитектурные примочки. Любой хорошо знакомый с данным фреймворком разработчик без труда разбирается в нашем «всем таким красивым ООП».
Тогда как говнокод понятен и прост, то в стройной ооп структуре проекта еще надо разобраться.
Мне кажется, Вы не понимаете, о чем я говорю, когда употребляю слово «говнокод». ООП, функциональщица и прочее могут быть или не быть, это совершенно неважно (в конце-концов, в том же C вообще нет ООП, но ряд самых значимых проектов написан именно на этом языке). Речь о том, когда программист решает проблему написаем 150 строк кода, вместо того, чтобы вызвать одну функцию из стандартной библиотеки/фреймворка. Потом «разработчик» узнает, что его функция не работает на таком наборе данных. А потом на таком. 150 строк кода вырастают до 300, код полон конструкции if и switch, повсюду непонятная лапша.
Позже, используя эту функцию, человек находит в ней ошибку, но исправляет не в теле функции, а где-то вне. В результате логика работы с этой конструкцией вылетела за пределы конструкции, и теперь другому разработчику не получится просто взять и заменить все это на одну строчку кода — потому что правильная работа теперь будет обрабатываться неправильно.
И поддержка этого ада превращается в настоящий кошмар. Менеджерам-то менять ничего не хочется, оно же работает, деньги вот приносит! Но любой чих-пых, вместо часа работы, может обернуться днем работы, а то и неделей. И тут менеджер вдруг понимает, что проект-то сложный, нужно на него больше людей, нанимает еще X разработчиков. Но вместо решения проблемы, мы приходим к проблеме «Если 1 женщина рожает ребенка за 9 месяцев, то 9 женщин должны родить за 1 месяц».
Я сталкивался с такими красивыми проектами, в которые кодер без 120 тыщ ЗП даже подойти бы не смог — и кому это нужно?
Когда пишется проект сегодня, а продается завтра — насрать, кто и как его будут писать.
Когда проект пишется год, два, пять лет, долгое время поддерживается, состав разработчиков сменяется — очень, ОЧЕНЬ важно писать проект грамотно. И начинать его должны писать люди, у которых ЗП много выше 120к.
крупнейший проект сетевой и там кода под PHP 4 дофига
Какая связь между плохим кодом и PHP? То, что на этом языке написано много плохого кода говорит лишь о том, что порог вхождения очень низкий, и любой, прочитав пару-тройку статей, может уже что-то налабать.
Баду никогда не использовал, но Вы лучше бы с каким-нибудь проектом типа ВКонтакте сравнили. Там команда разрабов была — мехматовцы, вмкашники, олимпиадники и прочие умы. Думаю, очень дорогая команда из крутых спецов. И как бы их не поливали дерьмом и не любили на Хабре, написали они очень значимый, очень большой и инфраструктурный проект.
Теоретически, я всё могу написать сам. Практически, понятное дело — не могу. Мне нужны дополнительные руки, которые я готов купить. Каким-то рукам я могу доверить лишь код для заготовленных мной интерфейсов. Какие-то руки я могу попросить придумать такие интерфейсы. Еще более квалифицированным рукам я могу поручить провести сравнительное исследование разных решений и выбрать лучшее (тут я ожидаю понимание коммерческого следствия лучшего решения). И совсем хорошим рукам, которых очень-очень-очень-очень мало, я готов отдать полную ответственность и людей в придачу.
В зависимости от рук, которые мне нужны я и буду составлять описание вакансии. При этом, я никогда не видел ситуации, в которой программиста нанимали бы со словами: «Вот тебе зарплата — занимайся чем хочешь.»
В зависимости от рук, которые мне нужны я и буду составлять описание вакансии. При этом, я никогда не видел ситуации, в которой программиста нанимали бы со словами: «Вот тебе зарплата — занимайся чем хочешь.»
При этом, я никогда не видел ситуации, в которой программиста нанимали бы со словами: «Вот тебе зарплата — занимайся чем хочешь.»
Ну, то, что Вы не видели, не значит, что такого нет :)
Ну так Вы все правильно пишите, я говорю о том же. Если Вам нужен программист, который будет писать код для заготовленных интерфейсов, не надо нанимать на эту должность Senior Developer'ов. Да и просто крепких developer'ов не надо, они, скорее всего, хотят дальше расти.
Просто тут все так пишут, что у всех творцы. Черт, дайте мне их координаты что ли! У нас половина команды любит творить, половина команды «фигак-фигак и в продакш». В итоге получается ок: одни думают, как это все будет работать в итоге (читай, бекенд на низком уровне), другие быстренько наращивают функционал.
Но вот проектов стало больше, и именно творцов немного не хватает.
Кто-то должен был в этом месте написат про valve :) В дополнение советую почитать Майкла Абраша (не могу сходу найти русский вариант) про историю valve, как он туда попал и что, всё-таки, не совсем «вот тебе зарплата — занимайся чем хочешь».
Да понятно, что нету.
Я просто за годы работы видел СТОЛЬКО корпоративного говна, в котором даже суперспецы за адекватное количество времени разобраться не могли, что вот эти вот выпады «у нас люди пытаются писать качественно даже там, где это особо не нужно» вызывают у меня улыбку. Шлите их ко мне, я Вам взамен говнокодеров, потом прибыль сравним :)
Я просто за годы работы видел СТОЛЬКО корпоративного говна, в котором даже суперспецы за адекватное количество времени разобраться не могли, что вот эти вот выпады «у нас люди пытаются писать качественно даже там, где это особо не нужно» вызывают у меня улыбку. Шлите их ко мне, я Вам взамен говнокодеров, потом прибыль сравним :)
А всё очень просто, по-моему.
Когда человек нанимается работать, то требования к его профессионализму и знаниям такие, будто его нанимают на разработку софта для Боинга.
Если бы честно писали «нужны мальчики-быдлокодеры, опытных специалистов просим не беспокоить, или потом не выпендриваться», то получили бы послушных и неразборчивых исполнителей.
Но ведь они же гордые! В каждой вакансии «3 года опыта в индустрии, знание А, Б, В, Г, Д, и, желательно фреймворка Ё» и т. п…
На собеседовании вас спрашивают по шаблоны проектирования, про умение выделять сущности, про инкапсуляцию… а потом швыряют в проект, где на всё это клали с прибором.
Когда человек нанимается работать, то требования к его профессионализму и знаниям такие, будто его нанимают на разработку софта для Боинга.
Если бы честно писали «нужны мальчики-быдлокодеры, опытных специалистов просим не беспокоить, или потом не выпендриваться», то получили бы послушных и неразборчивых исполнителей.
Но ведь они же гордые! В каждой вакансии «3 года опыта в индустрии, знание А, Б, В, Г, Д, и, желательно фреймворка Ё» и т. п…
На собеседовании вас спрашивают по шаблоны проектирования, про умение выделять сущности, про инкапсуляцию… а потом швыряют в проект, где на всё это клали с прибором.
Является ли художник-мультипликатор из студии Уолта Диснея хорошим художником? А Шагал — хороший художник?
Это такое проявление дзена, кторое может постичь каждый. Ни так не этак, и так и вот так. Всему есть место и всему найдется время.
Есть у вас время решить задачу правильно — решайте правильно. Иначе решайте быстро. Но решайте. Пытаться найти в себе Пикассо, работая в студии Диснея, как мимнимум не место. Да и не время, наверное.
Это такое проявление дзена, кторое может постичь каждый. Ни так не этак, и так и вот так. Всему есть место и всему найдется время.
Есть у вас время решить задачу правильно — решайте правильно. Иначе решайте быстро. Но решайте. Пытаться найти в себе Пикассо, работая в студии Диснея, как мимнимум не место. Да и не время, наверное.
Аминь.
Показалось, что многословно. Но раз многие этого не понимают, значит наверное Вы использовали нужное количество слов
Показалось, что многословно. Но раз многие этого не понимают, значит наверное Вы использовали нужное количество слов
Имхо, если рядовой разработчик не знает «говнокодить» ему или «кодить на вырост», то (с точки зрения компании в целом) это фейл конкретно его менеджера/тимлида (не объяснил правильно или не уволил непонятливого после N объяснений). Рядовой разработчик (не суперзвезда) вообще не должен принимать такие решения, это не в его компетенции.
Точно. Тем не менее, рядовому разработчику не лишним будет знать, чем руководствуется менеджер или тимлид. Если только, конечно, рядового разработчика вполне устраивает вечно оставаться рядовым разработчиком.
Как же я запарился работать с говнокодом после вот таких вот «практиков». Ведь именно все проблемы от этих ваших «давайте здесь сделаем проще, без ООП и SOLID» потом боком выходят следующим разработчикам. Одни сплошные менджеры, хендлеры и хелперы. Всюду. Логика размазана по слоям. Шаблон Specification? нет не слышал. Зато сделано 100500 if и switch. Слои? CQRS? изолированный домен? Та ну нах. Хендлеры и менджеры рулят! «Макконел, Фаулер, Эванс?» Ну да, что-то такое слышал про второго из них". и тут же «знаешь, ООП это не панацея». Писать говнокод — вот что плохо. Потому что кому-то потом с этим работать. Кому-то читать, офигевать, угадывать.
А ещё можно твердить, что у вас extream programming и код самоописуем, но при этом городить 3-4 экрана строчек кода в одном методе. Не знать, когда писать комментарии к коду (подсказка: для классов, публичных методов, в местах фикса багов и в местах, где нужно краткое пояснения почему так, а не иначе) и вообще их не писать. При этом покрытие юнит-тестами стремится к 0. Contineous Integration? Только на собираемость проекта. Dependndency injection? Да, есть зачем-то. Только не ясно зачем( юнит-тесто же не пишем как следует, время, ай ай ай). А писали бы, сразу архитектурные косяки повылезали бы.
После быстрого хотфикса, да даже в случае просто некачественного кода поддержка его сжирает в 100500 раз больше времени. Если он не покрыт тестами, то его рефакторинг просто становится опасен. Если нет интеграционных тестов, то регресс-тестинг становится невероятно утомительным и всё падает. Если не следовать SOLID а только всяким приколам с ИТ конференций в духе KISS или DRY то получаем всё тот же говнокод, который теперь почему-то считается kissed and dry. И считается только лишь самим автором. А оценивать-то должен тот, кому с этим кодом разбираться.
А ещё время сокращает гордое заявление об отсутствии у проекта документации, потому что код самоописуем. Нет, я приемлю такое, но где код самоописуем? Где?!
За 7 лет разработки на 10+ проектах мне приходилось встречать и местных гуру, которые с энтузиазмом дебажат исходники .net но с трудом понимают, как писатьк код так, чтобы его могли использовать другие без пол литра. И нормальных разработчиков( человек 5 всего), которые пишут код так, что читаешь его как открытую книгу и всё понятно. Даже система безопасности, даже если ты джуниор и никогда её раньше не видел.
Я понимаю всю озабоченность расп… ом программистов. Хабр и ЯП на на другом мониторе, когда мало времени — зло. Но давайте не скатываться в откровенный непрофессионализм и писать плохой код Парень из исповеди 1 просто должен потерпеть пару тройку лет, пока его не будут воспринимать как джуна. Это чисто психологический момент. Ну и стоит ему свои слова пару раз подтвердить цитатами из книг. И да, ему попались откровенные говнокодеры с большим опытом сидения в одном проекте.
Но больше всего меня удивил вывод:
"- Меньше классов, меньше функций, меньше кнопок, меньше связей и вообще — меньше.
— Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
и т.д."
потому что хороший код и не предполагает этого. Как бы все выводы-то логичны. Потому он и хорош, выверенный, оттестированный и проверенный.
PS разберитесь и освойте наконец-то работу с предметной областью и шаблоны проектирования. И тогда каждый новый разработчик будет на много быстрее вливаться в проект, а правки будут вноситься легко и непринуждённо.
А ещё можно твердить, что у вас extream programming и код самоописуем, но при этом городить 3-4 экрана строчек кода в одном методе. Не знать, когда писать комментарии к коду (подсказка: для классов, публичных методов, в местах фикса багов и в местах, где нужно краткое пояснения почему так, а не иначе) и вообще их не писать. При этом покрытие юнит-тестами стремится к 0. Contineous Integration? Только на собираемость проекта. Dependndency injection? Да, есть зачем-то. Только не ясно зачем( юнит-тесто же не пишем как следует, время, ай ай ай). А писали бы, сразу архитектурные косяки повылезали бы.
После быстрого хотфикса, да даже в случае просто некачественного кода поддержка его сжирает в 100500 раз больше времени. Если он не покрыт тестами, то его рефакторинг просто становится опасен. Если нет интеграционных тестов, то регресс-тестинг становится невероятно утомительным и всё падает. Если не следовать SOLID а только всяким приколам с ИТ конференций в духе KISS или DRY то получаем всё тот же говнокод, который теперь почему-то считается kissed and dry. И считается только лишь самим автором. А оценивать-то должен тот, кому с этим кодом разбираться.
А ещё время сокращает гордое заявление об отсутствии у проекта документации, потому что код самоописуем. Нет, я приемлю такое, но где код самоописуем? Где?!
За 7 лет разработки на 10+ проектах мне приходилось встречать и местных гуру, которые с энтузиазмом дебажат исходники .net но с трудом понимают, как писатьк код так, чтобы его могли использовать другие без пол литра. И нормальных разработчиков( человек 5 всего), которые пишут код так, что читаешь его как открытую книгу и всё понятно. Даже система безопасности, даже если ты джуниор и никогда её раньше не видел.
Я понимаю всю озабоченность расп… ом программистов. Хабр и ЯП на на другом мониторе, когда мало времени — зло. Но давайте не скатываться в откровенный непрофессионализм и писать плохой код Парень из исповеди 1 просто должен потерпеть пару тройку лет, пока его не будут воспринимать как джуна. Это чисто психологический момент. Ну и стоит ему свои слова пару раз подтвердить цитатами из книг. И да, ему попались откровенные говнокодеры с большим опытом сидения в одном проекте.
Но больше всего меня удивил вывод:
"- Меньше классов, меньше функций, меньше кнопок, меньше связей и вообще — меньше.
— Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
и т.д."
потому что хороший код и не предполагает этого. Как бы все выводы-то логичны. Потому он и хорош, выверенный, оттестированный и проверенный.
PS разберитесь и освойте наконец-то работу с предметной областью и шаблоны проектирования. И тогда каждый новый разработчик будет на много быстрее вливаться в проект, а правки будут вноситься легко и непринуждённо.
Что-то многова-то у вас абсолютов тут, как мне кажется. И какой-то фуфуфу снисходительный тон.
Как я выше писал, речь в статье не о том, что надо «фигак-фигак и в продакшен», а что не стоит упарываться по ООП и юзать все в меру экономической эффективности и здравого смысла. Клиенту (даже если вы делаете продукт для себя, я бы даже сказал особенно если вы делаете продукт для себя) надо адекватное соотношение цена-качество, а не космолет.
Если статья о том, о чём говорите вы — то она написана предельно неправильно. Как раз в стиле «фигак-фигак и в продакшен». Потому что все претензии автора в тексте — не к говнокоду упоротого ООП, а к собственно ООП, паттернам проектирования и прочим важным штукам, которые позволяют потом править бизнес-логику модуля за 0.5-1 sp вместо 2-4х, но для первичной реализации требуют несколько большего времени.
Вместо шаблонов проектирования, думаю, лучше освоить азы функционального программирования. Во-первых, проще, во-вторых, эти после этого «шаблоны» будут рождаться сами собой. Польза от них в основном в области терминологии (что тоже важно).
Подписываюсь тут под каждым словом.
Плюс — дело не только в грамотно нормализованной модели, знании SOLID и О-нотации, дело вообще в таком замечательном понятии как «обеспечение качества ПО». Вот с пониманием что это такое, у бизнеса реально большие проблемы. Что наплевательское отношение к такой на первый взгляд хрени, как проектирование классов и интерфейсов, как рефакторинг и код ревью, в общем к тому, на чем бабки не отбить, в дальнейшем выливается в бесконечные багфиксы и кастомер инциденты.
Качество кода — это не абстракция, качество кода реально оценивается с помощью кучи метрик, существует четкая зависимость времени, затраченного на поддержку кода от его качества. Но не понимают же, что условный день, потраченный на нормальную архитектуру, даже три дня, потраченных на рефакторинг говнокода, потом сэкономят условные две недели/месяц на багфиксинге. И хорошо, если дело еще обойдется просто багфиксингом, многие проекты, «написанные просто», реанимации уже не подлежат, такие полуживые трупы на искусственном дыхании.
Причина? Опять-таки, среднестатистический уровень компетенции людей, принимающих административные решения и распределяющих ресурсы проекта. Вроде бы на хабре слышал хорошую фразу — «вчера он порошком торговал, а сегодня менеджер проекта».
Плюс — дело не только в грамотно нормализованной модели, знании SOLID и О-нотации, дело вообще в таком замечательном понятии как «обеспечение качества ПО». Вот с пониманием что это такое, у бизнеса реально большие проблемы. Что наплевательское отношение к такой на первый взгляд хрени, как проектирование классов и интерфейсов, как рефакторинг и код ревью, в общем к тому, на чем бабки не отбить, в дальнейшем выливается в бесконечные багфиксы и кастомер инциденты.
Качество кода — это не абстракция, качество кода реально оценивается с помощью кучи метрик, существует четкая зависимость времени, затраченного на поддержку кода от его качества. Но не понимают же, что условный день, потраченный на нормальную архитектуру, даже три дня, потраченных на рефакторинг говнокода, потом сэкономят условные две недели/месяц на багфиксинге. И хорошо, если дело еще обойдется просто багфиксингом, многие проекты, «написанные просто», реанимации уже не подлежат, такие полуживые трупы на искусственном дыхании.
Причина? Опять-таки, среднестатистический уровень компетенции людей, принимающих административные решения и распределяющих ресурсы проекта. Вроде бы на хабре слышал хорошую фразу — «вчера он порошком торговал, а сегодня менеджер проекта».
А могли бы поделиться ссылка на английский источник? Я бы своей комманде раздал. Спасибо.
Вот. За последние пару дней текст вопроса был отредактирован настолько, что потерял первоначальный смысл (да и тему прикрыли). Теперь он называется «кто бы мне подсказал, как правильно», без затрагивания глубинных причин. Жаль.
Как человек, повидавший проект, которому уже по-моему 10 лет, написанный на asp.classic (кто вообще в 2014 году знает, что это такое?) хотел бы предложить всем оптимизаторам почитать свой говнокод трехлетней давности, и заставить себя немного нарастить его функционал, после чего стабилизировать и протестировать. Проклянете все на свете. Почему-то авторы таких пассажей всегда забывают, что есть проекты которые живут по 10 лет и больше, без переписываний с нуля, потому что переписать его просто уже невозможно, т.к. в мире существуют не только сайты-визитки но и огромные системы, в которые уже вложено огромное количество человеколет.
Отдельно позабавило «новое требование — новая система». Ну идите скажите директору, что для того чтобы добавить вот тут маленькую кнопочку и тут вылетающего верблюда нужно все переписать, тото он будет рад.
Проблема оверинжиниринга встречается, но не стоит так остро, я ни разу не встречал иерархию из 18 классов и тому подобный бред, а вот копирование куска кода в 30+ мест встречал и исправления во все эти места вносил, не очень весело, скажу я вам.
Отдельно позабавило «новое требование — новая система». Ну идите скажите директору, что для того чтобы добавить вот тут маленькую кнопочку и тут вылетающего верблюда нужно все переписать, тото он будет рад.
Проблема оверинжиниринга встречается, но не стоит так остро, я ни разу не встречал иерархию из 18 классов и тому подобный бред, а вот копирование куска кода в 30+ мест встречал и исправления во все эти места вносил, не очень весело, скажу я вам.
хотел бы предложить всем оптимизаторам почитать свой говнокод трехлетней давности, и заставить себя немного нарастить его функционал, после чего стабилизировать и протестировать. Проклянете все на свете.
Случалось такое. И проекты трёхлетней давности наращивал. И пятилетней. Случалось даже развивать (или адаптировать к новой задаче) код, которому 10 лет. В большинстве случаев особых проблем не возникало, хотя ни ООП, ни комментариев в коде практически не было.
Вы живете с большим технологическим кредитом. Есть большой риск (не говорю что это точно случится), что рано или поздно произойдет что-то из следующего:
1. Вашим программистам это надоест, а передать на поддержку новым вы не сможете, потому что фичи внедрены абы как, документации нет, платформа устеревшая, кругом говнокод
2. Вас накроют «кредиторы». Т.е. из-за большого числа неочевидных зависимостей и других технологических ошибок начнется лавинообразный процесс разваливания системы, и она перейдет в состояние «поправили тут, отвалилось там», выйти их которого будет уже почти невозможно. С вашей т.з. виноваты будут программисты-идиоты, потому что они на столько тупые обезьяны, что не могут ПРОСТО ДОБАВИТЬ ГАЛОЧКУ ЧТОБЫ НИЧЕГО НИГДЕ ПРИ ЭТОМ НЕ СЛОМАТЬ, ЧТО ЗА ИДИОТЫ, ЗАКАЗЧИК УЖЕ ЗВОНИЛ ТРИ РАЗА, но это будет не совсем так.
Я не придерживаюсь точки зрения, что всегда нужно переписывать все с нуля, более того, считаю её неверной. Необходимо поддерживать разумный баланс долгов и расплаты с ними. Да можно и, более того, нужно перед релизом или выставкой «лепить на горячую» говнокод, чтобы можно было показать, но это значит, что после выставки вы обязаны запланировать время на то, чтобы привести кодовую базу в надлежащее состояние (отдать долги). Вы же, судя по всему, предпочитаете подход «уже сделали это, пофигу как, работает, теперь прикрутите мне сверху замок, а на него флюгер с золотым петушком».
Разумеется речь в данном случае не идет о проектах которые сделал и забыл, там да, можно делать что хочешь, потому что после подписания документов и перевода денег этот сайтик вам будет совершенно до лампочки, но тогда нужно подбирать людей с соответствующим складом характера. Лично я встречал довольно много разработчиков, считающих подход «компилируется значит работает» абсолютно правильным, но почему-то на собеседованиях все просят рассказать про красно-черное дерево, а в реальных проектах делать лишь бы работало.
Если вы ведете бизнес так, что у вас нет ресурсов (временных, денежных) на то, чтобы поддерживать тот продукт, который всех кормит в надлежащем состоянии, то вы, возможно, не очень хороший менеджер (оценочное суждение).
1. Вашим программистам это надоест, а передать на поддержку новым вы не сможете, потому что фичи внедрены абы как, документации нет, платформа устеревшая, кругом говнокод
2. Вас накроют «кредиторы». Т.е. из-за большого числа неочевидных зависимостей и других технологических ошибок начнется лавинообразный процесс разваливания системы, и она перейдет в состояние «поправили тут, отвалилось там», выйти их которого будет уже почти невозможно. С вашей т.з. виноваты будут программисты-идиоты, потому что они на столько тупые обезьяны, что не могут ПРОСТО ДОБАВИТЬ ГАЛОЧКУ ЧТОБЫ НИЧЕГО НИГДЕ ПРИ ЭТОМ НЕ СЛОМАТЬ, ЧТО ЗА ИДИОТЫ, ЗАКАЗЧИК УЖЕ ЗВОНИЛ ТРИ РАЗА, но это будет не совсем так.
Я не придерживаюсь точки зрения, что всегда нужно переписывать все с нуля, более того, считаю её неверной. Необходимо поддерживать разумный баланс долгов и расплаты с ними. Да можно и, более того, нужно перед релизом или выставкой «лепить на горячую» говнокод, чтобы можно было показать, но это значит, что после выставки вы обязаны запланировать время на то, чтобы привести кодовую базу в надлежащее состояние (отдать долги). Вы же, судя по всему, предпочитаете подход «уже сделали это, пофигу как, работает, теперь прикрутите мне сверху замок, а на него флюгер с золотым петушком».
Разумеется речь в данном случае не идет о проектах которые сделал и забыл, там да, можно делать что хочешь, потому что после подписания документов и перевода денег этот сайтик вам будет совершенно до лампочки, но тогда нужно подбирать людей с соответствующим складом характера. Лично я встречал довольно много разработчиков, считающих подход «компилируется значит работает» абсолютно правильным, но почему-то на собеседованиях все просят рассказать про красно-черное дерево, а в реальных проектах делать лишь бы работало.
Если вы ведете бизнес так, что у вас нет ресурсов (временных, денежных) на то, чтобы поддерживать тот продукт, который всех кормит в надлежащем состоянии, то вы, возможно, не очень хороший менеджер (оценочное суждение).
Очень трудно работать с таким начальником, который всегда думает, что он лучше бы запрограммил, потому что «ну я же сам был программистом, я понимаю что к чему».
А я бы после второго такого «подката» подал бы заявление на увольнение. Такая метода только с джунами да терпилами легко прокатывает.
Отличный подход! Я бы просто сказал, что сделать дерьмо можно быстро и если вам очень хочется — мне несложно.
А в следующий раз я предложил бы вам также «махнуться» местами, когда заказчик предлагал бы делать откровенную дурь, а вы убеждали бы команду в том, что он упёрся и ничего не очет слушать. Попробовал бы поспорить на вашу зарплату, что если вы дадите мне с ним поговорить как следует, я смогу переубедить его.
И сделал бы я это не потому, что считаю, что я могу выполнять вашу работу лучше вас (если бы у меня получилось, для вас это был бы откровенный позор), а лишь чтобы проиллюстрировать вам, что логика «я — босс, потому что я вас круче» не работает среди специалистов. Каждый должен заниматься своим делом. А если вы считаете, что ваш подчиненный свою работу делает хуже вас — дилетанта, значит ему не место в вашей команде.
И — да — я бы тоже или ушел от вас и друзьям бы про этот случай рассказывал, если решат наниматься к вам, или просто перешел в соседний проект к адекватному руководителю.
А в следующий раз я предложил бы вам также «махнуться» местами, когда заказчик предлагал бы делать откровенную дурь, а вы убеждали бы команду в том, что он упёрся и ничего не очет слушать. Попробовал бы поспорить на вашу зарплату, что если вы дадите мне с ним поговорить как следует, я смогу переубедить его.
И сделал бы я это не потому, что считаю, что я могу выполнять вашу работу лучше вас (если бы у меня получилось, для вас это был бы откровенный позор), а лишь чтобы проиллюстрировать вам, что логика «я — босс, потому что я вас круче» не работает среди специалистов. Каждый должен заниматься своим делом. А если вы считаете, что ваш подчиненный свою работу делает хуже вас — дилетанта, значит ему не место в вашей команде.
И — да — я бы тоже или ушел от вас и друзьям бы про этот случай рассказывал, если решат наниматься к вам, или просто перешел в соседний проект к адекватному руководителю.
Ну тут не всегда дерьмо. Важен баланс.
Вы тут тоже в позу откровенную не становитесь. У менеджера есть определенный бюджет в который нужно вписаться.
Я в таких случаях, когда не хватает ресурсов обычно спрашивал у коллеги:
— Сколько нужно времени чтобы сделать простое рабочее решение сейчас?
— 1 день
— А вариант который ты считаешь правильным?
— 2 недели
— А зачем нам тратить сейчас 2 недели? Какие преимущества это нам даст?
— Ну если будем расширять функционал Х, или например нужно будет масштабировать систему по N пользователей это будет проще.
— Тогда предлагаю сейчас написать функционала ровно столько сколько нужно, чтобы работало, а когда будем делать X или N тогда разработаем нормальное решение. А сейчас может заложим в это простое решение вариацию на дальнейший легкий рефакторинг. Сколько на это нужно времени?
— Нуу… Наверное полтора дня.
В итоге обычно останавливаемся на этом, но я не забываю сделать пометку. А через некоторое время, когда становится ясно что не Х и не N не будет я показываю результат с точки зрения ресурсов этому коллеге. Не с точки зрения «Ага, мля, ты чудак тут не прав был» а с позиции «Смотри как мы с тобой тут клево сэкономили ресурсов и выдали рабочий вариант пользователям».
И вообще почему-то считается что простой вариант = говнокод, с чем я совсем не согласен.
Вы тут тоже в позу откровенную не становитесь. У менеджера есть определенный бюджет в который нужно вписаться.
Я в таких случаях, когда не хватает ресурсов обычно спрашивал у коллеги:
— Сколько нужно времени чтобы сделать простое рабочее решение сейчас?
— 1 день
— А вариант который ты считаешь правильным?
— 2 недели
— А зачем нам тратить сейчас 2 недели? Какие преимущества это нам даст?
— Ну если будем расширять функционал Х, или например нужно будет масштабировать систему по N пользователей это будет проще.
— Тогда предлагаю сейчас написать функционала ровно столько сколько нужно, чтобы работало, а когда будем делать X или N тогда разработаем нормальное решение. А сейчас может заложим в это простое решение вариацию на дальнейший легкий рефакторинг. Сколько на это нужно времени?
— Нуу… Наверное полтора дня.
В итоге обычно останавливаемся на этом, но я не забываю сделать пометку. А через некоторое время, когда становится ясно что не Х и не N не будет я показываю результат с точки зрения ресурсов этому коллеге. Не с точки зрения «Ага, мля, ты чудак тут не прав был» а с позиции «Смотри как мы с тобой тут клево сэкономили ресурсов и выдали рабочий вариант пользователям».
И вообще почему-то считается что простой вариант = говнокод, с чем я совсем не согласен.
Это очень круто. Побольше бы таких, как вы.
Сила действия рава силе противодействия. Я проиллюстрировал позицию, симметричную той, которую озвучил предыдущий оратор.
Адекватный руководитель и умный разработчик всегда найдут общий язык и по срокам, и по техническому долгу. Если каждый выслушает другого, в итоге будет консенсус. В худшем случае (было и такое) руководитель говорил мне «делай срочно, надо завтра», на что реально получал ответ открытым текстом «сделаю криво, будет дрянь, потом придется переделать, имей в виду» и этим ответом был вполне удовлетворен. Не пытаясь при этом говорить мне «спорим, я лучше сделаю!»
Кстати, очень тревожная тенденция. Не знаю, с чем связана. Многие хорошие опытные программисты, перепрыгнув на ветку менеджмента, становятся совершенно неадекватными руководителями. И как будто забывают не только принципы разработки, но и здравый смысл. Я сам такое наблюдал — один мой техлид практически потерял друга в такой ситуации. Печально и необъяснимо.
Адекватный руководитель и умный разработчик всегда найдут общий язык и по срокам, и по техническому долгу. Если каждый выслушает другого, в итоге будет консенсус. В худшем случае (было и такое) руководитель говорил мне «делай срочно, надо завтра», на что реально получал ответ открытым текстом «сделаю криво, будет дрянь, потом придется переделать, имей в виду» и этим ответом был вполне удовлетворен. Не пытаясь при этом говорить мне «спорим, я лучше сделаю!»
Кстати, очень тревожная тенденция. Не знаю, с чем связана. Многие хорошие опытные программисты, перепрыгнув на ветку менеджмента, становятся совершенно неадекватными руководителями. И как будто забывают не только принципы разработки, но и здравый смысл. Я сам такое наблюдал — один мой техлид практически потерял друга в такой ситуации. Печально и необъяснимо.
я предлагаю исполнителю спор на всю его з/п за месяц
Не совсем понял, 15 лет программистом или всего 15 лет?
Да, наверное слишком тонкая шутка для нашего цирка. Я это к тому, что в 15 лет это нормально представлять себе компанию этакой армейской структурой, где командир всегда прав, а солдаты это говно на твоих сапогах. А у взрослых это называется неуважением. И ни один себя уважающий человек не будет работать (долго) в такой атмосфере неприкрыто нарушенных рабочих границ. С начальником, который кичится своим невежеством, раздутым самомнением и панибратским отношением к подчиненным.
С той же позиции дам совет — не давите своим авторитетом. Недавно едва не потерял талантливого парня, только потому что примерно в таком тоне начал рассказывать что ему следует выбросить «редактор X» и поставить «IDE Y», потому что ошибку которую он искал 3-4 часа я нашел за 15 минут.
Будьте примером, а не тираном.
Будьте примером, а не тираном.
Зря вы «давили авторитетом», но людей, которые до сих пор используют редакторы, наверно нужно уже в принудительном порядке заставлять переходить на IDE. Даже самый навороченный и заставленный плагинами vim/sublime/[ваш вариант] не идет в сравнение с топовыми IDE.
Если у вас больше опыта в чем-то это отлично, но вы неправильно его используете. Надо не кичиться этим, а делиться.
Делиться можно по-разному:
Все способы работают, проверено лично.
Плюсы:
Делиться можно по-разному:
- статьи в корпоративном вики
- оформить в виде доклада, собрать всех и рассказать в переговорке
- «парное программирование» — сесть с разработчиком и вместе начать делать
Все способы работают, проверено лично.
Плюсы:
- в следующий раз разработчик сделает фичу быстрее
- к вам будут лучше относиться, ваш авторитет поднимется
- когда учишь других — структурируешь свои знания, сам начинаешь лучше понимать некоторые вещи
Почитал я пост и комменты, и не понимаю, почему вообще красивый код ставится в противоположность простому и короткому. Короткая программа и программа в стиле «тяп-ляп», вообще говоря, — вещи ортогональные.
Во-первых, на мой взгляд, простое и изящное решение — это как раз большая красота, чем обобщённая реализация всего, что ни попадя. Умение упихнуть код из трёх файлов с десятком классов в одну небольшую функцию — это и мастерство, и искусство одновременно. Читать короткую программу — одно удовольствие.
Во-вторых, возможность повторного использования кода — это всё важно. Но при этом надо всегда помнить, что сложность — враг надёжности. Программу, которая умещается на 1 экран, можно окинуть взглядом и понять, чего от неё ждать. Как только поток исполнения размазывается по нескольким местам, понять логику по исходникам становится невероятно трудно. Это влечёт за собой ошибки при сопровождении. Дописали чуть-чуть, не учли каких-то особенностей реализации, и в результате — баг. Покрыть всё тестами можно, отловить тем самым все сложные баги — это фантастика.
Как обычно, молясь, не стоит лоб расшибать. Есть места, где сложная компонентная иерархия уместна (например, вы разрабатываете OpenSceneGraph, которым будут пользоваться тысячи людей с совершенно разными задачи). Есть места, где уместны свой язык для описания конфигурации, умная сериализация всех объектов, генерация схем баз данных, метапрограммирование (например, если вы разрабатываете 1С: Предприятие). Но если реально нет бизнес-цели обобщать код, то это не только не делает его красивее, но и ухудшает его по многим параметрам.
Я уверен, что синьор-разработчики, которые указывали новичку на необходимость упростить код, имели в виду именно это — перестать плодить ненужные строки исходников и сделать код короче, проще, надёжнее и легче в сопровождении.
Во-первых, на мой взгляд, простое и изящное решение — это как раз большая красота, чем обобщённая реализация всего, что ни попадя. Умение упихнуть код из трёх файлов с десятком классов в одну небольшую функцию — это и мастерство, и искусство одновременно. Читать короткую программу — одно удовольствие.
Во-вторых, возможность повторного использования кода — это всё важно. Но при этом надо всегда помнить, что сложность — враг надёжности. Программу, которая умещается на 1 экран, можно окинуть взглядом и понять, чего от неё ждать. Как только поток исполнения размазывается по нескольким местам, понять логику по исходникам становится невероятно трудно. Это влечёт за собой ошибки при сопровождении. Дописали чуть-чуть, не учли каких-то особенностей реализации, и в результате — баг. Покрыть всё тестами можно, отловить тем самым все сложные баги — это фантастика.
Как обычно, молясь, не стоит лоб расшибать. Есть места, где сложная компонентная иерархия уместна (например, вы разрабатываете OpenSceneGraph, которым будут пользоваться тысячи людей с совершенно разными задачи). Есть места, где уместны свой язык для описания конфигурации, умная сериализация всех объектов, генерация схем баз данных, метапрограммирование (например, если вы разрабатываете 1С: Предприятие). Но если реально нет бизнес-цели обобщать код, то это не только не делает его красивее, но и ухудшает его по многим параметрам.
Я уверен, что синьор-разработчики, которые указывали новичку на необходимость упростить код, имели в виду именно это — перестать плодить ненужные строки исходников и сделать код короче, проще, надёжнее и легче в сопровождении.
>>Меньше классов, меньше функций, меньше кнопок, меньше связей и вообще — меньше.
Можно все уместить в один файл и в одну строку, кому от этого станет лучше?
>>Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
Вася не напишет, Петя не напишет, Вова не напишет — получится 6 копий одного и того же
>>Не пишите функции и методы класса до того, как у них появится пользователь. Т.е. сперва где-то появился вызов метода и только потом появился сам метод.
Попробуйте написать какое-нибудь API или компонент на продажу подобным способом
>>Вам не нужно три уровня наследования с шаблонным классом посередине.
Если я пишу программу про животных, то там будет и Животное и Млекопитающее и Корова — вот вам и три уровня
>> Стандартный модуль вполне способен решить вашу задачу — почитайте еще раз документацию.
Уж вам то лучше знать
>>SQL — не единственное в мире хранилище. Очень много всего можно запросто хранить прямо в файлах в JSON.
SQL это structured query language, это язык, чтобы запросы выполнять к данным. В языке нельзя хранить, а файлы Json не умеют выполнять запросы
>>Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
== Не думайте о системе на вырост, просто переписывайте ее каждые полгода
>>Этот алгоритм O(n^2) можно не оптимизировать до O(n logn), потому что в данном месте n никогда не больше 5, поскольку означает число задействованных пальцев на руке.
Когда n при продакшене вдруг станет миллионом, а не 5 как на ваших локальных тестах, то ваша фраза будет «не знаю почему так все тормозит, у меня нормально было»
>> SVN — отличная система контроля версий. Особенно, когда вместе с вами её используют непрограммисты, работающие с вами над одним проектом.
Ну если вам не нужно code review, то возможно. Иначе всем будет очень весело с откатами.
>>Вам действительно нужно попиксельное освещение для визуализации мат.модели или стандартного GL_SMOOTH хватит? И, кстати, мы будем показывать её на выставке на 7-летнем ноутбуке со встроенной графикой.
Лучше тогда не идите на выставку, зачем позориться
>>Правда думаете, что цикл на итераторах работает быстрее, чем на индексах, особенно если сравнить первый и второй со временем доступа к диску?
Если на миллион доступом к диску будет один цикл, то да. Но обычно наоборот. Кстати у меня SSD.
>>Похожие классы в двух проектах — не повод связать один с другим. Считайте это случайным совпадением. Если вы сделаете общий класс, то отныне, при любом изменении, вам придется думать о двух проектах одновременно. Стоит ли это того? Вряд ли.
Зачем вобще нужны компоненты и модули? Лучше писать как есть, в инлайне так сказать, зато об обратной совместимости думать не придется!
>>Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую часть программ прототипирования интерфейсов
Можно вывезти Васю из колхоза, но колхоз из Васи не вывезешь. А чего уж там! Это, вам не рокет-сайенс!
Можно все уместить в один файл и в одну строку, кому от этого станет лучше?
>>Не пишите обобщенную функцию, если её функционал не встретился минимум три раза в разных местах.
Вася не напишет, Петя не напишет, Вова не напишет — получится 6 копий одного и того же
>>Не пишите функции и методы класса до того, как у них появится пользователь. Т.е. сперва где-то появился вызов метода и только потом появился сам метод.
Попробуйте написать какое-нибудь API или компонент на продажу подобным способом
>>Вам не нужно три уровня наследования с шаблонным классом посередине.
Если я пишу программу про животных, то там будет и Животное и Млекопитающее и Корова — вот вам и три уровня
>> Стандартный модуль вполне способен решить вашу задачу — почитайте еще раз документацию.
Уж вам то лучше знать
>>SQL — не единственное в мире хранилище. Очень много всего можно запросто хранить прямо в файлах в JSON.
SQL это structured query language, это язык, чтобы запросы выполнять к данным. В языке нельзя хранить, а файлы Json не умеют выполнять запросы
>>Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
== Не думайте о системе на вырост, просто переписывайте ее каждые полгода
>>Этот алгоритм O(n^2) можно не оптимизировать до O(n logn), потому что в данном месте n никогда не больше 5, поскольку означает число задействованных пальцев на руке.
Когда n при продакшене вдруг станет миллионом, а не 5 как на ваших локальных тестах, то ваша фраза будет «не знаю почему так все тормозит, у меня нормально было»
>> SVN — отличная система контроля версий. Особенно, когда вместе с вами её используют непрограммисты, работающие с вами над одним проектом.
Ну если вам не нужно code review, то возможно. Иначе всем будет очень весело с откатами.
>>Вам действительно нужно попиксельное освещение для визуализации мат.модели или стандартного GL_SMOOTH хватит? И, кстати, мы будем показывать её на выставке на 7-летнем ноутбуке со встроенной графикой.
Лучше тогда не идите на выставку, зачем позориться
>>Правда думаете, что цикл на итераторах работает быстрее, чем на индексах, особенно если сравнить первый и второй со временем доступа к диску?
Если на миллион доступом к диску будет один цикл, то да. Но обычно наоборот. Кстати у меня SSD.
>>Похожие классы в двух проектах — не повод связать один с другим. Считайте это случайным совпадением. Если вы сделаете общий класс, то отныне, при любом изменении, вам придется думать о двух проектах одновременно. Стоит ли это того? Вряд ли.
Зачем вобще нужны компоненты и модули? Лучше писать как есть, в инлайне так сказать, зато об обратной совместимости думать не придется!
>>Доска с маркером + телефон с камерой отлично заменяют UML-диаграммы и большую часть программ прототипирования интерфейсов
Можно вывезти Васю из колхоза, но колхоз из Васи не вывезешь. А чего уж там! Это, вам не рокет-сайенс!
Если я пишу программу про животных, то там будет и Животное и Млекопитающее и Корова — вот вам и три уровняА точно нужны обязательно все эти три уровня в любой программе «про животных»? Вроде даже Стив Макконел в «Code Complete» рекомендовал не больше трёх уровней иерархии классов и не более 7+-2 членов во всём иерархическом дереве классов (глава 6 «Классы», раздел 6.3 «Вопросы проектирования и реализации», специально поискал).
Выскажусь… Программирование, действительно, не самоценно. Но:
Ваше «правильно» не правильно.
«Правильно» — категория относительная. «Правильно» — это то, как вас (и только вас) устраивает. Декларированное в статье «правильно» — это «правильно» не разработчика. Кого угодно — рук. проектом, директора компании, пользователя, но не разработчика. Требовать от разработчика безусловно принять такое «правильно» — значит получить кого-угодно, но уже не разработчика. Оно действительно надо?!
У разработчика свое «правильно». И это замечательно. Вы просто не умеете это использовать.
Ах-ах… «фабрика абстрактных автоматизаторов еще не дописана». Ужас какой.
А он говорил, что задача не на три дня, а на месяц. Но, я же «руководитель группы разработки» — я лучше знаю! С какой стати меня должно интересовать, почему по его мнению — задача на месяц? Зачем мне знать, как вообще он её собрался решать? Объяснить ему, зачем это мне нужно именно через три дня?! А не много ли чести?
Ну так же?
А может, это все-таки я тупой. Когда последний раз я смотрел код проекта? Не вообще код, а код нашего проекта. Могу я сказать, что я в нем разбираюсь? Лучше, чем мои разработчики? А если нет — может быть стоит перестать игнорировать их мнение?
«В три раза лучше»
Зависимость между временем и качеством, действительно, не линейная. Но, это не значит, что её совсем нет.
Вы уверены, что назначенный вами срок – тот самый, что дает те самые 80% качества? Конкретно у этого разработчика? Или вас устроит и условные 50%, которые он способен выдать за это время? А разработчик в курсе, что вам сейчас нужно «лишь бы запускалось»?
Это моя цель «работающая программа, неважно как написанная». Моя, как руководителя. Моя, как весьма посредственного руководителя. Но, это точно не цель моего разработчика. Это меня не интересует «как написанная». Его это очень даже интересует. Ему её сопровождать — не мне.
И если я хочу приблизиться к понятию «хороший руководитель», то меня должно начать интересовать «как».
«Красивый» код бывает
Любой код, удовлетворяющий всего двум простым критериям — «красивый».
Код должен легко читаться. Код должно быть легко менять. Если ваши разработчики пишут «красивый» код, то «ошибки, компромиссы и проблемы производительности» которые он содержит — не проблема.
И да… Пишите код исходя из того, что все программисты, которые будут сопровождать вашу программу, — склонные к насилию психопаты, знающие, где вы живете. Стив Макконел.
Ваше «правильно» не правильно.
«Правильно» — категория относительная. «Правильно» — это то, как вас (и только вас) устраивает. Декларированное в статье «правильно» — это «правильно» не разработчика. Кого угодно — рук. проектом, директора компании, пользователя, но не разработчика. Требовать от разработчика безусловно принять такое «правильно» — значит получить кого-угодно, но уже не разработчика. Оно действительно надо?!
У разработчика свое «правильно». И это замечательно. Вы просто не умеете это использовать.
Ах-ах… «фабрика абстрактных автоматизаторов еще не дописана». Ужас какой.
А он говорил, что задача не на три дня, а на месяц. Но, я же «руководитель группы разработки» — я лучше знаю! С какой стати меня должно интересовать, почему по его мнению — задача на месяц? Зачем мне знать, как вообще он её собрался решать? Объяснить ему, зачем это мне нужно именно через три дня?! А не много ли чести?
Ну так же?
А может, это все-таки я тупой. Когда последний раз я смотрел код проекта? Не вообще код, а код нашего проекта. Могу я сказать, что я в нем разбираюсь? Лучше, чем мои разработчики? А если нет — может быть стоит перестать игнорировать их мнение?
«В три раза лучше»
Зависимость между временем и качеством, действительно, не линейная. Но, это не значит, что её совсем нет.
Вы уверены, что назначенный вами срок – тот самый, что дает те самые 80% качества? Конкретно у этого разработчика? Или вас устроит и условные 50%, которые он способен выдать за это время? А разработчик в курсе, что вам сейчас нужно «лишь бы запускалось»?
Это моя цель «работающая программа, неважно как написанная». Моя, как руководителя. Моя, как весьма посредственного руководителя. Но, это точно не цель моего разработчика. Это меня не интересует «как написанная». Его это очень даже интересует. Ему её сопровождать — не мне.
И если я хочу приблизиться к понятию «хороший руководитель», то меня должно начать интересовать «как».
«Красивый» код бывает
Любой код, удовлетворяющий всего двум простым критериям — «красивый».
Код должен легко читаться. Код должно быть легко менять. Если ваши разработчики пишут «красивый» код, то «ошибки, компромиссы и проблемы производительности» которые он содержит — не проблема.
И да… Пишите код исходя из того, что все программисты, которые будут сопровождать вашу программу, — склонные к насилию психопаты, знающие, где вы живете. Стив Макконел.
Вы уверены, что назначенный вами срок – тот самый, что дает те самые 80% качества? Конкретно у этого разработчика? Или вас устроит и условные 50%, которые он способен выдать за это время? А разработчик в курсе, что вам сейчас нужно «лишь бы запускалось»?
Главная проблема заказчика — может быть сейчас, на этом этапе, ему действительно нужно, чтобы «лишь бы запускалось», но он не понимает, что и завтра это будет только «лишь бы запускалось». Построить на этой сопле вселенную он не сможет, а если попытается — она рухнет.
Заказчик может держать в голове целый план развития, но почему-то не делится им с разработчиками. Он-то сам знает, что собирается делать дальше, и все знают, что он собирается что-то делать и использовать эту штуку в качестве винтика какого-то своего механизма, но он не обясняет, какой это механизм, и что это за винтик, даже в общих чертах. Но почему-то рассчитывает на этот винтик и уверен, что он правильно сформулировал задачу и получит именно то, что представил себе в голове. А это не так.
Для разработчика — заказчик это я. Если я чего-то там не могу, не понимаю, и пытаюсь «построить на этой сопле вселенную», то это мои проблемы, как РГ, РП или еще какого руководителя. Разработчик-то тут причем?!
Вытащить из головы моего заказчика «план развития», это задача моя и моих аналитиков. Разработчики тут тоже не причем.
Ну а если я со своими разработчиками веду себя как — типа знаю, но не скажу, ибо ваши страдания меня радуют — то, о чем речь вообще?!
Вытащить из головы моего заказчика «план развития», это задача моя и моих аналитиков. Разработчики тут тоже не причем.
Ну а если я со своими разработчиками веду себя как — типа знаю, но не скажу, ибо ваши страдания меня радуют — то, о чем речь вообще?!
При том, что заказчик потом будет капать на мозги разработчику — «почему такое говно». Аргументы «ну ты же сам говорил — лишь бы запускалось» услышаны не будут: «ну ты же профессионал, должен понимать...»
Т.е. речь таки о «я со своими разработчиками веду себя как <вставте свой вариант>».
Вам не кажется, что в этом случае проблема не в разработчиках? Хотя, соглашусь, что в таком случае — это и их проблема. Но, по моему опыту, такого рода проблемы так или иначе решаются. И речь в статье малось о другом.
Вам не кажется, что в этом случае проблема не в разработчиках? Хотя, соглашусь, что в таком случае — это и их проблема. Но, по моему опыту, такого рода проблемы так или иначе решаются. И речь в статье малось о другом.
Главная проблема заказчика — может быть сейчас, на этом этапе, ему действительно нужно, чтобы «лишь бы запускалось», но он не понимает, что и завтра это будет только «лишь бы запускалось». Построить на этой сопле вселенную он не сможет, а если попытается — она рухнет.
А вот тут-то и кроется основная задача руководителя проекта — во-первых, угадывать, что именно хочет заказчик и насколько далеко идут его планы, а во-вторых объяснять этому заказчику, что он хочет.
Да-да, именно так: руководитель команды исполнителей должен доказательно объяснить заказчику, что тот хочет получить в результате.
Звучит дико? Отнюдь. Заказчик, как правило, сам толком не понимает, что он хочет. У него есть какие-то более-менее определенные фантазии насчет того, как что должно выглядеть в результате и куда это вс должно двигаться, но не более. Но если бы он мог корректно поставить задачу, то он был бы уже почти программист. Как говорил один мой преп в институте, «хорошая постановка задачи — уже половина решения».
Я раньше не понимал эту простую истину. Однажды я, учась фрилансу, попросил заказчика оформить мне ТЗ. Получил какую-то голубую муть. Начал с ним совместно эту муть перерабатывать… в итоге он слился. Потому что думать ему было очень и очень сложно. Его вообще не волновало, как программа должна вести себя в случае той или иной нештатной ситуации. Ему надо было решить проблему. То есть как раз то, что было описано в статье. И это было моей работой — поставить задачу корректно, решить, а потом убедить его в том, что он хотел именно это.
Так что когда заказчик говорит «добавьте вот тут такую фичу», а менеджер знает, что это или добавит костыль, или потребует переработки архитектуры проекта, он говорит заказчику: это либо сложно и долго, либо результат будет ненадежен. Вы какой вариант в данном случае предпочтете? Угадайте с трёх раз, что ответит заказчик, если планирует развивать проект. В худшем случае это будет «давайте сейчас тяп-ляп, а потом переделаем».
Ему надо было решить проблему.
Вся проблема в том, что «в двух словах» проблему описать, да ещё так, чтобы все понимали под этим одно и то же, никому ещё не удавалось. Поэтому, к сожалению, нужно описывать решение проблемы (не забывая про проблему, конечно). Наглядный пример проблемы:
— В коровнике коровы по колено в навозе.
И тут же появляется самое простое и быстрое решение — забить коров и снести нахрен коровник. Но оно почему-то не устраивает заказчика! Формулировка проблемы != формулировка задачи.
Ладно, положим, он попросил выработать другое решение, усложнив задачу: добавляется условие, что нужно обеспечить коровник средствами удаления навоза. И снова — предлагают неподходящее решение, давайте, мол, свернём в него реку, пусть она смоет оттуда всё. И вот так задача обрастает подробностями, он уже вроде бы всё сформулировал — но тут вдруг с него просят денег. Странно, казалось бы, с его стороны — проблема не решена, а платить уже надо! А с точки зрения тех, кто вырабатывал решения — проделана некоторая работа, выработаны и предложены варианты, они вполне закономерно не собирались делать эту работу бесплатно. Это называется «построение технического задания». Ах да, конечно, можно было бы этих трат избежать, если бы заказчик заранее предполагал, что так будет, и написал бы задание сам. Но это значит, что он уже выполнил часть работы, которую ожидал от исполнителя: вроде как хотелось дать ему простое описание проблемы и он как-нибудь сам, а пришлось писать какую-то штуку…
Итак, пишем техническое задание сами и выдаём его исполнителям. И теперь с них можно спрашивать только по заданию, их вообще теперь не должна волновать какую оно конкретную проблему призвано было решить. Им дали задание, они его решают, а проблема существует только у заказчика. Для них это не проблема, а всего лишь возможность заработать.
А теперь, в процессе внедрения решения, внезапно выясняется, что проект работает не очень гладко и коровы иногда попадают в устройства, удаляющие навоз. А задание уже сформировано, и достигнута договорённость, что за вот это задание заказчик получит определённую сумму. И тут хотят внести изменения! А проблема в том, что задание формулировал сам заказчик. Это его вина, что возможность ранения коров не была учтена. И закономерно, хотя и очень для него обидно, что придётся теперь нести дополнительные расходы (доработки проекта или утрата коров) — расплата за собственную ошибку.
Я могу продолжать. Проблема того, что заказчики не хотят внятно формулировать, чего хотят, кажется, неисчерпаема. И то, что исполнитель сам, без весьма активного участия заказчика, не сможет сделать из проблемы задачу, должно быть очень хорошо понятно.
Вся проблема в том, что «в двух словах» проблему описать, да ещё так, чтобы все понимали под этим одно и то же, никому ещё не удавалось. Поэтому, к сожалению, нужно описывать решение проблемы (не забывая про проблему, конечно).
Позволю дать вам совет.
Не нужно описывать решение проблемы. Если я весьма далек от уровня реализации — я понимаю, что обязательно что-то «забуду».
На самом деле, достаточно лишь убедиться в том, что задача будет решаться именно в том ключе, что и подразумевался при её постановке.
Самый простой способ — просто поговорить с исполнителем до того как. Самый надежный — попросить до исполнения написать vision. Его изучение, кроме всего прочего, даст актуальную информацию и о текущем состоянии.
просто поговорить с исполнителем до того как
Казалось бы, вот оно решение!
И тут появляются с одной стороны мудаки-заказчики, которые будут требовать бесплатно дорабатывать и дорабатывать проект, хотя он уже готов, просто поняли его неправильно или не до конца, потому, что этот мудак не смог внятно объяснить, чего ему надо; с другой стороны — мудаки-исполнители, которые не хотят привести решение к нормальному виду, чтобы оно могло «решить проблему» и требуют доплатить. И все они смеются над вашим советом.
А вот чтобы такого «веселья» не было, руководитель и должен составить грамотное (в том числе с юридической точки зрения) ТЗ. Чтобы заказчик поставил подпись под проектом и в оговоренные сроки (и за оговоренную плату) получил именно то, о чем условились. Любое изменение в ТЗ — за дополнительные деньги.
И если это условие ставится еще до начала составления сего документа, то самый большой риск, на который идет фирма — это потраченное впустую время самого менеджера, или его (менеджера) некомпетентность/недальновидность при составлении ТЗ.
Если в вашем проекте у заказчика «семь пятниц на неделе», если всё надо сделать «вчера», а работает вся система не пойми, как, так что даже сами разрабы не в курсе, что и как должно тут функционировать, то виноват в этом менеджер. И понял я лично это лишь в тот момент, когда мне, наконец, посчастливилось попасть в проект, где руководитель — умный и адекватный человек и профессионал своего дела.
И если это условие ставится еще до начала составления сего документа, то самый большой риск, на который идет фирма — это потраченное впустую время самого менеджера, или его (менеджера) некомпетентность/недальновидность при составлении ТЗ.
Если в вашем проекте у заказчика «семь пятниц на неделе», если всё надо сделать «вчера», а работает вся система не пойми, как, так что даже сами разрабы не в курсе, что и как должно тут функционировать, то виноват в этом менеджер. И понял я лично это лишь в тот момент, когда мне, наконец, посчастливилось попасть в проект, где руководитель — умный и адекватный человек и профессионал своего дела.
Не, ну хорошо, представьте, что ТЗ сделал исполнитель за отдельные деньги. И ближе к концу, на тестовом внедрении выяснилось, что в нём есть ошибка, в том смысле, что если делать по ТЗ, получается не очень. ТЗ подписано. Кто виноват и кто оплачивает доработки?
Я утверждаю, что заказчик, и это именно доработки и изменения ТЗ. Исполнитель не мог предугадать каких-то тонкостей предметной области заказчика, он имеет право на ошибку. Заказчик подписал это ТЗ и отвечает за его корректность со своей стороны.
Но заказчик с этим подходом не согласен. Мол, вы мне составили ТЗ, оно неправильное, вы плохо выполнили свою работу, которую я вам уже оплатил, и это ваши проблемы, что теперь вы основываясь на этой работе сделали что-то лишнее. Это ваши издержки, скажит заказчик.
Я утверждаю, что заказчик, и это именно доработки и изменения ТЗ. Исполнитель не мог предугадать каких-то тонкостей предметной области заказчика, он имеет право на ошибку. Заказчик подписал это ТЗ и отвечает за его корректность со своей стороны.
Но заказчик с этим подходом не согласен. Мол, вы мне составили ТЗ, оно неправильное, вы плохо выполнили свою работу, которую я вам уже оплатил, и это ваши проблемы, что теперь вы основываясь на этой работе сделали что-то лишнее. Это ваши издержки, скажит заказчик.
Есть такая полезная процедура — «переговоры». Это когда несколько умных людей собираются и обсуждают общую проблему и пытаются решить конфликты компромиссами. Не знаю, как у вас, а у меня менеджмент с заказчиками обычно «базарили» о нюансах реализации в течение всего процесса разработки.
О мелочах договаривались всегда. Показывали «сырые» версии программы, чтобы они подтвердили, что мы всё поняли правильно… Разумется, иногда мы ошибались и делали больше, чем планировали. И не возмущались. Иногда было наоборот и тогда они нам доплачивали. Договор и ТЗ нужны тогда, когда заказчик начинает «борзеть» в духе «а вот тут еще приделайте мне кнопочку „сделать офигенно“
О мелочах договаривались всегда. Показывали «сырые» версии программы, чтобы они подтвердили, что мы всё поняли правильно… Разумется, иногда мы ошибались и делали больше, чем планировали. И не возмущались. Иногда было наоборот и тогда они нам доплачивали. Договор и ТЗ нужны тогда, когда заказчик начинает «борзеть» в духе «а вот тут еще приделайте мне кнопочку „сделать офигенно“
Кого это волнует? Вы сейчас в позиции «Я художник, но меня никто не ценит».
Все что было придумано было придумано, потому что этого не было. Сейчас практически все возможные паттерны прописаны, языки программирования уже упираются в лингвальные пределы, поскольку представляют собой баланс между читабельностью и машинным кодом.
У вас какая-то коммунистическая ненависть к баблу, ебитде и акционерам.
Все что было придумано было придумано, потому что этого не было. Сейчас практически все возможные паттерны прописаны, языки программирования уже упираются в лингвальные пределы, поскольку представляют собой баланс между читабельностью и машинным кодом.
У вас какая-то коммунистическая ненависть к баблу, ебитде и акционерам.
А мне нравится оценивать сколько стоит мой код в деньгах. А оценивать очень просто — сколько стоила проблема(потери из-за того что не было такого функционала) или сколько прибыли (конверсии и т.д. ) прибавилось после решения проблемы с учетом того времени которое я затратил на решение этой проблемы(это расходы) — при некоторой выборки решений, проблем и оценок, можно сделать вывод о рыночной стоимости как программиста (интегратора).
Возможно, я выступлю непопулярно (в целом со статьёй я, если что, несогласен, почитайте мои другие комментарии), но скажу, что часто дебажить один метод на 50 (или даже 100) строк проще, чем 50 методов по одной строке.
Если вы пишете функцию, значит она должна иметь смысл сама по себе. А бить длинный, но целостный алгоритм на куски только из соображений того, что он длинный — глупость, сопоставимая с копипастой кода.
Главная проблема, в результате которой получаются статьи вроде этой, состоит в том, что программисты всё время ищут серебряную пулю. Люди вообще ленивые сволочи — им подавай универсальное решение. Думать головой ежеминутно в каждом конкретном случае им неохота. Пусть Фаулер думает — у него голова большая.
Если вы пишете функцию, значит она должна иметь смысл сама по себе. А бить длинный, но целостный алгоритм на куски только из соображений того, что он длинный — глупость, сопоставимая с копипастой кода.
Главная проблема, в результате которой получаются статьи вроде этой, состоит в том, что программисты всё время ищут серебряную пулю. Люди вообще ленивые сволочи — им подавай универсальное решение. Думать головой ежеминутно в каждом конкретном случае им неохота. Пусть Фаулер думает — у него голова большая.
дебажить один метод на 50 (или даже 100) строк проще, чем 50 методов по одной строке
А чем проще, можно пример?
По моим ощущением проще как раз когда все разбито на методы. Плюсы для меня:
- local variables не забиты кучей лишних переменных, реже нужно использовать watchers: количество переменных, которые вам надо одновременно анализировать, резко сокращается
- step into / step out сильно сокращают количество расставляемых брейкпоинтов
- стек вызванных функций с подсвеченными строками входа позволяет в любой момент вернуться в предыдущие состояния, какие тогда были у переменных значения
Вы, возможно, не имели дело с программами, «бизнес логика» которых включает в себя задачи математического моделирования. Случается так, что локальных переменных довольно много и лишних среди нет, любое разбиение на классы существенно вредит производительности, а главное — алгоритм прямой как стрела и бить его на методы — только запутывать.
Ну да. А еще превращают отладку в чехарду, когда методы мелкие.
step into / step out сильно сокращают количество расставляемых брейкпоинтов
Ну да. А еще превращают отладку в чехарду, когда методы мелкие.
Вы, возможно, не имели дело с программами, «бизнес логика» которых включает в себя задачи математического моделирования.Утрируя перефразируя и вспоминая историю вычислительной техники, получается забавнее: «Вы, возможно, не имели дело с программами, делающими то, для чего изначально было создано программирование.»… Что ж, да, так оно обычно и есть, как это ни грустно и ни смешно бы было.
А когда-то, лет 30-40 назад, такие программы были практически менйстримом (или одним из менйстримов) индустрии ПО и вычислительной техники…
В принципе суть статьи сводится к следующему: некачественная дешёвая техника выгоднее экономически и для бизнеса лучше продать три китайские дешёвые кофеварки + сервисное обслуживание к ним за пять лет, чем одну чуть подороже, которая прослужит двадцать лет. Точка зрения имеющая право на существование, но по сути противопоставляющая качество прибыли. Я как пользователь делаю очевидный выбор в пользу качества. Но я не организую бизнес. А организатор бизнеса делает очевидный выбор в пользу прибыли. И если прибыли будет не достаточно — он не организует бизнес и я, как пользователь, не получу вообще ничего — ни дешёвого и некачественного ни чуть подороже но отличное.
Статья рассматривает вопрос с одной стороны, не упоминая другую. Здесь всё говорит о том что программист это деньги его нанимателя и программисту нужно об этом помнить. А качество решения нанимателя не волнует — это уже головняк пользователя. В принятии любого решения всегда следует помнить об обеих сторонах процесса.
Ведь страшно же подумать — винда 7 тормозит на моём компе сегодня так же, как винда 95 тормозила 20 лет назад. А мощность компьютера выросла на два порядка! Мой телефон мощнее моего первого компьютера в 4 раза, а памяти имеет больше в сотни раз, но мне не всегда удаётся по нему позвонить из-за глюков и тормозов, а вот мой первый комьютер рисовал карту звездного неба и расчитывал экономику целой игровой вселенной.
Статья рассматривает вопрос с одной стороны, не упоминая другую. Здесь всё говорит о том что программист это деньги его нанимателя и программисту нужно об этом помнить. А качество решения нанимателя не волнует — это уже головняк пользователя. В принятии любого решения всегда следует помнить об обеих сторонах процесса.
Ведь страшно же подумать — винда 7 тормозит на моём компе сегодня так же, как винда 95 тормозила 20 лет назад. А мощность компьютера выросла на два порядка! Мой телефон мощнее моего первого компьютера в 4 раза, а памяти имеет больше в сотни раз, но мне не всегда удаётся по нему позвонить из-за глюков и тормозов, а вот мой первый комьютер рисовал карту звездного неба и расчитывал экономику целой игровой вселенной.
Разрешите поделиться моим скромным мнением по данной проблеме. Так как проблема комплексная, то и ответ будет составной:
> вам не нужны программисты. Вам надо решить проблему
С решением проблемы (надежнее, качественнее, дешевле, ...) справляется Автоматизированная Информационная Система и вы не можете на позиции директора ее реализовать самостоятельно тогда вам нужны исполнители и так повелось, что они инженеры, программисты и т.д. Итак, для решения вашей проблемы НУЖНЫ ИСПОЛНИТЕЛИ (ВОЗМОЖНО ИСПОЛНИТЕЛЯМИ БУДУТ ПРОГРАММИСТЫ).
> код — это всегда плохо
Код это средство делегировать задачу машине. Программисты это специалисты по переводу ЦЕЛЕЙ директоров в цели АИС. На этапе преобразования целей может произойти ошибка или программист может долго возиться с задачей. Совет по использованию простых решений, на самом деле совет УЧИТЬСЯ И ИСПОЛЬЗОВАТЬ ЧУЖИЕ ПРОТЕСТИРОВАННЫЕ РЕАЛИЗАЦИИ.
> Начните писать к commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.
Я хочу спросить Вас, а какую марку машины выбрали(выберете) Вы? Простую, но 1985 года выпуска не изменявшуюся и более не развивавшуюся с этого года или современный автомобиль с мягкими сидениями, ABS, USB, ...? Так получается, что дополнительные возможности появляются в развивающихся продуктах и придется дорабатывать систему. Но когда-то ABS вовсе не было и будучи студентом я не мог себе позволить автомобиль с ABS… Таким образом проблема глубже…
А где же проблема? Проблема не в ABS и не цене, а в том, что заказчики(директора) пока что делают небольшие продукты (назовем их прототипами) и прибыли пока не достаточно с этих продуктов на КРАСИВОЕ РЕШЕНИЕ, так вот… прототипы можно делать любого уровня КАЧЕСТВА (смотрите на личный кабинет МТС ;-), но вот только одна проблема улучшать их уже без причины(перерабатывать это будет затратно… и скорее всего это никто не будет делать) не будут.
Вот она и проблема:
Прототипы делают плохо и быстро. Если прототипы дают ожидаемые деньги их не пускают в улучшение, а кладут в поддержку и дельта уходит в карман директору. Проект подыхает (примеры нужно приводить или сами придумаете и найдете — в России их достаточно много).
Разработка прототипа как фундаментальной системы — дорого и не у всех хватает уверенности(опыта) и денег(стартового капитала).
Вот так и живем небоскребы в деревнях не можем строить ))))
> вам не нужны программисты. Вам надо решить проблему
С решением проблемы (надежнее, качественнее, дешевле, ...) справляется Автоматизированная Информационная Система и вы не можете на позиции директора ее реализовать самостоятельно тогда вам нужны исполнители и так повелось, что они инженеры, программисты и т.д. Итак, для решения вашей проблемы НУЖНЫ ИСПОЛНИТЕЛИ (ВОЗМОЖНО ИСПОЛНИТЕЛЯМИ БУДУТ ПРОГРАММИСТЫ).
> код — это всегда плохо
Код это средство делегировать задачу машине. Программисты это специалисты по переводу ЦЕЛЕЙ директоров в цели АИС. На этапе преобразования целей может произойти ошибка или программист может долго возиться с задачей. Совет по использованию простых решений, на самом деле совет УЧИТЬСЯ И ИСПОЛЬЗОВАТЬ ЧУЖИЕ ПРОТЕСТИРОВАННЫЕ РЕАЛИЗАЦИИ.
> Начните писать к commit'ах пользовательскую ценность добавленного кода. Не «добавил два метода», а «Теперь пользователю быстрее/легче/меньше...» или «появилась функция / изменилась реакция». Вам нечего написать? Вы ничего не сделали за день.
Я хочу спросить Вас, а какую марку машины выбрали(выберете) Вы? Простую, но 1985 года выпуска не изменявшуюся и более не развивавшуюся с этого года или современный автомобиль с мягкими сидениями, ABS, USB, ...? Так получается, что дополнительные возможности появляются в развивающихся продуктах и придется дорабатывать систему. Но когда-то ABS вовсе не было и будучи студентом я не мог себе позволить автомобиль с ABS… Таким образом проблема глубже…
А где же проблема? Проблема не в ABS и не цене, а в том, что заказчики(директора) пока что делают небольшие продукты (назовем их прототипами) и прибыли пока не достаточно с этих продуктов на КРАСИВОЕ РЕШЕНИЕ, так вот… прототипы можно делать любого уровня КАЧЕСТВА (смотрите на личный кабинет МТС ;-), но вот только одна проблема улучшать их уже без причины(перерабатывать это будет затратно… и скорее всего это никто не будет делать) не будут.
Вот она и проблема:
Прототипы делают плохо и быстро. Если прототипы дают ожидаемые деньги их не пускают в улучшение, а кладут в поддержку и дельта уходит в карман директору. Проект подыхает (примеры нужно приводить или сами придумаете и найдете — в России их достаточно много).
Разработка прототипа как фундаментальной системы — дорого и не у всех хватает уверенности(опыта) и денег(стартового капитала).
Вот так и живем небоскребы в деревнях не можем строить ))))
Прочитал только начало статьи.
В общем время — это деньги. И нужно всегда искать баланс на потери времени на разработке или дальнейшей поддержке (дальнейшей доработке другими программистами).
К тому же изначально писать досконально продуманный, качественный продукт — зло, ибо требования часто меняются как и происходит переосмысление дизайна продукта.
В общем время — это деньги. И нужно всегда искать баланс на потери времени на разработке или дальнейшей поддержке (дальнейшей доработке другими программистами).
К тому же изначально писать досконально продуманный, качественный продукт — зло, ибо требования часто меняются как и происходит переосмысление дизайна продукта.
Такие тексты пишут те, у кого нет опыта переписывания функциональности с нуля из-за того, что предыдуший вариант нихрена не расширяем и простым рефакторингом там не обойтись. Я некоторое время назад потратил 2 месяца на то, чтобы выкинуть из проекта здорровенные шматы говнокода и написать на этом месте своё, смею надеяться, достаточно изящное решение, которое и нынче используется вполне успешно. И расширяется при необходимости.
Такие тексты пишут те, у кого нет опыта переписывания функциональности с нуля из-за того, что предыдуший вариант нихрена не расширяем и простым рефакторингом там не обойтись.
Не только «те» пишут такие тексты. И у меня есть такой опыт. В моем случае предыдущий вариант быстро написанной «нихрена не расширяемой» системы позволил закрыть сделку по продаже нескольких единиц крупной техники по совокупной стоимости сильно превосходящей годовую зарплату программиста. Сейчас времени больше и требования шире — наша новая система и модульная, и кроссплатформенная, и всё остальное.
Вы делаете ту же ошибку, что и многие другие программисты, помещая программиста в центр. Про это статья.
Хм, ну вообще-то вы про меня почти ничего не знаете, но делаете выводы :)
Я прекрасно понимаю про деньги и сроки вообще-то, просто я сторонник того подхода, при котором мне не придётся платить программисту за два года работы, когда та же работа может быть сделана за один год. Да, можно написать за полгода, а потом потратить на переписывание и допиливание полтора. Но лучше всё-таки всё это сделать за один.
Я прекрасно понимаю про деньги и сроки вообще-то, просто я сторонник того подхода, при котором мне не придётся платить программисту за два года работы, когда та же работа может быть сделана за один год. Да, можно написать за полгода, а потом потратить на переписывание и допиливание полтора. Но лучше всё-таки всё это сделать за один.
После истории с «шаблонами проектирования», выпущенными в 1994 году, на «модные» тренды 80-х без улыбки смотреть тем более нельзя… К тому же 80-е — это эра господства языка С++, потом снискавшего у «особо острых языков» славу чуть ли не «языка для написания write-only программ» и «собрания всех ошибок, которые возможны при проектировании языка программирования», поэтому желание спрятать это «write-only» куда-нибудь «за барьер» вполне объяснимо. Да, и, объективно, кодогенерация, в том или ином виде, таки имеет некоторую нишу.
Хотя, по-моему, 95% того, что хотели от кодогенерации в 1980-х, сегодня дают системы, управляемые метаданными, интеллектуальные IDE, функциональное программирование и open source с обилием оттестированных библиотек, автоматически подключаемых при сборке.
Хотя, по-моему, 95% того, что хотели от кодогенерации в 1980-х, сегодня дают системы, управляемые метаданными, интеллектуальные IDE, функциональное программирование и open source с обилием оттестированных библиотек, автоматически подключаемых при сборке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как улучшить свой стиль программирования?