13 Simple Rules for Good Coding (from my 15 years of experience) 번역한 글입니다.

나는 15 이상의 경력을 가진 프로그래머이며 많은 여러 언어, 패러다임, 프레임워크를 사용해봤고 많은 삽질을 해봤다. 그리고 나는 좋은 코딩을 작성하기 위한 나만의 규칙들을 여러분에게 공유하고자 한다.

 

1.      최적화 VS 가독성. 최적화보단 가독성

코드는 항상 읽기 쉽고 개발자들이 이해할 수 있게끔 작성하라. 읽기 어려운 코드를 읽는데 소모되는 시간과 비용은 최적화로부터 얻을 수 있는 것보다 더욱 크다. 최적화가 필요하다면, DI (의존성 주입)을 사용해 독립적인 모듈로 만들고, 100%의 테스트 커버리지를 유지하여 최소 1년간은 건들지 않아도 되도록 만들어라.

2.      아키텍처 우선

나는 “우리는 빨리 개발을 해야하기 때문에 아키텍처를 설계할 시간이 없다”라고 말하는 사람을 많이 봐왔다. 그리고 그 중 99%가 이러한 생각 때문에 큰 문제를 겪었다.

아키텍처를 생각하지 않고 코드를 작성하는 것은 목표 달성을위한 계획없이 자신의 욕망을 꿈꾸는 것처럼 쓸모가 없다. 코드를 작성하기 전에 먼저 수행 할 작업, 사용 방법, 모듈화 방법, 서비스가 서로 어떻게 동작하는지, 구조가 무엇인지, 테스트 및 디버깅 방법, 업데이트 방법들을 먼저 생각하고 이해해야한다.

3.      테스트 커버리지

테스트는 좋은 일이지만 항상 비용 효율적인건 아니며 프로젝트에 따라 다르다.

테스트가 필요한 경우:

·         최소 한 달간은 건들지 않아도 될 모듈이나 마이크로서비스를 개발하는 경우

·         오픈소스 코드를 작성하는 경우

·         핵심 코드 또는 금전적인 부분과 맞닿는 코드를 작성하는 경우

·         코드를 업데이트 하는 것과 동시에 테스트를 업데이트 할 수 있는 충분한 비용이 있는 경우

테스트가 필요하지 않는 경우:

·         스타트업인 경우

·         팀이 작고 코드가 빠르게 변하는 경우

·         출력값을 보고 간단하게 수동으로 테스트가 가능한 스크립트를 작성하는 경우

나쁜 테스트 코드와 함께 코드를 짜는 것은 테스트가 없는 코드보다 더 위험할 수 있음을 기억하라.

4.      간단하고 단순하게

복잡한 코드를 작성하지 말라. 간단하게 작성하면 버그가 줄어들고 디버깅 시간도 줄어들 수 있다. 코드는 수많은 추상화 및 기타 객체지향적인 문제 (특히 Java 개발자와 관련이 있음) 없이 딱 필요한 일만을 수행해야하며, 추후에 간단한 방법으로 코드를 업데이트하기 위해 필요한 것의 20%를 수행해야한다.

5.      주석

주석은 나쁜 코드를 보여준다. 좋은 코드는 주석 없이도 이해할 수 있어야한다. 그러면 새로운 개발자를 위해 시간을 절약하기 위해 해야 할 일은 무엇인가? — 메서드의 정의와 사용법을 설명하는 한 줄짜리 간단한 문서를 작성하라. 이는 이해를 위한 많은 시간을 절약해 줄 것이며 — 더 많은 사람들에게 메서드를 더 잘 구현할 수 있는 기회를 제공해준다. 또한 이는 글로벌 코드 문서화를 위한 좋은 시작점이 될 것이다.

6.      강한 결합 VS 느슨한 결합

항상 마이크로서비스 아키텍처를 사용하도록 노력하라. 모놀리틱 소프트웨어는 마이크로서비스 소프트웨어보다 빠르지만, 단일 서버 환경에서만 그렇다. 마이크로서비스는 여러분의 소프트웨어를 여러 서버로의 분산뿐만 아니라 가끔은 하나의 머신에서의 분산처리 (프로세스 분산을 의미한다)도 할 수 있는 가능성을 제공해준다.

7.      코드 리뷰

코드 리뷰는 좋을 수도 있고 나쁠 수도 있다.

여러분의 팀에 코드의 95%를 이해하고 있고 시간 낭비 없이 모든 업데이트 사항을 모니터링 할 수 있는 개발자가 있는 경우에만 코드 리뷰를 도입하도록 하라. 이 외의 경우에는 단지 시간 낭비가 될 수 있으며 모두가 이를 싫어하게 될 것이다. 이 부분은 많은 질문을 가져오기 때문에 이를 좀 더 깊게 살펴보자.

많은 사람들은 코드 리뷰가 새로운 사람이나 코드의 다른 부분을 작업하는 팀원을 가르치는 좋은 방법이라고 생각한다. 그러나 코드 리뷰의 주요 목표는 코드 품질을 유지하는 것이지 가르치는게 아니다. 여러분의 팀이 원자로 또는 우주 로켓 엔진 냉각 시스템을 제어하는 코드를 작성했다고 가정해보자. 그리고 여러분은 아주 어려운 로직에서 큰 실수를 저질렀고, 이를 새로운 사람에게 코드 리뷰를 위해 제공했다고 해보자. 이 경우 여러분은 사고 위험에 대해 어떻게 생각하는가? — 내 대답은 70% 이상이다.

좋은 팀은 각자가 자신의 역할을 가지고 있으며 일의 한 부분에 대해 완전한 책임감을 갖고 있는 팀이다. 만약 누가 코드의 다른 부분을 이해하고 싶으면 해당 부분을 담당하고 있는 사람에게 찾아가 질문을 하면된다. 모든걸 아는건 불가능하며 전체보다는 코드의 작은 부분을 (하지만 적어도 30%) 완전히 이해하는것이 더 낫다.

8.      리팩토링은 작동하지 않는다

나는 일하는 동안 “나중에 리팩토링 할거니까 걱정하지마라”라는 말을 많이 들었다. 그리고 나중에 이는 큰 기술적 부채로 돌아오거나 모든 코드를 다 삭제한 후 처음부터 다시 작성하게 되었다.

따라서 처음부터 여러번 소프트웨어 다시 개발할 수 있는 자금이 있는게 아니라면 부채를 만들지 말라.

9.      피곤하거나 컨디션이 좋지 않을때 코딩하지 말라

개발자들이 피곤할 땐 평소보다 2-5배 더 많은 버그와 실수를 만들어낸다. 따라서 과업은 매우 나쁘다. 그렇기 때문에 하루의 업무시간을 약 6시간으로 고려하는 국가가 점점 더 많아지고 있으며, 일부 국가에서는 이미 실천하고있다. 정신적인 일은 육체적인 일을 다루는 것과 같지 않다.

10.  모든걸 한꺼번에 작성하자 말라 - 반복적으로 개발하라

코드를 작성하기 전에 우선 여러분의 고객과 클라이언트가 정말로 필요로 하는걸 분석하고 예측하고, 짧은 기간동안 개발할 수 있는 MVF(Most Valuable Features)를 추려내라. 품질 업데이트를 배포하기 위해 이러한 반복을 사용하도록 하고 무리한 요구사항과 품질 희생에 시간과 자원을 낭비하지말라.

11.  자동화 VS 수동

자동화는 장기적으로 100% 성공이다. 따라서 지금 당장 무언가를 자동화 할 수 있는것이 있다면 바로 하도록 하라. 5 분 밖에 걸리지 않는데, 왜 자동화 해야해?”라고 생각할 수도 있다. 하지만 한 번 계산해보자. 예를 들어 5명의 개발자로 이루어진 팀의 일상적인 작업을 들어보자. 5 * 5 * 21 * 12개월 = 6,300 = 105시간 = 13.125 ~ 5,250$. 직원이 40,000명일 경우엔 비용이 얼마나 커질까?

12.  나가서 취미를 갖자

일의 차별화는 정신 능력을 향상시키며 새롭고 신선한 아이디어를 제공한다. 따라서 잠시 쉬고 신선한 공기를 마시거나 친구들과 이야기를 하거나 기타를 연주하는등의 취미를 가져라.

13.  여유 시간에 새로운걸 배워라

학습을 중단하면 퇴화하기 시작한다.

 

좋은 코드 작성에 대한 아이디어와 관행에 대한 의견을 공유해준다면 매우 감사하겠다.

 

[출처]

https://mingrammer.com/translation-13-simple-rules-for-good-coding

 


저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by MoGuWai 모과이IT

PHP 코드 쪽에서



mysqli_query($conn,"set names utf8;");



위의 코드를 삽입한다.


저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by MoGuWai 모과이IT

기본 문자셋 설정

언어셋을 따로 설정하지 않고 DB를 생성하게 되면 latin1로 설정된다. 이 경우 게시판등에 한글이 출력될때는 문제가 없을수도 있으나 DB 자료 자체를 출력해보면 ??? 와 같은 문자로 출력된다.

BASH
sudo vi /etc/mysql/my.cnf

  [client]
  default-character-set = utf8

  [mysqld]
  character-set-client-handshake=FALSE
  init_connect="SET collation_connection = utf8_general_ci"
  init_connect="SET NAMES utf8"
  character-set-server = utf8 
  collation-server = utf8_general_ci

  [mysqldump]
  default-character-set = utf8

  [mysql]
  default-character-set = utf8

수정한 후에는 MySQL을 재시작한다.

BASH
sudo service mysql restart

우선 mysql 로그인을 한다.

BASH
mysql -uroot -p

문자셋을 확인한다.

BASH
mysql> status

  Server characterset:	utf8
  Db     characterset:	utf8
BASH
mysql> show variables like '%char%';

  +--------------------------+----------------------------+
  | Variable_name            | Value                      |
  +--------------------------+----------------------------+
  | character_set_client     | utf8                       |
  | character_set_connection | utf8                       |
  | character_set_database   | utf8                       |
  | character_set_filesystem | binary                     |
  | character_set_results    | utf8                       |
  | character_set_server     | utf8                       |
  | character_set_system     | utf8                       |
  | character_sets_dir       | /usr/share/mysql/charsets/ |
  +--------------------------+----------------------------+

max_allowed_packet 설정

이 값에 의해 쿼리문등으로 전송량이 결정된다. 기본값이 16M인데 이 값이 작아 오류를 내기도 한다.

BASH
sudo vi /etc/mysql/my.cnf

  [mysqld]
  max_allowed_packet    = 256M

MySQL 재시작

BASH
sudo service mysql restart

서버 이전시 DB 문자셋이 깨질경우 참고할 내용

http://blog.naver.com/PostView.nhn?blogId=nanobox&logNo=130165727244

MySQL 최적화

MySQL 서버를 최적화하기 위해 Percona's my.cnf generating tool을 사용하여 my.cnf 파일을 생성할 수 있다. 각각의 단계별 질문과 대답의 형식으로 my.cnf 파일을 생성해 준다. 이미 데이터가 들어있고 운영중인 MySQL 서버라면 백업하고 MySQL을 멈춘후 파일을 교체해야 한다.

백업하기

BASH
mysqldump --all-databases --all-routines -u root -p > ~/fulldump.sql

MySQL 서비스중지

BASH
sudo service mysql stop

원본 my.cnf 백업하고 새 파일로 교체

BASH
sudo cp /etc/my.cnf /etc/my.cnf.backup
sudo cp /path/to/new/my.cnf /etc/my.cnf

기존의 데이터베이스를 삭제하고 재설치

BASH
sudo rm -rf /var/lib/mysql/*
sudo mysql_install_db
sudo chown -R mysql: /var/lib/mysql
sudo service start mysql

Finally all that's left is to re-import your data. To give us an idea of how far the import process has got you may find the 'Pipe Viewer' utility, pv, useful. The following shows how to install and use pv for this case, but if you'd rather not use it just replace pv with cat in the following command. Ignore any ETA times produced by pv, they're based on the average time taken to handle each row of the file, but the speed of inserting can vary wildly from row to row with mysqldumps:

sudo apt-get install pv

pv ~/fulldump.sql | mysql

Once that is complete all is good to go!

This is not necessary for all my.cnf changes. Most of the variables you may wish to change to improve performance are adjustable even whilst the server is running. As with anything, make sure to have a good backup copy of config files and data before making changes.


MySQL Tuner is a useful tool that will connect to a running MySQL instance and offer suggestions for how it can be best configured for your workload. The longer the server has been running for, the better the advice mysqltuner can provide. In a production environment, consider waiting for at least 24 hours before running the tool. You can get install mysqltuner from the Ubuntu repositories:


sudo apt-get install mysqltuner

Then once its been installed, run it:

mysqltuner

and wait for its final report. The top section provides general information about the database server, and the bottom section provides tuning suggestions to alter in your my.cnf. Most of these can be altered live on the server without restarting, look through the official MySQL documentation (link in Resources section) for the relevant variables to change in production. The following is part of an example report from a production database which shows there may be some benefit from increasing the amount of query cache:

-------- Recommendations -----------------------------------------------------

General recommendations:

    Run OPTIMIZE TABLE to defragment tables for better performance

    Increase table_cache gradually to avoid file descriptor limits

Variables to adjust:

    key_buffer_size (> 1.4G)

    query_cache_size (> 32M)

    table_cache (> 64)

    innodb_buffer_pool_size (>= 22G)

One final comment on tuning databases: Whilst we can broadly say that certain settings are the best, performance can vary from application to application. For example, what works best for Wordpress might not be the best for Drupal, Joomla or proprietary applications. Performance is dependent on the types of queries, use of indexes, how efficient the database design is and so on. You may find it useful to spend some time searching for database tuning tips based on what applications you're using it for. Once you get past a certain point any adjustments you make will only result in minor improvements, and you'll be better off either improving the application, or looking at scaling up your database environment through either using more powerful hardware or by adding slave servers.



출처: http://webdir.tistory.com/217

저작자 표시 비영리 동일 조건 변경 허락
신고

'개발지식창고 > Web_DB' 카테고리의 다른 글

[Ubuntu] 우분투 MySQL 설정  (0) 2017.03.25
Posted by MoGuWai 모과이IT


티스토리 툴바