Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>1) Правильно ли, когда разработка алгоритма оценивается манагером вдвое дешевле ничего не значащего "сопровождения"?
Что значит: "вдвое дешевле"? Имеют ли эти вопросы отношение к качеству кода, который был выставлен на обозрение?
ЮЛ>2) Как вам ситуация, когда разработчик поставлен в условия самоокупаемости при разработке в основном разовых заказов от отечественных заказчиков?
Это рынок, не вижу проблемы. Кстати, кем поставлен?
Можно ли услышать ваше мнение о том, каким должен был быть процесс работы над задачей?
Начиная с постановки задачи и заканчивая приемкой результатов и оплатой?
RU>>Выделенные в моём посте фразы вы относите к одному и тому же куску кода? RU>>Если да, то мне странно, что вы не видите противоречия. RU>>Если нет, то непонятно, почему вы удивляетесь, что недоделанный согласно вашим же словам код коллеги не считают качественным.
ЮЛ>Схоластика. Проект был недоделан, и потому в нем появлялись комменты. Проект наконец доделан, все развивается. ЮЛ>По вашей логике выходит, коллеги глядя на завершенный проект, осуждают его недоделанность в прошлом и потому не считают его качественным. Вы уж определитесь или выражайтесь яснее.
Если кроме выложенного тут варианта кода есть доделанный, то по моей логике: RU>>непонятно, почему вы удивляетесь, что недоделанный согласно вашим же словам код коллеги не считают качественным.
Под коллегами я имею ввиду коллег здесь на форуме, которые видели только выложенный тут недоделанный вариант кода.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>А вы не находите, что для "много-много комментариев" больше подходит учебное пособие? Или все таки я должен за бесплатно писать рядом с кодом еще и учебное пособие?
Ууу как всё запущено.
ЮЛ>Вы кого называете заказчиком?
Кто тебе деньги платил и задачи ставил?
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Код был написан меньше чем за два месяца. Мной одним. Не потому, что я отказывался работать в команде, а потому что команда безбожно тупила. Естественно, я не собирался оставлять код в таком виде, а думал его переработать со временем. Профнепригодность — это когда код востребован заказчиком? Ну, не знаю. Скорее это профнепригодность манагера.
Без разницы как быстро писался код.
Дело в том, что он сразу должен быть откомментирован, в процессе написания.
В нём сразу должны быть осмысленные имена переменных.
Для него сразу должны писаться тесты.
Перед попаданием в систему контроля версий его должны отревьюверить коллеги, на предмет удовлетворения принятым в фирме стандартам написания кода и отсутствия очевидных багов.
Дело в том, что в больших проектах никому не нужен код, который работает, потому что "мамой клянусь!". Сейчас для индустрии это всё равно, что теоремы без доказательства в математике.
Код (это на практике код + тесты) должен сам по себе гарантировать заданный уровень качества, читабельности и модифицируемости.
Это печально, но ваш код отстой
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Здравствуйте, 0x7be, Вы писали:
ЮЛ>Тем что вы ответили на свой, но не мой вопрос. ЮЛ>Кстати, кто у вас исполнитель?
Программист, тестировщик, дизайнер и т.п.
ЮЛ>Вы всегда уводите обсуждение в сторону?
Вы сейчас первый это сделали. Мой вопрос был вызван именно этим фактом.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>1) Правильно ли, когда разработка алгоритма оценивается манагером вдвое дешевле ничего не значащего "сопровождения"?
Кажись я в первый неправильно понял вопрос.
Ворос про соотсоотношение первоначальных затрат на разработку и последующих затрат на сопровождения решения?
Здравствуйте, Varavva, Вы писали:
V>Про идеи — это вы с Платоном поговорите. Программирование же — это ремесло. Как токарь. Не более. И надо делать все просто и эффективно.
V>И да, код должен быть понятен любому дураку. И кстати, не надо всех считать тупее себя.
S>Нет тут никаких хакеров, почти. Этот форум наполнен среднячками и обывателями от программирования, S>не различающими сути о формальности средств выражения, представления, предоставления для машины, алгоритмов, S>и поэтому всерьёз обсуждающих про то, как правильно, for{} или BOOST_FOREACH. S>Для программы есть одно единственное требование-удовлетворять зараенe оговорённым требованиям. В 95% S>всех случаев это означает соответствие всевозможным параметрам времения исполнения, из которых производительность S>и безопасность являются оcновными. То, каков сам код, имеет вторичное значение. И это мировая практика разработки, S>которой, многим местным ылитным программистам и многим программистам в РФ вообще, стоит поучиться. Частенько можно S>тут узреть о том, что код, например, в open source, является некачественным, хотя многие, из местных оценщиков кода, S>не способны и на долю того, что могут и что делают авторы того некачественного кода из open source.
Вот интересно, о каких open source проектах ты говоришь? По моему опыту (и я могу привести огромное количество примеров) open source код весьма качественен. Все проекты, за которыми я следил, имели весьма неплохое качество кода. Там часто есть peer review (процедура, которую ТС едва ли прошел бы), тесты, да и сам код далек от того, что было в том топике. Ты то сам тот код, о котором идет речь пытался читать, прежде чем писать этот коммент? Там нет понятия "граф", там нет понятия "контур", несмотря на то, что утверждается, что программа ищет замкнутый контур из кусков кривых используя какие-то алгоритмы на графах. А как можно утверждать что она это делает, если нет ни одного теста и даже нет отдельного модуля, который можно независимо от гуя потрогать? Этот код даже нельзя проанализировать, и получается, что то, что этот код работает мы знаем только со слов его автора.
ЮЛ>В либерастическом смысле — выживает сильнейший (и тупейший)
И чем же ты можешь доказать, что ты такой умный, но недооцененный? Мне кажется наоборот, код пишешь так себе, soft skills ниже плинтуса, вечно кто-то в чем-то виноват.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Здравствуйте, местные хакеры.
Я весь топик не читал, терпения не хватило.
О коде. Он бы написан за 2 месяц? И заработал наконец.
А что мешало после этого перевести его в более понятный и читабельный вид? Не сразу, не торопясь, аккуратно разделяя на куски, возможно, покрывая его тестами.
Вам не дали времени на это, или вы сами не захотели? Я понимаю, что это математика, она никогда красотой не отличалась, но ведь действительно читать тяжело. К таким сложным вещам, как мне кажется, комментарии должн занимать место, сравнимое по объему с самим кодом.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ> Вот уж поверьте, бывают такие программы, которые не требуют никакого сопровождения. Это вам не как у Райкина "Кто рукав к гульфику пришил?"
Например, заказчику захочется переписать программу под Linux или Windows RT, тоже сопровождения не потребуется?
Здравствуйте, chaotic-good, Вы писали:
CG>Вот интересно, о каких open source проектах ты говоришь? По моему опыту (и я могу привести огромное количество примеров) open source код весьма качественен.
У меня есть претензии к коду в boost. Достаточно тяжело читается, всё раздроблено на мелкие
кусочки и раскидано по разным файлам и разным папкам. Такое впечатление, что его писали специально
для запутывания читающего. Вот, например, STL-вский код, большая часть которого во всех реализациях,
стянута с одной из первых масштабных реализаций либы от SGI Inc, читается просто и непринуждённо.
Также с linux-ом, в любом даже самом неопрятным коде разбираешься быстро. Качественный кода в PostrgeSQL,
легко читается, хотя там функций в 1000 строчек имеется много, ибо так и надо. И все вышеперечисленные,
бытующим на этом форуме критериям качества кода, не соответствуют, и код в них, с точки зрения упомянутых
критериев, кошмарный.
Но boost-это какой-то грёбанный кошмар. Вот это C++-нутое, относимое к его преимуществам и продвигаемое
как какой-то тренд, заключающееся в разбивании кода на мелкие сущности aka объекты, вот это и есть причина
тяжёлой читаемости кода в boost. Приходится скакать между файлами, папками, чтоб просмотреть и запомнить то,
чем является очередная, встретившаяся в коде сущность, которая зачастую состоит из одного typedef, и одного
метода с одной операцией.
Алгоритм дробить на объекты нужно, но объекты должны быть достаточно охватывающими. Мелкие подобъекты, должны
распологаться в пределах описания большого объекта, а не в другом файле и в другой папке. Именно так расписан STL.
Посмотрел тот кусок кода. Вот мои мысли:
1) Не индусятина. Признак индусского кода- наивные решения.
2) Логика прикручена к гуе. Сейчас Дельфи-стайл не в моде. Открути логику в классы и чтобы никаких зависмостей от гуи не было в алгоритме.
3) Класс с логикой покрой юнит тестом. Попутно всплывут ещё граничные случаи, о которых сходу не догадаешься.
4) Длинные методы порежь на короткие, с говорящими названиями
5) Комментарии по вкусу
6) Магические номерки- стыдно! Заменить на константы или енумы (по вкусу).
7) KompasObjectHolder и KompasIteratorHolder не нужны, не надо плодить сущностей без необходимости.
PS На днях пытался понять мой собственный код 2-годичной давности. Да, логика в отдельном классе, да, покрыто всё юнит-тестами. Да, не индусятина (наивным не назовёшь, без поллитры не разберёшься).
Здравствуйте, Aртём, Вы писали:
Aё>Здравствуйте, Юрий Лазарев, Вы писали:
Aё>Посмотрел тот кусок кода. Вот мои мысли: Aё>1) Не индусятина. Признак индусского кода- наивные решения. Aё>2) Логика прикручена к гуе. Сейчас Дельфи-стайл не в моде. Открути логику в классы и чтобы никаких зависмостей от гуи не было в алгоритме. Aё>3) Класс с логикой покрой юнит тестом. Попутно всплывут ещё граничные случаи, о которых сходу не догадаешься. Aё>4) Длинные методы порежь на короткие, с говорящими названиями Aё>5) Комментарии по вкусу Aё>6) Магические номерки- стыдно! Заменить на константы или енумы (по вкусу). Aё>7) KompasObjectHolder и KompasIteratorHolder не нужны, не надо плодить сущностей без необходимости.
Aё>PS На днях пытался понять мой собственный код 2-годичной давности. Да, логика в отдельном классе, да, покрыто всё юнит-тестами. Да, не индусятина (наивным не назовёшь, без поллитры не разберёшься).
А остальное сообственно говоря удел гениев, которые любую функцию пишут на асме в 10 комманд, но там тогда комментов надо больше программы
Моя точка зрения — код достаточно приличный, хотя нет в мире совершенства. Кое-что , действительно, переделать стоит.
Основная проблема в том, что большинство программистов сейчас пишут такой код, где, как правило, и без всяких комментариев понятно, что делается. Достаточно классам, переменным и методам дать хорошие имена, структурировать код, и он будет ясен и понятен. Просто дело в том, что код этот в большинстве с очень простой логикой, да и откуда в бизнес-сфере (а большинство задач сейчас из нее) взяться сложной логике ? Так, клик на кнопку, заполнить форму, отослать на сервер, записать что-то в БД , прочитать из БД, послать клиенту и т.д. Сами действия очень просты, хотя их взаимодействие может оказаться и непростым. Поэтому надо хотя бы сами действия оформить как можно лучше. Читаешь такой код — и все ясно, что делается и как. Модифицировать его как — тоже ясно, пока речь идет о модификациях вроде добавления поля в таблицу или класс и написания нового метода из 5 строчек.
У тебя же код, который как ни форматируй, как на функции не разделяй — все равно понятным не сделаешь, так как в нем некая не слишком тривиальная математика, которую нужно просто знать, и не из программы. И сложность написания такого кода не в том, чтобы корректно разделить код на методы, а в том, чтобы именно написать его и отладить. Алгоритм на 2 порядка сложнее, чем в обычной бизнес-программе (если там вообще об алгоритме можно говорить) Делить на методы стоит, и методы слишком большими быть не должны, это вообще-то верно, но не надо доводить до абсурда. Разделив такой код на маленькие методы, можно легко добиться противоположного результата — в этих методах просто запутаешься, только и будешь пытаться понять, что куда передается и что там делается, ускользнет суть дела. А вот разделение GUI (диалогов) и документа (математики) кто действительно мешал сделать как следует ?
В общем, если нужно оценить твою правоту против правоты твоего менеджера (я совершенно не касаюсь твоего отношения к нему и его к тебе, только по коду) — 3:2 в твою пользу.
Другое дело, что я не вижу, почему нельзя было отрефакторить этот код, если уж твой менеджер так хочет увидеть нечто более ему привычное. Выделить классы, разбить на части — это же не так много времени займет, во всяком случае, несравнимо с тем временем, которое ты потратил на написание всего этого.
PD>У тебя же код, который как ни форматируй, как на функции не разделяй — все равно понятным не сделаешь, так как в нем некая не слишком тривиальная математика, которую нужно просто знать, и не из программы. И сложность написания такого кода не в том, чтобы корректно разделить код на методы, а в том, чтобы именно написать его и отладить. Алгоритм на 2 порядка сложнее, чем в обычной бизнес-программе (если там вообще об алгоритме можно говорить) Делить на методы стоит, и методы слишком большими быть не должны, это вообще-то верно, но не надо доводить до абсурда. Разделив такой код на маленькие методы, можно легко добиться противоположного результата — в этих методах просто запутаешься, только и будешь пытаться понять, что куда передается и что там делается, ускользнет суть дела. А вот разделение GUI (диалогов) и документа (математики) кто действительно мешал сделать как следует ?
PD>Другое дело, что я не вижу, почему нельзя было отрефакторить этот код, если уж твой менеджер так хочет увидеть нечто более ему привычное. Выделить классы, разбить на части — это же не так много времени займет, во всяком случае, несравнимо с тем временем, которое ты потратил на написание всего этого.
Согласен с вами во всем, и даже с оценкой, почему я и не называл код никогда идеальным, только неплохим.
По рефакторинтгу — а я его делал — я уже отвечал в параллельной ветке (эту ветку тут без конца переносят, так что следить за ней никакой возможности нет).
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Здравствуйте, Loooser, Вы писали:
ЮЛ>Давайте усложним условия: вам постоянно давят на мозги, что код надо написать за две недели. Иначе невыгодно. Что вы на самоокупаемости, и заказ постоянно закрывают. Просто так. ЮЛ>Как скоро вы начнете писать все заново и т.д.? Или у вас будут задачи поважнее.
Начну при первой же возможности (реальной возможности). Т.е. если на написание исходного алгоритма в версии "быстро" мне нужно 2 недели, и руководство дает 2 недели, то ничего переписывать я не буду. Если руководство сказало сделать быстро, я делаю то, что требуется. Но потом ко мне не может быть претензий, т.к. я выполнил все, что от меня просили. Как я понял у вас получилась несколько другая ситуация. И кстати в таких случаях рекомендую все задачи получать в письменной форме.
L>> Если эти строки вам не говорят, как провести декомпозицию большой функции, то вам еще есть чему учиться...
ЮЛ>Учиться никогда не поздно. Только с ваших общих слов ничего не выжмешь. Конкретики не будет? Не стесняйтесь, поведайте, что же вам говорят эти строки?
Пожалуйста, эти строки говорят мне, следующее:
— есть класс который инкапсулирует алгоритм;
— в этом классе есть "единый набор переменных-массивов, которые ... нужны на всем протяжении каждого цикла";
— каждый цикл это отдельный приватный метод класса;
— на вход возможно получится обойтись одним публичным методом;
— на выходе методы возвращающие коллекции компонентов, узлов, контуров. Что там нужно?
Здравствуйте, Слава, Вы писали:
С>О коде. Он бы написан за 2 месяц? И заработал наконец.
Что значит, наконец. Он работал с самого начала и до конца. Тесты это показывали. Все, что над ним производилось, это наращивание функциональности, исследование частных случаев. Когда все случаи были исследованы, он был завершен (условно).
С>А что мешало после этого перевести его в более понятный и читабельный вид? Не сразу, не торопясь, аккуратно разделяя на куски, возможно, покрывая его тестами. С>Вам не дали времени на это, или вы сами не захотели? Я понимаю, что это математика, она никогда красотой не отличалась, но ведь действительно читать тяжело. К таким сложным вещам, как мне кажется, комментарии должн занимать место, сравнимое по объему с самим кодом.
А работа не завершалась никогда. Один этап пройден, заказчик хочет уже нового.
Здравствуйте, Loooser, Вы писали:
L> Пожалуйста, эти строки говорят мне, следующее: L> — есть класс который инкапсулирует алгоритм; L> — в этом классе есть "единый набор переменных-массивов, которые ... нужны на всем протяжении каждого цикла"; L> — каждый цикл это отдельный приватный метод класса; L> — на вход возможно получится обойтись одним публичным методом; L> — на выходе методы возвращающие коллекции компонентов, узлов, контуров. Что там нужно?
Ну это понятно. Только я подобную факторизацию уже сделал, разбил код на 8 подфункций примерно того же назначения, о чем пишете вы. Ну и? Положим, остались части по 500-800 строк, в которых идет обработка. Намного ли это упрощает читабельность?
Мне такая факторизация помогла в дальнейшей разработке только справиться с большим объемом, иметь средство быстро найти нужный раздел. Но если бы я продолжил рефакторинг внутри цельных по смыслу фрагментов, то боюсь, вышло бы не лучше, а хуже, в т.ч. и с пониманием.
Я не против рефакторинга, и допускаю, что и мой код допускает удобный рефакторинг. Только над этим надо думать, нужно время, а его то как раз и нет.
