Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Программирование Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
dbpatch
Member

Откуда:
Сообщений: 1082
как известно, существуют Style guide для кода, сколько там пробелов отступать и как скобки ставить.
с этим понятно и вопросов нет

но какие есть на просторах интернетов примеры гайдов к требованию написанию уже самого ПО?

к примеру, если мы пишем некие консольные приложения, демоны и утилиты:

а) приложения, бросающие ошибки - должны в обязательном порядке говорить о контексте, на котором они упали -
если обрабатывался файл, то нужно указать имя файла, номер строки и колонки,
если обрабатывалась таблица в базе данных - то показать имя таблицы, значение PK или rowid
б) обработка параметров командной строки, когда и как использовать два -, когда --, --usage, --help
в) писать все ошибки в stderr, а не в stdout, не писать в stderr, если демонизированы, писать в syslog
г) не требовать явного пользовательского ввода с клавиатуры

ну и т.п.

т.е. что-то вроде https://www.gnu.org/prep/standards/standards.html

но поглобальнее?
11 дек 17, 16:36    [21024656]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
hVostt
Member

Откуда:
Сообщений: 12205
dbpatch,

для начала общие принципы, SOLID, юнит-тесты. потом вырабатываете свои правила под конкретные кейсы. нет смысла тащить всё и колупать мозг пациентам. зачем?
11 дек 17, 16:56    [21024733]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
mayton
Member

Откуда: loopback
Сообщений: 35893
Правила... это пожалуй слишком строгая форулировка. По каждому пункту - it depends.
12 дек 17, 00:18    [21025588]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 2540
dbpatch,

для функциональности есть шаблоны проектирования
14 дек 17, 08:07    [21032521]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
dbpatch
Member

Откуда:
Сообщений: 1082
kealon(Ruslan)
dbpatch,

для функциональности есть шаблоны проектирования

блин, ну что за ерунда? я же показал пример (см. выше ссылку) руководства,

нужны - такие-же, только более развернутые.

а ты что привел? давай еще ссылку на K&R, на .NET Reference или и вовсе - на букварь и на арифметику для 3-го класса школы, нет ну почему нет?

интересуют имена собственные. вот тут, к примеру, чувак описывает - как физически огранизовывать код - группы пакетов, пакеты, компоненты
https://github.com/bloomberg/bde/wiki/physical-code-organization
https://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

вот тут - описывается типовая веб страница, правила организации оной
http://webstyleguide.com/wsg3/6-page-structure/3-site-design.html

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

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

не?
14 дек 17, 13:42    [21033545]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 44082
dbpatch
не?

Не. Есть просто некоторые традиции и понимание, что люди плохо обучаемы и потому следование этим традициям ускоряет процесс их привыкания к твоей софтине.
14 дек 17, 15:04    [21033893]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
kealon(Ruslan)
Member

Откуда: Нижневартовск
Сообщений: 2540
dbpatch
без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть
ну а там разве не так? кода там нет, просто схемы организации

Я бы посоветовал не париться со всякой фигнёй, везде по разному, пишите по ходу того что вас раздражать будет.
Как правило от правил, на высоких уровнях, больше вреда чем пользы.
14 дек 17, 17:30    [21034523]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
hVostt
Member

Откуда:
Сообщений: 12205
dbpatch
аналогичные руководства есть по всем аспектам - от логгинга до правил написания распределенных приложений.

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

не?


У нас постоянно такой гайд формируется, для каждого проекта свой. Очень сильно зависит от специфики, от уровня команды, на каждом уровне свой гайд: у дизайнеров свой, у верстальщиков свой, у прикладных разработчиков свой, у аналитиков свой, у фреймворк разработчиков свой. И ещё они разные от проекта к проекту. Ведётся вики, Howto, внутренний faq, теги, слак, всякое.

Унылый 500 страничный документ -- кому он нафиг упал? Ищете как ещё можно усложнить жизнь коллегам?
14 дек 17, 21:44    [21035108]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
hVostt
Member

Откуда:
Сообщений: 12205
dbpatch
без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть


Такие вопросы. Как часто должен средний разработчик обращаться к этим общим функциональным требованиям? Должен ли он помнить всё? Или как? Каким образом это должно контролироваться? Какие есть средства? Раз в неделю инспекция? Каждый день? Кто самый образованный следит за всем?

И где тут автоматизация?
14 дек 17, 21:45    [21035112]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
mayton
Member

Откуда: loopback
Сообщений: 35893
dbpatch
а) приложения, бросающие ошибки - должны в обязательном порядке говорить о контексте, на котором они упали -
если обрабатывался файл, то нужно указать имя файла, номер строки и колонки,
если обрабатывалась таблица в базе данных - то показать имя таблицы, значение PK или rowid

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

По поводу таблиц и колонок и значений. Есть огромное количество классических "толстых" клиентов
которые никогда ничего подобного не выводят. Фактически - они - контрпример.

б) обработка параметров командной строки, когда и как использовать два -, когда --, --usage, --help

Если взять Unix-утилиты командной строки то там можно заметить игнорирование этих правил.

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

Здесь - непонятно. Если "не требовать" - это означает предлагать альтернативу. А какая альтернатива?
Вы - знаете?
15 дек 17, 02:02    [21035488]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
antares0
Member

Откуда:
Сообщений: 246
mayton,
Не альтератива а равнофигизм. Юниксовые утилиты должны читать данные с потока стандартного ввода. А стоит за ним реальный терминал с живым пользователем или конвеерный вывод другой утилиты не долнжно влять на логику работы.
15 дек 17, 09:20    [21035727]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
dbpatch
Member

Откуда:
Сообщений: 1082
hVostt
dbpatch
без привязки к каким-то библиотекам и коду - а именно требования функциональные - вот у вас такое должно быть


Такие вопросы. Как часто должен средний разработчик обращаться к этим общим функциональным требованиям? Должен ли он помнить всё? Или как? Каким образом это должно контролироваться? Какие есть средства? Раз в неделю инспекция? Каждый день? Кто самый образованный следит за всем?

И где тут автоматизация?


каждый день,
должен,
только так.
нормоконтроль - code review и прочее.
частично - статический анализатор кода, но в основном человеки
нет, не раз в неделю, на каждый commit/pull request/merge, хотя то, о чем я говорю - это вообще из ТЗ и архитектуры
team lead следит

какая еще автоматизация? CI никто не отменял
15 дек 17, 13:24    [21036687]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
dbpatch
Member

Откуда:
Сообщений: 1082
antares0
mayton,
Не альтератива а равнофигизм. Юниксовые утилиты должны читать данные с потока стандартного ввода. А стоит за ним реальный терминал с живым пользователем или конвеерный вывод другой утилиты не долнжно влять на логику работы.


я имел в виду - что утилита не должна быть интерактивна, задавать всякие вопросы вида y/n/cancel и прочее.
да, пережевать поток ввода stdin - это не совсем пользовательский ввод, это просто соглашение - что любая последовательность байт будет так или иначе обработана, по EOF. вызывающий понимает, что он передает последовательность байт. и что обрабатывающий может ее или принять или нет - упасть и бросить ошибку.

а вот если приложение внезапно спрашивает y/n - то вызывающая сторона может об этом и не догадаться и повиснуть намертво и т.п.
15 дек 17, 13:29    [21036712]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
dbpatch
Member

Откуда:
Сообщений: 1082
mayton
dbpatch
а) приложения, бросающие ошибки - должны в обязательном порядке говорить о контексте, на котором они упали -
если обрабатывался файл, то нужно указать имя файла, номер строки и колонки,
если обрабатывалась таблица в базе данных - то показать имя таблицы, значение PK или rowid

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

По поводу таблиц и колонок и значений. Есть огромное количество классических "толстых" клиентов
которые никогда ничего подобного не выводят. Фактически - они - контрпример.


конкретно возник вопрос по существу - есть логгинг, отлично, при этом разработчики как хотят, так и пишут туда.
кто-то в info, кто-то в debug, кто-то в warn

форматы самые дикие и разнообразные. и почти никто - не пишет контекст - где там возникла та или иная ошибка, классика жанра - плюнуть в лог нечто вида invalid value detected: <value> и.... все, больше ничего.

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

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

не надо рассказывать, что там в каждом проекте все свое невероятно уникальное - в 99% случаев это одна и та-же переработка входящего потока в исходящий с сохранением всякого в базу данных
15 дек 17, 13:33    [21036722]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 7737
dbpatch
не надо рассказывать, что там в каждом проекте все свое невероятно уникальное
Я вам один умный вещь скажу - вы только не обижайтесь: именно так и есть.
Никто не станет тратить месяцы жизни там, где достаточно "осмотреться по сторонам", чтобы понять "как здесь принято".
15 дек 17, 13:44    [21036773]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
dbpatch
Member

Откуда:
Сообщений: 1082
Basil A. Sidorov
dbpatch
не надо рассказывать, что там в каждом проекте все свое невероятно уникальное
Я вам один умный вещь скажу - вы только не обижайтесь: именно так и есть.
Никто не станет тратить месяцы жизни там, где достаточно "осмотреться по сторонам", чтобы понять "как здесь принято".


И? где открытие? Я вон привел пример того, что в большинстве мест в принципе не принято правильно оформлять логгирвание.

И наверное стоит посмотреть хоть куда-то, чтоб увидеть, как на самом деле принято делать в хороших проектах.
Потому я и спрашиваю - где есть рафинированные правильные проекты и правила.

Смотреть по сторонам на типовой местячковый бардак - никакого смысла вообще нет, это все равно что современную архитектуру изучать по самодельным "пенокурятникам лкуса" и прочие гениальные дачные постройки в округе. Что они могут рассказать?
15 дек 17, 14:25    [21036934]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
Basil A. Sidorov
Member

Откуда:
Сообщений: 7737
dbpatch
Я вон привел пример того, что в большинстве мест в принципе не принято правильно оформлять логгирвание.
Протоколирование вообще отдельная и достаточно сложная задача, которую, как правило, не закладывают в бюджет проекта.
Потому я и спрашиваю - где есть рафинированные правильные проекты и правила.
Люди отвечают вам - нигде. Везде свои "местечковые правила". Но вы упёрлись и хотите святого грааля.
15 дек 17, 14:51    [21037056]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
hVostt
Member

Откуда:
Сообщений: 12205
dbpatch
какая еще автоматизация? CI никто не отменял


программист, который не может автоматизировать СВОЮ РАБОТУ, не понимает что это такое и зачем это нужно -- очень странный программист. похоже, он выбрал не ту профессию, ему бы в бюрократию, бумаги писать.

это лирика. по делу, это TDD, линтеры, метрики кода, которые покрывают 80-90% мудотни, на которую не нужно тратить человеческое время. если же заказчик/работодатель готов оплачивать вот это ежедневное вычитывание тонны всяких гайдов, ручной code review по гайдам и задрачивание всех и вся этими гайдами, то ради бога. можно ещё ритуалы всякие внести, типа стучать в бубен после каждого коммита и проводить утренние песнопения по гайдам усопших.

я конечно ЗА порядок, качество, и всячески приветствую полезную организацию работы. но если доводить до фанатизма, не уметь автоматизировать эту работу, то я считаю, нафиг оно не упало ни в каком виде.
15 дек 17, 16:26    [21037501]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
hVostt
Member

Откуда:
Сообщений: 12205
Basil A. Sidorov
Но вы упёрлись и хотите святого грааля.


Может сложиться впечатление, что задача -- задрочить всех разработчиков какой-то мудотнёй, которую можно было бы автоматизировать, но нет..., чтобы они поувольнялись к чертям.
15 дек 17, 16:28    [21037507]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13574
dbpatch
форматы самые дикие и разнообразные. и почти никто - не пишет контекст - где там возникла та или иная ошибка, классика жанра - плюнуть в лог нечто вида invalid value detected: <value> и.... все, больше ничего.

где, кто что там detected - полный хз. какая сессия стрельнула, какой реквест, в какой функии упало, иди, догадайтся
К недавнему вопросу о нужности исключений, содержащих кроме всего прочего StackTrace места возникновения, логирование которых на системном уровне не составит труда.
15 дек 17, 21:17    [21038343]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
mayton
Member

Откуда: loopback
Сообщений: 35893
antares0
mayton,
Не альтератива а равнофигизм. Юниксовые утилиты должны читать данные с потока стандартного ввода. А стоит за ним реальный терминал с живым пользователем или конвеерный вывод другой утилиты не долнжно влять на логику работы.

Я имел в виду не STDIN а формат ключей или опций командной строки.
15 дек 17, 21:26    [21038356]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
mayton
Member

Откуда: loopback
Сообщений: 35893
dbpatch

конкретно возник вопрос по существу - есть логгинг, отлично, при этом разработчики как хотят, так и пишут туда.
кто-то в info, кто-то в debug, кто-то в warn

форматы самые дикие и разнообразные. и почти никто - не пишет контекст - где там возникла та или иная ошибка, классика жанра - плюнуть в лог нечто вида invalid value detected: <value> и.... все, больше ничего.

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

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

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

Порядка 15 лет я сопровождаю и разрабатываю ПО для серверного софта. Но до сих пор я озадачен теми-же
вопросами что и вы. Я не отвечу на ваши. Я скорее наоборот - подкину новых. И дам несколько своих взглядов.

По поводу логгинга.

Тема - бесконечная. И неунывающая. И я задам вопрос (1). Кто будет читать лог? Пользователь? Дев-опс?
Первая-вторая-линия поддержки? Сисадмин? Разработчик? Разработчику по большему счету лог не нужен.
В режиме debug он степает по коду и видит все и вся. А в некоторых приложениях (mobile/Android/iOS) пользователь никогда
логи не увидит да и не нужны они ему никогда.

Давайте поговорим про это.

Вопрос (2). Упровни логгирования.. Я думаю тут просто надо подумать о том что мы не только инженеры но еще
и чуть экономисты. Мы работаем в условиях ограниченных ресурсов (диск) и не можем трейсить и дебажить все-все
переменные стека/потока/глобального контекста. На придется искать золотую середину. Не лишним будет курнуть
API логгирования (log4c?) и посмотреть какие есть возможности и рекомендации по использованию.

Давайте поговорим про золотую середину в уровнях детализации.

Вопрос (3). Форматы.. Скорее всего их не существует. И каждый пишет как бох даст. Но я-бы предложил
предварять каждую запись лога TIMESTAMP-ом в позиционном формате. Тоесть чтобы старшие разряды времени
шли в первую очередь. Это (гипотетически) даст нам возможность греп-ать и сорт-ить файл лексическими
конструкциями в диапазоне времени. Форматы уровня. Месседжа и контекста - произвольны. Но я-бы предложил
разбить их по логгерам. При этом полагать что логгер - это некий агрегат для технологии. Например DAO/Contoller/UI e.t.c.
Не для каждого модуля (это мелко) а именно для технологии или некого подраздела приложения.

Давайте обсудим это.

Вопрос (4). Контекст. Тут опять-же вопрос экономии. Как много мы готовы отдать дискового пространства
для сброса контекста ошибки? Локал-переменные? Стектрейс? Memory-dump? Забегая вперед я реально встречал
веб-приложения которые имели узким местом процедуру дампа сведений об ошибке. Она не бесплатна. И при некоторых
условиях можно DDOS-ить приложение искусственными ошибочными ситуациями. Обработка исключения - небесплатна.
Есть и забавные ситуации экономии ресурсов CPU/Memory. Яркий пример - неудачная реализация CSV-парсера на регулярках потребляет в 1000% больше энергии на ошибочных строках которые не проходят валидацию. Фиксится редко. Как показывает мой личный опыт.

Давайте про контекст.

Вопрос (5). invalid value detected. Здесь по пункту 1 надо смотреть в того что будет читателем этого сообщения.
Но если взять метрику соотношение полезного кода к коду который форматирует ошибку то я-бы очень сильно
настаивал на некой разумной цифре. Правило Паретто? 80:20 ? Возможно. В противном случае мы рискуем поймать
сложно уловимую ошибку типа - "исключение в блоке обработки исключений". Я более чем уверен что присутствующие
здесь господа не всегда тестируют негативные кейсы в модульных тестах и не всегда гарантируют отсутствие этого
сценария. Вобщем - будьте кратки. Сложный код обработки ошибки порождает рекурсивную дилемму. А сколько вообще
кейсов ошибки может быть? Вот ради примера берите простейшее С++/DBMS оконное GRUD приложение с 1-й табличкой
и давайте рисовать все ситуации с БД. (БД недоступна, таблица в блокировках, транзакция не прошла по ошибке триггеров,
ошибка констрейнта, и много-много). Все state базы данных перечислить и решить как и что выводить в ответ на каждую
ситуацию. И если мы просто дампим стек - то мы съезжаем с этого вопроса и уходим в начало дискуссии о том для
кого это лог.

Обсудим комплексность самой детализации ошибки.

Вопрос (6). Безопасность.. Согласно Керхгофсу, кража исходного кода не должна причинять неудобств. Тоесть
мы должны исходить из самого пессимистичного сценария. Злоумышленник знает код. Он его видел. Он - бывший сотрудник.
И он обладает бесконечным временем и терпением для осуществления атаки на систему. Какие сведения он может получить
делая синтетические ошибки и получая фидбек на экран или еще каким-то образом. Если вам кажется что это пустяк
и этим не стоит заниматься то обратите внимание на программные продукты Veracode и библиотеки OWASP. Иногда
(я имею в виду ентрепрайз) вы не сможете выкатить новый релиз пока не войдете в зеленый сектор отчота Veracode
или Sonar или прочих статик анализаторов в части отчота по безопасности.

Давайте поговорим про безопасность логов и дампов.

Вопрос (7). Собственно цена доработки системы до человеческого уровня логгирования. Я-бы предложил
анализ метрик сложности кода "до" и "после". Человеческий code-review. И ожидаемый business-value.

И по каждому пункту - соотв принимать решение.
15 дек 17, 22:08    [21038414]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
mayton
Member

Откуда: loopback
Сообщений: 35893
dbpatch
в) писать все ошибки в stderr, а не в stdout, не писать в stderr, если демонизированы, писать в syslog

syslog на мой взгляд является ценным ресурсом ОС Linux и я-бы не стал в каждом приложении
его использовать. Нет ничего хуже чем прикладной флуд в системном логе.

Семантический вопрос разделения прикладного и системного я пока оставляю за кадром. Бох вам судья
если вы решили что ваш код системный. Тут важнее осознание значимости момента.
15 дек 17, 22:45    [21038457]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13574
mayton
Тема - бесконечная. И неунывающая. И я задам вопрос (1). Кто будет читать лог? Пользователь? Дев-опс?
Первая-вторая-линия поддержки? Сисадмин? Разработчик?
По цепочке. Если пользователь не смог интерпретировать ошибку, то он обращается в техподдержку. Если техподдержка не смогла, то она обращается к системному администратору. Если и он не смог, то идёт обращение к разработчику.

mayton
Разработчику по большему счету лог не нужен.
Наоборот! Ему он нужен больше всего! Это единственная объективная информация, оперируя которой можно понять, что произошло при промышленной эксплуатации программы.

mayton
В режиме debug он степает по коду и видит все и вся. А в некоторых приложениях (mobile/Android/iOS) пользователь никогда
логи не увидит да и не нужны они ему никогда.
И это зря, нужно лучше относиться к пользователям. :-) Я бы всегда давал пользователю возможность получить полную информацию об ошибке, а он уж сам решит, нужно ему её читать или нет.

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

Другое дело, что качество StackTrace зависит от качества именования методов. Есть вероятность, что при нормальном именовании методов StackTrace будет понятен не только разработчику, но и системному администратору, а может быть даже и техподдержке. :-)
16 дек 17, 09:05    [21038821]     Ответить | Цитировать Сообщить модератору
 Re: правила написания ПО, style guide, но не для форматирования кода, а для функциональности  [new]
skyANA
Member

Откуда: Зеленоград
Сообщений: 23081
dbpatch
Basil A. Sidorov
пропущено...
Я вам один умный вещь скажу - вы только не обижайтесь: именно так и есть.
Никто не станет тратить месяцы жизни там, где достаточно "осмотреться по сторонам", чтобы понять "как здесь принято".


И? где открытие? Я вон привел пример того, что в большинстве мест в принципе не принято правильно оформлять логгирвание.

И наверное стоит посмотреть хоть куда-то, чтоб увидеть, как на самом деле принято делать в хороших проектах.
Потому я и спрашиваю - где есть рафинированные правильные проекты и правила.

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

К примеру поищите доклады Анатолия Кулакова из SpbDotNet Community про структурное логирование и сбор метрика.
Покажите, расскажите коллегам.
16 дек 17, 10:07    [21038861]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Программирование Ответить