Здравствуйте, местные хакеры.
я здесь новый и не стал бы сюда заглядывать по своей нужде, но спровоцировал мой начальник. Бывший мой начальник, поскольку недавно уволил меня при очень странных обстоятельствах. Этот типчик вам здесь известен, это его тема "Оцените качество кода" http://rsdn.ru/forum/cpp/5787830.flat
висит у вас на форуме, и это он вызвал меня на этот форум, будучи уверен, что будто мне нечего будет возразить, и меня тут раздавят морально, так же как он раздавил уже материально.
Почитав все его реплики в той теме, вы узнаете, что я бронтозавр и что я только что расстался с фортраном, и много чего такого, что узнаешь о себе только на коммунальной кухне.
При вашем желании я легко развею все его инсинуации.
Но всему поводом (видимо, формальным) послужило неудовольствие господина моим кодом, который, увы-увы, работает, и работает без ошибок, но так тяжело доходит до сознания Крутого Манагера. По его уверениям, все тут массой мой код отвергли, признали "ужасным", подтвердили худшие его опасения и потому он свернул все мои наработки (делавшиеся на заказ отечественным фирмам), разорвал договоры и отправил меня восвояси искать другую работу (которой у нас не так легко найти).
Честно говоря, я потому ожидал встретить тут тусующуюся толпу бандерлогов, с которыми я имею опыт общения на форумах различных тематик, от политических до научных и конспирологических. Но просмотрев реплики, я не нашел, что за "ужасность" высказалось какое то определенное большинство. Более того, я нахожу сообщения вполне толерантные, и даже с видимыми противниками, мне кажется, вполне можно найти понимание. Потому засчитываем заявление господина об явной "ужасности" ложью №1.
(Прошу прощения, надо прерваться. Продолжение следует. И обещаю, что по тематике форума, а не в форме разборки с Крутым меном)
Ага, тут есть редактирование сообщения. Поехали.
Давайте договоримся о парадигмах. Всякое программирование занимается полезным делом, когда воплощает решение задач реального мира. Программирование основано на языке, это его формальная сторона, тогда как содержательной является решение задач, то есть разработка алгоритма.
С этой точки зрения, все претензии господина относятся к формальной стороне дела, к сути проблемы он даже не подступал, и даже сама тема его "Оцените качество кода" чисто формальна — он даже не сделал попыток объяснить постановку задачи, почему и непонятно, что же он хочет.
Обсуждение в результате свелось к спору слепых о том, что такое слон, по форме частей его тела.
Позвольте мне расширить аналогию.
Все эти классы, шаблоны и прочие новомодные фичи для существа программы представляют что-то вроде оглавления, содержания книги. Но не оглавления составляют ценность книг. И не их оформление. Представим современных книгочеев, спорящих о качестве книги по ее переплету, обложке и тому подобным мелочам, но при том не удосуживающихся прочесть даже и главы из книги. Граф Толстой ужасен, скажут они, разве можно писать так длинно? Он явно бездарен, вот нам нравятся хокку, — если бы он умел написать Войну и мир на хокку, это было бы совсем другое дело. А так — нет, writeonly.
Или представьте, как какой издатель указывал бы Толстому, как и сколько писать?
Возможно, с тех пор формальные каноны усовершенствовались, но где же сегодня великая литература? Сплошь халтура.
Вспомним, как Моцарт задержался дорогой, слушая неумелого деревенского музыканта. И Сальери, этого мощного стража формалистики, — гений склоняется к несовершенству, ищет живую душу, а тот, кто "алгеброй поверил гармонию", лишь бездарно стучит по клавишам в своей агонии мнимого совершенства.
Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство.
Именно это я и хотел когда то сказать в отношении "Совершенного кода" Макконелла. Как альтернативу, я предложил бы написать книгу "Искусство написания несовершенного кода", которая оказалась бы еще полезнее. Но кто внимательно прочел МакКонелла, увидит, что в ней нет строгих формальных требований, это не катехизис программиста, а всего лишь сборник полезных приемов и интересных идей.
Но, как всегда, находятся не в меру религиозно-озабоченные деятели, которые возводят из частных случаев догматы и начинают слепо придерживаться их. Так возникают Крутые Манагеры.
Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом).
Ну ты растекся мыслию по древу. Считаешь себя Толстым и Моцартом в программировании?
Забываешь одну деталь в коммерческом программировании — код должен быть понятен любому, кто сядет его дебажить или расширять. Твой код не совсем таков. Не ужасен, но и далеко не идеал. На троечку. Не понимаю чего такой шум подняли изза одного классца ("новомодные штуки"??? )
Чтобы вы поверили этому (я не призываю проверять весь код), я расскажу наконец постановку задачи, и почему она вышла такая длинная.
Задача была поначалу для интереса — найти алгоритм поиска замкнутых контуров из произвольно заданного набора кусков кривых. Теория графов по Эйлеру была руководящей идеей. Основным требованием для меня являлось сохранение линейной скорости алгоритма.
Если кто то считает, что задача очевидным образом формализуется в виде классов — прошу на сцену. Я же таких явных классов не видел, а создавать их искусственно, на потребу г-на начальника, считаю бесполезной и даже вредной тратой времени. Я могу сформулировать такой критерий — если классов не видно, то лучше никаких классов, чем что то уродливое, но объектно-ориентированное.
И причин тут по меньшей мере две — 1)алгоритм не расползается по разным местам и файлам, а более менее локализован, что важно при его первичном моделировании, и 2)отладка не настолько утомительна, как в случае классов, да еще с использованием STL-фичей, на ошибки которых компилятор ругается хорошо если 10-этажнвм матом (а чаще просто вываливает на экран половину системных h-файлов), а отладчики в половине случаев не способны показать значение зарытого в классах члена или свойства.
Как вы сможете убедиться, весь "длинный" код в действительности достаточно линеен — а по этому признаку даже Конелл не запрещает удлинять функции. Последовательно определяются ребра, узлы, компоненты, наконец, ветви и контуры. Почему этот алгоритм не разбит на отдельные пошаговые подфункции? Из-за единого набора переменных-массовов, которые тут везде рабочие, но нужны на всем протяжении каждого цикла. Искусственно выносить их в классы, значит, терять локализацию, а это важнее мнимой красоты. Я вовсе при том не сторонник напихивать в одну функцию кучу разнородного барахла. Но как раз тут постановка диктует , потому что весь длинный алгоритм — един. И что функция получится длинной, я заранее знал и предупреждал манагера.
Любопытный факт — код алгоритма этот Манагер выложил в интернет , заявив , что этот код ему нафиг не нужен, но когда при моем увольнении зашел разговор, чтобы отдать мне этот код для завершения работы с заказчиком, — как стоило узнать о пошлом скупердяйстве манагера, который вдруг заявил, что код — собственность фирмы. Что это как не шизофрения?
Код я все же получил, хоть и без мелких примочек, и довел его до второй успешной реализации — на этот раз нам с заказчиком понадобилось найти алгоритм построения самого внешнего контура. И меня не сильно напрягала длина этого метода. Хотя новый алгоритм еще более разросся, но в нем заложена красивая идея, вот что важно, и эта внутренняя красота будет посовершенней дутой формальности.
Не затрагивая профессиональные навыки, а только психологию, скажу, что ты, похоже, из тех людей, которые лучше будут часами трындеть, чем просто пойдут и сделают.
Еще ты, похоже, из тех "мастодонтов", которые еще на фортране и с перфокартами бегали. Так вот, такие обычно глухи к любым замечаниям "этих сосунков, которые еще под стол ходили, когда я уже дифуры программировал". И такие как раз и готовы часами трындеть про Моцартов и Толстых.
Проще по-моему тупо было взять и поменять магические числа на дефайны, а не припираться часами.
Здравствуйте, Varavva, Вы писали:
V>Ну ты растекся мыслию по древу. Считаешь себя Толстым и Моцартом в программировании?
Я считаю в программировании (как и в любом деле) главной идею, а не формальный подход.
V>Забываешь одну деталь в коммерческом программировании — код должен быть понятен любому, кто сядет его дебажить или расширять. Твой код не совсем таков. Не ужасен, но и далеко не идеал. На троечку. Не понимаю чего такой шум подняли изза одного классца ("новомодные штуки"??? )
Понятен любому... дураку, хотите вы сказать? А что ему надо бы знать теорию графов и вообще хотеть разбираться в коде, это не в счет? А у нас сплошь и рядом за отладку и расширение садятся те, кто не в зуб ногой. Это и есть вид халтуры, а я почему то должен этому подмахивать, кладя всюду соломку в своем коде.
Я не против рефакторинга, если он действительно удачен и полезен для дела. Я против мелочных придирок и тупого невежества манагеров. Но рефакторинг, на мой взгляд, надо делать ПОСЛЕ написания алгоритма, и тем более не в ущерб простоте его написания.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Позвольте мне расширить аналогию. ЮЛ>Все эти классы, шаблоны и прочие новомодные фичи для существа программы представляют что-то вроде оглавления, содержания книги. Но не оглавления составляют ценность книг. И не их оформление. Представим современных книгочеев, спорящих о качестве книги по ее переплету, обложке и тому подобным мелочам, но при том не удосуживающихся прочесть даже и главы из книги. Граф Толстой ужасен, скажут они, разве можно писать так длинно? Он явно бездарен, вот нам нравятся хокку, — если бы он умел написать Войну и мир на хокку, это было бы совсем другое дело. А так — нет, writeonly. ЮЛ>Или представьте, как какой издатель указывал бы Толстому, как и сколько писать?
Ну, чисто формально эту аналогию надо переделать. Аналогом ужасного стиля кода будет присылка рукописи почерком врача с 50-летним стажем, с неровными строками, которые налезают друг на друга. В ситуации, когда надо не вчитываться, смакуя эпитеты, а за пару минут схватить содержание куска и понять, что надо менять — Толстой не катит. И вообще, это не художественная литература, а инструкция с элементами справочника с кучей таблиц и прочей информации, обширной, но не цельной.
Соответственно, и критерии оценки должны быть не нравится / "не нравится — спи, моя красавица", а чисто технические. Даже если выбор самих критериев отдаёт вкусовщиной (для языков типа C++ скобки на одном отступе или египетские — нет однозначного решения), само их применение должно быть чисто технологическим принципом. Использование общеизвестных распространённых приёмов и методов плюс соответствие ТЗ и стандарту стиля, где он может быть автоматизированно проверен/исправлен или хотя бы описан — вот критерий.
И если начальник говорит, что стиль плохой, но не имеет никаких ясных аргументов — значит, он не может ничего сказать по сути. Это действительно так, или Вы преувеличили?
ЮЛ>Возможно, с тех пор формальные каноны усовершенствовались, но где же сегодня великая литература? Сплошь халтура.
ЮЛ>Вспомним, как Моцарт задержался дорогой, слушая неумелого деревенского музыканта. И Сальери, этого мощного стража формалистики, — гений склоняется к несовершенству, ищет живую душу, а тот, кто "алгеброй поверил гармонию", лишь бездарно стучит по клавишам в своей агонии мнимого совершенства.
А вот Ваши сравнения с Толстым, Моцартом и т.д. — вот это уже фактор, на который я бы обратил особое внимание. Именно потому, что тут в таких сравнениях принципиальная методологическая ошибка. Может быть, проблема именно в том, что Вы неадекватно воспринимаете свою работу, вводя поэзию туда, где её быть не должно? (Я не говорю про всё программирование, в нём полно места для искусства, но даже в лучшей поэзии >90% работы это чистая механика.)
ЮЛ>Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство.
И это тоже смущает. Программа пишется под задание. Задание гарантированно будет меняться, это к гадалке не ходи. Но на конкретный момент достичь совершенства, закоммитить и забыть — это совершенно нормально, и это во всём, от программирования до выбора позы на диване. При чём тут названное Вами?
Я наскоро посмотрел на тот код... сильно вчитываться нет ни времени ни вдохновения, но некоторые моменты меня смущают. Начиная с банальности, нафига #ifdef перед #undef, продолжая странным форматированием (в десятке+ мест не соответствующим ни одному из стандартных стилей)... если бы Вы были более практичны, я бы начал с достижения предельного соответствия общим и местным стандартам именно в таких вещах. По методу "к пуговицам претензии есть? формальные условия выполнены? не нравится стиль? прошу совершенно точных и конкретных принципов, изложенных однозначным языком."
ЮЛ>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках?
Этот запрет ровно такой же, как и ограничение скорости в городе на какие-нибудь 50, 56, 60 км/ч. Какая из этих цифр правильнее и почему? Его регулярно меняют, и в соседней стране оно иное. Почему не 52 или 58? Почему в США 35 миль в час (что даёт названные 56)? Все эти конкретные числа имеют тот смысл, что 1) надо на чём-то остановиться, 2) они близки к правильным в среднем по больнице.
Вообще, в Вашем случае я не увидел чётких мест для применения такой границы. Математика описанного вида это такое, что в ней важнее алгоритм, а он или понимается целиком, или не понимается; когда есть чёткие отдельные сегменты логики, их можно разнести в разные функции/методы и тем самым сократить вероятность целой группы проблем вроде неожиданного переиспользования переменной.
ЮЛ>Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом).
Этому верю. Но будет ли понимать средний программист аналогичного класса всё то, что Вы схватываете в нём с ходу, потому что писали сами?
А будете ли помнить и вспоминать с ходу все необходимые подробности года через два?
Здравствуйте, Varavva, Вы писали:
V>Про идеи — это вы с Платоном поговорите. Программирование же — это ремесло. Как токарь. Не более. И надо делать все просто и эффективно.
С вами все ясно. Больше вопросов не имею. (Кстати, ну ка, токарь, давайте ка быстро и эффективно наваяйте алгоритм контуров, да так, чтобы вас начальство похвалило)
V>И да, код должен быть понятен любому дураку. И кстати, не надо всех считать тупее себя.
Здравствуйте, Varavva, Вы писали:
V>Не затрагивая профессиональные навыки, а только психологию, скажу, что ты, похоже, из тех людей, которые лучше будут часами трындеть, чем просто пойдут и сделают.
Похоже, вы тоже из манагеров?
V>Еще ты, похоже, из тех "мастодонтов", которые еще на фортране и с перфокартами бегали. Так вот, такие обычно глухи к любым замечаниям "этих сосунков, которые еще под стол ходили, когда я уже дифуры программировал". И такие как раз и готовы часами трындеть про Моцартов и Толстых. V>Проще по-моему тупо было взять и поменять магические числа на дефайны, а не припираться часами.
Это что за чушь? А, это очередная ложь, поведанная вам тут Крутым Манагером. Ну, мы еще вернемся к нему.
Здравствуйте, Юрий Лазарев, Вы писали
ЮЛ>С вами все ясно. Больше вопросов не имею. (Кстати, ну ка, токарь, давайте ка быстро и эффективно наваяйте алгоритм контуров, да так, чтобы вас начальство похвалило)
Пиписьками решили померяться? Извольте.
Ничего, что я работаю удаленно на несколько иностранных компаний, занимаясь разработкой софта в 3D моделировании и алгоритмировании операций с твердотельными объектами? Пользуясь моими разработками в этой области людям делают протезы на зубы и размещают краны на строительных площадках и разрабатывают новые модели механических часов и ювелирных изделий? Причем я посылаю заказчикам именно исходники. И все довольны. Ну ка...
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Но всему поводом (видимо, формальным) послужило неудовольствие господина моим кодом, который, увы-увы, работает, и работает без ошибок, но так тяжело доходит до сознания Крутого Манагера. По его уверениям, все тут массой мой код отвергли, признали "ужасным", подтвердили худшие его опасения и потому он свернул все мои наработки (делавшиеся на заказ отечественным фирмам), разорвал договоры и отправил меня восвояси искать другую работу (которой у нас не так легко найти).
Тут всё зависит от области применения кода.
Если он является частью большого проекта, который разрабатывается годами командой из десятков или сотен разработчиков, то... То твой код и правда ужасен, увы. То есть его бы даже на код ревью смотреть не стали, а сразу дали бы код стандарт и заставили переписать безотносительно его работоспособности.
Если твой менеджер ранее работал в крупных компаниях, то его позиция и последовавшая реакция (фактически увольнение за профнепригодность) вполне обоснована и понятна.
Здравствуйте, Юрий Лазарев, Вы писали:
V>>Проще по-моему тупо было взять и поменять магические числа на дефайны, а не припираться часами. ЮЛ>Это что за чушь? А, это очередная ложь, поведанная вам тут Крутым Манагером. Ну, мы еще вернемся к нему.
Хм, если Вы и на работе так общались, то дело точно не в коде...
Здравствуйте, netch80, Вы писали:
N>Ну, чисто формально эту аналогию надо переделать. Аналогом ужасного стиля кода будет присылка рукописи почерком врача с 50-летним стажем, с неровными строками, которые налезают друг на друга. В ситуации, когда надо не вчитываться, смакуя эпитеты, а за пару минут схватить содержание куска и понять, что надо менять — Толстой не катит. И вообще, это не художественная литература, а инструкция с элементами справочника с кучей таблиц и прочей информации, обширной, но не цельной.
Это неважно. Я говорю о различии содержания и формы. К сожалению, ныне форма превалирует. Содержания практически ноль, или оно уворовано (а значит, и не понято).
N>Соответственно, и критерии оценки должны быть не нравится / "не нравится — спи, моя красавица", а чисто технические. Даже если выбор самих критериев отдаёт вкусовщиной (для языков типа C++ скобки на одном отступе или египетские — нет однозначного решения), само их применение должно быть чисто технологическим принципом. Использование общеизвестных распространённых приёмов и методов плюс соответствие ТЗ и стандарту стиля, где он может быть автоматизированно проверен/исправлен или хотя бы описан — вот критерий.
По моему, для автоматической проверки все эти придирки несущественны, а вкусовщина именно и проявляется манагерами.
Вы за "технологические принципы" принимаете единство отступов, хотя для технологий тут как раз никаких препятствий не возникает. Чистый волюнтаризм.
Кстати, что за отступы вы мне тут инкриминируете? У меня есть своя "техника" — обычные отлаженные операторы я помещаю в общепринятом месте, а вот проблемные, содержащие ошибки, требующие внимания, ставлю (чаще временно, хотя остается надолго) в первые позиции строки. В принципе, по этой идее все такие строки бросаются в глаза, а то что они временные, служит залогом того, что при необходимости их можно безболезненно (или по крайней мере не особо задумываясь) удалить в окончательном коде.
N>И если начальник говорит, что стиль плохой, но не имеет никаких ясных аргументов — значит, он не может ничего сказать по сути.
Да он вообще не разбирается в сути.
N>А вот Ваши сравнения с Толстым, Моцартом и т.д. — вот это уже фактор, на который я бы обратил особое внимание. Именно потому, что тут в таких сравнениях принципиальная методологическая ошибка. Может быть, проблема именно в том, что Вы неадекватно воспринимаете свою работу, вводя поэзию туда, где её быть не должно? (Я не говорю про всё программирование, в нём полно места для искусства, но даже в лучшей поэзии >90% работы это чистая механика.)
Представьте, мне это нисколько не мешает.
ЮЛ>>Совершенство смерти подобно. Ведь любое движение нарушает уже достигнутое совершенство. N>И это тоже смущает. Программа пишется под задание. Задание гарантированно будет меняться, это к гадалке не ходи. Но на конкретный момент достичь совершенства, закоммитить и забыть — это совершенно нормально, и это во всём, от программирования до выбора позы на диване. При чём тут названное Вами?
Смысл высказывания в том, что стремление к совершенству полезно, но не чрезмерно. И уж тем более не должно становиться идолом, мешающим повседневной работе
N>Я наскоро посмотрел на тот код... сильно вчитываться нет ни времени ни вдохновения, но некоторые моменты меня смущают. Начиная с банальности, нафига #ifdef перед #undef, продолжая странным форматированием (в десятке+ не соответствующим ни одному из стандартных стилей)... если бы Вы были более практичны, я бы начал с достижения предельного соответствия общим и местным стандартам именно в таких вещах. По методу "к пуговицам претензии есть? формальные условия выполнены? не нравится стиль? прошу совершенно точных и конкретных принципов, изложенных однозначным языком."
Я выше на это не ответил?
ЮЛ>>Спрашивается, где у Конелла запрет на писание функций длиной более 200 строк? Что за соображения обосновывают эту магическую величину? Может ли код остаться неплохим при 201, 300, 1000 строках? N>Этот запрет ровно такой же, как и ограничение скорости в городе на какие-нибудь 50, 56, 60 км/ч. Какая из этих цифр правильнее и почему? Его регулярно меняют, и в соседней стране оно иное. Почему не 52 или 58? Почему в США 35 миль в час (что даёт названные 56)? Все эти конкретные числа имеют тот смысл, что 1) надо на чём-то остановиться, 2) они близки к правильным в среднем по больнице.
Совершенно верно, и в других моих програмах вы не найдете такого длинного кода. Но тем не менее случаи такие возможны и имеют право на существование. Или вы догматик?
N>Вообще, в Вашем случае я не увидел чётких мест для применения такой границы. Математика описанного вида это такое, что в ней важнее алгоритм, а он или понимается целиком, или не понимается; когда есть чёткие отдельные сегменты логики, их можно разнести в разные функции/методы и тем самым сократить вероятность целой группы проблем вроде неожиданного переиспользования переменной.
Ну если бы меня в данном случае беспокоила именно проблема переиспользования переменной, я бы наверное, придумал что то другое. Но мне важнее была цельность алгоритма.
ЮЛ>>Да, и вот этот мой код и есть тому подтверждение. При чем, я не говорю, хорошим, я говорю, неплохим, поскольку он все равно хорошо поддается отладке и скейлингу (последнее тому подтверждение — мой последний новый код, как развитие вами виденного, с новым оригинальным алгоритмом). N>Этому верю. Но будет ли понимать средний программист аналогичного класса всё то, что Вы схватываете в нём с ходу, потому что писали сами?
N>А будете ли помнить и вспоминать с ходу все необходимые подробности года через два?
А вот тут как раз самое интересное. Мой код подошел к своему совершенству, и я не вижу, зачем бы ему еще модифицироваться. Если есть такие предпосылки, его надо рефакторить, это само собой. Но опять таки, ПОСЛЕ написания алгоритма, а не в процессе его, когда основные концепции еще не устоялись.
Здравствуйте, Nuzhny, Вы писали:
N>Тут всё зависит от области применения кода. N>Если он является частью большого проекта, который разрабатывается годами командой из десятков или сотен разработчиков, то... То твой код и правда ужасен, увы. То есть его бы даже на код ревью смотреть не стали, а сразу дали бы код стандарт и заставили переписать безотносительно его работоспособности. N>Если твой менеджер ранее работал в крупных компаниях, то его позиция и последовавшая реакция (фактически увольнение за профнепригодность) вполне обоснована и понятна.
Код был написан меньше чем за два месяца. Мной одним. Не потому, что я отказывался работать в команде, а потому что команда безбожно тупила. Естественно, я не собирался оставлять код в таком виде, а думал его переработать со временем. Профнепригодность — это когда код востребован заказчиком? Ну, не знаю. Скорее это профнепригодность манагера.
И еще цитата
=Желаю не отчаиваться тем, кто живёт своим трудом. Пусть как можно больше людей поймёт, что настоящая профессия будет востребована, каким бы ни был курс рубля. Всегда будут нужны шофёры, повара, космонавты, военные, учителя. А вот менеджерам я желаю сменить работу и попытаться стать профессионалами.=
ЮЛ>Понятен любому... дураку, хотите вы сказать? А что ему надо бы знать теорию графов и вообще хотеть разбираться в коде, это не в счет? А у нас сплошь и рядом за отладку и расширение садятся те, кто не в зуб ногой. Это и есть вид халтуры, а я почему то должен этому подмахивать, кладя всюду соломку в своем коде.
Не стоит это так воспринимать. Я такой умный поэтому могу разобраться в таком сложном коде, а тот кто не может — идиот, это ущербная практика. Самые умные программисты умеют писать простой и понятный любому код, посредственные программисты пишут то, в чем потом сами могут разобраться с трудом. Тебе платят за решение задачи а не за то, чтобы ты один раз что-то написал и потом несколько лет занимался поддержкой, так как дешевле продолжить платить тебе, чем переписать это все к черту. Вот такой вот элитизм как правило признак непроффесионализма. Мне вот например очень сложно в твоем коде разобраться не потому что я не в зуб ногой (10 лет опыта за плечами), а потому что код реально плохой. Там в кучу смешана логика твоего гениального алгоритма и представление. Там есть функции размером в несколько десятков экранов, которые делают сразу множество вещей. Декомпозиции никакой нет вообще, god object с UI и логикой в одном флаконе. Там куча циклов внутри циклов, вместо использования стандартных алгоритмов. Его проще переписать к псам чем изменить любому человеку кроме тебя. Такой код иногда пишут для того чтобы повысить job security в ущерб интересам клиента.
И если ты думаешь, что идею никто кроме тебя не осилит — ты очень сильно ошибаешься. Алоритм там скорее всего несложный, сложно увидеть его в твоем коде. И вот судя по моему опыту, если не очевидно что код делает — код совершенно точно говно. Можно даже не сомневаться в этом ни на секунду. Логика с представлением в перемешку, значит код совершенно точно нужно выкинуть и написать заново.
Здравствуйте, Varavva, Вы писали:
V>Не затрагивая профессиональные навыки, а только психологию, скажу, что ты, похоже, из тех людей, которые лучше будут часами трындеть, чем просто пойдут и сделают.
Ну, справедливости ради, если человек только что потерял работу, то вполне понятно его желание "потрындеть" по этому поводу
Еще есть знаменитое keep your identity small Грэма. Не стоит воспринимать свой код как часть себя, как что-то личное, иначе ты не сможешь объективно на это смотреть. Это всего лишь код, который можно написать один раз, получить за него деньги и забыть. Статья очень хорошая, советую загуглить и прочитать.
Здравствуйте, jazzer, Вы писали:
J>Ну, справедливости ради, если человек только что потерял работу, то вполне понятно его желание "потрындеть" по этому поводу
Дак я сделал такой вывод не на основании здесь написанного, а на основании того КрутогоМанагера, писавшего в том посте — чел и на работе так делал. а тутошние простыни просто это подтверждают
)
