×Закрыть

Make It Work, Make It Good, Make It Fast

Всем привет.

Сижу вот отлаживаю код, который написан по принципу: Make It Work, Make It Good, Make It Fast.

Похоже некоторые девелоперы не правильно его понимают. Они останавливаются на первом пункте, а два последних откладывают на потом.

Поэтому хочется уточнить, что НЕ стоит ставить таске статус — Done, если Вы выполнили только первый пункт. Хотя бы выполните второй, что бы можно было понять Ваш код, ибо сделай хорошо, подразумевает: рабочий, хорошо читабельный код, который можно потом оптимизировать.

Если Вы остановились на первом пункте, и если у Вас нет привычки сразу делать качественно, то в результате — это нечто, что работает, но понять как оно работает не всегда просто и на это тратится уйма времени, которое могло бы быть потрачено на полезные вещи ИМХО.

Естественно всё сказанное относится к продакшин проектам, а не к пилотникам и прототипам, где главное проверить идею, а не создать продукт.

Проявляйте пожалуйста хоть каплю заботы к своим товарищам.

Спасибо за внимание и всем хорошей жизни.

LinkedIn

Лучшие комментарии пропустить

Не существует кода который кто-то бы не назвал говнокодом

Всі ми пишемо чистий, красивий код.
Просто до нас вже хтось гавно написав, треба все з нуля переписувати, а ніхто ж не дасть.
А там, де самі з нуля писали і вийшло як у тих, так на те були об’єктивні причини, багато причин.

Когда вы сделает остальное ...,

Make It Good, Make It Fast.

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Похоже некоторые девелоперы не правильно его понимают. Они останавливаются на первом пункте, а два последних откладывают на потом.

Проблема в скрамах — аджаилах и нечетких требованиях.

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

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

„Always try harder” VS „Relaх, Just Do It, Be Lucky”

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

но код не всегда должен быть поддерживаемым;

Да, не должен быть для короткоживущих проектов или не изменяемых в течении времени. Коих, наверное, максимум пару процентов.

Фигня, хороший код, который решает задачу с мимнимальными затратами.

Если мы говорим о долго живущем, развивающемя проекте, то ИМХО поддерживая порядок в коде, Вы минимизируете затраты на его понимание и изменение. Простая аналогия. Если у Вас есть понятная система, скажем хранения вещей в доме (в одном ящике инстументы, в другом посуда и т.д.) и Вы ей следуете. То это очевидно, что как только Вам понадобится какая-то вещь, вам не придётся перерывать весь дом что бы её найти. Затраты на то, что бы сделовать этой системе минимальны — выработать привычку класть всё на свои места, выигрыш колоссальный ИМХО.
Но если мы говорим о скрипте, который должен выполниться один раз и про него можно забыть, то естественно там ни к чему делать сложную архитектуру. Достаточно писать так, что бы не запутаться в процессе написания. Выполнить и забыть ИМХО.

Перфекционизм не допустим на коммерческом проекте.

Где здесь было хоть слово о перфекционизме ? Речь идёт о простом, легко читаемом коде, не более того. Что бы открыв его, человек мог быстро в нём разобраться, а не ломать голову тучу времени. Если конечно мы не говорим о каком-то нетривиальном алгоритме, где как не крути, а придётся подумать.

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

Ви власник бізнесу чи програміст?

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

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

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

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

Скорее, от понимания того, что даже получив миллион прибыли, в 99% случаев конфетку делать никто не будет. А будет «нет бюджета на рефакторинг, надо пилить новые фичи, ну и что, что костыли, работает же»

Если код решает свои задачи почему бы и нет, тем не менее часто говонокод не способен сделать это

Вот вроде и тема ничего, и жизненная. Но что-то мне подсказывает, что считая код автора, я буду чертыхатся, ровно так же как и автор :)

1. Я бы не стал по себе мерять окружающих )
2.

считая код автора

Код не надо считать, его нужно писать, читать и понимать )

Код не надо считать, его нужно писать, читать и понимать )

coub.com/view/7lkpt

Я бы не стал по себе мерять окружающих )

Я ж не меряю, я именно подозреваюc
И основанием этого подозрения есть тот факт, что сильно заметен ваш «нонкоформизм» к другой точке зрения :)
Не надо так, SOLID — отнюдь не панацея, он хорош только в хороших руках(окрепших умах), а очень часто в попытке сделать Good начинають смотреть SOLID, вспоминать паттерны, думать что оно еще не Good, а в результате получается дикий оверинжинириг, разобратся в котором часто намного сложнее, чем если бы оставили на стадии Works

Не надо так, SOLID — отнюдь не панацея

Никто не говорит что это панацея и все новые и классные штучки нужно стараться применять везде где можно...
Естественно что во всём должен быть здравый смысл, который к сожалению приходит только с опытом. Но, как показывает моя практика, человек либо использует SOLID, KISS почти всегда (если конечно существующий проект позволяет) или вообще не использует.
Если учесть что код пишет джун, у которого ещё не свормировалось понимание хорошего и плохого кода, то ему желательно использовать на начальных этапах какие-то практики, что бы сформировать культуру написания кода.
Если код пишет «папа» с опытом 10+, то как правило он понимает принципы, и он уже не думает о SOLID, KISS, паттернах и т.д. — у него эти все принципы так сказать «в крови», он пишет так, как будет оптимально в данном конкретном случае ИМХО.

Make It Work, Make It Good, Make It Fast.

Pick any two

А если серьезно, то В ИТ такая парадигма работать никогда не будет, потому что БЫСТРЕЕ, БЫСТРЕЕ, БЫСТРЕЕ, тяп-ляп и готово, главное — на рыночек побыстрее, а то порешает. В итоге автоматизированные унитазы смывают воду по 5 раз, в том числе пока ты на нем сидишь и гадишь, автоматы по сдаче камер в аренду в Сингапурском парке принимают только бумажные купюры, не дают сдачу, отказываются брать купюры, если сумма превысит необходимую, и самая мякотка — камера хранения стоит 15 баксов, купюры в 1 доллар нет, это монетка, купюра минимум два доллара. По прошествии какого-то времени автомат просто сбросит экран, подумав, что ты ушел. Это сделали айтишники, и айтишники будут сидеть и говорить «НАДА ПЛАСТИК ЮЗАТЬ!», а там тоже нихрена не работает! Кассы не считывают карты, считывают по 3 раза, при покупке билета в диснейленд ты попадаешь на «ВСЕМ СТОЯТЬ, ТЕРРОРКОНТРОЛЬ!!! ТЫ ТЕРРОРИСТ!!! ПРИШЛИ НАМ СКАН ПАСПОРТА ЧТОБЫ ДОКАЗАТЬ ОБРАТНОЕ!!!». Айти технологии пошли слишком далеко, и вместо упрощения жизни делают её наоборот, хуже.

Смартфон создавался, чтобы облегчить человеку рабочий процесс, а в результать человек хреначит 24/7, граница «работа/личная жизнь» как правило стерта, мы всегда в онлайне, всегда готовы плотненько поработать, и начинаем день с проверки емэйла, даже не вылезая из кровати. Спасибо, мистер айтец, это то чего я всю жизнь так жаждал! И опять же, на смартфоне ни черта не работает, а если работает — ты своими обновлениями все сломаешь. Да, обновления, нужно каждый день обновлять, день без обновлений это день прожитый зря! Ой, у тебя там что-то на компе стояло, что тебе нужно, а я это не учел, и моя обнова тебе все поломала? Сорян, ты там это, загугли как это решается, гугли, гугли, ГУГЛИ! Никто не чинит свои поделки, софт трехлетней давности уже считается древним дерьмом мамонта! Софт, это, сука, инструмент, я в гараже орудую молотком своего деда, этот молоток еще Сталина видел! Но нет, написал софтину, выложил на гитхаб, потешил свое эго и двигай дальше. А эго у программиста ОГРОМНОЕ! Программист ненавидит всех, кто не может признать его гений! В силу специфики работы прогер сначала всегда ищет то-то плохое, «отлавливает багу», и заявляет о находке всем, «надо же фикс в багрепорт задеплоить». Через год-два «вката в айти» это выливается в профессиональную деформацию, и с такими людьми очень неприятно общаться в жизни. Айти сгнило, потому что гнилые мы все, что его создаем.

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

И при этом постоянные улучшения — мы добавили кнопку которая решала ваши проблемы, теперь мы ее убираем потому что мы сделали платную фичу, теперь эта кнопка платная, апдейты ради апдейтов

Обновления ради обновлений — такое повсеместно.
Feature-driven development, релиз каждые 2-4-6 недель, а вы готовы к инновационному способу заявить миру о себе по-новому? Мы же делаем приложение ещё лучше (на самом деле — топчемся на месте)

Маркетологи и продуктоводы всерьёз обсуждают, как лучше: заголовок товара над или под его описанием, закапывают лишь человеко-часы, беспощадно и необратимо.
И таки в версии 38.26.1.9 он сверху. Ура!! СРОЧНОЕ ОБНОВЛЕНИЕ!
Слово «срочно» слишком обесценилось.
Сейчас везде всё называют срочным, хотя это далеко не оповещение о пожаре с вредным ветром и даже не исправление уязвимости.

Аналитика. Она везде, она отслеживает каждый шаг и интервал между шагами.
Нажали на пункт подпункта — вас записали.
Крутите ленту картинок и остановились, потому что вас отвлёк контролёр проверить билет, или вдруг на телефон кто-то позвонил. Вас записали.

Соцсети для социобпядей — отдельный бег по кругу. Пользователи настолько нетерпеливые, что им впадло комментировать или искать этот эмоджи 🏖 - приложение само его подставит за вас или напишет «Greetings!». Даже если вы об этом не просили, оно лучше знает, потому что вас записали, когда вы крутили ленту картинок.

А если вы не пользовались приложением целую вечность длиной в три дня, вам пришлют уведомление «Bot Bot, a lot happened since you last logged in».
Столько случилось — а вы не знали.
Случилось-приключилось, без вас.
Это же так страшно.
Соцсети внушают, что это действительно трагедия, что вы не в курсе чего-то. (даже подросткам пох_й уже, но не проблема, соцсети ищут более изощренный способ домогаться до ваших мозгов и объяснять вам свою надобность)
Вот я на работе, а котэ дома доедает пальму, скорее всего. А я не знаю, и это действительно плохо. Может купить электронный лазерный управлятор котами?

Таргетированная реклама, куда ж без неё.
Вы пришли домой к девушке починить её виндовс. А тут в браузере реклама детских колясок.
И девушка вам признаётся, что у неё на самом деле есть ребёнок, но сейчас с бабушкой и дедушкой. Её тоже записали. Или её подружку(?)

Инстаграм — пуп для пупов земли.

Знаете, что мне напоминает главная лента, там где идёт сетка картинок/видео по три в ряд?
(на новом айфоне, наверное, по четыре в ряд, но моему пять лет)

Напоминает банку с червями, которую захватили с собой на рыбалку.
Все так же шевелится и копошится.
Как лента.

Те же мысли.
Коллективный разум, так сказать.
Скоро напишу статью, но из-за прокрастинации даже этот комментарий откладывался на завтра.

Feature-driven development, мать его туда. Это и есть наша погибель...

В погоне за фичами, анимированными какашками, новыми кнопками, симпашками, анимашками забыли, с чего и для чего всё начиналось.

В результате — в системах всё больше багов, технический долг растёт, даже на поверхности — в проекте куча warnings, но кто на них смотрит, кто их читает? Больше, БОЛЬШЕ ФИЧ И СРОЧНОЕ ОБНОВЛЕНИЕ В СТУДИЮ.
Срочное обновление на твой телефон! Чтобы случайно на кнопку нажал. Когда ты на вокзале и собираешься вызвать такси.
Оно будет полчаса обновляться.
Правда, есть хорошая новость: до 99% долетит за три минуты.
Можно вызвать такси с телефона девушки, но тут плохая новость — он разрядился.
Ибо в её новом обновлении одно слишком важное приложение постоянно отслеживало местоположение, дабы сообщить ей об удивительных местах рядом и дать возможность по-новому заявить о себе миру, или как там написали маркетологи.

в проекте куча warnings

Можно просто открыть консоль в хроме и офигеть от красного полотона и это я не про то как вякие гостери и адблокеры режут риквесты на рекламу и говнотрекеры и подобное, а конкретно про баги которые сыпятся из UI сайтика.

Через год-два «вката в айти» это выливается в профессиональную деформацию, и с такими людьми очень неприятно общаться в жизни. Айти сгнило, потому что гнилые мы все, что его создаем.

Да не сгнило ещё.

Скорее эффективные менеджеры накрыли ёмкость крышкой и оставили все вариться с собственном соку аджайлов, релизов и дружелюбных опенспейсов.

Раньше айти было с чуть более человеческим лицом, хоть и с тысячами строк в главном файле.

Кстати, о профессиональной деформации, она есть.
Но если работаешь мидлом-сеньором, то не так сильно деформируешься.

У рекрутеров, например, чуть другая проф.деформация: они много врут.
По работе врут. В бытовом смысле врут. По инерции врут, в косметических мелочах врут, даже там где нет смысла врать.

Всі ми пишемо чистий, красивий код.
Просто до нас вже хтось гавно написав, треба все з нуля переписувати, а ніхто ж не дасть.
А там, де самі з нуля писали і вийшло як у тих, так на те були об’єктивні причини, багато причин.

Особливо весело це бачити у російськомовних замовників на фрілансі із формулюванням «там осталось немного доделать» — зрозуміло після тих, хто брався переписати з нуля. Дуже дивуються, коли взнають що «додєлать» коштує дорожче аніж з нуля.

Вообще-то это больше забота тех кто у кормила. Если программиста мотивируют исключительно за результат, то зачем ему напрягаться и отбирать у себя время? Ну а если его код не пройдёт ревью со всеми вытекающими, то в следующий раз он 10 раз подумает перед Done.

Или найдет контору, в которой бюрократия не мешает работу работать

Часто — да. Когда ревью на нескольких уровнях — да.

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

Если ревью влечет изменения (особенно, если есть несколько уровней ревью), ИМО в конторе одна из следующих проблем:
1) Синьоры на самом деле — джуны и не могут самостоятельно написать нормальный код/архитетуру, за ними нужен присмотрщик.
2) Нет code ownership, и люди коммитят в код, в котором не разбираются, в результате кто-то (архитектор?) должен за ними следить и только сам может интегрировать их изменения.
3) Вообще нет тестирования, и баги проще отлавливать через ревью, чем запустить результат и посмотреть, как он работает/ассертит/фейлит авто/юниттесты.
4) Программисты часто покидают контору, поэтому нужна высокая степень взаимозаменяемости.

Согласен, но, так же ИМХО, code review достаточно эффективно когда:
1. В комманду пришёл новый разработчик. И при помощи такого инструмента как Code Review его можно достаточно быстро обучить специфике работы над проектом. Но, если пришёл достаточно опытный дев, и проект нормально написан, он и сам впринципе достаточно быстро вникнет, но всё равно Code Review не помешает на начальном этапе
2. В комманде не только синьёры, а ещё есть мидлы и джуны. Для них Code Review — это лекарство
3. Очень большой распределённый проект, на котором куча «разношёрстных» людей, что-то типа команд на Cross Over и им подобным. Там комманды формируются полностью из вновь прибывших над которыми стоит один тех лид по совместительству менеджер

1) Синьоры на самом деле — джуны и не могут самостоятельно написать нормальный код/архитетуру, за ними нужен присмотрщик.

не обязательно, синьоры тоже не могут всё знать. Обоюдный ревью код очень даже эффективен.

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

1) А як тоді баги з’являються у сіньорів? Всі помиляються та проекти бувають величенькі та складні.
2) Code ownership однією людиною є злом, бо є ще bus factor, щонайменше. Рев’ю також допомагає тим, хто знає цю частину кода, слідкувати за тим, що там коїться. Архітектор/лід звичайно дивиться напівока тільки і довіряє цим іншим.
3) Тести не заміняють рев’ю, рев’ю не заміняє тестів. Різні інструменти. І є ще методи боротьби з багами, наприклад пентестінг, які використовують незважаючи на те, що існують авто та юніттести.
4) Заміняємість таки потрібна. Не тільки на випадок твого уходу/хвороби/відпустки, але і щоб можна було тобі допомогти, якщо треба.

Тут баланс між оверхедом (час, мораль, перемикання між тасками) на ревью та ризиками. На невеликих проектах (одна людина на модуль) обов’язкове ревью швидко починає заважати. Коли тобі треба (алгоритм якийсь злий, наприклад) — то сам попросиш сусіда код почитати. А коли кількасот рядків змін в логіці — навіщо витрачати його час, коли він все одно не зможе нормально відстежити, що відбувається в твоєму модулі.

Сказаное вами — справедливо, но только для тех контор, в которых ревью «на нескольких уровнях» и несет чисто формальный характер. В большинстве случаев оно помогает сделать код лучше и понятнее для команды.

какая компания такие и «спецы»

Ну я бы не судил по еденичному случаю...
Тем более сегодя не так много профи на рынке труда, не всегда получается найти подходящего кандидата, поэтому доукомпликтовывают комманду теми кто есть ИМХО, в надежде что они переймут всё лучшее у более продвинутых товарищей по комманде.

Некоторые начинают с «make it fast», делая преждевременную оптимизацию на говнокоде. Отэто конечно треш и угар, особенно индусятскими методами.

Есть такая штука — Definition of Done.
Она есть всегда, только в некоторых командах она на уровне традиций, у некоторых — закреплена бездушными политиками. И зависит только от стоимости конкретной задачи и стоимости ошибки. Если команда на потоке разрабатывает сайты-визитки по $20 штука, то там оно — тестер не нашел поплывшей верстки за n времени на страницу (даже простейший код-ревью там излишен и дорог). Если разрабатывается медсофт по $x000 за копию и миллионными исками по ошибке — то там будет и анализ покрытия юнит-тестами с падающим билдом при падении этого показателя ниже заданного, и покрытие основного функционала интеграционными blackbox-автотестами на всех поддерживаемых осях с регрессией по производительности, и фашисткий код-ревью (за качество кода вопросы возникают к ревьюеру, а не к код написавшему), и злой архитектор, бьющий по рукам за сильно связаный код всех, до кого дотянется, и много-много живых и еще более злых тестеров. В этом случае бизнес готов платить за качество продукта (в том числе кода) и может его мониторить.
Вопрос — почему вы не все д’Артаньаны, я ведь страдаю от этого,- не должен задаваться разработчиком разработчику (данное высказывание является субъективным и не претендует на истину в последней инстанции)

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

Вопрос — почему вы не все д’Артаньаны, я ведь страдаю от этого,-

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

От такого спасает код ревью, человеком с експертизой в данном поле. Заодно и написавший знания подтянет. А чтобы вопросы имели право возникать — нужны Code Standard, написанные архитектором (или сворованные у больших дядь того же домена). Но все это редко возникает на горизонтальном уровне, в основном только у очень крутых команд из ниндзя-рокстаров, а не обычных украинских сениоров. В остальных случаях — бизнес смотрит на потери времени=денег — меняет процессы, чтоб впредь не допущать такого. Выхода три — при смене работы спрашивать про процессы, про обеспечение качества кода или становиться архитектором и убеждать бизнес в необходимости траты времени на обеспечение качества кода, ждать пока этот процесс произойдет эволюционным путем.

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

Какая от этого польза конкретному деву («мне»)?

Развитие ИМХО. Т.е. будет расти качество твоего кода и кода всей комманды. Как следстиве больше удовольствия от работы и осознания того, что ты сегодня стал на миллиметр лучше, твой код стал ещё более качественным. Как бонус рост твоего рейта на рынке труда.
Если этих процессов, гуиделайнов нет, то там получается так, что кто-то пишет нормальный код, а кто-то нет, т.к. нет единого стандарта. И начинаются конфликты различные. Т.е. там куча ньюансов... Хорошо если комманда нормальная и они просто видят что кто-то делает классно и сами (без указа начальника) начинают учиться. А есть такие, что мол мне за это никто не платит, почему я должен переучиваться и т.д...

Т.е. будет расти качество твоего кода и кода всей комманды. Как следстиве больше удовольствия от работы и осознания того, что ты сегодня стал на миллиметр лучше, твой код стал ещё более качественным. Как бонус рост твоего рейта на рынке труда.

Быстрее стать лидом/архитектором и радикально повысить рейт.

Согласен по всем пунктам, нечего добавить.

є ще декілька випадків:
— може працював зальотний фрілансер за фіксовану оплату — це теж не рахується
— або чуваків припахали пошуріку накостиляти нову фічу при дедлайнах інших завдань ітд

І ще є можливість, що прогер, який писав, не дуже сильний, і то вже є останній етап в його розумінні :P

Не существует кода который кто-то бы не назвал говнокодом

То у вас в конторі була політика працювати по цьому принципу і ставити статус Done після першого пункту, але тепер ви написали на доу і вона зміниться?

Тому що як писати і коли ставити Done — визначається політикою контори. А якщо на це починають впливати пости з доу, то в конторі — треш все одно.

То у вас в конторі була політика працювати по цьому принципу і ставити статус Done після першого пункту

Нет

Не вирішуючи вигадані проблеми.

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

Разобраться можно в любом коде, вопрос лишь в том, сколько на это уйдет времени и сил.
Если код хорошо струтурирован, содержит внятные имена переменных и методов, соблюдается хотя бы принцип single responsibility и методы не по 1000 строк, то время на его осознание несоизмеримо меньше, чем на код, кторый написан без этих guidelines ИМХО.
Или Вы считаете что это все выпендреж ?
Попробуйте поработать на серьезных проектах с высоким уровнем ответственности. Скажем в медицинской сфере. Или почитайте какие требования к коду в NASA.

Попробуйте поработать на серьезных проектах с высоким уровнем ответственности. Скажем в медицинской сфере. Или почитайте какие требования к коду в NASA.

Такой же говнокод, как и везде, только оттестированный.

Хуже. Поскольку секретный

Ну почти весь код (если мы не говорим об Open Source) — секретный, ибо как только Вы подписали NDA, Вы не можете его никому показывать (как правило).

там NDA с грифом «совершенно секретно, перед прочтением сьесть»

Мой обыт говорит о другом.
У нас были достаточно серьёзные требования на длинну методов, на названия переменных, на количество вложенных блоков и т.д. Многоуровневое Code Review, когда твой код смотрит Тим лид, кто-то из членов комманды, плюс на стороне заказчика.
Просто в США серьёзные требования для разработки Мед. ПО. Что-бы пройти сертификацию, необходимо что бы твой код соответствовал определённому количеству критериев.

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

Почти на всех проектах которых я работал(не NASA и не медицина) было несколько этапов ревью, плюс почти повсеместно есть статические анализаторы кода(сонар например) который не позволит вам делать полотна +1000, проверит форматирование, написаны ли тесты итд. Так что такие требования есть не только в тех сферах которые вы перечислили.

Не зовсім вірно, Майк правий. Щоб пройти сертифікацію (FDA) необхідно щоб ви працювали відповідно до налагоджених процесів, де особливий нахил виділений тестуванню, а те який у вас код: назви, розмір методів, костилі нікого не хвилює, вірніше хвилює тільки в тому випадку, якщо у ваших процесах, які мають бути задокументовані написано, що код повинен відповідати стандартам в яких визначені назви, розмір методів і т д

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

У нас были достаточно серьёзные требования на длинну методов, на названия переменных

странно, что именно про эти пункты Вы в первую очередь решили сказать :)

Простите, а что в этом странного ? Про SOLID, KISS, паттерны я уже упоминал в начале.

Про SOLID, KISS, паттерны я уже упоминал в начале.

нет «в начале»

i.imgur.com/KDvxFfm.png
Я думал этих рекоммендаций будет достаточно.

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

i.imgur.com/KDvxFfm.png
Я думал этих рекоммендаций будет достаточно.

оно как бы где-то внизу, ветка обычно читается сверху вниз...

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

оно как бы где-то внизу, ветка обычно читается сверху вниз...

Та да, но я стараюсь вначале прочитать всю переписку, а потом комментировать, но то такое, быват такое полотно что всё и не прочтёшь...

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

Да, книги то есть, но кто их читает ?
Многие гонятся за новизной, за модными фреймворками, главное что бы был логотип модный. Типа, та я лямбда функции пишу в облаке и изучаю нейронные сети, что ты мне тут паришь. А вот азы, А, Б, В многие скипают, хотя да — книг много. Я просто по себе сужу, до прочтении книги «Чистый Код», лично у меня было не мало говнокода, т.е. да, спасибо тех лидам которы старались как-то прививать культуру на проектах где я начинал, но вот в этой книге, многие хорошие подходы собраны в одном месте и если начинаешь это реально применять, просто не можешь нарадоваться, реально лично у меня количество кайфа получаемого от работы стало намного больше, и товарищам стало приятнее со мной работать. Реально это супер кайф писать хороший код, когда всё компактно, хорошие имена, правильная интуитивно понятная структура, классы не перегружены, продуманная архитектура, берёшь проект и просто кайфуешь от того как он сделан ИМХО.

Та да, но я стараюсь прочитать вначале прочитать всю переписку, а потом комментировать, но то такое, быват такое полотно что всё и не прочтёшь...

вы представляете, сколько займёт времени прочитать всю переписку и запомнить где и что хотел ответить, если не найду ответа ниже? :)

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

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

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

Круть ! Спасибо за инфо ! Надо будет купить, почитать ! :)

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

Это детский сад.

Просто в США серьёзные требования для разработки Мед. ПО. Что-бы пройти сертификацию, необходимо что бы твой код соответствовал определённому количеству критериев.

Софт, а не код. К коду требования только со стороны Life/Mission critical подходов, которые делают «красивый» код неимоверным говнокодом, например, никаких переменных на стеке, только в хипе и ещё куча прелестей.

Это детский сад.

Почему ? Вы считаете что читабельность кода не имеет значения ? ИМХО человеческих фактор в основном корень всех багов. И все адекватные технари это понимают и стараются свести его к минимуму. Вводят различные практики типа: SOLID, KISS, guidelines по именованию переменных, длине метотов, структуре и т.д. Что бы сделать код максимально понятным и свести к минимуму человеческий фактор при чтении кода другим девелопером.

сделать код максимально понятным и свести к минимуму человеческий фактор при чтении кода

Это подразумевает, что кодописатель понимает, как вся система в общем и его модуль в деталях должен работать в конкретных случаях. Часто это не так (привет интеграционные тесты, которые для этого существуют; привет тестирование совместимости с чужим софтом).

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

Полностью с этим согласен. Человек должен вначале понять как работает проект в целом, потом перейти к той части которую он будет менять, понять смежные с ней части, взаимные влияния и т.д. И только потом, с пониманием этого делать свои изменения.

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

Почему ?

Потому что этот комплекс подходов не улучшит код никак.

Вы считаете что читабельность кода не имеет значения ?

Читабельность не имеет никакого отношения к качеству кода. Она ортогональна качеству.

И все адекватные технари это понимают и стараются свести его к минимуму. Вводят различные практики типа: SOLID, KISS, guidelines по именованию переменных, длине метотов, структуре и т.д.

Часто я сомневаюсь в их адекватности, многие исходят из того, что ТАК НАДО, не понимая особо зачем, а не так ЛУЧШЕ ИЛИ УДОБНЕЕ. Особенно требование к длине методов выглядит полностью неадекватным, когда несчастный программер, которого давят этим требованием начинается расчленять длинную функцию на какие-то нелогичные подфункции c кучей параметров. Или ещё хуже — микрофункции по три-пять строк со странными именами. И так делает каждый разработчик, превращая код в простыню микрофункций. Уж лучше бы метод был на 1000 строк. И так с любым принципом, возведённым в ранг непогрешимой истины.

Читабельность не имеет никакого отношения к качеству кода. Она ортогональна качеству.

Ну не знаю, если код так написан, то что его тяжело читать, то можно не правильно понять, и возрастает шанс наплодить багов ИМХО.
Так же имя переменной «a» мне мало что говорит о её содержании... Мне придётся тщательно изучить код, где она используется и как, а если это умножить на 1000 строк кода, которые Вы предлогаете в замен компактным методам, но сами можете догадаться что из этого может получиться.

Особенно требование к длине методов выглядит полностью неадекватным, когда несчастный программер, которого давят этим требованием начинается расчленять длинную функцию на какие-то нелогичные подфункции c кучей параметров.

Так а зачем было идти в программеры, если возникает сложность в том что бы разделить 1000 строк кода, на осмысленные блоки и дать им внятные имена ? Это типа что, так сложно ? Да, вначале это будет заставлять задуматься (если привык делать «полотна»), но через неделю, этот программер даже не будет задумываться об этом. Это будет делаться на автомате. Т.е. можно делать правильные действия, а можно неправильные. Силы тратятся примерно одинавовые, но результат ИМХО противоположный. Но просто надо сдедать усилие — переучить себя и потом наслаждаться красивым кодом ИМХО.

Или ещё хуже — микрофункции по три-пять строк со странными именами.

Ну если получается простыня микрофункций, то значит класс сильно большой, что скорее всего говорит о нарушении принципа Single Responsibility, когда в один класс намешано всего. Если у приложения хорошая архитектура, то классы получаются не большие как правило (в моей личной практике, на истину не претендую). И да ты дробишь, не всегда на 3-5 строк, но на смысловые блоки. Типа GetCustomerById, GetCustomerByEmail и т.д. Имя каждого метода даёт однозначное представление о том что он делает, человек сразу понимает что там. Ему даже не надо дрилиться вглубь, смотреть что же там происходит. Он просто читает имя метода и всё понимает. Но если у него идёт полотно, как Вы говорите в 1000 строк, и нет коментариев, то блин, ну не всегда очевидно что этот код делает, приходится вникать, тратить время. А тут GetCustomerById — и всё понятно.
Что проще и быстрее:
1. Осмыслить полотно из 1000 строк
2. Осмыслить компактный метод в 4 строки типа:

var customer = GetCustomerBy(id);
UpdateCustomerPhone(customer, phone);
SaveCustomer(customer);

return customer;
, где ясна основная логика метода, функция которую он выполняет. И уже дальше пройти вглубь того метода, где предпологается изменения — и там тоже самое, есть вызовы методов у которых «хорошие» имена, и тоже ясно что этот метод делает. Ну т.е. для меня очевидно что это намного проще. Левое полушареие мозга так устроено, что он не может работать более чем с 5 — 7 еденицами информации. И читая полотно, ему всё равно приходится дробить это на какие-то блоки, что бы оперировать более мощными понятиями. Вот Вы когда читаете код, Вы ж смотрите, ага в этих 50 строках, что-то вычитывается... Ага а вот там обновляется какое-то поле, т.е. по сути Вы всё равно дробите этот код на блоки. Так почему бы это не сделать сразу и человек откроет код и сразу всё поймёт, ему не придётся делать лишнюю операцию по дроблению кода у себя в голове.

Оять же на истину не претендую, некоторые девы действительно говорят что им удобнее длинные полотна. Один говорил что типа как читает книгу, глава за главой. А там ему надо постоянно уходить в глубокие иерархии. Но я думаю это следствия неправильной архитектуры, глубокие иерархии не должны получаться, если функционал грамотно разнесён по классам, за вычетом конечно некоторых исключений и костылей.

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

Как минимум потому что:
1) это увеличивает класс (С++)
2) ухудшает читаемость, если оригинальный метод был линейным (выполнение сверху вниз) с какими-то коментами — придется прыгать по коду в новые функции вместо того, чтобы читать подряд
3) если используется много переменных состояния на стеке, их надо тянуть аргументами в новые методы, что неудобно
4) когда функция растет эволюционно, разделение сломает историю изменений в гите

Пункт 2 частково вирішується ide, яка може показувати метод без переходу на нього.

Ну если получается простыня микрофункций, то значит класс сильно большой, что скорее всего говорит о нарушении принципа Single Responsibility, когда в один класс намешано всего.

Ты пишешь с позиции GetCustomerBy(id);, тогда это работает. А если у тебя сложный алгоритм, то... начнутся проблемы с тем, чтобы выделить крупные сущности, ибо часто ничего напрашивающего нет. Какие-то мелкие части можно выделить, а что покрупнее... Это очень субъективно и затруднит чтение метода другими, ибо они не будут в курсе твоей идеи.

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

static inline uint64_t next_combination_mask(const uint64_t x)
{
    const int n = ctz64(x);
    const uint64_t a = x & (-x);
    const uint64_t b = x + a;
    const uint64_t c = b ^ x;
    const uint64_t d = c >> (n+2);
    return b | d;
}

Ну какие тут имена можно придумать для a, b, c, d?

Читабельность не имеет никакого отношения к качеству кода. Она ортогональна качеству.

Это было — на ассемблере, но давно прошло. Сегодня качество кода — это в том числе, например, и то, насколько легко его поддерживать, плюс возможность развивать данное ПО, не переписывая его заново. Чиста пару цитат от тех, на чьих книгах и советах мы все учились:

„Programs must be written for people to read, and only incidentally for machines to execute.” (Co. Harold Abelson)

„Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” (Co. John Woods)

„The best programs are written so that computing machines can perform them quickly and so that human beings can understand them clearly. A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.” (Сo. Donald Ervin Knuth)

Сегодня качество кода — это в том числе, например, и то, насколько легко его поддерживать, плюс возможность развивать данное ПО, не переписывая его заново.

Maintainability — это один из многих параметров. И как оно напрямую связано с «читабельностью»? Understandability and Changeability — это не «читабельность».

Читаемость подразумевает под собой, как быстро ты можешь прочитать код поняв его. Не просто прочитать, а прочитать и понять.
Мы же не в детском саду, это очевидно ИМХО. Зачем просто читать что либо, без понимания... Это в школе дети зубрят, не понимая (не все конечно), что бы им поставили оценку, но я думаю тут собрались взрослые люди.

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

Если понять, то это Understandability. Чтобы понять код, иногда достаточно толкового комментария в нужном месте. К самому свойству «читабельности» это опять же имеет малое отношения. Можно прочесть и понять код построчно, но не то, что он делает целиком.

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

У тебя просто настоящего кода не было, вот ты и бесишься!

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

Якщо ви не можете просто описати складне, то в мене для вас погані новини...

Это у меня для тебя плохие новости — ты не видел действительно сложного чего-то ;-)

Вам знаком принцип «разделяй и всластвуй» ? Когда сложные вещи дробятся на более мелкие. Строятся иерархии и т.д. Для чего это всё ? Не ради забавы судя по всему, а для того что бы упростить понимание сложных вещей.

И ?
Прекрасный легко читаемый код.
Разбит на небольшие функции.
Названия переменных соответствуют терминологии... Т.е. если Вы понимаете предметную область то для Вас не составит труда разобраться в таком коде...
То что я и пытаюсь донести...

Другое дело если там бы были не reminder, count, а вместо них: a, b, c... И это было бы полотно в 1000 строк....

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

Дык, алгоритм Евклида в начале любого учебника по теории чисел... Например, мне нравится Виноградов, Основы теории чисел, страница 9, § 2с

Дык суть не в том, а в том, чтобы осознать алгоритм читая

Прекрасный легко читаемый код.

Там внутри main() алгоритм Полларда в 10 строчек

Да, мна сразу вспомнился первый том «Исскуство Программирования» Д.Кнута. Там где-то этот алгоритм вначале был.
Но, суть не в этом, а в том, что если ты не понимаешь предметную область, то какой-бы не был красивый и чистый код, придётся подумать. Без этого никак ИМХО. Но ! Если код написан хорошо, то это сэкономит время.

А мне вспомнилась сортировочная сеть в 5 строчек где-то в конце первого тома Седжвика.

Кароче, я не понимаю к чему Вы клоните ? Нужно писать говнокод, в огромных полотнах с переменными a,b,c,d,... Не разбивать его на функции и плевать на все эти SOLID и прочую фигню ? Т.е. в чём Ваш посыл, просяните пожадуйста...

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

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

Это всё очень хоршо, но мой опыт говорит о том, что как правило кто-то когда-то создал сложный алгоритм, который тяжело понять другому человеку и это нормально. Например программист-математик взял какую то математическую теорию и создал на базе неё алгоритм, который решает какую то задачу бизнеса. Потом его закодил и переключился на другой проект. Остальная часть комманды не владеет этой предметной областью, они просто вызывают его алгоритм. Если там будут комменты, они всё равно ничерта там не поймут, им придётся для этого выучить математику, т.е. подняться на другой уровень абстакции. Даже если они поймут что там куда прибавляется, вычитается и они поймут закономерности, это всё равно не тот уровень понимания, который у них должен быть для внесения правок. Ну хотя если алгоритм простой, то возможно этого хватило бы, но тогда зачем его комментировать если он и так простой.
Но если бы они взяли книгу, скажем по алгебре нашли там математические выкладки, на которых основывается этот алгоритм, поняли их. И уже потом, со знанием основ, начали читать хорошо написанный код. То это было бы правильно ИМХО.

В эмбедеде, например, один и тот же программист может кодить поддержку протоколов и стандартов, работу с файлами (в том числе защита от сбоев питания или крешей во время записи), бизнес-логику приложения, алгоритмы (если по дороге вдруг понадобится) и real-time потоки. И это все должно быть легким и быстро работать. И совместимым с чужим оборудованием, кода которого у тебя нет. И без стандартных библиотек, потому что они не влазят.

Выражаю свою искреннее уважение ембеддед девелоперам, честно.

Но в каком нибудь бизнес приложениее девелопер (если фул стек синьйор):
1. Должен уметь проектировать, поддерживать БД (SQL/noSQL). Т.е. знать реляционную алгебру, методы нормализации, понимать алгоритмы на которых построена СУБД. Я имею ввиду различные индексы, как джоинятся таблицы и т.д., т.е. нужно глубинное понимание, иначе дедлоки ты никак не отловишь.
2. Хорошо знать язык, несколько фреймворков и либ которые используются на проектах
3. Писать бизнес логику
4. Уметь асинхронное программирование, иногда многопоточное
5. Различные статистические алгоритмы для репортингов и прочих штук
6. Понимать домен приложения, т.е. как работает бизнес
7. Иногда по совметсительству фронт енд: HTML/CSS/JS + фреймворки

Но если мы говорим о написании своих алгоритмов — то да, как правило они берутся из каких-то либ. И только в редких случаях, если ничего из существующего не устравивает, начинаешь мутить своё что-то. И да там другая специфика. Я где то там писал, что когда учился (а учился я на «Прикладной Математике»), доводилось смотреть на научный код на Fortran, Pascal, Mapple, свой писать. И да, там есть своя специфика относящаяся к науке. Переменные I,J,K, несколько вложенных циклов и т.д. Но, ИМХО я не считаю этот код хорошим. Сами учённые это признают. Они говорят — мы физики, мы пишем код постольку по скольку, они не умеют его писать, и им на это пофиг. Он раз его написал скрепя зубами и забыл. Оформил в либу и вызывает. Поэтому до сих пор отчасти живы все эти старые языки. Там какой-то метод интерполяции живёт в виде процедуры написанной в 70-ые годы и порядок. Никто его не будет переписывать, ибо «Мы физики, нас вся ваша крастота кода не колышит, нам надо раз сделать и забыть, мы не собираемся этот код саппортить и добавлть новые фичи, работает — не трожь».

Но, если мы говорим о бизнес приложении, которое развивается, то здесь это ИМХО не желательно. Это может быть в прототипе каком-то, пилотном проекте. Но не в боевом приложении ИМХО.

Мне лично помогают коменты типа:
// Case 9876
или
// Possible if XXX
вокруг костылей в коде — не приходится лезть в git blame чтобы понять, зачем этот странный кусок и что сломается, если его убрать или изменить.
Также ИМО хорошо когда есть коменты возле сложных if/else (что и почему/когда здесь происходит) и коменты-заголовки секций в больших функциях и в интерфейсах.

Всё субъективно, для кого-то даже элементарные битовые хаки, вроде x & -x могут у кого-то вызвать затруднение

[Offtopic]
Mystic, ты шоле?
[/Offtopic]

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

Якщо назва функції містила всю необхідну інформацію, то проблем із відновленням контексту не було б. Вона мусить називатися приблизно так «getFactorOfNumberUsingPollardAlgorithm»

І чим та назва допоможе зрозуміти алгоритм? Маєте компактний (10 рядків) код з добре названими змінними та одним викликом функції. За Вашими аргументами його дія має бути очевидною, бо ж коменти в нормальному коді непотрібні. Аж ні. Воно робить невідомо що й невідомо навіщо.

І чим та назва допоможе зрозуміти алгоритм?

Тим, що його можна нагуглити

А коли алгоритм не стандартний з книжки, а свої розробники писали новий під потреби проекта? Що гуглити будете без коментарів в коді?

Документацію, яка описує базові принципи алгоритму.

Себто, Ви прийшли до того, що код сам себе не описує, і до 10 рядків кода потрібно написати окремий документ на кілька сторінок, щоб пояснити, що той код робить?

А коли алгоритм не стандартний з книжки, а свої розробники писали новий під потреби проекта? Що гуглити будете без коментарів в коді?

документацию относительно алгоритмов лучше писать отдельно, т.к. коду свойственно меняться/переноситься и нужно тянуть за собой ещё и комментарии

коду свойственно меняться/переноситься и нужно тянуть за собой ещё и комментарии

так может тогда при переносе и где-то посредине функции сам код порваться, если комментарии из функции выпадают

А ссылка на источник где? Надо
getFactorOfNumberUsingPollardAlgorithmSeeTAoCPVolume3Edition3Chapter6Page365

Видавництво та дату видання забув...

getFactorOfNumberUsingPollardAlgorithmSeeTAoCPVolume3Edition3Chapter6Pa

а завтра эту документацию реорганизуют :)

[Offtopic]
Что бы такого посоветовать, чтобы помочь научиться различать «что бы» и «чтобы»?..
[/Offtopic]

Ти краще за мене знаєш, що я бачив, а що ні ;)

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

З цим ніхто не сперечається. Більшість агриться на банальну фразу, що коментарі не потрібні. Вони думають, що код стане тільки гірше від цього. Але ця банальна фраза призначена для того, щоб в решті решт навчитися писати нормальний код. Дивна та й годі, коментарі не пишеш, а код тільки краще стає! Так, стає краще, факт. Якщо ти не можеш прочитати свій код через пів року, тобі треба переписувати його. Шляхом страждань ти стаєш кращим. А варіант з лінивкою, коли тупо написав коментар та забув, робить тебе деградантом.

Більшість агриться на банальну фразу, що коментарі не потрібні. Вони думають, що код стане тільки гірше від цього.

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

ногда достаточно толкового комментария в нужном месте.

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

Но если там наколбасили чёрт знает что, и читая код, человек не может понять что там происходит, да он понимает что это цикл, это там какой-нибудь if, но что этот код делает в целом не ясно — то это и есть плохой код. Если этот код завернуть в метод (исключить его из Вами любимого полотны в 1000 строк), дать этому методу хорошее название, сделать имена переменных понятными, разбить на под-методы с хорошими именами, то сразу станет ясно что это. И не нужно будет никаких комментариев ИМХО.
В общем, Ваше лично дело как писать код, пишите полотна, комментируйте их, Ваше право...

Код и есть повествование, которое не нуждается в коментариях.

Проблема в том, что ты живёшь в замкнутом мире в стиле «UpdateCustomerPhone(customer, phone);», а мир немного сложнее.

а мир немного сложнее.

Це не значить, що його неможливо описати ;)

Можно описать, вот только читать его иногда сложно. Ну и бизнесс логика в энтерпайзе может быть такой слжоной что без доки нифига не поймешь,что это за сущности и зачем они. А еще удобно и поятно для человека не значит быстро для компа. Или алгоритм обработки данных может быть сильно привязан к архитектуре других пороектов\сервисов или привязан к специфике устройства, специфике работы с данными и прочее прочее... А если это CRUD то конечно там все просто, можно и по пьяни писать и все равно будет просто и понятно.

Проблема в том, что ты живёшь в замкнутом мире

Смотри, ты не знаешь в каком мире я живу, начнём с этого... Мы вообще мало знакомы. Я считаю, что невежественно говорить о том о чём не знаешь, извени.

Саме прикольне, що з часом я повернувся до підходу, який використав пан Niklaus Wirth ще в Паскалі: спочатку декларації, потім код. Це геніальний винахід, який дозволяє чітко зрозуміти, що ти хочеш та навіщо тобі це. Навіть базовий препроцесінг можна зробити під час ініціалізації, що дозволяє написати вже майже половину коду певного методу. Всі змінні перед очима, далі буде тільки код, в якому треба по максимуму уникати розгалуження if/then/else. Це робить вашу логіку максимально «пласкою» та приємною для читання. А що робити, якщо в мене хитрі умови, купа складної логіки, залежності тощо, скажете ви? А вивчіть хоча б раз, як працюють скорінгові системи та скінченний автомат, як працюють суматори. Вся ваша «складна» логіка може бути легко розкладена на складові та описана в пласкому вигляді.

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

У меня лучше идут функциональные тесты — тестируем более-менее готовый фрагмент. Потому как юнит-тестирование (тестирование отдельного метода в TDD) часто требует большого мока для окружения.

Например, вот генератор ходов в русских шашках: inc.gen-moves.c. Чтобы протестировать метод add_mam_takes, нам надо воссоздать контекст вычислений, в котором выполняется этот метод. Это уже не очень приятно, не говоря о том, что контекст может легко менятся в ходе разработки (читай переделывать тесты).

Зато функциональный тест тут работает на ура: для заданной позиции проверяем те ли хода были сгенерированы. Это практически никогда не изменится.

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

Ну.... тимчасові значення...

input_t * restrict const ptr = flake->paths[1] + output * nflake;
memcpy(ptr, base, (nflake-1) * sizeof(input_t));
ptr[nflake-1] = input;

Виносити змінну ptr нагору... Буде забруднення, також треба придумати ім’я, ...

Винести три рядки у окремий метод? Важко придумати назву, по якій можна здогадатися що коїться (три рядки подивився й зрозміло).

Але навіть якщо третій рядок не потрібн, то мені більш зручно писати так, а не робити довгий рядок
memcpy(flake->paths[1] + output * nflake, base, (nflake-1) * sizeof(input_t));

Тимчасові можна залишати як є, якщо так подобається. Це ж підхід, не вимоги мови.

Даже если не брать в расчёт сложные алгоритмы и логику, в которых без поллитра не разберёшься, а взять банальщину типа

«UpdateCustomerPhone(customer, phone);»

то даже тут бывают комментарии весьма кстати.
Например, UpdateCustomerPhone(customer, phone, userId)
где userId, например, ид этого же кастомера. 23-х летний сеньор, начитавшийся умной теории, конечно же скажет «нахуа наговнокодили избыточность, это же ид есть прямо в переменной customer» и сразу же отрефакторит, удалив этот параметр, напишет пост на доу про одних говнокодеров вокруг и побежит за премией к начальству. А если бы код сопровождался комментариями, то в них было бы написано, что этот id передаётся для того, чтобы не правили чужие телефоны, подставив чужой id. Конечно, проверку желательно делать где-то повыше, но как там говорится по поводу того, что модули должны быть самодостаточны и проверяй всё, что приходит на вход ;)

Если код такой, что на него приходится писать комменты, и это не какой-то нетривиальнй алгоритм, то это как правило признак того, что архитектура приложения перестала удовлетворять новым требованиям расширения ИМХО. Т.е. ты не можешь сделать «прямо», и делаешь через какой-то костыль, и следовательно приходится это дело комментить, а то кто-то не так поймёт и наплодит багов.
В идеале, надо рефакторить, менять модель, что бы она поддерживала необходимые изменения нативно, без костылей и код при этом был не двусмысленным и легко понимаемым.
Но если по каким-то причинам, сейчас рефакторить не подходящее время, то да, тех долг и коммент :)

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

а где тут костыль? Здесь проверка безопасности, имеет ли пользователь вносить изменения. Хорошо, над кодом в примере, что я дал выше, можно сделать обёртку, но если например вот так:

UpdateCustomerPhone(customer, phone, companyId)

в бизнес-правилах сказано, что менять телефон кастомера может только админ компании. На клиенте мы знаем ид компании текущего админа, в переменной customer инфы о его компании нет, нужно лезть в базу. Предлагаешь 2 раза лазить в базу, первый раз чтобы узнать companyId для кастомера, сравнить с companyId для текущего админа и, если они совпадают, тогда вызывать изменения? Можно и так, но бизнес-правила могут говорить «поменьше обращений к БД», вот потому что гладиолус, заказчик имеет на это право и у него могут быть свои соображения на этот счёт. Т.е. тогда это реализовывается внутри этого метода, одним запросом к БД выбираются данные для обновления и проверяются права на редактирование. Вот в таком случае комментарий и нужен, что это companyId для проверки прав на редактирование, чтобы очередной 23-х летний сеньор не выкинул этот параметр в праведном гневе типа тут избыточность...

Патерни з далеких дев’яностих... Ностальжі прямо...
Права спочатку перевіряються на вході, ще під час роутінгу. Навіть варіанти, можу редагувати, але дані не належать мені.

Права спочатку перевіряються на вході

Какая прелесть!

Где на входе, до модуля?
И, опять же, бизнес-правила могут гласить что угодно

Та какой модуль, все в контроллере — чих пых и вернул вьюшку, все наглядно и молодежно ))))

кстати, мой опыт говорит, что подход с полотнами (если говорить о вебе) аля запросы к БД прямо в контроллерах, без всяких слоёв, куда читабельнее и стабильнее, чем недоархитектура, когда всё якобы разбили на слои и модули, но при этом пробрасывают на самый верх то, что используется для БД и т.д.

Можуть, але на перевірку це не впливає. Ніяк. Процедура мусить залишатися однією.

Процедура мусить залишатися однією.

т.е. одной? Для чего одной? И почему прямо должна?

Якщо ви змішуєте різні процедури перевірки прав, то ви будете страждати. Уніфікація дозволяє це робити в одному місці та міняти без проблем та наслідків по безпеці. Мусить — тому що діряві продукти це радість для поганців та біда для бізнесу.

Уніфікація дозволяє це робити в одному місці та міняти без проблем та наслідків по безпеці.

а заказчик, например, поставил правило «поменьше запросов к БД».

То воно буде виконано в повному об’ємі.

А почему в объекте customer, нет companyId ?
ИМХО это и есть проблемное место. Вместо того что бы писать коммент, нужно нормально сделать класс Customer. Что бы из таблички вытаскивались все поля, companyId в том числе...
Плюс дать хорошее имя параметру, вместо companyId -> modifierCompanyId или что-то такое, что бы было понятно, что это идентификатор того, кто пытается делать изменения ИМХО.
А внутри

UpdateCustomerPhone(customer, phone, companyId)
сделать вызов метода:
if (IsAuthorized(customer, modifierCompanyId))
{
  // Update logic
}
, где IsAuthorized:
private bool IsAuthorized(Customer customer, modifierCustomerId)
{
  return customer.companyId == modifierCustomerId;
}
А почему в объекте customer, нет companyId ?

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

Что бы из таблички вытаскивались все поля, companyId в том числе...

Вытаскивать и тянуть наверх всё, что не используется. Шикарно :)
Класс customer первоначально был вытянут в каком-то виде чтобы показать юзеру что-то там. CompanyId, вытянутое за компанию, будет прямым нарушением SRP

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

Если есть таблица:

Customer
(
  CustomerId,
  FirstName,
  LastName,
  ...
  CompanyId
)
то это нормально — вычитать одним запросом всю сущность, а не подтягивать по одному полю ИМХО. В любом случае не вижу проблемы, что бы вычитать лишний int32...

А если вы польюуетесь ORM/micro ORM, то тем более, с этим нет проблем ИМХО...

то это нормально — вычитать одним запросом всю сущность

зачем? Вычитывать нужно только то, что нужно для этой конкретной задачи, для которой вычитывается
Плюс ко всему, уже могут быть готовые и оттестированные части, где нет этого companyId

Ок, пишите как знаете. Я бы делал так. Расходимся.

так Ваше решение нарушает SRP, между прочим :) Но это так, мелочи...

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

Первое.
Начнём с того что это изначально дурацкий пример с провекой прав, и такие вещи сейчас решаются аспектами, которые реализуются атрибутами к методу.

Второе.

Вычитывать нужно только то, что нужно для этой конкретной задачи,

Для этой конкретной задачи (Вы сами это написали) нужно проверть, является ли редакотор в той же компании что и кастомер. Поэтому для решения данной задачи должно быть изначально подтянуто поле Customer.CompanyId.

Третье.
Если Вы говорите что для изменения кастормера, нужно проверать соответствие компании, то зравый смысл мне говорит о том, что это надо будет сделать и при добавлении, удалении, обновлении других полей, отличных от phone... Поэтому поле Customer.CompanyId часто используется и здравый смысл мне подсказывает, что часто используемые поля нужно подтягивать сразу, ибо вероятность что они пригодятся достаточно велика...

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

к какому методу? К контроллеру, чтоль? :)

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

как угодно может быть.

Если на каждый чих (фичу) рефакторить систему, никогда не отрелизишься.

Ну и тестировать тоже, юниттесты не всегда есть\вменяемые.

Если на каждый чих (фичу) рефакторить систему, никогда не отрелизишься.

Это говорит о том, что архитектура перестала удовлетворять новым требованиям. И да, иногда можно прилепить костыль и создать тех. долг, но в любом случае рано или поздно (если проект продолжит развиваться), придётся делать рефакторинг. И чем быстрее это сделать, тем лучше, иначе система так обрастёт костылями, что как бы не пришлось всё переписывать с нуля ИМХО...

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

Есть ИМХО в этом подходе и свои плюсы и свои минусы.
Если лепить костыли, то да, вроде как не надо перетестировать функционала много, но...

Если потом последует рефакторинг, который затронет много фунционала (это ж все костыли поотлетают, всё на них завязанное тоже и т.д.), то придётся делать достаточно комплексное тестирование.
Но, если делать небольшие рефакторинги, не дожидаясь того момента, когда прокет стало невозможно сапортить, то это:
1. Не приведёт к той ситуации, когда надо переписать пол проекта, со всеми вытекающими
2. Не будет скачков по затратам в тестировании, Вы отрефакторили часть кода (это не весь проект), QA это протестировали. Т.е. график нагрузки тестировщиков будет более плавный ИМХО.
3. Если лепить костыли, то заказчик будет думать что всё ок, но потом, когда Вы ему скажите, что надо тут всё переписать и это потребует несколько месяцев. И тогда не будут добавляться новые фичи, а просто будет переписываться уже готовый функционал и заново всё перетестироваться, боюсь ему это может не понравиться. Но всё зависет от заказчика. Есть такие, что они готовы на такие риски, лишь бы только сейчас добавить фичу побыстрее и любой ценой...

Лично я бы выбрал серединный путь. Да, иногда добавлять костыли, ибо не известно что будет завтра и возможно сегодняшний рефакторинг преждевременен, но когда ясны тенденции дальнейшего развития проекта, делать рефакторинг, а не доводить до того момента, когда нужно всё переписать из за костыля на костыле. Так нагрузка на комманду будет распределена более плавно и течение проекта будет более прогнозируемым ИМХО.

Если потом последует рефакторинг, который затронет много фунционала (это ж все костыли поотлетают, всё на них завязанное тоже и т.д.), то придётся делать достаточно комплексное тестирование.

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

если делать небольшие рефакторинги

 Вы не сможете менять ни высокоуровневую архитектуру при эволюционном росте проекта (MVP -> external release -> more features -> v 2.0 -> ...) ни даже количество и роли классов внутри модуля.

Если лепить костыли, то заказчик будет думать что всё ок, но потом, когда Вы ему скажите, что надо тут всё переписать и это потребует несколько месяцев. И тогда не будут добавляться новые фичи, а просто будет переписываться уже готовый функционал и заново всё перетестироваться, боюсь ему это может не понравиться.

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

Если изначально высокоуровневая архитектура была нормальной

Вопрос нормальности архитектуры, достаточно скользкий. Т.е. да, есть общие принципы как: расширяемость, поддерживаемость, гибкость, и т.д. и т.п., но как показывает практика на начальном этапе, не всегда удаётся предусмотреть как будут меняться требования. И то, что вчера казалось нормальной архитектурой, завтра может стать недопустимым.
На пример, вначале проектировали какое-то n-tier/MVC app, но потом функционал разросся так, что его уже не возможно саппортить, нужно переходть к SOA/microservices. И вроде бы закладывались вначале на вполне адекватную архитектуру, а оказалось, что потом её перестало хватать.

Тестирование после рефакторинга нужно в любом случае.

Да, но вопрос в каком объёме. При больших рефакторингах, когда затрагиваются основы или большое количество модулей, нужно перетестировать большинство функционала. Но какой-то промежуточный рефакторинг, скажем поменялась структура некоторых бизнес объектов, соответственно поменялись в базе таблицы, ОРМ слой и т.д. То в данном случае придётся перетестировать только функционал связанный с этими бизнес объектами и зависимыми от них объектами. Но это далеко не всё приложение.

Вы не сможете менять ни высокоуровневую архитектуру при эволюционном росте проекта (MVP -> external release -> more features -> v 2.0 -> ...) ни даже количество и роли классов внутри модуля.

100%, никто не спорит. О высокоуровневой архитектуре речи не идёт. Т.е. это глобальные изменеия, которые так или иначе потребудет полностью всё перетестировать... та это целое дело )
Я наверно не правильно выразился, я скорее говорю о внутреннем дизайне приложения. Ну например потребовалось добавить какие то поля связанные с бизнес объектом, но эти поля связаны не 1 к 1, но решили не плодить пока новых таблиц и пренебречь нормализацией, в угоду сроков. Костыль — костыль. Потом возникает ситуация, что нужна новая сущность, и что бы её создать, нужно нормализовать таблицу, ну или лепить очередной костыль. Т.е. уже понятна тенденция, что эта часть будет обрастать новыми сущностями. Говорим — стоп костыль, давай будем рефакторить, разность те поля по новым таблицам, нормализовывать базу, деать всё по правильному, ибо скоро мы не сможем это сапортить... Перепилили, тестеры перетестили связанный функционал, все довольны: заказчик получил небольшой фриз, в день-два, и проект лишился ненужных костылей ИМХО.

архитектура перестала удовлетворять новым требованиям.

Возможно, под «архитектурой» мы понимаем разные вещи.
Я под ней понимаю базовую структуру приложения: количество и назначение потоков, парадигму общения между ними (actors, pipes and filters, MVC, 3-tier, microservices), набор высокоуровневых классов, описывающих/проксирующих базовые сущности и каналы взаимодествия между ними.
Содержится ли CompanyId внутри Customer — это детали реализации, а не архитектура.

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

Understandability ... — это не «читабельность».

Если кому-то удается успешно понять и поддерживать код, не читая его, то таки да, Вы правы :8) но большинство и читая чужой код, не сильно врубается :(

Чукча приходит в издательство и представляет свою книгу. Редактор смотрит и видит вместо букв — неведомые закорючки. Он спрашивает: — Чукча, ты читать вообще умеешь? — Чукча, однако, не читатель. Чукча — писатель. ©

Особенно требование к длине методов выглядит полностью неадекватным, когда несчастный программер, которого давят этим требованием начинается расчленять длинную функцию на какие-то нелогичные подфункции c кучей параметров.

Лучше смотреть всё-таки на цикломатическую сложность метода. Часто длинная функция это не линейный код в стиле fprintf(f, "New line in a file.\n");. Чаще всего это некоторая логика. Внутри которой присутствуют циклы, вложенные условия и т. п. И навигация по такой функции тоже может составлять проблемы.

И навигация по такой функции тоже может составлять проблемы.

Ну а навигация по 20 микрофункциям — это разве гораздо легче? Вот про то и речь.

Есть просто сложность алгоритма, от которой никуда не уйти. И тут как в том анекдоте, «одевай трусики, не одевай трусики...» Тут уже вопрос вкуса и целое искусство, как написать код читаемым. Но, наверное, 1000 строчек кода это всё-таки перебор. Пересмотрел свой код, там рекорд в районе 250 строчек, и то выглядит угрожающе common.c:1048.

у меня почему-то тоже 250)

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

Вот ога, правда жизни!
Только я бы «зачастую» поменял на 90+% случаев

и свести к минимуму человеческий фактор при чтении кода другим девелопером.

Боюсь вы путаете что такое вообще «человеческий фактор» но если в данном контексте то «свести в минимуму» будет именно целенаправленно «свести к минимум необходимость чтения кода человеком в принципе» тогда можно будет говорить об «снижении человеческого фактора».

То что вы (здесь обобщение) делаете код более удобным для человека это как раз наоборот «увеличение человеческого фактора».

Довольно хороший пример на тему современные «пакователи» (как там они правильно называются?) JS кода фокус в том что интерпретатору всё равно более того «лишние» переводы строк он видит только как «пробелы» в свою очередь «лишние» соотв. удалив все переводы строк и пробелы это прямо сделает код более «удобочитаемым» именно для компьютера что в свою очередь «отрицает удобство для человека» и соотв. «человеческий фактор».

Вот сейчас у меня на проекте вопрос «а зачем?» мол якобы «красивее код» и идёт «работа» сделать «старый сишный код более плюсовым» при этом «работа» именно «сделать видимость якобы «удобочитаемость для человека» ни об каком реальном рефакторинге и оптимизации и вообще «вычитывании» речи не идёт настолько что... ))

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

Так вот это и есть тот самый «детский сад» о котором говорит Майк и он реально не имеет никакого отношения к mission critical но с другой стороны он таки довольно популярен причём среди больших (даже без «довольно») корпораций хотите узнать почему?

Вопрос в том что этим местом они подменяют архитектурный подход как метод «освоения сложности» чисто организационными подходами ориентированными на «освоение работы» максимального количества кодеров низкой квалификации. Именно когда стоит вопрос «управлять» 100500 таких «кодеров» тогда такие «методы задания метрик методов» (каламбур) с одной стороны единственная возможность с другой ну надо признать как-то оно работает.

Но здесь важно (по крайней мере мне и чисто технически) не путать цели. Архитектура это цель «освоения сложности объекта» а «метрики кода» это цель усвоения 100500 низкоквалифицированных работников.

Второе всё равно не может создать первое. Я проверял. ))

Боюсь вы путаете что такое вообще «человеческий фактор»

Человеческий фактор, это способность человеком делать ошибки. И рост их числа с повышением сложности выполняемой им работы ИМХО.

Довольно хороший пример на тему современные «пакователи» (как там они правильно называются?) JS кода фокус в том что интерпретатору всё равно более того «лишние» переводы строк он видит только как «пробелы» в свою очередь «лишние» соотв. удалив все переводы строк и пробелы это прямо сделает код более «удобочитаемым» именно для компьютера что в свою очередь «отрицает удобство для человека» и соотв. «человеческий фактор».

Ну как сказать, ужимается сам файл, меньше кушает трафика (хотя уже давно контент зипуется и dial-up канул в лету), парсеру на миллисекунды меньше трудиться. Плюс таким образом они пытаются «закрыть» код, что бы сложнее было его реверсить... Никто не говорит что это делается для понижения «человеческого фактора». Это делается сугубо для продакшина, что бы выжать максимум перфоменса...

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

Ну так это полный бред... Где я писал что нужно так делать или рефакторить ? Я просто говорю, что надо писать нормальный код, следовать SOLID, KISS если это возможно, давать нормальные имена переменным и методам, хорошо структурировать, не делать невменяемые «полотна». Вот и всё.

какой нафик хип в лайф критикал? все аллоцируется вовремя сборки

Нежелательно. Есть уникумы, которые переменные отправляли в rodata вместо data сегмента и потом оно раз в полнолуние крешилось при попытке записать значение.

Но ты прав, что оно «аллоцируется при старте», поэтому особого значения хип в данном случае не имеет.

никаких переменных на стеке, только в хипе

щито? в чем смысл?

Смысл в прогнозируемости расхода стека.

чтобы не было стековерфлова?

Да. В основном это касается структур, размер которых не ясен на глаз, ну и запрет использования VLA.

Стек может быть сильно более ограниченным в размере чем хип.

ЗЫ: просто программеры обычно привыкли не считаться с его размерами ну кроме бесконечной рекурсии и технически они правы настолько что поддержать 10к коннекшинов «традиционными средствами многопоточности» не получится чисто технически потому что оперативки не хватит на размещение стеков на 10к потоков ))

Понятно, спасибо за объяснение.

Например, ядро Linux имеет ограничение в 4k или 8k для стека. А это мало. Основная причина в том, что при определенных условиях, обращение к отсутствующей странице в памяти вызовет kernel panic, а значит стек нельзя выгружать в swap. Получается большой расход ресурсов с учётом того, кто Linux может быть запущен на самом разном железе.

Не только в США, Израиль, например. Но зачастую, по архитектуре там требований особо нет, больше вопросов по синтаксису, аля чтобы default был в switch’e и такое прочее.

мне приходилось работать с медицинскими компаниями, качество кода которых проверялось какими-то компетентными органами

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

Откуда у государства компетентные органы? Все раз за разом путают код и софт — это абсолютно разные вещи.

почитайте какие требования к коду в NASA.

Вы когда-нибудь код ученых видели?

Да видел. Я учился на «Прикладной Математике». Мы учили Fortran с его бесчисенными библиотеками численных методов и т.д. Так же, Mapple и подобные штуки.
Да, и нас самих, учили писать код для научных рассчётов, а не делать бизнес приложения. Например на паскале сделать софтину которая строит эпюры моментов для какой-то балки и в таком духе.
Да, там конечно сам чёрт ногу сломает :) Идут полотна вложенных циклов с переменными типа I,J,K и т.д. :) Но оно понятно, когда ты знаешь, например, что это формула умножения матриц и есть перед глазами формула с этими же i,j,k на бумаге. И там как правило развесистые комментарии, если это какая-то либа...

Same shit. Matlab и адский салат из i,j, k в коде — наше все

I,J,K — ещё фигня. Их мало и они простые.
Не фигня, когда в каком-нибудь методе Рунге-Кутты 6-го порядка, окосев от названий переменных, вставляешь implicit none в начало подпрограммы и обнаруживаешь, что в одном месте кода используется переменная N2MPK, а в остальных — N2MKP. Опосля чего начинаешь резко сомневаться во всём, что считалось 20-30 лет на этом коде.

Я встречал достаточно радикальоное предложение переписать всю литературу по физике. И вместо однобуквенных обозначений использовать идентификаторы :)

И вместо однобуквенных обозначений

Проблема же ж в основном в том что латинский алфавит не поддерживает греческие однобуквы ))

ЗЫ: это не считая математической записи математических выражений.

Идея как раз в том, чтобы вместо греческих букв просто писать идентификаторы. Например, вместо F = \gamma \frac{m_1 m_2}{r^2} писать

Force = GravitationalСonstant frac(mass1 mass2, Radius^2)
или
Force = GravitationalСonstant * frac(mass1 * mass2, Radius^2)
или даже
Force = GravitationalСonstant * mass1 * mass2 / Radius^2

Основная проблема тут в том, что для математика/физика гораздо важнее внешний вид формулы, а что именно участвует в формуле часто второстепенно. А длинные идентификаторы как раз затрудняют понимание того, что происходит. Более того, одну и ту же формулу можно записать по разному, подчёркивая ту или иную особенность

Не только для математиков. Ты тоже хрен прочтешь и поймешь такую уродливую формулу. Хотя отсутствие греческих букв в ASCII было кривым решением в свое время.
Да и сейчас, затрахаешься во многих языках программирования идентификатор греческими буквами записать.

Ну... мы вылазим за семь бит ASCII:
24*2 (греческие) + 26*2 (английские) + 10 (цифры) = 110.
А еще надо управляющие символы (32 многовато конечно), знаки препинания (минимальный набор уже !"'~@#$%^&*()+=_{}[]\/?.,<>| уже 25..

Ну а сейчас в общем-то и не проблема набрать, это больше возможности текстового редактора. Например, Ctrl+K a * позволяет легко вставить α.

Ну... мы вылазим за семь бит ASCII:

В extended ASCII была целая линия отведена под греческие символы — 0xE0-0xEF. Только туда c появлением VGA адаптеров полезли русефекаторы.

Ну это не было частью какого-либо стандарта. Общее правило было чтить значения символов с кодами до 127 включительно, а выше можно использовать по своему усмотрению. И там жили русские символы, псевдографика, разные варианты из европейских алфавитов, ... И много кодировок cp866, KOI-8ru, KOI-8ua, cp1251, ...

Ну вот, кодировка cp866: link. Куда там можно влезть? Ряды BCD заняты псевдографикой, и без них грустно было бы работать в NC, ME, TP, ... где вместо рамок было бы чёрт знает что. Далее, 4 ряда нам надо для символов кириллицы. Жертвовать рядом F, как по мне, было наилучшим решением, потому как символ FF иногда рассматривался как спецсимвол (например, FTP по этой причине часто не воспринимал имена файлов в кодировке cp1251 с буквой «я»).

Ну это не было частью какого-либо стандарта.

Ничего себе. Это был мегастандарт.

И там жили русские символы, псевдографика, разные варианты из европейских алфавитов, ... И много кодировок cp866, KOI-8ru, KOI-8ua, cp1251, ...

Это было потом. Вначале не было никаких кодовых страниц, была базовая extended ASCII.

Ряды BCD заняты псевдографикой, и без них грустно было бы работать в NC, ME, TP

Псевдографику было запрещено менять. Не потому что грустно, а потому что больно. Я вот специально не скажу почему, интересно кто-то ещё помнит почему?

Кто это стандарт использовал, кто его опубликовал?

IBM PC Industrial Standard — туда входят не только extended ASCII. Использовали все — это до сих пор доминантная платформа.

Не все, например, Atary этому не следовал, Z80 тоже. Так, стандарт одной фирмы...

Atary

Atari.

Z80

Это просто процессор.

Так, стандарт одной фирмы...

Окстись.
arstechnica.com/...​s/2005/12/total-share/10

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

И что? ISO/IEC 646 как минимум с 1964 года говорит, что нет никакой стандартной даже 7 бит ASCII, т.к. тоже позволяет менять кодировки. Или всё-таки есть стандартная дефолтная ASCII?

Вот тебе греческая 7бит ASCII:
www.itscj.ipsj.or.jp/iso-ir/018.pdf

Начнём с того что Atari — компьютер, т.е. некторый набор железа (если конечно Вы не имели ввиду Атари, как некий целостный комплекс железа и ПО), а Z80, просто процессор.
А железу пофиг не все ваши ASCII и прочее, как его запрограммируешь, так оно и будет работать.
Кодировки и прочие штуки появляются как правило на уровне системного ПО, но иногда и прикладного, как это мы можем видеть в браузерах, которые заточена под всё что только можно...

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

Ну, реально и немного формально — не всегда пофиг.

Пример 1: команда CPUID в x86 отдаёт имя производителя и brand string процессора в ASCII.

Пример 2: так называемые unpacked decimal команды в IBM System/360 были рассчитаны на кодировку EBCDIC, а именно они в ней формировали число в памяти. Цифры от 0 до 9 кодировались от F0 до F9, а не от 30 до 39, как в ASCII. Аналогично, плюс и минус перед числом были из EBCDIC.

Если ещё точнее — в S/360 был переключатель в 1 бит в PSW, использовать тут EBCDIC или ASCII, но было крайне мало тех, кто ставил его в ASCII. В S/370 его убрали, оставив только EBCDIC.
Зато в S/390 добавили, из-за тотальной юникодизации, команды преобразования между UCS4 и UTF8! (хотя с unpacked decimal они никак не связаны, и вообще последнее не рекомендуется к использованию).

Так что в процессорах тоже могут быть заточки :)
конкретно в 8086 их, да, не было.

Пример 1: команда CPUID в x86 отдаёт имя производителя и brand string процессора в ASCII.

Да, но это никак не влияет ни на что по сути, но чисто формально — да, в EEPROM зашиты символы в ASCII.

Пример 2:

Не спорю, на верняка есть какое-то специализированное железо, в которое «зашиты» алгоритмы по работе со строками...

Но, ИМХО это настолько узкоспециализированные случаи и их настолько мало по сравнению с общим количеством железа, что ими можно пренебречь...

Это было потом. Вначале не было никаких кодовых страниц, была базовая extended ASCII.

Не было никакой фиксированной «extended ASCII», это тебе приснилось.
То, что ты этим словом называешь, это было codepage 437.
А на самом деле это было множество таблиц, каждая для своего случая. Вот только мелкая цитата:

DOS computers built for the North American market, for example, used code page 437, which included accented characters needed for French, German, and a few other European languages, as well as some graphical line-drawing characters. The larger character set made it possible to create documents in a combination of languages such as English and French (though French computers usually use code page 850), but not, for example, in English and Greek (which required code page 737).

То есть даже в пределах одной линии IBM PC для разных стран зашивались разные наборы.

Среди этого, русские «основная» и «альтернативная» были только мелкой частью всего бардака.

Сам же бардак регулировался пачкой стандартов — например, стандартами ECMA-13,35,48 (лежат в открытом доступе, можно почитать, узнать много интересного — это скорее не тебе, раз ты оригинальный ISO646 видел, но остальным может быть полезно). Они определяют esc-коды для включения конкретных страниц (для тех, кто их отрабатывает — например, принтеры), методы построения многосимвольных кодировок, и тому подобное.

Самое интересное в них, что даже ASCII не являлся в этом плане однозначным стандартом! Стандартом был IA5, а ASCII — только конкретная его разновидность. То, что потом стало ASCII = IA5 по умолчанию, и именно ASCII лёг в основу Unicode — это уже чисто фактор доминации США.

Псевдографику было запрещено менять. Не потому что грустно, а потому что больно. Я вот специально не скажу почему, интересно кто-то ещё помнит почему?

Если ты к тому, что в ней рисовали большинство программ типа Нортона, то это банально.

Не было никакой фиксированной «extended ASCII», это тебе приснилось. То, что ты этим словом называешь, это было codepage 437.

Проснись. То, что ты называешь «437» появилось гораздо позже. Вначале был CGA с аппаратным знакогенератором.

А на самом деле это было множество таблиц, каждая для своего случая. Вот только мелкая цитата:

Это было гораздо позже.

Если ты к тому, что в ней рисовали большинство программ типа Нортона, то это банально.

Нет. Стыдно не знать! Shame on you! %) VGA контроллеры только при рендеринге символов псевдографики для 9×16 матрицы использовали не zero stuffing для последнего столбца, а репликацию последнего бита. Фича аппаратная, неотключаемая, эмулируется по сей день. Это тебе ещё монетка в копилку extended ASCII. Если туда запихнуть любые буквы в тот диапазон, то в 9×16 они будут невообразимо уебищными на экране.

Проснись. То, что ты называешь «437» появилось гораздо позже. Вначале был CGA с аппаратным знакогенератором.

И в нём для североамериканского рынка была зашита 437, а для других — другие кодировки.

Это было гораздо позже.

Тогда же.

Нет. Стыдно не знать! Shame on you! %) VGA контроллеры только при рендеринге символов псевдографики для 9×16 матрицы использовали не zero stuffing для последнего столбца, а репликацию последнего бита.

Я знаю, но не вспомнил.
Как-то оно не било именно мне граблями, поэтому не вспоминается.
И ты неправ в деталях, потому что — цитирую -

There are modes with a character box width of 9-dots (e.g. the default 80×25 mode), however the 9th column is used for spacing between characters, so the content cannot be changed. It is always blank, and drawn with the current background colour. An exception to this is in Line Graphics Enable mode, which causes code points 0xC0 to 0xDF inclusive to have the 8th column repeated as the 9th. These code points cover those box drawing characters which must extend all the way to the right side of the glyph box. For this reason, placing letter-like characters in code points 0xC0—0xDF should be avoided. The box drawing characters from 0xB0 to 0xBF are not extended as they do not point to the right and so do not require extending.

И диапазон у́же, и Line Graphics Enable начиная с EGA и VGA — регулируемо (см. PORTS.B в RBIL). Вот в CGA/MDA и раньше, да, оно не управлялось, но там и штатной возможности смены фонтов не было.

Так что правильно говорить не «нельзя помещать буквы в этот диапазон», а «плохо помещать псевдографику в другой диапазон».

Фича аппаратная, неотключаемая,

Отключаемая, RTFM.

И в нём для североамериканского рынка была зашита 437, а для других — другие кодировки.

Ты выдаешь желаемое за действительное. Покажи мне локализованные аппаратно IBM PC XT, не клоны.

И ты неправ в деталях, потому что — цитирую -

Я тебя попрошу не цитировать то, что ты не знаешь сам.

The box drawing characters from 0xB0 to 0xBF are not extended as they do not point to the right and so do not require extending.

Полная ахинея — напиши тем, откуда ты скопировал. Весь диапазон B0-BF также имеет репликацию, поэтому правильно указывать зону B0-DF.

И диапазон у́же, и Line Graphics Enable начиная с EGA и VGA — регулируемо

В EGA не было 9×16. Line Graphics Enable был оригинально недокументированным битом в регистре, его наличие было обусловлено режимом, в котором текстовый контроллер дисплея мог рендерить 512 символов. В любом случае default state — это 1. По поводу неотключаемости был неправ.

Так что правильно говорить не «нельзя помещать буквы в этот диапазон», а «плохо помещать псевдографику в другой диапазон».

Я не вижу противоречия. Тем более «правильности» в этом выводе.

Я тебя попрошу не цитировать то, что ты не знаешь сам.

Все мы находим 99% информации не собственными экспериментами, а из книг или интернета.
Если ты считаешь, что неправильно — ok, у тебя есть все возможности исправить.
Но почему тебе не кажется, что это ты ошибаешься, по прошествии уже 30+ лет от выхода этого всего хозяйства?

Полная ахинея — напиши тем, откуда ты скопировал.

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

В EGA не было 9×16.

Да, согласен. По крайней мере для типовых версий.

Я не вижу противоречия. Тем более «правильности» в этом выводе.

Что тут можно не увидеть? Отключил — и грузи себе буквы без возможного двоения.

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

Потому что у меня есть исходники железа? Или потому что я могу попробовать? %)

(Я еще готов предположить, что разные ревизии отличались в поведении.)

Нет. Я могу допустить только наличие первых полностью несовместимых клонов VGA, потом IBM открыла спецификацию. Если подобное и было, то очень короткий период. Если ты помнишь турбовижн, он использовал все символы псевдографики, и если бы не было репликации, то этот горб бы всплыл моментально.

Intel в описании своего эмулятора VGA даже положил дисклеймер:

In some literature describing the VGA standard, the range of extended ASCII codes that are said to include the line-drawing characters is mistakenly specified as C0h to DFh, rather than the correct range of B0h to DFh.

www.x.org/...​chv-bsw-vol12-display.pdf

Это всего лишь википедия. Напиши сам, а лучше исправь со ссылкой на надёжный источник. Твоей памяти тут, извини, недостаточно.

Я не исправляю википедию — там часто сидят тупиздни, по крайней мере в секции графики. По факту когда-то я сделал штук двадцать исправлений, приняли 2, потом одно из них исправили опять назад. Хер с ними.

Что тут можно не увидеть? Отключил — и грузи себе буквы без возможного двоения.

Так поправь википедию, так что даже она говорит о:

For this reason, placing letter-like characters in code points 0xC0—0xDF should be avoided.

а не о псевдографике.

16 символов вместо _минимум_ 2*24 для полного алфавита это вообще издевательство, о котором не стоило упоминать.

Это для формул, а не для поддержки греческого. Их хватало на 98% всех случаев.

Блин в чем проблема написать статью ну или доку или отчёт и в комменте ссылку на номер формулы. А так формула выглядит вообще-то сильно непривычно

Часто удобнее в комменте к методу просто формулы записать, а не ссылку на доку где-то там. Это можно в стиле теха записать, но мало кто прочитает.

100%. Куда-то лезть, где-то там в доке искать формулу... Гораздо эффективнее когда она перед глазами в коде.

Только вот большинство редакторов до сих пор не научилось теховскую нотацию в картинку сразу переводить. Да, можно дописать скриптик, что тех дернет и картинку слепит, правда в доку уже (doxygen это и делает).
Весят IDE уже безумно, а такого простого не умеют до сих пор, не говоря уже о простых текстовых редакторах.

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

Только вот большинство редакторов до сих пор не научилось теховскую нотацию в картинку сразу переводить.

Ответ очевиден — это нафиг никому не нужно, кроме едениц, типа тебя, количество которых стремится к нулю по отношению к общему количеству девелоперов ИМХО.

Весят IDE уже безумно, а такого простого не умеют до сих пор, не говоря уже о простых текстовых редакторах.

Опять же, ответ очевиден — бизнес не будет добавлять в IDE фичу, которая нужна 1% девов. Это не рентабельно с точки зрения бизнеса. Они запилят 100500 фич, которые нужны большинству девов... Там улучшат интеграцию с дебагером, какие-то плюшки ушлучшающие юзабилити, продуктивность девелопера и т.д.
Каждая фича имеет свой приоритет, и видимо поддержка TeX у них где-то там на задворках беклога...
Поэтому, есть специальные плгины, для решения подобных, узконаправленных фич, ссылку на который (как пример) я привёл.

Пока у всех, как начинаются «улучшения», так их тулом пользоваться становиться невозможно. Я вот уже боюсь, что скоро QtCreator начнут «улучшать» — ибо основные нужные функции уже не глючат.

но мало кто прочитает.

Могут, но не все.

Это выжимка : habr.com/...​mpany/hexlet/blog/303160 ; видел, кажется на том же Хабре и более подбробную версию в оригинале, и свидетельствую: в т.ч. и административные меры типа code style, code review и фейсом об тейбл за их нарушения и профанацию, могут привести к значительному сокращению количества ошибок в коде.

Забавные требования, интересно, сколько из современных проектов можно было бы сделать (при вменяемом бюджете) их поддерживая.

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

 То, что могут привести — это да. Вопрос в цене: замедление проекта и увольнение наиболее активных сотрудников. Смотри The Parable of the Two Programmers.

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

Т.е. выработать навык писать код определённым образом и довести это до автоматизма дело нескольких недель ИМХО

Вообще это автоматизируется единожды ну с дальнейшими доработками по мере выхода новых «правил» и полностью «закрывается» программно реализованным «прихорашивателем кода» всё ))

объяснить ему, что это хорошо, что так он вырастет как специалист, будет делать свою работу более качественно

Это бред. Ещё раз вы путаете цели так и сам термин «специалист» и в свою очередь цели его «специализации».

ведь в NASA делают не сайты визитки, тут на кону миллиарды долларов и человеческие жизни.

Вы не НАСА простите ))

Это бред. Ещё раз вы путаете цели так и сам термин «специалист» и в свою очередь цели его «специализации».

Термит «специалист» отражает такое понятие как квалификация. Чем более качественный код Вы пишете, тем выше Ваше квалификация ИМХО. Т.е. это один из праметров, по которому можно сказать о квалификации разработчика.

Вы не НАСА простите ))

Ну я думаю помимо NASA есть не мало компаний, которые делают проекты, где цена ошибки, потеря репутации, больших сумм, как следствие увольнений и т.д. А возможно и человеческих жизней. В любом случае, даже если Вы делаете сайты визитки, не стоит прекращать своё развитие ИМХО...

ОК, штрафом по кошельку, а не фейсом об тейбл :)

И +$500/month тому, кого наймут на его место?

Опять-таки не обязательно; +$500/month — это скорее традиционная забота того, кто ушол. Есть разные промоушены для этого, джуны например в которых коде стайл легче вставить :8)
Вааще это весьма философский вопрос, из субЪективного идеализьма я бы сказал: есть ли во Вселенной нечто совершеннее моего кода или же ясен пень что нету. Если программер соглашается с тем, что абсолютное совершенство недостижимо, но на пути к нему находятся не только он сам, но и все его товарищи по тиму (в том числе бывшие, заложившие основы сего кода, и будущие, которые будут исправлять его ошибки), тогда фейсы, тейблы и все остальное в процессе даже не возникает.

Забавные требования, интересно, сколько из современных проектов можно было бы сделать (при вменяемом бюджете) их поддерживая.

Нормальные )) надо конкретно смотреть на чём они писали т.е. конкретно об чём это. Может там и компилятора не было ))

Другой конкретный пример конкретной практики в реальном коде есть 4 (четыре) функции написанные на ассемблере (зачем-то) лично я готов спорить что переписав их на «чисто си» плюс современные компиляторы плюс понимаю вопросов более или менее оптимизации (причём последнее даже вряд ли понадобится) при этом в производительности они как минимум не потеряют как максимум наоборот.

Другое дело что когда-то это могло быть актуальным и это «когда-то» было даже «относительно недавно» может быть всего лишь в конце прошлого века ))

и увольнение наиболее активных сотрудников.

Здесь вопрос интересный и на уровне корпораций таки сложный. Проблема в том что им нужны +100500 сотрудников и им чисто технически неоткуда взять «равнозначное количество активных» либо это будет стоить слишком дорого потому их приходится а) заменять на 100500 «неактивных» б) придумывать методы административные по управлению этими 100500 и их «неактивным» кодов в) при этом явно отказываться от найма таки «активных» просто потому что они а) будут прямо мешать «неактивным» б) будут морально неэффективны в услових «+100500 неактивных».

Но вообще там часть их всё равно будет просто либо «временных экспертов» либо «единичных экспертов» при этом так или иначе «не касающихся неактивных и их кода».

Т.е. сталася жопа пришли посмотрели экспертное мнение выдали жопу поправили +$100500 забрали и ушли далее 100500 «неактивных» продолжают «кодить и пр.» как и ранее.

В целом следует признать это работает.

ЗЫ: кстати именно поэтому корпорациям выгоднее покупать чужие «готовые продукты с командами и экспертизой» чем «выращивать свои».

У нас на C++ проекте эффективно работает и коде-стайл, и ревью; коде стайл содержит все рекомендации из приведенной статьи кроме двойного разыменования.
Ваш ответ, в частности, предполагает, что «наиболее активные сотрудники» — это те, которые неуправляемы сверху и уверены только в своем правильном коде :) Тада да, строптивые и непризнанные еще гении редко где и как приходятся ко двору. Щодо ціни — снижаются денежные и временные затраты на тестирование и отладку.

У нас на C++ проекте эффективно работает и коде-стайл, и ревью; коде стайл содержит все рекомендации из приведенной статьи кроме двойного разыменования.

Вот это уже интересно. Приведу те самые рекомендации, с расшифровкой:
1) Не использовать динамическое распределение памяти после инициализации. — У Вас на С++ проекте не используются new/delete (прощай C+±style наследование и полиморфизм, а также STL). Возможны только объекты фиксированной длины (прощай строки, привет буфера). Вероятно переполнение буферов, так как нет аллокатора памяти (привет отказы при повышении нагрузки). Прощай половина design patterns так как в них наследование и динамическое создание/удаление объектов.
2) Использование указателей должно быть ограничено. Допустимо не больше одного уровня разыменования. Операторы разыменования не должны быть скрыты в макро определениях или внутри typedef. Указатели на функции запрещены. — Прощай C-style интерфейсы и полиморфизм (благодаря которым живет ядро Линукса и старый софт).
Из того, что я видел, указатели на функции использовались даже в радиотелефонах 90-х на DSP с 2 (или 4) киловордами RAM. Интересно, что Ваша контора может без них написать на С++.

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

Про тот пункт который у Вас № 2, а в статье № 9, я написал вышее: «кроме двойного разыменования». Сори, имелся в виду весь пункт целиком.

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

Я думаю, применительно к плюсам, речь идет о том, что память имеет смысл выделять либо на инициализации обЪекта (убивать — когда не нужна и проверять на финализации), либо пользоваться только смарт-пойнтерами. Для сишки, допустим, было в этом смысле актуальным распределять память на старте одним большим куском.
А STL — это неизбежное и необходимое зло :) ибо во всем этом есть еще ключевое слово — «рекомендации». Т.е. предполагается, что девелопер не только активный , но и думающий :). Дапустим из родственного, не рекомендуется lazy initialization. Но если очень надо и иначе — только через вставление костылей в код, то можна.

Вопрос в цене: замедление проекта

Замедления не будет, ибо сильно сократятся сроки отладки.

Мне нравятся эти административные меры

Ну, по опыту, после 1 мес на проекте, где не принято пушить, если комит не прошел все валидити и финд бага, привыкаешь, и уже даже в сайд проджекте САМ запускаю и чекаю

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

конечно, как можно написать фичу, следуя всем принципам SOLID, если архитектуры проекта, как таковой, нет в принципе?

Насколько я знаю то это никто не оплачивает

Есть такое понятие как развитие. Стремление делать свою работу с каждым разом более и более качественно, не зависимо от того платят за это или нет. Ну и когда человек достигает определённого уровня, происходит либо повышение ЗП, либо смена места работы. Но не как самоцель, а как результат роста специалиста...
Т.е. то место где находится человек (в основном, но не всегда) отражает его уровень компетенции и уровень заработка ИМХО.
Поэтому если Вам никто не платит за то, что бы Вы писали качественный код, то возможно Вы находетесь не в том месте ? И вопрос почему Вы не находетесь в том месте где приветсвуется развитие ?

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

Это вредит бизнесу так как увеличивает сроки разработки фич. Жизнь в том, что пока контора А сделает фичу качественно, контора Б сделает 2 фичи быстро, и отберет у конторы А сегмент рынка.

Это вредит бизнесу так как увеличивает сроки разработки фич. Жизнь в том, что пока контора А сделает фичу качественно, контора Б сделает 2 фичи быстро, и отберет у конторы А сегмент рынка.

только спустя 2 года добавление фичи в код конторы А будет стоить на порядок дешевле и быстрее, нежели той же фичи в код конторы Б

Контора А эти 2 года не протянет

Контора А эти 2 года не протянет

А конторе Б заказчик через 2 года будет предъявлять претензии мол почему так дорого обходится саппорт :)
Но это его было решение, на начальном этапе...

Но это его было решение, на начальном этапе...

Вот! Вы много знаете людей, которые признают, что обосрались из-за своей жадности?

Вот! Вы много знаете людей, которые признают, что обосрались из-за своей жадности?

нет, но это не отменяет причин, почему проект скатился в говно...

Когда наберут достаточно денег от заказчиков — отрефакторят по кускам. Рефакторить проще, если есть деньги, чем если их нет)

Когда наберут достаточно денег от заказчиков — отрефакторят по кускам.

Отрефакторить иногда сложнее, чем переписать с нуля

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

Непопулярная истина: ещё со времён ассемблера код пишется не для компьютера. Код пишется для людей. Программирование — гуманитарная наука, состоящая на 100% из чьей-то отсебятины, где-то-то решил как будет правильно.

ИЧСХ, чем дальше от мейнстрима, тем логики в коде меньше. Но весь дебилизм, накопленный «ещё до того, как стало модным» — увы, сохраняется на весь жизненный цикл. Как, скажем, отсутствие в JavaScript нативного ООП. Хотя казалось бы, всё давно изучено и переизучено, возьми и добавь, спрос есть. На том же PHP откатали симбиоз ООП и ХЗП (от которого оно пошло), и пашет, и даже оптимизировать сумели.

Программирование — гуманитарная наука

медицина — найгуманітарніша з наук. ви почерк лікарів бачили?

Люди це здатні прочитати? То не наука, то релігія!

Дуже розповсюджений міф. Насправді вони з легкістю продадуть вам зовсім інший препарат.

Головне шо допоможе. Інкапсуляція ж!

Заміна одного фуфломіцину іншим ролі не відіграє. Так само якщо взагалі не знають що за препарат, тупо пхають фуфломіцин, гірше не зробить.

На жаль із кодом така хєрня не проканає.

На жаль із кодом така хєрня не проканає.

Звісно не проканає. От є код з набором багів А, а ти його перетворюєш на код з набором багів «А з чертою»

в нормальных странах рецепты уже давно электронные

Забрав в архіві свою дитячу медичну картку. Виявилася дивовижна річ — в 1982-1983 році в карті не робили записи, а друкували на машинці і вклеювали (!!!). Далі, щоправда, все від руки, і зрозуміти мало що можна.

Программирование — гуманитарная наука

Она не гуманитарная, она не точная, как математика. Математические аспекты можно доказать, их правоту или неправоту. Доказать правильность кода невозможно. Можно доказать его «неправильность», неработоспособность. Но доказать, что он работоспособен — нельзя. Из-за этого можно написать говнокод и сказать, что это шедевр.

Это ты ещё не доказывал что код неработоспособен. Особенно весело когда саппорт украинский. Впрочем, даже они отдыхают по сравнению с саппортом Дропбокса. Но саппорт ПейПэла это вообще сказка — сообщил им про баг, так они только через ШЕСТЬ ЛЕТ закрыли дырку. До того мне месяц доказывали, что это не баг, это фича. Притом баг элементарный, закрываемый в 1 строчку на открытой части кода.

Короче, точно тут кот наплакал. И даже когда в него углубишься, найдёшь там тонны гуманитарки. Потому что для работоспособности кода мало читать документацию как работает (она кстати тоже гуманитарка), хорошо если она ещё есть. А ещё приходится читать исходники. Хорошо когда они с комментами, хорошо когда не на китайском. Особо весело когда у тебя код потом не компилится, потому что переменная на китайском :)

В общем над маааленькой частью точной науки лежит слоёв 8 гуманитарки. Хуже всего то, что те кто думает что знают — знают только верхний слой. Когда им начинаешь рассказывать что 2+2=4 уже в коде, смотрят как на врага народа, «не знающего» единственно верного синтаксического сахара, который уже успел устареть.

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

Точно так же сложно объяснять людям с высшим образованием, что констант не существует. Что исключения пишутся не просто так. Что не существует универсального equals. Или что «слабые ссылки» — ущербная ветвь эволюции.

Да что уж говорить, элементарный пример вызывает дискуссии по поводу работы кода (на JS).

var universeKiller = 0;
if(universeKiller!=0 && 1/universeKiller>0) console.error("Шрёдингер, киса сдохла!");
console.info(" - Мяу!");
Разумеется, сработает так, как и должно сработать. Но попробуйте рассказать это тем, кто собеседования проводит. Как и то, что код нужно писать именно в таком стиле (линейном) чтобы он был быстро читаемым. Особенно когда кода много, и читать вероятно придётся джунам.
Простой пример: чем абстрактный класс от интерфейса отличается? Правильный ответ — все отличия у вас в голове.

Не ну абстрактный класс может содердать код.... А интерфейс не может. Ну и там в зависимости от языка например другой класс может реализовывать несколько интерфейсов, но наследоваться строго от одного класса. Т.е. отличия есть и вполне ощутимые ИМХО.

Точно так же сложно объяснять людям с высшим образованием, что констант не существует.

Как это не существует ?

const double Pi = 3.14159; // This is Pi constant

Понятно что в микрухе их нет, там просто тригера, но с точки зерния языка и его синтаксиса они есть, и будет ошибка компиляции, если в коде будет попытка перезаписать значение. Ну и как бы если оставаться на этом уровне абстракции, то всё ок. Создавай себе константы и используй.

P.S. Но если смотреть на уровне байткода JavaVM, то да, насколько я знаю, что интерфейсты, что абкстрактные классы транслируются в одинковый байт код. Но на уровне компилятора не позволено интерфейсу иметь имплементации методов.
Но в C# дела обстоят по другому. Интерфес транслируется в стркутуру (на IL), которая не может содержать переменных, поэтому даже используя хаки на уровне IL, не получится из интерфейса сделать абстрактный класс.

Да у тебя и абстрактный класс не должно получиться создать. Ты не можешь создать экземпляра ни абстрактного класса, ни интерфейса. С точки зрения человека, абстрактный класс и интерфейс практически одинаковые сущности, с той лишь разницей для ассоциативной памяти, что абстрактный класс — это КЛАСС, в котором часть работы упрощена, а интерфейс это КЛАСС, в котором ничего не сделано, то бишь пустой.

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

Пример нативного языка: слово xy йня. Это абстракный класс, или конкретный, или интерфейс? Правильный ответ: у мозга нет ООП, это одно и то же. Мозг не создаёт конкретных шаблонов, всё есть абстракция. И точно так же при написании грамотного кода, абстрактные сущности нужно создавать ТОЛЬКО ЕСЛИ они соответствуют понимаемому мозгом шаблону. И нельзя, если такого шаблона не существует. Потому что человек не сможет оперировать этой неведомой xнёй, особенно когда такого счастья сотни и сотни, особенно если раскиданы по разным файлам.

Именно. Отличия заканчиваются на гуманитарном уровне. На уровне прикладного программирования они уже стираются. На уровне отладки, и соответственно на уровне исполнения — их уже практически нет, если мы не говорим о системном программировании.

Я о том и говорю, что программирование — гуманитарная наука. Слишком большое количество кода написано ну оооочень неоптимально, и только потому не оптимизируется, что так потеряется контроль человеком. А потеря контроля = непойманные ошибки. И чем цена ошибки выше (а время — это деньги), тем больше слоёв абстракции.

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

Простой пример: регулярные выражения. Это эпической красоты геморой, способный довести до белого коления любого тестировщика. Если быть точным, они вообще не тестируемы в полном объёме, и нечитаемы в общем виде. Их правила настолько быстро забываются, что ошибки делают не только лишь все. Чего стоит один маленький факт: за всю историю человечества не создано ровно ни одного конструктора регулярных выражений, который бы мог без ошибок создать regex для человека, ничего не понимающего в его синтаксисе. НИ ОДНОГО.

Тем не менее, что делают кодеры, когда параметризируют софт? Правильно — выводят в параметр его величество regex. Акцентирую внимание, софт не для программиста, скорее для админа, притом уровня студента и ниже. И вот он должен разбираться, как там экранировать кракозяблы. Будут ли там ошибки? К гадалке не ходи! И разумеется, тестировщика под руками у него нет.

Так что пусть лучше железо выполнит 100 000 лишних телодвижений, чем пользователь одно. И каждый программист, находящийся на стороне пользователя — гуманитарий. А остальных надо гнать поганой метлой ото всюду, где софт может соприкасаться с людьми (это 99+% софта). Даже под embedded софт надо писать по-человечески!

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

 вы свой код полугодичной давно попробуйте без комментариев попробуйте прочесть))))))

Честно, после определённых мероприятий, стал писать код намного лучше чем до. Да, иногда смотришь через год и понимаешь что можно было сделать лучше, но явного кала стало намного меньше.
Список мероприятий:

  • Прочтение книги Боба Мартина «Чистый Код» и освоение предлогаемых им практик
  • Освоение и доведение до автоматизма таких подходов как: SOLID, KISS, ...
  • Прохождение хорошего тренинга по патернам проектирования
  • Годы опыты

Ссылочку на тренинг можно?

Я несколько лет назад работал в одной из IT компаний и там руководство договорилось с одной тренинговой компанией (XP Injection если я не ошибаюсь), что бы они пришли к нам в офис и провели двух дневный тренинг по различным методологиям и паттернам проектирования.
Компания называется: XP Injection
Тренера зовут: Евгений Борисов (bsevgeny@gmail.com)
Но вот ссылочки к сожалению нет :)
Но тренинг мне понравился и дал положительный результат ИМХО.

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

Ну тот тренинг был не только про SOLID. Там были затронуты многие важные темы:

  • SOLID
  • KISS
  • Паттерны проектирования (а их не мало)
  • Разбирались фейлы, проблемные места, которые приводят к размножению багов и т.д.
Т.е. это был честный двух дневный тренинг с практикой.

И что, работает? А то у нас по старинке, за яйца колёными щипцами. Тоже работает.

Я свой читаю через 3-4 года без особых проблем. И даже чужой, если он нормально разбит на слои и следует принципам SOLID

Возможно, не попадались алгоритмические или сильно асинхронные задачи.

главное в таких случаях — разобраться с «ядром», абстрагируясь от реализаций.

Особенно, когда «ядро» — сыроватый (спагетти) стандарт на сотни страниц, или десяток стандартов, дополняющих друг друга.

тогда в принципе это красиво не реализуемо и качество кода уже не при чём

Почему, реализуемо, когда хорошо понимаешь предметную область и все реальные interoperability issues. Вот только понимание приходит с практикой, а практика — от проблем пользователей в продакшне.
Ну и еще, можно попытаться сразу поддержать последний навороченный стандарт, но на это надо много времени, и не факт, что заказчик/начальство дождется. Или можно быстро сделать рабочий прототип, и потом его апгрейдить новыми стандартами, но это гарантирует legacy code через год-два.

Запомните, лучшее враг хорошего, работает не трож. Просто набератейте в команду нормальных разработчиков и будет вам счастье. И да еще такой момент, на рынке аутсорса результат не важен, важно на сколько много гребец тратит время на работу (ибо галера получает не за результат а за жопа часы), и от сюда все вытекающие последствия, 23 летнии сеньоры, и 25 летнии солюшин архитекторы и говно код на всех уровнях архитектуры.

Запомните, лучшее враг хорошего,

Здесь ключевое слово ИМХО: «хорошего» :)

Запомните, лучшее враг хорошего, работает не трож.

что значит «работает — не трожь». ПО — это не статическая вещь, оно постоянно меняется

Когда вы сделает остальное ...,

Make It Good, Make It Fast.

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

какой ответ пришлет программист, который будет разбираться в вашем коде

Хороший код — 0%
Плохой код — 0%
Всё переписать! — 100%

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

Разработка итеративна. Тот, кто пишет первую итерацию системы/модуля, не знает изначально всех требований и граблей. В результате со временем модули обрастают костылями. Если *этому же* человеку дать написать вторую версию — вероятно, она будет значительно лучше и чище, с учетом предыдущего опыта инкостыляции. Если дать писать новому человеку — оно будет другое, вероятно — архитектурно проще (с учетом формы спагетти предыдущего кода), но часть костылей не заметят и поведение будет отличаться. И тут можете надеяться, что у Вас 100% покрытие тестами разных уровней)

Если *этому же* человеку дать написать вторую версию — вероятно, она будет значительно лучше и чище, с учетом предыдущего опыта инкостыляции.

это, по моему опыту, и есть непродуманность архитектуры с самого начала :)

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

Everything should be made as simple as possible, but no simpler. Также, All problems in computer science can be solved by another level of indirection. Если вначале не заложить этой гибкости, нужно будет переписывать весь код одновременно.

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

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

Да уж, всякое бывает. Бывают условия, когда действительно от тебя не много зависит. Но я думаю в сложных ситуациях нужно пробовать объяснять руководству о том, что луше сделать хорошо, а то в будущем будут несоизмеримые затраты на поддержку, как говорится попытка не пытка.

Возможно, у кого-то из людей была далеко не работа в голове, а мысли об умершем накануне родственнике.

Ну так зачем садиться работать в таком состоянии ? Может лучше отдохнуть, прежить сложную ситуацию и потом на свежую голову садиться работать ?

Не судите людей.

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

Из того, что я вижу, абсолютное большинство старается делать свою работу хорошо. Другое дело, что не всегда удаётся в силу личных качеств и обстоятельств.

И Вы много видите ? +/- 10 человек Вашей комманды ?

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

Конечно, вы правы. Я имел в виду, что это уже испробовано и не увенчалось успехом, дедлайн сместить не удалось.

Может лучше отдохнуть, прежить сложную ситуацию и потом на свежую голову садиться работать ?

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

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

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

И Вы много видите ? +/- 10 человек Вашей комманды ?

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

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

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

Если вокруг вас таких много — возможно у вас не всё хорошо в компании / команде с культурой отношения к работе.

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

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

Не. Намного более вероятно что они просто были говнокодерами.

Подписаться на комментарии