Jump to content
SpravkaCRM.ru - Ваш справочник по CRM

Search the Community

Showing results for tags 'требования'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Categories

  • Перевод официального мануала SuiteCRM
  • Обучающие статьи о SuiteCRM
    • Для программиста
  • Доводим напильником SuiteCRM
  • Расширения для SuiteCRM
    • Патчи с исправлениями ошибок в SuiteCRM
  • Программист за работой
  • Диалоги о SuiteCRM

Categories

  • Records
  • CRM-система для застройщика
    • Manual
  • CRM-система для кредитного брокера
  • CRM for Programmer
  • CRM-система для салонов красоты
    • Руководство

Forums

  • SugarCRM/SuiteCRM
    • Все вопросы пока сюда
    • Заметки по ходу разработки
    • Нам пишут
    • Работа
  • CRMHosting.io
    • SuiteCRM последней версии
    • CRM для продажи пиццы/суши/ролл
    • CRM для Застройщика
    • CRM для Кредитного брокера
    • CRM для Салонов красоты
  • Другие CRM-системы
    • AmoCRM
    • Bitrix24
    • BPM Online
    • Прочие CRM
  • Всего по немногу
    • Программисту
    • Arduino
    • Без систематики

Categories

  • Модули SuiteCRM/SuiteCRM
  • Manuals

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Found 1 result

  1. Все мы наверное сталкивались с проектами, в которых поучавствовало несколько разработчиков. Каждый разработчик привносил что то свое в проект, свой стиль написания кода, свои любимые приемы для реализации тех или иных задач. Из некоторых приёмов мы подчёрпывали что то новое с мыслями типа: Или такими: Но чем больше народу поучавствовало в проекте, тем больше хочется сказать: И не по тому, что отдельно взятые программисты плохи или хороши в своем деле (хотя и это тоже :-) ), а потому что все они пишут по разному! И когда очередной программист приходит на проект, он владеет информацией о исходном проекте SugarCRM/SuiteCRM, о том, как написан код разработчиками этой CRM. А вот стиль написания предыдущего программиста он не знает. Это делает код менее читабельным, а следовательно требует больше времени на его изучение и дальнейшую правку. Ну и в целом уменьшается комфортность сопровождения подобного проекта. По этому мы так и любим начинать проекты "с нуля": потому что там нет ЧУЖОГО НЕЧИТАБЕЛЬНОГО ГОВНОКОДА! Таким образом суть дальнейших инструкций: выработать у нашей команды единый стиль написания кода. Чтобы получив проект от своего коллеги вы не изучали разные уровни участия в нем других программистов по подобию колец на дереве. Чтобы все было для вас читабельным и максимально приближенным к комфортному сопровождению проекта. Дальнейшие инструкции выработаны на основании моего представления о внешнем виде кода, подкрепленного долгой практикой. Не являются конечной инстанцией. Предлагайте в комментариях свои варианты обосновав их. Итак: Комментарии Все мы знаем, что комментировать код надо. Его приятнее читать, когда ты можешь понять при помощи простого языка что же хотел тут сделать предыдущий программист. При должном уровне знания языка программирования конечно можно читать код, и сходу понимать что он делает. Но не всегда код является явным, названия переменных описывают их суть, а внезапные require_once вообще вносят некоторую сумятицу. Конечно не надо при этом делать из кода произведение и писать сочения для каждой строки кода. Но основные позиции по комментированию я укажу: Старайтесь комментировать любой логический блок! Описывайте в целом суть внутри дальнейших инструкций: /** * Получить PDF-версию протокола * @return mPDF */ public function getProtocolPDF() { // Проверяем версию Комитета if((int)date("Ymd", strtotime($this->fact_date)) < 20160601) { // Версия протокола до 1 июня 2016 года $pdf = $this->getProtocolPDFBefore20160601(); } return $pdf; } Всегда вносите описание для функций: должно быть в целом описание функции, перечисление и описание всех входных параметров и описание типа возвращаемых функцией данных: /** * Тут краткое описание функции, для чего она нужна * @param $var1 * @param $var2 * @param string $var3 * @return array */ public function testFunction($var1, $var2, $var3 = '') { // Тут тело функции $return_array = array(); // .... return $return_array; } Тоже самое касается в обязательном порядке и JavaScript-кода: /** * Тут краткое описание функции, для чего она нужна * @param var1 * @returns {*} */ function testFunction(var1) { // Тут тело функции var i; // .... return i; } В редакторе, в котором я пользуюсь для написания проектов (PHPStorm, возможно в других редакторах типа NetBeans тоже есть), есть удобная вещь для упрощения внесения описания для функций: если прям над функцией набрать /** и нажать на энтер, то весь код описания переменных и возвращаемого функцией значения сгенерится автоматически, и вам останется лишь дописать словами описание что же делает данная функция! Вот такой удобный лайфхак! Комментарии в SQL-запросах. Да да. Встречаются редко. Почти не встречаются. Но все мы знаем как выглядят названия таблиц и полей в них для связей. Особенно связей созданных новых модулей, где не какой-нибудь `account_id`, а куча полей типа `am_tasktemplates_am_projecttemplatesam_projecttemplates_ida`. А если еще модули и с длинными названиями ... Как правило комментарии в SQL-запросах применяются, когда весь SQL-запрос формируется в одном блоке кода, а не "размазан" по коду и собирается из кирпичиков. Удобно пользоваться комментариями именно на этапе написания кода. В итоговом сгенерированном SQL-запросе комментарии уже особо не нужны. Комментировать необходимо логические блоки подключения разных таблиц через INNER/LEFT JOIN, а также не явные условия в WHERE: // Получаем список активных Проектов с активными Сделками + их Контрагент // В проектах должны быть Проектные задачи, назначенные на текущего пользователя // И ряд условий $sql = " SELECT DISTINCT `accounts`.`id` AS `account_id`, `accounts`.`name` AS `account_name`, `opportunities`.`id` AS `opportunity_id`, `opportunities`.`name` AS `opportunity_name`, `opportunities`.`name` AS `opportunity_name`, `opportunities`.`conditions` AS `opportunity_conditions`, `opportunities`.`working_sheme`, `opportunities`.`jobprice_scope_of_work`, `opportunities`.`jobprice_monthly_requirement_type`, `opportunities`.`jobprice_monthly_requirement_hours`, `opportunities`.`jobprice_single_max_hours`, `opportunities`.`hourly_money_in_month`, `opportunities`.`hourly_scope_of_work`, `opportunities`.`hourly_hours_in_day`, `opportunities`.`hourly_cost`, `opportunities`.`hourly_single_max_hours`, `project`.`id` AS `project_id`, `project`.`name` AS `project_name`, `project`.`estimated_start_date` AS `project_start`, `project`.`estimated_end_date` AS `project_end`, `project`.`assigned_user_id` AS `project_assigned_user_id` FROM `project` # Подключаем Сделку INNER JOIN `projects_opportunities` ON `projects_opportunities`.`project_id` = `project`.`id` AND `projects_opportunities`.`deleted` = 0 INNER JOIN `opportunities` ON `opportunities`.`id` = `projects_opportunities`.`opportunity_id` AND `opportunities`.`status` = 'Active' AND `opportunities`.`deleted` = 0 # Подключаем Контрагента INNER JOIN `projects_accounts` ON `projects_accounts`.`project_id` = `project`.`id` AND `projects_accounts`.`deleted` = 0 INNER JOIN `accounts` ON `accounts`.`id` = `projects_accounts`.`account_id` AND `accounts`.`deleted` = 0 # Подключаем задачу INNER JOIN `project_task` ON `project_task`.`project_id` = `project`.`id` AND `project_task`.`deleted` = 0 AND `project_task`.`assigned_user_id` = '{$row_user['id']}' WHERE `project`.`deleted` = 0 # Нужны только Проекты с активным статусом AND `project`.`status` = 'Active' ORDER BY `opportunities`.`priority_number`, `project`.`estimated_start_date` "; Комментарии в Smarty-шаблонах считаю не обязательными, хотя и будут приятным дополнением: <span style="position: relative; top: 3px;"> {if $user.app.curentAction} {* Значек статуса задачи *} {if $user.app.curentAction.action == 'startTask'} {* В работе *} <span style="position: relative; top: -3px;"> <span class="label label-sm arrowed-right label-success" style="top: 1px;"> <span style="position:relative;top: 1px;">В процессе</span></span> </span> {elseif $user.app.curentAction.action == 'pauseTask'} {* На паузе *} <span style="position: relative; top: -3px;"> <span class="label label-sm arrowed-right" style="top: 1px;"> <span style="position:relative;top: 1px;">Приостановлено</span></span> </span> {/if} {if $user.app.curentAction.trelloURL} {* Ссылка на карту Trello *} <a href="{$user.app.curentAction.trelloURL}" target="_blank"><i class="fa fa-trello"></i></a> {/if} &quot;<A href="index.php?module=ProjectTask&action=DetailView&record={$user.app.curentAction.id}" target="_blank">{$user.app.curentAction.name}</A>&quot; <small>для</small> &quot;{$user.app.curentAction.accountName}&quot; <small>делает</small> {$user.app.curentAction.taskDuration} {if $user.app.curentAction.estimated_effort} <small>при расчетной длительности</small> {$user.app.curentAction.estimated_effort} {/if} {else} <span class="red">Задача не найдена</span> {/if} </span> SQL Запросы к базе данных так же необходимо оформлять таким образом, чтобы можно было их легко читать. Структура и перечень таблиц стандартных модулей как правило разработчикам более менее знакома. А вот привнесенные модули с их таблицами и полями как правило не известны другому программисту. И увеличение читабельности SQL-запросов позволит уменьшить барьер непонимания логики запроса. Да и читать подобные запросы намного приятнее: Самое первое и ОБЯЗАТЕЛЬНОЕ правило: обрамляйте ВСЕГДА названия таблиц и полей в обратные апострафы "`"! Это позволяет не только увеличить читабельность запроса, но и избежать ошибок SQL-синтаксиса да и в целом повышает отказоустойчивость кода. Используйте отступы для описания структуры SQL-запроса. При помощи кнопки Tab это легко делается, а IDE сама подстроится под нужный уровень вложенности когда после очередной строки вы нажмете Enter. Любая строка, относящаяся к той или иной SQL-конструкции, должна быть на один уровень глубже этой конструкции. Тоже самое касается сложных логических кострукций в WHERE, где при помощи скобок и AND или OR формируются сложные запросы: выделяйте внутренние скобки углубляя их: SELECT `nra_certificates`.`rate_lang_type`, `nra_certificates`.`count`, `nra_certificates`.`date_due`, `nra_certificates`.`date_deadline`, `nra_certificates`.`description` AS `certificate_description`, `ract_ratingactions_cstm`.`data_publ_reliza_c` AS `date_publ` FROM `nra_certificates` LEFT JOIN `opportunities_cstm` ON `opportunities_cstm`.`id_c` = `opportunities`.`id` WHERE (`nra_certificates`.`status` IN ('','pr','print','send_drb') OR `nra_certificates`.`status` IS NULL) AND ( `ract_ratingactions_cstm`.`rating_type_c` = `opportunities_cstm`.`last_rating_type_1_c` AND `opportunities_cstm`.`last_rating_status_1_c` NOT IN ('otozvan','priostanovlen') OR `ract_ratingactions_cstm`.`rating_type_c` = `opportunities_cstm`.`last_rating_type_2_c` AND `opportunities_cstm`.`last_rating_status_2_c` NOT IN ('otozvan','priostanovlen') ) AND `ract_ratingactions_cstm`.`data_publ_reliza_c` IS NOT NULL AND `nra_certificates`.`deleted` = 0 Используйте верхний регистр для написания SQL-команд. это позволит визуально легко отличать команды от названия таблиц и полей, что тоже способствует повышению читабельности SQL-запроса.
×