Нужно ли писать комментарии к функциям?
Вопрос по большому счету однозначный, конечно нужно. Но делать это нужно с не меньшей тщательностью чем написание самого кода. Комментарии нужны, для того чтобы помочь человеку, который впервые видит функцию понять что она делает. И совершенно ненужны комментарии которые написаны лишь для того чтобы код соответствовал код стилю. Яркий пример - это следующий комментарий к функции getCustomer()
Ну вот правда - это просто лишняя строка кода, прочитав его я не получу ни какой новой инфы о том что делает функция getCustomer(), то что она получает покупателя я и так вижу из названия. Откуда она его получает, для чего, какие конкретно данные о покупателе она получает, не понятно (тут не будем останавливаться на том что тип возвращаемого значения можно указывать, в данном случае это лишнее).
Вопрос по большому счету однозначный, конечно нужно. Но делать это нужно с не меньшей тщательностью чем написание самого кода. Комментарии нужны, для того чтобы помочь человеку, который впервые видит функцию понять что она делает. И совершенно ненужны комментарии которые написаны лишь для того чтобы код соответствовал код стилю. Яркий пример - это следующий комментарий к функции getCustomer()
/** Функция для получения покупателей **/.
Ну вот правда - это просто лишняя строка кода, прочитав его я не получу ни какой новой инфы о том что делает функция getCustomer(), то что она получает покупателя я и так вижу из названия. Откуда она его получает, для чего, какие конкретно данные о покупателе она получает, не понятно (тут не будем останавливаться на том что тип возвращаемого значения можно указывать, в данном случае это лишнее).
Почему бы для этой функции не написать вот такой комментарий
Так же при оформлении комментариев хорошей практикой является придерживание определенных стандартов. Для каждого языка они свои, но в целом очень похожи. Например для PHP - это PHPDoc. Многие редакторы также понимают синтаксис стандартных комментариев PHPDoc.
/** Получает строку с данными покупателя из таблицы customers **/На мой взгляд этот комментарий не на много длиннее, но значительно информативнее. Прочитав его я могу понять что мне ждать в ответе. Это либо null, либо строка из таблицы customers.
Так же при оформлении комментариев хорошей практикой является придерживание определенных стандартов. Для каждого языка они свои, но в целом очень похожи. Например для PHP - это PHPDoc. Многие редакторы также понимают синтаксис стандартных комментариев PHPDoc.
Как правильно документировать код.
1. Начать писать писать комментарии к функциям на этапе начала разработки. То есть написал функцию и сразу задокументировал ее. Ок все правильно сделал.
2. После того как свеженькая функция задокументирована сразу можно начать ее править, естественно уже написанные комментарии при этом менять не нужно, ну или максимум поменять только при первой правке, больше смысла не имеет.
3. Понять что написанная функция не нужна в принцыпе и удалить ее.
4. Нет все таки нужна! Написать заново, но наученный прошлым опытом решить задокументировать потом.
5. Дописать первую версию фичи, попытаться задокументировать то что было пропущено в процессе разработки.
6. Получить порцию правок, начать внедрять их не обращая внимания на комментарии.
7. Попробовать выпустить релиз.
8. Понять что все работает не так, в панике править имеющийся код и дописывать новые функции не обращая внимание на комментарии.
9. Тешить себя мыслью, что будет время для рефакторинга.
10. Начать разработку новой фичи.
1. Начать писать писать комментарии к функциям на этапе начала разработки. То есть написал функцию и сразу задокументировал ее. Ок все правильно сделал.
2. После того как свеженькая функция задокументирована сразу можно начать ее править, естественно уже написанные комментарии при этом менять не нужно, ну или максимум поменять только при первой правке, больше смысла не имеет.
3. Понять что написанная функция не нужна в принцыпе и удалить ее.
4. Нет все таки нужна! Написать заново, но наученный прошлым опытом решить задокументировать потом.
5. Дописать первую версию фичи, попытаться задокументировать то что было пропущено в процессе разработки.
6. Получить порцию правок, начать внедрять их не обращая внимания на комментарии.
7. Попробовать выпустить релиз.
8. Понять что все работает не так, в панике править имеющийся код и дописывать новые функции не обращая внимание на комментарии.
9. Тешить себя мыслью, что будет время для рефакторинга.
10. Начать разработку новой фичи.
Прогресс ради прогресса
#личноемнение
1. Фейковое развитие 🏗🏕
====================================================
Задумался тут вот о такой штуке как развитие веба. Безусловно он сейчас, как говориться, шагнул очень далеко, и получил широкое развитие. Но вот только на мой взгляд он идет по экстенсивному пути. То есть несмотря на то что все разработчики, все издания, гайды, приложения и т.д. пишут о необходимости минимизации трафика, оптимизации использования ресурсов, сжатии и обфускации кода, оптимизации картинок и много еще всего такого. Вот несмотря на все это по факту мы ничего не оптимизируем, а тупо увеличиваем мощности, расширяем каналы трафика, увеличиваем скорости интернета, увеличиваем объемы памяти. Все это конечно здорово что интернет становится быстрее, и компы становятся все мощнее, но из за того что в разработке мы только лишь говорим об оптимизации, но по большому счету ей не занимаемся, мы не видим существенного улучшения от этого.
2. Пруфы ⚙️📺
====================================================
Приведу небольшой пример который немного визуализирует то что хотел сказать. 10 лет назад я мог без труда зайти на ютубчик и смотреть на нем любимые видосики я могу сделать это и сейчас, собственно ни чего не изменилось все как и 10 лет назад. Но есть одно отличие 10 лет назад я делал это на компе у которого было внимание 512 MB оперативы. Да и по тем меркам это был хлам, но тем не менее видосики на нем я смотрел без особых проблем. Скажу больше, я на нем не только их смотрел но и монтировал и рендерил. На моем нынешнем ноуте имеется 8 GB оперативной памяти, что в 16 раз больше. При сравнении кажется как это дофига, но хотя давайте взглянем. Просто два открытых поисковика в хроме сейчас занимают 400 мегабайт моей оперативы, на что! что блин на главной странице Яндекса и Гугла такого что может весить 400 мгабайт (ну ладно, если быть честными до конца сами страницы весят по 80 и 40 метров, остальное это движок хрома, но все равно я блин просто открыл браузер и лишился 400 мегабайт). Ок давайте посмотрим какой нибудь видосик. Что правда? 570 мегабайт для трех вкладок? Ок на своем старом компе посмотреть это видео нормально мне уже не удастся. Да и на современном если я активно работаю, например у меня открыт пхпшторм, пару вкладок в браузере и в другом браузере фоном играет музыка, я уже испытываю затруднения. Про рендеринг видео говорить не приходится. То есть по сути что раньше что сейчас я могу выполнять одни и те же задачи причем с одинаковой загрузкой компьютера.
3. Сейчас научу как надо 😂📚
====================================================
Что-ж это не радует даже несмотря на лучшее качество видео и прочие и т.д. Все таки хотелось бы чтобы по мере прогресса одни и те же задачи становились легче и занимали относительно меньше ресурсов. Что я хочу сказать - если 10 лет назад на среднем компе я мог монтировать видео среднего для того времени качества, то сейчас на среднем компе я хочу монтировать 2 видео среднего для настоящего времени качества. Это называется интенсивный рост, то есть качественный. Это прогресс здорового человека а не просто тупое увеличение мощностей.
Немного утрированная мысль конечно но все же думаю имеет под собой определенное здравое зерно.
#личноемнение
1. Фейковое развитие 🏗🏕
====================================================
Задумался тут вот о такой штуке как развитие веба. Безусловно он сейчас, как говориться, шагнул очень далеко, и получил широкое развитие. Но вот только на мой взгляд он идет по экстенсивному пути. То есть несмотря на то что все разработчики, все издания, гайды, приложения и т.д. пишут о необходимости минимизации трафика, оптимизации использования ресурсов, сжатии и обфускации кода, оптимизации картинок и много еще всего такого. Вот несмотря на все это по факту мы ничего не оптимизируем, а тупо увеличиваем мощности, расширяем каналы трафика, увеличиваем скорости интернета, увеличиваем объемы памяти. Все это конечно здорово что интернет становится быстрее, и компы становятся все мощнее, но из за того что в разработке мы только лишь говорим об оптимизации, но по большому счету ей не занимаемся, мы не видим существенного улучшения от этого.
2. Пруфы ⚙️📺
====================================================
Приведу небольшой пример который немного визуализирует то что хотел сказать. 10 лет назад я мог без труда зайти на ютубчик и смотреть на нем любимые видосики я могу сделать это и сейчас, собственно ни чего не изменилось все как и 10 лет назад. Но есть одно отличие 10 лет назад я делал это на компе у которого было внимание 512 MB оперативы. Да и по тем меркам это был хлам, но тем не менее видосики на нем я смотрел без особых проблем. Скажу больше, я на нем не только их смотрел но и монтировал и рендерил. На моем нынешнем ноуте имеется 8 GB оперативной памяти, что в 16 раз больше. При сравнении кажется как это дофига, но хотя давайте взглянем. Просто два открытых поисковика в хроме сейчас занимают 400 мегабайт моей оперативы, на что! что блин на главной странице Яндекса и Гугла такого что может весить 400 мгабайт (ну ладно, если быть честными до конца сами страницы весят по 80 и 40 метров, остальное это движок хрома, но все равно я блин просто открыл браузер и лишился 400 мегабайт). Ок давайте посмотрим какой нибудь видосик. Что правда? 570 мегабайт для трех вкладок? Ок на своем старом компе посмотреть это видео нормально мне уже не удастся. Да и на современном если я активно работаю, например у меня открыт пхпшторм, пару вкладок в браузере и в другом браузере фоном играет музыка, я уже испытываю затруднения. Про рендеринг видео говорить не приходится. То есть по сути что раньше что сейчас я могу выполнять одни и те же задачи причем с одинаковой загрузкой компьютера.
3. Сейчас научу как надо 😂📚
====================================================
Что-ж это не радует даже несмотря на лучшее качество видео и прочие и т.д. Все таки хотелось бы чтобы по мере прогресса одни и те же задачи становились легче и занимали относительно меньше ресурсов. Что я хочу сказать - если 10 лет назад на среднем компе я мог монтировать видео среднего для того времени качества, то сейчас на среднем компе я хочу монтировать 2 видео среднего для настоящего времени качества. Это называется интенсивный рост, то есть качественный. Это прогресс здорового человека а не просто тупое увеличение мощностей.
Немного утрированная мысль конечно но все же думаю имеет под собой определенное здравое зерно.
Многие новички не уделяют должного времени на изучение GIT перед тем как начать свою карьеру в разработке. Из-за этого приступив к командной разработки, они могут доставить много головной боли и себе и всей команде. Начиная с попадания в коммиты каких-то левых файлов и заканчивая затиранием измененией своих коллег. Ох как это доставляет, когда смотришь коммит джуна и спрашиваешь - "а зачем ты удалил какую то функцию из ядра проекта?". Ответ - "я там ни чего не трогал". Ну классика же). Или когда кто то путается в своих же фичах и бранчах и теряет изменения. Ну это ли не веселье - всей командой отыскивать и восстанавливать его изменения. Это не для обиды написано или чтобы над кем то посмеяться, а для того чтобы обратить внимание на такой важнейший инструмент как GIT.
Приведу буквально 5 команд которые вы должны знать на отлично, чтобы избежать этих проблем.
1. Клонирование репозитория. Понимать разницу между работой с репозиторием по https и ssh. Уметь настроить доступ по ssh. Команда
1. Клонирование репозитория. Понимать разницу между работой с репозиторием по https и ssh. Уметь настроить доступ по ssh. Команда
git clone
2. Создание, удаление, переключение между ветками. Особое внимание тут нужно уделить пониманию как ведут себя ваши не закомиченные изменения при переключении между ветками и создании новых веток. git branch, git branch -d, git checkout
3. Понимание разницы между локальной и удаленной веткой. Синхронизация с удаленной веткой. Подтянуть, запушить изменения. git pull , git push
4. Понимание состояний изменений. Незакомичено, добавлено в индекс, закомичено. Умение их отменить и добавить. git commit, git checkout, git add, git reset
5. Переключение между между коммитами, понимать что такое HEAD git checkout
6. Это уже в виде факультатива, не раз видел как разрабы проработавшие больше года не могли сменит адрес или имя ссылки на удаленный репозиторий. git remote -v git remote add git remote get-url
Если вы будете кристально прозрачно понимать эти концепции - цены вам не будет на начальных этапах. Удачи!Шаблонизаторы
Всегда недолюбливал синтаксис шаблонизаторов в PHP. Ну вот хоть убейте не вижу в них большого смысла. Вот как раз недавно наткнулся на вот такой вот кусок кода в пыховском файле. Там конечно намешена и логика и отображение и в целом этот код не очень, но на нем можно хорошо проиллюстрировать мысль что не так сильно уж шаблонизаторы упрощают жизнь.
Вот кусок этого кода на PHP:
Смысл в том, что сам по себе шаблонизатор не делает код сильно понятнее если к этому не стремиться. Просто переписав "лапшу" на шаблонизаторе она не перестанет быть лапшой.
Вот например не мой взгляд код который действительно понятный и лаконичный и на PHP и на TWIG:
Всегда недолюбливал синтаксис шаблонизаторов в PHP. Ну вот хоть убейте не вижу в них большого смысла. Вот как раз недавно наткнулся на вот такой вот кусок кода в пыховском файле. Там конечно намешена и логика и отображение и в целом этот код не очень, но на нем можно хорошо проиллюстрировать мысль что не так сильно уж шаблонизаторы упрощают жизнь.
Вот кусок этого кода на PHP:
//PHP - вытащил пример из реального кодаА вот как он бы выглядел если бы был написан с использованием шаблонизатора TWIG:
<? if $user['balance_type']!=2 { ?>
<div class="panel panel-default">
<!--какой то html-->
</div>
<? } ?>
//переписал его на TWIG (разница небольшая)И вот хоть убейте меня не вижу я тут большой разницы, ну эти два говнокода абсолютно одинаковые и ни как шаблонизатор не сделал из него что то похожее на "best practices" код.
{% if balance_type !=2 %}
<div class="panel panel-default">
<!--какой то html-->
</div>
{% endif %}
Смысл в том, что сам по себе шаблонизатор не делает код сильно понятнее если к этому не стремиться. Просто переписав "лапшу" на шаблонизаторе она не перестанет быть лапшой.
Вот например не мой взгляд код который действительно понятный и лаконичный и на PHP и на TWIG:
//phpТут в переменной передается просто имя класса которое ставить например блок в display: none. Подойдет конечно не для всех случаев но смысл думаю ясен.
<div class="panel panel-default <?=$is_none?>">
<!--какой то html-->
</div>
//twig
<div class="panel panel-default {{ is_none }}">
<!--какой то html-->
</div>
#продвижениебизнеса
#оффтоп
✅ Ха-ха
Американец продал свой пикап автосалону и не снял с него рекламу своего бизнеса. Ну и где же он его увидел в следующий раз? Конечно же у террористов.
С зениткой в кузове!
❌ После этого мужик получил много звонков в свою фирму)))
Возьмем на заметку как новый рекламный канал.
#оффтоп
✅ Ха-ха
Американец продал свой пикап автосалону и не снял с него рекламу своего бизнеса. Ну и где же он его увидел в следующий раз? Конечно же у террористов.
С зениткой в кузове!
❌ После этого мужик получил много звонков в свою фирму)))
Возьмем на заметку как новый рекламный канал.
🥳👏👍
В последнем релизе Telegram ввел некоторые новые фичи, наиболее значимой и не побоюсь этого слова долгожданной из которые являются папки. Когда эту возможность только анонсировали - очень ждал ее, потому как - это сильно упростит жизнь и позволит систематизировать чаты.
❗️❗️❗️🤦♀️🤦♂️🤷♀️🤷♂️
И вот релиз, и вот первые разочарования. Ну правда, может это я конечно что то не допонял, но вот такой странной реализации этого функционала ни как не ожидал. Если создать папку и положить в нее какие то чаты то я естественно ожидаю что эти чаты пропадут у меня из общего потока и будут отображаться только в этой папке. Но почему то разработчики посчитали такое поведение неправильным. И сделали так, что после того как я засунул всякие спамные чаты в отдельную папку они мало того, что не пропали у меня из общего потока, так теперь еще и сама папка мне сигнализирует что в ней лежат непрочитанные сообщения. Блин ну как так то.
✅Опять же на мой взгляд - это то случай когда не надо было ни чего изобретать и пытаться что то улучшить, а просто взять уже всем привычную логику и перенести ее к себе. Любой человек работает с папками у себя на компе и он привык к этой логике, ну вот не чего тут по моему изобретать. Ну как говориться как есть так и хорошо.
❤️🌈Все равно Telegram крутой, может когда то и переделают)))
В последнем релизе Telegram ввел некоторые новые фичи, наиболее значимой и не побоюсь этого слова долгожданной из которые являются папки. Когда эту возможность только анонсировали - очень ждал ее, потому как - это сильно упростит жизнь и позволит систематизировать чаты.
❗️❗️❗️🤦♀️🤦♂️🤷♀️🤷♂️
И вот релиз, и вот первые разочарования. Ну правда, может это я конечно что то не допонял, но вот такой странной реализации этого функционала ни как не ожидал. Если создать папку и положить в нее какие то чаты то я естественно ожидаю что эти чаты пропадут у меня из общего потока и будут отображаться только в этой папке. Но почему то разработчики посчитали такое поведение неправильным. И сделали так, что после того как я засунул всякие спамные чаты в отдельную папку они мало того, что не пропали у меня из общего потока, так теперь еще и сама папка мне сигнализирует что в ней лежат непрочитанные сообщения. Блин ну как так то.
✅Опять же на мой взгляд - это то случай когда не надо было ни чего изобретать и пытаться что то улучшить, а просто взять уже всем привычную логику и перенести ее к себе. Любой человек работает с папками у себя на компе и он привык к этой логике, ну вот не чего тут по моему изобретать. Ну как говориться как есть так и хорошо.
❤️🌈Все равно Telegram крутой, может когда то и переделают)))
#лайфхак
Иногда бывает нужно в одном запросе соединить две таблицы по связи один ко многим, но не так как это сделает JOIN, соединив одну строку с несколькими связанными. Нужно чтобы получилась одна строка в которой есть поле содержащее строки из связанной таблицы.
Тут можно сделать 2 запроса и потом их обработать нужным образом, или если вы используете фреймоворк там это тоже реализовано, но все равно там делается 2 запроса которые потом уже обрабатываются.
Вот способ как можно это сделать в одном запросе. Для этого нужно будет использовать возможности mySql по работе с Json. А именно функции GROUP_CONCAT - эта функция конкатенирует результаты всего запроса, и функцию JSON_OBJECT которая создает Json строку.
Допустим имеем две следующие таблицы:
ORDERS
+----+------——-+
| id | name |
+----+---——----+
| 1 | ivan |
| 2 | elena |
| 3 | anonim |
+----+----——---+
GOODS
+----+-----———------+------—----+
| id | noscript | order_id |
+----+-------———----+----—------+
| 1 | phone | 1 |
| 2 | headphones | 1 |
| 3 | laptop | 2 |
| 4 | keyboard | 2 |
| 5 | camera | 3 |
+----+--------———---+------—-----+
Они связаны через поле goods.order_id. Предположим что мы хотим получить все товары которые заказала Елена. Чтобы у нас были такие поля order_id, order_name, order_goods. В поле order_goods будут лежать все строки из таблицы goods связанные с данным заказом.
Запрос будет выглядеть вот так:
Иногда бывает нужно в одном запросе соединить две таблицы по связи один ко многим, но не так как это сделает JOIN, соединив одну строку с несколькими связанными. Нужно чтобы получилась одна строка в которой есть поле содержащее строки из связанной таблицы.
Тут можно сделать 2 запроса и потом их обработать нужным образом, или если вы используете фреймоворк там это тоже реализовано, но все равно там делается 2 запроса которые потом уже обрабатываются.
Вот способ как можно это сделать в одном запросе. Для этого нужно будет использовать возможности mySql по работе с Json. А именно функции GROUP_CONCAT - эта функция конкатенирует результаты всего запроса, и функцию JSON_OBJECT которая создает Json строку.
Допустим имеем две следующие таблицы:
ORDERS
+----+------——-+
| id | name |
+----+---——----+
| 1 | ivan |
| 2 | elena |
| 3 | anonim |
+----+----——---+
GOODS
+----+-----———------+------—----+
| id | noscript | order_id |
+----+-------———----+----—------+
| 1 | phone | 1 |
| 2 | headphones | 1 |
| 3 | laptop | 2 |
| 4 | keyboard | 2 |
| 5 | camera | 3 |
+----+--------———---+------—-----+
Они связаны через поле goods.order_id. Предположим что мы хотим получить все товары которые заказала Елена. Чтобы у нас были такие поля order_id, order_name, order_goods. В поле order_goods будут лежать все строки из таблицы goods связанные с данным заказом.
Запрос будет выглядеть вот так:
SELECT *, (В результате в поле goods мы получим валидный Json со всеми товарами из таблицы
SELECT GROUP_CONCAT(
JSON_OBJECT(
'goods_id', id,
'goods_noscript', noscript
)
) FROM goods WHERE order_id = ord.id) as goods
FROM orders ord
WHERE id = 2
{
"goods_id": 3,
"goods_noscript": "laptop"
},
{
"goods_id": 4,
"goods_noscript": "keyboard"
}